hauptseminar: relationales modell, normalisierungstheorie

HAUPTSEMINAR:
RELATIONALES MODELL, NORMALISIERUNGSTHEORIE
WINTERSEMESTER 2001/2002
BETREUER :
VERFASSER:
WOLFGANG WOHNER
ABDELKARIM HARBAOUI
VORTRAGSTERMIN: 06.11.2001
- Dr. Edgar F. Codd (Turing Award 1981) -
1
INHALTSVERZEICHNIS
1. Einleitung.................................................................................................................3
1.1.
History................................................................................................................3
1.2.
Dr. Edgar F. Codd .....................................................................................3
1.3.
Motivation für den Einsatz eines DBMS ....................................4
1.3.1.
1.3.2.
1.3.3.
Redundanz und Inkonsistenz ......................................................................4
Probleme des Mehrbenutzerbetriebs .........................................................4
Verlust von Daten ..........................................................................................4
2. Das relationale Modell und die Normalform....................4
2.1. Definition des relationalen Modells.....................................................5
2.1.1. Mathematischer Formalismus .........................................................................5
2.1.2. Schema und Ausprägung einer Relation ......................................................6
2.2. Normalform (nach Codd) ...........................................................................8
2.2.1. Die Prozedur ........................................................................................................9
2.2.2. Funktionale Abhängigkeit .........................................................................10
2.2.3. Normalisierung heute ......................................................................................11
2.3.
Sprachliche Aspekte..............................................................................11
3.1. Operatoren der Relationenalgebra ...................................................12
3.1.1. Permutation ........................................................................................................13
3.1.2. Projektion ...........................................................................................................14
3.1.3. Der relationale Verbund (Join) .....................................................................14
3.1.4. Andere Verbunde .............................................................................................15
3.1.5. Link (Tie) ...........................................................................................................16
3.1.6. Komposition ......................................................................................................16
3.1.6. Restriktion ..........................................................................................................18
3.2. Redundanz.........................................................................................................19
3.2.1. Starke Redundanz ...........................................................................................19
3.2.2. Schwache Redundanz ....................................................................................20
3.3. Konsistenz..........................................................................................................20
4. Zusammenfassung .....................................................................................20
5. Literatur ...................................................................................................................21
2
1. Einleitung
Die Datenbank ist eine Bezeichnung für gespeicherten Daten. Sie enthält
Informationseinheiten, die zur Kontrolle und Steuerung eines Aufgabenbereichs
notwendig sind.
Für den Zugriff auf die Datenbasis, zur Kontrolle der Konsistenz und zur Modifikation
der Daten sind klare Konzepte notwendig. Diese Programme nennt man
Datenbankverwaltungssysteme.
1.1. History
Datenbanksysteme, die nach dem hierarchischen Datenbankmodell entwickelt
wurden, waren in den 60er Jahren weit verbreitet [Chen, 1976]. Der Benutzer musste
die Speicherstruktur jedoch selbst verwalten. Außerdem war die Manipulation
größerer Mengen von Daten sehr aufwendig.
Aufgrund dieser und weiterer Mängel entwickelte Dr. Edgar F. Codd (1970 ) das
relationale Modell.
Die Anforderungen an ein Datenbanksystem hatten sich verändert - ein neues
Datenbankkonzept wurde benötigt. Da komplexe Objekte, wie sie in Designsystemen (z.B. CAD) häufig vorhanden sind, unter relationalen Datenbanksystemen
nur mit hohem Aufwand realisiert werden können, wurde mit Hilfe des
objektorientierten Datenbankmodells Ende der 80er Jahre unsere Datenbankwelt
erweitert.
Systeme wie MS Access und Oracle, die auf dem relationalen Datenbankmodell
aufbauen, sind noch bis heute am weitesten verbreitet, da dieses Modell eine gute
Basis zur Kontrolle der Redundanz, Konsistenz und für die Ableitbarkeit von
Relationen besitzt (wird später in Punkt 3.2. erklärt).
1.2. Dr. Edgar F. Codd
Er wurde 1923 in Portland, UK geboren und erwarb seinen Titel als Ph.D an der
Universität von Michigan. Die in seiner Zeit zum Archivieren und Verwalten von
Daten entwickelten Systeme wiesen viele Schwachstellen auf und führten meistens
zu Fehlern. So galt sein erstes Papier „A relational model of data for large shared
data banks“ (Communications of the ACM, Juni 1970) über das relationale Modell
dem Versuch, ein besseres System zu entwickeln. Dort legt der Erfinder und
Mitentwickler des relationalen Modells die Gundlagen der Relationenalgebra sowie
die erste, zweite und dritte Normalform ([k,E 2001] Seite 174) dar. Auch die BCNormalform und der relationale Tupelkalkül wurden von Codd erfunden und
anschließend nachgereicht ([Rustin 1972] R. Rustin, Data Base Systems, PrenticeHall, Englewood Cliffs, NJ (1972)).
Für diese Arbeiten und seine zahlreichen weiteren Veröffentlichungen hat Codd 1981
den Turing-Preis, die höchste Auszeichnung für Informatiker, erhalten.
3
1.3. Motivation für den Einsatz eines DBMS
Der Einsatz
eines Datenbankverwaltungssystemes ist die beste Alternative,
voneinander abhängige Daten effizient zu modellieren und effektiv zu verwalten.
Ohne ein solches System, indem man z.B. Informationen in isolierten Dateien
speichert, ergeben sich gravierende Probleme, die im Folgenden dargestellt werden:
1.3.1.
Redundanz und Inkonsistenz
Redundanz bedeutet das mehrfache Speichern einer einzelnen Information.
Falls viele Kopien einer Information nötig sind, kommt es vor, dass Änderungen nicht
in allen Kopien realisiert werden, d.h. Inkonsistenz.
Beispiel (ohne DBMS): Wenn ein Angestellter zum Abteilungsleiter befördert wird
und bei der Registrierung in der Abteilungsleiterliste der alte Eintrag als normale
Angestellter nicht gelöscht wird (d.h. die Daten dieser Mitatbeiter sind dopplt
gespeichert), entstehen redundante Daten. Redundanz verursacht meistens die
Inkonsistenz, also wenn z.B. als erstes der Alte Eintrag geändert wird und die neue
Eintragung nicht, spricht man von Inkonsistenz.
1.3.2.
Probleme des Mehrbenutzerbetriebs
Wird eine Datei von zwei oder mehreren Personen bearbeitet, kann es passieren,
dass die Änderungen des einen Benutzers von dem anderen, der die Datei zuletzt
zurücklegt, überschrieben werden. Das nennt man „Lost Update“. Ein DBMS
verhindert so ein Problem.
1.3.3.
Verlust von Daten
Ohne ein DBMS ist die Wiederherstellung eines konsistenten Zustands der
Gesamtdateneinheit im Fehlerfall sehr schwierig oder sogar unmöglich. Geht die
Datenbank von einem Zustand zum nächsten über, verhindert das DBMS Fehler
während der Transaktion. Im Fehlerfall kann das System den vorherigen Zustand
wiederherstellen.
Nachdem die wichtigsten Probleme, die im Allgemeinen beim Erstellen eines
Datenbanksystems zu untersuchen sind, aufgelistet wurden, sollen nun die Inhalte
des ersten Papiers Codds „A relational model of data for large shared data banks“
diskutiert werden.
2. Das relationale Modell und die Normalform
Im Gegensatz zu den bis zu den 70er Jahren vorherrschenden satzorientierten
Datenmodellen (das Netzwerkmodell und das hierarchische Modell), besteht die
Besonderheit dieses Datenmodells in der mengenorientierten Verarbeitung der
Informationen. Das relationale Modell ist im Vergleich zu den satzorientierten
Modellen sehr einfach strukturiert. Eine Relation ist eine flache Tabelle, in welcher
die Zeilen den Datenobjekten entsprechen. Diese Einfachheit zählt zu den Vorteilen
dieses Modells. Das relationale Modell bietet eine maximale Unabhängigkeit der
4
Daten, d.h. Änderungen in der physischen (oder logischen) Ebene – wie das
nachträgliche Anlegen eines Indexes - dürfen nicht die Sichten- bzw. BenutzerEbene beeinflussen, außer effizienzmäßig.
•
•
•
In der physischen Ebene werden die Speicherstrukturen festgelegt.
In der logischen Ebene wird in dem Datenbankschema (wird noch im Punkt
2.1.2 erklärt) festgelegt, welche Daten gespeichert sind.
Während das Datenbankschema der logischen Ebene die gesamte
Informationsmenge darstellt, werden in der sichten Ebene nur Teilmengen der
Daten bereitgestellt.
Sichten Ebene
Logische Ebene
2.1. Definition des relationalen Modells
Eine Relation ist eine Menge von Tupeln (Zeilen), wie oben bereits erwähnt. Man
kann die Relation als Tabelle illustrieren, wobei in die Zeilen die Datensätze (Tupel)
eingetragen werden. Die Spalten enthalten die aktiven Domänenwerten bzw.
Attributelemente (dies wird im Folgenden noch genauer erklärt).
2.1.1. Mathematischer Formalismus
Domänen (Bereiche von Aktivitäten, Beschreibungen eines physischen oder
logischen Gegenstandes oder Interessen, die kontrollierbar sind) sind
Wertebereiche, die nicht notwendigerweise unterschiedlich sein müssen: D1, D2, D3
..., Dn; und Di = Dj ist zugelassen für i ≠ j mit {n, i, j} ∈ IN. Der Inhalt dieser Domänen
kann nicht strukturiert werden und hat nur atomare Werte (die erste Normalform).
Mögliche Domänen sind z.B. Zahlen, Zeichenketten etc. Eine Relation ist eine
Teilmenge des kartesischen Produkts der n Domänen:
R ⊆ D1Χ ..... ΧDn
5
2.1.2. Schema und Ausprägung einer Relation
Hier muss man zwischen dem Schema einer Relation, das durch die n Domänen
gegeben ist, und der aktuellen Ausprägung (Instanz), die durch die Relation
dargestellt wird, unterscheiden. Ein Element der Menge R wird als Tupel bezeichnet;
seine Stelligkeit ergibt sich aus dem Relationenschema. In diesem abstrakten
Beispiel ist die Stelligkeit n. Im Folgenden soll nun der Unterschied deutlich gemacht
werden.
Beispiel: Supply ⊆ String Χ String Χ integer Χ String
In diesem Schema ist der Name des Suppliers durch den ersten String-Wert
repräsentiert, Part durch den zweiten, der Integer-Wert steht für den Project und das
Attribut Quantity wird durch den letzten String-Wert dargestellt . Supply ist eine 4stellige Relation.
Schema: Supply: = {Supplier, Part, Project, Quantity t}
Ausprägung: Hier wird die Relation als Tabelle bezeichnet, weil man sich die
Ausprägung einer Relation wie folgt als flache Tabelle veranschaulichen kann.
Supplier
………
Part
……………
Supply
Project
……………
Quantity
………………..
Abb. 1. Eine Ausprägung der Relation Supply
Sei R eine n-stellige Relation, R = { A1, A2, ......, An }. R hat die folgenden
Eigenschaften:
(1) Jede Zeile ist ein n-Tupel von R.
(2) Die Ordnung der Zeilen ist irrelevant. Das erklärt die Mengenorientierung des
relationalen Modells.
(3) Die Zeilen sind deutlich verschieden, d.h. Keine Tupelduplikaten sind zulässig.
(4) Die Ordnung der Spalten ist signifikant (außer wenn die Domänennamen
verschieden sind).
(5) Jede Spalte bekommt den Namen der korrespondierenden Domäne.
Das Beispiel in Abb. 2 illustriert die 4-stellige Relation Supply. In dieser beschreibt
man folgendes: Welcher Teil (Part) wird geliefert, welcher Lieferant (Supplier) liefert
den Teil, zu welchem Projekt (Project) gehört der Teil sowie die Zahl der gelieferten
Teile (Quantity).
6
Supplier
1
1
2
2
4
Part
2
3
3
7
1
Supply
Project
5
5
7
5
1
Quantity
17
23
9
4
12
Abb. 2. Relation mit Grad 4
Im Abb. 3 stellt man eine 3-stellige Relation dar, um die Bedeutsamkeit der Ordnung
der Spalten zu zeigen.
Part
1
2
3
2
3
4
6
Component
Part
5
5
5
6
6
7
7
Quantity
9
7
2
12
3
1
1
Abb. 3. Relation mit zwei gleichen Domänen
Die Relation component: = {part, part, quantity} ≡ {x, y, z} hat zwei identische
Attribute bzw. Domänennamen, wobei das erste Attribut eine Teilmenge von dem
zweiten (x ⊂ y) ist. z steht für die Zahl der x-Teile, die man benöigt, um ein y-Einheit
zu bauen. X und y unterscheiden sich semantisch , also eine andere Permutation der
Attribute liefert eine neue Ausprägung, die nicht die gleiche Information wie
component hat.
Um so ein Problem zu vermeiden, muss man die gleichbenannten Attribute z.B.
entsprechend ihrer Funktionen benennen, im Beispiel: x → sub.part und y →
super.part. Der Punkt ist nur ein Namensbestandteil, und darf nicht mit dem
Komponentoperator - z.B. in SQL - verwechselt werden.
Die Informationen in einer Datenbank sind eine Menge von Relationen, die i. a.
verschiedene Stelligkeiten (degrees) haben. Eine n-stellige Relation ist
zeitvariierend, d.h. man kann in jeder Zeit neue n-Tupel einfügen, existierende Zeilen
löschen oder Komponenten aller möglichen n-Tupel ändern.
Eine der Möglichkeiten,wie man das relational Modell für eine Datenbank errichten
kann, ist die Normalform. Für diesen Zweck müssen jedoch erst einige Konzepte
(active domain, primary key, foreign key, and nonsimple domain) definiert werden.
Hier wird nicht zwischen Gegenständen und Beziehungen unterschieden.
7
a) Aktive Domäne (Active domain)
In der Relation part: = {pNumber, pName, pColor, pWeight, quantityOnHand,
quantityInOrder} ist jedes Attribut bzw. jede Domäne eine Menge von Werten.
Während es vorstellbar ist, dass z.B. alle möglichen Farben eines Teils in mancher
Ausprägung dargestellt werden, ist es unwahrscheinlich, dass die restlichen
Domänen-Werte auch alle in einer Instanz vorzukommen (Unterschied zwischen
endlichen und unendlichen Mengen). Die Menge der Werte, die zu einem
bestimmten Zeitpunkt in der Tablle repräsentiert sind, nennt man „active domain“.
b) Primärschlüssel (Primary key)
Ein primary key ist eine nicht redundante Domäne (oder eine Domänenmenge) einer
Relation, deren Werte den Inhalt der Tabelle (Tupel) eindeutig identifizieren können.
Im Beispiel part ist der Primärschlüssel pNumber. Gibt es mehrere nicht redundante
Kandidatenschlüssel, dann kann man ohne Einschränkung einen als Primärschlüssel
davon auswählen.
c) Fremdschlüssel (Foreign key)
Ein Attribut (oder Attributmenge) ist ein Fremdschlüssel in einer Relation R, wenn er
kein Primärschlüssel ist und weist auf einen Primärschlüssel in einer anderen
Relation S hin (R und S können identisch sein). Das kommt vor, wenn es sich um
eine Beziehung darstellende Tabelle handelt oder wenn die Relation durch
Kreuzprodukt oder Verbund (siehe Punkt 3.1.3.) von anderen Relationen entstanden
ist. In der Relation supply ist die Kombination {supplier, part, project} ein
Primärschlüssel, während jedes dieser drei Attribute ein Fremdschlüssel ist.
d) Nichteinfache Domäne (Nonsimple domain)
Als solche bezeichnet man strukturierbare Domänen. Eine Domäne ist nicht einfach,
wenn sie wiederum eine Relation darstellt. In der Relation employee in Abb. 4 ist
jobhistory eine Relation, mit jobdate, title und salaryhistorie als Attribute. Jobhistory
ist ein nicht elementarer Wertebereich, dies nennt man nonsimple domain.
2.2. Normalform (nach Codd)
Wenn eine Relation eine oder mehrere nicht atomare Domänen beinhaltet, kann sie
nicht als eine flache Tabelle veranschaulicht werden, d.h. man kann sie nicht zwei–
dimensional mit homogenen Spalten darstellen. Normalisierung ist die Bezeichnung
der Prozedur, mit welcher man alle nonsimple domains eliminieren kann, so dass die
Relationen die Normalform annehmen.
Im Abb. 4(a) sind Relationen mit nicht einfachen Domänen dargestellt. Jobhistory
und children sind nonsimple domains der Relation employee. Salaryhistory ist ein
strukturiertes Attribut der Relation jobhistory.
Die Merkmale einer nicht normalisierten Kollektion von Relationen sind:
(1) Der Graph von nonsimple domains, die in Beziehung stehen, ist eine
Kollektion von Bäumen.
8
(2) Der Primärschlüssel besteht aus einer oder mehreren elementaren Domänen.
Employee
Jobhistory
Salary history
Children
Employee: = {man#, name, birthdate, jobhistory, children}
Jobhistory: = {jobdate, title, salaryhistory}
Salaryhistory: = {salarydate, salary}
Children: = {childname, birthyear}
Abb. 4 (a) nicht in normal Form Relationen
2.2.1. Die Prozedur
Sowohl im Abb. 4(a) als auch im Abb. 4(b) sind Primärschlüssel unterstrichen und
kursiv geschrieben. Im Abb 4(b) ist die Kollektion der Relationen durch die folgenden
Schritte in Normalform erzwungen worden.
(1) Der Primärschlüssel der Wurzel-Relation wird in jeden der Knoten-Relationen
eingefügt. Im Beispiel employee ist man# gemeint.
(2) Der Primärschlüssel einer Kind-Relation ist zum einen Teil aus dem alten
eigenen Primärschlüssel zusammengesetzt und zum anderen Teil aus dem
von der Vater-Relation übernommenen. In der Relation Jobhistory’ ist der
neue Primärschlüssel „man#, jobdate“.
(3) Alle nicht einfachen Domänen in der Vater-Relation eliminieren, wie jobhistory
und children in Employee.
(4) Die Wurzel-Relation merken und diese Operationen beim rechten und linken
Teilbaum wiederholen.
9
Durch die Anwendung dieser Prozedur erhält man folgende Relationen:
Employee’: = {man#, name, birthdate}
Jobhistory’: = {man#, jobdate, title}
Salaryhistory’: = {man#, jobdate, salarydate, salary}
Children’: = {man#, childname, birthyear}
Abb. 4 (b) in normal Form Relationen
2.2.2. Funktionale Abhängigkeit
Die funktionale Abhängigkeiten sind Grundlagen der Entwurfs- und
Modellierungstechnik eines Datenbanksystems. Im ersten Papier [Codd 1970] ist
dieses Thema nicht behandelt worden sondern erst ab [Codd 1972]. Das hier
Erklärte wird danach für die detaillierte Definition der Normalform benötigt.
a. Definition
Sei R eine Menge von Attributen, R= {a1, a2, ....., an} , so dass (a1, a2, ....., an) aus
dem Domänenvektorprodukt (D1xD2x.....xDn), Di = Dj ist für i ≠ j zugelassen, d.h.
verschiedene Attribute dürfen gleiche Domänen haben. Ist a1 funktional abhängig von
a2, dann existiert eine Funktion F mit:
F(R.a1) = R.a2
Eine funktionale Abhängigkeit - oft abgekürzt als FD (engl. functional dependency) wird wie folgt dargestellt:
tß
Hierbei repräsentieren die Buchstaben t und ß jeweils Mengen von Attributen. Ist die
FD t ß auf dem Relationenschema R definiert, d.h. t und ß bilden Teilmengen von
R, dann sind nur solche R- Instanzen erlaubt, wo für alle Paare von Tupeln a, b aus
R mit a.t = a.ß muß auch gelten b.t = b.ß.
b. Volle funktionale Abhängigkeit
Neben der funktionalen Abhängigkeit muss die FD linksreduziert (t ist minimal) sein,
formal ein Attribut a ist in R voll funktional abhängig von {a1, a2, ..., an}, g.d.w. a nicht
von einer echten Teilmenge ( {a1, a2, ...., ak} | k ≤ n ) funktional abhängig ist.
Hinweis: Ist der Primärschlüßel zusammengesetzt, so ist jedes Attribut von ihm funk.
abhängig, aber nicht unbedingt voll funktional abhängig.
10
c. Transitive Abhängigkeit
(F+ ist die Menge der linksreduzierten funktionalen Abhängigkeiten in R).
Gegeben sei eine Menge funktionaler Abhängigkeiten F, ein Relationenschema R,
eine Attributsmenge X und ein Attribut A aus R. A ist transitiv abhängig von X, wenn
es eine Attributmenge Y aus R gibt, so dass (X Y) von F+ und (Y A ) von F+
sind und (Y X) gehört F+, A nicht von der Form XY gilt.
XYA
2.2.3. Normalisierung heute
Hier werden nur die erste, die zweite und die dritte Normalform besprochen. Im [K, E
2001], Seite 174 wird behauptet, dass diese Normalformen equivalent zur der obigen
Normalform-Prozedur (2.2.1.) sind. Das kann höchstens gelten, wenn in jeder
Relation alle Attribute nur den Gegenstand beschreiben, der von der Relation
dargestellt wird, d.h. die Attribute sind voll abhängig vom Primärschlüssel.
In der ersten Normalform wird die Atomarität der Attribute gefordert, d.h. die Attribute
dürfen nicht strukturiert (komplexe Werte) sein.
Ein Relationenschema ist in zweiter Normalform, wenn es in erster NF ist und wenn
jedes Nicht-Schlüssel-Attribut von jedem Schlüssel der Relation voll abhängig ist.
Eine Relation nimmt die dritte Normalform an, wenn es in zweiter NF ist und kein
nichtprimes (∉ {Kandidatenschlüsselattribut}) Attribut von einem Schlüssel in R
transitiv abhängig ist.
Erste NF
Zweite NF
Dritte NF
D.h. die dritte NF setzt die zweite voraus, diese wiederum die erste.
2.3. Sprachliche Aspekte
Man benötigt neben der Strukturbeschreibung eine Sprache, mit welcher die
Informationen in der Datenbank definiert und manipuliert werden können. In diesem
Zusammenhang werden zwei Hauptsprachen vorgestellt:
Sublanguage (die Datendefinition und die Datenmanipulation, wie SQL) und die
Hostlanguage ( Programmiersprache wie C, Java, COBOLD, in welcher man eine
DSL einbetten kann ). Die DSL (Sublanguage) erlaubt die Deklaration der Relationen
und ihre Domänen. Bei der Deklaration wird der Primärschlüssel der entsprechenden
11
Relation identifiziert. Die Sublanguage ermöglicht genaue Angaben über Ergebnisse
der lesenden Anfragen und besitzt Sicherheitsbeschränkungen, so dass nur
authorisierte Benutzer auf bestimmte Bereiche in der Datenbank Aktionen ausführen
könen. Die Besonderheit dieser Sprache liegt in ihrer Datenbeschreibungsfähigkeit
(und nicht in der Rechenfähigkeit) [C, J 1995].
3. Redundanz und Inkonsistenz
Eine Information ist redundant, wenn sie ohne Informationsverlust weggelassen
werden kann; Konsistenz ist die „Richtigkeit" von Daten im Zusammenhang mit
anderen Daten. Ist eine Datenbank inkonsistent, so können Daten aus der gleichen
oder anderen Quellen nicht miteinander kombiniert werden, ohne zu falschen
Ergebnissen zu führen.
Vor einer detaillierteren Erklärung werden die Gundlagen der Relationenalgebra
eingeführt.
Supply2
Supplier
Part#
partColor
partweight
project
S1
S1
S3
S4
1
1
5
2
We
We
Ro
Bl
5
5
7
1
10
20
30
40
Die Eigenschaften des Teils 1 sind redundant gespeichert. Falls das Projekt 40
gelöscht wird, werden Informationen über Supplier S4 verloren gehen (Inkonsistenz).
3.1. Operatoren der Relationenalgebra
Die relationale Algebra ist prozedural orientiert, d.h. ein relationenalgebraischer
Ausdruck enthält implizit einen Bearbeitungsplan, wie die Anfrage auszuwerten ist.
Sie spielt die grössere Rolle bei der Realisierung von Datenbanksystemen. Stehen
die Relationen in einer Kollektion, dann kann man im Allgemeinen alle möglichen
Mengenoperationen anwenden.
Zunächst werden einige Operatoren der Relationenalgebra kurz erwähnt, dann
werden die Operatoren, die Codd in seinem ersten Papier beschrieben hat,
eingeführt. Einige dieser Operatoren werden heute nicht mehr verwendet und fast
alle hatten damals andere Symbole.
12
•
Selektion (σ): Die Tupel (die Zeilen), die das Selektionsprädikat erfüllen,
werden bei dieser Operator selektiert.
•
Projektion (Π): Die Spalten der Tabelle, die als Projektionsprädikat im
Ausdruck dargestellt sind, werden hier als Ergebnis ausgegeben.
•
Vereinigung (U): Nur zwei Relationen, deren Schemata gleich sind, sind,
vereinbar.
•
Mengendifferenz (-): Falls zwei Relationen R1, R2 gleiche Domänen und
Attributnamen haben, kann man durch (R1 – R2 ) die Tupel, die in R1 und nicht
in R2 vorkommen, definieren.
•
Kreuzprodukt (X): Man bildet durch das kartesische Produkt zweier
Relationen (R1 X R2) alle möglichen Tupel-Paare aus R1 und R2. Das Schema
der Ergebnisrelation (sch(R1XR2)) ist eine Vereinigung aus sch(R1) und
sch(R2).
•
Umbenennung von Relationen und Attributen (ρ):
ρ v (Relation): V ist der neue Name der Relation.
ρ v Attribut (Relation): Das Attribut wird zu V umbenannt.
•
•
) : (R1 ⋈ R2) := Π A1,....,An, R1.B1,..., R1.Bk, C1,..,Cm (σ
R1.b1=R2.B1,...,R1.Bk=R2.Bk (R1 X R2)), mit R1 = { A1, A2, .., B1, ..., Bk, ..An } und R2 = {
C1, C2, ..., B1, ..., Bk, Cn }.
Der Verbund (
⋈
Allgemeine/Theta Join ( ⋈θ ): (R1 ⋈θ R2) := σθ (R1 X R2).
Man selektiert aus den n∗m Tupeln nur die Zeilen, die eine beliebige
Bedingung bzw. ein beliebiges Prädikat θ erfüllen.
•
Mengenduchschnitt (∩): R1∩R2 := R1 – (R1 – R2).
•
Die relationale Division (÷): Für die Durchführung der Division (R1 ÷ R2) muss
gelten, dass R2 eine Teilmenge von R1 ist. Dann ist das Ergebnisschema als
Mengendifferenz zu definieren, also nur die Attribute, die in R1 und nicht in R2
enthalten sind, werden ausgegeben.
Zunächst werden die Operatoren aus dem Papier [Codd 1970] eingeführt.
3.1.1. Permutation
Eine binäre Relation hat eine Array-Repräsentation mit zwei Spalten. Vertauscht man
die Spalten, so bekommt man eine Spiegelung der Relation. I. a. erhält eine nstellige Relation n! = n(n-1)(n-2)....*2*1 Instanzen, wenn man ihre Attribute
permutiert, (die Identität und die Spiegelung sind eingeschlossen). Das Beispiel
supply in Bild 2. hat 4! = 24 Permutationen. Weil das relationale Modell keine
sortierten Listen enthält, ist der Gebrauch von diesem Operator nicht mehr nötig. In
seltenen Fällen kann die Permutation durch die Projektion und ein passendes
Prädikat als Subskript ausgedrückt werden. Indem man Relationen ohne ihre
Permutationen speichert, gewinnt man an Speicherkapazität. Dies zählt zu den
Vorteilen des relationalen Modells.
13
3.1.2. Projektion
Die Spalten der Tabelle werden hier als Ergebnis ausgegeben. Die Projektion ist
durch das griechische Π bezeichnet und hat als Projektionsprädikat nur die Menge
der Attribute, die projiziert sein sollen. I. a. verzichtet man auf die Mengenklammern.
ΠPrädikat (Relation),
Πproject, supplier (supply)
Beispiel: Allgemein
Konkret
Π project, supplier (supply)
Project
5
5
1
7
Supplier
1
2
4
2
Abb.5 permutierte Projektion
Im konkreten Beispiel wurde gleichzeitig permutiert und projeziert.
3.1.3. Der relationale Verbund (Join)
Der Verbund ( Join ) zweier Argumentrelationen R1 und R2, (R1 * R2) hat insgesamt
n + m + k Attribute, wenn R1 und R2 n + k bzw. m + k Attribute haben, und k der Zahl
der in beiden Relationen gleichbenannten Attribute. Man kann sich das
Ergebnisschema wie folgt veranschaulichen:
R1 * R2: = Π
A1
σ R1.B1 = R2.B1,...,R1.Bk = R2.Bk (R1 × R2))
A1,...An, R1.B1,..., R1.Bk, C1,…, Cm (
R1 – R2
A2 .............
An
B1
B2
R1 * R2
R1 ∩ R2
...................
Bk
C1
R2 – R1
C2 ..............
Beispiel:
R1:= {supplier, part}
Supplier
Part
1
1
2
1
2
2
R2: = {part, project}
Part
Project
1
1
1
2
2
1
Abb. 6. zwei verbindbare Relationen
14
Cm
Supplier
1
1
2
2
2
R1 * R2
Part
1
1
1
1
2
Project
1
2
1
2
1
Abb. 7. Der natürliche Verbund zwischen R1 und R2
R1 und R2 (in Abb. 6) sind verlustfrei verbindbar, d.h. R1 * R2 := {(s, p, j) | R1:= (s, p) ∧
R2:= (p, j)}. Man kann im Abb.7 sehen, wie die gleichbenannten Attribute nur einmal
vorkommen, und dass
Π s, p (R1 * R2) = R1 und Π p, j (R1 * R2) = R2.
3.1.4. Andere Verbunde
Wenn Π p, s (R1) oder R2 eine Funktion (n1 oder 11 Relationen) ist, dann kann
es keine Ambiguität geben, deshalb ist auch nur ein natürlicher Join möglich. Die
Mehrdeutigkeit, welche in der Abb 6. durch jedes Element der Domäne Part erzeugt
wird, erklärt die Pluralität der Verbunde. Die Ambiguität in der Verbindung (R1 * R2)
kann manchmal mit Hilfe einer dritten Relation T(j, s) gelöst werden. Diese Relation
sollte die folgenden Eigenschaften mitbringen:
(1)
Π 1 (T) = Π 2 (R2),
(2)
Π 2 (T) = Π 1 (R1),
(3) T (j, s) → ∃p (R1 (s, p) ∧ R2 (p, j)),
(4) R1 (s, p) → ∃J (R2(p, j) ∧ T (j, s)),
(5) R2 (p, j) → ∃s (T (j, s) ∧ R1 (s, p)).
Nimmt man an, U = R1 * R2 * T, die sogenannte cyclic 3-Join dann folgt:
Π 12 (U) = R1, Π 23 (U) = R2, und Π 31 (U) = T.
Sei γ (R) = { (a1, a2, ..., an-1) : R (a1, a2, ……an-1, an) ∧ a1 = an}, dann kann man den
natürlichen cyclic 3-Join mit γ(R1 * R2 * T) beschreiben.
Um zwischen cyclic 3-Join und linear 3-Join unterscheiden zu können, definiert man
eine 4-stellige Relation V, so dass: Π 12 (V) = R1, Π 23 (V) = R2, und
Der natürliche linear 3-Join von R1, R2, und T ist wie folgt zu definieren:
Π 34 (V) = T
R1 * R2 * T = { (a, b, c, d) : R1(a, b) ∧ R2(b, c) ∧ T(c, d) }.
15
Bemerkung: Der natürliche 2-Join ist assoziativ.
Beispiel:
R1: = {supplier, part}
Supplier
Part
1
a
2
b
2
a
T: = {project, supplier}
Project
Supplier
d
1
d
2
e
2
e
2
R2: = {part, project}
Part
Project
a
d
a
e
b
d
b
e
Abb. 8. Relationen mit mehreren cyclic 3-Joins
U: = {supplier, part, project}
S
P
j
1
A
d
2
a
e
2
b
d
2
b
e
Abb. 9. Eine cyclic 3-Join der Relationen in Abbildung 8.
3.1.5. Link (Tie)
Sei eine Relation R = { A1, A2, ......, An }. R wird verknüpft (tied), wenn alle Tupel mit
R.A1 ≠ R.An eliminiert werden, d.h. die Restriktion (moderne Bedeutung) von R auf
R’ (R’ ⊆ R), mit R’.A1 = R’.An. Der Operator Tie wird mit
γ betzeichnet.
Beispiel:
R
supplier
1
2
2
part
1
1
2
supplier
1
2
γR
part
1
2
3.1.6. Komposition
R1{ X,Y } und R2{ Y, Z } sind zwei verbindbare Relationen und U = R1 * R2 ist eine
Verbundrelation von R1 und R2. T ist eine Komposition aus R1 und R2 g.d.w. T = Π
X, Z (U). Im Spezialfall, dass R1 und R2 binäre Relationen sind, ist T = Π 1, 3 (U). Die
Pluralität der Verbindungen liefert keine Information über die Zahl der
16
Kompositionen. Während man den Join-Operator durch einen Stern (*) visualisiert,
steht der Punkt (·) für die Komposition . Im Beisp. R1 · R2 = Π 13 (R1 * R2).
Weil ein natürlicher Verbund immer möglich ist, gibt es auch immer eine natürliche
Komposition.
Beispiel:
R1 · R2
Supplier
Project
1
1
1
2
2
1
2
2
Abb. 10 natürliche Komposition von R1 und R2.
T
Supplier
2
1
Project
1
2
Abb. 11 beliebige Komposition T von R1 und R2.
Die Kompositionen zweier oder mehrerer Relationen sind höchstens so viele wie die
Verbindungen. In Abb.12 ist c als Quelle der Mehrdeutigkeit durch die erste
Komposition eliminiert worden. Während so viele Joins möglich sind, kann hier nur
eine Komposition generiert werden.
R2
R1
Supplier
1
1
1
2
2
2
Part
a
b
c
c
d
e
Part
a
b
c
c
d
e
Project
g
f
f
g
g
f
R1·R2
Supplier
1
1
2
2
Project
g
f
g
f
Abb.12 mehrere Verbunde und nur eine Komposition
17
Das lässt sich auch auf nicht binäre Relationenpaare (auch mit verschiedenen
Stelligkeiten) verallgemeinern, in dem man dem oberen Muster folgt und die
Relationen paaweise verbindet.
Eine schlechte Anwendung der Komposition führt zu Fehlern. Im Beispiel supply
möchte man herausfinden, welche Projekte von welchem Lieferant stammen, und
setzt dabei voraus, dass supplier’s Elemente auf parts verweisen, und part’s
Elemente wiederum auf die Projekte zeigen. Nur eine natürliche Komposition
zwischen project und supplier kann diese Anfrage korrekt beantworten.
3.1.6. Restriktion
y
F (x)
x
-∞
0
+∞
F ist definiert in dem Bereich ]-∞, +∞[ , man kann sie aber schlecht beschreiben. Hier
bietet sich die Restriction als gute Lösung an. Während F in der Domäne ] -∞, 0] die
Form einer Gerade hat (F ( x ≤ o ) = ax + b), steigt F im positiven Bereich
exponentiell ( F (x > 0) = exp(x)) an. F ( x ≤ o ), F (x > 0) sind Funktionen.
Analog; ein Relationsteil ist wiederum eine Relation. R1 ist über R2 in R1’ reduziert
(restricted), d.h. Π L (R1’) = Π M (R2) mit |L| = |M| ≤ |R1|, |R2| und R1’ ⊆ R1 (R1’ ist
maximal). Man bezeichnet die Restriction mit“ R1L|MR2 “.
Bemerkung: Der SQL-Operator SELECT wird auch mit RESTRICT bezeichnet.
18
Beispiel: R1’ = R1 23|12 R2
s
1
2
2
2
2
R1
P
A
a
a
b
b
R2
J
A
A
B
A
B
P
a
c
b
J
A
B
B
s
1
2
2
R1’
p
a
a
b
j
A
A
B
Abb. 13 Restriktion
3.2. Redundanz
Während Redundanz im physikalischen Bereich das Mehrfachspeichern einer
einzigen Information bedeutet, kann dieses Problem in der Benutzerebene anders
verstanden werden. Um dies besser zu erklären, muss man die Bedeutung der
Ableitbarkeit von Relationen verdeutlichen.
Ein algebraischer Ausdruck besteht aus einer sequentiellen Folge von Operatoren Θ
angewandt auf Argumentrelationen A = {A1, A2,.....}, und liefert eine Ergebnisrelation
E. Also gilt, E ist Θ -ableitbar aus der Relationenmenge A.
3.2.1. Starke Redundanz
Eine Kollektion von Relationen heißt stark redundant, wenn die Projektion von
mindestens einer Relation auch aus anderen Relationsprojektionen in jeder Zeit
ableitbar ist.
Beispiel: Die Kollektion ist einelementig, also besteht sie aus nur einer Relation.
Employee: = {serial#, name, manager#, managername}
∆t (manager#) ⊂ ∆t (serial#), ∆t (managername) ⊂ ∆t (name)
Der Primärschlüssel ist serial#, manager# , bezeichnet den Fremdschlüssel und ∆t
steht für die aktive Domäne. Die Relation ist redundant, weil das Attribut
managername nicht nötig ist, da es auch unter dem Attribut name eingetragen ist .
Das die Redundanz stark ist, wird durch die nächste Gleichung bewiesen:
Π34 (employee) = Π12 (employee) 1|1 Π3(employee)
19
3.2.2. Schwache Redundanz
Wenn es in einer Relationenmenge mindestens ein Mitglied gibt, welches eine
Projektion besitzt, die man aus Relationenverbunde (nicht Projektionen wie oben) der
gleichen Menge jederzeit ableiten kann, spricht man von schwacher Redundanz.
Beispiel:
P(s#, d#, ...), Q(s#, j#, …), R(d#, j#. ...).
Π12(P), Π12(Q), Π12(R) sind drei komplexe (Konverse ist keine Funktion)
Relationen. Man kann Π12(P) ableiten aus einer Π12(Q)- Π21(R)-Komposition.
3.3. Konsistenz
Eine Relationen - Zusammenstellung ist konsistant, wenn alle logischen funktionalen
Abhängigkeiten über die Zeit erhalten bleiben. Für das obige Beispiel:
Π12(P) = Π12(Q).Π21(R) ≡ L = M . N
Es muss immer gelten:
Π1(L) = Π1(M), Π2(P) = Π2(N) und
(a, c) ∈ L ⇔ ∃ b | (a, b) ∈ M & (c, b) ∈ N
Bei bestimmten Eingriffen - wie Einfügen, Löschen oder Einträge ändern - sollte das
Datenbanksystem nach Inkonsistanz prüfen, und wenn möglich, diese verhindern,
damit die Daten konsistant bleiben.
4. Zusammenfassung
Der erste Teil der Ausarbeitung beschäftigt sich mit der Enstehungsgeschichte des
relationalen Modells und einer Motivation für den Einsatz eines DBMS. Anschließend
wurden das R-Modell und die Normalform eingeführt und die Konsistenz sowie
Redundanz erklärt. Gleichzeitig führte man aber auch einige Operatoren der
Relationalalgebra ein.
Das relationale Modell ist im Laufe der Jahre weiter entwickelt worden. Codd hat
beispielsweise in seinen weiteren Publikationen noch Normalformen definiert und
führte den Relationentupelkalkül ein. Die Definitionen, die hier aufgeführt sind,
entsprechen dem Wissen Codds und anderer Informatiker bei der Geburt dieses
Modells. Da es sich um eine Theorie handelt, besitzt das R-Modell seine eigene
Terminologie (Normalform, Relationalalgebra, Referentielle Integretät, ........), die sich
ebenfalls im Laufe der Zeit verändert. Dies ist z.B. bei den eingeführten Operatoren
zu beobachten.
Zuletzt arbeiteten die Hersteller der RDBMS daran, die Konzepte des
objektorientierten Datenbankverwaltungssystems zu übernehmen, um eine
20
Mischform zu konstruieren, z.B. SQL3 [M, J 1995]. Das Ziel ist, die relationale und
objektorientierte Konzepte in SQL zu integrieren und neue Datentypen zu definieren,
die das DBMS verwalten kann. Mit SQL3 wird die Modellierungsmächtichkeit erhöht.
5. Literatur
•
[Codd 1970] E. F. Codd, “A Relational Model of Data for large Shared
Databanks”, Communications of the ACM , Volume 13, Number 6 (June
1970), pages 377-387.
•
[K, E 2001] A. Kemper, A. Eickler, „Datenbanksysteme“, Oldenbourg Verlag,
ISBN: 3-486-25706-4, pages 15-16 und 72.
•
[Rustin 1972] R. Rustin, “Data Base Systems, Prentice-Hall”, Englewood
Cliffs, NJ (1972)
•
[C, J 1995] Chris J. Date „An introduction to Database Systems “.
•
[M, J 1995] Melton, Jim. „Accomodating SQL3 and ODMG“.
•
[Chen,
1976]
P.
Chen.
„the
www.csc.lsu.edu/~chen/papers.html
Entity
Relationship
Model“,
21