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
erleichtert, Speicherplatz wird gespart.
Daten sind übersichtlich abgelegt, Abfragen sind
einfach.
gute Handhabbarkeit,
einfache Zugriffe über möglichst wenige
Tabellen
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
V1
Meier
V1
Meier
V1
Meier
V2
Schneider
V2
Schneider
V3
Müller
PLZ
80075
80075
80075
70038
70038
10183
Verk_Adresse
München
München
München
Stuttgart
Stuttgart
Berlin
Produktname
Waschmaschine
Herd
Kühlschrank
Herd
Kühlschrank
Staubsauger
Umsatz
11000
5000
1000
4000
3000
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
Relation
Tupel
Kardinalität
Attribut
Grad
Primärschlüssel
Gebiet
Informelle Ausdrucksweise
Tabelle
eine Zeile (Reihe) einer Tabelle
Anzahl der Zeilen einer Tabelle
eine Spalte (Feld) einer Tabelle
Anzahl der Spalten einer Tabelle
eindeutiger Bezeichner einer Zeile (eines Tupels)
Menge aller möglichen Werte
L#
Lname
Stadt
PLZ
L1
Müller
München
81724
Schmidt
Regensburg
93055
L3
Maier
Hamburg
20543
L4
Schwarz
Köln
50087
L5
Weiß
Berlin
11168
Relation L2
Kopf(zeile)
Rumpf
Tupel
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 ...;
CREATE VIEW ...;
SELECT ...;
CREATE TEMPORARY TABLE ...;
Erzeugen einer Basisrelation
Erzeugen einer Sicht
Abfrage
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
7
1998
Herd
T06
<--- Primärschlüssel ------------->
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
V1
P1
11000
V1
P2
5000
V1
P3
1000
V2
P2
4000
V2
P3
3000
V3
P4
1000
Abb. 3 Beispiel zu Entitäten und Eigenschaften
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)
Produkt_Nr
CHARACTER(4)
Umsatz
SMALLINT,
PRIMARY KEY (Verk_Nummer, Produkt_Nr)
);
REFERENCES Verkaeufer,
REFERENCES Produkt,
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