Das relationale Datenbankmodell

Bisher liegen die Daten unserer Miniwelt in einem abstrakten Modell vor, das die Realität durch Entitytypen und ihre Beziehungen zueinander widerspiegelt. Das ER-Modell ist - wie wir gesehen haben - in der Phase des konzeptionellen Entwurfs einer Datenbank hervorragend geeignet, ein Datenbanksystem ohne Abhängigkeit von der späteren Implementierung zu gestalten. Im Anschluss an den konzeptionellen Entwurf folgt beim Datenbankdesign der logische Entwurf. Hierbei wird ein spezielles Datenbankmodell ausgewählt und das Ergebnis des konzeptionellen Entwurfs auf dieses Datenbankmodell abgebildet. Meist ist noch eine Optimierung anhand unterschiedlicher Qualitätskriterien erforderlich.

Die klassischen DBMS-Systeme, die als Software auf Computern zur Verfügung stehen, beruhen alle auf Datenbankmodellen, deren Gestaltungsmöglichkeiten gegenüber dem ER-Modell eingeschränkt sind. Man unterscheidet zwischen dem hierarchischen, dem Netzwerk-, dem relationalen und dem objektorientierten Modell. Das mit Abstand wichtigste ist das relationale Modell, deshalb soll es hier als einziges vorgestellt werden. Es geht zurück auf Arbeiten von E. F. Codd Anfang der 70er Jahre. Auch MySQL verwendet dieses Datenmodell (ebenso wie Access, dBase, Paradox, Oracle usw.). Das relationale Modell beruht auf mathematischen Grundlagen, die allerdings einfach sind und Begriffe der Mathematik verwenden.

Konzepte des relationalen Datenbankmodells

Relation / kartesisches Produkt

Das relationale Datenbankmodell basiert auf dem mathematischen Begriff der Relation. Eine Relation R ist eine Teilmenge des kartesischen Produkts einer Liste von Wertbereichen W₁, W₂, ...,W_n:

R ⊆ W₁ x W₂ x ... x W_n

n-Tupel

Elemente einer Relation R sind die n-Tupel der Art (v₁,v₂,...,v_n) mit v_i ∈ W_i. Die Größe n bezeichnet man als Grad der Relation R.
Im Beispiel einer Oberstufenverwaltung kommen Kurse als Entities vor. Kurse werden durch die drei Attribute Kurs-Nr, Thema und Jahrgangsstufe beschrieben. Die Kursnummer ist eine natürliche Zahl und das Thema eine Zeichenkette (String). Die Wertemengen sind demnach:

W₁ = N
W₂ = {x | x ist String}
W₃ = {11/I, 11/II, 12/I, 12/II, 13/I, 13/II}

Exemplarisch sind hier vier Kurse K₁ bis K₄ in Form von Tripeln (3 Tupel) angegeben:

K₁ = (13, Analysis 3, 13/II)
K₂ = (2, Short Stories, 12/I)
K₃ = (38, Datenbanken, 12/II)
K₄ = (19, Antihelden, 11/II)

Sie bilden die vierelementige Relation

KURS = {(13, Analysis 3, 13/II), (2, Short Stories, 12/I), (38, Datenbanken, 12/II), (19, Antihelden, 11/II)}

Tabellenschreibweise

Die Mengenschreibweise ist unübersichtlich. Daher ist die dazu äquivalente Tabellenschreibweise besser geeignet und üblich:

KURS

In der ersten Zeile der Tabelle werden die jeweiligen Attribute als Spaltenköpfe notiert. Sie gehören somit nicht zur Relation. Vielmehr beschreiben sie das Relationenschema, also den hier beschriebenen Entitytyp. Jede weitere Zeile der Tabelle beschreibt ein Tupel der Relation, entspricht also einem Entity. Der allgemeine Aufbau einer Tabelle im Relationenmodell ist demnach gegeben durch:

Den neu eingeführten Begriffen stellen wir in folgender Tabelle eine erläuternde Beschreibung und eine Übersetzung in das ER-Modell gegenüber.

Vergleich relationales/ER-Modell

Der Übersetzungstabelle vom relationalen Modell in das ER-Modell entnehmen wir, dass das Relationenschema dem Entitytyp des ER-Modells entspricht. Um über Relationenschemata sprechen zu können, benutzt man die Schreibweise:

Allgemein: R(A1, A2, ..., A3)
Beispiel: Kurs(Kurs-Nr, Thema, Jahrgangsstufe)

Schlüsselattribute zeichnet man durch Unterstreichung aus.

Relation als Tabelle

Bei der Darstellung einer Relation als Tabelle muss man immer beachten, dass die Tabelle lediglich eine übersichtliche Darstellung einer Menge ist. Dies bedeutet unter anderem, dass in einer Relationentabelle nie zwei gleiche Zeilen vorkommen dürfen und die Reihenfolge der Zeilen keine Bedeutung hat.

» drucken: pdf | html