Datenbanktheorie - Relationales Datenbankmodell (RDM/RDMS)

Das relationale Modell wurde bei IBM Research durch Ted Codd entwickelt und erstmals 1970 veröffentlicht. ([3]1)
Auf Datenbankmodelle, wie das Netzwerkmodell und hierarchische Systeme soll hier nicht näher eingegangen werden.
Im folgenden werden nun wichtige Grundlagen zum Relationalen Datenbankmodell in geraffter Form dargestellt.

Grundbegriffe des relationalen Modells

Relation: Bezeichnet eine einzelne Tabelle der Datenbank

Attribut: Spalte einer Tabelle

Tupel: Ein Rekord (Datensatz) einer Relation (ugs.: eine Zeile einer Tabelle)

Degree: Gibt die Zahl der Attribute einer Relation an

Domäne: Gibt den Wertebereich eines Attributs an.
Dabei sind die Domänen tabellenübergreifend und können in verschiedenen Tabellen verwendet werden, beispielsweise in Schlüsselattributen.

Kardinalität: Bezeichnet die Anzahl der Tupel einer Relation

NULL-Wert

NULL ist ein Zustandsindikator, welcher angibt, dass ein bestimmter Wert nicht gesetzt wurde und somit nicht vorhanden ist.

„In SQL, NULL is not a value. It is a state indicating that an item's value is unknown or nonexistent.“[4]

Außerdem ist zu beachten, dass dieser Zustand durch keinen Wert repräsentiert werden kann, so gilt grundsätzlich:

NULL ≠ 0 und NULL ≠ [Leere Zeichenkette] und NULL ≠ NULL

Somit wird deutlich, dass ein auf „leer“ gesetztes Feld (aus menschlicher Sicht), beispielsweise durch Zuweisung eines Strings der Länge 0 nicht NULL enthält, da das Feld ja gesetzt wurde, sondern stattdessen einen leeren String zurück liefert.

Nullwerte können also wie folgt interpretiert werden (nach [2]):

Relationen

Relationen bilden das zentrale Element einer jeden Datenbank, daher sollen einzelne Fakten dazu nun nochmals ausführlicher erläutert werden.
Eine Relation besteht aus einer vergleichsweise statischen Anzahl von Attributen. Dagegen kann die Zahl der Tupel je nachdem, ob Datensätze gelöscht oder eingefügt werden steigen bzw. fallen, wodurch sich die Kardinalität der Relation entsprechend ändert, die Degree-Angabe jedoch unverändert bleibt.
In einem relationalen Modell müssen außerdem bestimmte Bedingungen erfüllt sein. So darf innerhalb einer Relation kein Tupel identisch zu einem anderen der selben Relation sein. Außerdem ist die Reihenfolge sowohl der Tupel als auch der Attribute in einer Relation nicht festgelegt und kann somit nicht als Grundlage zur verlässlichen Ansprache einer bestimmten Zelle dienen.

Alle Attribute unterliegen einer Domäne. Im einfachsten Falle ist dies der Feldtyp, welcher für das entsprechende Attribut definiert wird. Ein recht häufig verwendeter Feldtyp ist VARCHAR, welcher die Speicherung von Zeichenketten ermöglicht. Außerdem seien folgende Domänen genannt, welche ebenfalls zum Einsatz kommen: INTEGER (Speicherung von Ganzzahlen), BLOB (Binary Large Objekt; - Speicherung von beliebigen Binärinformationen bzw. Text ohne Längenbegrenzung [mit Ausnahme der physikalisch gegebenen]), TIMESTAMP (Speicherung von Datum und Zeit) und DECIMAL (Speicherung von Dezimalzahlen). Je nach Datenbanksystem stehen weitere/andere Feldtypen zur Verfügung.
Einschränkungen dieses Wertebereichs sind natürlich denkbar. So können Gültigkeitseinschränkungen für einzelne Attribute vergeben werden.

Ferner sind Domänen als atomar aufzufassen. Dies bedeutet, dass die Werte innerhalb einer Domäne nicht mehr sinnvoll in weitere Domänen zerlegt werden können. Da jedes Attribut auf einer Domäne basiert, folgt daraus direkt, dass auch Attribute atomar sein müssen.

Schlüssel

Unique/Candidate-Key

Sobald alle Werte eines Attributs/einer Attributmenge eindeutig (unique) sind, werden diese als Candidate-Key bezeichnet. Ein Candidate-Key kann aus mehreren Attributen zusammengesetzt sein, um seine Eindeutigkeit zu erlangen. Allerdings darf er nicht mehr Attribute enthalten, als für diese Eindeutigkeit unbedingt nötig. So verliert ein zusammengesetzter Candidate- Key nach Entfernen eines Attributs sofort seine Gültigkeit, da dann die Eindeutigkeit nicht mehr gewährleistet sein darf. [1]/[2]

Aus dem Grundsatz, dass innerhalb einer Relation keine gleichen Tupel vorkommen dürfen, folgt direkt, dass jede Relation mindestens einen Candidate-Key besitzen muss, nämlich die Verbindung aus allen Attributen. Allerdings muss dies nicht zwangsläufig ein [genutzter] Candidate-Key sein, was in den meisten Fällen zutreffen wird.

Eine Sonderstellung bildet der so genannte Superschlüssel, welcher alle Attribute enthalten kann, auch wenn diese Redundanz enthalten, so dass die Eindeutigkeitseinschränkung auch nach Entfernen einzelner Attribute nicht verletzt wird. Durch solch einen Superschlüssel wird gleichzeitig festgelegt, dass keine zwei Tupel einer Relation innerhalb eines Relationszustands identisch sein dürfen. [2]

Zusammenfassend kann gesagt werden, dass der jeweilige Schlüssel eindeutig ein Tupel der Relation kennzeichnen muss.

Primärschlüssel

Ein Primärschlüssel (Primary-Key) dient zum gezielten Zugriff auf die Tupel einer Relation. Dabei besitzt jede Relation genau einen Primärschlüssel. Jedes Tupel einer Relation muss über diesen Primärschlüssel eindeutig identifiziert werden können, was nach sich zieht, dass der Primärschlüssel gleichzeitig die Bedingungen eines Candidate-Keys erfüllen muss.

Fremdschlüssel

Fremdschlüssel (Foreign-Keys) dienen dazu, unterschiedliche Relationen miteinander logisch zu verknüpfen. Ein Attribut bzw. eine Attributmenge, welche als Fremdschlüssel deklariert wird, besitzt die selbe Domäne, wie der Primärschlüssel einer anderen Relation. Über die Beziehung von Fremd- und Primärschlüssel ist es so möglich, mittels JOIN eine Ergebnisrelation aus den beiden zugrunde liegenden Relationen zu erhalten.

Referenzielle Integrität

Die entsprechenden Bedingungen der referenziellen Integrität werden jeweils zwischen zwei Relationen definiert und stellen sicher, dass die Integrität zwischen den Tupeln der beteiligten Relationen erhalten bleibt.
Gemäß der Einschränkung der Entityintegrität dürfen Primärschlüssel nicht NULL enthalten, da sie so keine eindeutige Identifizierung der einzelnen Tupel gewährleisten würden. Fremdschlüssel dürfen ebenfalls nicht den Status NULL besitzen, da sie sich stets auf einen Primärschlüssel beziehen und die selbe Domäne wie dieser aufweisen.

Ein Fremschlüssel (FK) zwischen zwei Relationen (R1; R2) muss folgende Gültigkeitsbedingungen erfüllen (nach [2]):

  1. Die Attribute von FK in R1 haben die selbe Domäne, wie der Primärschlüssel von R2
  2. Ein Wert von FK in R1 kommt im aktuellen Zustand entweder als Primärschlüssel-Wert eines Tupels in R2 vor, oder ist NULL

Diese beiden Regeln stellen sicher, dass in einer relationalen Datenbank zu keiner Zeit die Integritätsbedingungen verletzt werden, da die Datenbank sonst nicht den Anforderungen an eine relationale Datenbank entsprechen würde.
Die Einhaltung dieser Integritätsbedingungen ist dabei einzig und allein die Aufgabe des DBMS und nicht Sache des Klienten.
Dabei muss das DBMS entsprechende Anfragen an die Datenbank, welche die Tupelmenge einer Relation verändern können (Insert, Update und Delete), prüfen und sollten sie gegen die Integritätsbedingungen verstoßen, zurückweisen.

1 siehe http://www.acm.org/classics/nov95/