Relationale Datenbanksystemen

Das relationale Datenbankmodell ist heutzutage das verbreitetste Modell in der Datenbankentwicklung. Im Mittelpunkt steht hier die namensgebende Relation, die mathematisch gesehen nichts anderes als eine Beschreibung für eine Tabelle ist. Durch die relationale Algebra können Operationen auf diese Relation durchgeführt werden. Erstmals vorgeschlagen wurde es im Jahr 1970 vom britischen Mathematiker und Datenbanktheoretiker Edgar F. Codd. Und auch wenn es einige Kritikpunkte beinhaltet, ist es dennoch bis heute der etablierte Standard für Datenbanken.

Grundlagen

Eine relationale Datenbank besteht aus einer oder mehreren Tabellen (Relationen), in denen Daten abgespeichert werden können. Und zwar in der Form, dass jede Zeile (Tupel) einen eigenen Datensatz (Record) darstellt. Die Spalten jeder Zeilen sind Attribute, also Eigenschaften der abgespeicherten Daten. Eine Domäne/Domain ist dabei der Wertebereich, den die Attribute annehmen könne. Durch ein Relationenschema lassen sich sowohl die Anzahl als auch die Typen der Attributen einer Relation festlegen.

Beispiel:

Ein Datensatz muss eindeutig identifizierbar sein. Dies wird mittels eines oder mehreren Schlüssel (engl. Keys) sichergestellt. Über den Schlüssel soll aber nicht nur die Identifizierung des Datensatzs sichergestellt werden, eine weitere Anforderung ist, dass der Schlüssel auch minimal ist. Im oberen Beispiel ist der Schlüssel Mitarbeiter-Nr, da diese Nr. immer nur genau einmal pro Mitarbeiter vergeben wird. Andere Attribute in der Tabelle tauchen häufiger auf, so ist weder der Vorname einzigartig (es gibt zwei mal Max), noch der Nachname und selbst wenn in diesem Fall die Kombination von Vorname und Nachname ein Schlüssel sein könnte, wäre dies in der Praxis nicht zu empfehlen, da es durchaus zwei Personen im Unternehmen mit dem komplett gleichen Namen (Vorname und Nachname) geben könnte.

Nun könnte man die obere Tabelle durch eine weitere Tabelle ergänzen:

In diesem Fall wäre der Schlüssel die Abteilungsbezeichnung, da diese immer nur einmal vergeben wird. In der Praxis wäre auch hier eine Abteilungsnummer besser. Möchte man nun wissen, wo beispielsweise Max Müller sitzt, dann müssten die beiden Tabellen verbunden werden (über einen sogenannten Join). Bei einem Join werden aus zwei oder mehreren Tabellen eine virtuelle Tabelle mit allen Spalten aus den verbundenen Tabellen. Dies geht nun ganz einfach über die Schlüssel (wobei das Attribut Abteilung in der Tabelle Mitarbeiter der sogenannte Fremdschlüssel wäre und in der Tabelle Abteilung der sogenannte Primärschlüssel), sodass man mit einer Abfrage sieht, dass Max Müller in Gebäude 1 sitzt. Natürlich hätte man diese Informationen auch in der Mitarbeiter-Tabelle speichern können, da der Sitz aber von der Abteilung abhängig ist, hätte man viele doppelte, redundante Einträge. Dieser zusätzliche Speicheraufwand ist aber nur eine Seite der Medaille. Falls sich nämlich nun der Sitz der Abteilung ändert, müsste man im Falle von einer Tabelle alle Einträge auf einmal ändern. Im oberen Fall mit zwei Tabellen reicht eine einzige Änderung in der Abteilungstabelle. Auch beim Löschen oder Einfügen können bei einem falschen Tabellenentwurf sogenannte Anomalien auftauchen. Generell versucht man deshalb aus einer großen Tabelle mehrere kleinere Tabellen machen. Diese Zerlegung muss aber wohlüberlegt sein, da man im schlechtesten Fall solch eine Zerlegung einer Relation in mehrere Relationen zu einem Informationsverlust führt. Deshalb sollte man zu einem systematischen Vorgehen greifen, dass mit der sogenannten Normalisierung existiert.

Nachteile bzw. Kritik an dem relationalen Datenmodell

Obwohl das relationale Datenmodell heutzutage präferiert wird, gibt es dennoch einige Nachteile des Konzepts, die immer wieder für Kritik sorgen. Darunter fällt beispielsweise:

• Künstliche Schlüsselattribute: Wie man schon im oberen Beispiel sieht, kommt es häufig vor, dass man künstliche Schlüsselattribute in die Relationen aufnimmt, die man eigentlich sonst nicht brauchen würde. Beispielsweise könnte man um die Größe des Schlüssels der Abteilungstabelle statt der Abteilungsbezeichnung ein zusätzliches Feld "Abteilungs-Nr." einfügen. Die Nummer wäre deutlich kürzer als der komplette Name, wird aber sonst eigentlich nicht gebraucht, es handelt sich lediglich um Verwalduntgsinformationen.
• Fehlende Homogenität zu Programmiersprachen: Entwickler können hiervon ein Lied singen. Generell sind Programmiersprachen und Datenbanken unterschiedliche Welten. Von der Syntax über die Datentypen usw. In der Regel ist es aber erforderlich, dass beide Welten ohne Probleme ineinander greifen. Dafür benötigt man wiederum oft externe Programmierschnittstellen, die wiederum einige Beschränkungen mit sich bringen können
• ...