1 Relationale Datenbanken (DB): Das Relationenmodell

1 Relationale Datenbanken (DB): Das Relationenmodell
[eine Zusammenfassung von Christian Rausch nach Schicker: „Datenbanken und SQL“, 1999]
Vereinfacht ausgedrückt bestehen relationale Datenbanken aus Tabellen, in denen Daten
gespeichert sind. Üblicherweise stehen die Tabellen in Beziehungen zueinander, d. h. manche
Einträge sind Verweise auf andere Einträge in anderen Tabellen.
Wichtige Anforderungen an eine Datenbank:
geringe Redundanz, gleiche Daten sind möglichst nicht an mehreren
Stellen gleichzeitig abgelegt. Dadurch bleibt die DB
übersichtlicher, Updates der Daten werden
gute Handhabbarkeit,
einfache Zugriffe über möglichst wenige
Tabellen
erleichtert, Speicherplatz wird gespart.
Daten sind übersichtlich abgelegt, Abfragen sind
einfach.
Sicherstellung von Konsistenz und Integrität Datenbeziehungen bleiben in sich logisch und
stimmig. Keine Gefahr von Datenverlust z. B. bei
Updates oder Löschungen.
1.1 Beispiel zu relationalen Datenbanken
Negativbeispiel: Datenbanktabelle VerkaeferProdukt (Tab. 1):
Tab. 1 VerkaeferProdukt
Verk_Nr Verk_Name PLZ Verk_Adresse Produktname Umsatz
V1 Meier 80075 München Waschmaschine 11000
V1 Meier 80075 München Herd 5000
V1 Meier 80075 München Kühlschrank 1000
V2 Schneider 70038 Stuttgart Herd 4000
V2 Schneider 70038 Stuttgart Kühlschrank 3000
V3 Müller 10183 Berlin Staubsauger 1000
Zu jedem Verkäufer ist
dessen Nummer und Name (Verk_Nr und Verk_Name),
PLZ und Stadt seiner Adresse (PLZ und Verk_Adresse),
der Name der von ihm verkauften Produkte (Produktname)
und der Umsatz angegeben.
Nachteile obiger Tabelle:
Redundanzen: Name, PLZ und die Adresse der Verkäufer kommen mehrfach vor.
Unbequeme Handhabbarkeit: ändert ein beliebiger Verkäufer seine Adresse, so ist eine variable
Anzahl von Adresseinträgen zu ändern. Falls nicht alle Adresseinträge geändert werden, so
besteht die Gefahr von Inkonsistenzen.
Redundanz ist immer eine Gefahrenquelle für Fehler und Inkonsistenzen.
Falls die Firma den Artikel Staubsauger aus dem Programm nimmt, so können nicht einfach die
1/13

Zeilen, die den Produktnamen Staubsauger enthalten, entfernt werden, da sonst auch alle
Informationen zu Verkäufer Müller aus der Datenbank entfernt werden!
E. F. Codd untersuchte ab 1970 den optimalen Aufbau von Tabellen und legte die Grundlage zu
mathematisch-fundierten Theorien (relationale Algebra, Relationenkalül, Normalformenlehre).
Es wurde theoretisch belegt, dass Tabellen so aufgebaut werden können, dass sowohl Redundanzen
in den Daten vermieden als auch Einzeldaten isoliert gelöscht werden können.
1.2 Relationale Datenstrukturen
Übersicht
Entsprechung der formalen relationalen Ausdrücke mit
mehr informellen alltäglichen Ausdrücken:
Tab. 2
Formale relationale Ausdrücke Informelle Ausdrucksweise
Relation Tabelle
Tupel eine Zeile (Reihe) einer Tabelle
Kardinalität Anzahl der Zeilen einer Tabelle
Attribut eine Spalte (Feld) einer Tabelle
Grad Anzahl der Spalten einer Tabelle
Primärschlüssel eindeutiger Bezeichner einer Zeile (eines Tupels)
Gebiet Menge aller möglichen Werte
L# Lname Stadt PLZ Kopf(zeile)
L1 Müller München 81724
Relation L2 Schmidt Regensburg 93055 Rumpf
L3 Maier Hamburg 20543 Tupel
L4 Schwarz Köln 50087
L5 Weiß Berlin 11168
Attribute
Grad
Abb. 1 Relationale Begriffe am Beispiel: L1-L5 Primärschlüssel; die Kardinalität ist die Zeilenzahl
(=Tupelzahl)
Der Kopf besteht aus einer festen Anzahl von Attributen:
{(A1; D1), (A2; D2), ... , (An; Dn)}, wobei jedes Attribut Ai genau mit einem Gebiet korrespondiert
(1 i n)
Der Rumpf besteht aus einer variablen Anzahl von Tupeln.
2/13

Der Grad einer Relation R (d. h. die Spaltenzahl = Attributszahl) wird beim Erzeugen der Relation
festgelegt (beim Hinzufügen einer Spalte (Attribut) handelt es sich genaugenommen um die
Überführung der Relation in eine andere). Die Kardinalität ist beim Erzeugen der Relation gleich
Null und erhöht sich mit jedem Einfügen eines neuen Tupels.
Definition (Relation)
Eine Relation ist eine Tabelle obiger Gestalt, bestehend aus einem Kopf und einem Rumpf, mit
folgenden 4 Eigenschaften:
Es gibt keine doppelten Tupel.
Tupel sind nicht geordnet (etwa von oben nach unten).
Attribute sind nicht geordnet (etwa von links nach rechts).
Alle Attribute sind atomar, d. h. jedes Attribut („Tabellenelement“) enthält nur ein Element.
(Handhabung wird vereinfacht, Speicherbedarf kann besser geplant werden.)
Definition (Relationale Datenbank)
= eine Ansammlung von normalisierten Relationen,
die zeitlich variieren (können).
die einen (geeigneten) Grad haben.
die Relationen stehen zueinander in einer bestimmten Beziehung und
werden von einem Verwaltungssystem gemeinsam verwaltet.
Eine Datenbank, die ausschließlich mit SQL Befehlen verwaltet und auf die ausschließlich mit
SQL Befehlen zugegriffen wird, ist bereits eine relationale Datenbank, da SQL nur Relationen
kennt.
Unterscheidung
„eigentliche“ Relationen von „eigentl.“ Relationen abgeleitete Relationen
Basisrelationen (am wichtigsten, da „eigentliche“ Relation)
existieren tatsächlich (real) in der DB, haben Namen und sind dauerhaft gespeichert.
Sichten (Views)
virtuell und nicht real
erscheinen dem Benutzer wie „normale“ Relationen
aus Basisrelationen abgeleitet
geeignet, um Benutzer mit eingeschränkten Rechten z.B. nur „Teilsicht“ auf eine best.
Relation zu gewähren.
Abfrageergebnisse (Query-Results)
sind auch Relationen
existieren nur temporär als Abfrageergebnisse auf Bildschirm oder Drucker
Temporäre Relationen
existieren wie Abfrageergebnisse nur temporär
werden aber erst durch best. Aktionen z.B. Beenden einer Transaktion zerstört
dienen v.a. zum Abspeichern von Zwischenergebnissen.
3/13

In SQL:
CREATE TABLE ...; Erzeugen einer Basisrelation
CREATE VIEW ...; Erzeugen einer Sicht
SELECT ...; Abfrage
CREATE TEMPORARY TABLE ...; Erzeugen einer temporären Relation
Definition (Primärschlüssel)
der Primärschlüssel ist ein besonderes Attribut, durch das jeder Tupel eindeutig beschrieben wird.
Primärschlüssel kann aus mehreren Einzelattributen zusammengesetzt sein.
Wegen der Def. der Relation (einmaliges Auftauchen eines Tupels) besitzt jede Relation einen
Primärschlüssel. Im ungünstigsten Fall erstreckt sich dieser über mehrere oder sogar alle Attribute!
Bsp. Primärschlüssel Tab. 3
Tab. 3 Relation Lagerbestand mit zusammengesetztem Primärschlüssel
Produktname Produkttyp Bestand Preis
Staubsauger T06 25 498
Staubsauger T17 17 219
... ... ... ...
Herd T04 10 1598
Herd T06 7 1998
1.3 Relationale Integritätsregeln
Physische Integrität
Vollständigkeit der Zugriffspfade und der physischen Speicherstrukturen
Vom Datenbankprogrammierer nicht beeinflussbar.
Ablaufintegrität
Korrektheit der ablaufenden Programme
Keine Dateninkonsistenz im Mehrfachbenutzerbetrieb
Verantwortung: Anwendungsprogrammierer und Datenbankdesigner
Zugriffsberechtigung
korrekte Vergabe der Zugriffsberechtigung
Verantwortung: Datenbank-Administrator
Semantische Integrität
Übereinstimmung der Daten in der DB mit denen in der realen Welt
Gefahr: z.B. aus Versehen könnten falsche Werte z.B. Mengenangaben eingegeben
werden
Abhilfe: Eingabe muss auf Korrektheit überprüft werden.
Empfehlung: die Gebiete sind so klein wie möglich zu wählen.
Verantwortung: Anwendungsprogrammierer, Datenbank-Administrator, DB-Hersteller
4/13

1.3.1 Entitäts-Integritätsregel = 1. Integritäsregel
Jeder Primärschlüssel identifiziert jedes Tupel eindeutig jedes Tupel hat einen Primärschlüssel.
1. Integritätsregel (Entitäts-Integritätsregel)
Keine Komponente des Primärschlüssels einer Basisrelation darf nichts enthalten.
Definition (Schlüsselkandidat)
Ein eventuell aus mehreren einzelnen Attributen zusammengesetztes Attribut heißt
Schlüsselkandidat, falls es
eindeutig jedes Tupel identifiziert und
minimal ist, d.h. bei Weglassen eines einzelnen Attributs die Eindeutigkeit verloren geht.
Definition (Primärschlüssel, alternativer Schlüssel)
Besitzt eine Relation mehrere Schlüsselkandidaten, so wird davon einer als Primärschlüssel
ausgewählt; alle anderen heißen alternative Schlüssel. Der Primärschlüssel soll minimal sein.
Teilattribute des alternativen Schlüssels dürfen leer sein.
Bsp. für Auftreten von Primärschlüssel und alternativen Schlüsseln in Tab. 4:
Tab. 4 Tabelle der chemischen Elemente
Protonen Atomgewicht Name Symbol
1 1,0079 Wasserstoff H
2 4,0026 Helium He
3 6,9410 Lithium Li
... ... ... ...
NB: Protonenzahl, Namen und Symbol des Elements sind Schlüsselkandidaten.
1.3.2 Referenz-Integritätsregel
Diese regelt Verweise der Relationen untereinander. Allgemein gesprochen sind Relationen
einzelne Objekte ohne zwingenden Bezug. Üblicherweise gibt es aber einen Bezug, da in
Datenbanken „zusammengehörige“ Dinge verwaltet werden. Der Bezug zwischen zwei Relationen
wird durch einen weiteren Schlüssel, den sog. Fremdschlüssel hergestellt. Fremdschlüssel sind der
„Kitt“, der die einzelnen Relationen zu einem gemeinsamen Datenbestand zusammenfügt.
Definition (Fremdschlüssel)
Ein (möglicherweise zusammengesetztes) Attribut einer Basisrelation heißt Fremdschlüssel, falls
das ganze Attribut entweder nichts oder einen definierten Inhalt enthält,
eine Basisrelation mit einem Primärschlüssel existiert, so dass jeder definierte Wert des
Fremdschlüssels zum Wert jenes Primärschlüssels identisch ist.
Beispiel für die Relationen Personal, Kunde und Auftrag (Tab. 5) (nächste Seite)
5/13

Tab. 5 Beispiel für die Relationen Personal, Kunde und Auftrag
6/13

2. Integritätsregel (Referenz-Integritätsregel)
Eine relationale Datenbank enthält keinen Fremdschlüssel (ungleich NULL), der auf einen nichtexistenten
Primärschlüssel verweist.
Problem: Falls ein Tupel mit Primärschlüssel gelöscht werden soll, auf den Fremdschlüssel
verweisen, so kann dieses nicht einfach gelöscht werden, da sonst der Fremdschlüssel ins Leere
verweist wodurch die 2. Integritätsregel verletzt wäre.
Lösungsmöglichkeiten:
Löschen bzw. Ändern nicht durchführen
ON DELETE NO ACTION bzw. ON UPDATE NO ACTION
Löschen bzw. Ändern rekursiv aller darauf verweisender Tupel
ON DELETE CASCADE bzw. ON UPDTATE CASCADE
Nullsetzen aller darauf verweisender Fremdschlüssel
ON DELETE SET NULL bzw. ON UPDTATE SET NULL
1.4 Relationale Algebra
E. F. Codd definierte eine vollständige Syntax auf 8 Operatoren und schuf eine relationale Algebra.
Er zeigte, dass damit alle denkbaren Zugriffe auf beliebige Relationen der Datenbank möglich sind.
1.4.1 Relationale Operatoren
Eine Relation R ist eine Menge (R ist Menge aller Relationen)
Es gibt 8 Mengenoperatoren auf R x R (binäre Operatoren) und R (unäre Operatoren).
Das Bildgebiet ist wieder eine Menge (Relation).
Binäre Operatoren sind z.B. Addition und Multiplikation
Unäre Operatoren sind z.B. das negative Vorzeichen.
Vereinigung R1 UNION R2
Alle Tupel, die wenigstens in einer der beiden Relationen vorkommen
Schnitt R1 INTERSECT R2
Enhält nur die in beiden Relationen vorkommenden Tupel.
Differenz R1 MINUS R2
Bezüglich der Tupel: R1 ohne R2 i.e. R1 \ R2
Kartesisches Produkt R1 TIMES R2
alle möglichen Kombinationen der Tupel aus R1 und R2
Restriktion R WHERE Bedingung
die sich ergebende Relation ist eine Teilmenge von R entsprechend der Bedingung
Projektion R [Attributsauswahl]
alle Tupel, aber nur mit einer Auswahl von Attributen werden angezeigt.
7/13

(Natürliche) Verbindung R1 JOIN R2
alle mögl. Kombinationen der Tupel aus R1 u. R2.
„gemeinsame Attribute dienen als Verknüpfung“, Verknüpfung bei gemeinsamen Attributen ist
über Fremdschlüssel -> Primärschlüssel gegeben.
Division R1 DEVIDEBY R2
R1 muss mindestens alle Att. von R2 enthalten (R2 ist Teilmenge von R1).
Die neue Relation
enthält nur die Attribute, die R1 zusätzlich zu R2 hat
enthält nur die Tupel von R2 deren Attribute Att mit denen von R1 übereinstimmen.
nur die „neuen“ Attribute werden gewählt (d.h. nur in R1 enthalten)
nur die Tupel werden gewählt, wo für die Attribute gilt, die in R1 und R2 vorhanden sind:
„die Attribute stimmen in ihren Werten überein“
Graphische Verdeutlichung (Abb. 2):
Abb 2.1: Natürliche Verbindung (JOIN) der Relationen Personal und Auftrag
Abb 2.2: Graphische Verdeutlichung der 8 relationalen Operatoren
8/13

2 Datenbankdesign
2.1 Normalformenlehre
Die Normalformenlehre betrachtet immer Relationen für sich.
Das Entity-Relationship-Modell ist ein Gesamt-Design mit allen Beziehungen zwischen den
Relationen.
Die Normalformenlehre beschreibt, wie Relationen aufgebaut werden sollen, um Redundanzen zu
vermeiden. Codd stellte 1970 3 Normalformen auf, heute gibt es insg. 5 Normalformen.
Die 1. - 3. finden am meisten Anwendung.
Die Normalformen bauen aufeinander auf, d.h. befindet sich eine Datenbank in der m.ten
Normalform, so befindet sie sich auch in der n.ten (m n).
Definition (erste Normalform)
Eine Relation ist in der ersten Normalform, wenn alle zugrundeliegenden Gebiede nur atomatre
Werte anthalten.
Definition (funktionale Abhähngigkeit)
Ein Attrbut Y einer Relation R heiß funktional abhängig vom Attirbut X derselben Relation, wenn
zu jedem X-Wert höchsten ein Y-Wert möglich ist.
Ist Y von X funktional abhängig so schreiben wir:
X->Y
Definition (volle funktionale Abhängigkeit)
Ein Attribut Y einer Relation R heißt voll funktional abhängig vom Attribut X derselben Relation,
wenn es funktional abhängig von X ist, nicht aber funktional abhängig von beliebigen Teilattributen
von X.
Ist Y von X voll funktional abhängig so schreiben wir:
X=>Y
Definition (zweite Normalform)
Eine Relation ist in der zweiten Normalform, wenn sie in der ersten Normalform ist, und jedes
Nichtschlüsselattribut voll funktional abhängig vom Primärschlüssel ist.
(Ein Nichtschlüsselattribut ist jedes (auch zusammengesetzte) Attribut, das kein Schlüsselkandidat
ist.)
Bemerkung:
Eine normalisierte Relation mit einem nicht zusammengesetzten Primärschlüssel befindet sich
immer in der zweiten Normalform. Umgekehrt besitzt eine Relation, die sich nicht in der zweiten
Normalform befindet, einen zusammengesetzten Primärschlüssel.
Definition (Determinante)
Eine Determinante ist ein (eventuell zusammengesetztes) Attribut, von dem ein anderes voll
funktional abhängig ist.
Diese Definition besagt nur, dass jedes Attribut, von dem ein Doppelpfeil ausgeht, als Determinante
bezeichnet wird. In der zweiten Normalform sind also mindestens alle Schlüsselkandidaten
Determinanten. Die dritte Normalform geht noch einen Schritt weiter:
9/13

Definition (dritte Normalform nach Boyce/Codd)
Eine normalisieret Relation ist in der dritten Normalform, wenn jede Determinante dieser Relation
ein Schlüsselkandidat ist.
Bemerkung
Jede beliebige Relation kann durch Umformung (meist Zerlegung in mehrere Relaitonen) in die
zweite und auch in die dritte Normalform überführt werden.
Vierte und fünfte Normalform (Ausblick)
Primärschlüssel und alternative Schlüssel sind möglichst so zu wählen, dass sie nur aus ein oder
höchstens zwei Attributen bestehen. Dies sind Aussage und Inhalt der vierten und fünften
Normalform.
Besitzt eine Relation einen nicht zusammengesetzten Primärschlüssel, so fallen die Definitionen der
dritten, vierten und fünften Normalform zusammen!
2.2 Entity-Relationship-Modell
Nachdem geklärt wurde, wie einzelne Relationen aufgebaut werden sollten, wird nun beschrieben,
wie die Beziehungen zwischen den Relationen gestaltet werden sollen.
2.2.1 Entitäten
Tab. 5 Begriffe zu relationalen Datenbanken
Entiät ein unterscheidbares Objekt (im Sinne der betrachteten Objekte in der
Datenbank), im mathematischen Sinne ein Element
Eigenschaft ein Teil einer Entität, der die Entität beschreibt
Beziehung eine Entität, die zwei oder mehr Entitäten miteinander verknüpft
Subtyp eine Entität Y, die auch zu einer Entität X gehört
Supertyp eine Entität, die Subtypen enthält
Tab. 6 Beispiele zu den Begriffen zu relationalen Datenbanken
Begriff Beispiele
Entität Person, Werkzeugteil, Produkt, Rechnung
Eigenschaft Name, Vorname, PLZ, Ort, Adresse einer
Person; Einzelteile, aus denen ein Werkzeug
besteht; Rechnungsdatum
Beziehung die Relation Verknuepfung verbindet die
Relationen Verkaeufer und Produkt (siehe
Tab.7)
Subtyp die Entität Programmierer ist ein Subtyp zu
Entität Person.
Supertyp die Entität Person ist ein Supertyp der Entität
Programmierer.
10/13

Tab. 7 Relation Verkaeufer
Verk_Nr Verk_Name PLZ Verk_Adresse
V1 Meier 80075 München
V2 Schneider 70038 Stuttgart
V3 Müller 50083 Köln
Tab. 8 Relation Produkt
Prod_Nr Produktname
P1 Waschmaschine
P2 Herd
P3 Kühlschrank
P4 Staubsauger
Tab. 9 Realtion Verknuepfung
Verk_Nr Produkt_Nr Umsatz
Abb. 3 Beispiel zu Entitäten und Eigenschaften
V1 P1 11000
V1 P2 5000
V1 P3 1000
V2 P2 4000
V2 P3 3000
V3 P4 1000
11/13

Ein Beispiel zu Beziehungen zwischen Relationen (Abb. 4):
Eine Entität Person hat eine Beziehung zu der Entität (Relation) Abteilung, in der Daten zu den
Abteilungen abgespeichert sind. Diese Beziehung stellt selbst eine Entität dar, eine sog.
Beziehungs-Entität (dargestellt als Raute).
Abb. 4 Beispiel einer Beziehungsrelation
Es wird zwischen schwachen und starken Entitäten unterschieden. Eine schwache Entität hängt von
einer starken Entität ab. Wird die starke Entität entfernt, so verliert jede von ihr abhängige
schwache Entität ihre Daseinsberechtigung und kann auch entfernt werden.
Ein Beispiel wären die Entitäten Produkt, Einzelteile und Fehler. Die Entitäten Einzelteile und
Fehler hängen von Prokukt ab. Falls alle Fehler prokukt-spezifisch sind, so ist Fehler eine schwache
Entiät, d. h. falls das Produkt aus der Prokuktion genommen wird, so sind die Fehlerdaten wertlos.
Einzelteile können jedoch für verschiedene Produkte verwendet werden, diese Entität ist daher nicht
schwach.
2.2.2 Beziehungen: Primärschlüssel und Fremdschlüssel
Eine Beziehungsentiät zwischen zwei Entitäten enthält zwei Fremdschlüssel, die auf die
Primärschlüssel der beiden Entitäten verweisen. Es liegen also Beziehungen wie zwischen
Verkaefer und Produkt, oder wie zwischen Teilelieferant und Teile vor. Es sind auch Beziehungen
zwischen mehreren Entitäten möglich, die Beziehungs-Entitäten enthalten dann dementsprechend
mehr Fremdschlüssel.
Abb. 5 Beziehungsrelation zwischen Verkaeufer und Prokukt
Die Relation Verknuepfung wird in SQL wie folgt erzeugt, wobei alle Schlüsselinformationen
bereits mit angegeben sind:
12/13

CREATE TABLE Verknuepfung
( Verk_Nummer CHARACTER(4) REFERENCES Verkaeufer,
Produkt_Nr CHARACTER(4) REFERENCES Produkt,
Umsatz SMALLINT,
PRIMARY KEY (Verk_Nummer, Produkt_Nr)
);
Einige Empfehlungen zum Erstellen einer Datenbank:
Auswahl aller Eigenschaften, die in die Datenbank aufgenommen werden sollen (meist ein
langwieriger und zeitraubender Prozess). Eine gute Auswahl schon in der Anfangsphase
verhindert ein mehrmaliges und zeitraubendes Anpassen der Datenbank.
Zusammenfassen der Eigenschaften zu Entitäten. Hier ist die Normalformenlehrre zu
berücksichtigen. Bei guter Auswahl der Entitäten werden die Relationen meist automatisch in
dritter oder höherer Normalform sein.
Ermittlung der Beziehungen zwischen den einzelnen Entitäten
Erzeugen der Relationen, Erzeugen der Beziehungsrelationen. Geeignete Wahl der
Fremdschlüssel.
Ermittlung der Eigenschaften der Fremdschlüssel. (Was soll mit ihnen geschehen falls der
zugehörige Primärschlüssel eine „Lösch- oder Update-Anfrage“ bekommt.) Hier helfen auch
Stichworte wie schwache Entität und Subtyp weiter.
13/13