SQL Structured Query Language

Transkript

1 AKAD HOCHSCHULEN FÜR BERUFSTÄTIGE SQL Structured Query Language Beispiel Hotel Prof. Thomas Müller Seminartext für das Diplomandenseminar Wirtschaftsinformatik Alle SQL-Beispiele dieses Seminartextes wurden unter dem Datenbanksystem INTERBASE von Borland entwickelt und getestet. Die SQL-Beispiele lassen sich jedoch auch mit dem Datenbanksystem MS ACCESS von Microsoft ausführen. Sie finden die Hoteldatenbank HOTEL.MDB zum Download unter der Adresse

2 2 AKAD Diplomandenseminar Wirtschaftsinformatik Übersicht über die Seminarinhalte 1. Systemanalyse 1.1 Systembegriff 1.2 Ansätze zur Systemanalyse Konventioneller Ansatz und Kritik am Lifecycle-Konzept Prototyping 1.3 Erhebungs- und Darstellungstechniken Beobachtung, Interview Structured (System) Analysis Entscheidungstabellentechnik (mit Übungsaufgabe) 1.4 Systemimplementierung Hilfsmittel des Algorithmendesigns Graphische Darstellung von Algorithmen (Struktogramme) Stepwise Refinement 1.5 Projektplanung mit Netzplantechnik Vorgang, Ereignis, Knoten, Kanten Beispiel eines Netzplanes Übungsaufgabe Netzplantechnik 2. Datenbanksysteme 2.1 Ziele und Strategien der Datenorganisation, Datenbankbegriffe 2.2 Das relationale Datenbankmodell (RDBMS) 2.3 Einsatzbeispiel RDBMS (Hoteldatenbank) Relationenmodell und Normalisierung Selektion, Projektion und Join Weitere Anfragetypen 2.4 Semantische Datenmodelle (Entity- Relationship-Diagramm) 2.5 Übungsaufgabe Datenbanken 3. Individuelle Datenverarbeitung 3.1 Begriff und Abgrenzung 3.2 Ausgewählte IDV-Anwendungen Textverarbeitung Hypertext Groupware Tabellenkalkulation Die in der obigen Übersicht hervorgehobenen Abschnitte werden in diesem Seminartext ausführlich behandelt und vertieft. Copyright Prof. Thomas Müller, Grundhof / AKAD, 1995, 1999, 2001, 2002, 2003 Alle Rechte vorbehalten. Vervielfältigung sowie sonstige Verbreitung und Verwertung auch auszugsweise nur mit schriftlicher Genehmigung des Autors.

3 Inhaltsverzeichnis 1. Strukturierung der Daten (Normalisierung) Relationenmodell Daten in unnormalisierter Form Speichereffizienz der unnormalisierten Form durch Mengen Redundanzprobleme Anomalieprobleme Einfügeanomalien Änderungsanomalien Löschanomalien Problem der Nullwerte Normalformen von Relationen Arten der Abhängigkeit Erste Normalform (1NF) Zweite Normalform (2NF) Dritte Normalform (3NF) Integritätsbedingungen Referentielle Integrität durch Fremdschlüsselbeziehungen Weitere Integritätsbedingungen Einrichtung der Datenbank (DDL) Erfassung von Daten (DML) Anfragen an die Datenbasis (Retrieval) DML Statement SELECT Anfragetypen Selektion, Projektion und Join Operatoren in SELECT-Statements SQL-Funktionen Subqueries SQL-Klauseln ORDER BY-Klausel GROUP BY-Klausel HAVING-Klausel UNION-Klausel Verwendung von Literalen Änderung und Löschung von Daten Entwicklung von Views für die Datenbank Hinweise zu den normalisierten Relationen Literaturhinweise Stichwortverzeichnis Daten des Beispiels ER-Diagramm zum Hotelbeispiel Abbildungsverzeichnis 51 3

4 4 Strukturierung der Daten (Normalisierung) 1. Strukturierung der Daten (Normalisierung) 1.1. Relationenmodell Das hier darzustellende Relationenmodell stellt reale Sachverhalte (Daten) in tabellarischer Form dar. Zu den zu betrachtenden Sachverhalten gehören die Objekte (Entitäten, entities) mit ihren Eigenschaften (Attributen), die Beziehungen (relationship) zwischen diesen Objekten, ebenfalls mit ihren Eigenschaften (Beziehungsattribute). Entitytyp Attribute Attributwerte KdNr Name Wohnort 100 Müller Hagen AKAD Meier Pinneberg Flensburg Entities 103 Schmidt Kiel Domänen z.b.: KdNr: Name: Zeichenkette mit 40 Zeichen Abb. 1: Begriffe des Relationenmodells Jeder Sachverhalt entspricht einer Zeile (Tupel oder Entities) in einer solchen Tabelle. Eine Relation ist also eine Menge solcher Tupel. Jedes Tupel wird dabei durch eine endliche Menge gleicher Eigenschaften (Attribute) beschrieben und durch unterschiedliche Eigenschaftswerte (Attributwerte) spezifiziert. Die Attribute entsprechen dabei den Spaltenüberschriften der Tabelle, die Attributwerte den jeweiligen Eintragungen in einer Zeile. Ausgehend von einer unnormalisierten Form 1 werden die Daten durch schrittweise Zerlegung (Aufspaltung), den Normalisierungsprozess, in mehrere Relationen aufgeteilt, die den spezifischen Notwendigkeiten der betrachteten Objekte und insbesondere ihrer Beziehungen untereinander gerecht werden. Die Normalisierung der Relationen dient folgenden Zielen: 1. Vermeidung von Redundanz (mehrmaliges Festhalten ein- und desselben Sachverhaltes). 2. Vermeidung der infolge von Redundanz entstehenden Anomalien und NULL-Werte (Probleme bei der Datenmanipulation wie Einfügungen, Löschungen in bzw. Aktualisierung der Datenbasis). 3. Sicherung der Daten-Integrität (Speichern realitätskonformer Sachverhalte). 4. Einsparung von Speicherplatz. Wichtig dabei ist jedoch, dass sich aus jeder im Rahmen des Prozesses gebildeten Form der Daten (Relationen) die ursprünglich in der unnormalisierten Form vorhandene Information wieder rekon- 1 Von unnormalisierter Form spricht man, wenn alle benötigten Daten unabhängig von ihren jeweiligen Beziehungen sich in einer Tabelle befinden.

5 Strukturierung der Daten (Normalisierung) 5 struieren lässt 2 : Die Normalisierung darf also nicht zu Informationsverlusten führen. Unter Normalisierung versteht man also die verlustfreie Zerlegung einer Relation in mehrere Relationen. Dies wird dadurch erreicht, dass alle durch Teilung verlorengehenden Beziehungen durch Aufnahme der identifizierenden Eigenschaften (Primärschlüssel) in beide neuen Relationen und Aufbau von Fremd 3 - und Primärschlüsselbeziehungen bzw. -verweisen festgehalten werden. Zusätzlich erhält jede Relation im Rahmen der Normalisierung ein Schlüsselattribut, dessen Attributwert einen Tupel eindeutig identifiziert (Bedingung der Entitätsintegrität). Als Schlüssel kommen dabei entweder ein einzelnes Attribut einer Relation oder auch eine Kombination mehrerer Attribute in Betracht (zusammengesetzter Schlüssel). Einen solchen Schlüssel nennt man Primärschlüssel Daten in unnormalisierter Form Daten in unnormalisierter Form sind daran erkennbar, dass sie Attribute besitzen, die sich aus mehreren Elementen zusammensetzen (z.b. Gast mietet Zimmer mehrmals hintereinander). Daher können in der unnormalisierten Relation am Kreuzungspunkt von Spalten und Zeilen mehrere Werte (sog. Mengen) auftreten. Die Ausgangsrelation für die Datenbank Hotel, die jeweils ein Vermietverhältnis beschreibt, kann in unnormalisierter Form wie folgt abgebildet werden: R.Vermietung Name Wohnort Strasse ZiNr Art Ausst. Dauer Miete Abb. 2: Unnormalisierte Relation Vermietung Beispieldaten (Tupel) der Relation Vermietung zeigen dabei die Möglichkeit des Auftretens von Mengen in der Relation: R.Vermietung Name Wohnort Strasse ZiNr Art Ausst. Dauer Miete Müller Hagen Weg EZ DBF {1,4} Abb. 3: Unnormalisierte Relation Vermietung mit Mengen Die in dieser Tabelle beschriebenen Sachverhalte besagen, dass der Gast Müller aus Hagen zweimal das Zimmer 100 gemietet hat. Einmal betrug die Mietdauer einen, das zweite Mal vier Tage. In dieser unnormalisierten Form die nachfolgend beschriebenen Probleme auf Speichereffizienz der unnormalisierten Form durch Mengen In der Relation R.Vermietung treten Mengen auf: Im Beispiel können in der Spalte Dauer mehrere Einträge erfolgen, da ja ein Gast mehrfach hintereinander ein Zimmer mieten kann. Dies widerspricht rein formal der Forderung, dass Werte im Kreuzungspunkt von Spalten (Attributen) und Zeilen (Entities) atomar (nicht weiter zerlegbar) sein müssen 4. Darüber hinaus ist damit das Problem weiterer Kombinationen (selber Gast, selbes Zimmer, selbe Dauer) noch gar nicht angesprochen; Dies würde dazu führen, dass alle Attribute zweier Tupel identisch wären. Da unbekannt ist, wieviele Attributwerte entstehen können, müsste ein entsprechend ausreichender Speicherplatz für diese Mengen bevorratet werden. Dieser müsste bei der Speicherung eines jeden Satzes vorgesehen werden, da der Direktzugriff auf Daten jeweils zur Berechnung der Speicheradresse eine feste Satzlänge voraussetzt Man nennt diese Bedingung die Referentielle Integritätsbedingung. Vgl. dazu Seite 13. Technisch gesehen müßte hier für alle denkbaren weiteren Vermietungen an denselben Gast entsprechend Speicherplatz freigehalten bzw. bevorratet werden (vgl. AKAD-Heft Datenbanken).

6 6 Strukturierung der Daten (Normalisierung) Die gezeigten Mengen ließen sich jedoch einfach wie folgt auflösen: R.Vermietung Name Wohnort Strasse ZiNr Art Ausst. Dauer Miete Müller Hagen Weg EZ DBF Müller Hagen Weg EZ DBF Abb. 4: Auflösung von Mengen Im engeren Sinne enthält die obige Relation dennoch eine Menge: Die Ausstattungsmerkmale kennzeichnen ja eigentlich Mengen von Ausstattungsdetails wie Dusche, Bad... u.s.w.. Genau genommen müssten auch diese Werte zerlegt werden und für jedes Ausstattungsmerkmal ein neues Attribut in die Relation aufgenommen werden. Erkennbar ist diese Eigenschaft auch an der entsprechend notwendigen Formulierung zum Auffinden eines Tupels mit dem Merkmal D wie Dusche: Hier ist ein Auffinden nur unter Formulierung einer SELECT...WHERE Ausstattung like '%D%' möglich, einer Selektion, die unterhalb der eigentlichen relationalen Abfrageebene liegt. Damit wären die Ausstattungswerte nicht mehr atomar und würden so den Grundsätzen der Normalformen nicht entsprechen. In unserem Beispiel betrachten wir jedoch alle Einträge der Art DBFT, DFT,... als unteilbare Menge, die im Bereich der Domäne ( = Wertebereich) von Ausstattung liegen Redundanzprobleme Redundanzprobleme ergeben sich durch mehrfache Speicherung ein- und derselben Sachverhaltes an unterschiedlichen Stellen (Spalten) der unnormalisierten Relation. Sofern ein Gast mehrmals die Dienste unseres Hotels in Anspruch nimmt (s. Abb. 4), sind alle Gastattribute zu wiederholen. Bei jeder erneuten Vermietung eines Zimmers sind alle Attribute des Zimmers zu wiederholen. In der Abb. 4 wären also sowohl die Gastattribute Wohnort und Strasse als auch die Zimmerattribute Art, Ausstattung und Miete redundant. Redundanz zieht nicht nur einen erhöhten Speicherbedarf nach sich, sondern führt auch zu weiteren Probleme im Zusammenhang mit den grundlegenden Speicheroperationen des Einfügens, Löschens und Änderns. Bei vorliegender Datenstruktur können durch diese Operationen Anomalien entstehen, die dazu führen, dass der reale Sachverhalt nicht mehr korrekt abgebildet wird. Schließlich treten bei Redundanz auch oftmals unbestimmte (Null-) Werte auf Anomalieprobleme Einfügeanomalien Auch das Einfügen nicht realitätskonformer Sachverhalte führt zur Inkonsistenz der Datenbasis. So stellt in vorstehender Relation der folgende Einschub keine Verletzung des Relationenprinzips dar: R.Vermietung Name Wohnort Strasse ZiNr Art Ausst. Dauer Miete Müller Hagen Weg DZ DBFR Meier Grundhof Turmweg EZ DBFT Abb. 5: Inkonsistenzen durch Einfügeanomalien Die Einfügung des Tupels (Meier, Grundhof, Turmweg 7, 110, DZ, DBFT) führt zur Abbildung des realitätsfremden Sachverhalts, dass das Zimmer 110 sowohl ein Einzel- als auch ein Doppelzimmer sein kann.

7 Strukturierung der Daten (Normalisierung) Änderungsanomalien Ändern sich die Ausstattungsmerkmale eines Zimmers (z.b. Zimmer 100 hat nun die Ausstattung Dusche/Bad/Fernsehen/Telefon = DBFT), so wäre sicherzustellen, dass in allen Tupeln (Zeilen) der Relation die Änderungen vorgenommen werden. Werden die Preise für Einzelzimmer (EZ) bspw. generell um 10 % erhöht, so sind diese Änderungen an allen betroffenen Tupeln vorzunehmen. Andernfalls wird die Datenbasis inkonsistent, da sie Widersprüche beinhaltet. Z.B. kostet das Zimmer 100 für Herrn Müller aus Hagen dann 60.00, für Herrn Müller aus Pinneberg jedoch Zieht bspw. ein Gast um (von Hagen nach Flensburg), so wäre auch hier eine mehrfache Änderung der Daten (alle Tupel von Müller aus Hagen) erforderlich. Ein Unterlassen der Änderungen in einigen Tupeln würde zur Inkonsistenz der Datenbasis führen. R.Vermietung Name Wohnort Strasse ZiNr Art Ausst. Dauer Miete Müller Flensburg Aue EZ DBF Müller Hagen Weg EZ DBFT Abb. 6: Inkonsistenzen durch Änderungsanomalien Löschanomalien Diese entstehen beim Entfernen von Informationen aus der Datenbasis. Storniert z.b. Herr Meier aus Grundhof eine Zimmerreservierung für ein neues Zimmer, so sind mit der Stornierung gleichfalls alle Zimmerattribute verloren, sofern sie nicht "zufällig" in einem anderen Tupel auftreten. Zugleich ist auch die Adresse des Gastes (sofern er zum ersten Mal bei uns als Gast auftritt) nicht mehr bspw. für Werbeaktionen verfügbar. R.Vermietung Name Wohnort Strasse ZiNr Art Ausst. Dauer Miete Meier Grundhof Hof EZ DBFR Müller Hagen Weg EZ DBFT Abb. 7: Inkonsistenzen durch Löschanomalien Letztendlich dient die Vermeidung von Anomalien der Sicherstellung der Integrität der Datenbasis. So muss z.b. sichergestellt sein, dass bei Löschungen z.b. aller Vermietverhältnisse mit dem Gast Müller nicht auch zugleich ein Zimmer vollständig gelöscht wird oder dass z.b. bei Löschung eines Gastes alle noch nicht abgerechneten Leistungen erhalten bleiben. Die Sicherung der (referentiellen) Integrität wird von unterschiedlichen DBMS mehr oder weniger unterstützt. So kann es sinnvoll sein, im Rahmen der Implementierung einer Anwendung zu definieren, was bei der Löschung von Gästen mit noch offenen Rechnungen (z.b. definiert durch bestehende Fremdschlüsselbeziehung 5 zur Tabelle Rechnung) passieren soll. Im wesentlichen lassen sich hier drei Optionen anführen: Abweisung des Löschauftrages Löschung aller Vermietverhältnisse Löschung der Beziehung Abb. 8: Optionen des DELETE-Kommando RESTRICT CASCADE NULLIFY Zur Vermeidung von Redundanz und in deren Folge entstehenden Anomalieproblemen ist die bisherige Relation R.Vermietung weiter zu zerlegen. Prinzipiell werden dabei die durch die Zerlegung einer 5 Vgl. dazu Seite 13.

8 8 Strukturierung der Daten (Normalisierung) Relation verlorengehenden Beziehungen durch verknüpfte Primärschlüssel (gleiche Spalten in unterschiedlichen Relationen) festgehalten (Sicherstellung der Integrität) Problem der Nullwerte Bei näherer Betrachtung der obigen Relation sind folgende Probleme ersichtlich: Soll in die obige Relation R.Vermietung ein neues Zimmer eingefügt werden, das gerade fertiggestellt wurde, so ergibt sich das Problem der Null-Werte. Null-Werte können dabei als unbekannte oder auch als nicht zutreffende Werte aufgefasst werden. Da evtl. noch kein Gast für das Zimmer vorhanden ist, müssten in die Tabelle für alle Gastattribute NULL-Werte eingetragen werden. Desgleichen müssten z.b. bei telefonischen Bestellungen, denen nicht sofort ein Zimmer zugeordnet werden kann (oder denen mehrere mögliche Zimmer zugeordnet werden könnten) ebenfalls NULL-Werte für die Zimmerattribute Verwendung finden. Dabei entsteht das Problem der Selektion nach diesen Werten: Beim Suchen, Ändern oder Löschen kann nur noch nach dem Kriterium "Ist Null" oder "Ist nicht Null" selektiert werden. R.Vermietung Name Wohnort Strasse ZiNr Art Ausst. Dauer Miete Müller Hagen Weg 1 NULL NULL NULL NULL NULL NULL NULL NULL 110 EZ DBFT NULL Abb. 9: Beispieldatensätze mit NULL-Werten Im Rahmen des Normalisierungsprozesses, der zur Vermeidung von Anomalie- und Nullwertproblemen durchgeführt wird, werden in der Praxis drei Normalformen unterschieden, die nachfolgend anhand unseres Beispiels erläutert werden Normalformen von Relationen Arten der Abhängigkeit Zum besseren Verständnis der Definitionen sei hier zunächst der Begriff der Abhängigkeit definiert. Dabei geht es immer um die Abhängigkeiten zwischen solchen Attributen, die ein Entity eindeutig und vollständig beschreiben (sog. Schlüsselkandidaten bzw. Schlüsselattribute) und solchen, die diese Eigenschaft nicht aufweisen (sog. Nichtschlüsselattribute). Funktionale Abhängigkeit: Funktional abhängig sind Attribute einer Relation, die sich nicht unabhängig voneinander ändern können. Funktionale Abhängigkeit impliziert also, dass zu jedem unabhängigen Attribut 1 genau ein Wert des abhängigen Attributes 2 gehört. Aus der Kenntnis des Wertes des Attributes 1 kann also der Wert des Attributs 2 abgeleitet werden. Sei S ein Schlüsselattribut der Relation R(S,A) und A ein weiteres (Nichtschlüssel-) Attribut der Relation: Dann gilt A als funktional abhängig von S, wenn genau zu jedem Wert von S exakt ein Wert von A gehört: R.Funktional S (Kfz-Fahrgestellnummer) WX RDT-3456-W A (Halter) Müller, Thomas Müller, Sylvia Abb. 10: Beispiel Funktionale Abhängigkeiten Volle funktionale Abhängigkeit: Voll funktional abhängig sind Attribute einer Relation immer dann, wenn mit einer bestimmten Wertekombination zweier oder mehrerer unabhängiger Attribute genau 1 Wert des abhängigen Attributes einhergeht. Volle funktionale Abhängigkeit impliziert also die Abhängigkeit eines Attributes von einer Attributskombination.

9 Strukturierung der Daten (Normalisierung) 9 Seien S1 und S2 ein zusammengesetzter Schlüssel der Relation R(S1, S2, A), dann gilt A als voll funktional abhängig, wenn zu jeder zulässigen Wertekombination von S1 und S2 genau 1 Wert des Attributes A gehört. R.Voll Funktional S1 (Model) S2 (Typ) A (Preis) Mazda 626 Fließheck ,00 Mazda 626 Kombi ,00 Abb. 11: Beispiel Voll funktionale Abhängigkeiten Transitive Abhängigkeit: Transitive Abhängigkeiten beschreiben indirekte Abhängigkeiten zwischen Nichtschlüsselattributen. Sei S1 ein Schlüssel der Relation R(S1, A, B), dann gilt B als transitiv abhängig, wenn A von S1, S1 aber nicht von A funktional abhängt, B jedoch von A funktional abhängig ist. Im Beispiel ist Halter und Wohnort von der Fahrgestellnummer funktional abhängig (nicht aber umgekehrt, da eine Person mehrere Kfz halten kann). Dagegen ist das Bundesland nicht von der Fahrgestellnummer, sondern vom Wohnort funktional abhängig. R.Transitiv S (Kfz-Fahrgestellnummer) Halter B (Bundesland) A (Wohnort) WX-4576 Müller, Thomas Schleswig-Holstein Grundhof 4456-RDT-3456-W Müller, Sylvia Hessen Frankfurt Abb. 12: Beispiel Transitive Abhängigkeiten Erste Normalform (1NF) An die erste Normalform sind die folgenden Bedingungen geknüpft: Die Attribute dürfen nur einfache Werte aufweisen, d.h., sie müssen atomar (nicht weiter zerlegbar) sein. Am Kreuzungspunkt von Spalten und Zeilen darf höchstens ein skalarer Wert stehen. Jede Relation erhält einen eindeutigen Schlüssel oder eine eindeutige Schlüsselkombination (Primärschlüssel), der das Tupel eindeutig identifiziert. D.h., es gibt keinen zweiten Tupel mit dem selbem Primärschlüssel, der eine andere Attributskombination beschreibt. Die Forderungen der 1NF können durch Aufspaltung der Relation R.Vermietung in 2 neue Relationen erfüllt werden (Primärschlüssel sind doppelt unterstrichen): R.Gast Name Wohnort Strasse R.Vermietung Name ZiNr Art Ausst. Dauer Miete Abb. 13: Neue Relationen Gast und Vermietung zur Erreichung der 1 NF Als Primärschlüssel wurde hier der Name des Gastes und - in der Relation R.Vermietung - zusätzlich die Zimmernummer gewählt. Verlorengehende Beziehungen zu übergeordneten Relationen werden durch Übernahme des/der Primärschlüssel/-kombination (hier Name) erhalten. Dies führt jedoch in unserem Beispiel zu folgenden Problemen: 1. Da ein Primärschlüsselattribut eine Relation eindeutig und vollständig beschreiben soll und er damit ein eindeutiges Identifizierungsmerkmal darstellt, scheint der Name allein dafür nicht geeignet. Zwei Gäste mit dem Namen Müller wären dadurch nicht voneinander zu unterscheiden. Denkbar wäre eine Kombination aus Name und Wohnort (zusammengesetzter Schlüssel); je-

10 10 Strukturierung der Daten (Normalisierung) doch könnten auch hier offensichtlich Probleme entstehen (2 Gäste Müller aus Frankfurt sind leicht vorstellbar). Dies könnte Veranlassung geben, auch den Straßennamen in den Schlüssel aufzunehmen. Es entstünde dadurch jedoch die ursprünglich zerlegte Relation. 2. Wesentlich vereinfachen lässt sich die Aufspaltung von Relationen jedoch durch die Einführung eines "künstlichen" Schlüssels, der die Unterscheidung einzelner Entities durch ein Attribut ermöglicht und damit erheblich verkürzt und vereinfacht. Eine solche Möglichkeit bietet z.b. die Einführung einer eindeutigen Kundennummer (KdNr). Diese wird nur je einmal für einen ganz bestimmten Gast vergeben und unterscheidet Gäste voneinander. Erst dann ist es möglich, Gäste mit gleichem Namen, Wohnort und Strasse (Zweifamilienhaus mit Vater und Sohn) zu unterscheiden. 3. Die Verbindung zwischen den aufgeteilten Relationen lässt sich dann ebenfalls mit nur einer Spalte in der zweiten Relation abbilden. 4. Die Definition von Primärschlüsseln in der Datenbank setzt zugleich rein technisch gesehen voraus, dass diese Werte nicht wiederholt auftreten können (UNIQUE-Klausel). Bei der Wahl der Schlüsselkombination Name, Wohnort, Strasse ist dies jedoch wie gezeigt nicht immer sicherzustellen. Daraus ergibt sich eine verbesserte Aufteilung der Ursprungsrelation in die neuen Relationen R.Gast KdNr Name Wohnort Strasse R.Vermietung KdNr ZiNr Art Ausst. Dauer Miete Abb. 14: Verbesserung der 1NF durch künstlichen Schlüssel Kundennummer (KdNr) Die Redundanz- und Anomalieprobleme für Gastdaten wurden damit entfernt: Jede erneute Vermietung an einen Gast, der bereits einmal da war, würde nur zu einem neuen Datensatz in der Vermietung mit der entsprechenden (vorhandenen) Kundennummer führen. Die Gastattribute treten nun nur noch einmalig in der Relation Gast auf. Die durch die Aufteilung verlorene Beziehung (Gast Müller hat Einzelzimmer 100 mit der Ausstattung DBF zu einem Preis von gemietet) wird über die Aufnahme des Primärschlüssels Kundennummer in die Relation Vermietung erhalten. Betrachtet man die Relation Vermietung genauer, so bleibt festzustellen, dass auch hier ein Teil der geschilderten Anomalie- und Redundanzprobleme fortbestehen. Wird ein Zimmer gelöscht, so lassen sich die Vermietverhältnisse nicht rekonstruieren (Löschanomalie). Art und Ausstattung der Zimmer können durch Änderungen bei gleicher Zimmernummer verschieden sein (Änderungsanomalie). Gibt es für ein Zimmer keine offene Rechnung, d.h., keinen Eintrag in der Relation Vermietung mehr, sind die Zimmerinformationen endgültig verloren (Löschanomalie). Auch tritt weiterhin das Problem der NULL-Werte auf (Neues Zimmer ohne Vermietung). Diese Überlegungen führen zur Bildung der 2. Normalform (2NF) einer Relation Zweite Normalform (2NF) Allgemein lässt sich formulieren, dass sich eine Relation in der 2. Normalform (2NF) befindet, wenn sie sich in der ersten Normalform befindet und zur Beschreibung der Abhängigkeit vom Primärschlüssel für jedes Nicht-Primärschlüsselattribut alle Attribute des Primärschlüssels und nicht nur Teile davon gehören (volle funktionale Abhängigkeit der Nichtschlüssel von den Schlüsselattributen). Daraus ergibt sich, dass die 2NF nur bei Vorliegen zusammengesetzter Primärschlüssel (wie im Falle der Relation Zimmer) relevant wird. Relationen mit nur einem Primärschlüsselattribut sind automatisch bei Vorliegen der 1NF auch und der Form der 2NF. Die Relation Vermietung widerspricht dieser Forderung, da sich hier die Attribute Art, Ausstattung und Miete bereits aus dem Primärschlüssel Zimmernummer ergeben; Die Kundennummer ist dafür nicht erforderlich. Dies trifft jedoch nicht für die Mietdauer zu: Diese ist vom Gesamtschlüssel (Kundenund Zimmernummer) abhängig.

11 Strukturierung der Daten (Normalisierung) 11 Daher ist die Relation erneut aufzuteilen. Aus der Relation Vermietung ergeben sich nun die beiden neuen Relationen R.Zimmer ZiNr Art Ausst. Miete Abb. 15: Relation Zimmer in 2NF R.Vermietung ZiNr KdNr Dauer Abb. 16: Neue Relation Vermietung Die Relation Vermietung birgt jedoch einen Nachteil in sich: Da die Attribute Kundennummer und Zimmernummer als Primärschlüsselkombination jeweils nur einmal eine ganz bestimmte Attributkombination erlauben, wird es hier nicht möglich sein, die zweimalige Vermietung ein- und demselben Zimmers an ein- und denselben Gast historisch abzubilden. Darin zeigt sich eine gewisse Schwäche des Relationenmodells schlechthin: sollen Historien abgebildet werden, müsste für diese Relation ein neuer Schlüssel gefunden werden. Vorstellbar wäre hier die Aufnahme des Vermietdatums in den Primärschlüssel, da ja ein Zimmer nicht am gleichen Tag doppelt vermietet sein kann oder auch die Vergabe einer Ereignisnummer wie Buchungsnummer. Soll jedoch nicht eine Historie, sondern der jeweilige Zustand (im Sinne eines Platzbuchungssystems) abgebildet werden, so ergeben sich hier keine Nachteile: Ein- und dasselbe Zimmer kann ja nicht zur gleichen Zeit zweimal vermietet sein. Die Belegung des Zimmers wird erst wieder möglich, wenn es frei gegeben wurde (durch Löschung der Vermietung). In unserem Beispiel soll jedoch die Historie (zur Speicherung aller offenen Posten) abbildbar sein. Ohne Einführung eines "künstlichen" Schlüssels und unter Verzicht auf einen Primärschlüssel entstünden die folgenden Relationen, die jedoch eine Verletzung der Entitätsintegrität darstellen. R.Vermietung ZiNr KdNr Dauer Abb. 17: Relation Vermietung ohne Primärschlüssel (Struktur) Diese Vorgehensweise erlaubt nun auch die Abbildung gleicher Attributskombinationen: R.Vermietung KdNr ZiNr Dauer Abb. 18: Relation Vermietung ohne Primärschlüssel (Daten) Aus obiger Tabelle wird zugleich deutlich, dass diese Vorgehensweise erhebliche Nachteile mit sich führt: Bei allen Datenbankoperationen auf diese Tabelle wäre Zeile 1 nicht mehr von Zeile 3 zu unterscheiden. D.h., Löschungen, Änderungen oder Selektionen würden immer beide Zeilen zugleich betreffen, da hier kein eindeutiges Unterscheidungsmerkmal vorhanden ist. Daher fügen wir auch in diese Relation einen künstlichen Schlüssel ein, dessen einzige Aufgabe es ist, die Tupel eindeutig voneinander zu unterscheiden. Es wird hier die Einführung einer Buchungsnummer (BuNr) als Primärschlüssel vorgeschlagen. Damit ist zugleich einer grundsätzlichen Forderung des Datenbankentwurfs Rechnung getragen: Jede Relation verfügt über einen Primärschlüssel (Bedingung der Entitätsintegrität).

12 12 Strukturierung der Daten (Normalisierung) Aus den genannten Gründen ergibt sich folgende neue Relation Vermietung: R.Vermietung BuNr ZiNr KdNr Dauer Abb. 19: Primärschlüssel Buchungsnummer in der Relation Vermietung Dritte Normalform (3NF) Die Forderung der 3. Normalform (3NF) betrifft die direkte Abhängigkeit aller Nichtschlüssel- vom Schlüsselattribut. Eine Relation befindet sich in der 3NF, wenn sie sich in der 2NF befindet und alle Nichtschlüsselattribute direkt vom Primärschlüssel abhängen. Das heißt, dass alle Nichtschlüsselattribute wechselseitig voneinander unabhängig sind und damit auch keine indirekten Abhängigkeiten (Transitivität) der Nichtschlüsselattribute untereinander bestehen. Die Relation Zimmer des Beispiels weist eine solche indirekte Abhängigkeit auf: Die Zimmermiete wird in unserem Beispiel zunächst direkt von der Ausstattung bestimmt, nicht jedoch vom Primärschlüssel Zimmernummer. Daher ist hier die Miete in eine neue Relation Preis auszugliedern, was zu folgenden neuen Relationen führen würde: R.Preis Ausst. Miete Abb. 20: Neue Relation Preis R.Zimmer ZiNr Art Ausst. Abb. 21: Relation Zimmer in 3NF Andererseits ist die Abhängigkeit des Preises nur von der Ausstattung in unserem Beispiel nicht realitätsnah: Zusätzlich müsste noch die Art des Zimmers in der Miete berücksichtigt werden (Doppelzimmer mit DBF teurer als Einzelzimmer mit DBF). Daher ist in die Preisrelation die Art als Schlüssel mit aufzunehmen, was zu einem zusammengesetzten Schlüssel führt: R.Preis Art Ausst. Miete R.Zimmer ZiNr Art Ausst. Abb. 22: Verbesserte Relationen Preis und Zimmer in 3NF In diesem Beispiel ist zugleich ersichtlich, dass die Redundanz der Primärschlüssel sehr stark ansteigt. Damit steigt z.b. zugleich der Aufwand bei einer entsprechenden Abfrage der Tabellen (z.b. SELECT ZiNr, Zimmer.Ausstattung, Zimmer.Art, Miete FROM Zimmer, Preis WHERE Zimmer.Ausstattung = Preis.Ausstattung AND Zimmer.Art = Preis.Art) 6. Bei weiterer Prüfung der Relationen zeigt sich, dass nun durch Einfügen, Ändern und Löschen keine Anomalien mehr erzeugt werden können. Daher wurde die 3. Normalform erreicht. Ein letztes Problem besteht allerdings noch bezüglich solcher Attributwerte, die sich zum Zwecke der Verbindung der Relationen untereinander in einer weiteren Relationen befinden. Für alle diese Werte muss gelten: Es muss ein entsprechender Wert in der anderen Relation existieren. Folgende zwei Beispiele mögen den Zusammenhang erhellen: 6 Vgl. dazu Kapitel Anfragen an die Datenbasis (Retrieval) auf Seite 24.

13 Strukturierung der Daten (Normalisierung) Niemals darf in der Relation Vermietung eine Kundennummer existieren, für die sich in der Relation Gast nicht ein entsprechender Wert finden lässt. Der Adressat einer Rechnung ließe sich nicht ermitteln. 2. Niemals darf sich in der Relation Vermietung ein Zimmer befinden, das nicht in der Relation Zimmer existiert. Art und Ausstattung würden damit nicht feststellbar sein, womit auch eine Preisermittlung unmöglich wäre. Man nennt diese Bedingungen auch die Bedingungen zur Sicherung der referentiellen Integrität. Ein mögliches Instrument zur Sicherung der referentiellen Integrität, das von den meisten Datenbanksystemen unterstützt wird, ist die Möglichkeit zur Formulierung von Fremdschlüsselbeziehungen Integritätsbedingungen Referentielle Integrität durch Fremdschlüsselbeziehungen Fremdschlüsselbeziehungen erleichtern die Erhaltung der Integrität, insbesondere der referentiellen Integrität, einer Datenbank. Ein Fremdschlüssel ist ein Attribut, dass in einer anderen Relation ein Primärschlüsselattribut ist. Zwischen beiden baut das DBMS eine besondere Beziehung auf, die sicherstellt, dass zu jeder Zeit für alle Fremdschlüsselattribute ein entsprechendes Primärschlüsselattribut gefunden wird. Dies ist bei allen Verbunden 8 von Tabellen relevant. Beispiel: Gegeben sei folgendes, leicht verkürzte Relationenschema: R.Vermietung (BuNr, KdNr, ZiNr, Dauer) R.Gast (KdNr, Name, Wohnort, Strasse); R.Zimmer (ZiNr, Ausstattung, Ausstattung); Ohne Formulierung von Fremdschlüsselbeziehungen wären folgende Einschübe in die Relationen möglich, die eine Rekonstruktion der Gesamtinformation nicht mehr ermöglichen würden: Einfügen/Ändern einer KdNr in Vermietung, für die in R.Gast kein Datensatz/kein Entity existiert. Einfügen/Ändern einer ZiNr in Vermietung, für die in R.Zimmer kein Datensatz existieren. Löschen eines Zimmers/Gastes, für das in Relation Vermietung eine (vielleicht noch nicht abgerechnete) Vermietung verzeichnet ist; Es wäre bei Rechnungsstellung kein Zimmer und damit auch kein Preis bestimmbar bzw. kein Rechnungsadressat mehr vorhanden. Im obigen Beispiel wäre es also sinnvoll, zwischen der Relation Gast bzw. der Relation Zimmer und der Relation Vermietung eine Fremdschlüsselbeziehung aufzubauen. Die Fremdschlüsselattribute sind die, die in beiden Relationen enthalten sind und in der referenzierten Relation Primärschlüsseleigenschaft haben. In den referenzierenden Relationen sind diese Attribute die Fremdschlüsselattribute: Relation Primärschlüssel Fremdschlüssel referenzierte Relationen Gast KdNr - - Zimmer ZiNr Art, Ausstattung Preis Vermietung BuNr KdNr, ZiNr Gast, Zimmer Preis Art, Ausstattung - - Abb. 23: Primär- und Fremdschlüssel des Relationenschemas Hotel Die Formulierung von Fremdschlüsselbeziehungen sorgt dafür, dass zu einer Vermietung immer und zu jeder Zeit ein Gast in der Relation Gast und ein Zimmer in der Relation Zimmer gefunden wird (referentielle Integritätsbedingung), da sie zur Folge hat, dass Änderungen/Einfügungen/Löschungen, die die Integrität zerstören würden, i.d.r. zurückgewiesen würden oder zumindest die korrekte Rei- 7 8 Eine Alternative dazu stellt die Verwendung von Datenbank-Triggern da, die die Einhaltung der beschriebenen Regeln überwachen. Ein Verbund selektiert Daten aus mehreren Tabellen und wird auch als Join bezeichnet.

14 14 Strukturierung der Daten (Normalisierung) henfolge der Operationen einzuhalten wäre. Gleiches gilt für die Beziehungen zwischen Zimmer und Preis. Folgende Tabelle zeigt, welche Operationen auf mit Fremdschlüsselbeziehungen versehene Tabellen erlaubt bzw. abgewiesen werden. Dabei ist beispielsweise Vermietung die referenzierende, Gast bzw. Zimmer die referenzierte Relation, d.h., Vermietung.KdNr referenziert Gast.KdNr und Vermietung.ZiNr referenziert Zimmer.ZiNr. Gleiches gilt für Zimmer (referenzierende) und Preis (referenzierte Relation). Dabei wird die Option RESTRICT unterstellt. Operation Granularität 9 Vermietung Gast Zimmer Preis INSERT Tupel erlaubt, wenn in Gast ein Entity mit KdNr und in Zimmer ein Entity mit ZiNr vorhanden ist, sonst wird abgewiesen erlaubt, z.b. neuer Gast DELETE Tupel erlaubt erlaubt, wenn in Vermietung kein Gast mit dieser KdNr mehr existiert, sonst wird abgewiesen UPDATE Nichtschlüsselattribut Primärschlüsselattribut wird abgewiesen wird abgewiesen Fremdschlüsselattribut erlaubt, z.b. Dauer erlaubt, z.b. Wohnort erlaubt, wenn in Gast ein Entity mit KdNr und in Zimmer ein Entity mit ZiNr vorhanden ist, sonst wird abgewiesen nicht vorhanden Abb. 24: Operationentableau bei Fremdschlüsselbeziehungen erlaubt, wenn die beschriebene Art/ Ausstattung in der Relation Preis enthalten ist, sonst wird abgewiesen erlaubt, wenn in Vermietung kein Zimmer mit dieser ZiNr mehr existiert, sonst wird abgewiesen nicht vorhanden erlaubt, z.b. neue Art/Ausstattungskombination mit einem Preis erlaubt, wenn in Zimmer kein Tupel mehr mit der entsprechenden Art/Ausstattung existiert, sonst wird abgewiesen erlaubt, z.b. Miete wird abgewiesen wird abgewiesen erlaubt, wenn die geänderte Art/ Ausstattung in der Relation Preis enthalten ist, sonst wird abgewiesen nicht vorhanden Daraus, dass eine Operation abgewiesen wird, ist jedoch nicht endgültig zu schließen, dass diese Operation überhaupt nicht möglich wäre: Entscheidend ist - wie beim Einfügen auch (s. Kapitel 3: Erfassung der Daten) bereits verdeutlicht - die Reihenfolge der Operationen und die bei der Einrichtung der Relationen vereinbarten Optionen von Update/Delete, die RESTRICT, CASCADE oder NULLIFY sein können. INSERT in eine referenzierende Relation (z.b. Vermietung) erfordert erst das Einfügen der/des entsprechenden Tupels in der/die referenzierten Tabelle/n (Gast und Zimmer); m.a.w. ist zuerst ein Gast mit der entsprechenden KdNr und (es handelt sich ja hier um eine zusammengesetzte Fremdschlüsselbeziehungen) ein Zimmer mit der entsprechenden ZiNr einzufügen, dann kann in Vermietung das Tupel mit der entsprechenden KdNr und ZiNr (für die dann ja Werte in Gast.KdNr und Zimmer.ZiNr gefunden werden) eingefügt werden. 9 Granularität = kleinste, mit einer Datenbankoperation erreichbare Attributmenge. Man unterscheidet dabei einmal die Zeile (z.b. Löschen mindestens einer Zeile, nicht aber eines Attributes) und den Attributwert (z.b. Ändern nur eines Attributwertes, die übrigen Attributwerte bleiben unverändert).

15 Strukturierung der Daten (Normalisierung) 15 DELETE in einer referenzierten Relation (Gast und Zimmer) erfordert erst das Löschen der/des entsprechenden Tupels in der/den referenzierenden Relation/en (Vermietung); m.a.w. ist bspw. zuerst die Vermietung mit der entsprechenden KdNr/ZiNr-Kombination zu löschen; erst dann kann der Gast mit der entsprechenden KdNr und (es handelt sich ja hier um eine zusammengesetzte Fremdschlüsselbeziehungen) das Zimmer mit der entsprechenden ZiNr gelöscht werden. Andernfalls würde ja auch bspw. eine Rechnung für eine Vermietung keine Gastadresse mehr finden. UPDATE erfordert dagegen eine differenzierte Betrachtung: Zum einen könnte man die Änderung des Wertes eines Primärschlüsselattributes, zum anderen auch die eines Nichtschlüsselattributs und drittens auch die eines Fremdschlüsselattributs vornehmen wollen. Die Änderung des Wertes eines Nichtschlüsselattributes in referenzierender und referenzierter Relation (z.b. Vermietung.Dauer und Zimmer.Art oder Gast.Name) stellt uns vor keine Probleme, da die Fremdschlüsselbeziehungen dadurch nicht berührt werden. Die Änderung eines Primärschlüsselattributwertes wird in der/den referenzierten Relation/en (Gast/Zimmer) auf jeden Fall abgewiesen, da sich - wie beim Ändern - ein Informationsverlust einstellen würde (nicht für alle Tupel in der referenzierenden Relation (Vermietungen) würde dann ein Gast/Zimmer in der/den referenzierten Relation/en (Gast/Zimmer) gefunden. Gleiches gilt für die Primärschlüsselattribute der referenzierenden Relation/en (Vermietung). In diesem Falle wäre nur ein Löschen und ein anschließendes Einfügen (in der jeweils oben beschriebenen Reihenfolge) möglich. Für den Wert eines Fremdschlüsselattributs in der (ja nur dort vorkommenden) referenzierenden Relation (Vermietung) ist in den oben genannten Grenzen (KdNr und ZiNr müssen in Gast/Zimmer vorhanden sein) eine Änderung möglich: eine in Gast vorhandener KdNr kann ja jederzeit ein in Zimmer vorhandene ZiNr buchen; da jedoch hier die Fremd- zugleich auch die Primärschlüsselkombination der Relation Vermietung ist, scheitert dies an der Nichtänderbarkeit der Primärschlüssel (s.o.)! Zu lösen wäre dieses Problem, wenn in Vermietung eine fortlaufende Buchungsnummer (BuNr) als Primärschlüsselattribut eingefügt würde (wie dies ja bereits geschehen ist) und die Primärschlüsseleigenschaft der Attribute KdNr sowie ZiNr in Vermietung aufgehoben würden. Dann wäre hier eine Änderung von Vermietung.KdNr und Vermietung.ZiNr möglich Weitere Integritätsbedingungen Im Rahmen der Entwicklung des obigen Datenbankschemas wurde bisher auf die Bedeutung der referentiellen Integrität sowie die der Entitätsintegrität hingewiesen. Neben diesen ist darüber hinaus auch die benutzerdefinierte Integrität von Bedeutung. Im Rahmen der Sicherstellung der benutzerdefinierten Integrität ist es oft wünschenswert, die Einhaltung von Werten einer Domäne (Wertebereich) sicherzustellen, um "unsinnige" Eingaben zu verhindern. Eine solche Sicherung könnte auf unterschiedliche Art und Weise bewirkt werden: Zum einen sind zu verschiedenen Datenbanken Werkzeugprogramme (TOOLS) erhältlich, die über solche Sicherungsmechanismen verfügen (z.b. SQL-Forms für das DB-System ORACLE). Weiterhin könnten über die Verwendung von Views (s. unten) unter Einsatz der CHECK OPTION Wertebereiche eingegrenzt werden (sog. Constraints). Sofern solche Mechanismen jedoch in dem verwendeten Datenbanksystem nicht implementiert sind, hilft oft der "Umweg" über die Nutzung der Instrumente zur Sicherstellung der referentiellen Integrität. Ein Beispiel mag den Zusammenhang erhellen: Nehmen wir an, unsere Relation Gast sollte für die Zwecke der Serienbrieferstellung ein zusätzliches Attribut Anrede erhalten: m für männlich (Anrede: Herrn), w für weiblich (Anrede: Frau) und f für Firma (Anrede: keine spezielle). Bei der Erfassung neuer Gäste kann es nun vorkommen, dass dem Erfasser der Daten die Kürzel nicht präsent sind. Er könnte bspw. für männlich H (Anrede: Herrn) und für weiblich F (Anrede: Frau) eingeben. Bei entsprechender Selektion durch ein Textverarbeitungssystem, das Serienbriefanschriften aus unserer Datenbank entnimmt, könnten die Tupel, die mit H oder F gekennzeichnet sind, nicht korrekt verarbeitet werden, da die Tupel ja nach Anrede=m oder Anrede=w oder Anrede=f selektiert würden. Zur Lösung eines solchen (oder ähnlichen Problems) könnte man eine zusätzliche Relation Floskel in die Datenbank aufnehmen. Diese weist einen Grad von 1 auf (d.h., sie hat genau 1 Attribut, das wir Bezeichnung nennen wollen). Wir nehmen dazu genau 3 Tupel (Kardinalität der Relation ist dann 3) in die Relation auf: Nämlich die Werte "m", "w" und "f" (für Herrn/ Frau/Firma). Was haben wir nun erreicht? Wenn wir zwischen dem Attribut Gast.Anrede und dem Attribut Floskel.Bezeichnung eine Fremdschlüsselbeziehung aufbauen (Gast.Anrede referenziert Floskel.Bezeichnung), so wird die Aufnahme einer Anrede bei der Erfassung des neuen Gastes, deren Wert nicht in Flos-

16 16 Strukturierung der Daten (Normalisierung) kel.bezeichnung enthalten ist, abgewiesen. Es kann somit nicht zu einer falschen Erfassung von Werten für die Anrede kommen. Das geschilderte Problem erscheint relativ trivial. Ein ähnliches Problem jedoch könnte die Erfassung von Rechtsformen gespeicherter Unternehmen sein. Wer will dann aber noch zwischen den (identischen) Rechtsformen "GmbH +.CO" bzw. "GmbH & CO" oder auch "GmbH & CO.KG" bei einer Selektion nach Rechtsformen unterscheiden? Insgesamt ergeben sich folgende Relationen, die nun unmittelbar in die Datenbanksprache SQL umgesetzt werden können. Die Relationennamen entsprechen den Tabellennamen, die Attributbezeichnungen den der Spaltennamen der Datenbank. Primärschlüssel sind doppelt, Fremdschlüsselbeziehungen einfach unterstrichen: R.Gast (KdNr, Name, Wohnort, Strasse) R.Zimmer (ZiNr, Ausstattung, Art ) R.Preis R.Vermietung (Ausstattung, Art, Miete) (BuNr, KdNr, ZiNr, Dauer) Abb. 25: Relationenschema zur Datenbank Hotel mit Primär- und Fremdschlüsseln Ungelöst ist allerdings noch das Problem der Postleitzahlen. Soll die Adresse um eine Postleitzahl ergänzt werden, müsste genau genommen zusätzlich die Relation PLZ R.PLZ (Ort, PLZ) Abb. 26: Ergänzungen zum Relationenschema Hotel als eigenständige Relation errichtet werden. Andernfalls würde - bei Aufnahme der PLZ in die Relation Gast - die Forderung der 3NF (Nicht-Transitivität, d.h., keine wechselseitige Abhängigkeit der Nichtschlüsselattribute) nicht erfüllt: Die PLZ ist funktional abhängig vom Ort, nicht aber vom Primärschlüssel der Relation, der Kundennummer des Gastes. Sichtbar würde dies nicht nur am Datenbankschema, sondern auch an einem möglichen Inhalt der Datenbasis. Hier wären dann nämlich folgende Entities vorstellbar: R.Gast_Mit_PLZ KdNr PLZ Wohnort Grundhof Grundhof Abb. 27: Relation Gast mit Verstoß gegen die 3NF Es ist unmittelbar einsichtig, dass bei Änderungen des Wohnortes des Gastes mit der KdNr 1 (z.b. in den Ort Hagen) und "vergessener" Änderung der PLZ (in 58093) Mutationsanomalien entstehen. Dies kann durch Auslagerung in die Relation PLZ einfach verhindert werden, da sich dort dann die korrekte Postleitzahl für Hagen finden würde. Dadurch würde zugleich das Auftreten einer transitiven Abhängigkeit zwischen PLZ und Wohnort (wechselseitige Abhängigkeit, keine direkte Abhängigkeit vom Primärschlüssel) verhindert. Die Beziehung zwischen Postleitzahl und Ort ist in der Bundesrepublik wie folgt zu beschreiben: Jeder Ort hat genau eine Postleitzahl; eine Postleitzahl kann jedoch zu mehreren Orten gehören. Daher wurde der Ort(sname) als Primärschlüssel für die Relation PLZ verwendet. Die wenigen Ausnahmen, dass ein Ort auch mehrere Postleitzahlen haben kann, vernachlässigen wir hier. Dieser Umstand könnte aber durch Bildung der Primärschlüsselkombination PLZ, ORT berücksichtigt werden. Nach der Einführung des neuen Postleitzahlsystems ändert sich die Situation allerdings: Größere Orte können nun über mehrere Postleitzahlen verfügen. Außerdem gibt es die an ein Postfach gekoppelte Postleitzahl und zusätzlich die Postleitzahl von Großkunden. Dies würde letztlich bedeuten, dass das Gesamtverzeichnis der Postleitzahlen jeweils als eigenständige Relation vorzuhalten wäre.

17 Strukturierung der Daten (Normalisierung) 17 Es müsste eine Fremdschlüsselbeziehung zwischen Ort und Straße bzw. Postfach hergestellt werden. Dies bedeutet jedoch, dass auch bei einem geringem Adressenbestand eine große Datenmengen (im Prinzip das gesamte Verzeichnis der Postleitzahlen in Deutschland) in einer Relation vorzuhalten wären. Daher erscheint es in diesen Fällen sinnvoll, die Postleitzahl als Attribut zur (Gast-) Adressen aufzunehmen und die Redundanz in Kauf zu nehmen.

18 18 Einrichtung der Datenbank (DDL) 2. Einrichtung der Datenbank (DDL) Vor der konkreten Einrichtung der Relationen in der Datenbank muss die Wahl geeigneter Datentypen erfolgen. Die Wahl der Datentypen für die Attribute hängt in hohem Maße von dem verwendeten DBMS ab. Die hier gezeigten Typen werden u.a. vom Datenbanksystem INTERBASE 10 unterstützt. Vor der Errichtung der Tabellen lassen sich entsprechende Domänen im DBMS einrichten, die eine exakte Abgrenzung von möglichen Wertemengen erlauben. Domäne Datentyp Check DomKdNr Integer Values Between 100 and 999 DomZiNr Integer Values Between 100 and 300 DomArt VarChar(2) Values in ( EZ, DZ ) Abb. 28: Domänen der Datenbank HOTEL Spalte Datentyp Inhalt Primärschlüssel Fremdschlüssel KdNr DomKdNr Kundennummer Gast Vermietung Name VarChar(50) Name des Gastes - - Wohnort VarChar(50) Wohnort des Gastes - PLZ Strasse VarChar(50) Strasse des Gastes - ZiNr DomZiNr Zimmernummer Zimmer Vermietung Art DomArt Einzel-/Doppelzimmer Preis Zimmer Ausstattung Varchar(10) Ausstattungskürzel Preis Zimmer Miete Double Precision -Betrag je Nacht und Person - - BuNr Integer Buchungsnummer Vermietung - Dauer Integer Aufenthalt in Tagen - - Abb. 29: Datentypen der Attributswerte der Relationen Die Einrichtung der Datenbank erfolgt mit den DDL 11 Statements von SQL; diese lassen sich wie folgt strukturieren: (a) Bildung physikalischer Strukturen CREATE OPEN CLOSE DROP CREATE ALTER DROP CREATE (b) Bildung logischer Strukturen DATABASE TABLESPACE INDEXSPACE BUFFERSPACE CREATE ALTER DROP CREATE DROP TABLE VIEW INDEX SCHEMA 10 Das Datenbanksystem Interbase wird als lokale Datenbank von Inprise (Borland) mit der Entwicklungsumgebung DELPHI ausgeliefert und ist mittlerweile auch unter Open Source verfügbar. Für die Beispiele wurde die Version: WI-V verwendet. 11 DDL = Data Definition Language (CREATE, DROP,...) DCL = Data Control Language (GRANT, REVOKE: Verwaltung von Rechten der Benutzer).

19 Einrichtung der Datenbank (DDL) 19 (c) Datenbankerweiterung/Rekonstruktion CREATE DROP SYNONYM Abb. 30: DDL Befehle von SQL Die Datenbank wird nun mit der folgenden Anweisung eingerichtet: CREATE DATABASE HOTEL USER xyz PASSWORD mypassword Damit wird die Datenbank auch zugleich eröffnet. Nach Verlassen mit EXIT und neuer Nutzung kann diese dann mit CONNECT DATABASE Hotel adressiert werden. Anschließend wird ist der physikalische Speicherplatz zu reservieren: CREATE TABLESPACE Dateiname; CREATE INDEXSPACE Dateiname; Die Einrichtung und Strukturierung der Tabellen erfolgt mit der CREATE TABLE-Anweisung. Das DDL Statement CREATE TABLE ist ein extrem komplexer Befehl, der je nach SQL-Implementierung über eine Vielzahl von Optionen z.b. zur Sicherung der referentiellen Integrität der Datenbasis verfügt. CREATE TABLE [creator].tabellenname (Spaltenname Spaltentyp, [NOT NULL [UNIQUE] [DEFAULT literal NULL USER] [PRIMARY KEY] [REFERENCES [creator.]tabellenname [ON UPDATE RESTRICT [ON DELETE RESTRICT CASCADE SET NULL]] {,repeat} [,UNIQUE (Liste von Spaltennamen)] [,PRIMARY KEY(Liste von Spaltennamen)] [,FOREIGN KEY (Liste von Spaltennamen)] REFERENCES [creator.]tabellenname [ON UPDATE RESTRICT [ON DELETE RESTRICT CASCADE SET NULL]] {,repeat} [IN TABLESPACE INDEXSPACE Dateiname] [CHECK (Spaltenname Restriktion) {,repeat} Abb. 31: DDL Befehl CREATE TABLE von SQL Dabei gelten die folgenden Konventionen: [] Optionale Angaben {} wiederholbare Angaben alternative Angaben/Optionen Die Bedeutung der wichtigsten Schlüsselwörter dabei sind: NOT NULL UNIQUE PRIMARY KEY FOREIGN KEY/ REFERENCES ON DELETE/ON UP- DATE keine Null-Werte erlaubt, kein Leerfeld identische Werte in unterschiedlichen Tupeln nicht erlaubt definiert das/die Schlüsselfelder Festlegung einer Fremdschlüsselbeziehung durch Angabe der referenzierten Tabelle; Spaltenname muss identisch sein. Statements zur Sicherung der referentiellen Integrität der Datenbank Abb. 32: Schlüsselwörter des CREATE TABLE Befehls von SQL

20 20 Einrichtung der Datenbank (DDL) Die entworfenen Relationen können damit wie folgt eingerichtet werden: CREATE TABLE Gast (KdNr DomKdNr NOT NULL PRIMARY KEY, Name Varchar(50) NOT NULL, Wohnort Varchar(50), Strasse Varchar(50)); Abb. 33: Einrichtung der Relation Gast Zusätzlich könnte die Spalte Gast.Wohnort auch die Spalte PLZ.Ort als Fremdschlüssel referenzieren. Dies hätte den Vorteil, dass ein neuer Gast nur dann eingefügt werden könnte, wenn sich in der Tabelle PLZ auch der entsprechende Ortsname finden würde. Das Weglassen dieser Option führt dann dazu, dass bei einer Anfrage nach der vollständigen Adresse eines Gastes (inkl. Postleitzahl) ein solcher Gast nicht selektiert würde. Vermeiden ließe sich dies durch die Formulierung der Anfrage als Outerjoins, einer speziellen Form des Joins (zum Join siehe unten). Andererseits lässt sich durch das hier gewählte Relationenschema auch ein Gast ohne PLZ erfassen. Dann kann die Relation Preis erfasst werden, da sie ebenfalls keine Fremdschlüsselbeziehung aufweist. CREATE TABLE Preis (Ausstattung Varchar(10) NOT NULL, Art DomArt NOT NULL, Miete Double Precision NOT NULL, PRIMARY KEY (Ausstattung, Art)); Abb. 34: Einrichtung der Relation Preis Nun kann die Relation Zimmer formuliert werden, da sie die Relation Preis referenziert und diese bereits implementiert ist. CREATE TABLE Zimmer(ZiNr Dom ZiNr NOT NULL PRIMARY KEY, Ausstattung Varchar(10) NOT NULL, Art DomArt NOT NULL, FOREIGN KEY (Ausstattung, Art) REFERENCES Preis); Abb. 35: Einrichtung der Relation Zimmer Die Angabe REFERENCES Preis baut eine Fremdschlüsselbeziehung zu dem gleichnamigen Attribut Ausstattung der Relation Preis auf. Dabei könnten entsprechende Optionen für das Löschen (z.b. Löschen einer Ausstattungs-/Preisrelation führt zur Ablehnung [Option ON DELETE RESTRICT), so dass die referentielle Integrität sichergestellt bleibt) formuliert werden. Das Weglassen einer solchen Option impliziert hier jedoch automatisch die RESTRICT Option. Es fehlen noch die Tabellen Vermietung und PLZ für die Datenbank HOTEL: CREATE TABLE Vermietung(BuNr Integer NOT NULL PRIMARY KEY, KdNr DomKdNr NOT NULL REFERENCES Gast, ZiNr DomZiNr NOT NULL REFERENCES Zimmer, Dauer Integer NOT NULL); Abb. 36: Einrichtung der Relation Vermietung CREATE TABLE PLZ (PLZ Numeric(4), Ort VarChar(50) NOT NULL PRIMARY KEY); Abb. 37: Einrichtung der Relation Postleitzahl