Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

SS 2004B. König-Ries: Datenbanksysteme4-1 Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung.

Ähnliche Präsentationen


Präsentation zum Thema: "SS 2004B. König-Ries: Datenbanksysteme4-1 Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung."—  Präsentation transkript:

1 SS 2004B. König-Ries: Datenbanksysteme4-1 Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung

2 SS 2004B. König-Ries: Datenbanksysteme4-2 Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung

3 SS 2004B. König-Ries: Datenbanksysteme4-3 Einordnung (1) Elementare Zustandsräume Konstruktoren für Zustandsräume Operatoren Datenmodell Konkreter Zustandsraum Konkrete Konsistenz- bedingungen DB-Schema Konkrete Zustände (schemaverträglich ) Transaktionsproze- duren Datenbasis Grundsätzliche Organisation des DBMS Organisation der DB für eine bestimmte Miniwelt Beschreibung eines bestimmten Zustands der Miniwelt DB-EntwurfDB-Betrieb

4 SS 2004B. König-Ries: Datenbanksysteme4-4 Einordnung (2) Primärdaten Externes Datenmodell Anfragebearbeitung Internes Datenmodell Satz- u. Satzmengenverwaltung Physische Datenstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Daten- wörterbuch Metadaten Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung

5 SS 2004B. König-Ries: Datenbanksysteme4-5 Anforderungen an rel. Datenbasisschema Passende Informationskapazität: Datenbasis muss genügend großen Zustandsraum besitzen, um alle relevanten Zustände der Miniwelt abzubilden, aber nicht mehr. Intuitivität: Gruppierung der Attribute zu Relationen sollte semantische Zusammenhänge der Miniwelt widerspiegeln. Anfragen sollten in möglichst natürlicher Weise formuliert werden können. Effizienz: Zusammenführung der Daten bei Lese-Operationen sollte möglichst wenig Verbindungs-Operationen (Joins) erfordern. Überwachung der Konsistenzbedingungen bei Schreib-Operationen sollte möglichst wenig Aufwand erfordern.

6 SS 2004B. König-Ries: Datenbanksysteme4-6 Aufgabe Datenbankentwurf: Methodisches Vorgehen zur Modellierung der Miniwelt und Überführung in ein Datenbasisschema. Nachdruck auf Informationskapazität und Intuitivität Einflussfaktoren: Semantische Lücke zwischen Gegebenheiten der Miniwelt und Typsystem + Konsistenzregeln des Datenmodells Hohe Kosten nachträglicher Schema-Änderungen Relationales Schema ABCABABCD ? Miniwelt Semantische Lücke

7 SS 2004B. König-Ries: Datenbanksysteme4-7 Lösung (1) Naheliegender Ansatz: Überwinde semantische Lücke nicht in einem Schritt, sondern sukzessive. Üblich sind zwei Abbildungsschritte: Zwischenschalten einer weiteren Modellierungsebene (sog. konzeptuelle Modellierungsebene) zwischen Miniwelt und Datenmodell. Vorteil: Modellierungs-Elemente der konzeptuellen Ebene müssen nicht implementiert werden, daher keine Einschränkung der Ausdrucksmächtigkeit zugunsten von Effizienz erforderlich. Abbildung von konzeptueller auf Datenmodell-Ebene hat definierte Spielräume, bietet daher Entwurfsfreiräume für Kompromisse zwischen den Anforderungen.

8 SS 2004B. König-Ries: Datenbanksysteme4-8 Lösung (2) Anforderungen an Semantisches Datenmodell: Ausdrucksmächtigkeit Aspekt-Vielfalt Klare Semantik Standardisierung Werkzeugunterstützung Logisches Schema ABCABABCD Miniwelt Konzeptuelles (semantisches) Schema vonnach Strecke Entfernung 1.. Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone Flugzeugtyp FtypId {eindeutig} Name First Business Economy Flug FlugNr {eindeutig} Wochentage Kunde Name {eindeutig} Telefon Passagier TicketNr {eindeutig} WirdGeflogenMIt Gibt SitzeinteilungVorFür Bedient Abflugszeit Ankunftszeit PlatzCode Datum 1.. Buchung 0..1 {Strecke.von Flug.Bedient.von} hatBuchung Semantisches Datenmodell Logisches Datenmodell

9 SS 2004B. König-Ries: Datenbanksysteme4-9 Lösung (3) Logisches Schema ABCABABCD Miniwelt Konzeptuelles (semantisches) Schema vonnach Strecke Entfernung 1.. Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone Flugzeugtyp FtypId {eindeutig} Name First Business Economy Flug FlugNr {eindeutig} Wochentage Kunde Name {eindeutig} Telefon Passagier TicketNr {eindeutig} WirdGeflogenMIt Gibt SitzeinteilungVorFür Bedient Abflugszeit Ankunftszeit PlatzCode Datum 1.. Buchung 0..1 {Strecke.von Flug.Bedient.von} hatBuchung Semantisches Datenmodell Logisches Datenmodell Relationales Datenmodell UML (intuitiv) Erweitert relational (formal) makroskopische Betrachtung mikroskopische Betrachtung Überarbeitung Schematransformation

10 SS 2004B. König-Ries: Datenbanksysteme4-10 Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung

11 SS 2004B. König-Ries: Datenbanksysteme4-11 Beschränkung auf die für den Datenbankentwurf bedeutsamen Konstrukte Makroskopische Betrachtung Systemanalytischer Ausgangspunkt: Klassischer Systembegriff als Ansammlung von Objekten und von Beziehungen, die zwischen den Objekten bestehen. Primäres Strukturierungsmittel: Klassifikation zu Mengen irgendwie als ähnlich angesehener Objekte. Vorgehen: Informell, pragmatisch, stark graphisch orientiert. Historie: Entity-Relationship Modeling (ERM) Object Modeling Technique (OMT) Unified Modeling Language (UML)

12 SS 2004B. König-Ries: Datenbanksysteme4-12 Diagramme von UML (1) Anwendungsfalldiagramm (use case diagram) (2) Klassendiagramm (class diagram) (3) Sequenzdiagramm (sequence diagram) (4) Kollaborationsdiagramm (collaboration diagram) (5) Zustandsdiagramm (statechart diagram) (6) Aktivitätsdiagramm (activity diagram) (7) Komponentendiagramm (component diagram) (8) Verteilungsdiagramm (deployment diagram) Implementierungs- diagramme (implementation diagrams) Interaktions- diagramme (interaction diagrams) Verhaltens- diagramme (behavior diagrams) Struktur- diagramm

13 SS 2004B. König-Ries: Datenbanksysteme4-13 UML-Klassendiagramm: Klassen Basiselemente des Klassendiagramms: Objekt: Modell eines wohlunterscheidbaren Gegenstandes in der Miniwelt. Klasse: Repräsentant einer Menge von Objekten. Definition einer Klasse setzt sich aus Attributen und Operatoren zusammen. Beispiele: Flüge, Flugzeugtypen, Flughäfen, Kunden, Tickets. Darstellung: Kunde Name: string TelNr: string buchen (FlugNr: string, Datum: date) stornieren (FlugNr: string, Datum: date)

14 SS 2004B. König-Ries: Datenbanksysteme4-14 UML-Klassendiagramm: Zusicherungen Zusicherungen: Ergänzung von Klassenbeschreibungen durch einfache Konsistenzbedingungen. Beispiele: Einschränkung des Wertebereichs eines Attributs über den Datentyp hinaus, Aufrufbedingungen für Operatoren, Schlüsselbedingungen. Ticket TicketNr: int {TicketNr>0, TicketNr eindeutig}

15 SS 2004B. König-Ries: Datenbanksysteme4-15 UML-Klassendiagramm: Vererbung Generalisierung: Zusammenführen mehrerer Klassen zu einer Klasse durch Beschränkung auf ihre gemeinsamen Eigenschaften. Spezialisierung: Gewinnen mehrerer neuer Klassen aus einer Klasse durch Hinzufügen unterschiedlicher spezieller Eigenschaften. Darstellung: Semantik: Vererbung von Eigenschaften der Oberklassen an die entsprechenden Unterklassen. Kunde Internetkunde Reisebürokunde

16 SS 2004B. König-Ries: Datenbanksysteme4-16 UML-Klassendiagramm: Assoziationen (1) Objektverbindung: Beziehung zwischen individuellen Objekten. Assoziation: Klassifikation einer Menge von Objektverbindungen, definiert zwischen Klassen. Gewöhnlich zwischen verschiedenen Klassen, darf aber auch reflexiv sein. Stelligkeit einer Assoziation: Anzahl der Objekte, die an den individuellen Objektverbindungen teilhaben. Nicht beschränkt, binärer Fall jedoch am häufigsten. Notation binär: FlugFlugzeugtyp

17 SS 2004B. König-Ries: Datenbanksysteme4-17 UML-Klassendiagramm: Assoziationen (2) Jede Assoziation wird mit einem Assoziationsnamen versehen, der beschreibt, worin die Beziehung besteht. Assoziationsnamen haben dann natürliche Leserichtung von einem Klassennamen zum anderen, die man durch einen Pfeil neben dem Namen kennzeichnet. Assoziationsnamen können für beide Leserichtungen notiert werden: FlugFlugzeugtyp WirdGeflogenMit Gibt SitzeinteilugVorFür

18 SS 2004B. König-Ries: Datenbanksysteme4-18 UML-Klassendiagramm: Assoziationen (3) Bei drei- und mehrstelligen Assoziationen entfällt Leserichtung. Assoziationen können als eigene Assoziationsklasse ausgebildet und mit Attributen versehen werden: KundeTicket Flug platzCode: string datum: date Buchung

19 SS 2004B. König-Ries: Datenbanksysteme4-19 UML-Klassendiagramm: Assoziationen (4) Assoziationen belassen viel Spielraum für die Modellierung. Gleiche Sachverhalte können unterschiedlich modelliert werden: KundeFlug TicketNr: string platzCode: string datum: date Bucht

20 SS 2004B. König-Ries: Datenbanksysteme4-20 UML-Klassendiagramm: Assoziationen (5) Multiplizität der Assoziation bezüglich einer Klasse: Anzahl der individuellen Objektverbindungen, die eine Instanz dieser Klasse eingehen kann. Im zweistelligen Fall: Mit wie vielen Objekten der gegenüberliegenden Klasse kann ein Objekt der Klasse verbunden sein? Vermerk in Leserichtung, also bei der gegenüberliegenden Klasse FlugFlugzeugtyp WirdGeflogenMit Gibt SitzeinteilungVorFür

21 SS 2004B. König-Ries: Datenbanksysteme4-21 UML-Klassendiagramm: Assoziationen (6) Multiplizität bei mehrstelligen Assoziationen hat wenig intuitive UML- Definition: Betrachte bei Stelligkeit n Kombination von n-1 Objekten und bestimme, mit wie vielen Objekten der verbleibenden Klasse sie verbunden sein kann KundeTicket Flug platzCode: string datum: date Buchung Multiplizität gilt für Flug als Flugbewegung, nicht als Flugplanung! Flugbewegung, wenn Datum zur Differenzierung mit einbezogen werden könnte. In UML nicht vorgesehen! Mit Multiplizitäten lassen sich also Unstimmigkeiten bei der Modellierung aufdecken!

22 SS 2004B. König-Ries: Datenbanksysteme4-22 UML-Klassendiagramm: Assoziationen (7) Anbindung von Zusicherungen an Assoziationen: { k1,k2 Kunde: k1.Buchung.TicketNr = k2.Buchung.TicketNr k1=k2} Alternativ: Das selbe Ticket gehört unabhängig vom Flug zu genau 1 Kunden! KundeTicket Flug platzCode: string datum: date Buchung

23 SS 2004B. König-Ries: Datenbanksysteme4-23 UML-Klassendiagramm: Assoziationen (8) Rolle: Sichtweise eines Objektes durch das gegenüberliegende Objekt. Besonders bei reflexiven Assoziationen interessant. Flug Anschlussflug Ankommend Abgehend

24 SS 2004B. König-Ries: Datenbanksysteme4-24 UML-Klassendiagramm: Assoziationen (9) Gerichtete Assoziation: Assoziation, die nur in einer Richtung traversiert werden soll. (Als Optimierungshinweis für Implementierung aufzufassen.) Notation durch offene Pfeilspitze: Flug Anschlussflug Ankommend Abgehend

25 SS 2004B. König-Ries: Datenbanksysteme4-25 UML-Klassendiagramm: Aggregationen Aggregation: Ganzes-Teile-Beziehung als Sonderfall einer Assoziation. Aggregationen dürfen Multiplizitäten aufweisen, jedoch gehört ein Teil nur zu höchstens einem Ganzen. Existenzgebunden, andernfalls. FlughafenTerminalFlugsteig

26 SS 2004B. König-Ries: Datenbanksysteme4-26 vonnach WirdGeflogenMit Gibt SitzeinteilungVorFür AbflugszeitAnkunftszeit PlatzCode Datum Buchung Flugzeugtyp FtypId {eindeutig} Name First Business Economy Flug FlugNr {eindeutig} Wochentage Entfernung Ticket TicketNr {eindeutig} Kunde Name {eindeutig} Telefon Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone { k1,k2 Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket k1=k2} UML-Klassendiagramm: Beispiel

27 SS 2004B. König-Ries: Datenbanksysteme4-27 UML-Klassendiagramm: Faustregeln Klasse oder Assoziation? Will man über einen Sachverhalt Aussagen machen, wozu man Methoden benötigt, so sollte er als Klasse erfasst werden. Dient ein Sachverhalt lediglich dazu, eigentlich interessierende Sachverhalte zu verknüpfen, so ist für ihn eine Assoziation zu wählen.

28 SS 2004B. König-Ries: Datenbanksysteme4-28 Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung

29 SS 2004B. König-Ries: Datenbanksysteme4-29 Abbildung UML-Schema Rel. Schema (1) Abbildungsregeln für Klassen: Klasse mit allen Attributen Relation (sog. Objektrelation). Atomarer Datentyp des UML-Klassendiagramms Übernahme des Attributs, Überführung Datentyp in Domäne des relationalen Schemas. Verbund-Datentyp des UML-Klassendiagramms Pro Verbundelement: Übernahme von dessen Attribut, Überführung von dessen Datentyp in Domäne des relationalen Schemas. Mengenorientierte Datentypen des UML-Klassendiagramms Übernahme des Attributs, Nachbearbeitung der zunächst ja nicht atomaren Domäne. Für Zwecke der Transformation auf relationale Schemata müssen Schlüssel unmittelbar im Klassendiagramm in Form von Zusicherungen vermerkt werden Schlüssel der Relation.

30 SS 2004B. König-Ries: Datenbanksysteme4-30 Abbildung UML-Schema Rel. Schema (2) Abbildungsregeln für binäre Assoziationen C 1 C 2 mit Multiplizität an C 2 1: Seien RC 1, RC 2 die Objektrelationen zu C 1, C 2. Füge zu RC 1 Schlüsselattribute von RC 2 hinzu, wobei bei Namenskonflikten der Assoziationsname als Präfix vorangestellt wird. Im späteren Betrieb nehmen diese Attribute in jedem RC 1 -Tupel den Schlüssel des assoziierten RC 2 -Tupels auf (Fremdschlüssel). Ist an C 2 die Multiplizität 0..1, so können hier NULL-Werte auftreten. Falls die Assoziation attributiert ist, werden die Attribute ebenfalls C 1 zugeschlagen. Behandlung von binären Assoziationen C 1 C 2 mit Multiplizität an C 1 1 entsprechend.

31 SS 2004B. König-Ries: Datenbanksysteme4-31 Abbildung UML-Schema Rel. Schema (3) Abbildungsregeln für ternäre und höhere Assoziationen: Betrachte Assoziation A als eigene Klasse CA mit einer separaten binären Assoziation zu jeder an A beteiligten Klasse C i, dort mit Multiplizität 1. Bilde CA auf separate Relation RA ab (Assoziationsrelation). Attribute von RA sind die Schlüsselattribute jeder Objektrelation RC i sowie alle Attribute der Assoziation selber. Bei Namenskonflikten wird den Fremdschlüsselattributen von der jeweilige Rollen- oder Klassenname als Präfix vorangestellt. Alle Attribute bilden gemeinsam den Schlüssel von RA. Nachbearbeitung zur Reduktion des Schlüssels. Im Betrieb wird für jede konkrete Objektverbindung ein Tupel in RA eingefügt. Die Attribute dieses Tupels enthalten die Schlüssel der beteiligten RC i -Tupel als Fremdschlüssel.

32 SS 2004B. König-Ries: Datenbanksysteme4-32 Abbildung UML-Schema Rel. Schema (4) Abbildung von Vererbung erfordert Simulation der Zugehörigkeit von Objekten zu Oberklassen. Beispiel für Abbildungen: Jedes Objekt wird ausschließlich durch ein Tupel in derjenigen Objektrelation repräsentiert, die seinem spezifischsten Typ entspricht. Alle ererbten Attribute einer Klasse werden mit in die Objektrelation aufgenommen. Für jedes Objekt wird ein Tupel in allen Objektrelationen angelegt, die Oberklassen (inklusive der direkten Klasse) des Objekts entsprechen. Jede Objektrelation erhält nur die Schlüsselattribute der Klasse sowie die unmittelbar in der Klasse definierten, nicht ererbten Attribute. Da alle Tupel den gemeinsamen Schlüssel erhalten, ist die Zugehörigkeit zu Oberklassen implizit repräsentiert, muss dann aber von jeder Applikation nachvollzogen werden.

33 SS 2004B. König-Ries: Datenbanksysteme4-33 vonnach WirdGeflogenMIt Gibt SitzeinteilungVorFür AbflugszeitAnkunftszeit PlatzCode Datum Buchung Flugzeugtyp FtypId {eindeutig} Name First Business Economy Flug FlugNr {eindeutig} Wochentage Entfernung Ticket TicketNr {eindeutig} Kunde Name {eindeutig} Telefon Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone { k1,k2 Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket k1=k2} Anwendung der Regeln: KUNDE (Name, Telefon) TICKET (TicketNr) BUCHUNG (TicketNr, FlugNr, Name, PlatzCode, Datum) FLUGHAFEN (FlughCode, Name, Stadt, Land, Zeitzone) FLUG (FlugNr, Wochentage, Entfernung, FtypId, von, nach, Abflugszeit, Ankunftszeit) FLUGZEUGTYP (FtypId, Name, First, Business, Economy) Eindeutigkeits-Zusicherungen berücksichtigt, Multiplizitäten zum Teil verloren gegangen. Abbildung UML-Schema Rel. Schema (5)

34 SS 2004B. König-Ries: Datenbanksysteme4-34 vonnach WirdGeflogenMIt Gibt SitzeinteilungVorFür AbflugszeitAnkunftszeit PlatzCode Datum Buchung Flugzeugtyp FtypId {eindeutig} Name First Business Economy Flug FlugNr {eindeutig} Wochentage Entfernung Ticket TicketNr {eindeutig} Kunde Name {eindeutig} Telefon Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone { k1,k2 Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket k1=k2} Anwendung der Regeln: KUNDE (Name, Telefon) TICKET (TicketNr, Name) BUCHUNG (TicketNr, FlugNr, PlatzCode, Datum) FLUGHAFEN (FlughCode, Name, Stadt, Land, Zeitzone) FLUG (FlugNr, Wochentage, Entfernung, FtypId, von, nach, Abflugszeit, Ankunftszeit) FLUGZEUGTYP (FtypId, Name, First, Business, Economy) Abbildung UML-Schema Rel. Schema (6)

35 SS 2004B. König-Ries: Datenbanksysteme4-35 Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung

36 SS 2004B. König-Ries: Datenbanksysteme4-36 Motivation Nachbearbeitung eines bereits konstruierten relationalen Schemas mit dem Ziel einer Qualitätsverbesserung. Qualitätsverbesserung hier: Durchsetzen der Konsistenzbedingungen mit einem Minimum an Aufwand zur Laufzeit. Ausnutzen einer Erweiterung des relationalen Datenmodells für ein präzises, theoretisch untermauertes Vorgehen.

37 SS 2004B. König-Ries: Datenbanksysteme4-37 Vorgehen Mikroskopische Betrachtung einzelner Relationen auf bestimmte Formen von Konsistenzbedingungen (sog. Abhängigkeiten), die aufgrund der Gegebenheiten der Miniwelt für diese Relation gelten müssen. Überarbeitung: Aufstellen der Abhängigkeiten. Zerlege eine Relation nach gewissen Regeln, die die Abhängigkeiten ausnutzen, so in Teilrelationen, dass die Durchsetzung der Konsistenzbedingungen ein Minimum an Aufwand zur Laufzeit erfordert. Schematransformation): Algorithmisch. Ergebnis des Verfahrens ist eine verfeinerte Menge von Relationen (genauer: Relationstypen) mit Schlüssel- und Fremdschlüsselbedingungen, die das gesuchte Datenbankschema darstellt.

38 SS 2004B. König-Ries: Datenbanksysteme4-38 Beispielszenario (1) Sei Ergebnis der UML-Schematransformation die Relation FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name)

39 SS 2004B. König-Ries: Datenbanksysteme4-39 Beispielszenario (2) flugNr von nach ftyp wochent ab an entf ticketNr platz datum name LH458 MUC SFO 744 MDMDFSS K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 MDMDFSS A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 MDMDFSS K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 MDMDFSS A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 MDMDFSS A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 MDMDFSS E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 -D-D-S E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 -D-D-S G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 -D-D-S C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 -D-D-S D 12-AUG-00 Kuhn_Mrs_E LH501 GIG FRA M-F-S K 22-SEP-00 Nimis_Mr_J LH6390 SIN SYD 744 MDMDFSS A 06-AUG-00 Weinand_Mr_C LH6390 SIN SYD 744 MDMDFSS G 09-SEP-00 Pulkowski_Mr_S LH6391 SYD SIN 744 MDMDFSS J 20-OCT-00 Pulkowski_Mr_S LH6488 SFO HNL D10 MDMDFSS A 01-SEP-00 Schmitt_Mrs_B LH6489 HNL SFO D10 MDMDFSS A 22-SEP-00 Schmitt_Mrs_B LH676 FRA ALY 319 -D--FSS A 04-AUG-00 Nagi_Mr_K LH677 ALY FRA 319 M-M--SS F 23-AUG-00 Nagi_Mr_K LH710 FRA NRT 744 MDMDFSS D 10-SEP-00 Witte_Mr_R LH710 FRA NRT 744 MDMDFSS K 11-AUG-00 Gimbel_Mr_M LH711 NRT FRA 744 MDMDFSS B 26-AUG-00 Gimbel_Mr_M LH778 FRA SIN 744 MDMDFSS K 05-AUG-00 Weinand_Mr_C LH778 FRA SIN 744 MDMDFSS K 08-SEP-00 Pulkowski_Mr_S LH779 SIN FRA 744 MDMDFSS B 20-OCT-00 Pulkowski_Mr_S...

40 SS 2004B. König-Ries: Datenbanksysteme4-40 Abhängigkeiten Überarbeitung beruht auf Abhängigkeiten zwischen Attributen als speziellen Konsistenzbedingungen. Varianten: Funktionale Abhängigkeiten als Verallgemeinerung von Schlüsselbedingungen, Mehrwertige Abhängigkeiten als weitere Verallgemeinerung funktionaler Abhängigkeiten, Inklusionsabhängigkeiten als Verallgemeinerung von Fremdschlüsselbedingungen (spielen untergeordnete Rolle). Wegen Schema-Ebene: Alle Formen sind echte Konsistenzbedingungen, d.h. Anforderungen an spätere Relationsinstanzen (Verpflichtung für das Datenbanksystem!).

41 SS 2004B. König-Ries: Datenbanksysteme4-41 Funktionale Abhängigkeiten (1) Formale Definition: Sei R(A 1,A 2,...,A n ) Relationstyp mit Attributen A 1, A 2,...,A n. Eine funktionale Abhängigkeitsbedingung (kurz: FD) für R ist ein Ausdruck X Y mit X, Y {A 1, A 2,...,A n }. Sei Z = R\(X Y). R erfüllt die Bedingung X Y wenn für R in jedem Zustand gilt: Sind t 1 und t 2 Tupel mit t 1 [X]=t 2 [X] und t 1 [Z] t 2 [Z], so t 1 [Y]=t 2 [Y]. Zu einem bestimmten Wert unter X findet man also in jedem Tupel, in dem dieser Wert vorkommt, den selben Wert unter Y.

42 SS 2004B. König-Ries: Datenbanksysteme4-42 Funktionale Abhängigkeiten (2) Intuition: FD X Y sagt aus, dass in der modellierten Miniwelt ein X- Merkmal das Y-Merkmal eindeutig bestimmt und daher in der späteren Relation Tupel, die in ihren X-Werten übereinstimmen, auch in ihren Y- Werten übereinstimmen müssen. Lokalität der Semantik: Zusammenhang zwischen Teilmengen der Attribute mit Gültigkeit unabhängig vom Rest der Relation.

43 SS 2004B. König-Ries: Datenbanksysteme4-43 Funktionale Abhängigkeiten: Beispiele FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) soll folgende FDs erfüllen: flugNr vonvon,nach entfernung flugNr nachticketNr name flugNr abflugszeitflugNr,ticketNr platzCode flugNr ankunftszeitflugNr,ticketNr datum flugNr ftypId flugNr,platzCode,datum ticketNr flugNr wochentage Zusatzforderung: Auf jedem Flughafen darf zu jeder Zeit nur eine einzige Maschine in eine bestimmte Richtung starten: von,nach,abflugszeit flugNr

44 SS 2004B. König-Ries: Datenbanksysteme4-44 Sonderfälle: Z=W: XW YW Z= : XW Y Armstrong-Axiome für FDs Mit funktionalen Abhängigkeiten kann man rechnen! Für alle Attributmengen X, Y, Z gelten die folgenden drei Armstrong- Axiome (XY ist dabei Kurzform für X Y): Reflexivität: Falls Y X, dann X Y. Expansivität: Falls X Y, Z W, dann XW YZ. Transitivität: Falls X Y und Y Z, dann X Z. Aus diesen Axiomen folgen weitere Regeln, z.B.: Vereinigung: Falls X Y und X Z, dann X YZ. Dekomposition: Falls X YZ, dann X Y und X Z.

45 SS 2004B. König-Ries: Datenbanksysteme4-45 Armstrong-Axiome: Beispiele Reflexivität: Es gilt stets von,nach von. Expansivität: Aus flugNr nach folgt flugNr,von nach. Transitivität: Aus flugNr,platzCode,datum ticketNr und ticketNr name folgt flugNr,platzCode,datum name. Vereinigung: Aus flugNr von und flugNr nach folgt flugNr von, nach.

46 SS 2004B. König-Ries: Datenbanksysteme4-46 Hülle einer Menge von FDs Fazit: Aus einer Menge von FDs lässt sich eine Reihe weiterer FDs herleiten. Definition: Ist (endliche) Menge von FDs, dann bezeichne + die Menge aller FDs, die sich vermittels der Armstrong-Axiome aus herleiten lassen. + wird Hülle von genannt. Bemerkung: + ist wohldefiniert, weil sich nur endlich viele verschiedene FDs über den in vorkommenden Attributen formulieren lassen.

47 SS 2004B. König-Ries: Datenbanksysteme4-47 Kanonische Überdeckung Kanonische Überdeckung c einer Menge von FDs ist Gegenteil der Hülle: Minimale Menge an FDs, die noch zu äquivalent ist. Berechnung wie folgt: Zerlege alle FDs in gemäß Regel X YZ X Y X Z in FDs, die nur ein Attribut auf der rechten Seite haben. Entferne aus der resultierenden Menge von FDs alle redundanten FDs (solche, die aus den verbleibenden hergeleitet werden können). Eliminiere für jede verbleibende FD X Y alle redundanten Attribute auf der linken Seite (d.h., wenn es X X mit X Y + gibt, ersetze X Y durch X Y). Fasse unter den verbleibenden Abhängigkeiten alle solche mit gleicher linker Seite gemäß Regel X Y X Z X YZ zusammen.

48 SS 2004B. König-Ries: Datenbanksysteme4-48 Kanonische Überdeckung: Beispiel flugNr von flugNr nach flugNr abflugszeit flugNr ankunftszeit flugNr ftypId flugNr wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr Erste drei Schritte entfallen!

49 SS 2004B. König-Ries: Datenbanksysteme4-49 flugNr von flugNr nach flugNr abflugszeit flugNr ankunftszeit flugNr ftypId flugNr wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr Kanonische Überdeckung: Beispiel flugNr von, nach, abflugszeit, ankunftszeit, wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr flugNr von, nach, abflugszeit, ankunftszeit, wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr flugNr von, nach, abflugszeit, ankunftszeit, wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode, datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr flugNr von, nach, abflugszeit, ankunftszeit, wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode, datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr

50 SS 2004B. König-Ries: Datenbanksysteme4-50 Voll funktionale Abhängigkeiten Voll funktionale Abhängigkeit = Abhängigkeit, bei der auf der linken Seite nichts mehr weggelassen werden kann. Formal: Sei Menge von FDs und X Y weitere FD. X Y heißt voll funktionale Abhängigkeit bezüglich, wenn es keine echte Teilmenge X von X mit X Y + gibt. In diesem Fall wird X Y statt X Y geschrieben. Bemerkungen: voll ist immer relativ zu einer gegebenen Grundmenge von FDs zu verstehen; es handelt sich nicht um eine absolute Eigenschaft von FDs. Kanonische Überdeckung liefert volle FDs.

51 SS 2004B. König-Ries: Datenbanksysteme4-51 Voll funktionale Abhängigkeiten: Beispiel Alle für FLUGINFO ursprünglich postulierten FDs sind voll funktional bezüglich ihrer Gesamtmenge: flugNr vonvon,nach entfernung flugNr nachticketNr name flugNr abflugszeitflugNr,ticketNr platzCode flugNr ankunftszeitflugNr,ticketNr datum flugNr ftypId flugNr,platzCode,datum ticketNr flugNr wochentage

52 SS 2004B. König-Ries: Datenbanksysteme4-52 Hülle einer Attributmenge Hülle A + einer Attributmenge A bezüglich Menge von FDs ist Gesamtmenge der Attribute, die vermöge von A funktional abhängen. Berechnung durch wiederholte Anwendung von FDs aus : A + := A; while A + noch wachsend do for each (X Y) do if X A + then A + := A + Y; end for end while // A + enthält nun das Ergebnis

53 SS 2004B. König-Ries: Datenbanksysteme4-53 Hülle einer Attributmenge: Beispiel flugNr von flugNr nach flugNr abflugszeit flugNr ankunftszeit flugNr ftypId flugNr wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr {flugNr, ticketNr} + = {flugNr, ticketNr, flugNr von flugNr nach flugNr abflugszeit flugNr ankunftszeit flugNr ftypId flugNr wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr {flugNr, ticketNr} + = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, flugNr von flugNr nach flugNr abflugszeit flugNr ankunftszeit flugNr ftypId flugNr wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr {flugNr, ticketNr} + = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, flugNr von flugNr nach flugNr abflugszeit flugNr ankunftszeit flugNr ftypId flugNr wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr {flugNr, ticketNr} + = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, flugNr von flugNr nach flugNr abflugszeit flugNr ankunftszeit flugNr ftypId flugNr wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr {flugNr, ticketNr} + = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum flugNr von flugNr nach flugNr abflugszeit flugNr ankunftszeit flugNr ftypId flugNr wochentage von,nach entfernung ticketNr name flugNr,ticketNr platzCode flugNr,ticketNr datum flugNr,platzCode,datum ticketNr von,nach,abflugszeit flugNr {flugNr, ticketNr} + = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum}

54 SS 2004B. König-Ries: Datenbanksysteme4-54 Mehrwertige Abhängigkeiten (1) Verallgemeinerung einer funktionalen Abhängigkeit X Y auf den Fall, dass nicht der einzelne Y-Wert, sondern die Gesamtmenge dieser Werte durch X bestimmt wird. Beispiel: Betrachte zusätzliches Merkmal Filmtitel, das die während eines Flugs gezeigten Filme beschreibt. Naheliegende FD flugNr,datum filmtitel kann nicht gefordert werden, da auf Fernflügen evt. mehrere Filme gezeigt werden. Lösung: Mehrwertige Abhängigkeit flugNr,datum filmtitel besagt, dass flugNr und datum die Menge der zugehörigen Filmtitel unabhängig von weiteren Attributen bestimmen.

55 SS 2004B. König-Ries: Datenbanksysteme4-55 Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen): FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name LH458 MUC SFO 744 Casablanca K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi D 12-AUG-00 Kuhn_Mrs_E Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen): FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name LH458 MUC SFO 744 Casablanca K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi D 12-AUG-00 Kuhn_Mrs_E Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen): FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name LH458 MUC SFO 744 Casablanca K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi D 12-AUG-00 Kuhn_Mrs_E Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen): FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name LH458 MUC SFO 744 Casablanca K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi D 12-AUG-00 Kuhn_Mrs_E Mehrwertige Abhängigkeiten (2)

56 SS 2004B. König-Ries: Datenbanksysteme4-56 Mehrwertige Abhängigkeiten Formale Definition: Sei R(A 1,A 2,...,A n ) Relationstyp mit Attributen A 1, A 2,...,A n. Eine mehrwertige Abhängigkeitsbedingung (kurz: MVD) ist ein Ausdruck X Y mit X, Y {A 1, A 2,...,A n }. Sei Z = R\(X Y). Eine Instanz r von R erfüllt die Bedingung X Y, wenn X 2 Y Funktion: Sind t 1, t 2 Tupel in r mit t 1 [X] = t 2 [X], so existiert Tupel t 3 mit t 3 [X]=t 1 [X], t 3 [Y]=t 1 [Y], t 3 [Z]=t 2 [Z] (und aus Symmetriegründen Tupel t 4 mit t 4 [X]=t 1 [X], t 4 [Y]=t 2 [Y], t 4 [Z]=t 1 [Z]). Die Belegung der restlichen Attribute (der Kontext) darf also keine Rolle spielen! Lokalität der Semantik: Zusammenhang zwischen Teilmengen der Attribute mit Gültigkeit unabhängig vom Rest der Relation.

57 SS 2004B. König-Ries: Datenbanksysteme4-57 Mehrwertige Abhängigkeiten: Beispiele (1) Betrachte wieder ursprüngliche Variante von FLUGINFO: FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name). Buchungen und Flugplanung haben nichts miteinander zu tun, außer dass ihnen die Flugnummer gemeinsam ist. Die jeweiligen Informationen können also ohne Kenntnis des Restes gewonnen werden. flugNr ticketNr,platzCode,datum,name flugNr von,nach,ftypId,wochentage,abflugszeit,ankunftszeit,entfernung

58 SS 2004B. König-Ries: Datenbanksysteme4-58 Mehrwertige Abhängigkeiten: Beispiele (2) Dagegen ist flugNr ticketNr,platzCode (Die Flugnummer bestimmt die Tickets und die dafür belegten Sitzplätze) keine MVD, da die Menge sich mit dem Datum ändert. Stattdessen: flugNr,datum ticketNr,platzCode

59 SS 2004B. König-Ries: Datenbanksysteme4-59 Zwei Axiome Folgerungen aus Erfüllungsbedingung: MVD ist Verallgemeinerung von FD: Aus X Y folgt X Y (jede FD ist auch MVD). Unabhängigkeit von der restlichen Belegung: Aus X Y folgt X Z mit Z = R\(X Y). (Symmetrie). Folglich: Eine Instanz r von R erfüllt die Bedingung X Y, wenn gilt: r = XY (r) XZ (r).

60 SS 2004B. König-Ries: Datenbanksysteme4-60 Axiome für mehrwertige Abhängigkeiten Für MVDs gelten erweiterte Armstrong-Axiome: Sei R Relationstyp mit Attributmenge U := {A 1, A 2,...,A n } und X, Y, Z beliebige Teilmengen von {A 1, A 2,...,A n }. Dann gilt: Reflexivität: Falls Y X, dann X Y. Expansivität: Falls X Y, dann XZ YZ für Z beliebig. Transitivität: Falls X Y und Y Z, dann X (Z \ Y). Symmetrie: Falls X Y, dann X (U \ Y). Umwandlung: Falls X Y, dann X Y. Mischung: Falls X Y und XY Z, dann X (Z \ Y). Mit diesen Axiomen lässt sich Hülle + einer Menge von FDs und MVDs definieren.

61 SS 2004B. König-Ries: Datenbanksysteme4-61 Schlüssel Einordnung des Schlüsselbegriffs in Abhängigkeitstheorie: Sei R(A 1,A 2,...,A n ) Relationstyp, Menge von FDs für R und S Teilmenge von {A 1,A 2,...,A n }. S heißt Superschlüssel von R bzgl., wenn S A 1,...,A n +. S heißt Schlüssel (besser: Schlüsselkandidat) von R bzgl., wenn S A 1,...,A n +. Jede FD S X (X {A 1,A 2,...,A n }) heißt Schlüsselabhängigkeit. Bemerkung: Falls mehrere Schlüsselkandidaten für eine Relation existieren, muss einer davon als Primärschlüssel ausgezeichnet werden.

62 SS 2004B. König-Ries: Datenbanksysteme4-62 Systematisches Finden eines Schlüssels Sei Relationstyp R mit Attributen A 1, A 2,...,A n und Menge von FDs für R gegeben. Algorithmus zur Bestimmung eines Superschlüssels S für R bzgl. : S := while S + {A 1,...,A n } do choose A i {A 1,...,A n } \ S + S := S {A i } end while // S ist jetzt Superschlüssel Bemerkung: Algorithmus liefert nicht notwendig Schlüssel. Dieser kann jedoch stets aus S durch Weglassen von Attributen gewonnen werden.

63 SS 2004B. König-Ries: Datenbanksysteme4-63 Finden eines Schlüssels: Beispiel FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr vonvon,nach entfernung flugNr nachticketNr name flugNr abflugszeitflugNr,ticketNr platzCode flugNr ankunftszeitflugNr,ticketNr datum flugNr ftypId flugNr,platzCode,datum ticketNr flugNr wochentage IterationSS + A i 1{}{} {flugNr} 2{flugNr} {flugNr,von,nach,abflugszeit,ankunftszeit, {ticketNr} ftypdId,wochentage,entfernung} 3{flugNr, ticketNr} -- alle Attribute --

64 SS 2004B. König-Ries: Datenbanksysteme4-64 Schlüssel von FLUGINFO Durch Ausprobieren erhält man Menge aller Schlüssel von FLUGINFO: {flugNr,ticketNr} {flugNr,platzCode,datum}

65 SS 2004B. König-Ries: Datenbanksysteme4-65 Anomalien MVD X Y für Relationstyp R(A 1,...,A n ) besagt, dass jede Instanz r natürliche Verbindung semantisch unabhängiger Teilrelationen r XY := XY (r) und r XZ := XZ (r) ist: r = XY (r) XZ (r) mit Z = {A 1,...,A n } \ (X Y), XZ {A 1,...,A n } XY. Gilt auch, falls X Y aber X Z. MVDs sind unerwünscht, da sie bei Schreibzugriffen sogenannte Anomalien verursachen. Problem: Wegen Kombination in einer Relation r muss für ein XY- Tupel der gesamte XZ-Kontext mitgeführt werden Einfüge-, Änderungs- und Lösch-Anomalien.

66 SS 2004B. König-Ries: Datenbanksysteme4-66 Einfüge-Anomalien Es werde MVD X Y und assoziierte Gleichung r = XY (r) XZ (r) mit Y X und Z = {A 1,...,A n } \ (X Y) unterstellt. Einfüge-Anomalie: XY-Wertekombination kann nicht in r eingefügt werden, solange keine Z-Werte vorliegen. Beispiel: Einfügen eines neuen Fluges in FLUGINFO erst möglich, wenn zumindest eine Buchung vorliegt (da Werte für Attribute ticketNr, platzCode, datum, name benötigt werden). Abhilfe durch Verwendung von NULL-Werten für fehlende Attributwerte möglich, allerdings unter Inkaufnahme komplexerer SQL-Semantik.

67 SS 2004B. König-Ries: Datenbanksysteme4-67 Änderungs-Anomalien Es werde MVD X Y und assoziierte Gleichung r = XY (r) XZ (r) mit Y X und Z = {A 1,...,A n } \ (X Y) unterstellt. Änderungs-Anomalie: XY-Wertekombination wird redundant für jede Z-Wertekombination gespeichert, Änderungen müssen daher mehrfach durchgeführt werden. Beispiel: Änderung der Ankunftszeit eines Fluges in FLUGINFO muss redundant für jede vorliegende Buchung durchgeführt werden.

68 SS 2004B. König-Ries: Datenbanksysteme4-68 Lösch-Anomalien Es werde MVD X Y und assoziierte Gleichung r = XY (r) XZ (r) mit Y X und Z = {A 1,...,A n } \ (X Y) unterstellt. Lösch-Anomalie: Beim Löschen der letzten Z-Wertekombination für gegebene X-Wertekombination gehen auch alle zugehörigen Y- Wertekombinationen verloren. Beispiel: Beim Löschen der letzten Buchung für einen Flug in FLUGINFO geht auch jedwede Information über FlugNr, Start- und Zielflughafen, FtypId etc. verloren. Gegenstück zu Einfüge-Anomalie, Abhilfe ebenfalls durch NULL-Werte möglich.

69 SS 2004B. König-Ries: Datenbanksysteme4-69 Ziel der Normalisierung Normalisierung: Prozess der Schematransformation mit den Zielen: Beseitigen von MVDs. DBMS kann Schlüsselbedingungen effizient überwachen; Normalisierung versucht daher, FDs in Schlüsselbedingungen zu transformieren. Auch damit lassen sich MVDs eliminieren. Zu Grunde liegendes Ziel: Beseitigen der Anomalien bei Schreiboperationen.

70 SS 2004B. König-Ries: Datenbanksysteme4-70 Schlüssel- und Nichtschlüsselattribute Definition (technisch, für Normalformenlehre): Sei R(A 1,...,A n ) Relationstyp und Menge von FDs für R. Ein Attribut A i heißt Schlüsselattribut von R bzgl., wenn es einen Schlüsselkandidat S von R bzgl. mit A i S gibt, und Nichtschlüsselattribut sonst. Beispiel: Schlüssel von FLUGINFO sind: {flugNr,ticketNr} {flugNr,platzCode,datum} Schlüsselattribute von FLUGINFO sind also: flugNr, ticketNr, platzCode, datum.

71 SS 2004B. König-Ries: Datenbanksysteme4-71 Normalisierung: Vorgehen und Ziele Umsetzung der Ziele durch Zerlegung von Relationen in Teilrelationen mit kleineren Attributmengen. Zu klären: 1)Welche Zerlegungen sind gut? 2)Welche Zerlegungen sind korrekt? 3)Wie findet man gute und korrekte Zerlegungen?

72 SS 2004B. König-Ries: Datenbanksysteme4-72 Normalformen FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) FDs: flugNr vonvon,nach entfernung flugNr nachticketNr name flugNr abflugszeitflugNr,ticketNr platzCode flugNr ankunftszeitflugNr,ticketNr datum flugNr ftypId flugNr,platzCode,datum ticketNr flugNr wochentage Schlüssel: {flugNr,ticketNr}, {flugNr,platzCode,datum} Frage 1 führt auf sog. Normalformen als Erfolgsmaßstab für Eliminieren von unerwünschten FDs und MVDs.

73 SS 2004B. König-Ries: Datenbanksysteme4-73 Erste Normalform Relationstyp R(A 1,...,A n ) und Menge von FDs und MVDs für R sei im Folgenden fest vorgegeben. R ist in erster Normalform (1NF), wenn die Domänen aller Attribute primitive Typen sind. FLUGINFO ist 1NF, da alle Attribute primitive Domänen haben. Gilt im relationalen Modell immer.

74 SS 2004B. König-Ries: Datenbanksysteme4-74 Zweite Normalform R ist in zweiter Normalform (2NF), wenn jedes Nichtschlüsselattribut von jedem Schlüssel voll funktional abhängt. (Nichtschlüsselattribute dürfen also nicht von Teilen eines Schlüssels abhängen.) FLUGINFO nicht in 2NF, da es Nichtschlüsselattribute gibt, die bereits allein von ticketNr oder flugNr abhängen. Zerlegung: FLUGANGABE (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung) TICKET (ticketNr, name) BUCHUNG (flugNr, ticketNr, platzCode, datum) Zweite Normalform ist insbesondere (aber nicht nur!) in den folgenden Fällen gegeben: Alle Schlüssel sind einelementig. Es gibt keine Nichtschlüsselattribute.

75 SS 2004B. König-Ries: Datenbanksysteme4-75 Dritte Normalform R ist in dritter Normalform (3NF), wenn für jede FD X A mit A Nichtschlüsselattribut gilt: X ist Superschlüssel. Dritte Normalform gilt nicht in FLUGANGABE, da Abhängigkeit von,nach Entfernung besteht und {von,nach} nicht Superschlüssel ist. Relation BUCHUNG ist in dritter Normalform, da alle Attribute Schlüsselattribute sind, TICKET weil ticketNr Superschlüssel ist. Zerlegung von FLUGANGABE: FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) FLUGSTRECKE (von, nach, entfernung)

76 SS 2004B. König-Ries: Datenbanksysteme4-76 Dritte Normalform Dritte Normalform ist also nicht gegeben, wenn ein Nichtschlüsselattribut von (einer Kombination von) Attributen abhängt, die Nichtschlüsselattribute einschließen. Dritte Normalform liegt insbesondere (aber nicht nur!) vor, wenn es keine Nichtschlüsselattribute oder keine FDs gibt.

77 SS 2004B. König-Ries: Datenbanksysteme4-77 Dritte Normalform: Zwischenergebnis FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) flugNr (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (von, nach, abflugszeit) flugNr FLUGSTRECKE (von, nach, entfernung) (von, nach) entfernung TICKET (ticketNr, name) ticketNr name BUCHUNG (flugNr, ticketNr, platzCode, datum) (flugNr, ticketNr) (platzCode, datum) (flugNr, platzCode, datum) ticketNr

78 SS 2004B. König-Ries: Datenbanksysteme4-78 Boyce-Codd-Normalform R ist in Boyce-Codd-Normalform (BCNF), wenn für jede FD X Y gilt: X ist Superschlüssel. In 3NF werden nur Abhängigkeiten betrachtet, bei denen auf der rechten Seite Nichtschlüsselattribute stehen. In 3NF sind auch FDs mit Schlüsselattributen auf der rechten Seite möglich. Boyce-Codd-Normalform gilt in allen vier Relationen. Ältere Definitionen bezogen sich nur auf den Primärschlüssel. Dann wäre BUCHUNG (flugNr, ticketNr, platzCode, datum) nicht in BCNF wegen (flugNr, platzCode, datum) ticketNr.

79 SS 2004B. König-Ries: Datenbanksysteme4-79 Vierte Normalform R ist in vierter Normalform (4NF), wenn für jede MVD X Y gilt: X ist Superschlüssel (und damit X Y). Vierte Normalform gilt in allen vier Relationen. Betrachte Relation mit Angaben, welche Passagiere wann welche Filme gesehen haben: ZUSCHAUER (Name, FlugNr, Datum, Filmtitel) und frühere MVD FlugNr,Datum Filmtitel Boyce-Codd-Normalform, da keine FDs vorliegen. Vierte Normalform gilt nicht, da (FlugNr,Datum) nicht Superschlüssel ist.

80 SS 2004B. König-Ries: Datenbanksysteme4-80 Vierte Normalform Präzise Formulierung: 4NF liegt genau dann vor, wenn für jede FD X Y und jede MVD X Y mindestens eine der folgenden Aussagen zutrifft: X Y. X Y = alle Attribute der betrachteten Relation. X ist Superschlüssel der betrachteten Relation.

81 SS 2004B. König-Ries: Datenbanksysteme4-81 Normalformen in der Übersicht 1NF 2NF 3NF BCNF 4NF Alle Relationen Nichtschlüsselattribute hängen voll funktional von jedem Schlüssel ab Nichtschlüsselattribute hängen funktional nur von Superschlüsseln ab Keine FDs außer Schlüsselabhängigkeiten Keine MVDs außer Schlüsselabhängigkeiten

82 SS 2004B. König-Ries: Datenbanksysteme4-82 Zerlegung und Konstruktion Frage 2: Welche Zerlegungen sind korrekt? Zerlegung ersetzt Relationstyp R(A 1,...,A n ) und Menge von assoziierten Abhängigkeiten durch mehrere einzelne Relationstypen R i (A i 1,...,A i j ) mit Abhängigkeiten i. Attributmengen der einzelnen R i können überlappen, Vereinigung muss {A 1,...,A n } ergeben. Statt Instanz r von R werden Projektionen r i : Attribute(R i ) (r) abgespeichert, r wird durch natürliche Verbindung r = r 1 r 2... r k konstruiert.

83 SS 2004B. König-Ries: Datenbanksysteme4-83 Korrektheit von Zerlegungen Durch Speicherung der Teilrelationen statt der unzerlegten Relation r darf Zustandsraum r nicht verändert werden. Korrektheitsforderung daher: Durch Zerlegung darf weder (1)die Speicherung konsistenter Zustände von r unmöglich (2)noch die Speicherung inkonsistenter Zustände in r möglich werden. r ist nur virtuell! Als konsistent gilt per Definition jeder Zustand von r! Zerlegungen, die (1) erfüllen, heißen verlustlos und Zerlegungen, die (2) erfüllen, konsistenzwahrend (oft auch abhängigkeitsbewahrend genannt).

84 SS 2004B. König-Ries: Datenbanksysteme4-84 Verlustlosigkeit Formale Definition: Sei R(A 1,...,A n ) Relationstyp, Menge von FDs und MVDs für R, r Instanz von R. Zerlegung {(R i (A i 1,...,A i j ), i ) | i = 1,...,k} von (R, ) in Teilrelationen R i mit assoziierten Abhängigkeiten i ist verlustlos, wenn für r gilt: Jede Projektion r i A i 1,...,A i j (r) erfüllt die Abhängigkeiten in i (1 i k). r r 1 r 2... r k.

85 SS 2004B. König-Ries: Datenbanksysteme4-85 Abhängigkeitsbewahrung Formale Definition: Sei R(A 1,...,A n ) Relationstyp, Menge von FDs und MVDs für R, r Instanz von R. Zerlegung {(R i (A i 1,...,A i j ), i ) | i = 1,...,k} von (R, ) in Teilrelationen R i mit assoziierten Abhängigkeiten i ist abhängigkeitsbewahrend, wenn gilt: Sind für 1 i k Instanzen r i von R i (A i 1,...,A i j ) gegeben, die jeweils i erfüllen, dann muss r 1 r 2... r k die Bedingungen in erfüllen. r r 1 r 2... r k.

86 SS 2004B. König-Ries: Datenbanksysteme4-86 Korrekte Zerlegung: Beispiel FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (von, nach) entfernung ticketNr name (flugNr, ticketNr) (platzCode, datum) (flugNr, platzCode, datum) ticketNr FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) flugNr (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) FLUGSTRECKE (von, nach, entfernung) (von, nach) entfernung TICKET (ticketNr, name) ticketNr name BUCHUNG (flugNr, ticketNr, platzCode, datum) (flugNr, ticketNr) (platzCode, datum) (flugNr, platzCode, datum) ticketNr abhängigkeitsbewahrend! verlustlos?

87 SS 2004B. König-Ries: Datenbanksysteme4-87 Inkorrekte Zerlegung: Beispiel Weitere Zerlegung von FLUG in Teilrelationen FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) in FLUGTAGE (flugNr, von, nach, ftypId, wochentage) STRECKENZEITEN (von, nach, abflugszeit, ankunftszeit) nicht abhängigkeitsbewahrend (flugNr (abflugszeit,ankunftszeit) geht verloren); Folge: Gibt es zwei Flüge auf derselben Strecke mit unterschiedlichen Zeiten, so entsteht kartesisches Produkt.

88 SS 2004B. König-Ries: Datenbanksysteme4-88 Gewinnung von Zerlegungen Erreichter Kenntnisstand: Welche Zerlegungen sind gut? Höhere Normalformen. Welche Zerlegungen sind korrekt? Verlustlose und abhängigkeitsbewahrende Zerlegungen. Frage 3: Wie findet man gute und korrekte Zerlegungen? Zerlegungsalgorithmen, im Folgenden zu betrachten.

89 SS 2004B. König-Ries: Datenbanksysteme4-89 Grundsätzliche Resultate Theorem: Für jeden Relationstyp R(A 1,...,A n ) und jede Menge von FDs über {A 1,...,A n } gibt es: eine verlustlose (aber nicht notwendig abhängigkeitsbewahrende) Zerlegung in eine Menge von Relationstypen in BCNF, eine verlustlose und abhängigkeitsbewahrende Zerlegung in eine Menge von Relationstypen in 3. Normalform, polynomiale Algorithmen, die diese Zerlegungen finden. Wenn auch MVDs enthält, lässt sich eine verlustlose Zerlegung in Relationstypen in 4. Normalform finden.

90 SS 2004B. König-Ries: Datenbanksysteme4-90 Algorithmus zur Zerlegung in 3NF (1) In der Praxis zerlegt man normalerweise in 3. Normalform. Man kann zeigen, dass Bedingung r = Attribute(R 1 ) (r)... Attribute(R k ) (r) gilt für alle Instanzen r von R, die Abhängigkeiten in erfüllen, genau dann erfüllt ist, wenn die für die Verbindung maßgeblichen (d.h. abzugleichenden) Attribute jeder Teilrelation R i einen Schlüssel von R i gemäß i darstellen.

91 SS 2004B. König-Ries: Datenbanksysteme4-91 Algorithmus zur Zerlegung in 3NF (2) // Eingabe: Relationstyp R und Menge von FDs // c sei kanonische Überdeckung von, // in der FDs absteigend nach Anzahl der Attribute sortiert sind (wichtig) // Idee: bilde separaten Relationstyp R i (X,Y) für jede FD X Y in c, // sofern X Y nicht bereits durch anderen Relationstyp R j abgedeckt ist i := 0 for each (X Y) c do if j: 1 j i (X Y) Attribute(R j ) then begin j := j {X Y} end else begin i := i +1; R i := (X Y); i := {X Y} end end if end for // Relationstyp für Schlüssel von R bilden, falls noch nicht abgedeckt if 1 j i: Attribute(R j ) sind nicht Superschlüssel von R then begin i := i +1; R i := irgendein Schlüssel von R; i := end end if

92 SS 2004B. König-Ries: Datenbanksysteme4-92 Algorithmus zur Zerlegung in 3NF (3) Gewonnene Zerlegung ist i.A. nicht eindeutig, da Wahlfreiheit bzgl. Bildung und Sortierung der kanonischen Überdeckung und Auswahl des Schlüssels im Abschlussschritt besteht.

93 SS 2004B. König-Ries: Datenbanksysteme4-93 3NF-Zerlegung von FLUGINFO FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr) (platzCode, datum) (flugNr, platzCode, datum) ticketNr (von, nach) entfernung ticketNr name FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr) (platzCode, datum) (flugNr, platzCode, datum) ticketNr (von, nach) entfernung ticketNr name FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr) (platzCode, datum) (flugNr, platzCode, datum) ticketNr (von, nach) entfernung ticketNr name FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) BUCHUNG (flugNr, ticketNr, platzCode, datum) FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr) (platzCode, datum) (flugNr, platzCode, datum) ticketNr (von, nach) entfernung ticketNr name FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) BUCHUNG (flugNr, ticketNr, platzCode, datum) FLUGSTRECKE (von, nach, entfernung) FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr (von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) (flugNr, ticketNr) (platzCode, datum) (flugNr, platzCode, datum) ticketNr (von, nach) entfernung ticketNr name FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) BUCHUNG (flugNr, ticketNr, platzCode, datum) FLUGSTRECKE (von, nach, entfernung) TICKET (ticketNr, name)

94 SS 2004B. König-Ries: Datenbanksysteme4-94 4NF-Zerlegung Vorgestellter Zerlegungsalgorithmus berücksichtigt nur FDs, da bei MVDs i.A. keine abhängigkeitsbewahrende Zerlegung in 4. Normalform möglich ist. Verlustlose Zerlegung eines Relationstyps R, der nicht in 4. Normalform ist, ist jedoch leicht möglich: Sei X Y MVD, in der X nicht Superschlüssel ist. Setze Z := {A 1,...,A n } \ (X Y). Dann gilt XZ {A 1,...,A n } XY. Zerlege R in Relationstypen R 1 (X,Y) und R 2 (X,Z). MVD X Y besagt gerade, dass jede Instanz von R sich durch natürliche Verbindung ihrer Projektionen auf XY bzw. XZ rekonstruieren lässt, Zerlegung also verlustlos ist. Anschließend ggf. weitere Zerlegung der Teilrelationen.

95 SS 2004B. König-Ries: Datenbanksysteme4-95 Inklusionsabhängigkeiten Zerlegung gibt i.A. Anlass zu Fremdschlüsselbedingungen, z.B. Fremdschlüssel {flugNr} und {ticketNr} in BUCHUNG. Allgemeine Form solcher Bedingungen sind sogenannte Inklusionsabhängigkeiten (kurz: IDs): Sind R 1, R 2 Relationstypen und X Attribute(R 1 ), Y Attribute(R 2 ) Listen von Attributen mit kompatiblen Domänen, so ist ID Ausdruck der Form R 1.X R 2.Y. Instanzen r 1, r 2 von R 1, R 2 erfüllen R 1.X R 2.Y, wenn X (r 1 ) Y (r 2 ).


Herunterladen ppt "SS 2004B. König-Ries: Datenbanksysteme4-1 Kapitel 4: Datenbankentwurf Einführung UML Modellierung Schematransformation Normalisierung."

Ähnliche Präsentationen


Google-Anzeigen