Home » Tutorials » Datenbanken » MySQL mit ZeosLib

MySQL mit ZeosLib

Grundlagen

Eine Datenbank ist erst mal eine Ansammlung von Daten. Diese Daten stehen miteinander in Beziehung. Man nennt dieses besondere Datenbankmodell, das in den 80ern entwickelt wurde, deshalb auch relationales Datenbankmodell. Der Vorteil dieses Modells ist, dass die Struktur der Datenbank sehr flexibel ist. Erweitert man die Datenbankstruktur müssen entsprechende Anwendungen nicht gezwungenermaßen neu geschrieben werden, wie es bei „flachen Dateien“ der Fall gewesen wäre. Bei flachen Dateien wird die Struktur fest in der Anwendung gespeichert. Schon kleinste Änderungen hätten unter Umständen eine aufwendige Modifikation der Hauptanwendung zur Folge.

Datenbanken werden heutzutage überall eingesetzt, sei es in großen Unternehmen, um beispielsweise Kundendaten zu verwalten oder privat zu Hause als kleine Adressdatenbank. Ein normales Adressbuch kann man im Prinzip auch als Datenbank auf dem Papier ansehen.

Aufbau einer relationalen Datenbank

Eine Datenbank (engl. database) besteht in der Regel aus einer oder mehreren Tabellen (engl. table). In diesen Tabellen befinden sich die Daten. Eine Tabelle oder auch Relation genannt, ist, wie der Name schon sagt, wie eine normale Tabelle aufgebaut. Die Spalten nennen sich dabei Felder (engl. field), die Zeilen stellen die einzelnen Datensätze (engl. record) dar. Den Inhalt einer Datenzelle bezeichnet man als Wert (engl. value).

Die untenstehende Tabelle stellt den Aufbau einer Adressdatenbank dar, mit der es möglich ist, den Namen, Vornamen, Straße, Ort und die Postleitzahl eines Freundes zu speichern.

Name Vorname Straße Wohnort PLZ
Mustermann Max Musterstraße 5 Musterhausen 12345
Beispiel Sam Beispielstraße 5 Beispielhausen 54321

 

Anforderungen an eine Datenbank

An eine Datenbank werden mehrere Bedingungen gestellt, um Daten sicher speichern und verwalten, die später leicht wieder ausgegeben werden können. Um die Daten sicher und dauerhaft speichern zu können, muss der Datenzugriff und die Datenintegrität gesteuert werden. Auch dienen Backup-Möglichkeiten dazu, Daten sicher zu speichern.

Da meist mehrere Benutzer auf die gleiche Datenbank zugreifen, muss das Datenbanksystem in der Lage sein, Konflikte, die durch den gleichzeitigen Zugriff auf die Datenbank entstehen, zu vermeiden.

Eine Datenbank muss zusätzlich die Integrität der Daten bewahren. Die Daten müssen widerspruchsfrei vorliegen. Speichert man in einer Datenbank beispielsweise Datumsangaben, darf das Datum 32.01.2003 nicht angenommen werden, das es ein solches Datum nicht gibt. Außerdem soll auf die Daten nur auf logischer, gedachten Ebene in Form einer Tabelle zugegriffen werden.

Außerdem sollten die Daten abgekapselt vorliegen und nicht von einem Programm/Dateisystem (physikalische Datenunabhängigkeit) abhängig sein.

Die 12 goldenen Regeln

E.F. Codd erarbeitete in der Zeit von 1970 bis 1985 das relationale Datenbankmodell. Hauptbestandteil dieses Modells ist ein relationales Datenbankmanagementsystem (RDBMS), das als Schnittstelle zwischen Anwender und den physikalisch vorliegenden Daten fungiert.

Er stellte dazu 12 Regeln auf, die eine relationale Datenbank zu erfüllen hat. Aber auch heute, mehr als 15 Jahre nach ihrer Veröffentlichung, wurden diese Regeln noch nicht komplett von allen Datenbanken, die sich relational nennen, umgesetzt. Die untenstehenden 12 Regeln stellen eine Zusammenfassung der Coddschen Regeln dar. Die komplette Zusammenstellung finden Sie unter 1.

Regel 1 – Informationsregel: Auf die Daten soll man ausschließlich auf logischer Ebene in Form von Relationen (Tabellen) zugreifen können, gleichwie die Daten physikalisch vorliegen. Zugriffe über Pointer o.ä. ist nicht erlaubt.

Regel 2 – Zugriffsgarantie: Jeder Wert muss durch eine logische Kombination aus dem Namen der Tabelle (Relation), Namen einer Spalte und einem Primärschlüssel erreichbar sein.

Regel 3 – Platzhalter: Ein relationales Datenbanksystem muss universelle Platzhalter bereithalten, damit auf logischer Ebene mit fehlenden Informationen gearbeitet werden kann. Man spricht dabei von dem Wert NULL, der nicht mit der numerischen 0 oder einem Leerstring zu verwechseln ist.

Regel 4 – Strukturänderung: Dem Benutzer muss es möglich sein, auf logischer Ebene auf die Struktur der Datenbank zuzugreifen, um vorhandene Relationen zu ändern oder neue zu erstellen. Diese Beschreibung der Datenbank nennt man auch Systemkatalog.

Regel 5 – Sprache: Das DBMS muss eine Programmiersprache zur Verfügung stellen, mit deren Hilfe, auf die Daten auf logischer Ebene zugegriffen wird. Dabei müssen folgende Bedingungen erfüllt werden:

  • Ihre einzelnen Statements müssen aus Zeichenketten mit einer wohldefinierten Syntax bestehen.
  • Die Sprache muß umfassend sein und Kommandos zur Daten- und Viewdefinition, zur Manipulation der Daten, zur Autorisierung des Zugriffs, zur Sicherung der Integrität und zum Verpacken in Pakete (Transaktionen 3) enthalten.

SQL hat sich hier als Quasistandard etabliert.

Regel 6 – Umgang mit Views: Das DBMS muss Möglichkeiten zur Verwaltung von Views bereitsstellen. Bei Views handelt es sich um eine Art virtuelle Tabelle. Damit lassen sich Datenbankabfragen ineinander schachteln bzw. die Ergebnisse temporär speichern.

Regel 7 – Operandenfähigkeit der Tabellen: Die Tabellen lassen sich wie ein Operand nutzen, d.h. ihre Daten lassen sich später flexibler bearbeiten. Dadurch ist es möglich mehr als nur einen Befehl (insbesondere SELECT, UPDATE und DELETE) auf einmal auszuführen.

Regel 8 – Physikalische Unabhängigkeit: Ein relationales DBMS darf nicht vom Anwenderprogramm abhängig sein. Das gilt für die Hardwareausstattung sowie für die Art der Speicherung der Daten. Es ist dadurch möglich, die Aufgaben des Servers (sprich dem DBMS) klar vom Client (dem Anwenderprogramm) zu trennen.

Regel 9 – Logische Unabhängigkeit: Es ist möglich, die Struktur einer Relation zu ändern, ohne dass das Anwendungsprogramm modifiziert werden muss. Gängige Praxis ist es beispielsweise eine Tabelle physikalisch auf zwei Orte zu verteilen, sie logisch aber als eine Tabelle auszugeben. Der umgekehrte Weg, zwei Tabellen zu einer Tabelle zusammenzuführen, ist ebenfalls möglich.

Regel 10 – Erhaltung der Integrität: Die Erhaltung der Integrität5 soll nicht die Aufgabe des Anwendungsprogramms, sondern des Datenbankmanagementsystems sein. Die Integritätsregeln sollen in der verwendeten Abfragesprache der Datenbank enthalten sein.

Regel 11 – Aufteilung der Daten: Die Ansprechung einer RDBMS bleibt bei gleicher Sprache logisch unbeeinflusst, wenn Daten aufgeteilt bzw. zusammengeführt werden.

Regel 12 – Sicherheit: Die mit einer hohen Sprache (meist mengenorientiert) festgelegten Integritätsregeln dürfen nicht durch eine Low-Level Sprache (meist satzorientiert) umgangen werden.

Anomalien in der Datenhaltung

Bei der Haltung der Daten kann es zu Problemen kommen, wenn die Daten modifiziert werden6. Dies geschieht beim Einfügen, Löschen und Ändern von Datensätzen und beim Hinzufügen neuer Tabellen. Man unterscheidet dabei drei Fehlertypen, die auf ein unglücklich gewähltes Datenbankdesign seitens des Programmierers zurückzuführen sind.

Insert-Anomalie

Bei dem obigen Beispiel einer Adressdatenbank ist es nicht möglich nur einen Namen und Vornamen einzugeben. Der Datensatz ist nur komplett, wenn zusätzlich auch Straße, Ort und Postleitzahl bekannt sind. Diesen Umstand bezeichnet man als Insert-Anomalie.

Update-Anomalie

Als Update-Anomalie bezeichnet man die fehlerhafte Aktualisierung redundant gehaltener Daten. Befindet sich ein Datensatz in verschiedenen Tabellen, müssen bei einem Update alle Vorkommnisse aktualisiert werden.

Delete-Anomalie

Bei der Delete-Anomalie handelt es sich im Prinzip um die gleiche Problematik, die auch schon bei der Insert-Anomalie auftrat. Speichert man Daten in einem Datensatz, die eigentlich nicht zusammengehören, können diese auch nur zusammen gelöscht werden.

Man sollte sich bei der Programmierung einer Anwendung, die auf eine Datenbank aufsetzt, schon im voraus die genaue Datenbankstruktur überlegen, um die Daten flexibel zu halten und den oben genannten Anomalien aus dem Weg zu gehen.

Beziehungen zwischen den Tabellen

Manchmal lassen sich die Anomalien nur vermeiden, indem man ein Problem auf mehrere Tabellen verteilt, auch wenn man dadurch manche Informationen redundant halten muss. Stehen die einzelnen Datensätze mit Datensätzen in anderen Tabellen in Beziehun, spricht man dabei von einer Verkettung. Die drei häufigsten Beziehungstypen sind 1:1, 1:N und N:M-Beziehungen.

Bei einer 1:1-Beziehung steht genau ein Datensatz einer Tabelle mit einem Datensatz einer anderen Tabelle in Beziehung:

Bei einer 1:N-Beziehung kann ein Datensatz aus einer Tabelle mit mehreren Datensätzen einer anderen Tabelle in Beziehung stehen. Die Beziehungen dürfen sich hierbei nicht überschneiden.

Bei einer M:N-Beziehung handelt es sich im Prinzip um eine 1:N-Beziehung, bei der sich die Verknüpfungen überschneiden dürfen. Die Verknüpfung lässt sich dabei nicht mehr über einen Primärschlüssel realisieren. Man bedient sich einer zusätzlichen Tabelle, die die Informationen enthält, um die Daten zu verbinden. Man sieht, dass die Anfälligkeit gegenüber Fehlern mit der Komplexität der Verknüpfungen zwischen den Tabellen steigt. Das Löschen und Hinzufügen von Datensätzen kann unter Umständen nicht mit einem Schlag erledigt werden – dies kann unvollständige Datensätze zur Folge haben und zu den oben genannten Anomalien führen. Dies soll nur eine kurze Einführung sein. Nur über den Aufbau und die Prinzipien einer Datenbank könnte man ganze Bücher füllen. Weitere Informationen zu diesem Thema findest du mithilfe der Suchmaschine Google.