Das relationale...

Das relationale Datenbankmodell

Udo Kelter

27.11.2013

Zusammenfassung dieses Lehrmoduls

Das relationale Datenbankmodell besteht im Kern aus Operationen wieder Selektion, der Projektion und diversen Verbundoperationen. Diesewerden in der relationalen Algebra zusammengefaßt. Dieses Lehrmo-dul stellt diese Operationen vor. Vorab wird die statische Struktureiner relationalen Datenbank definiert. Aus der Vielzahl denkbarerIntegritätsbedingungen werden hier nur Schlüsselbegriffe behandelt;wir unterscheiden u.a. Identifikations-, Super-, Fremd-, Primär- undSekundärschlüssel.

Vorausgesetzte Lehrmodule:obligatorisch: - Datenverwaltungssysteme

Stoffumfang in Vorlesungsdoppelstunden: 2.0

1

Das relationale Datenbankmodell 2

Inhaltsverzeichnis1 Datenbankmodelle vs. reale Datenbanksprachen 3

2 Die Struktur relationaler Datenbanken 42.1 Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Integritätsbedingungen . . . . . . . . . . . . . . . . . . . . . . 8

3 Die relationale Algebra 93.1 Die Selektion . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Die Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Die Mengenoperationen . . . . . . . . . . . . . . . . . . . . . 123.4 Die Umbenennung . . . . . . . . . . . . . . . . . . . . . . . . 133.5 Das Kreuzprodukt . . . . . . . . . . . . . . . . . . . . . . . . 143.6 Verbundoperationen . . . . . . . . . . . . . . . . . . . . . . . 17

3.6.1 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . 173.6.2 Der natürliche Verbund . . . . . . . . . . . . . . . . . 193.6.3 Der Theta-Verbund . . . . . . . . . . . . . . . . . . . 233.6.4 Äußere Verbunde . . . . . . . . . . . . . . . . . . . . . 23

3.7 Die Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.8 Relationale Vollständigkeit . . . . . . . . . . . . . . . . . . . . 283.9 Ausdrücke in der relationalen Algebra . . . . . . . . . . . . . 29

4 Schlüssel 304.1 Superschlüssel und Identifizierungsschlüssel . . . . . . . . . . 304.2 Primärschlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Fremdschlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4 Kriterien für die Festlegung von Identifizierungs- und Primär-

schlüsseln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5 Weitere Schlüsselbegriffe . . . . . . . . . . . . . . . . . . . . . 37

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

c©2013 Udo Kelter Stand: 27.11.2013Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer odergedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenom-men werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarfder expliziten Genehmigung. Die jeweils aktuellste Version ist über http://kltr.de erreichbar.


Das relationale Datenbankmodell ist eines der drei “konventionellen”Datenbankmodelle und, gemessen am Entwicklungstempo der Infor-matik, schon uralt. Es geht auf Arbeiten von E.F. Codd am IBM SanJose Research Laboratory [Co70] zurück. Seine Entwicklung wurdemaßgeblich von mehreren Prototypen relationaler DBMS beeinflußt,namentlich dem System R am IBM San Jose Research Laboratory, In-gres an der University of California at Berkeley und Query-by-Exampleam IBM T.J. Watson Research Center.Im Laufe der Jahre wurden sehr umfangreiche formale Grundlagen

des relationalen Datenbankmodells entwickelt. Ferner wurden vielfältigeErweiterungen der ursprünglichen Konzepte vorgeschlagen.In der Praxis ist das relationale Datenbankmodell heute dominie-

rend. Eine Vielzahl kommerzieller oder kostenloser relationaler DBMSist verfügbar.

1 Datenbankmodelle vs. reale Datenbankspra-chen

Das relationale Datenbankmodell legt zunächst nur zentrale, grundle-gende Konzepte fest (s. Begriff Datenbankmodell in [DVS] ), nämlich dieStruktur einer Datenbank und lesende Operationen auf dieser Struktur.Ein praktisch benutzbares System muß zusätzlich viele technische De-tails festlegen, angefangen bei der Syntax entsprechender Sprachen undBedienschnittstellen. Zum Vergleich: das Konzept einer while-Schleifewird von allen normalen imperativen Programmiersprachen unterstützt,die konkrete Syntax und technische Details können ganz erheblichdifferieren. Neben den Abfragen und Datenänderungen müssen außer-dem Funktionen bzw. Sprachkonstrukte zur Definition konzeptuellerund interner Schemata, Rechteverwaltung, Administration usw. an-geboten werden; das relationale Datenbankmodell legt diese Bereichenicht fest. Ähnlich wie Programmiersprachen sind daher die konkre-ten Abfragesprachen für relationale Systeme äußerlich sehr verschiedenund differieren auch außerhalb der grundlegenden Konzepte in vielentechnischen Details.

c©2013 Udo Kelter Stand: 27.11.2013


Für die Darstellung der grundlegenden Konzepte braucht man na-türlich dennoch Notationen, also eine Sprache. Die relationale Algebraund die relationalen Kalküle kann man in diesem Sinne als Sprachenansehen, die nur den Kern des relationalen Datenbankmodells abdeckenund von jeglichem störenden Ballast befreit sind.

2 Die Struktur relationaler Datenbanken

2.1 Tabellen

Die statische Struktur einer relationalen Datenbank kann man in-formell wie folgt definieren (eine präzisere Definition folgt später):

1. Eine relationale Datenbank besteht aus mehreren Tabellen. JedeTabelle 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 Spaltereden wir auch von einem Attribut.

4. Der Rumpf (oder “Inhalt”) einer Tabelle enthält eine Menge vonZeilen, d.h. Duplikate von Zeilen sind nicht erlaubt. Jede Zeile ent-hält in jeder Spalte einen Wert entsprechend dem Wertebereich derSpalte.

Tabelle: kundenKundennummer Kundenname Wohnort Kreditlimit177177 Meier, Anne Weidenau 2000.00177180 Büdenbender, Christa Siegen 9000.00185432 Stötzel, Gyula Siegen 4000.00167425 Schneider, Peter Netphen 14000.00171876 Litt, Michael Siegen 0.00

Abbildung 1: Beispieltabelle



Als Beispiel betrachten wir eine Tabelle kunden , in der Daten überdie Kunden eines Unternehmens verwaltet sein mögen (s. Bild 1). DieSpalte Kreditlimit gibt an, wieviele Waren dem Kunden auf Kreditgeliefert werden. Der Sinn der restlichen Spalten ist offensichtlich. DieWertebereiche der Spalten sind (von links nach rechts): 1. ganze Zahl,2. Text, 3. Text, 4. reelle Zahl. Über Längenbeschränkungen der Texteoder die Genauigkeit der Zahlen machen wir uns an dieser Stelle keineGedanken.

Eine Zeile repräsentiert oft eine Entität in der realen Welt, in unse-rem Beispiel repräsentiert jede Zeile einen Kunden. Wenn die Tabellezwei völlig gleiche Zeilen enthalten würde, wäre der gleiche Sachverhaltdoppelt repräsentiert; dies wäre sinnlos, Duplikate von Zeilen werdendaher nicht erlaubt.

Die Spalten enthalten die Beschreibungsmerkmale der repräsentiertenEntität. Interessant ist hier die Beobachtung, daß die Reihenfolge derSpalten unwesentlich ist, die folgende Tabelle ist zu der vorstehendenoffenbar äquivalent:

Tabelle: kundenWohnort Kundennummer Kundenname KreditlimitWeidenau 177177 Meier, Anne 2000.00Siegen 177180 Büdenbender, Christa 9000.00. . . . . . . . . . . .

Eine Zeile können wir daher auch als eine Menge von Attributzuwei-sungen auffassen, z.B. die erste Zeile als:

Kundennummer = 177177; Wohnort = Weidenau; Kundenname =”Meier, Anne”; Kreditlimit = 2000.00

Während die Reihenfolge der Attribute aus einer konzeptuellen Sicht-weise irrelevant ist, ist sie für die physische Speicherung i.a. relevant.Beide Sichtweisen müssen aber strikt getrennt werden; Datenbankmo-delle definieren nur konzeptuelle Aspekte, die physische Speicherungbleibt hier völlig außer Betracht.



2.2 Relationen

Die Bezeichnung “relational” stammt vom mathematischen Begriff einerRelation ab. Eine Relation ist in der Mathematik bekanntlich definiertals Teilmenge des Kreuzprodukts mehrerer Mengen, i.a.:

R ⊆ D1 ×D2 × . . .×Dn

Ein Element einer Relation nennt man Tupel. Den Inhalt der letztenTabelle könnte man offenbar als folgende Relation ansehen:

kunden ⊆ string × integer × string × real

Tabellen werden oft als Relationen bezeichnet und umgekehrt, es gibtaber einen signifikanten Unterschied: Relationen haben kein Äquivalentzum 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 einRelationentyp.Ein Relationentyp (auch als Relationenschema oder Relatio-

nenformat 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 sindoder im Moment nicht interessieren, und als

Relationentypname = ( . . . , Attributname: Wertebereich; . . . )

wenn die Wertebereiche angegeben werden sollen. Als Wertebereicheder Attribute sind nur elementare Datentypen wie integer, real, date,string usw. zugelassen, nicht hingegen strukturierte Datentypen wieArrays, Tupel, Mengen usw. oder gar Relationen1.Unsere erste Version der Kundentabelle führt also zu folgendem

Relationentyp:1In erweiterten relationalen Modellen, die wir hier nicht behandeln, können

Attribute dagegen strukturierte Typen haben.



Kunden = ( Kundennummer: integer;Kundenname: string;Wohnort: string;Kreditlimit: real )

Wir werden einen Relationentyp oft vereinfachend als Menge (undnicht Folge) von Attributen ansehen und die Schreibweisen A ∈ Rbzw. R1 ⊆ R2 benutzen, um darzustellen, daß das Attribut Aim Relationentyp R vorkommt bzw. daß im Relationentyp R1 nurAttribute aus dem Relationentyp R2 vorkommen.

Da wir hier den Begriff Typ gebrauchen, sei ein Vergleich mit denTypen in Programmiersprachen gestattet: ein Relationentyp entsprichtin etwa einem Datentyp, der als Menge von Objekten (oder Records)mit den Attributen gemäß dem Relationentyp definiert ist. Eine Rela-tion kann man in der Denkwelt von Programmiersprachen als Variabledieses Typs ansehen.

In Datenbanken ist die strikte Trennung zwischen Typ und Variablewenig sinnvoll, weil es zu jedem Relationentyp immer nur eine Rela-tion gibt. Daher werden dort immer gleich Relationen definiert, ihrTyp wird nur implizit mitdefiniert und hat keinen Namen. Für dieErklärung des relationalen Datenbankmodells werden wir allerdingswiederholt Relationentypen benötigen, so daß wir auf diesen Begriffnicht verzichten kö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 vom Relationentyp R seinsoll, ist wegen des Rückgriffs auf den mathematischen Relationsbegriffimplizit klar,

- daß alle Tupel von r insofern korrekt sind, daß die Werte dereinzelnen Attribute aus den passenden Wertebereichen stammen,und



- daß keine Tupel in r doppelt vorhanden sind (eine Relation isteine Menge und keine Multimenge)2.

Wir werden i.f. Tabellen als Darstellung von Relationen benutzenund die beiden Begriffe in diesem Sinne synonym verwenden.

2.3 Integritätsbedingungen

Es gibt sehr viele Arten, Integritätsbedingungen in relationalen Daten-banken zu formulieren. Es ist Geschmackssache, wieviele davon manzum “Kern” des relationalen Datenbankmodells zählt. Man kann dieIntegritätsbedingungen grob wie folgt einteilen:

- Dynamische Integritätsbedingungen schränken die erlaubtenZustandsübergänge bei Änderungen der Daten ein. Beispielsweisekönnte bei einem Attribut Familienstand der Übergang von verhei-ratet nach ledig verboten sein. Dynamische Integritätsbedingungenwerden wir nicht weiter betrachten.

- Statische Integritätsbedingungen schränken den erlaubten Zu-stand einer Datenbank weiter ein. Das bekannteste Beispiel sind(Identifizierungs-) Schlüssel.

Integritätsbedingungen können allenfalls bei Änderungen an denDaten verletzt werden. Ein DBMS muß daher bei allen ändernden Ope-rationen entsprechende Prüfungen durchführen und die Operation ggf.mit einem Fehlercode zurückweisen.Lesende Operationen sind dagegen überhaupt nicht von Integri-

tätsbedingungen betroffen: diese Operationen arbeiten auf beliebigenDatenbankinhalten, also erst recht auf der Teilmenge der “korrekten”Datenbankinhalte. Aus diesem Grunde sind Integritätsbedingungen fürdie nachfolgende Diskussion der relationalen Algebra nicht erforderlich.

2Technisch wäre es kein Problem, auch Multimengen zuzulassen. In der Pra-xis erspart man sich aus Performancegründen oft die Eliminierung von Duplikaten.Wie schon erwähnt sind aber Duplikate von Tupeln i.a. nicht sinnvoll.



3 Die relationale Algebra

Der Begriff Algebra stammt aus der Mathematik. Eine Algebra istdefiniert durch eine Wertemenge3 und i.a. mehrere Funktionen, diemit Werten dieser Menge arbeiten. Beispiele für Algebren sind diereellen Zahlen oder Matrizen zusammen mit den diversen Rechenope-rationen. Die Funktionen können beliebig viele Argumente haben undliefern stets einen Wert aus der Wertemenge zurück. Daher kann manFunktionsaufrufe schachteln und Ausdrücke konstruieren.Die relationale Algebra ist eine ganz normale Algebra im vorste-

henden Sinn. Als Werte benutzen wir beliebige Relationen. Daß dieentstehende Wertemenge recht groß ist und ganze Relationen als Argu-mente oder Resultate etwas schwergewichtig erscheinen mögen, brauchtuns nicht weiter zu stören.

Die relationale Algebra enthält keine Operationen, mit denen manRelationen erzeugen bzw. löschen und in einer Relation Tupel einfügen,löschen oder verändern kann. Derartige Operationen müssen in realenSprachen natürlich vorhanden sein. Die relationale Algebra konzen-triert 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 irgend-wie existieren und mit Tupeln gefüllt worden sind. Analog gilt dies fürdie Relationentypen, also das konzeptuelle Schema der Datenbank.

Die Operationen der relationalen Algebra entsprechen nicht unzufäl-lig den typischen Aufgaben, die beim Umgang mit Datenbanken in derPraxis auftreten. Wir stellen sie anschließend einzeln vor.

3.1 Die Selektion

Die Selektion erlaubt es, aus einer vorhandenen Relation r bestimmteTupel zu selektieren. Zurückgeliefert wird eine neue Relation, die nurdie Tupel enthält, die das Selektionskriterium erfüllen. Notiert wird dieSelektion üblicherweise in der Form

3Dies gilt für eine einsortige Algebra. Mehrsortige Algebren arbeiten mit mehre-ren Wertemengen, die hier als Sorten bezeichnet werden.



σBedingung( r )

Der griechische Buchstabe sigma (σ) erinnert an das S im Wort Selek-tion. Das Ergebnis einer Selektion hat den gleichen Relationentyp wiedie Argumentrelation.Als Beispiel betrachten wir die Menge der Kunden aus der Rela-

tion kunden in Bild 1, deren Kreditlimit größer als 5000 EUR 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 Wohnort Kreditlimit177180 Büdenbender, Christa Siegen 9000.00167425 Schneider, Peter Netphen 14000.00

Im vorstehenden Beispiel trat nur eine sehr einfache Selektionsbedin-gung auf, die den Wert eines Attributs mit einer Konstanten verglich.Neben > sind auch die Vergleichsoperatoren <, ≤, ≥, = und 6= möglich.Ferner können so geformte elementare Bedingungen mit den BooleschenOperatoren (∧, ∨, ¬) und Klammern zu Ausdrücken zusammengesetztwerden. Die Bedingungen dürfen sich natürlich nur auf solche Attributebeziehen, die im Typ der Argumentrelation vorkommen.

Übungsaufgabe: Zeigen Sie, daß die und-Verküpfung von zwei Be-dingungen durch eine Hintereinanderschaltung von zwei Selektionenmit den einzelnen Bedingungen ersetzt werden kann, daß also für einebeliebige Relation r und Bedingungen B1 und B2 gilt:

σB1∧B2 ( r ) = σB1 (σB2 ( r )) = σB2 (σB1 ( r ))

3.2 Die Projektion

Die Projektion löst das Problem, überflüssige Attribute in den Tupelneiner Relation zu entfernen. Man projiziert eine Relation auf die Attri-



bute, die man noch beibehalten möchte. Notiert wird die Projektionü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 möchten jetzt nur noch Kundenname und Wohnort haben, die bei-den anderen Attribute bzw. Spalten sollen “wegprojiziert” werden. Dieserreichen wir mit folgendem Ausdruck:

πKundenname,Wohnort ( kunden )

Die entstehende Tabelle ist:

Tabelle: πKundenname,Wohnort ( kunden )

Kundenname WohnortMeier, Anne WeidenauBüdenbender, Christa SiegenStötzel, Gyula SiegenSchneider, Peter NetphenLitt, Michael Siegen

Das Ergebnis einer Projektion hat i.a. nicht den gleichen Relatio-nentyp wie die Argumentrelation4. Der Typ der Ergebnisrelation hatgenau die in der Projektion angegebenen Attribute.

Für die formale Definition der Projektion benötigen wir folgende neueNotation: Sei r eine Relation mit Relationentyp R , t ein Tupel inr , also t ∈ r , A ⊆ R eine nichtleere Teilmenge der Attribute in R. Dann bezeichnet t[A] das Tupel, das die Attributwerte für die Attri-bute in A gemäß t enthält. Mit dieser Notation können wir dasErgebnis einer Projektion wie folgt definieren:

πA (r) = { t[A] | t ∈ r }4Eine Ausnahme ist lediglich der wenig sinnvolle Sonderfall, daß man auf alle

Attribute der Argumentrelation projiziert.



Im vorigen Beispiel hat die Ergebnisrelation genausoviele Tupel wiedie Argumentrelation. Dies ist nicht immer der Fall, wie folgendesBeispiel zeigt:

πWohnort ( kunden )

Die entstehende Tabelle ist:

Tabelle: πWohnort ( kunden )

WohnortWeidenauSiegenNetphen

Sie hat nur noch 3 Tupel, denn in der Spalte Wohnort treten nur 3verschiedene Werte auf. Man betrachte noch einmal die obige Definiti-on der Projektion: πA (r) ist als Menge, nicht als Multimenge definiert.Zwei verschiedene Tupel t1, t2 ∈ R , t1 6= t2, können nach der Projek-tion gleich sein und führen daher nur zu einem einzigen Tupel in derErgebnisrelation.

Übungsaufgabe: Seien P , Q und R Relationentypen, r eineRelation vom Typ R . Zeigen Sie, daß folgendes gilt:

P ⊆ Q ⊆ R ⇒ π P (π Q ( r )) = π P ( r )

3.3 Die Mengenoperationen

Da Relationen als Mengen von Tupeln definiert sind, sind automatischalle Mengenoperationen auf Relationen anwendbar. Voraussetzung istnatürlich, daß die beteiligten Relationen den gleichen Relationentyphaben.Wenn also r1 und r2 Relationen vom Typ R sind, dann ist

r1 ∪ r2 die Vereinigungr1 ∩ r2 der Schnitt



r1 − r2 die Differenzvon r1 und r2 . Das Ergebnis hat wieder den Relationentyp R .Als Beispiel betrachten wir wieder die Relation kunden in Bild 1.

Wir suchen jetzt die Kunden, die in Weidenau wohnen oder ein Kre-ditlimit > 10000 haben. Hierzu definieren wir die Relation k1 wiefolgt:

k1 = σWohnort=“Weidenau′′ ( kunden ) ∪ σKreditlimit>10000 ( kunden )

Das Ergebnis ist:

Tabelle: k1Kundennummer Kundenname Wohnort Kreditlimit177177 Meier, Anne Weidenau 2000.00167425 Schneider, Peter Netphen 14000.00

Wir hätten dieses Ergebnis natürlich auch mit der folgenden Defini-tion erzielen können;

k1 = σWohnort=“Weidenau′′ ∨ Kreditlimit>10000 ( kunden )

Übungsaufgabe: Zeigen Sie, daß die oder-Verküpfung von zwei Be-dingungen durch eine Vereinigung von zwei Selektionen mit den ein-zelnen Bedingungen ersetzt werden kann, daß also für eine beliebigeRelation r und Bedingungen B1 und B2 gilt:

σB1∨B2 ( r ) = σB1 ( r ) ∪ σB2 ( r )

3.4 Die Umbenennung

Aus technischen Gründen benötigen wir für die folgenden Operationeneine Hilfsoperation, mit der man Attribute umbenennen kann. Sei reine Relation vom Typ R und A ∈ R , B /∈ R . Dann ist

ρ A→ B ( r )



eine Relation mit dem gleichen “Inhalt” wie r , aber mit einem Typ,bei dem das Attribut A in B umbenannt worden ist5. Der Buchsta-be rho (ρ) erinnert an rename. Der Typ der Ergebnisrelation ist, alsAttributmenge aufgefaßt, gleich ( R − { A }) ∪ { B }.

Wir wenden die Umbenennungsoperation auch auf Relationennamenan. Sei r eine Relation vom Typ R , s ein Name, der bisher keineRelation benennt, dann ist

ρ s ( r )

eine Relation namens s mit Typ R und dem gleichen Inhalt wie r.

3.5 Das Kreuzprodukt

Eine sehr häufige praktische Aufgabe besteht darin, Tupel aus verschie-denen Relationen zu neuen Tupeln zu “verbinden”; Beispiele werden wirerst später besprechen.Das Verbinden von Einzelelementen zu einem Tupel ist durch das

mathematische Kreuzprodukt hinlänglich bekannt und wurde bereitsbeim Relationsbegriff ausgenutzt. Es liegt nahe, statt einzelner Werte-bereiche auch ganze Relationen durch das mathematische Kreuzproduktzu verbinden. Seien also r1 , . . . , rn Relationen, dann können wirfolgendes mathematische Kreuzprodukt bilden:

r 1 × . . .× r n

Dies ist aber leider keine Relation im Sinne der relationalen Algebra:Ein Tupel in diesem Kreuzprodukt hat die Form

(t1, . . . , tn)

5Diese Definition ist formal nicht sauber, sollte aber dennoch präzise verständlichsein. Eine formal saubere Definition bedingt einen wesentlich höheren notationellenAufwand; Tupel müssen dann als Abbildungen von Mengen von Attributnamen inMengen von Wertemengen definiert werden (wie z.B. in [Vo99]). Da dieser nota-tionelle Aufwand keinen signifikanten Gewinn an Präzision bringt, andererseits derintuitiven Verständlichkeit abträglich ist, wird er hier vermieden.



wobei ti ein Tupel aus Ri ist; als Elemente relationaler Tupelsind aber nur elementare Datentypen zugelassen. Wir hätten auch einProblem, den Relationentyp dieses Kreuzprodukts zu benennen.

Ein Lösungsansatz besteht darin, die Tupel ti , ..., tn zu “konkate-nieren”, also ein einziges neues Tupel zu bilden. Diese Idee funktioniertaber nur dann, wenn keine Attributnamen doppelt auftreten, also wenndie Typen der beteiligten Relationen paarweise disjunkt sind. Unterdieser Annahme können wir das relationale Kreuzprodukt folgen-dermaßen definieren:

r 1 × . . .× r n = {< t1 | . . . | tn > | t i ∈ r i }Darin ist < t1 | . . . | tn > die Konkatenation der einzelnen Tupel. DerTyp des Kreuzprodukts ist die Vereinigung der Ri , 1 ≤ i ≤ n.

Die Bildung eines Kreuzprodukts veranschaulicht Bild 2 am Beispielzweier Relationen, die 3 bzw. 2 Tupel enthalten; der Aufbau der Tupelinteressiert hier nicht, der Inhalt ist mit “aa”, “bb” usw. nur angedeutet.

=X

cc

aaxx

yy

cc

cc

bb

bb

aaaa

yy

xx

yy

xx

yy

xx

bb

Abbildung 2: Beispiel eines Kreuzprodukts

Da jedes Tupel der ersten Relation mit jedem Tupel der zweitenkombiniert wird, gilt folgende Formel:

| r× s |= | r | ∗ | s |Darin bezeichnet | r | die Anzahl der Tupel einer Relation r .Die “Länge” der Ergebnistupel (gemessen in der Zahl der Attribu-

te) ist gleich der Summe der Längen der Argumenttupel. Bei derKreuzproduktbildung entstehen also sehr viele und lange Tupel6.

6Deshalb wird das Kreuzprodukt in der Praxis auch fast nie wirklich berech-



Wir hatten unser relationales Kreuzprodukt bisher nur unter der An-nahme definieren können, daß die Typen der beteiligten Relationenpaarweise disjunkt sind; diese Annahme ist natürlich nicht immer er-füllt. Die Lösung besteht darin, die Attribute, die in mehr als einerRelation auftreten, automatisch umzubenennen, in dem wir die den Re-lationsnamen getrennt durch einen Punkt voranstellen. Hierzu müssenwir nachfolgende Restriktionen für die Syntax von Namen einführen:

- Relationsnamen dürfen keinen Punkt enthalten.- Ein Attribut kann einen lokalen oder globalen Namen haben. Ein

lokaler Name enthält keinen Punkt. Ein globaler Name besteht auseinem Relationsnamen gefolgt von einem Punkt und einem lokalenAttributnamen.

- Ein Relation darf nicht zugleich ein Attribut mit einem globalenNamen der Form r.A und ein Attribut mit dem lokalen Namen Ahaben.

Bei der Bildung von r 1 × . . .× r n somit immer dann, wenn ri einAttribut A und eine andere Relation rj , j 6= i, ein Attribut mit Na-men A oder x.A hat, in ri das Attribut A zu ri.A umbenannt. D.h. wirführen innerhalb der Operationsausführung und vor der eigentlichenBildung des Kreuzprodukts die Umbenennung

ρA→r.A (r)

durch. Unter der Annahme, daß alle auftretenden Relationsnamenverschieden sind, sind anschließend alle Attributnamen eindeutig.

Natürlich können die betroffenen Attribute auch explizit vor der Bil-dung des Kreuzprodukts umbenannt werden, wenn die automatische(implizite) Umbenennung im Einzelfall unpassend ist.

Gelegentlich will man auch das Kreuzprodukt einer Relation mit sichselbst bilden. Dies verbieten wir hier und verlangen, daß in solchen

net. Im Rahmen der Optimierung werden Kreuzprodukte, die in einer vorgegebenenAbfrage auftreten, praktisch immer zu Verbundoperationen umgeformt; letzterelassen sich meist effizient berechnen. Mit relationalen Abfragesprachen kann man(bzw. sollte man oft sogar) Abfragen formulieren, die auf den ersten Blick extremineffizient aussehen. Wir gehen hierauf in Abschnitt 3.9 noch näher ein.



Fällen zunächst explizit eine der Relationen umbenannt wird, so daßletztlich alle involvierten Relationen eindeutige Namen bekommen.

3.6 Verbundoperationen

3.6.1 Beispiel

Wir betrachten nun das schon angekündigte Beispiel, bei dem Daten,die in verschiedenen Relationen stehen, zusammenzuführen sind. Wirführen hierzu eine weitere Relation lieferungen ein, die folgendenRelationentyp hat:

Lieferungen = ( Datum: date;Wert: real;Kundennummer: integer;Lager: string;Lieferadresse: string )

Ein Tupel dieses Typs zeigt an, daß am angegebenen Datum Waren imangegebenen Gesamtwert an den Kunden, der durch die Kundennummeridentifiziert wird, geliefert worden sind, und zwar vom angegebenenLager aus an die angegebene Lieferadresse. Der Inhalt der Relationlieferungen sei wie in Bild 3 angegeben.

Tabelle: lieferungenDatum Wert Kundennummer Lager Lieferadresse00-08-12 2730.00 167425 Mitte Bahnhofstr. 500-08-14 427.50 167425 Nord Luisenstr. 1300-08-02 1233.00 171876 West Bergstr. 33

Abbildung 3: Beispieltabelle für Lieferungen

Wir wollen nun eine Relation erzeugen (und anzeigen oder aus-drucken), in der für alle Lieferungen Datum, Wert und der Name desKunden angezeigt werden. Den Namen des Kunden mit einer gegebenen



Kundennummer können wir anhand der Relation kunden herausfin-den. Wir können das gesuchte Resultat in mehreren Schritten wie folgtkonstruieren:

1. Wir müssen Daten aus verschiedenen Relationen in einzelnen Tupelnzusammenbringen. Der einzige Operator, der dies leistet, ist das re-lationale Kreuzprodukt. Wir bilden also zuerst das Kreuzproduktvon lieferungen und kunden :

r1 = lieferungen × kunden

Dieser erste Schritt kann im Prinzip ein extrem großes Zwischen-ergebnis erzeugen. Dies braucht uns aber nicht zu stören, wie wirspäter sehen werden, wird dieses Zwischenergebnis infolge internerOptimierungen nicht wirklich erzeugt.

Die beiden Relationen haben das Attribut Kundennummer gemein-sam. Gemäß der definierten Funktionsweise des Kreuzprodukts istdieses Attribut automatisch in lieferungen.Kundennummer bzw.kunden.Kundennummer umbenannt worden.

2. In r1 ist jedes Lieferungstupel mit jedem Kundentupel kombi-niert worden. Die meisten dieser Kombinationen sind für unserenZweck unsinnig und daher überflüssig; wir interessieren uns nur fürdie Kombinationen, bei denen lieferungen.Kundennummer undkunden.Kundennummer den gleichen Wert haben, denn nur hier sinddie richtigen Kundendaten und Lieferungsdaten kombiniert. Wirbilden also

r2 = σ lieferungen.Kundennummer= kunden.Kundennummer ( r1 )

3. In r2 sind die Spalten lieferungen.Kundennummer und kun-den.Kundennummer identisch: dies war gerade die Selektionsbedin-gung. Eine der beiden Spalten ist offensichtlich entbehrlich und kannentfernt werden. Der lange Attributname der verbliebenen Spalteist dann nicht mehr notwendig, wir können wieder den ursprüngli-chen Namen verwenden. Wir gehen nun so vor, daß wir zuerst eineder Spalten in den ursprünglichen Namen umbenennen:

r3 = ρlieferungen.Kundennummer→Kundennummer ( r2 )



4. Die überflüssige Spalte mit dem langen Namen können wir nunentfernen, indem wir einfach auf die Vereinigung der beiden Relatio-nentypen projizieren:

r4 = πLieferungen∪ Kunden ( r3 )

5. Zum Schluß entfernen wir noch die nicht benötigten Attribute; ge-fragt war nur nach Datum, Wert und Kundennamen:

r5 = πDatum,Wert,Kundenname ( r4 )

Unser Endresultat sieht folgendermaßen aus:

Tabelle: r5Datum Wert Kundenname00-08-12 2730.00 Schneider, Peter00-08-14 427.50 Schneider, Peter00-08-02 1233.00 Litt, Michael

3.6.2 Der natürliche Verbund

Das vorige Beispiel weist eine sehr häufig auftretende Problemstruk-tur auf: die Werte in der Spalte Kundennummer in der Relationlieferungen kann man als “Referenzen” auf Tupel in der Relati-on kunden ansehen7. Unsere Absicht war es, zu jedem Tupel inlieferungen die dort stehende Referenz auf ein Kundentupel zu ver-folgen und Daten aus diesem Kundentupel hinten an das Lieferungstupelanzuhängen – so hätte man es auch von Hand gemacht (s. auch Bild4). Letztlich verbinden wir solche Paare von je einem Lieferungstupelund einem Kundentupel, die im gemeinsamen Attribut Kundennummerden gleichen Wert haben.

7Die Denkweise in Referenzen unterstellt, daß die Kundennummern in der Rela-tion kunden eindeutig sind, daß also eine bestimmte Kundennummer höchstenseinmal in der Spalte Kundennummer in der Relation kunden auftritt. Dies trifft inder Praxis auf fast alle Verbundbildungen zu, ist aber nicht zwingend erforderlich.



..... .....

..... .....

177180

177180 177180

Abbildung 4: Auflösung einer “Referenz”

Der natürliche Verbund (natural join) verallgemeinert diesen Vor-gang; er faßt die obigen Schritte 1 bis 4 zu einer einzigen Operationzusammen. Sie wird mit dem Zeichen on notiert. Mit Hilfe des natürli-chen Verbunds können wir das Beispiel in Abschnitt 3.6.1 wesentlicheinfacher lösen, und zwar wie folgt:

πDatum,Wert,Kundenname ( lieferungen on kunden )

Definition: Gegeben seien zwei Relationen r und s mit den Re-lationentypen R bzw. S .Sei V = R ∩ S die Menge der Verbundattribute. Es kann be-liebig viele Verbundattribute geben, i.a. ist also V = {v1,...,vn}.Dann ist:

r on s = π R∪ S (ρ r.V→ V (σ r.V=s.V ( r × s )))

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 Verbundattri-buten übereinstimmen.

Die Schreibweise ρ r.V→ V (...) ist eine Kurzform für

ρr.v1→v1(. . . (ρr.vn→vn(...)) . . .)

In dem Sonderfall, daß R und S disjunkt sind, also V die leereMenge ist, ist im obigen Ausdruck die Selektionsbedingung leer, d.h.die selektierten Tupel müssen keine Bedingung erfüllen, es wird also



nichts weggefiltert. Bei V = ∅ bilden auch die darauf folgende Projek-tion und die Umbenennung ihre Argumente identisch ab, der natürlicheVerbund verhält sich dann also wie das Kreuzprodukt.Wie schon oben erwähnt ist es nicht zulässig, das Kreuzprodukt

einer Relation mit sich selbst zu bilden, stattdessen muß wenigstens ei-ne der Relationen vorher umbenannt werden. Dies gilt auch für dennatürlichen Verbund. Wenn man dies tut, also z.B.

r on ρ s ( r )bildet, erhält man als Ergebnis genau r (s. folgende Übungsaufgaben),d.h. ein Verbund einer Relation mit sich selbst ist überflüssig.

Übungsaufgabe: Zeigen Sie, daß der natürliche Verbund eine kom-mutative Operation ist, d.h. für beliebige Relationen (oder besser gesagtTabellen) r und s gilt:

r on s = s on r

Übungsaufgabe: Zeigen Sie, daß der natürliche Verbund eine asso-ziative Operation ist, d.h. für beliebige Relationen r , s und tgilt:

( r on s ) on t = r on ( s on t )

Übungsaufgabe: Zeigen Sie, daß im Sonderfall R = S der Ver-bund den Durchschnitt der beiden Relationen bildet, also:

R = S ⇒ r on s = r ∩ s

Übungsaufgabe: Berechnen Sie unter Nutzung des Ergebnisses dervorigen Übungsaufgabe r on ρ s ( r ).

Verbundpartner. Ein sehr simpler Algorithmus zur Implementie-rung des Verbunds r on s arbeitet wie folgt:- man durchläuft alle Tupel t ∈ r ,- für jedes t durchläuft man alle Tupel u ∈ s , und- für die Tupel u, die zusammen mit t die Verbundbedingung erfüllen,

gibt man ein Ergebnistupel aus.



Das geschachtelte Durchlaufen beider Relationen entspricht der Bil-dung eines Kreuzprodukts. Jedes Ergebnistupel enthält natürlich dieAttributwerte gemäß t und u.Im Endeffekt realisiert man damit für jedes t ∈ r eine lineare Su-

che nach den Verbundpartnern von t in s . Verbundpartner vont sind diejenigen Tupel u ∈ s , für die gilt: u [V] = t [V] . Diese Mengekönnen wir auch als Abfrage formulieren:

σ s.V=t[ V ]( s )

Häufige Denkfehler. Das obige Beispiel, in dem wir den Verbundder Relationen lieferungen und kunden gebildet haben, enthältMerkmale, die in der Praxis sehr häufig auftreten. Diese Merkmale wer-den sehr leicht irrtümlich zu notwendigen Voraussetzungen erklärt oderfalsch interpretiert; die häufigsten Denkfehler in diesem Zusammenhangsind:

1. Denkfehler: Im Beispiel und in ca. 99 % aller praktischen Fällehat man genau ein Verbundattribut. Dies wird oft fälschlicherwei-se als Voraussetzung angesehen! Der Verbund ist für beliebig vieleVerbundattribute definiert, auch für V = ∅!

2. Denkfehler: Wenn keine Verbundattribute vorhanden sind, alsoV = ∅, dann findet ein Tupel in r scheinbar keine Verbundpartnerin s , also ist r on s = ∅. Dies ist falsch.

Wenn V = ∅, dann ist die Menge der Verbundpartner von t, wieoben definiert, σ s. ∅=t[∅]( s ). Darin verstehen wir s.∅ als “leeresTupel mit 0 Attributen”. Offensichtlich ist damit die Bedingung s.∅= t[∅] für jedes beliebige u erfüllt, d.h. in Wirklichkeit sind für einbeliebiges t ∈ r alle u ∈ s Verbundpartner, und r on s = r × s .

3. Denkfehler: Im obigen Beispiel und in fast allen praktischen Fällenist das Verbundattribut in einer der beiden Relationen eindeutig.Dies haben wir auch unterstellt, als wir oben die Kundennummernin der Relation lieferungen als “Referenzen” auf genau ein Tu-pel in kunden interpretiert haben. Diese Eindeutigkeit ist abernicht notwendig. Wie schon bei der Definition des Begriffs Verbund-



partner gesehen kann ein t ∈ r beliebig viele Verbundpartner in shaben.

3.6.3 Der Theta-Verbund

Beim natürlichen Verbund wurden bei der Prüfung, ob ein Paar vonTupeln verbunden werden soll,

- der Vergleichsoperator = benutzt, und- es wurde jeweils das gleiche Attribut in beiden Tupeln für den Ver-

gleich herangezogen.

Dies wird beim Θ- (Theta-) Verbund dahingehend verallgemeinert,

- daß irgendein Vergleichsoperator Θ ∈ {=, 6=, <,≤, >,≥} benutztwird und

- daß unterschiedliche Attribute in beiden Tupeln für den Vergleichherangezogen werden.

Wenn r und s Relationen vom Typ R bzw. S sind und A ∈R und B ∈ S Attribute mit gleichem Wertebereich, dann ist einTheta-Verbund wie folgt definiert:

r onr.AΘ s.B s := σr.AΘ s.B ( r × s )

Man kann geteilter Meinung darüber sein, ob der Theta-Verbund vieleinbringt; eine wesentliche Ersparnis an Schreibarbeit und ein dement-sprechender Gewinn an Übersichtlichkeit der Ausdrücke – die ein großerVorteil des natürlichen Verbundes sind – tritt hier jedenfalls nicht ein.

Ein Gleichheitsverbund (equi-join) ist ein Theta-Verbund mit demVergleichsoperator =.

3.6.4 Äußere Verbunde

Wir betrachten noch einmal das Beispiel in Abschnitt 3.6.1 und nehmenan, in der Relation kunden sei das Tupel mit der Kundennummer167425 gelöscht worden. Wenn wir jetzt wieder den Verbund

lieferungen on kunden



bilden, würden die beiden ersten Tupel in der Relation lieferungen(s. Bild 3) keinen Verbundpartner mehr finden und dementsprechendherausfallen. Dies ist aber oft nicht erwünscht. Wenn der Kundenna-me nicht ermittelt werden kann, sollte der Sachverhalt, daß der Wertunbekannt ist, angezeigt werden, etwa in folgender Form:

Datum Wert Kunden-nummer

Lieferadresse Kundenname

00-08-12 2730.00 167425 Bahnhofstr. 5 NULL00-08-14 427.50 167425 Luisenstr. 13 NULL00-08-02 1233.00 171876 Bergstr. 33 Litt, Michael

Der Text NULL soll einen Nullwert darstellen; dieser drückt aus,daß der tatsächliche Attributwert unbekannt ist.In der vorstehenden Tabelle haben wir bei den Tupeln aus liefe-

rungen (also dem linken Verbundargument), die keinen Verbundpart-ner gefunden haben, einen künstlichen Verbundpartner benutzt. DieseArt von Verbund nennt man linken äußeren Verbund.Analog wird beim rechten äußeren Verbund für Tupel des rech-

ten Verbundarguments ggf. ein künstlicher Verbundpartner benutzt.Der äußere Verbund ist die Vereinigung von linkem und rechtemäußeren Verbund.

3.7 Die Division

Das Kreuzprodukt ist in gewisser Weise vergleichbar mit einer Multi-plikation; im Kreuzprodukt r × s wird jedes Tupel aus r mitjedem Tupel aus s kombiniert (s. auch Bild 2). Die relationale Divi-sion kann man sich als eine Art inverse Operation zum Kreuzproduktvorstellen.Hierzu betrachten wir das Beispiel in Bild 2 noch einmal genauer.

Jedes der Tupel “aa”, “bb” und “cc” der linken Relation führt zu einemeigenen Abschnitt im Ergebnis (in Bild 2 jeweils durch einen kleinenZwischenraum abgesetzt): die linken Hälften der Tupel eines Abschnittsenthalten alle das gleiche, z.B. “aa”, die schattiert dargestellten rechten



Hälften bilden eine Kopie der rechten Argumentrelation. Diese rechteHälfte eines Abschnitts wiederholt sich wie ein Stempelabdruck immerwieder.

Bei der Umkehrung der Kreuzproduktbildung suchen wir sozusagennach Stempelabdrücken (s. Bild 5):

xxdd

=:

yy

xx

cc

aa

yy

xx

zz

xx

yy

xxaaaa

bb

bb

cc

cczzcc

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”. Für “aa” ist ein kompletter Stempelabdruck vorhanden, für “bb”und “dd” nur ein unvollständiger, “bb” und “dd” sind daher nicht imErgebnis enthalten. Die Tupel “bb/xx” und “dd/xx” tragen somit nichtzum Ergebnis bei, ebenfalls nicht das Tupel “bb/zz”, da “zz” nicht imDivisor auftritt. Die relationale Division ähnelt insofern der ganzzah-ligen Division ohne Rest. Wegen dieses Rests erhält man, wenn manden Quotienten wieder mit dem Divisor multipliziert, i.a. nur noch eineTeilmenge des ursprünglichen Dividenden:

( 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 genaudann im Ergebnis enthalten, wenn {t} × s ⊆ x , also wenn für alle t’∈ s gilt: < t | t′ >∈ x . Bildlich gesprochen enthält das Ergebnisdiejenigen “linken Hälften” von Tupeln aus x , die mit allen “rechtenHälften” aus s kombiniert in x auftreten.

Anwendungsbeispiel. Als Anwendungsbeispiel für die Division be-trachten wir eine Relation konten , die Angaben zu den Konten einerBank enthält und die folgenden Relationentyp hat:

Konten = ( Kontonummer: integer;Kundennummer: integer;Filialenname: string )

Der Filialenname gibt den Namen der Filiale an, bei der das Kontogeführt wird. Ein Kunde kann bei einer Filiale beliebig viele Kontenhaben. Gesucht sind nun die Kunden, die bei allen Filialen wenigstensein Konto haben. Für die Lösung unserer Aufgabe bilden wir zunächstdie Relation

kundeFiliale = πKundennummer,Filialenname ( konten )

Diese enthält genau dann ein Tupel < k, f >, wenn der Kunde k we-nigstens ein Konto in der Filiale f hat. Die Liste aller Filialen erhaltenwir als eine 1-spaltige Tabelle mittels:

filialen = πFilialenname ( kundeFiliale )

Die Kunden, die in jeder Filiale ein Konto haben, erhalten wir nunmehrdurch:

kundeFiliale ÷ filialen



Das Typische an unserem Anwendungsbeispiel war, daß ein all-Quantor bei der Beschreibung der gesuchten Daten benutzt wurde(“Kunden, die bei allen Filialen ein Konto haben”). Für derart spezi-fizierte Suchergebnisse kann man generell die Division einsetzen. Inden Selektionsbedingungen einer Selektion ist ein all-Quantor nichterlaubt; die Division bietet daher einen Ersatz. Ein Ersatz für denExistenz-Quantor ist nicht notwendig, denn dieser wird implizit durchdie Selektion realisiert.

Berechnung von x ÷ s : x ÷ s kann direkt durch Ausnutzung derDefinition algorithmisch berechnet werden:

- Man bildet π R ( x ) als die Menge der Kandidaten, die im Ergebnisenthalten sein könnten.

- Für jedes t ∈ π R ( x ) prüft man, ob {t} × s ⊆ x . Falls ja, kommt tin die Ergebnismenge.

Die Division ist aber auch, was man spontan vielleicht nicht erwar-ten würde, zurückführbar auf die früher definierten Operationen. Zuberechnen sei also x ÷ s . Sei R = X − S und

r = π R ( x )

r enthält alle “Kandidaten”, die im Ergebnis sein könnten. r isti.a. eine Obermenge von x ÷ s , denn r kann Tupel enthalten, fürdie {t} × s ⊆ x nicht gilt. Um diese Tupel (“durchgefallene Kandi-daten”) zu finden, benutzen wir einen Trick: Wir bilden zunächst dieRelation r × s . Sei nun

inv = ( r × s )− x

inv ist die Invertierung von x in r × s . Wir betrachtenden Inhalt von inv an einem Auszug unseres Beispiels aus Bild 5.Wir können hier 2 Fälle unterscheiden, die in Bild 6 veranschaulichtsind:

1. Für den Kandidaten t = “aa” sind alle Kombinationen mit denTupeln des Divisors in x vorhanden, und es gilt: {t} × s ⊆ x .



(r x s) x (r x s) − x

aaaa

bb

bb yy

xx

yy

xx aaaa

bb

bb zz

xx

yy

xx

bb yy

Abbildung 6: relationale Division

inv enthält daher kein Tupel der Form “aa/...”, weil alle der-artigen Tupel aus r × s auch in x vorhanden sind und somitabgezogen wurden.

2. Für den Kandidaten t = “bb” sind nicht alle Kombinationen mit denTupeln des Divisors vorhanden, und es gilt: {t} × s 6⊆ x .

In inv bleibt daher wenigstens eine der fehlenden Kombinatio-nen ü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 zuvielsind. Unser Endresultat ist also

x ÷ s = r − π R ( inv )

bzw. x ÷ s = π R ( x )− π R ((π R ( x )× s )− x )

3.8 Relationale Vollständigkeit

Wir haben inzwischen eine Reihe von Operationen mit Relationen ken-nengelernt und schon bei den relativ komplizierten Verbundoperationenund der Division bemerkt, daß wir sie auf die einfacheren Operationen

σ, π, ρ,∪,−,×

zurückführen konnten. Die Verbundoperationen und die Division mö-gen zwar die Formulierung mancher Abfragen erleichtern, sie erweiterndie Fähigkeiten der relationalen Algebra aber nicht wirklich, d.h. es gibtkein Suchproblem, das nur mit ihrer Hilfe lösbar wäre. Dieser Effekt ist



auch bei diversen weiteren Operationen, die man sich noch ausdenkenkann, zu beobachten.Hieraus schlußfolgert man, daß die Ausdruckskraft, die durch die

vorstehende Operationenmenge erreicht wird, einerseits ausreichendfür eine große Klasse von Problemen, andererseits ein Minimum anAusdruckskraft ist, das von jeder Abfragesprache für relationale Da-tenbanken erreicht werden sollte; solche Sprachen nennt man daherrelational vollständig8.

Die Operationenmenge {σ, π, ρ,∪,−,×} ist übrigens minimal in demSinne, daß keine der Operationen auf die anderen zurückführbar ist; je-de echte Teilmenge wäre nicht mehr relational vollständig. Wir hättenalternativ statt des Kreuzprodukts zuerst den natürlichen Verbund ein-führen können und hätten dann das Kreuzprodukt auf den natürlichenVerbund zurückgeführt; die Operationenmenge {σ, π, ρ,∪,−,on} ist alsoeine andere minimale, relational vollständige Operationenmenge.

3.9 Ausdrücke in der relationalen Algebra

Wie schon einleitend erwähnt setzen wir bei der relationalen Algebraeine existierende Datenbank, also ein konzeptuelles Schema und dazupassende existierende Relationen, voraus. Hierdurch ist eine Menge vonNamen von Relationen und Attributen vorgegeben. Diese Namen kön-nen wir nun an passender Stelle in den Operationen der relationalenAlgebra einsetzen. Überall dort, wo eine relationale Operation eine Re-lation als Argument benötigt, kann natürlich wiederum ein relationalerAusdruck eingesetzt werden.

Syntaktisch korrekte Ausdrücke sind analog zu arithmetischen Aus-drücken in gängigen Programmiersprachen definiert. Details der Synta-xdefinition und -prüfung und Übersetzung interessieren uns an dieserStelle nicht, und wir setzen i.f. syntaktisch korrekte Ausdrücke voraus.

Ausdrücke werden klassischerweise von innen nach außen ausgewer-8Diese Bezeichnung ist insofern irreführend, als eine praxisgerechte Sprache viele

über die zentralen Abfrageoperationen hinausgehende Funktionen anbieten muß,s. Abschnitt 1. So gesehen sind die Operationen der relationalen Algebra ziemlichunvollständig.



tet. Die entstehenden Zwischenresultate müssen gepuffert werden.Diese Zwischenresultate können, wenn Verbunde oder Kreuzprodukteauftreten, extrem groß werden, d.h. man kann erhebliche Performance-Probleme bekommen, wenn man einen relationalen Ausdruck in kano-nischer Weise auswertet.

Man kann das Ergebnis eines relationalen Ausdrucks oft effizienter be-rechnen als durch eine kanonische Auszuwertung; die Bestimmung eineseffizienteren Rechenverfahrens bezeichnet man als Optimierung. Durchdie Optimierung ist es vielfach möglich, auch äußerlich “ineffiziente”Ausdrücke recht effizient auszuwerten. Die entscheidende Konsequenzhieraus ist, daß man bei der Formulierung relationaler Abfragen zu-nächst keine Rücksicht auf Ineffizienz bei der kanonischen Auswertungnehmen sollte und sich stattdessen besser auf die inhaltliche Korrektkeitdes Ausdrucks konzentieren sollte. Lösungen, die klar und korrekt, aber“ineffizient” sind, sind vielfach kompakter und deswegen leichter für Op-timierer behandelbar als “effiziente” komplizierte (und schlimmstenfallsinkorrekte) Lösungen.

Wenn der Optimierer der Datenbank wider Erwarten doch keine effi-ziente Ausführung findet – Wunder wirken können Optimierer nicht,und nicht jedes DBMS hat einen guten Optimierer – , kann man ineinem zweiten Schritt immer noch versuchen, durch Umformung derAnfrage die eigentliche Arbeit des Optimierers doch selbst von Handzu erledigen.

4 Schlüssel

Wir hatten schon in Abschnitt 2.3 Identifizierungsschlüssel als eine ty-pische Integritätsbedingung erwähnt; nachdem wir nun die Operationender relationalen Algebra kennen, können wir einige Schlüsselbegriffeleichter exakt definieren.

4.1 Superschlüssel und Identifizierungsschlüssel

Wir betrachten noch einmal die Relation kunden in Bild 1. Von demAttribut Kundennummer verlangten wir schon früher, daß es “eindeutig”



sein sollte, m.a.W. daß zu jeder Kundennummer höchstens ein Tupelvorhanden sein sollte. Eine Kundennummer identifiziert also, sofernvorhanden, genau ein Tupel. Formal läßt sich dies so ausdrücken:

kn ∈ πKundennummer (kunden) ⇒ | σKundennummer=kn (kunden) |= 1

Die vorstehende Bedingung ist äquivalent zu der folgenden kompakterenBedingung (Beweis: Übungsaufgabe):

| πKundennummer (kunden) | = | kunden |

Das Attribut Wohnort hat diese Eigenschaft offensichtlich nicht. Eskönnte aber sein, daß die beiden Attribute Wohnort und Kundennamezusammen die Identifizierungseigenschaft haben. Generell kann einebeliebige Menge von Attributen zur Identifikation von Tupeln verwen-det werden. Eine derartige Menge von Attributen nennen wir einenSuperschlüssel. Die formale Definition lautet:

Sei R ein Relationentyp, K ⊆ R eine Attributmenge. Wenn Kein Superschlüssel für R ist, dann gilt für jede korrekte Relation rmit dem Relationentyp R stets folgendes:

| πK (r) | = | r |

Die Attribute in K nennen wir auch Schlüsselattribute. Bildlich ge-sprochen gehen beim Projizieren auf einen Superschlüssel keine Tupelverloren, weil eben keine Kombination der Werte der Schlüsselattributedoppelt auftritt.

Der seltsam klingende Name Superschlüssel rührt daher, daß dieAttributmenge gemäß der vorstehenden Definition auch “überflüssige”Attribute enthalten kann, die für die Identifikation eigentlich nicht ge-braucht werden. Ein extremes Beispiel ist die Attributmenge R; R istimmer ein Superschlüssel für R , sofern die Relation eine Menge ist9.

Ein Identifizierungsschlüssel ist eine minimale Menge von Attri-buten, die Superschlüssel ist.

9Manche DBMS erlauben Tupel-Duplikate, in solchen Fällen existiert kein einzi-ger Superschlüssel.



Für unsere Relation kunden sind {Kundennummer} und {Kundenna-me, Wohnort} Identifizierungsschlüssel. Wenn zusätzlich die Personal-ausweisnummer zu jedem Kunden vorhanden wäre, wäre {Personal-ausweisnummer} ein weiterer Identifizierungsschlüssel. Dieses Beispielzeigt, daß es für einen Relationentyp mehrere Identifizierungsschlüsselgeben kann.

Die Bezeichnung Schlüssel wird meist als Synonym zu Identifizie-rungsschlüssel verstanden. Unter einem Schlüsselwert bei einem Tupelt verstehen wir die Menge der Attributwerte von t bei den Attributendes Identifizierungsschlüssels.

Es sei noch einmal daran erinnert, daß Schlüsseleigenschaften Inte-gritätsbedingungen, also vom Anwender definierte Anforderungen sind.Zu der Erkenntnis, daß eine Attributmenge K ein Identifizierungs-schlüssel ist, kommt man nicht etwa dadurch, daß man den Zustandder Datenbank eine Zeitlang beobachtet und währenddessen dauerndkontrolliert, ob die Identifizierungseigenschaft erfüllt ist. Es ist genauumgekehrt: die Identifizierungseigenschaft wird vorgegeben, und dasDBMS hat dafür zu sorgen, daß unerwünschte Zustände verhindertwerden.

Das DBMS muß bei jedem Einfügen eines neuen Tupels oder Änderneines vorhandenen Tupels für jeden Identifizierungsschlüssel prüfen, obder neue Schlüsselwert schon in der Relation auftritt. Diese Prüfungkann so implementiert werden, daß die ganze Relation linear durchsuchtwird. Dies ist i.a. (außer bei kleinen Relationen) zu ineffizient, dahermuß für einen Identifizierungsschlüssel praktisch immer ein Verzeichnisangelegt werden, in dem die aktuell vorhandenen Schlüsselwerte ver-zeichnet sind und das effizient durchsuchbar ist (z.B. als Baumstrukturoder Hash-Tabelle)10. Dieses Verzeichnis muß bei allen Datenänderun-gen entsprechend aktualisiert werden. Sofern eine Relation mehrere

10Eine effiziente Suche wird z.B. auch durch die sortierte Speicherung nach demIdentifizierungsschlüssel ermöglicht; allerdings machen hier Einfügungen und Lö-schungen Probleme. Derartige Implementierungstechniken sind kein Thema diesesLehrmoduls.



Identifizierungsschlüssel hat, muß für jeden ein eigenes Verzeichnis dervorhandenen Schlüsselwerte angelegt werden.

Viele DBMS erlauben es, Relationen zu definieren, die keinen ein-zigen Identifizierungsschlüssel haben. Eine derartige Relation kannTupelduplikate enthalten. Auch die Gesamtmenge aller Attribute bildethier keinen Schlüssel, denn dann wären keine Duplikate erlaubt.

4.2 Primärschlüssel

Die Verzeichnisse für die Identifizierungsschlüssel kosten Platz undRechenzeit, man würde sie daher lieber vermeiden. Dies ist in derTat bei vielen internen Speicherstrukturen möglich. Bei den folgen-den Annahmen und Implementierungsentscheidungen bekommt mandie Eindeutigkeitsprüfung praktisch gratis:

1. jedes Tupel wird in einem Speichersatz gespeichert (vgl. [DBSA]),2. die Relation wird in einem B*-Baum gespeichert,3. der Identifizierungsschlüssel ist einelementig (enthält also nur ein

Attribut),4. man verwendet die Schlüsselwerte der Tupel als Schlüsselwerte im

B*-Baum.

Diese sehr effiziente Prüfung der Schlüsseleigenschaft ist aber nur beieinem einzigen Identifizierungsschlüssel möglich. Wenn man mehrereIdentifizierungsschlüssel hat, muß man für die übrigen nach wie vorseparate Verzeichnisse anlegen.

Als Primärschlüssel bezeichnet man denjenigen Identifizierungs-schlüssel, für den die Möglichkeit der sehr effizienten Prüfung derSchlüsseleigenschaft ausgenutzt werden soll. Welche Implementierungs-techniken hierzu verwendet werden, bleibt eine Entscheidung des DBMS-Herstellers.Neben der Prüfung der Schlüsseleigenschaft ist natürlich bei einem

Primärschlüssel auch die Suche nach dem Tupel, das einen bestimmtenWert bei diesem Attribut hat, besonders effizient möglich. DerartigeSuchvorgänge sind z.B. bei der Verbundbildung nötig (s. das Beispiel



in Abschnitt 3.6.1). Daher wird man, sofern mehrere Identifizierungs-schlüssel vorhanden sind, denjenigen als Primärschlüssel auswählen,mit dem häufig Verbunde gebildet werden. In den meisten Fällen hatman aber ohnehin nur einen einzigen Identifizierungsschlüssel, der dannautomatisch als Primärschlüssel zu wählen ist.

Die vorstehenden Beobachtungen zeigen, daß die Festlegung desPrimärschlüssels eine Implementierungsentscheidung ist, die für diekonzeptionelle Struktur der Datenbank unerheblich ist. Im Sinne der3-Ebenen-Schema-Architektur (s. Abschnitt 5.2) gehört die Festlegungdes Primärschlüssels also zum internen Schema. Im Gegensatz dazugehören Identifizierungsschlüssel zum konzeptuellen Schema.

Leider wird zwischen den Ebenen oft nicht sauber getrennt. Die Be-zeichnung Schlüssel wird vielfach auch als Synonym zu Primärschlüsselverstanden.Eine wesentliche Ursache für diese Vermischung von Begriffen liegt

darin, daß man beim Entwurf der konzeptuellen Schemata durchausRücksicht auf deren Implementierung nehmen muß; dies ist nicht ganzkonsistent mit der Idealvorstellung, wonach die konzeptuellen und im-plementierungsbezogenen Aspekte völlig getrennt voneinander auf denbeiden unteren Ebenen der 3-Ebenen-Schema-Architektur behandeltwerden können. Betrachten wir hierzu wieder das Beispiel in Bild 1.Einer der Identifizierungsschlüssel war {Kundenname, Wohnort}. Die-ser Identifizierungsschlüssel ist i.a. als Primärschlüssel ungeeignet, weilhier die internen Schlüsselwerte als Konkatenation der beiden Attribut-werte gebildeten werden müßten und weil diese Zeichenketten relativlang werden können. Aus Effizienzgründen erlauben Implementierun-gen von B*-Bäumen und ähnlichen internen Strukturen ggf. nur relativkurze Schlüsselwerte fester Länge, z.B. ganze Zahlen mit 4 oder 8 BytesLänge oder Zeichenketten mit 8 Zeichen.Sofern die “natürlichen” Identifizierungsschlüssel alle als Primär-

schlüssel ungeeignet sind, muß man ein künstliches Schlüsselattributerfinden; hierauf gehen wir in Abschnitt 4.4 ausführlicher ein.



4.3 Fremdschlüssel

Identifizierungsschlüssel einer Relation werden oft von einer anderen Re-lation aus “referenziert”. In unserer Relation lieferungen kam z.B. dasAttribut Kundennummer vor, das Identifizierungsschlüssel in kunden ist.Es sollte offensichtlich keine Lieferung geben, bei der die Kundennum-mer “ins Leere zeigt”, weil sie in kunden nicht auftritt. Die Abwesenheitsolcher Datenfehler bezeichnet man auch als referentielle Integrität.Formal formuliert fordern wir folgende Mengeninklusion:

πKundennummer (lieferungen) ⊆ πKundennummer (kunden)

Kundennummer bezeichnen wir als Fremdschlüssel in der Relation lie-ferungen. Alle Werte, die im Attribut Kundennummer in lieferungenauftreten, müssen auch im Attribut Kundennummer in kunden auftreten.Die allgemeine Definition ist: sei K eine Attributmenge, r eine Re-

lation mit dem Relationentyp R, K ⊆ R, s eine andere Relation mitdem Relationentyp S und K ein Identifizierungsschlüssel in S. Wenn KFremdschlü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, gelöschtwerden, und

2. daß Tupel in r erzeugt werden, bei denen der Wert der Fremdschlüs-selattribute kein Tupel in s referenziert.

Nullwerte sollten in Fremdschlüsseln vermieden werden. Wenn mansie zuläßt, bedeutet ein Nullwert, daß unbekannt ist, welches andereTupel referenziert wird.

4.4 Kriterien für die Festlegung von Identifizierungs-und Primärschlüsseln

Identifizierungsschlüssel werden häufig als Fremdschlüssel in anderenRelationen benutzt; hieraus ergeben sich mehrere Kriterien, die bei derFestlegung von Identifizierungsschlüsseln beachtet werden sollten:



- Können die Werte beim Eintragen immer sofort bestimmt wer-den? Man kann theoretisch auch Nullwerte bei Schlüsselattributenzulassen, praktisch stört dies aber sehr. U.a. können keine Fremd-schlüssel-Referenzen auf dieses Tupel in anderen erzeugt werden.

- Sind die Werte kurz und schreibbar? Dies betrifft wieder den Fall,daß in anderen Relationen Fremdschlüssel-Referenzen von Handeingetragen werden müssen.

- Sind die Werte “sprechend”, d.h. ist den Systembenutzern intuitivverständlich, welche reale Entität durch ein Tupel dargestellt wird?Diese Anforderung steht oft im Widerspruch zu den beiden ersten.

Ein weiteres Kriterium betrifft die zeitliche Entwicklung des Daten-bankinhalts. Die aktuell in einem Identifizierungsschlüssel auftretendenWerte müssen natürlich eindeutig sein; zusätzlich kann es sinnvoll sein,die Eindeutigkeit über die Zeit hinweg zu verlangen. Beispielsweisekönnte Kundenname ein Identifizierungsschlüssel sein und derzeit eineKundin “Meier, Anna” vorhanden sein. Diese wird irgendwann gelöscht,und ein Jahr später wird eine andere, neue Kundin eingetragen, die zu-fällig genauso heißt. Wenn man derartiges vermeiden will, dürfen einmalbenutzte Identifizierungsschlüsselwerte nicht wiederverwendet werden.Hierzu müßte ein Verzeichnis aller jemals verwendeten Identifizierungs-schlüsselwerte geführt werden, was sehr aufwendig und platzraubendsein kann.

Die vorstehenden Anforderungen werden oft von “natürlichen” Iden-tifizierungsschlüsseln, die sich aus einer von Implementationsaspektenunbeeinflußten Datenmodellierung ergeben, nicht erfüllt. Beispielswei-se sind textuelle Namen zwar oft gut verständlich, aber zu lang undwiederverwendbar.Im Endergebnis entscheidet man sich daher oft dazu, ein künstli-

ches Schlüsselattribut, meist eine laufende Nummer, zu erfinden. DasAttribut Kundennummer ist ein Beispiel hierfür, denn “von Natur aus”haben Kunden keine Nummer.



4.5 Weitere Schlüsselbegriffe

Sofern mehrere Identifizierungsschlüssel vorhanden sind, werden sieoft auch als Schlüsselkandidaten bezeichnet. Jeder Identifizierungs-schlüssel ist ein Kandidat dafür, Primärschlüssel zu werden, nur einerschafft es. Diese Bezeichnung vermengt die konzeptuelle und interneBegriffs- und Denkwelt besonders stark, weshalb wir sie weitgehendvermeiden werden.

Ein Sortierschlüssel (sort key) bestimmt die Reihenfolge, in derdie Speichersätze in einem DB-Segment gespeichert werden. Hierdurchkann die Verarbeitung kompletter Relationen beschleunigt werden. EinSortierschlüssel muß nicht unbedingt identifizierend sein.

Ein Sekundärschlüssel (secondary key) ist eine Menge von Attribu-ten, für die ein Sekundärindex vorhanden ist. Ein Sekundärschlüssel isti.a. nicht identifizierend. Der Sekundärindex ist eine Datenstruktur, diejedem Sekundärschlüsselwert eine Liste der Sätze bzw. Tupel zuordnet,bei denen die entsprechenden Attributwerte auftreten. Beispielsweisekönnte es sinnvoll sein, bei der Relation konten einen Sekundärindexfür das Attribut Kundenname einzurichten; dies beschleunigt die Suchenach den Kunden mit einem bestimmten Namen erheblich.

Die folgende Tabelle stellt noch einmal alle Schlüsselbegriffe zusam-men und gibt jeweils an, ob es sich um einen Begriff der konzeptuellenoder internen Ebene in der 3-Ebenen-Schema-Architektur handelt undob die Attribute identifizierend sind.

Begriff Ebene identifizierendIdentifizierungsschlüssel logisch jaSuperschlüssel logisch jaSchlüsselkandidat logisch jaFremdschlüssel logisch neinPrimärschlüssel intern meistSekundärschlüssel intern neinSortierschlüssel intern nein



Implementierungen für Primärschlüssel sind meist so gestaltet, daßdie Eindeutigkeit der Schlüsselwerte erzwungen wird. Man kann aberauch leicht Varianten dieser Implementierungen bilden, bei denen meh-rere Sätze mit dem gleichen Primärschlüsselwert vorhanden sein dürfen,die dann beim Lesen als Gruppe behandelt werden. Bei solchen Imple-mentierungen ist ein Primärschlüssel nicht automatisch auch Identifi-zierungsschlü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 inverszum Kreuzprodukt ist und mit der Suchaufgaben gelöst werden können,die All-Quantoren enthalten

Fremdschlüssel: (Kontext: Attributmenge F in Relation R1 ist Fremd-schlüssel auf eine Relation R2) Menge von Attributen, die Tupel ineiner anderen Relation identifizieren sollen; ist eine Integritätsbedin-gung, wonach die Projektion von R1 auf F komplett in der Projektionvon R2 auf F enthalten ist

Identifizierungsschlüssel: minimale Menge von Attributen, die ein Super-schlüssel ist

Primärschlüssel: Attribut (-kombination), die der Primärindex unterstütztProjektion: Operation der relationalen Algebra, mit der in den Tupeln ei-

ner Eingaberelation Attribute entfernt werden können; entstehendeDuplikate werden eliminiert



relationale Algebra: Algebra mit den Kernfunktionen relationaler Daten-banksysteme im Bereich der Abfragedienste, insb. Selektion, Pro-jektion, Mengenoperationen, Kreuzprodukt, natürlicher bzw. Theta-Verbund und Division

Relationenschema: Namen und Typen der Attribute einer Relation; Syn-onyme: Relationentyp, Relationenformat

Schlüssel: Oberbegriff für mehrere spezielle Schlüsselbegriffe; oft als Syn-onym für Identifizierungsschlüssel benutzt

Schlüsselkandidat: Synonym für IdentifizierungsschlüsselSekundärschlüssel: Attribut (-kombination), für die ein Sekundärindex

vorhanden istSelektion: Operation der relationalen Algebra, mit der Tupel einer Einga-

berelation anhand einer Bedingung selektiert werden könnenSortierschlüssel: Attribut (-kombination), nach der intern sortiert gespei-

chert wirdSpalte (column): einer Tabelle; Synonym: AttributSuperschlüssel: Menge von Attributen, deren Werte die Tupel einer Rela-

tion eindeutig identifizierenTabelle (table): Hauptbestandteile einer relationalen Datenbank; wird oft

als Synonym zu Relation benutztVerbund: Operation der relationalen Algebra, mit der die Tupel zweier Ein-

gaberelationen paarweise verbunden werden, sofern sie eine Verbund-bedingung erfüllen; beim Theta-Verbund wird die Verbundbedingungexplizit vorgegeben, beim Gleichheitsverbund werden Attribute derzu verbindenden Tupel auf Gleichheit getestet, beim natürlichen Ver-bund werden nur Tupel verbunden, die in allen Attributen, die beidenRelationen gemeinsam sind, jeweils die gleichen Werte haben

Verbund, äußerer: der linke (rechte) äußere Verbund ist eine Variante dernormalen Verbunde, bei denen Tupel der linken (rechten) Eingaberela-tion, die keinen Verbundpartner in der rechten (linken) Eingaberelationfinden, ergänzt um Nullwerte bei den fehlenden Attributen, zum Er-gebnis hinzugenommen werden; der beidseitige äußere Verbund liefertdie Vereinigung des rechten und linken äußeren Verbunds

Zeile (row): einer Tabelle; Synonym: Tupel


Index|

..|, 15

3-Ebenen-Schema-Architektur, 34, 37

Administration, 3Attribut, 4, 39

Reihenfolge, 5Wertebereich, 6Wertzuweisung, 5

B*-Baum, 33

Datenbank, 4Datenbankmodell

konventionelles, 3relationales, 3

Datenbanksprache, 3Division, 24, 38Duplikate, 5, 7

equi-join, 23

Fremdschlüssel, siehe Schlüssel

Gleichheitsverbund, 23

Identifizierungsschlüssel, siehe Schlüs-sel

Integritätsbedingung, 8Überprüfung, 8dynamische, 8statische, 8

Kalkül, siehe relationale KalküleKreuzprodukt, 14, 21, 24

natural join, 20

Notationskonventionen, 7Nullwert, 24

Optimierung, 30

Primärschlüssel, siehe SchlüsselProjektion, 10, 38

Rechteverwaltung, 3referentielle Integrität, 35Relation, 6relationale Algebra, 9, 38

äußerer Verbund, 23Ausdrücke, 29

Auswertung, 29Differenz, 12Division, 24Gleichheitsverbund, 23Kreuzprodukt, 14natürlicher Verbund, 19Projektion, 10Schnitt, 12Theta-Verbund, 23Umbenennung, 13Vereinigung, 12

relationale Kalküle, 3relationale Vollständigkeit, 29Relationenschema, 6, 39Relationentyp, 6

als Menge von Attributen, 7

Schema, 3Schlüssel, 30, 32, 34, 39

als Integritätsbedingungen, 32Fremdschlüssel, 35, 37, 38Identifizierungsschlüssel, 31, 38

Auswahlkriterien, 35

40


künstlicher, 34Prüfung, 32Wiederverwendung von Schlüs-

selwerten, 36Primärschlüssel, 33, 34, 37, 38

Auswahl, 33Schlüsselattribut, 31Schlüsselkandidat, 37, 39Sekundärschlüssel, 37, 39Sortierschlüssel, 37, 39Superschlüssel, 31, 37, 39

Schlüsselkandidat, siehe SchlüsselSchlüsselwert, 32secondary key, 37Sekundärschlüssel, siehe SchlüsselSelektion, 9, 39

Bedingung mit all-Quantor, 26sort key, 37Sortierschlüssel, siehe SchlüsselSpalte, 4, 39Superschlüssel, siehe Schlüssel

t[A], 11Tabelle, 4, 39Tupel, 6, 39

Umbenennung, 13

Verbund, 39äußerer, 23, 39Gleichheits-, 23, 39natürlicher, 19, 39Theta-, 23, 39

Verbundattribute, 20Vollständigkeit, 28

Zeile, 4, 39


Das relationale...

Documents

Transcript of Das relationale...