Datenbanksysteme

Dieser Artikel soll eine Einührung in den allgemeinen Aufbau von Datenbanksystemen bieten. Dabei wird nicht speziell auf ein Produkt, sondern auf den allgemeinen Aufbau eingegangen.

Datenbanksystem

Ein Datenbanksystem (kurz DBS = DataBase System) besteht aus zwei Hauptkomponenten:

1. dem Datenbankverwaltungssystem (DBMS = DataBase Management System)
2. und der eigentlichen Datenbank (DB = DataBase)

Datenbank

Die Datenbank ist der Teil eines DBS, in welchem die Daten physisch abgespeichert sind (meist in Form von Tabellen). Neben den eigentlichen Nutzdaten werden auch noch Informationen wie Indizes, Logs und Meta-Daten in der DB abgespeichert.

Datenbankverwaltungssystem

Das Datenbankverwaltungssystem liefert diverse Unterstützungsdienste und regelt den Zugriff auf die DB. Zusammengefasst hat ein DBMS folgende Aufgaben:

• Zugriff auf die DB ermöglichen
• Verwaltung der Index-Dateien
• Transaktionsverwaltung
• Korrektheit bei Mehrbenutzerbetrieb gewährleisten
• Datensicherung
• Sicherheit

• Die Daten werden abstrahiert, der Zugriff wird also einfacher
• die Verwendung eines DBMS spart Zeit und somit Geld gegenüber dem direkten Datenzugriff auf Dateiebene
• Man braucht sich nicht um die Integrität der Daten zu kümmern

Architektur

Das DBMS kann vom Programmierer als Blackbox betrachtet werden, d.h. man braucht sich nicht darum zu kümmern, wie ein DBMS aufgebaut ist. Es ist aber dennoch nützlich, wenn man grundlegend über die Arbeitsweise des DBMS Bescheid weiss.

Ein DBMS ist vereinfacht ausgedrückt in drei Ebenen unterteilt:

1. die externe Ebene (benutzerspezifische Sicht)
2. die konzeptuelle Ebene (logische Sicht)
3. die interne Ebene (physische Sicht)

Zum besseren Verständnis eine Darstellung dieser drei Ebenen:

Interne Ebene

Die interne Ebene kümmert sich um die physische Abspeicherung der Daten. Weiter ist die Verwaltung des Pufferspeichers auf dieser Ebene angesiedelt.

Die kleinsten Einheiten sind dabei sog. Seiten, die von der internen Ebene zwischen dem physischen Datenspeicher (Harddisk) und dem Memory hin und her bewegt werden. Eine weitere wichtige Aufgabe der internen Ebene ist die Sicherung der Datenkonsistenz zwischen Datenspeicher und Memory (Synchronisation). Sollten sich Datenobjekte ändern, so verwaltet die interne Ebene, wie die Speicherseiten verändert werden müssen. Ausserdem hat die interne Ebene die Aufgabe, die Indizes zu verwalten.

Konzeptuelle Ebene

Die konzeptuelle Ebene befasst sich mit der Abstraktion der Daten. D.h. die Darstellung der Daten, die im physischen Schema vorliegen, wird so angepasst, wie sie der Benutzer haben möchte und umgekehrt. In einem relationalen Datenbanksystem möchte der Benutzer Daten in Form von ganzen Tabellen sehen und nicht in der Form, wie die Daten in der internen Ebene vorliegen.

Die konzeptuelle Ebene hat zusammengefasst die Aufgabe, die Daten für die interne/externe Ebene entsprechend darzustellen.

Externe Ebene

Die Bereitstellung der Daten erfolgt in der externen Ebene durch ein Anwendungsprogramm.

Der Benutzer interagiert nur mit der externen Ebene eines Datenbanksystems, die beiden tieferen Ebenen bleiben ihm verborgen.

Ablauf einer Abfrage

Stellt der Benutzer eine Anfrage an ein Datenbanksystem, so sieht dies meistens nicht nach viel Arbeit aus - das Ergebnis erscheint meist schon nach wenigen Millisekunden. Im Datenbanksystem selber werden jedoch viele Operationen durchgeführt. Der Ablauf einer Abfrage kann (stark vereinfacht) wie folgt aussehen:

1. Das Datenbanksystem empfängt die vom Benutzer gestellte Anfrage
2. Die Anfrage läuft durch eine Syntaxprüfung und wird validiert
3. Das DBS prüft, ob der Benutzer die notwendigen Rechte zum Ausführen der gestellten Anfrage besitzt
4. Die physischen Daten und deren Zugriffspfade werden ermittelt (Umwandlung der externen Sicht in die interne Sicht)
5. Das DBS beauftragt das Betriebssystem mit dem lesen der ermittelten Speicherbereiche
6. Die gelesenen Daten werden vom Betriebssystem in den Systempuffer des Datenbanksystems geschrieben
7. Die Daten werden in die externe Sicht überführt und der Anfrage entsprechend zusammengestellt
8. Das Datenbanksystem sperrt die Daten für andere Benutzer solange, bis deren Bearbeitung abgeschlossen ist
9. Die transformierten Daten werden dem Anwendungsprogramm übergeben und gelangen somit zurück zum Benutzer

Transaktionen

Eine Transaktion ist ein Stapel an SQL-Anweisungen, der vom Datenbanksystem als ganzes abgearbeitet wird. Sämtliche Transaktionen werden von der Datenbank in einem sog. Transaktionsprotokoll geloggt. Tritt in einer SQL-Anweisung innerhalb einer Transaktion ein Fehler auf, so kann mithilfe des Transaktionsprotokolls wieder der Ursprungszustand hergestellt werden.

Physische Architektur

Die Aufgabe eines Datenbanksystems ist es, verschiedenen Benutzern einen Zugriff auf einen Datenbestand über ein Netzwerk zu bieten. Es gibt verschiedene Ansätze, wie dieser Zugriff bewerkstelligt werden kann. Dabei kann zwischen folgenden drei Ansätzen unterschieden werden:

• Client/Server
• File/Server
• Hostbasiertes System

Dabei spielt es keine Rolle, ob sich der Client und der Server physisch auf dem gleichen Rechner befinden oder über ein Netzwerk miteinander verbunden sind.

Client/Server Architektur

Die meisten modernen DBS setzen auf der Client/Server-Architektur auf. Dabei laufen auf dem Client und dem Server zwei unabhängige Prozesse. Die Kommunikation läuft über eine definierte Schnittstelle nach dem Frage-Antwort-Prinzip. Der Server bietet den Clients also einen Dienst an, die Clients nehmen diesen in Anspruch.

Der Vorteil an dieser Architektur ist derjenige, dass der Server den Datenbestand selbständig verwaltet und somit mehrere Clients über den Server auf diesen Datenbestand zugreifen können.

Client und Server können auch auf dem gleichen Rechner laufen. Auch hier spricht man von einer Client/Server-Architektur, da der Client- und der Serverprozess nach wie vor selbständig agieren. In der Regel wird der Serverprozess aber auf einen leistungsstarken Rechner gelegt, der sonst keinen Client-Aufgaben nachkommen muss und dementsprechend schneller läuft.

Beispiele für Client/Server-DBS sind:

• Oracle
• DB2
• PostgreSQL
• MySQL
• Microsoft SQL Server

File/Server Architektur

Bei einer File/Server-Architektur agiert ein Rechner zugleich als Client und als Server, es liegt keine physische Trennung vor. Mit anderen Worten; ein File/Server-DBS greift direkt auf den Datenbestand zu. Dieser Datenbestand kann entweder lokal, oder im Netzwerk auf einem anderen Rechner liegen.

Die Aufgabe, den Datenbestand zu verwalten kommt also nicht wie bei der Client/Server-Architektur dem Serverprozess zu, sondern wird direkt von einem Datenbanktreiber übernommen.

Die Datenbanktreiber können verwendete Datensätze mit Locks versehen. Ein Mehrbenutzerbetrieb ist also grundsätzlich möglich, jedoch nicht gerade performant. File/Server-DBS eignen sich eher für die Verwendung von einem einzigen Benutzer.

Beispiele für File/Server-DBS sind:

• Jet-Engine (Microsoft Access)
• FoxPro
• dBase
• Paradox

Hostbasierte Systeme

Ein hostbasiertes DBS besteht aus zwei Komponenten; dem Host und dem Terminal. Wie bei der Client/Server-Architektur greift hier der eine Rechner (Terminal) über den anderen Rechner (Host) auf den Datenbestand zu. Der Unterschied ist jedoch der, dass der Client- und der Serverprozess auf dem Host laufen, das Terminal dient nur zur Ein- und Ausgabe der Daten. Man spricht auch gelegentlich von dummen Terminals, da diese keinerlei Logik besitzen.