Das relationale Datenbankmodell

Transcription

Udo Kelter
10.11.2008
Zusammenfassung dieses Lehrmoduls
Das relationale Datenbankmodell besteht im Kern aus Operationen
wie der Selektion, der Projektion und diversen Verbundoperationen.
Diese werden in der relationalen Algebra zusammengefaßt. Dieses
Lehrmodul stellt diese Operationen vor. Vorab wird die statische
Struktur einer relationalen Datenbank definiert. Aus der Vielzahl
denkbarer Integritätsbedingungen werden hier nur Schlüsselbegriffe
behandelt; wir unterscheiden u.a. Identifikations-, Super-, Fremd-,
Primär- und Sekundärschlüssel.
Vorausgesetzte Lehrmodule:
obligatorisch:
– Datenverwaltungssysteme
Stoffumfang in Vorlesungsdoppelstunden:
1
2.0
2
Inhaltsverzeichnis
1 Datenbankmodelle vs. reale Datenbanksprachen
3
2 Die
2.1
2.2
2.3
4
4
6
8
3 Die
3.1
3.2
3.3
3.4
3.5
3.6
Struktur relationaler Datenbanken
Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integritätsbedingungen . . . . . . . . . . . . . . . . . . . . . .
relationale Algebra
Die Selektion . . . . . . . . . . . . . .
Die Projektion . . . . . . . . . . . . .
Die Mengenoperationen . . . . . . . .
Die Umbenennung . . . . . . . . . . .
Das Kreuzprodukt . . . . . . . . . . .
Verbundoperationen . . . . . . . . . .
3.6.1 Beispiel . . . . . . . . . . . . .
3.6.2 Der natürliche Verbund . . . .
3.6.3 Der Theta-Verbund . . . . . .
3.6.4 Äußere Verbunde . . . . . . . .
3.7 Die Division . . . . . . . . . . . . . . .
3.8 Relationale Vollständigkeit . . . . . . .
3.9 Ausdrücke in der relationalen Algebra
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Schlüssel
4.1 Superschlüssel und Identifizierungsschlüssel . . . . . . .
4.2 Primärschlüssel . . . . . . . . . . . . . . . . . . . . . . .
4.3 Fremdschlüssel . . . . . . . . . . . . . . . . . . . . . . .
4.4 Kriterien für die Festlegung von IdentifizierungsPrimärschlüsseln . . . . . . . . . . . . . . . . . . . . . .
4.5 Weitere Schlüsselbegriffe . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
und
. . .
. . .
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
11
12
13
14
16
16
18
22
23
23
27
28
29
30
32
33
34
36
37
37
38
c
2008
Udo Kelter
Stand: 10.11.2008
Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer oder
gedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenommen werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarf
der expliziten Genehmigung. Die jeweils aktuellste Version ist über http://kltr.de erreichbar.
3
Das relationale Datenbankmodell ist eines der drei “konventionellen”
Datenbankmodelle und, gemessen am Entwicklungstempo der Informatik, schon uralt. Es geht auf Arbeiten von E.F. Codd am IBM San
Jose Research Laboratory [Co70] zurück. Seine Entwicklung wurde
maßgeblich von mehreren Prototypen relationaler DBMS beeinflußt,
namentlich dem System R am IBM San Jose Research Laboratory, Ingres an der University of California at Berkeley und Query-by-Example
am IBM T.J. Watson Research Center.
Im Laufe der Jahre wurden sehr umfangreiche formale Grundlagen
des relationalen Datenbankmodells entwickelt, ferner wurden vielfältige Erweiterungen der ursprünglichen Konzepte vorgeschlagen.
In der Praxis ist das relationale Datenbankmodell heute dominierend. Eine Vielzahl kommerzieller oder kostenloser relationaler DBMS
ist verfügbar.
1
Datenbankmodelle vs. reale Datenbanksprachen
Das relationale Datenbankmodell legt zunächst nur zentrale, grundlegende Konzepte fest (s. Begriff Datenbankmodell in [DVS]), nämlich
die Struktur einer Datenbank und lesende Operationen auf dieser
Struktur. Ein praktisch benutzbares System muß zusätzlich viele technische Details festlegen, angefangen bei der Syntax entsprechender
Sprachen und Bedienschnittstellen. Zum Vergleich: das Konzept einer
while-Schleife wird von allen normalen imperativen Programmiersprachen unterstützt, die konkrete Syntax und technische Details können
ganz erheblich differieren (for (..,..,..) { .. } in C; WHILE ...
BEGIN ... END in Modula-2). Neben den Abfragen und Datenänderungen müssen außerdem Funktionen bzw. Sprachkonstrukte zur Definition konzeptueller und interner Schemata, Rechteverwaltung, Administration usw. angeboten werden; das relationale Datenbankmodell
legt diese Bereiche nicht fest. Ähnlich wie Programmiersprachen sind
daher die konkreten Abfragesprachen für relationale Systeme äußerlich sehr verschieden und differieren auch außerhalb der grundlegenden
c
2008
Udo Kelter
Stand: 10.11.2008
4
Konzepte in vielen technischen Details.
Für die Darstellung der grundlegenden Konzepte braucht man
natürlich dennoch Notationen, also eine Sprache. Die relationale Algebra und die relationalen Kalküle kann man in diesem Sinne als Sprachen ansehen, die nur den Kern des relationalen Datenbankmodells
abdecken und von jeglichem störenden Ballast befreit sind.
2
2.1
Die Struktur relationaler Datenbanken
Tabellen
Die statische Struktur einer relationalen Datenbank kann man informell wie folgt definieren (eine präzisere Definition folgt später):
1. Eine relationale Datenbank besteht aus mehreren Tabellen. Jede
Tabelle hat einen eindeutigen Namen.
2. Eine Tabelle hat eine Menge von Spalten.
3. Eine Spalte hat einen eindeutigen Namen, der im Tabellenkopf
steht, und einen zugeordneten Wertebereich. Statt von einer Spalte reden wir auch von einem Attribut.
4. Der Rumpf (oder “Inhalt”) einer Tabelle enthält beliebig viele Zeilen; jede Zeile enthält in jeder Spalte einen Wert entsprechend dem
Wertebereich der Spalte.
Tabelle: kunden
Kundennummer Kundenname
177177
Meier, Anne
177180
Büdenbender, Christa
185432
Stötzel, Gyula
167425
Schneider, Peter
171876
Litt, Michael
Wohnort
Weidenau
Siegen
Siegen
Netphen
Siegen
Kreditlimit
2000.00
9000.00
4000.00
14000.00
0.00
Abbildung 1: Beispieltabelle
c
2008
Udo Kelter
Stand: 10.11.2008
5
Als Beispiel betrachten wir eine Tabelle kunden , in der Daten über
die Kunden eines Unternehmens verwaltet sein mögen (s. Bild 1). Die
Spalte Kreditlimit gibt an, wieviele Waren dem Kunden auf Kredit
geliefert werden. Der Sinn der restlichen Spalten ist offensichtlich. Die
Wertebereiche der Spalten sind (von links nach rechts): 1. ganze Zahl,
2. Text, 3. Text, 4. reelle Zahl. Über Längenbeschränkungen der Texte
oder die Genauigkeit der Zahlen machen wir uns an dieser Stelle keine
Gedanken.
Eine Zeile repräsentiert oft eine Entität in der realen Welt, in unserem Beispiel repräsentiert jede Zeile einen Kunden. Wenn die Tabelle
zwei völlig gleiche Zeilen enthalten würde, wäre der gleiche Sachverhalt
doppelt repräsentiert; dies wäre sinnlos, Duplikate von Zeilen werden
daher nicht erlaubt.
Die Spalten enthalten die Beschreibungsmerkmale der repräsentierten Entität. Interessant ist hier die Beobachtung, daß die Reihenfolge
der Spalten unwesentlich ist, die folgende Tabelle ist zu der vorstehenden offenbar äquivalent:
Tabelle: kunden
Wohnort
Kundennummer
Weidenau 177177
Siegen
177180
...
...
Kundenname
Meier, Anne
...
Kreditlimit
2000.00
9000.00
...
Eine Zeile können wir daher auch als eine Menge von Attributzuweisungen auffassen, z.B. die erste Zeile als:
Kundennummer = 177177; Wohnort = Weidenau; Kundenname =
”Meier, Anne”; Kreditlimit = 2000.00
Während die Reihenfolge der Attribute aus einer konzeptuellen
Sichtweise irrelevant ist, ist sie für die physische Speicherung i.a. relevant. Beide Sichtweisen müssen aber strikt getrennt werden; Datenbankmodelle definieren nur konzeptuelle Aspekte, die physische Speicherung bleibt hier völlig außer Betracht.
c
2008
Udo Kelter
Stand: 10.11.2008
2.2
6
Relationen
Die Bezeichnung “relational” stammt von mathematischen Begriff einer Relation ab. Eine Relation ist in der Mathematik bekanntlich
definiert als Teilmenge des Kreuzprodukts mehrerer Mengen, i.a.:
R ⊆ D1 × D2 × . . . × Dn
Ein Element einer Relation nennt man Tupel. Den Inhalt der letzten
Tabelle könnte man offenbar als folgende Relation ansehen:
kunden ⊆ string × integer × string × real
Tabellen werden oft als Relationen bezeichnet und umgekehrt, es
gibt aber einen signifikanten Unterschied: Relationen haben kein Äquivalent zum Tabellenkopf. Die “Spalten” einer Relation haben keinen
Namen, sie sind nur anhand ihrer Position benennbar, und ihre Bedeutung muß durch eine separate Definition angegeben werden. Letzteres
leistet ein Relationentyp.
Ein Relationentyp (auch als Relationenschema oder Relationenformat bezeichnet) besteht aus:
– einem Namen, der innerhalb einer Datenbank eindeutig ist
– einer Folge von Attributdefinitionen
Notieren werden wir Relationentypen nach folgendem Muster:
Relationentypname = ( . . . , Attributname, . . . )
wenn die Wertebereiche der Attribute schon anderweitig bekannt sind
oder im Moment nicht interessieren, und als
Relationentypname = ( . . . , Attributname: Wertebereich; . . . )
wenn die Wertebereiche angegeben werden sollen. Als Wertebereiche
der Attribute sind nur elementare Datentypen wie integer, real, date,
string usw. zugelassen, nicht hingegen strukturierte Datentypen wie
Arrays, Tupel, Mengen usw. oder gar Relationen1 .
Unsere erste Version der Kundentabelle führt also zu folgendem
Relationentyp:
1
In erweiterten relationalen Modellen, die wir hier nicht behandeln, können Attribute dagegen strukturierte Typen haben.
c
2008
Udo Kelter
Stand: 10.11.2008
7
Kunden = ( Kundennummer: integer;
Kundenname: string;
Wohnort: string;
Kreditlimit: real )
Wir werden einen Relationentyp oft vereinfachend als Menge (und
nicht Folge) von Attributen ansehen und die Schreibweisen A ∈ R bzw.
R1 ⊆ R2 benutzen, um darzustellen, daß das Attribut A im Relationentyp R vorkommt bzw. daß im Relationentyp R1 nur Attribute aus
dem Relationentyp R2 vorkommen.
Da wir hier den Begriff Typ gebrauchen, sei ein Vergleich mit
den Typen in Programmiersprachen gestattet: ein Relationentyp entspricht in etwa einem Datentyp, der als Menge von Objekten (oder
Records) mit den Attributen gemäß dem Relationentyp definiert ist.
Eine Relation kann man in der Denkwelt von Programmiersprachen
als Variable dieses Typs ansehen.
In Datenbanken ist die strikte Trennung zwischen Typ und Variable wenig sinnvoll, weil es zu jedem Relationentyp immer nur eine
Relation gibt. Daher werden dort immer gleich Relationen definiert,
ihr Typ wird nur implizit mitdefiniert und hat keinen Namen. Für die
Erklärung des relationalen Datenbankmodells werden wir allerdings
wiederholt Relationentypen benötigen, so daß wir auf diesen Begriff
nicht verzichten können.
Bzgl. der Schreibweisen werden wir die Konvention einhalten,
– Namen von Relationen klein zu schreiben
– Namen von Relationentypen und Attributmengen groß zu schreiben
Wenn wir festlegen, daß eine Relation r von Relationentyp R sein
soll, ist wegen des Rückgriffs auf den mathematischen Relationsbegriff
implizit klar,
– daß alle Tupel von r insofern korrekt sind, daß die Werte der einzelnen Attribute aus den passenden Wertebereichen stammen, und
c
2008
Udo Kelter
Stand: 10.11.2008
8
– daß keine Tupel in r doppelt vorhanden sind (eine Relation ist eine
Menge und keine Multimenge)2 .
Wir werden i.f. Tabellen als Darstellung von Relationen benutzen
und die beiden Begriffe in diesem Sinne synonym verwenden.
2.3
Integritätsbedingungen
Es gibt sehr viele Arten, Integritätsbedingungen in relationalen Datenbanken zu formulieren; es ist ein bißchen Geschmackssache, wieviele davon man zum “Kern” des relationalen Datenbankmodells zählt.
Man kann die Integritätsbedingungen grob wie folgt einteilen:
– Dynamische Integritätsbedingungen schränken die erlaubten
Zustandsübergänge bei Änderungen der Daten ein. Beispielsweise könnte bei einem Attribut Familienstand der Übergang von
verheiratet nach ledig verboten sein. Dynamische Integritätsbedingungen werden wir nicht weiter betrachten.
– Statische Integritätsbedingungen schränken den erlaubten Zustand einer Datenbank weiter ein. Das bekannteste Beispiel sind
(Identifizierungs-) Schlüssel.
Integritätsbedingungen können allenfalls bei Änderungen an den
Daten verletzt werden. Ein DBMS muß daher bei allen ändernden
Operationen entsprechende Prüfungen durchführen und die Operation
ggf. mit einem Fehlercode zurückweisen.
Lesende Operationen sind dagegen überhaupt nicht von Integritätsbedingungen betroffen: diese Operationen arbeiten auf beliebigen Datenbankinhalten, also erst recht auf der Teilmenge der “korrekten”
Datenbankinhalte. Aus diesem Grunde sind Integritätsbedingungen
für die nachfolgende Diskussion der relationalen Algebra nicht erforderlich.
2
Technisch wäre es kein Problem, auch Multimengen zuzulassen. In der Praxis erspart man sich aus Performancegründen oft die Eliminierung von Duplikaten.
Wie schon erwähnt sind aber Duplikate von Tupeln i.a. nicht sinnvoll.
c
2008
Udo Kelter
Stand: 10.11.2008
3
9
Die relationale Algebra
Der Begriff Algebra stammt aus der Mathematik. Eine Algebra ist
definiert durch eine Wertemenge3 und i.a. mehrere Funktionen, die
mit Werten dieser Menge arbeiten. Beispiele für Algebren sind die
reellen Zahlen oder Matrizen zusammen mit den diversen Rechenoperationen. Die Funktionen können beliebig viele Argumente haben und
liefern stets einen Wert aus der Wertemenge zurück. Daher kann man
Funktionsaufrufe schachteln und Ausdrücke konstruieren.
Die relationale Algebra ist eine ganz normale Algebra im vorstehenden Sinn. Als Werte benutzen wir beliebige Relationen. Daß
die entstehende Wertemenge recht groß ist und ganze Relationen als
Argumente oder Resultate etwas schwergewichtig erscheinen mögen,
braucht uns nicht weiter zu stören.
Die relationale Algebra enthält keine Operationen, mit denen man
Relationen erzeugen bzw. löschen und in einer Relation Tupel einfügen,
löschen oder verändern kann. Derartige Operationen müssen in realen Sprachen natürlich vorhanden sein; die relationale Algebra konzentriert sich ausschließlich auf die “lesenden” Operationen und die
Frage, welche Daten man aus einer vorhandenen Datenbank extrahieren kann. Es wird vorausgesetzt, daß die Relationen der Datenbank
schon irgendwie existieren und mit Tupeln gefüllt worden sind. Analog gilt dies für die Relationentypen, also das konzeptuelle Schema der
Datenbank.
Die Operationen der relationalen Algebra entsprechen nicht unzufällig den typischen Aufgaben, die beim Umgang mit Datenbanken
in der Praxis auftreten. Wir stellen sie anschließend einzeln vor.
3.1
Die Selektion
Die Selektion erlaubt es, aus einer vorhandenen Relation r bestimmte
Tupel zu selektieren. Zurückgeliefert wird eine neue Relation, die nur
3
Dies gilt für eine einsortige Algebra. Mehrsortige Algebren arbeiten mit mehreren Wertemengen, die hier als Sorten bezeichnet werden.
c
2008
Udo Kelter
Stand: 10.11.2008
10
die Tupel enthält, die das Selektionskriterium erfüllen. Notiert wird
die Selektion üblicherweise in der Form
σBedingung ( r )
Der griechische Buchstabe sigma (σ) erinnert an das S im Wort Selektion. Das Ergebnis einer Selektion hat den gleichen Relationentyp wie
die Argumentrelation.
Als Beispiel betrachten wir die Menge der Kunden aus der Relation
kunden in Bild 1, deren Kreditlimit größer als 5000 DM ist. Folgender
Ausdruck liefert eine Relation mit genau diesen Kunden:
σKreditlimit>5000.00 ( kunden )
Die entstehende Tabelle ist
Tabelle: σKreditlimit>5000.00 ( kunden )
Kundennummer Kundenname
177180
167425
Schneider, Peter
Wohnort
Siegen
Netphen
Kreditlimit
9000.00
14000.00
Im vorstehenden Beispiel trat nur eine sehr einfache Selektionsbedingung auf, die den Wert eines Attributs mit einer Konstanten
verglich. Neben > sind auch die Vergleichsoperatoren <, ≤, ≥, = und
6= möglich. Ferner können so geformte elementare Bedingungen mit
den Booleschen Operatoren (∧, ∨, ¬) und Klammern zu Ausdrücken
zusammengesetzt werden. Die Bedingungen dürfen sich natürlich nur
auf solche Attribute beziehen, die im Typ der Argumentrelation vorkommen.
Übungsaufgabe: Zeigen Sie, daß die und-Verküpfung von zwei Bedingungen durch eine Hintereinanderschaltung von zwei Selektionen
mit den einzelnen Bedingungen ersetzt werden kann, daß also für eine
beliebige Relation r und Bedingungen B1 und B2 gilt:
σB1∧B2 ( r ) = σB1 (σB2 ( r )) = σB2 (σB1 ( r ))
c
2008
Udo Kelter
Stand: 10.11.2008
3.2
11
Die Projektion
Die Projektion löst das Problem, überflüssige Attribute in den Tupeln
einer Relation zu entfernen. Man projiziert eine Relation auf die Attribute, die man noch beibehalten möchte. Notiert wird die Projektion
üblicherweise in der Form
πAttributmenge ( r )
Der griechische Buchstabe pi (π) erinnert an das Wort Projektion.
Als Beispiel betrachten wir wieder die Relation kunden in Bild
1. Wir möchten jetzt nur noch Kundenname und Wohnort haben, die
beiden anderen Attribute bzw. Spalten sollen “wegprojiziert” werden.
Dies erreichen wir mit folgender Ausdruck:
πKundenname,Wohnort ( kunden )
Die entstehende Tabelle ist:
Tabelle: πKundenname,Wohnort ( kunden )
Kundenname
Wohnort
Meier, Anne
Weidenau
Büdenbender, Christa Siegen
Stötzel, Gyula
Siegen
Schneider, Peter
Netphen
Litt, Michael
Siegen
Das Ergebnis einer Projektion hat i.a. nicht den gleichen Relationentyp wie die Argumentrelation4 . Der Typ der Ergebnisrelation hat
genau die in der Projektion angegebenen Attribute.
Für die formale Definition der Projektion benötigen wir folgende
neue Notation: Sei r eine Relation mit Relationentyp R , t ein Tupel
in r , also t ∈ r , A ⊆ R eine nichtleere Teilmenge der Attribute in
R . Dann bezeichnet t[A] das Tupel, das die Attributwerte für die Attribute in A gemäß t enthält. Mit dieser Notation können wir das
Ergebnis einer Projektion wie folgt definieren:
4
Eine Ausnahme ist lediglich der wenig sinnvolle Sonderfall, daß man auf alle
Attribute der Argumentrelation projiziert.
c
2008
Udo Kelter
Stand: 10.11.2008
12
πA (r) = { t[A] | t ∈ r }
Im vorigen Beispiel hat die Ergebnisrelation genausoviele Tupel
wie die Argumentrelation. Dies ist nicht immer der Fall, wie folgendes
Beispiel zeigt:
πWohnort ( kunden )
Die entstehende Tabelle ist:
Tabelle: πWohnort ( kunden )
Wohnort
Weidenau
Siegen
Netphen
Sie hat nur noch 3 Tupel, denn in der Spalte Wohnort treten nur
3 verschiedene Werte auf. Man betrachte noch einmal die obige Definition der Projektion: πA (r) ist als Menge, nicht als Multimenge
definiert. Zwei verschiedene Tupel t1 , t2 ∈ R , t1 6= t2 , können nach der
Projektion gleich sein und führen daher nur zu einem einzigen Tupel
in der Ergebnisrelation.
Übungsaufgabe: Seien P , Q und R Relationentypen, r eine Relation vom Typ R . Zeigen Sie, daß folgendes gilt:
P ⊆ Q ⊆ R
3.3
⇒
π P (π Q ( r )) = π P ( r )
Die Mengenoperationen
Da Relationen als Mengen von Tupeln definiert sind, sind automatisch
alle Mengenoperationen auf Relationen anwendbar. Voraussetzung ist
natürlich, daß die beteiligten Relationen den gleichen Relationentyp
haben.
Wenn also r1 und r2 Relation vom Typ R sind, dann ist
r1 ∪ r2 die Vereinigung
r1 ∩ r2 der Schnitt
r1 − r2 die Differenz
von r1 und r2 . Das Ergebnis hat wieder den Relationentyp R .
c
2008
Udo Kelter
Stand: 10.11.2008
13
Als Beispiel betrachten wir wieder die Relation kunden in Bild 1.
Wir suchen jetzt die Kunden, die in Weidenau wohnen oder ein Kreditlimit > 10000 haben. Hierzu definieren wir die Relation k1 wie
folgt:
k1 = σWohnort=“W eidenau′′ ( kunden ) ∪ σKreditlimit=10000 ( kunden )
Das Ergebnis ist:
Tabelle: k1
Kundennummer
177177
167425
Kundenname
Meier, Anne
Schneider, Peter
Wohnort
Weidenau
Netphen
Kreditlimit
2000.00
14000.00
Wir hätten dieses Ergebnis natürlich auch mit der folgenden Definition erzielen können;
k1 = σWohnort=“W eidenau′′ ∨ Kreditlimit=10000 ( kunden )
Übungsaufgabe: Zeigen Sie, daß die oder-Verküpfung von zwei Bedingungen durch eine Vereinigung von zwei Selektionen mit den einzelnen Bedingungen ersetzt werden kann, daß also für eine beliebige
Relation r und Bedingungen B1 und B2 gilt:
σB1∨B2 ( r ) = σB1 ( r ) ∪ σB2 ( r )
3.4
Die Umbenennung
Aus technischen Gründen benötigen wir für die folgenden Operationen
eine Hilfsoperation, mit der man Attribute umbenennen kann. Sei r
eine Relation vom Typ R und A ∈ R , B ∈
/ R . Dann ist
ρA →B (r )
eine Relation mit dem gleichen “Inhalt” wie r , aber einem Typ, bei
den das Attribut A in B umbenannt worden ist5 . Der Buchstabe rho
5
Diese Definition ist formal nicht sauber, sollte aber dennoch präzise verständlich
sein. Eine formal saubere Definition bedingt einen wesentlich höheren notationellen
Aufwand; Tupel müssen dann als Abbildungen von Mengen von Attributnamen in
Mengen von Wertemengen definiert werden (wie z.B. in [Vo99]). Da dieser nota-
c
2008
Udo Kelter
Stand: 10.11.2008
14
(ρ) erinnert an rename. Der Typ der Ergebnisrelation ist, als Attributmenge aufgefaßt, gleich ( R − { A }) ∪ { B }.
Wir wenden die Umbenennungsoperation auch auf Relationennamen an. Sei r eine Relation vom Typ R , s ein Name, der bisher keine
Relation benennt, dann ist
ρs (r )
eine Relation namens s mit Typ R und dem gleichen Inhalt wie r .
3.5
Das Kreuzprodukt
Eine sehr häufige praktische Aufgabe besteht darin, Tupel aus verschiedenen Relationen zu neuen Tupeln zu “verbinden”; Beispiele werden wir erst später besprechen.
Das Verbinden von Einzelelementen zu einem Tupel ist durch das
mathematische Kreuzprodukt hinlänglich bekannt und wurde bereits
beim Relationsbegriff ausgenutzt. Es liegt nahe, statt einzelner Wertebereiche auch ganze Relationen durch das mathematische Kreuzprodukt zu verbinden. Seien also r1 , . . . , rn Relationen, dann können
wir folgendes mathematische Kreuzprodukt bilden:
r1 × ... × rn
Dies ist aber leider keine Relation im Sinne der relationalen Algebra:
Ein Tupel in diesem Kreuzprodukt hat die Form
(t1 , . . . , tn )
wobei ti ein Tupel aus Ri ist; als Elemente relationaler Tupel sind
aber nur elementare Datentypen zugelassen. Wir hätten auch ein Problem, den Relationentyp dieses Kreuzprodukts zu benennen.
Ein Lösungsansatz besteht darin, die Tupel ti , ..., tn zu “konkatenieren”, also ein einziges neues Tupel zu bilden. Diese Idee funktioniert aber nur dann, wenn keine Attributnamen doppelt auftreten, also wenn die Typen der beteiligten Relationen paarweise disjunkt sind.
tionelle Aufwand keinen signifikanten Gewinn an Präzision bringt, andererseits der
intuitiven Verständlichkeit abträglich ist, wird er hier vermieden.
c
2008
Udo Kelter
Stand: 10.11.2008
15
Unter dieser Annahme können wir das relationale Kreuzprodukt
folgendermaßen definieren:
r 1 × . . . × r n = { < t1 | . . . | tn > | t i ∈ r i }
Darin ist < t1 | . . . | tn > die Konkatenation der einzelnen Tupel. Der
Typ des Kreuzprodukts ist die Vereinigung der Ri , 1 ≤ i ≤ n.
Die Bildung eines Kreuzprodukts veranschaulicht Bild 2 am Beispiel zweier Relationen, die 3 bzw. 2 Tupel enthalten; der Aufbau der
Tupel interessiert hier nicht, der Inhalt ist mit “aa”, “bb” usw. nur
angedeutet.
aa
bb
cc
aa
aa
X
xx
yy
=
bb
bb
cc
cc
xx
yy
xx
yy
xx
yy
Abbildung 2: Beispiel eines Kreuzprodukts
Da jedes Tupel der ersten Relation mit jedem Tupel der zweiten
kombiniert wird, gilt folgende Formel:
| r×s |=| r | ∗| s |
worin | r | die Anzahl ihrer Tupel einer Relation r bezeichnet.
Die “Länge” der Ergebnistupel (gemessen in der Zahl der Attribute) ist gleich der Summe der Längen der Argumenttupel. Bei der
Kreuzproduktbildung entstehen also sehr viele und lange Tupel6 .
Wir hatten unser relationales Kreuzprodukt bisher nur unter der
Annahme definieren können, daß die Typen der beteiligten Relationen paarweise disjunkt sind; diese Annahme ist natürlich nicht immer
6
Deshalb wird das Kreuzprodukt in der Praxis auch fast nie wirklich berechnet.
Im Rahmen der Optimierung werden Kreuzprodukte, die in einer vorgegebenen
Abfrage auftreten, praktisch immer zu Verbundoperationen umgeformt; letztere
lassen sich meist effizient berechnen. Mit relationalen Abfragesprachen kann man
(bzw. sollte man oft sogar) Abfragen formulieren, die auf den ersten Blick extrem
ineffizient aussehen. Wir gehen hierauf in Abschnitt 3.9 noch näher ein.
c
2008
Udo Kelter
Stand: 10.11.2008
16
erfüllt. Die Lösung besteht darin, die Attribute, die in mehr als einer
Relation auftreten, automatisch umzubenennen. Sei A ein solches Attribut; dann wird A in jeder Relation ri , in deren Typ A vorkommt, zu
ri . A umbenannt, d.h. wir führen innerhalb der Operationsausführung
und vor der eigentlichen Bildung des Kreuzprodukts die Umbenennung
ρ A → r i. A ( r i)
durch. Unter der Annahme, daß die Namen aller ri verschieden sind,
sind anschließend alle Attributnamen eindeutig.
Natürlich können die betroffenen Attribute auch explizit vor der
Bildung des Kreuzprodukts umbenannt werden, wenn die automatische (implizite) Umbenennung im Einzelfall unpassend ist.
Gelegentlich will man auch das Kreuzprodukt einer Relation mit
sich selbst bilden. Dies verbieten wir hier und verlangen, daß in solchen
Fällen zunächst explizit eine der Relationen umbenannt wird, so daß
letztlich alle involvierten Relationen eindeutige Namen bekommen.
3.6
3.6.1
Verbundoperationen
Beispiel
Wir betrachten nun das schon angekündigte Beispiel, bei dem Daten,
die in verschiedenen Relationen stehen, zusammenzuführen sind. Wir
führen hierzu eine weitere Relation lieferungen ein, die folgenden
Relationentyp hat:
Lieferungen = ( Datum: date;
Wert: real;
Kundennummer: integer;
Lager: string;
Lieferadresse: string )
Ein Tupel dieses Typs zeigt an, daß am angegebenen Datum Waren im
angegebenen Gesamtwert an den Kunden, der durch die Kundennummer
identifiziert wird, geliefert worden sind, und zwar vom angegebenen
Lager aus an die angegebene Lieferadresse. Der Inhalt der Relation
lieferungen sei wie in Bild 3 angegeben.
c
2008
Udo Kelter
Stand: 10.11.2008
Tabelle: lieferungen
Datum
Wert
Kundennummer
00-08-12 2730.00
167425
00-08-14
427.50
167425
00-08-02 1233.00
171876
17
Lager
Mitte
Nord
West
Lieferadresse
Bahnhofstr. 5
Luisenstr. 13
Bergstr. 33
Abbildung 3: Beispieltabelle für Lieferungen
Wir wollen nun eine Relation erzeugen (und anzeigen oder ausdrucken), in der für alle Lieferungen Datum, Wert und der Name des
Kunden angezeigt werden. Den Namen des Kunden mit einer gegebenen Kundennummer können wir anhand der Relation kunden herausfinden. Wir können das gesuchte Resultat in mehreren Schritten wie
folgt konstruieren:
1. Wir müssen Daten aus verschiedenen Relationen in einzelnen Tupeln zusammenbringen. Der einzige Operator, der dies leistet, ist
das relationale Kreuzprodukt. Wir bilden also zuerst das Kreuzprodukt von lieferungen und kunden :
r1 = lieferungen × kunden
Dieser erste Schritt kann im Prinzip ein extrem großes Zwischenergebnis erzeugen. Dies braucht uns aber nicht zu stören, wie wir
später sehen werden, wird dieses Zwischenergebnis infolge interner
Optimierungen nicht wirklich erzeugt.
Die beiden Relationen haben das Attribut Kundennummer gemeinsam. Gemäß der definierten Funktionsweise des Kreuzprodukts ist dieses Attribut automatisch in lieferungen.Kundennummer bzw. kunden.Kundennummer umbenannt worden.
2. In r1 ist jedes Lieferungstupel mit jedem Kundentupel kombiniert worden. Die meisten dieser Kombinationen sind für unseren
Zweck unsinnig und daher überflüssig; wir interessieren uns nur für
die Kombinationen, bei denen lieferungen.Kundennummer und
kunden.Kundennummer den gleichen Wert haben, denn nur hier
sind die richtigen Kundendaten und Lieferungsdaten kombiniert.
c
2008
Udo Kelter
Stand: 10.11.2008
18
Wir bilden also
r2 = σ lieferungen.Kundennummer = kunden.Kundennummer ( r1 )
3. In r2 sind die Spalten lieferungen.Kundennummer und kunden.Kundennummer identisch: dies war gerade die Selektionsbedingung. Eine der beiden Spalten ist offensichtlich entbehrlich und
kann entfernt werden. Der lange Attributname der verbliebenen
Spalte ist dann nicht mehr notwendig, wir können einfacher wieder
den ursprünglichen Namen verwenden. Wir gehen nun so vor, daß
wir zuerst eine der Spalten in den ursprünglichen Namen umbenennen:
r3 = ρlieferungen.Kundennummer→Kundennummer ( r2 )
4. Die überflüssige Spalte mit dem langen Namen können wir nun
entfernen, indem wir einfach auf die Vereinigung der beiden Relationentypen projizieren:
r4 = πLieferungen ∪ Kunden ( r3 )
5. Zum Schluß entfernen wir noch die nicht benötigten Attribute; gefragt war nur nach dem Datum, Wert und Kundennamen:
r5 = πDatum,Wert,Kundenname ( r4 )
Unser Endresultat sieht folgendermaßen aus:
Tabelle: r5
Datum
Wert
00-08-12 2730.00
00-08-14
427.50
00-08-02 1233.00
3.6.2
Kundenname
Schneider, Peter
Schneider, Peter
Litt, Michael
Der natürliche Verbund
Das vorige Beispiel weist eine sehr häufig auftretende Problemstruktur auf: die Werte in der Spalte Kundennummer in der Relation
c
2008
Udo Kelter
Stand: 10.11.2008
19
lieferungen kann man als “Referenzen” auf Tupel in der Relation kunden ansehen7 . Unsere Absicht war es, zu jedem Tupel in
lieferungen die dort stehende Referenz auf ein Kundentupel zu verfolgen und Daten aus diesem Kundentupel hinten an das Lieferungstupel anzuhängen - so hätte man es auch von Hand gemacht (s. auch
Bild 4). Letztlich verbinden wir solche Paare von Lieferungstupel und
Kundentupel, die im gemeinsamen Attribut Kundennummer den gleichen Wert haben.
.....
177180 .....
.....
177180 .....
177180
1111
0000
0000
1111
1111
0000
0000
1111
Abbildung 4: Auflösung einer “Referenz”
Der natürliche Verbund (natural join) verallgemeinert diesen
Vorgang; er faßt die obigen Schritte 1 bis 4 zu einer einzigen Operation zusammen. Sie wird mit dem Zeichen 1 notiert. Mit Hilfe
des natürlichen Verbunds können wir das Beispiel in Abschnitt 3.6.1
wesentlich einfacher lösen, und zwar wie folgt:
πDatum,Wert,Kundenname ( lieferungen 1 kunden )
Definition: Gegeben seien zwei Relationen r und s mit den Relationentypen R bzw. S .
Sei V = R ∩ S die Menge der Verbundattribute. Es kann beliebig
viele Verbundattribute geben, i.a. ist also V = {v1 ,...,vn}.
Dann ist:
r 1 s = π R ∪ S (ρ r.V → V (σ r.V=s.V ( r × s )))
7
Die Denkweise in Referenzen unterstellt, daß die Kundennummern in der Relation kunden eindeutig sind, daß also eine bestimmte Kundennummer höchstens
einmal in der Spalte Kundennummer in der Relation kunden auftritt. Dies trifft in
der Praxis auf fast allen Verbundbildungen zu, ist aber nicht zwingend erforderlich.
c
2008
Udo Kelter
Stand: 10.11.2008
20
Die Schreibweise σ r.V=s.V ist eine Kurzform von
σr.v1 =s.v1 ∧ ... ∧ r.vn =s.vn
Es werden also nur solche Tupel verbunden, die in allen Verbundattributen übereinstimmen.
Die Schreibweise ρ r.V → V (...) ist eine Kurzform für
ρr.v1 →v1 (. . . (ρr.vn →vn (...)) . . .)
In dem Sonderfall, daß R und S disjunkt sind, also V die leere
Menge ist, ist im obigen Ausdruck die Selektionsbedingung leer, d.h.
die selektierten Tupel müssen keine Bedingung erfüllen, es wird also
nichts weggefiltert. Bei V = ∅ bilden auch die darauf folgende Projektion und die Umbenennung ihre Argumente identisch ab, der natürliche
Verbund verhält sich dann also wie das Kreuzprodukt.
Wie schon oben erwähnt ist es nicht zulässig, das Kreuzprodukt
einer Relation mit sich selbst zu bilden, stattdessen muß wenigstens
eine der Relationen vorher umbenannt werden. Dies gilt auch für den
natürlichen Verbund. Wenn man dies tut, also z.B.
r 1 ρs (r )
bildet, erhält man als Ergebnis genau r (s. folgende Übungsaufgaben), d.h. ein Verbund einer Relation mit sich selbst ist überflüssig.
Übungsaufgabe: Zeigen Sie, daß der natürliche Verbund eine kommutative Operation ist, d.h. für beliebige Relationen (oder besser gesagt Tabellen) r und s gilt:
r 1 s = s 1 r
Übungsaufgabe: Zeigen Sie, daß der natürliche Verbund eine assoziative Operation ist, d.h. für beliebige Relationen r , s und t gilt:
(r 1 s ) 1 t = r 1 (s 1 t )
Übungsaufgabe: Zeigen Sie, daß im Sonderfall R = S der Verbund
den Durchschnitt der beiden Relationen bildet, also:
R = S ⇒ r 1 s = r∩s
c
2008
Udo Kelter
Stand: 10.11.2008
21
Übungsaufgabe: Berechnen Sie unter Nutzung des Ergebnisses der
vorigen Übungsaufgabe r 1 ρ s ( r ).
Verbundpartner. Eine sehr simpler Algorithmus zur Implementierung des Verbunds r 1 s besteht darin, alle Tupel t ∈ r zu durchlaufen, für jedes t dessen Verbundpartner in s zu suchen und pro
Verbundpartner u ein Ergebnistupel auszugeben, das Attributwerte
gemäß t und u enthält. Verbundpartner von t sind diejenigen Tupel
u ∈ s , für die gilt: u [V] = t [V] . Diese Menge können wir auch als
Abfrage formulieren:
σu[V ]=t[V ] ( s )
Häufige Denkfehler. Das obige Beispiel, in dem wir den Verbund
der Relationen lieferungen und kunden gebildet haben, enthält
Merkmale, die in der Praxis sehr häufig auftreten. Diese Merkmale
werden sehr leicht irrtümlich zu notwendigen Voraussetzungen erklärt
oder falsch interpretiert; die häufigsten Denkfehler in diesem Zusammenhang sind:
1. Denkfehler: Im Beispiel und in ca. 99 % aller praktischen Fälle
hat man genau ein Verbundattribut. Dies wird oft fälschlicherweise als Voraussetzung angesehen! Der Verbund ist für beliebig viele
Verbundattribute definiert, auch für V = ∅!
2. Denkfehler: Wenn keine Verbundattribute vorhanden sind, also
V = ∅, dann findet ein Tupel in r scheinbar keine Verbundpartner
in s , also ist r 1 s = ∅. Dies ist falsch.
Wenn V = ∅, dann ist die Menge der Verbundpartner von t,
wie oben definiert, σu[∅]=t[∅] ( s ). Darin verstehen wir u[∅] als “leeres Tupel mit 0 Attributen”. Offensichtlich ist damit die Bedingung u[∅] = t[∅] für jedes beliebige u erfüllt, d.h. in Wirklichkeit
sind für ein beliebiges t ∈ r alle u ∈ s Verbundpartner, und
r 1 s = r × s.
3. Denkfehler: Im obigen Beispiel und in fast allen praktischen Fällen
ist das Verbundattribut in einer der beiden Relationen eindeutig.
Dies haben wir auch unterstellt, als wir oben die Kundennummern
c
2008
Udo Kelter
Stand: 10.11.2008
22
in der Relation lieferungen als “Referenzen” auf genau ein Tupel
in kunden interpretiert haben. Diese Eindeutigkeit ist aber nicht
notwendig. Wie schon bei der Definition des Begriffs Verbundpartner gesehen kann ein t ∈ r beliebig viele Verbundpartner in s
haben.
3.6.3
Der Theta-Verbund
Beim natürlichen Verbund wurden bei der Prüfung, ob ein Paar von
Tupeln verbunden werden soll,
– der Vergleichsoperator = benutzt, und
– es wurde jeweils das gleiche Attribut in beiden Tupeln für den Vergleich herangezogen.
Dies wird beim Θ- (Theta-) Verbund dahingehend verallgemeinert,
– daß irgendein Vergleichsoperator Θ ∈ {=, 6=, <, ≤, >, ≥} benutzt
wird und
– daß unterschiedliche Attribute in beiden Tupeln für den Vergleich
herangezogen werden.
Wenn r und s Relationen vom Typ R bzw. S sind und A ∈ R und B
∈ S Attribute mit gleichen Wertebereich, dann ist ein Theta-Verbund
wie folgt definiert:
r 1r.A Θ s.B s := σr.A Θ s.B ( r × s )
Man kann geteilter Meinung darüber sein, ob der Theta-Verbund viel
einbringt; eine wesentliche Ersparnis an Schreibarbeit und ein dementsprechender Gewinn an Übersichtlichkeit der Ausdrücke – die ein
großer Vorteil des natürlichen Verbundes sind – tritt hier jedenfalls
nicht ein.
Ein Gleichheitsverbund (equi-join) ist ein Theta-Verbund mit
dem Vergleichsoperator =.
c
2008
Udo Kelter
Stand: 10.11.2008
3.6.4
23
Äußere Verbunde
Wir betrachten noch einmal das Beispiel in Abschnitt 3.6.1 und nehmen an, in der Relation kunden sei das Tupel mit der Kundennummer
167425 gelöscht worden. Wenn wir jetzt wieder den Verbund
lieferungen 1 kunden
bilden, würden die beiden ersten Tupel in der Relation lieferungen
(s. Bild 3) keinen Verbundpartner mehr finden und dementsprechend
herausfallen. Dies ist aber oft nicht erwünscht. Wenn der Kundenname nicht ermittelt werden kann, sollte der Sachverhalt, daß der Wert
unbekannt ist, angezeigt werden, etwa in folgender Form:
Datum
Wert
00-08-12
00-08-14
00-08-02
2730.00
427.50
1233.00
Kundennummer
167425
167425
171876
Lieferadresse
Kundenname
Bahnhofstr. 5
Luisenstr. 13
Bergstr. 33
NULL
NULL
Litt, Michael
Der Text NULL soll einen Nullwert darstellen; dieser drückt aus,
daß der tatsächliche Attributwert unbekannt ist.
In der vorstehende Tabelle haben wir bei den Tupeln aus lieferungen (also dem linken Verbundargument), die keinen Verbundpartner gefunden haben, einen künstlichen Verbundpartner benutzt. Diese
Art von Verbund nennt man linken äußeren Verbund.
Analog wird beim rechten äußeren Verbund für Tupel des rechten Verbundarguments ggf. ein künstlicher Verbundpartner benutzt.
Der äußere Verbund ist die Vereinigung von linkem und rechtem
äußeren Verbund.
3.7
Die Division
Das Kreuzprodukt ist in gewisser Weise vergleichbar mit einer Multiplikation; im Kreuzprodukt r × s wird jedes Tupel aus r mit jedem
Tupel aus s kombiniert (s. auch Bild 2). Die relationale Division kann
man sich als eine Art inverse Operation zum Kreuzprodukt vorstellen.
c
2008
Udo Kelter
Stand: 10.11.2008
24
Hierzu betrachten wir das Beispiel in Bild 2 noch einmal genauer. Jedes der Tupel “aa”, “bb” und “cc” der linken Relation führt zu
einem eigenen Abschnitt im Ergebnis (in Bild 2 jeweils durch einen
kleinen Zwischenraum abgesetzt): die linken Hälften der Tupel eines
Abschnitts enthalten alle das gleiche, z.B. “aa”, die schattiert dargestellten rechten Hälften bilden eine Kopie der rechten Argumentrelation. Diese rechte Hälfte eines Abschnitts wiederholt sich wie ein
Stempelabdruck immer wieder.
Bei der Umkehrung der Kreuzproduktbildung suchen wir sozusagen nach Stempelabdrücken (s. Bild 5):
bb
bb
cc
cc
cc
xx
yy
xx
zz
xx
yy
zz
dd
xx
aa
aa
:
xx
yy
=
aa
cc
Abbildung 5: relationale Division
– Dividend ist eine Relation x vom Typ X ;
– Divisor ist eine Tupelmenge in einer Teilmenge der Spalten, aufgefaßt als Relation s vom Typ S (der “Stempel”)
– im Quotienten enthalten sind solche Tupel aus den restlichen Spalten von x , die mit allen Tupeln des Divisors kombiniert auftreten
Im Beispiel in Bild 5 besteht der Stempel aus den Tupeln “xx”
und “yy”. Für “aa” ist ein kompletter Stempelabdruck vorhanden,
für “bb” und “dd” nur ein unvollständiger, “bb” und “dd” sind daher
nicht im Ergebnis enthalten. Die Tupel “bb/xx” und “dd/xx” tragen
somit nicht zum Ergebnis bei, ebenfalls nicht das Tupel “bb/zz”, da
“zz” nicht im Divisor auftritt. Die relationale Division ähnelt insofern
der ganzzahligen Division ohne Rest. Wegen dieses Rests erhält man,
wenn man den Quotienten wieder mit dem Divisor multipliziert, i.a.
nur noch eine Teilmenge des ursprünglichen Dividenden:
c
2008
Udo Kelter
Stand: 10.11.2008
25
(x ÷ s ) × s ⊆ x
Formal definiert ist die Division wie folgt: Gegeben sei
– eine Relation x vom Typ X (der Dividend)
– eine Relation s vom Typ S (der Divisor),
wobei ∅ =
6 S und S ⊂ X sein muß. Sei R = X − S . Dann ist
x ÷ s = { t | t ∈ π R ( x ) ∧ {t} × s ⊆ x }
Das Ergebnis ist eine Relation vom Typ R . Ein Tupel t ist genau
dann im Ergebnis enthalten, wenn {t} × s ⊆ x , also wenn für alle
t’ ∈ s gilt: < t | t′ > ∈ x . Bildlich gesprochen enthält das Ergebnis
diejenigen “linken Hälften” von Tupeln aus x , die mit allen “rechten
Hälften” aus s kombiniert in x auftreten.
Anwendungsbeispiel. Als Anwendungsbeispiel für die Division betrachten wir eine Relation konten , die Angaben zu den Konten einer
Bank enthält und die folgenden Relationentyp hat:
Konten = ( Kontonummer: integer;
Kundennummer: integer;
Filialenname: string )
Der Filialenname gibt den Namen der Filiale an, bei der das Konto geführt wird. Ein Kunde kann bei jeder Filiale eine oder mehrere
Konten haben. Gesucht sind nun die Kunden, die bei allen Filialen
wenigstens ein Konto haben. Für die Lösung unserer Aufgabe bilden
wir zunächst die Relation
kundeFiliale = πKundennummer,Filialenname ( konten )
Diese enthält genau dann ein Tupel < k, f >, wenn der Kunde k wenigstens ein Konto in der Filiale f hat. Die Liste aller Filialen erhalten
wir als eine 1-spaltige Tabelle mittels:
filialen = πFilialenname ( kundeFiliale )
Die Kunden, die in jeder Filiale ein Konto haben, erhalten wir nunmehr durch:
c
2008
Udo Kelter
Stand: 10.11.2008
26
kundeFiliale ÷ filialen
Das Typische an unserem Anwendungsbeispiel war, daß ein allQuantor bei der Beschreibung der gesuchten Daten benutzt wurde
(“Kunden, die bei allen Filialen ein Konto haben”). Für derart spezifizierte Suchergebnisse kann man generell die Division einsetzen. In
den Selektionsbedingungen einer Selektion ist ein all-Quantor nicht
erlaubt; die Division bietet daher einen Ersatz. Ein Ersatz für den
Existenz-Quantor ist nicht notwendig, denn dieser wird implizit durch
die Selektion realisiert.
Berechnung von x ÷ s : x ÷ s kann direkt durch Ausnutzung der
Definition algorithmisch berechnet werden:
– Man bildet π R ( x ) als die Menge der Kandidaten, die im Ergebnis
enthalten sein könnten.
– Für jedes t ∈ π R ( x ) prüft man, ob {t} × s ⊆ x . Falls ja, kommt
t in die Ergebnismenge.
Die Division ist aber auch, was man spontan vielleicht nicht erwarten würde, zurückführbar auf die früher definierten Operationen. Zu
berechnen sei also x ÷ s . Sei R = X − S und
r = πR (x )
r enthält alle “Kandidaten”, die im Ergebnis sein könnten. r ist i.a.
eine Obermenge von x ÷ s , denn r kann Tupel enthalten, für die
{t} × s ⊆ x nicht gilt. Um diese Tupel (“durchgefallene Kandidaten”) zu finden, benutzen wir einen Trick: Wir bilden zunächst die
Relation r × s . Sei nun
inv = ( r × s ) − x
inv ist die Invertierung von x in r × s . Wir betrachten den Inhalt
von inv an einem Auszug unseres Beispiels aus Bild 5. Wir können
hier 2 Fälle unterscheiden, die in Bild 6 veranschaulicht sind:
1. Für den Kandidaten t = “aa” sind alle Kombinationen mit den
Tupels des Divisors in x vorhanden und es gilt: {t} × s ⊆ x .
c
2008
Udo Kelter
Stand: 10.11.2008
(r x s)
aa
aa
bb
bb
xx
yy
xx
yy
27
x
(r x s) − x
aa
aa
bb
xx
yy
xx
bb
zz
bb
yy
Abbildung 6: relationale Division
inv enthält daher kein Tupel der Form “aa/...”, weil alle derartigen Tupel aus r × s auch in x vorhanden sind und somit
abgezogen wurden.
2. Für den Kandidaten t = “bb” sind nicht alle Kombinationen mit
den Tupels des Divisors vorhanden und es gilt: {t} × s 6⊆ x .
In inv bleiben daher wenigstens eine der fehlenden Kombinationen übrig. Wenn wir nun noch auf R projizieren, haben wir einen
“durchgefallenen Kandidaten” gefunden.
Die Tupel in π R ( inv ) sind somit gerade diejenigen, die in r zuviel
sind. Unser Endresultat ist also
x ÷ s = r − π R ( inv )
x ÷ s = π R ( x ) − π R ((π R ( x ) × s ) − x )
bzw.
3.8
Relationale Vollständigkeit
Wir haben inzwischen eine Reihe von Operationen mit Relationen
kennengelernt und schon bei den relativ komplizierten Verbundoperationen und der Division bemerkt, daß wir sie auf die einfacheren
Operationen
σ, π, ρ, ∪, −, ×
zurückführen konnten. Die Verbundoperationen und die Division
mögen zwar die Formulierung mancher Abfragen erleichtern, sie erweitern die Fähigkeiten der relationalen Algebra aber nicht wirklich,
c
2008
Udo Kelter
Stand: 10.11.2008
28
d.h. es gibt kein Suchproblem, das nur mit ihrer Hilfe lösbar wäre.
Dieser Effekt ist auch bei diversen weiteren Operationen, die man sich
noch ausdenken kann, zu beobachten.
Hieraus schlußfolgert man, daß die Ausdruckskraft, die durch die
vorstehende Operationenmenge erreicht wird, einerseits ausreichend
für eine große Klasse von Problemen, andererseits ein Minimum an
Ausdruckskraft ist, das von jeder Abfragesprache für relationale Datenbanken erreicht werden sollte; solche Sprachen nennt man daher
relational vollständig8 .
Die Operationenmenge {σ, π, ρ, ∪, −, ×} ist übrigens minimal in
dem Sinne, daß keine der Operationen auf die anderen zurückführbar ist, jede echte Teilmenge wäre nicht mehr relational vollständig.
Wir hätten alternativ statt des Kreuzprodukts zuerst den natürlichen Verbund einführen können und hätten dann das Kreuzprodukt
auf den natürlichen Verbund zurückgeführt; die Operationenmenge
{σ, π, ρ, ∪, −, 1} ist also eine andere minimale, relational vollständige
Operationenmenge.
3.9
Ausdrücke in der relationalen Algebra
Wie schon einleitend erwähnt setzen wir bei der relationalen Algebra
eine existierende Datenbank, also ein konzeptuelles Schema und dazu
passende existierende Relationen, voraus. Hierdurch ist eine Menge
von Namen von Relationen und Attributen vorgegeben. Diese Namen
können wir nun an passender Stelle in den Operationen der relationalen Algebra einsetzen. Überall dort, wo eine relationale Operation
eine Relation als Argument benötigt, kann natürlich wiederum ein relationaler Ausdruck eingesetzt werden.
Syntaktisch korrekte Ausdrücke sind analog zu arithmetischen Ausdrücken in gängigen Programmiersprachen definiert. Details der Syntaxdefinition und -prüfung und Übersetzung interessieren uns an dieser
8
Diese Bezeichnung ist insofern irreführend, als eine praxisgerechte Sprache viele über die zentralen Abfrageoperationen hinausgehende Funktionen anbieten muß,
s. Abschnitt 1. So gesehen sind die Operationen der relationalen Algebra ziemlich
unvollständig.
c
2008
Udo Kelter
Stand: 10.11.2008
29
Stelle nicht, und wir setzen i.f. syntaktisch korrekte Ausdrücke voraus.
Ausdrücke werden klassischerweise von innen nach außen ausgewertet. Die entstehenden Zwischenresultate müssen gepuffert werden.
Diese Zwischenresultate können, wenn Verbunde oder Kreuzprodukte
auftreten, extrem groß werden, d.h. man kann erhebliche PerformanceProbleme bekommen, wenn man einen relationalen Ausdruck in kanonischer Weise auswertet.
Man kann das Ergebnis eines relationalen Ausdrucks oft effizienter
berechnen als durch eine kanonische Auszuwertung; die Bestimmung
eines effizienteren Rechenverfahrens bezeichnet man als Optimierung.
Durch die Optimierung ist es vielfach möglich, auch äußerlich “ineffiziente” Ausdrücke recht effizient auszuwerten. Die entscheidende
Konsequenz hieraus ist, daß man bei der Formulierung relationaler
Abfragen zunächst keine Rücksicht auf Ineffizienz bei der kanonischen
Auswertung nehmen sollte und sich stattdessen besser auf die inhaltliche Korrektkeit des Ausdrucks konzentieren sollte. Lösungen, die klar
und korrekt, aber “ineffizient” sind, sind vielfach kompakter und deswegen leichter für Optimierer behandelbar als “effiziente” komplizierte
(und schlimmstenfalls inkorrekte) Lösungen.
Wenn der Optimierer der Datenbank wider Erwarten doch keine effiziente Ausführung findet – Wunder wirken können Optimierer nicht,
und nicht jedes DBMS hat einen guten Optimierer – , kann man in
einem zweiten Schritt immer noch versuchen, durch Umformung der
Anfrage die eigentliche Arbeit des Optimierers doch selbst von Hand
zu erledigen.
4
Schlüssel
Wir hatten schon in Abschnitt 2.3 Identifizierungsschlüssel als eine
typische Integritätsbedingung erwähnt; nachdem wir nun die Operationen der relationalen Algebra kennen, können wir einige Schlüsselbegriffe leichter exakt definieren.
c
2008
Udo Kelter
Stand: 10.11.2008
4.1
30
Superschlüssel und Identifizierungsschlüssel
Wir betrachten noch einmal die Relation kunden in Bild 1. Von dem
Attribut Kundennummer verlangten wir schon früher, daß es “eindeutig” sein sollte, m.a.W. daß zu jeder Kundennummer höchstens ein Tupel vorhanden sein sollte. Eine Kundennummer identifiziert also, sofern vorhanden, genau ein Tupel. Formal läßt sich dies so ausdrücken:
kn ∈ πKundennummer (kunden)
⇒
| σKundennummer=kn (kunden) | = 1
Die vorstehende Bedingung ist äquivalent zu der folgenden kompakteren Bedingung (Beweis: Übungsaufgabe):
| πKundennummer (kunden) | =
| kunden |
Das Attribut Wohnort hat diese Eigenschaft offensichtlich nicht. Es
könnte aber sein, daß die beiden Attribute Wohnort und Kundenname
zusammen die Identifizierungseigenschaft haben. Genereller kann eine
beliebige Menge von Attributen zur Identifikation von Tupeln verwendet werden. Eine derartige Menge von Attributen nennen wir einen
Superschlüssel. Die formale Definition lautet:
Sei R ein Relationentyp, K ⊆ R eine Attributmenge. Wenn K ein
Superschlüssel für R ist, dann gilt für jede korrekte Relation r mit
dem Relationentyp R stets folgendes:
| πK (r) | =
| r |
Die Attribute in K nennen wir auch Schlüsselattribute. Bildlich gesprochen gehen beim Projizieren auf einen Superschlüssel keine Tupel
verloren, weil eben keine Kombination der Werte der Schlüsselattribute doppelt auftritt.
Der seltsam klingende Name Superschlüssel rührt daher, daß die
Attributmenge gemäß der vorstehenden Definition auch “überflüssige”
Attribute enthalten kann, die für die Identifikation eigentlich nicht gebraucht werden. Ein extremes Beispiel ist die Attributmenge R; R ist
immer ein Superschlüssel für R , sofern die Relation eine Menge ist
(also keine Duplikate erlaubt sind).
Ein Identifizierungsschlüssel ist eine minimale Menge von Attributen, die Superschlüssel ist.
c
2008
Udo Kelter
Stand: 10.11.2008
31
Für unsere Relation kunden sind {Kundennummer} und {Kundenname, Wohnort} Identifizierungsschlüssel. Wenn zusätzlich die Personalausweisnummer zu jedem Kunden vorhanden wäre, wäre {Personalausweisnummer} ein weiterer Identifizierungsschlüssel. Dieses Beispiel
zeigt, daß es für einen Relationentyp mehrere Identifizierungsschlüssel
geben kann.
Die Bezeichnung Schlüssel wird meist als Synonym zu Identifizierungsschlüssel verstanden. Unter einem Schlüsselwert bei einem
Tupel t verstehen wir die Menge der Attributwerte von t bei den Attributen des Identifizierungsschlüssels.
Es sei noch einmal daran erinnert, daß Schlüsseleigenschaften Integritätsbedingungen, also vom Anwender definierte Anforderungen
sind. Zu der Erkenntnis, daß eine Attributmenge K ein Identifizierungsschlüssel ist, kommt man nicht etwa dadurch, daß man den
Zustand der Datenbank eine Zeitlang beobachtet und währenddessen
dauernd kontrolliert, ob die Identifizierungseigenschaft erfüllt ist. Es
ist genau umgekehrt: die Identifizierungseigenschaft wird vorgegeben,
und das DBMS hat dafür zu sorgen, daß unerwünschte Zustände verhindert werden.
Das DBMS muß bei jedem Einfügen eines neuen Tupels oder
Ändern eines vorhandenen Tupels für jeden Identifizierungsschlüssel
prüfen, ob der neue Schlüsselwert schon in der Relation auftritt. Diese Prüfung kann so implementiert werden, daß die ganze Relation
linear durchsucht wird. Dies ist i.a. (außer bei kleinen Relationen)
zu ineffizient, daher muß praktisch immer für einen Identifizierungsschlüssel ein Verzeichnis angelegt werden, in dem die aktuell vorhandenen Schlüsselwerte verzeichnet sind und das effizient durchsuchbar ist
(z.B. als Baumstruktur oder Hash-Tabelle)9 . Dieses Verzeichnis muß
bei allen Datenänderungen entsprechend aktualisiert werden. Sofern
eine Relation mehrere Identifizierungsschlüssel hat, muß für jeden ein
9
Eine effiziente Suche wird z.B. auch durch die sortierte Speicherung nach
dem Identifizierungsschlüssel ermöglicht; allerdings machen hier Einfügungen und
Löschungen Probleme. Derartige Implementierungstechniken sind kein Thema dieses Lehrmoduls.
c
2008
Udo Kelter
Stand: 10.11.2008
32
eigenes Verzeichnis der vorhandenen Schlüsselwerte angelegt werden.
Viele DBMS erlauben es, Relationen zu definieren, die keinen einzigen Identifizierungsschlüssel haben. Eine derartige Relation kann
Tupelduplikate enthalten. Auch die Gesamtmenge aller Attribute bildet hier keinen Schlüssel, denn dann wären keine Duplikate erlaubt.
4.2
Primärschlüssel
Die Verzeichnisse für die Identifizierungsschlüssel kosten Platz und Rechenzeit, man würde sie daher lieber vermeiden. Dies ist in der Tat
bei vielen internen Speicherstrukturen möglich. Bei den folgenden Annahmen und Implementierungsentscheidungen:
1. jedes Tupel wird in einem Speichersatz gespeichert (vgl. [DBSA]),
2. die Relation wird in einem B*-Baum gespeichert,
3. der Identifizierungsschlüssel ist einelementig (enthält also nur ein
Attribut),
4. man verwendet die Schlüsselwerte der Tupel als Schlüsselwerte im
B*-Baum
bekommt man die Eindeutigkeitsprüfung praktisch gratis! Diese sehr
effiziente Prüfung der Schlüsseleigenschaft ist aber nur bei einem einzigen Identifizierungsschlüssel möglich; wenn man mehrere Identifizierungsschlüssel hat, muß man für die übrigen nach wie vor separate
Verzeichnisse anlegen.
Als Primärschlüssel bezeichnet man denjenigen Identifizierungsschlüssel, für den die Möglichkeit der sehr effizienten Prüfung der
Schlüsseleigenschaft ausgenutzt werden soll. Welche Implementierungstechniken hierzu verwendet werden, bleibt eine Entscheidung des
DBMS-Herstellers.
Neben der Prüfung der Schlüsseleigenschaft ist natürlich bei einem
Primärschlüssel auch die Suche nach dem Tupel, das einen bestimmten
Wert bei diesem Attribut hat, besonders effizient möglich. Derartige
Suchvorgänge sind z.B. bei der Verbundbildung nötig; s. das Beispiel
in Abschnitt 3.6.1. Daher wird man, sofern mehrere Identifizierungsschlüssel vorhanden sind, denjenigen als Primärschlüssel auswählen,
c
2008
Udo Kelter
Stand: 10.11.2008
33
mit dem häufig Verbunde gebildet werden. In den meisten Fällen
hat man aber ohnehin nur einen einzigen Identifizierungsschlüssel, der
dann automatisch als Primärschlüssel zu wählen ist.
Die vorstehenden Beobachtungen zeigen, daß die Festlegung des
Primärschlüssels eine Implementierungsentscheidung ist, die für die
konzeptionelle Struktur der Datenbank unerheblich ist. Im Sinne der
3-Ebenen-Schema-Architektur (s. Abschnitt 5.2 in [DVS]) gehört die
Festlegung des Primärschlüssels also zum internen Schema. Im Gegensatz dazu gehören Identifizierungsschlüssel zum konzeptuellen Schema.
Leider wird zwischen den Ebenen oft nicht sauber getrennt. Die
Bezeichnung Schlüssel wird vielfach auch als Synonym zu Primärschlüssel verstanden.
Eine wesentliche Ursache für diese Vermischung von Begriffen liegt
darin, daß man beim Entwurf der konzeptuellen Schemata durchaus
Rücksicht auf deren Implementierung nehmen muß; dies steht etwas
im Widerspruch zu der Idealvorstellung, wonach die konzeptuellen und
implementierungsbezogenen Aspekte völlig getrennt voneinander auf
den beiden unteren Ebenen der 3-Ebenen-Schema-Architektur behandelt werden können. Betrachten wir hierzu wieder das Beispiel in Bild
1. Einer der Identifizierungsschlüssel war {Kundenname, Wohnort}.
Dieser Identifizierungsschlüssel ist i.a. als Primärschlüssel ungeeignet,
weil hier die internen Schlüsselwerte als Konkatenation der beiden Attributwerte gebildeten werden müßten und weil diese Zeichenketten
relativ lang werden können. Aus Effizienzgründen erlauben Implementierungen von B*-Bäumen und ähnlichen internen Strukturen ggf.
nur relativ kurze Schlüsselwerte fester Länge, z.B. ganze Zahlen mit 4
oder 8 Bytes Länge oder Zeichenketten mit 8 Zeichen.
Sofern die “natürlichen” Identifizierungsschlüssel alle als Primärschlüssel ungeeignet sind, muß man ein künstliches Schlüsselattribut
erfinden; hierauf gehen wir in Abschnitt 4.4 ausführlicher ein.
4.3
Fremdschlüssel
Identifizierungsschlüssel einer Relation werden oft von einer anderen
Relation aus “referenziert”. In unserer Relation lieferungen kam
c
2008
Udo Kelter
Stand: 10.11.2008
34
z.B. das Attribut Kundennummer vor, das Identifizierungsschlüssel in
kunden ist. Es sollte offensichtlich keine Lieferung geben, bei der die
Kundennummer “ins Leere zeigt”, weil sie in kunden nicht auftritt.
Die Abwesenheit solcher Datenfehler bezeichnet man auch als referentielle Integrität. Formal formuliert fordern wir folgende Mengeninklusion:
πKundennummer (lieferungen) ⊆ πKundennummer (kunden)
Kundennummer bezeichnen wir als Fremdschlüssel in der Relation lieferungen. Alle Werte, die im Attribut Kundennummer in
lieferungen auftreten, müssen auch im Attribut Kundennummer in
kunden auftreten.
Die allgemeine Definition ist: sei K eine Attributmenge, r eine Relation mit dem Relationentyp R, K ⊆ R, s eine andere Relation mit dem
Relationentyp S und K der Primärschlüssel in S. Wenn K Fremdschlüssel in r (mit Bezug auf s) ist, dann gilt stets
πK (r) ⊆ πK (s)
Das DBMS muß hier verhindern,
1. daß Tupel in s, auf die noch Referenzen in r existieren, gelöscht
werden, und
2. daß Tupel in r erzeugt werden, bei denen der Wert der Fremdschlüsselattribute kein Tupel in s referenziert.
Nullwerte sollten in Fremdschlüsseln vermieden werden. Wenn man
sie zuläßt, bedeutet ein Nullwert, daß unbekannt ist, welches andere
Tupel referenziert wird.
4.4
Kriterien für die Festlegung von Identifizierungsund Primärschlüsseln
Identifizierungsschlüssel werden häufig als Fremdschlüssel in anderen
Relationen benutzt; hieraus ergeben sich mehrere Kriterien, die bei
der Festlegung von Identifizierungsschlüsseln beachtet werden sollten:
c
2008
Udo Kelter
Stand: 10.11.2008
35
– Können die Werte beim Eintragen immer sofort bestimmt werden?
Man kann theoretisch auch Nullwerte bei Schlüsselattributen zulassen, praktisch stört dies aber sehr. U.a. können keine Fremdschlüssel-Referenzen auf dieses Tupel in anderen erzeugt werden.
– Sind die Werte kurz und schreibbar? Dies betrifft wieder den Fall,
daß in anderen Relationen Fremdschlüssel-Referenzen von Hand
eingetragen werden müssen.
– Sind die Werte “sprechend”, d.h. ist den Systembenutzern intuitiv
verständlich, welche reale Entität durch ein Tupel dargestellt wird?
Diese Anforderung steht oft im Widerspruch zu den beiden ersten.
Ein weiteres Kriterium betrifft die zeitliche Entwicklung des Datenbankinhalts. Die aktuell in einem Identifizierungsschlüssel auftretenden Werte müssen natürlich eindeutig sein; zusätzlich kann es sinnvoll
sein, die Eindeutigkeit über die Zeit hinweg zu verlangen. Beispielsweise könnte Kundenname ein Identifizierungsschlüssel sein und derzeit
eine Kundin “Meier, Anna” vorhanden sein. Diese wird irgendwann
gelöscht, und ein Jahr später wird eine andere, neue Kundin eingetragen, die zufällig genauso heißt. Wenn man derartiges vermeiden will,
dürfen einmal benutzte Identifizierungsschlüsselwerte nicht wiederverwendet werden. Hierzu müßte ein Verzeichnis aller jemals verwendeten
Identifizierungsschlüsselwerte geführt werden, was sehr aufwendig und
platzraubend sein kann.
Die vorstehenden Anforderungen werden oft von “natürlichen”
Identifizierungsschlüsseln, die sich aus einer von Implementationsaspekten unbeeinflußten Datenmodellierung ergeben, nicht erfüllt. Beispielsweise sind textuelle Namen zwar oft gut verständlich, aber zu
lang und wiederverwendbar.
Im Endergebnis entscheidet man sich daher oft dazu, ein künstliches Schlüsselattribut, meist eine laufende Nummer, zu erfinden. Das
Attribut Kundennummer ist ein Beispiel hierfür, denn “von Natur aus”
haben Kunden keine Nummer.
c
2008
Udo Kelter
Stand: 10.11.2008
4.5
36
Weitere Schlüsselbegriffe
Sofern mehrere Identifizierungsschlüssel vorhanden sind, werden sie
oft auch als Schlüsselkandidaten bezeichnet. Jeder Identifizierungsschlüssel ist ein Kandidat dafür, Primärschlüssel zu werden, nur einer
schafft es. Diese Bezeichnung vermengt die konzeptuelle und interne
Begriffs- und Denkwelt besonders stark, weshalb wir sie weitgehend
vermeiden werden.
Ein Sortierschlüssel (sort key) bestimmt die Reihenfolge, in der
die Speichersätze in einem DB-Segment gespeichert werden. Hierdurch kann die Verarbeitung kompletter Relationen beschleunigt werden. Ein Sortierschlüssel muß nicht unbedingt identifizierend sein.
Ein Sekundärschlüssel (secondary key) ist eine Menge von Attributen, für die ein Sekundärindex vorhanden ist. Ein Sekundärschlüssel
ist i.a. nicht identifizierend. Der Sekundärindex ist eine Datenstruktur, die jedem Sekundärschlüsselwert eine Liste der Sätze bzw. Tupel
zuordnet, bei denen die entsprechenden Attributwerte auftreten. Beispielsweise könnte es sinnvoll sein, bei der Relation konten einen Sekundärindex für das Attribut Kundenname einzurichten; dies beschleunigt die Suche nach den Kunden mit einem bestimmten Namen erheblich.
Die folgende Tabelle stellt noch einmal alle Schlüsselbegriffe zusammen und gibt jeweils an, ob es sich um einen Begriff der konzeptuellen
oder internen Ebene in der 3-Ebenen-Schema-Architektur handelt und
ob die Attribute identifizierend sind.
Begriff
Identifizierungsschlüssel
Superschlüssel
Schlüsselkandidat
Fremdschlüssel
Primärschlüssel
Sekundärschlüssel
Sortierschlüssel
c
2008
Udo Kelter
Ebene
logisch
logisch
logisch
logisch
intern
intern
intern
identifizierend
ja
ja
ja
nein
meist
nein
nein
Stand: 10.11.2008
37
Implementierungen für Primärschlüssel sind meist so gestaltet,
daß die Eindeutigkeit der Schlüsselwerte erzwungen wird. Man kann
aber auch leicht Varianten dieser Implementierungen bilden, bei denen mehrere Sätze mit dem gleichen Primärschlüsselwert vorhanden
sein dürfen, die dann beim Lesen als Gruppe behandelt werden. Bei
solchen Implementierungen ist ein Primärschlüssel nicht automatisch
auch Identifizierungsschlüssel.
Literatur
[Co70] Codd, E.F.: A relational model for large shared data banks;
CACM 13:6, p.377-387; 1970/06
[Vo99] Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme; Oldenbourg; 1999
[DBSA] Kelter, U.: Lehrmodul “Architektur von DBMS”; 2001
[DVS] Kelter, U.: Lehrmodul “Datenverwaltungssysteme”; 2002
Glossar
Division: Operation der relationalen Algebra, die in gewisser Weise invers zum Kreuzprodukt ist und mit der Suchaufgaben gelöst werden
können, die All-Quantoren enthalten
Fremdschlüssel: (Kontext: Attributmenge F in Relation R1 ist Fremdschlüssel auf eine Relation R2) Menge von Attributen, die Tupel in
einer anderen Relation identifizieren sollen; ist eine Integritätsbedingung, wonach die Projektion von R1 auf F komplett in der Projektion
von R2 auf F enthalten ist
Identifizierungsschlüssel: minimale Menge von Attributen, die ein Superschlüssel ist
Primärschlüssel: Attribut (-kombination),
terstützt
die der Primärindex un-
Projektion: Operation der relationalen Algebra, mit der in den Tupeln einer Eingaberelation Attribute entfernt werden können; entstehende
Duplikate werden eliminiert
c
2008
Udo Kelter
Stand: 10.11.2008
38
relationale Algebra: Algebra mit den Kernfunktionen relationaler Datenbanksysteme im Bereich der Abfragedienste, insb. Selektion, Projektion, Mengenoperationen, Kreuzprodukt, natürlicher bzw. ThetaVerbund und Division
Relationenschema: Namen und Typen der Attribute einer Relation; Synonyme: Relationentyp, Relationenformat
Schlüssel: Oberbegriff für mehrere spezielle Schlüsselbegriffe; oft als Synonym für Identifizierungsschlüssel benutzt
Schlüsselkandidat: Synonym für Identifizierungsschlüssel
Sekundärschlüssel: Attribut (-kombination), für die ein Sekundärindex
vorhanden ist
Selektion: Operation der relationalen Algebra, mit der Tupel einer Eingaberelation anhand einer Bedingung selektiert werden können
Sortierschlüssel: Attribut (-kombination), nach der intern sortiert gespeichert wird
Spalte (column): einer Tabelle; Synonym: Attribut
Superschlüssel: Menge von Attributen, deren Werte die Tupel einer Relation eindeutig identifizieren
Tabelle (table): Hauptbestandteile einer relationalen Datenbank; wird oft
als Synonym zu Relation benutzt
Verbund: Operation der relationalen Algebra, mit der die Tupel zweier Eingaberelationen paarweise verbunden werden, sofern Sie eine Verbundbedingung erfüllen; beim Theta-Verbund wird die Verbundbedingung
explizit vorgegeben, beim Gleichheitsverbund werden Attribute der
zu verbindenden Tupel auf Gleichheit getestet, beim natürlichen Verbund werden nur Tupel verbunden, die in allen Attributen, die beiden
Relationen gemeinsam sind, jeweils die gleichen Werte haben
Verbund, äußerer: der linke (rechte) äußere Verbund ist eine Variante der
normalen Verbunde, bei denen Tupel der linken (rechten) Eingaberelation, die keinen Verbundpartner in der rechten (linken) Eingaberelation finden, ergänzt um Nullwerte bei den fehlenden Attributen,
zum Ergebnis hinzugenommen werden; der beidseitige äußere Verbund
liefert die Vereinigung des rechten und linken äußeren Verbunds
Zeile (row ): einer Tabelle; Synonym: Tupel
c
2008
Udo Kelter
Stand: 10.11.2008
Index
| .. |, 15
Primärschlüssel, siehe Schlüssel
3-Ebenen-Schema-Architektur, 33, 36 Projektion, 11, 37
Administration, 3
Attribut, 4, 38
Reihenfolge, 5
Wertebereich, 6
Wertzuweisung, 5
Rechteverwaltung, 3
referentielle Integrität, 34
Relation, 6
relationale Algebra, 9, 37
äußerer Verbund, 23
Ausdrücke, 28
B*-Baum, 32
Auswertung, 29
Differenz, 12
Datenbank, 4
Division, 23
Datenbankmodell
Gleichheitsverbund, 22
konventionelles, 3
Kreuzprodukt, 14
relationales, 3, 4
natürlicher Verbund, 18
Datenbanksprache, 3
Projektion, 11
Division, 23, 37
Schnitt, 12
Duplikate, 5, 7
Theta-Verbund, 22
Umbenennung, 13
equi-join, 22
Vereinigung, 12
relationale
Kalküle, 4
Fremdschlüssel, siehe Schlüssel
relationale Vollständigkeit, 28
Gleichheitsverbund, 22
Relationenformat, 6
Relationenschema, 6, 38
Identifizierungsschlüssel, siehe SchlüsselRelationentyp, 6
Integritätsbedingung, 8
als Menge von Attributen, 7
dynamische, 8
statische, 8
Schema, 3
Überprüfung, 8
Schlüssel, 29, 31, 33, 38
als Integritätsbedingungen, 31
Kalkül, siehe relationale Kalküle
Fremdschlüssel, 34, 36, 37
Kreuzprodukt, 14, 20, 23
Identifizierungsschlüssel, 30, 37
Auswahlkriterien, 34
natural join, 19
künstlicher, 33
Notationskonventionen, 7
Prüfung, 31
Nullwert, 23
Wiederverwendung von Schlüsselwerten, 35
Optimierung, 29
39
40
Primärschlüssel, 32, 33, 36, 37
Auswahl, 32
Schlüsselattribut, 30
Schlüsselkandidat, 36, 38
Sekundärschlüssel, 36, 38
Sortierschlüssel, 36, 38
Superschlüssel, 30, 36, 38
Schlüsselkandidat, siehe Schlüssel
Schlüsselwert, 31
secondary key, 36
Sekundärschlüssel, siehe Schlüssel
Selektion, 9, 38
Bedingung mit all-Quantor, 26
sort key, 36
Sortierschlüssel, siehe Schlüssel
Spalte, 4, 38
Superschlüssel, siehe Schlüssel
t[A], 11
Tabelle, 4, 38
Tupel, 6, 38
Umbenennung, 13
Verbund, 38
äußerer, 23, 38
Gleichheits-, 22, 38
natürlicher, 18, 38
Theta-, 22, 38
Verbundattribute, 19
Vollständigkeit, 27
Zeile, 4, 38
c
2008
Udo Kelter
Stand: 10.11.2008

Das relationale Datenbankmodell

Transcription

Similar documents

Skript mit Übungen (veraltet) - Hochschule Ravensburg

Übungsskript „Relationale Algebra“

- IPD Goos

Key–based Overlay Routing in Mobilen Ad–Hoc Netzen

Teil 6: Relationale Algebra

Datenbank SQL PHP - DSP: Datenbank, MySQL und PHP

Zusammenfassung - Hu

DBF - Normalisierung

Relationale Algebra

Grundlagen der Datenbanken

Zusammenfassung

Datenbankadministration - 2. SQL

Datenbankanfragen und -operationen mittels SQL

Lösungen zur Prüfungsklausur (Muster)

Kapitel 3 SQL = Structured Query Language

Klausur WS1516 mit Musterlösungen

Algorithmen und Datenstrukturen 1 - 4. Seminar

Datenbankprogrammierung (Oracle)

Ankündigung