HAUPTSEMINAR: RELATIONALES MODELL, NORMALISIERUNGSTHEORIE

HAUPTSEMINAR:

RELATIONALES MODELL, NORMALISIERUNGSTHEORIE

WINTERSEMESTER 2001/2002 BETREUER : WOLFGANG WOHNER VERFASSER: ABDELKARIM HARBAOUI

VORTRAGSTERMIN: 06.11.2001

- Dr. Edgar F. Codd (Turing Award 1981) -

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. Redundanz und Inkonsistenz

...4

1.3.2. Probleme des Mehrbenutzerbetriebs

...4

1.3.3. 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

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 Design- systemen (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 BC- Normalform und der relationale Tupelkalkül wurden von Codd erfunden und anschließend nachgereicht ([Rustin 1972] R. Rustin, Data Base Systems, Prentice- Hall, 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.

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

Sichten Ebene

Daten, d.h. Änderungen in der physischen (oder logischen) Ebene – wie das nachträgliche Anlegen eines Indexes - dürfen nicht die Sichten- bzw. Benutzer- Ebene 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.

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}

Logische Ebene

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 4- stellige 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.

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).

Supply

Supplier Part Project Quantity

……… ……… ……… ………..

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.

Component

Part Part Quantity

1 2 3 2 3 4 6

5 5 5 6 6 7 7

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.

Supply

Supplier Part Project Quantity

1 1 2 2 4

2 3 3 7 1

5 5 7 5 1

17 23 9 4 12

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.

(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.

Durch die Anwendung dieser Prozedur erhält man folgende Relationen:

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.

Employee’: = {man#, name, birthdate}

Jobhistory’: = {man#, jobdate, title}

Salaryhistory’: = {man#, jobdate, salarydate, salary}

Children’: = {man#, childname, birthyear}

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.

X Y A

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.

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

Erste NF

Zweite NF

Dritte NF

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.

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.

• 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.

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

• 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.

• Der Verbund (

⋈

^{) : (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 }.

• 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 n- stellige 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

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.

Beispiel: Allgemein

Π

^Prädikat (Relation), Konkret

Π

project, supplier (supply)

Π

project, supplier (supply)

Project Supplier 5

5 1 7

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,...An, R1.B1,..., R1.Bk, C1,…, Cm(

σ

R1.B1 = R2.B1,...,R1.Bk = R2.Bk(R1

×

^R2))

R1

*

R2

R1 – R2 R1∩ R2 R2 – R1

A1 A2 ... An B1 B2 ... Bk C1 C2 ... Cm

Beispiel:

Abb. 6. zwei verbindbare Relationen

R1:= {supplier, part} R2: = {part, project}

Supplier Part Part Project

1 2 2

1 1 2

1 1

2

1 2 1

R1 * R2

Supplier Part Project 1

1 2 2 2

1 1 1 1 2

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}

Π

^{34 (V) = T}

Der natürliche linear 3-Join von R1, R2, und T ist wie folgt zu definieren:

R1 * R2 * T = { (a, b, c, d) : R1(a, b) ∧ R2(b, c) ∧ T(c, d) }.

Bemerkung: Der natürliche 2-Join ist assoziativ.

Beispiel:

Abb. 8. Relationen mit mehreren cyclic 3-Joins

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 γ ^R

supplier part supplier part

1 2 2

1 1 2

1

2 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 R1: = {supplier, part} R2: = {part, project}

Supplier Part Part Project

1 2 2

a b a

a a b b

d e d e T: = {project, supplier}

Project Supplier d

d e e

1 2 2 2

U: = {supplier, part, project}

S P j

1 2 2 2

A a b b

d e d e

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 2 2

1 2 1 2

Abb. 10 natürliche Komposition von R1 und R2.

T

Supplier Project 2

1 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.

R1 R2

Supplier Part Part Project

1 1 1 2 2 2

a b c c d e

a b c c d e

g f f g g f

R1

·

R2

Supplier Project 1

1 2 2

g f g f

Abb.12 mehrere Verbunde und nur eine Komposition

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

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.

F (x)

Beispiel: R1’ = R1 23|12 R2

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:

Π

³⁴ (employee) =

Π

¹² (employee) 1|1

Π

³(employee)

R1 R2 R1’

s P J P J s p j

1 2 2 2 2

A a a b b

A A B A B

a c b

A B B

1 2 2

a a b

A A B

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),

Π

¹²(R) sind drei komplexe (Konverse ist keine Funktion) Relationen. Man kann

Π

¹²(P) ableiten aus einer

Π

^12(Q)-

Π

²¹(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:

Π

¹²

(P)

=

Π

¹²

(Q) . Π

²¹

(R) ≡

^{L = M}

.

^N

Es muss immer gelten:

Π

¹

(L)

=

Π

¹

(M), Π

²

(P)

=

Π

²

(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

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 Entity Relationship Model“, www.csc.lsu.edu/~chen/papers.html