Das relationale Datenbankmodell

Transkript

1 Das relationale Datenbankmodell Udo Kelter 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 Integritätsbedingungen werden hier nur Schlüsselbegriffe behandelt; wir unterscheiden u.a. Identifikations-, Super-, Fremd-, Primär- und Sekundärschlüssel. Vorausgesetzte Lehrmodule: obligatorisch: Datenverwaltungssysteme Stoffumfang in Vorlesungsdoppelstunden: 2.0 1

2 Das relationale Datenbankmodell 2 Inhaltsverzeichnis 1 Datenbankmodelle vs. reale Datenbanksprachen 3 2 Die Struktur relationaler Datenbanken Tabellen Relationen Integritätsbedingungen Die relationale Algebra Die Selektion Die Projektion Die Mengenoperationen Die Umbenennung Das Kreuzprodukt Verbundoperationen Beispiel Der natürliche Verbund Der Theta-Verbund Äußere Verbunde Die Division Relationale Vollständigkeit Ausdrücke in der relationalen Algebra Schlüssel Superschlüssel und Identifizierungsschlüssel Primärschlüssel Fremdschlüssel Kriterien für die Festlegung von Identifizierungs- und Primärschlüsseln Weitere Schlüsselbegriffe Literatur Glossar Index Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer oder gedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenommen werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarf der expliziten Genehmigung. Die jeweils aktuellste Version ist über erreichbar.

3 Das relationale Datenbankmodell 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] zurü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 vielfältige Erweiterungen der ursprünglichen Konzepte vorgeschlagen. In der Praxis ist das relationale Datenbankmodell heute dominierend. Eine Vielzahl kommerzieller oder kostenloser relationaler DBMS ist verfügbar. 1 Datenbankmodelle vs. reale Datenbanksprachen Das relationale Datenbankmodell legt zunächst nur zentrale, grundlegende Konzepte fest (s. Begriff Datenbankmodell in [DVS]), nämlich die Struktur einer Datenbank und lesende Operationen auf dieser Struktur. Ein praktisch benutzbares System muß zusä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 unterstützt, die konkrete Syntax und technische Details können ganz erheblich differieren (for (..,..,..) {.. } in C; WHILE... BEGIN... END in Modula-2). Neben den Abfragen und Datenänderungen mü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. Ähnlich wie Programmiersprachen sind daher die konkreten Abfragesprachen für relationale Systeme äußerlich sehr verschieden und differieren auch außerhalb der grundlegenden

4 Das relationale Datenbankmodell 4 Konzepte in vielen technischen Details. Für die Darstellung der grundlegenden Konzepte braucht man natürlich dennoch Notationen, also eine Sprache. Die relationale Algebra und die relationalen Kalküle kann man in diesem Sinne als Sprachen ansehen, die nur den Kern des relationalen Datenbankmodells abdecken und von jeglichem störenden Ballast befreit sind. 2 Die Struktur relationaler Datenbanken 2.1 Tabellen Die statische Struktur einer relationalen Datenbank kann man informell wie folgt definieren (eine präzisere Definition folgt spä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 enthält beliebig viele Zeilen; jede Zeile enthält in jeder Spalte einen Wert entsprechend dem Wertebereich der Spalte. Tabelle: kunden Kundennummer Kundenname Wohnort Kreditlimit Meier, Anne Weidenau Büdenbender, Christa Siegen Stötzel, Gyula Siegen Schneider, Peter Netphen Litt, Michael Siegen 0.00 Abbildung 1: Beispieltabelle

5 Das relationale Datenbankmodell 5 Als Beispiel betrachten wir eine Tabelle kunden, in der Daten über die Kunden eines Unternehmens verwaltet sein mö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. Über Längenbeschränkungen der Texte oder die Genauigkeit der Zahlen machen wir uns an dieser Stelle keine Gedanken. Eine Zeile repräsentiert oft eine Entität in der realen Welt, in unserem Beispiel repräsentiert jede Zeile einen Kunden. Wenn die Tabelle zwei völlig gleiche Zeilen enthalten würde, wäre der gleiche Sachverhalt doppelt repräsentiert; dies wäre sinnlos, Duplikate von Zeilen werden daher nicht erlaubt. Die Spalten enthalten die Beschreibungsmerkmale der repräsentierten Entität. Interessant ist hier die Beobachtung, daß die Reihenfolge der Spalten unwesentlich ist, die folgende Tabelle ist zu der vorstehenden offenbar äquivalent: Tabelle: kunden Wohnort Kundennummer Kundenname Kreditlimit Weidenau Meier, Anne Siegen Büdenbender, Christa Eine Zeile können wir daher auch als eine Menge von Attributzuweisungen auffassen, z.b. die erste Zeile als: Kundennummer = ; Wohnort = Weidenau; Kundenname = Meier, Anne ; Kreditlimit = Während die Reihenfolge der Attribute aus einer konzeptuellen Sichtweise irrelevant ist, ist sie für die physische Speicherung i.a. relevant. Beide Sichtweisen müssen aber strikt getrennt werden; Datenbankmodelle definieren nur konzeptuelle Aspekte, die physische Speicherung bleibt hier völlig außer Betracht.

6 Das relationale Datenbankmodell 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 D 1 D 2... D n Ein Element einer Relation nennt man Tupel. Den Inhalt der letzten Tabelle kö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 Ä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 Relationen 1. Unsere erste Version der Kundentabelle führt also zu folgendem Relationentyp: 1 In erweiterten relationalen Modellen, die wir hier nicht behandeln, können Attribute dagegen strukturierte Typen haben.

7 Das relationale Datenbankmodell 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 gemäß 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. Für die Erklärung des relationalen Datenbankmodells werden wir allerdings wiederholt Relationentypen benötigen, so daß wir auf diesen Begriff nicht 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 von Relationentyp R sein soll, ist wegen des Rü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

8 Das relationale Datenbankmodell 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 Integritätsbedingungen Es gibt sehr viele Arten, Integritätsbedingungen in relationalen Datenbanken zu formulieren; es ist ein bißchen Geschmackssache, wieviele davon man zum Kern des relationalen Datenbankmodells zählt. Man kann die Integritätsbedingungen grob wie folgt einteilen: Dynamische Integritätsbedingungen schränken die erlaubten Zustandsübergänge bei Änderungen der Daten ein. Beispielsweise könnte bei einem Attribut Familienstand der Übergang von verheiratet nach ledig verboten sein. Dynamische Integritätsbedingungen werden wir nicht weiter betrachten. Statische Integritätsbedingungen schränken den erlaubten Zustand einer Datenbank weiter ein. Das bekannteste Beispiel sind (Identifizierungs-) Schlüssel. Integritätsbedingungen können allenfalls bei Änderungen an den Daten verletzt werden. Ein DBMS muß daher bei allen ändernden Operationen entsprechende Prüfungen durchführen und die Operation ggf. mit einem Fehlercode zurückweisen. Lesende Operationen sind dagegen überhaupt nicht von Integritätsbedingungen betroffen: diese Operationen arbeiten auf beliebigen Datenbankinhalten, also erst recht auf der Teilmenge der korrekten Datenbankinhalte. Aus diesem Grunde sind Integritätsbedingungen für die nachfolgende Diskussion der relationalen Algebra nicht erforderlich. 2 Technisch wäre es kein Problem, auch Multimengen zuzulassen. In der Praxis erspart man sich aus Performancegründen oft die Eliminierung von Duplikaten. Wie schon erwähnt sind aber Duplikate von Tupeln i.a. nicht sinnvoll.

9 Das relationale Datenbankmodell 9 3 Die relationale Algebra Der Begriff Algebra stammt aus der Mathematik. Eine Algebra ist definiert durch eine Wertemenge 3 und i.a. mehrere Funktionen, die mit Werten dieser Menge arbeiten. Beispiele für Algebren sind die reellen Zahlen oder Matrizen zusammen mit den diversen Rechenoperationen. Die Funktionen können beliebig viele Argumente haben und liefern stets einen Wert aus der Wertemenge zurück. Daher kann man Funktionsaufrufe schachteln und Ausdrü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 mögen, braucht uns nicht weiter zu stören. Die relationale Algebra enthält keine Operationen, mit denen man Relationen erzeugen bzw. löschen und in einer Relation Tupel einfügen, löschen oder verändern kann. Derartige Operationen müssen in realen Sprachen natü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 gefüllt worden sind. Analog gilt dies für die Relationentypen, also das konzeptuelle Schema der Datenbank. Die Operationen der relationalen Algebra entsprechen nicht unzufä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. Zurückgeliefert wird eine neue Relation, die nur 3 Dies gilt für eine einsortige Algebra. Mehrsortige Algebren arbeiten mit mehreren Wertemengen, die hier als Sorten bezeichnet werden.

10 Das relationale Datenbankmodell 10 die Tupel enthält, die das Selektionskriterium erfüllen. Notiert wird die Selektion ü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 größer als 5000 DM ist. Folgender Ausdruck liefert eine Relation mit genau diesen Kunden: Die entstehende Tabelle ist σ Kreditlimit> ( kunden ) Tabelle: σ Kreditlimit> ( kunden ) Kundennummer Kundenname Wohnort Kreditlimit Büdenbender, Christa Siegen Schneider, Peter Netphen 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 möglich. Ferner können so geformte elementare Bedingungen mit den Booleschen Operatoren (,, ) und Klammern zu Ausdrücken zusammengesetzt werden. Die Bedingungen dürfen sich natürlich nur auf solche Attribute beziehen, die im Typ der Argumentrelation vorkommen. Übungsaufgabe: Zeigen Sie, daß die und-verküpfung von zwei Bedingungen durch eine Hintereinanderschaltung von zwei Selektionen mit den einzelnen Bedingungen ersetzt werden kann, daß also für eine beliebige Relation r und Bedingungen B1 und B2 gilt: σ B1 B2 ( r ) = σ B1 (σ B2 ( r )) = σ B2 (σ B1 ( r ))

11 Das relationale Datenbankmodell Die Projektion Die Projektion löst das Problem, überflüssige Attribute in den Tupeln einer Relation zu entfernen. Man projiziert eine Relation auf die Attribute, 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 beiden anderen Attribute bzw. Spalten sollen wegprojiziert werden. Dies erreichen wir mit folgender Ausdruck: Die entstehende Tabelle ist: π Kundenname,Wohnort ( kunden ) Tabelle: π Kundenname,Wohnort ( kunden ) Kundenname Wohnort Meier, Anne Weidenau Büdenbender, Christa Siegen Stötzel, Gyula Siegen Schneider, Peter Netphen Litt, Michael Siegen Das Ergebnis einer Projektion hat i.a. nicht den gleichen Relationentyp wie die Argumentrelation 4. Der Typ der Ergebnisrelation hat genau die in der Projektion angegebenen Attribute. Für die formale Definition der Projektion benö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 für die Attribute in A gemäß t enthält. Mit dieser Notation kö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.

12 Das relationale Datenbankmodell 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: Die entstehende Tabelle ist: π Wohnort ( kunden ) 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 t 1, t 2 R, t 1 t 2, können nach der Projektion gleich sein und führen daher nur zu einem einzigen Tupel in der Ergebnisrelation. Übungsaufgabe: Seien P, Q und R Relationentypen, r eine Relation 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 automatisch alle Mengenoperationen auf Relationen anwendbar. Voraussetzung ist natü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.

13 Das relationale Datenbankmodell 13 Als Beispiel betrachten wir wieder die Relation kunden in Bild 1. Wir suchen jetzt die Kunden, die in Weidenau wohnen oder ein Kreditlimit > haben. Hierzu definieren wir die Relation k1 wie folgt: k1 = σ Wohnort= W eidenau ( kunden ) σ Kreditlimit=10000 ( kunden ) Das Ergebnis ist: Tabelle: k1 Kundennummer Kundenname Wohnort Kreditlimit Meier, Anne Weidenau Schneider, Peter Netphen Wir hätten dieses Ergebnis natürlich auch mit der folgenden Definition erzielen können; k1 = σ Wohnort= W eidenau Kreditlimit=10000 ( kunden ) Übungsaufgabe: Zeigen Sie, daß die oder-verküpfung von zwei Bedingungen durch eine Vereinigung von zwei Selektionen mit den einzelnen Bedingungen ersetzt werden kann, daß also für eine beliebige Relation r und Bedingungen B1 und B2 gilt: 3.4 Die Umbenennung σ B1 B2 ( r ) = σ B1 ( r ) σ B2 ( r ) Aus technischen Gründen benötigen wir fü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 ist 5. Der Buchstabe rho 5 Diese Definition ist formal nicht sauber, sollte aber dennoch präzise verständlich sein. Eine formal saubere Definition bedingt einen wesentlich höheren notationellen Aufwand; Tupel müssen dann als Abbildungen von Mengen von Attributnamen in Mengen von Wertemengen definiert werden (wie z.b. in [Vo99]). Da dieser notac 2002 Udo Kelter Stand:

14 Das relationale Datenbankmodell 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 häufige praktische Aufgabe besteht darin, Tupel aus verschiedenen Relationen zu neuen Tupeln zu verbinden ; Beispiele werden wir erst später besprechen. Das Verbinden von Einzelelementen zu einem Tupel ist durch das mathematische Kreuzprodukt hinlä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 r 1,..., r n Relationen, dann können wir folgendes 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 (t 1,..., t n ) wobei t i ein Tupel aus R i ist; als Elemente relationaler Tupel sind aber nur elementare Datentypen zugelassen. Wir hätten auch ein Problem, den Relationentyp dieses Kreuzprodukts zu benennen. Ein Lösungsansatz besteht darin, die Tupel t i,..., t n 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 Präzision bringt, andererseits der intuitiven Verständlichkeit abträglich ist, wird er hier vermieden.

15 Das relationale Datenbankmodell 15 Unter dieser Annahme können wir das relationale Kreuzprodukt folgendermaßen definieren: r 1... r n = { < t 1... t n > t i r i } Darin ist < t 1... t n > die Konkatenation der einzelnen Tupel. Der Typ des Kreuzprodukts ist die Vereinigung der R i, 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 X xx yy = aa aa 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 Länge der Ergebnistupel (gemessen in der Zahl der Attribute) ist gleich der Summe der Längen der Argumenttupel. Bei der Kreuzproduktbildung entstehen also sehr viele und lange Tupel 6. Wir hatten unser relationales Kreuzprodukt bisher nur unter der Annahme definieren können, daß die Typen der beteiligten Relationen paarweise disjunkt sind; diese Annahme ist natü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 näher ein.

16 Das relationale Datenbankmodell 16 erfüllt. Die Lösung besteht darin, die Attribute, die in mehr als einer Relation auftreten, umzubenennen. Sei A ein solches Attribut; dann wird A in jeder Relation r i, in deren Typ A vorkommt, zu r i. A umbenannt, d.h. wir führen vor der eigentlichen Bildung des Kreuzprodukts die Umbenennung ρ A r i. A ( r i ) durch. Unter der Annahme, daß die Namen aller r i verschieden sind, sind anschließend alle Attributnamen eindeutig. Wenn die vorstehende automatische Umbenennung von Attributen im Einzelfall unpassend ist, können natürlich die betroffenen Attribute auch explizit vor der Bildung des Kreuzprodukts umbenannt werden. Gelegentlich will man auch das Kreuzprodukt einer Relation mit sich selbst bilden. Dies verbieten wir hier und verlangen, daß in solchen Fällen zunächst explizit eine der Relationen umbenannt wird, so daß letztlich alle involvierten Relationen eindeutige Namen bekommen. 3.6 Verbundoperationen Beispiel Wir betrachten nun das schon angekündigte Beispiel, bei dem Daten zu einer Entität, die in verschiedenen Relationen stehen, zusammenzuführen sind. Wir führen hierzu eine weitere Relation lieferungen ein, die folgenden Relationentyp hat: Lieferungen = ( Datum: date; Wert: real; Lager: integer; Kundennummer: string; Lieferadresse: string ) Ein Tupel dieses Typs zeigt an, daß an den durch die Kundennummer identifizierten Kunden am angegebenen Datum Waren im angegebenen Gesamtwert geliefert worden sind, und zwar vom angegebenen Lager aus an die angegebene Lieferadresse. Der Inhalt der Relation lieferungen sei wie in Bild 3 angegeben.

17 Das relationale Datenbankmodell 17 Tabelle: lieferungen Datum Wert Kundennummer Lager Lieferadresse Mitte Bahnhofstr Nord Luisenstr West Bergstr. 33 Abbildung 3: Beispieltabelle für Lieferungen Nehmen wir nun an, wir wollten eine Relation erzeugen (und anzeigen oder ausdrucken), in der für alle Lieferungen Datum, Wert und der Name des Kunden angezeigt werden. Den Namen der Kunden mit einer gegebenen Kundennummer können wir anhand der Relation kunden herausfinden. Wir können das gesuchte Resultat in mehreren Schritten wie folgt konstruieren: 1. Wir bilden das Kreuzprodukt von lieferungen und kunden : r1 = lieferungen kunden Die beiden Relationen haben das Attribut Kundennummer gemeinsam. Nach unseren früheren Festlegungen ist das Attribut in lieferungen.kundennummer bzw. kunden.kundennummer umbenannt worden. 2. In r1 ist jedes Lieferungstupel mit jedem Kundentupel kombiniert worden. Die meisten dieser Kombinationen sind für unseren Zweck unsinnig und daher überflüssig; wir interessieren uns nur für die Kombinationen, bei denen lieferungen.kundennummer und kunden.kundennummer den gleichen Wert haben, denn nur hier sind die richtigen Kundendaten und Lieferungsdaten kombiniert. 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

18 Das relationale Datenbankmodell 18 Spalte ist dann nicht mehr notwendig, wir können einfacher wieder den ursprünglichen Namen verwenden. Wir gehen nun so vor, daß wir zuerst eine der Spalten in den ursprünglichen Namen umbenennen: r3 = ρ lieferungen.kundennummer Kundennummer ( r2 ) 4. Die überflüssige Spalte mit dem langen Namen kö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 benö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 Kundenname Schneider, Peter Schneider, Peter Litt, Michael Der natürliche Verbund Das vorige Beispiel weist eine sehr häufig auftretende Struktur auf: die Werte in der Spalte Kundennummer in der Relation lieferungen kann man als Referenzen auf Tupel in der Relation kunden ansehen. Wir unterstellen jetzt einmal, daß die Kundennummern eindeutig sind, daß also eine Kundennummer höchstens einmal in der Spalte Kundennummer in der Relation kunden auftritt. 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 anzuhängen - so hätte man es auch von Hand gemacht (s. auch Bild 4). Letztlich verbinden wir solche Paare von Lieferungstupel und Kundentupel, die im

19 Das relationale Datenbankmodell 19 gemeinsamen Attribut Kundennummer den gleichen Wert haben. Solche Paare von Tupeln bilden Verbundpartner voneinander Abbildung 4: Auflösung einer Referenz Der natürliche Verbund (natural join) verallgemeinert diesen Vorgang; er faßt die obigen Schritte 1 bis 4 zu einer einzigen Operation, die mit dem Zeichen notiert wird, zusammen. Gegeben seien zwei Relationen r und s mit den Relationentypen R bzw. S. Sei V = R S. Dann ist wie folgt definiert: r s = π R S (ρ r.v V (σ r.v=s.v ( r s ))) Die Attribute in V nennt man auch die Verbundattribute. In den meisten Fällen hat man genau ein Verbundattribut, es kann i.a. beliebig viele Verbundattribute geben, also V = {v 1,...,v n }. Die Schreibweise ρ r.v V (...) ist eine Kurzform für Die Schreibweise σ r.v=s.v ρ r.v1 v 1 (... (ρ r.vn v n (...))...) ist eine Kurzform von σ r.v1 =s.v 1... r.v n=s.v n Es werden also nur solche Tupel verbunden, die in allen Verbundattributen übereinstimmen. In dem Sonderfall, daß R und S disjunkt sind, also V die leere Menge ist, ist auch die Selektionsbedingung leer, d.h. die selektierten Tupel müssen keine Bedingung erfüllen, es wird also nichts weggefiltert. Bei V = bilden auch die Projektion und die Umbenennung ihre Argumente identisch ab, der natürliche Verbund verhält sich dann also wie das Kreuzprodukt. Mit Hilfe des natürlichen Verbunds können wir das Beispiel in Abschnitt wesentlich einfacher lösen, und zwar in der Form

20 Das relationale Datenbankmodell 20 π Datum,Wert,Kundenname ( lieferungen kunden ) Übungsaufgabe: Zeigen Sie, daß im Sonderfall R = S der Verbund den Durchschnitt der beiden Relationen bildet, also: R = S r s = r s Übungsaufgabe: Zeigen Sie, daß der natürliche Verbund eine assoziative Operation ist, d.h. für beliebige Relationen r, s und t gilt: Der Theta-Verbund ( r s ) t = r ( s t ) Beim natürlichen Verbund wurden bei der Prüfung, ob ein Paar von Tupeln verbunden werden soll, der Vergleichsoperator = benutzt, und es wurde jeweils das gleiche Attribut in beiden Tupeln für den Vergleich herangezogen. Verbund dahingehend verallgemei- Dies wird beim Θ- (Theta-) nert, daß irgendein Vergleichsoperator Θ {=,, <,, >, } benutzt wird und daß unterschiedliche Attribute in beiden Tupeln fü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 r.a Θ s.b s := σ r.a Θ s.b ( r s ) Man kann geteilter Meinung darüber sein, ob der Theta-Verbund viel einbringt; eine wesentliche Ersparnis an Schreibarbeit und ein dementsprechender Gewinn an Übersichtlichkeit der Ausdrücke die ein großer Vorteil des natürlichen Verbundes sind tritt hier jedenfalls nicht ein.

21 Das relationale Datenbankmodell 21 Ein Gleichheitsverbund (equi-join) ist ein Theta-Verbund mit dem Vergleichsoperator = Äußere Verbunde Wir betrachten noch einmal das Beispiel in Abschnitt und nehmen an, in der Relation kunden sei das Tupel mit der Kundennummer gelöscht worden. Wenn wir jetzt wieder den Verbund lieferungen kunden bilden, würden die beiden ersten Tupel in der Relation lieferungen (s. Bild 3) keinen Verbundpartner mehr finden und dementsprechend herausfallen. Dies ist aber oft nicht erwünscht. Wenn der Kundenname nicht ermittelt werden kann, sollte der Sachverhalt, daß der Wert unbekannt ist, angezeigt werden, etwa in folgender Form: Datum Wert Kundennummer Lieferadresse Kundenname Bahnhofstr. 5 NULL Luisenstr. 13 NULL Bergstr. 33 Litt, Michael Der Text NULL soll einen Nullwert darstellen; dieser drückt aus, daß der tatsä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 künstlichen Verbundpartner benutzt. Diese Art von Verbund nennt man linken äußeren Verbund. Analog wird beim rechten äußeren Verbund für Tupel des rechten 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 Multiplikation; im Kreuzprodukt r s wird jedes Tupel aus r mit jedem

22 Das relationale Datenbankmodell 22 Tupel aus s kombiniert (s. auch Bild 2). Die relationale Division kann man sich als eine Art inverse Operation zum Kreuzprodukt vorstellen. Hierzu betrachten wir das Beispiel in Bild 2 noch einmal genauer. Jedes der Tupel aa, bb und cc der linken Relation führt zu einem eigenen Abschnitt im Ergebnis (in Bild 2 jeweils durch einen kleinen Zwischenraum abgesetzt): die linken Hälften der Tupel eines Abschnitts enthalten alle das gleiche, z.b. aa, die schattiert dargestellten rechten Hälften bilden eine Kopie der rechten Argumentrelation. Diese rechte Hälfte eines Abschnitts wiederholt sich wie ein Stempelabdruck immer wieder. Bei der Umkehrung der Kreuzproduktbildung suchen wir sozusagen nach Stempelabdrücken (s. Bild 5): aa aa bb bb cc cc cc dd xx yy xx zz xx yy zz xx : 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 ist für aa ein kompletter Stempelabdruck vorhanden, für bb und dd nur ein unvollstä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 ähnelt insofern der ganzzahligen Division ohne Rest. Wegen

23 Das relationale Datenbankmodell 23 dieses Rests erhält man, wenn man den Quotienten wieder mit dem Divisor multipliziert, i.a. nur noch eine Teilmenge 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 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 für alle t s gilt: < t t > x. Bildlich gesprochen enthält das Ergebnis diejenigen linken Hälften von Tupeln aus x, die mit allen rechten Hälften aus s kombiniert in x auftreten. Anwendungsbeispiel. Als Anwendungsbeispiel für die Division betrachten wir eine Relation konten, die Angaben zu den Konten einer Bank 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 Konto gefü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. Für die Lösung unserer Aufgabe bilden wir zunächst die Relation kundefiliale = π Kundennummer,Filialenname ( konten ) Diese enthä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 )

24 Das relationale Datenbankmodell 24 Die Kunden, die in jeder Filiale ein Konto haben, erhalten wir nunmehr durch: 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 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 fü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 berechnet werden: Man bildet π R ( x ) als die Menge der Kandidaten, die im Ergebnis enthalten sein könnten Für jedes t π R ( x ) prüft man, ob {t} s x. Die Division ist aber auch, was man spontan vielleicht nicht erwarten würde, zurückführbar auf die früher definierten Operationen. Zu berechnen sei also x s. Sei R = X S und r = π R ( x ) r enthält i.a. eine Obermenge von x s, r kann Tupel enthalten, für die {t} s x nicht gilt. Um diese Tupel zu finden, benutzen wir einen Trick: Wir bilden zunä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. inv enthält kein Tupel der Form aa/..., weil alle derartigen Tupel in r s auch in x vorhanden sind und somit abgezogen wurden. Für Tupel der Form bb/... gilt dies nicht: es bleibt eines übrig. Beide Fälle sind in Bild 6 veranschaulicht.

25 Das relationale Datenbankmodell 25 aa aa bb bb (r x s) x (r x s) x xx yy xx yy aa aa bb bb xx yy xx zz bb yy Abbildung 6: relationale Division Die Tupel in π R ( inv ) sind somit gerade diejenigen, die in r zuviel sind. 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 kennengelernt und schon bei den relativ komplizierten Verbundoperationen und 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 erweitern die Fähigkeiten der relationalen Algebra aber nicht wirklich, d.h. es gibt kein Suchproblem, das nur mit ihrer Hilfe lösbar wä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 für eine große Klasse von Problemen, andererseits ein Minimum an Ausdruckskraft ist, das von jeder Abfragesprache für relationale Datenbanken erreicht werden sollte; solche Sprachen nennt man daher

26 Das relationale Datenbankmodell 26 relational vollständig 7. Die Operationenmenge {σ, π, ρ,,, } ist übrigens minimal in dem Sinne, daß keine der Operationen auf die anderen zurückführbar ist, jede echte Teilmenge wäre nicht mehr relational vollständig. Wir hätten alternativ statt des Kreuzprodukts zuerst den natürlichen Verbund einführen können und hätten dann das Kreuzprodukt auf den natürlichen Verbund zurückgeführt; die Operationenmenge {σ, π, ρ,,, } ist also eine andere minimale, relational vollständige Operationenmenge. 3.9 Ausdrücke in der relationalen Algebra Wie schon einleitend erwä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 können wir nun an passender Stelle in den Operationen der relationalen Algebra einsetzen. Überall dort, wo eine relationale Operation eine Relation als Argument benötigt, kann natürlich wiederum ein relationaler Ausdruck eingesetzt werden. Syntaktisch korrekte Ausdrücke sind analog zu arithmetischen Ausdrücken in gängigen Programmiersprachen definiert. Details der Syntaxdefinition und -prüfung und Übersetzung interessieren uns an dieser Stelle nicht, und wir setzen i.f. syntaktisch korrekte Ausdrücke voraus. Ausdrücke werden klassischerweise von innen nach außen ausgewertet. Die entstehenden Zwischenresultate müssen gepuffert werden. Diese Zwischenresultate können, wenn Verbunde oder Kreuzprodukte auftreten, extrem groß werden, d.h. man kann erhebliche Performance- Probleme bekommen, wenn man einen relationalen Ausdruck in kanonischer Weise auswertet. Man kann das Ergebnis eines relationalen Ausdrucks oft effizienter 7 Diese 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 ziemlich unvollständig.

27 Das relationale Datenbankmodell 27 berechnen als durch eine kanonische Auszuwertung; die Bestimmung eines effizienteren Rechenverfahrens bezeichnet man als Optimierung. Durch die Optimierung ist es vielfach möglich, auch äußerlich ineffiziente Ausdrücke recht effizient auszuwerten. Die entscheidende Konsequenz hieraus ist, daß man bei der Formulierung relationaler Abfragen zunächst keine Rücksicht auf Ineffizienz bei der kanonischen Auswertung nehmen sollte und sich stattdessen besser auf die inhaltliche Korrektkeit des Ausdrucks konzentieren sollte. Lösungen, die klar und korrekt, aber ineffizient sind, sind vielfach kompakter und deswegen leichter für Optimierer behandelbar als effiziente komplizierte (und schlimmstenfalls inkorrekte) Lösungen. Wenn der Optimierer der Datenbank wider Erwarten doch keine effiziente Ausführung findet Wunder wirken kö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 Schlüssel Wir hatten schon in Abschnitt 2.3 Identifizierungsschlüssel als eine typische Integritätsbedingung erwähnt; nachdem wir nun die Operationen der relationalen Algebra kennen, können wir einige Schlüsselbegriffe leichter exakt definieren. 4.1 Superschlüssel und Identifizierungsschlüssel Wir betrachten noch einmal die Relation kunden in Bild 1. Von dem Attribut Kundennummer verlangten wir schon früher, daß es eindeutig sein sollte, m.a.w. daß zu jeder Kundennummer höchstens ein Tupel vorhanden sein sollte. Eine Kundennummer identifiziert also, sofern vorhanden, 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 kompakc 2002 Udo Kelter Stand:

28 Das relationale Datenbankmodell 28 teren Bedingung (Beweis: Übungsaufgabe): π Kundennummer (kunden) = kunden Das Attribut Wohnort hat diese Eigenschaft offensichtlich nicht. Es kö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 Superschlüssel. Die formale Definition lautet: Sei R ein Relationentyp, K R eine Attributmenge. Wenn K ein Superschlüssel für R ist, dann gilt für jede korrekte Relation r mit dem Relationentyp R stets folgendes: π K (r) = r Die Attribute in K nennen wir auch Schlüsselattribute. Bildlich gesprochen gehen beim Projizieren auf einen Superschlüssel keine Tupel verloren, weil eben keine Kombination der Werte der Schlüsselattribute doppelt auftritt. Der seltsam klingende Name Superschlüssel rührt daher, daß die Attributmenge gemäß der vorstehenden Definition auch überflüssige Attribute enthalten kann, die für die Identifikation eigentlich nicht gebraucht werden. Ein extremes Beispiel ist die Attributmenge R; R ist immer ein Superschlüssel für R, sofern die Relation eine Menge ist (also keine Duplikate erlaubt sind). Ein Identifizierungsschlüssel ist eine minimale Menge von Attributen, die Superschlüssel ist. Für unsere Relation kunden sind {Kundennummer} und {Kundenname, Wohnort} Identifizierungsschlüssel. Wenn zusätzlich die Personalausweisnummer zu jedem Kunden vorhanden wäre, wäre {Personalausweisnummer} ein weiterer Identifizierungsschlüssel. Dieses Beispiel zeigt, daß es für einen Relationentyp mehrere Identifizierungsschlüssel geben kann. Die Bezeichnung Schlüssel wird meist als Synonym zu Identifizierungsschlüssel verstanden. Unter einem Schlüsselwert bei einem

29 Das relationale Datenbankmodell 29 Tupel t verstehen wir die Menge der Attributwerte von t bei den Attributen des Identifizierungsschlüssels. Es sei noch einmal daran erinnert, daß Schlüsseleigenschaften Integritätsbedingungen, also vom Anwender definierte Anforderungen sind. Zu der Erkenntnis, daß eine Attributmenge K ein Identifizierungsschlüssel ist, kommt man nicht etwa dadurch, daß man den Zustand der Datenbank eine Zeitlang beobachtet und währenddessen dauernd kontrolliert, ob die Identifizierungseigenschaft erfüllt ist. Es ist genau umgekehrt: die Identifizierungseigenschaft wird vorgegeben, und das DBMS hat dafür zu sorgen, daß unerwünschte Zustände verhindert werden. Das DBMS muß bei jedem Einfügen eines neuen Tupels oder Ändern eines vorhandenen Tupels für jeden Identifizierungsschlüssel prüfen, ob der neue Schlüsselwert schon in der Relation auftritt. Diese Prü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 für einen Identifizierungsschlüssel ein Verzeichnis angelegt werden, in dem die aktuell vorhandenen Schlüsselwerte verzeichnet sind und das effizient durchsuchbar ist (z.b. als Baumstruktur oder Hash-Tabelle) 8. Dieses Verzeichnis muß bei allen Datenänderungen entsprechend aktualisiert werden. Sofern eine Relation mehrere Identifizierungsschlüssel hat, muß für jeden ein eigenes Verzeichnis der vorhandenen Schlüsselwerte angelegt werden. Viele DBMS erlauben es, Relationen zu definieren, die keinen einzigen Identifizierungsschlüssel haben. Eine derartige Relation kann Tupelduplikate enthalten. Auch die Gesamtmenge aller Attribute bildet hier keinen Schlüssel, denn dann wären keine Duplikate erlaubt. 8 Eine effiziente Suche wird z.b. auch durch die sortierte Speicherung nach dem Identifizierungsschlüssel ermöglicht; allerdings machen hier Einfügungen und Löschungen Probleme. Derartige Implementierungstechniken sind kein Thema dieses Lehrmoduls.

30 Das relationale Datenbankmodell Primärschlüssel Die Verzeichnisse für die Identifizierungsschlüssel kosten Platz und Rechenzeit, man würde sie daher lieber vermeiden. Dies ist in der Tat bei vielen internen Speicherstrukturen mö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 Identifizierungsschlüssel ist einelementig (enthält also nur ein Attribut), 4. man verwendet die Schlüsselwerte der Tupel als Schlüsselwerte im B*-Baum bekommt man die Eindeutigkeitsprüfung praktisch gratis! Diese sehr effiziente Prüfung der Schlüsseleigenschaft ist aber nur bei einem einzigen Identifizierungsschlüssel möglich; wenn man mehrere Identifizierungsschlüssel hat, muß man für die übrigen nach wie vor separate Verzeichnisse anlegen. Als Primärschlüssel bezeichnet man denjenigen Identifizierungsschlüssel, für den die Möglichkeit der sehr effizienten Prüfung der Schlüsseleigenschaft ausgenutzt werden soll. Welche Implementierungstechniken 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 bestimmten Wert bei diesem Attribut hat, besonders effizient möglich. Derartige Suchvorgänge sind z.b. bei der Verbundbildung nötig; s. das Beispiel in Abschnitt Daher wird man, sofern mehrere Identifizierungsschlüssel vorhanden sind, denjenigen als Primärschlüssel auswählen, mit dem häufig Verbunde gebildet werden. In den meisten Fällen hat man aber ohnehin nur einen einzigen Identifizierungsschlüssel, der dann automatisch als Primärschlüssel zu wählen ist. Die vorstehenden Beobachtungen zeigen, daß die Festlegung des Primärschlüssels eine Implementierungsentscheidung ist, die für die konzeptionelle Struktur der Datenbank unerheblich ist. Im Sinne der

31 Das relationale Datenbankmodell 31 3-Ebenen-Schema-Architektur (s. Abschnitt 5.2 in [DVS]) gehört die Festlegung des Primärschlüssels also zum internen Schema. Im Gegensatz dazu gehören Identifizierungsschlüssel zum konzeptuellen Schema. Leider wird zwischen den Ebenen oft nicht sauber getrennt. Die Bezeichnung Schlüssel wird vielfach auch als Synonym zu Primärschlüssel verstanden. Eine wesentliche Ursache für diese Vermischung von Begriffen liegt darin, daß man beim Entwurf der konzeptuellen Schemata durchaus Rücksicht auf deren Implementierung nehmen muß; dies steht etwas im Widerspruch zu der Idealvorstellung, wonach die konzeptuellen und implementierungsbezogenen Aspekte völlig getrennt voneinander auf den beiden unteren Ebenen der 3-Ebenen-Schema-Architektur behandelt werden können. Betrachten wir hierzu wieder das Beispiel in Bild 1. Einer der Identifizierungsschlüssel war {Kundenname, Wohnort}. Dieser Identifizierungsschlüssel ist i.a. als Primärschlüssel ungeeignet, weil hier die internen Schlüsselwerte als Konkatenation der beiden Attributwerte gebildeten werden müßten und weil diese Zeichenketten relativ lang werden können. Aus Effizienzgründen erlauben Implementierungen von B*-Bäumen und ähnlichen internen Strukturen ggf. nur relativ kurze Schlüsselwerte fester Länge, z.b. ganze Zahlen mit 4 oder 8 Bytes Länge oder Zeichenketten mit 8 Zeichen. Sofern die natürlichen Identifizierungsschlüssel alle als Primärschlüssel ungeeignet sind, muß man ein künstliches Schlüsselattribut erfinden; hierauf gehen wir in Abschnitt 4.4 ausführlicher ein. 4.3 Fremdschlüssel Identifizierungsschlüssel einer Relation werden oft von einer anderen Relation aus referenziert. In unserer Relation lieferungen kam z.b. das Attribut Kundennummer vor, das Identifizierungsschlü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 Integrität. Formal formuliert fordern wir folgende Mengeninklusion:

32 Das relationale Datenbankmodell 32 π Kundennummer (lieferungen) π Kundennummer (kunden) Kundennummer bezeichnen wir als Fremdschlüssel in der Relation lieferungen. Alle Werte, die im Attribut Kundennummer in lieferungen auftreten, mü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 Primärschlüssel in S. Wenn K Fremdschlü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öscht werden, und 2. daß Tupel in r erzeugt werden, bei denen der Wert der Fremdschlüsselattribute kein Tupel in s referenziert. Nullwerte sollten in Fremdschlüsseln vermieden werden. Wenn man sie zuläßt, bedeutet ein Nullwert, daß unbekannt ist, welches andere Tupel referenziert wird. 4.4 Kriterien für die Festlegung von Identifizierungsund Primärschlüsseln Identifizierungsschlüssel werden häufig als Fremdschlüssel in anderen Relationen benutzt; hieraus ergeben sich mehrere Kriterien, die bei der Festlegung von Identifizierungsschlüsseln beachtet werden sollten: Können die Werte beim Eintragen immer sofort bestimmt werden? Man kann theoretisch auch Nullwerte bei Schlüsselattributen zulassen, praktisch stört dies aber sehr. U.a. können keine Fremdschlü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 Hand eingetragen werden müssen.

33 Das relationale Datenbankmodell 33 Sind die Werte sprechend, d.h. ist den Systembenutzern intuitiv verstä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 Datenbankinhalts. Die aktuell in einem Identifizierungsschlüssel auftretenden Werte müssen natürlich eindeutig sein; zusätzlich kann es sinnvoll sein, die Eindeutigkeit über die Zeit hinweg zu verlangen. Beispielsweise könnte Kundenname ein Identifizierungsschlüssel sein und derzeit eine Kundin Meier, Anna vorhanden sein. Diese wird irgendwann gelöscht, und ein Jahr später wird eine andere, neue Kundin eingetragen, die zufällig genauso heißt. Wenn man derartiges vermeiden will, dürfen einmal benutzte Identifizierungsschlüsselwerte nicht wiederverwendet werden. Hierzu müßte ein Verzeichnis aller jemals verwendeten Identifizierungsschlüsselwerte geführt werden, was sehr aufwendig und platzraubend sein kann. Die vorstehenden Anforderungen werden oft von natürlichen Identifizierungsschlüsseln, die sich aus einer von Implementationsaspekten unbeeinflußten Datenmodellierung ergeben, nicht erfüllt. Beispielsweise sind textuelle Namen zwar oft gut verständlich, aber zu lang und wiederverwendbar. Im Endergebnis entscheidet man sich daher oft dazu, ein künstliches Schlüsselattribut, meist eine laufende Nummer, zu erfinden. Das Attribut 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 sie oft auch als Schlüsselkandidaten bezeichnet. Jeder Identifizierungsschlüssel ist ein Kandidat dafür, Primärschlü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 Sortierschlüssel (sort key) bestimmt die Reihenfolge, in der

34 Das relationale Datenbankmodell 34 die Speichersätze in einem DB-Segment gespeichert werden. Hierdurch kann die Verarbeitung kompletter Relationen beschleunigt werden. Ein Sortierschlüssel muß nicht unbedingt identifizierend sein. Ein Sekundärschlüssel (secondary key) ist eine Menge von Attributen, für die ein Sekundärindex vorhanden ist. Ein Sekundärschlüssel ist i.a. nicht identifizierend. Der Sekundärindex ist eine Datenstruktur, die jedem Sekundärschlüsselwert eine Liste der Sätze bzw. Tupel zuordnet, bei denen die entsprechenden Attributwerte auftreten. Beispielsweise könnte es sinnvoll sein, bei der Relation konten einen Sekundärindex für das Attribut Kundenname einzurichten; dies beschleunigt die Suche nach den Kunden mit einem bestimmten Namen erheblich. Die folgende Tabelle stellt noch einmal alle Schlü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 Ebene identifizierend Identifizierungsschlüssel logisch ja Superschlüssel logisch ja Schlüsselkandidat logisch ja Fremdschlüssel logisch nein Primärschlüssel intern meist Sekundärschlüssel intern nein Sortierschlüssel intern nein Implementierungen für Primärschlüssel sind meist so gestaltet, daß die Eindeutigkeit der Schlüsselwerte erzwungen wird. Man kann aber auch leicht Varianten dieser Implementierungen bilden, bei denen mehrere Sätze mit dem gleichen Primärschlüsselwert vorhanden sein dürfen, die dann beim Lesen als Gruppe behandelt werden. Bei solchen Implementierungen ist ein Primärschlüssel nicht automatisch auch Identifizierungsschlüssel.

35 Das relationale Datenbankmodell 35 Literatur [Co70] Codd, E.F.: A relational model for large shared data banks; CACM 13:6, p ; 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 gelöst werden können, die All-Quantoren enthalten Fremdschlüssel: (Kontext: Attributmenge F in Relation R1 ist Fremdschlüssel auf eine Relation R2) Menge von Attributen, die Tupel in einer anderen Relation identifizieren sollen; ist eine Integritätsbedingung, wonach die Projektion von R1 auf F komplett in der Projektion von R2 auf F enthalten ist Identifizierungsschlüssel: minimale Menge von Attributen, die ein Superschlüssel ist Primärschlüssel: Attribut (-kombination), die der Primärindex unterstützt Projektion: Operation der relationalen Algebra, mit der in den Tupeln einer Eingaberelation Attribute entfernt werden können; entstehende Duplikate werden eliminiert relationale Algebra: Algebra mit den Kernfunktionen relationaler Datenbanksysteme im Bereich der Abfragedienste, insb. Selektion, Projektion, Mengenoperationen, Kreuzprodukt, natürlicher bzw. Theta- Verbund und Division Relationenschema: Namen und Typen der Attribute einer Relation; Synonyme: Relationentyp, Relationenformat Schlüssel: Oberbegriff für mehrere spezielle Schlüsselbegriffe; oft als Synonym für Identifizierungsschlüssel benutzt Schlüsselkandidat: Synonym für Identifizierungsschlüssel

36 Das relationale Datenbankmodell 36 Sekundärschlüssel: Attribut (-kombination), für die ein Sekundärindex vorhanden ist Selektion: Operation der relationalen Algebra, mit der Tupel einer Eingaberelation anhand einer Bedingung selektiert werden können Sortierschlüssel: Attribut (-kombination), nach der intern sortiert gespeichert wird Spalte (column): einer Tabelle; Synonym: Attribut Superschlü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 erfüllen; beim Theta-Verbund wird die Verbundbedingung explizit vorgegeben, beim Gleichheitsverbund werden Attribute der zu verbindenden Tupel auf Gleichheit getestet, beim natürlichen Verbund werden nur Tupel verbunden, die in allen Attributen, die beiden Relationen gemeinsam sind, jeweils die gleichen Werte haben Verbund, äußerer: der linke (rechte) ä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, ergänzt um Nullwerte bei den fehlenden Attributen, zum Ergebnis hinzugenommen werden; der beidseitige äußere Verbund liefert die Vereinigung des rechten und linken äußeren Verbunds Zeile (row): einer Tabelle; Synonym: Tupel

37 Index.., 15 3-Ebenen-Schema-Architektur, 30, 34 Primärschlüssel, siehe Schlüssel Projektion, 11, 35 Administration, 3 Attribut, 4, 36 Reihenfolge, 5 Wertebereich, 6 Wertzuweisung, 5 B*-Baum, 30 Datenbank, 4 Datenbankmodell konventionelles, 3 relationales, 3, 4 Datenbanksprache, 3 Division, 21, 35 Duplikate, 5, 7 equi-join, 21 Fremdschlüssel, siehe Schlüssel Gleichheitsverbund, 21 Relationenschema, 6, 35 Identifizierungsschlüssel, siehe Schlüssel Integritätsbedingung, 8 dynamische, 8 statische, 8 Überprüfung, 8 Kalkül, siehe relationale Kalküle Kreuzprodukt, 14, 19, 21 natural join, 19 Notationskonventionen, 7 Nullwert, 21 Optimierung, 26 Rechteverwaltung, 3 referentielle Integrität, 31 Relation, 6 relationale Algebra, 9, 35 äußerer Verbund, 21 Ausdrücke, 26 Auswertung, 26 Differenz, 12 Division, 21 Gleichheitsverbund, 20 Kreuzprodukt, 14 natürlicher Verbund, 18 Projektion, 11 Schnitt, 12 Theta-Verbund, 20 Umbenennung, 13 Vereinigung, 12 relationale Kalküle, 4 relationale Vollständigkeit, 26 Relationenformat, 6 Relationentyp, 6 als Menge von Attributen, 7 Schema, 3 Schlüssel, 27, 28, 31, 35 als Integritätsbedingungen, 29 Fremdschlüssel, 32, 34, 35 Identifizierungsschlüssel, 28, 35 Auswahlkriterien, 32 künstlicher, 31 Prüfung, 29 Wiederverwendung von Schlüsselwerten, 33 37

38 Das relationale Datenbankmodell 38 Primärschlüssel, 30, 31, 34, 35 Auswahl, 30 Schlüsselattribut, 28 Schlüsselkandidat, Sekundärschlüssel, 34, 35 Sortierschlüssel, 33, 34, 36 Superschlüssel, 28, 34, 36 Schlüsselkandidat, siehe Schlüssel Schlüsselwert, 28 secondary key, 34 Sekundärschlüssel, siehe Schlüssel Selektion, 9, 36 Bedingung mit all-quantor, 24 sort key, 33 Sortierschlüssel, siehe Schlüssel Spalte, 4, 36 Superschlüssel, siehe Schlüssel t[a], 11 Tabelle, 4, 36 Tupel, 6, 36 Umbenennung, 13 Verbund, 36 äußerer, 21, 36 Gleichheits-, 20, 36 natürlicher, 18, 36 Theta-, 20, 36 Verbundattribute, 19 Verbundpartner, 19 Vollständigkeit, 25 Zeile, 4, 36