Kapitel 4: Datenbankentwurf

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

Einordnung (1) Datenmodell DB-Schema Datenbasis
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 DB-Entwurf DB-Betrieb Grundsätzliche Organisation des DBMS Organisation der DB für eine bestimmte Miniwelt Beschreibung eines bestimmten Zustands der Miniwelt SS 2004 B. König-Ries: Datenbanksysteme

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

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. SS 2004 B. König-Ries: Datenbanksysteme

B. König-Ries: Datenbanksysteme
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 A B C D ? Miniwelt Semantische Lücke SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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

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

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) Beschränkung auf die für den Datenbankentwurf bedeutsamen Konstrukte SS 2004 B. König-Ries: Datenbanksysteme

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) Struktur- diagramm Interaktions- diagramme (interaction diagrams) Verhaltens- diagramme (behavior diagrams) Implementierungs- diagramme (implementation diagrams) SS 2004 B. König-Ries: Datenbanksysteme

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) SS 2004 B. König-Ries: Datenbanksysteme

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} SS 2004 B. König-Ries: Datenbanksysteme

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. Internetkunde Kunde Reisebürokunde SS 2004 B. König-Ries: Datenbanksysteme

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: Flug Flugzeugtyp SS 2004 B. König-Ries: Datenbanksysteme

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: WirdGeflogenMit Flug Flugzeugtyp Gibt SitzeinteilugVorFür SS 2004 B. König-Ries: Datenbanksysteme

Bei drei- und mehrstelligen Assoziationen entfällt Leserichtung. Assoziationen können als eigene Assoziationsklasse ausgebildet und mit Attributen versehen werden: platzCode: string datum: date Buchung Kunde Ticket Flug SS 2004 B. König-Ries: Datenbanksysteme

Assoziationen belassen viel Spielraum für die Modellierung. Gleiche Sachverhalte können unterschiedlich modelliert werden: TicketNr: string platzCode: string datum: date Kunde Flug Bucht SS 2004 B. König-Ries: Datenbanksysteme

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. WirdGeflogenMit Flug 1.. 1 Flugzeugtyp Gibt SitzeinteilungVorFür SS 2004 B. König-Ries: Datenbanksysteme

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. Flugbewegung, wenn Datum zur Differenzierung mit einbezogen werden könnte. In UML nicht vorgesehen! platzCode: string datum: date Buchung Kunde 1 0..1 Ticket Mit Multiplizitäten lassen sich also Unstimmigkeiten bei der Modellierung aufdecken! Multiplizität gilt für Flug als Flugbewegung, nicht als Flugplanung! 1..5 Flug SS 2004 B. König-Ries: Datenbanksysteme

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! platzCode: string datum: date Buchung Kunde 1 0..1 Ticket 1..5 Flug SS 2004 B. König-Ries: Datenbanksysteme

Rolle: Sichtweise eines Objektes durch das gegenüberliegende Objekt. Besonders bei reflexiven Assoziationen interessant. 0.. Abgehend Flug 1 Ankommend Anschlussflug SS 2004 B. König-Ries: Datenbanksysteme

Gerichtete Assoziation: Assoziation, die nur in einer Richtung traversiert werden soll. (Als Optimierungshinweis für Implementierung aufzufassen.) Notation durch offene Pfeilspitze: 0.. Abgehend Flug 1 Ankommend Anschlussflug SS 2004 B. König-Ries: Datenbanksysteme

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 . 1..5 1..20 Flughafen Terminal Flugsteig SS 2004 B. König-Ries: Datenbanksysteme

UML-Klassendiagramm: Beispiel
Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone 1 1 Ankunftszeit nach von Abflugszeit Flugzeugtyp 1.. 1.. FtypId {eindeutig} Name First Business Economy Flug Gibt SitzeinteilungVorFür FlugNr {eindeutig} Wochentage Entfernung 1 1.. WirdGeflogenMit 1..5 Kunde 1 0..1 Ticket Name {eindeutig} Telefon TicketNr {eindeutig} Buchung PlatzCode Datum {k1,k2  Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket  k1=k2} SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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

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 Ci, dort mit Multiplizität 1. Bilde CA auf separate Relation RA ab (Assoziationsrelation). Attribute von RA sind die Schlüsselattribute jeder Objektrelation RCi 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 RCi-Tupel als Fremdschlüssel. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

Eindeutigkeits-Zusicherungen berücksichtigt, Multiplizitäten zum Teil verloren gegangen. Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone 1 1 Ankunftszeit nach von Abflugszeit Flugzeugtyp 1.. 1.. FtypId {eindeutig} Name First Business Economy Flug Gibt SitzeinteilungVorFür FlugNr {eindeutig} Wochentage Entfernung 1 1.. WirdGeflogenMIt 1..5 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) Kunde 1 0..1 Ticket Name {eindeutig} Telefon TicketNr {eindeutig} Buchung PlatzCode Datum {k1,k2  Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket  k1=k2} SS 2004 B. König-Ries: Datenbanksysteme

Flughafen FlughCode {eindeutig} Stadt Land Name Zeitzone 1 1 Ankunftszeit nach von Abflugszeit Flugzeugtyp 1.. 1.. FtypId {eindeutig} Name First Business Economy Flug Gibt SitzeinteilungVorFür FlugNr {eindeutig} Wochentage Entfernung 1 1.. WirdGeflogenMIt 0..5 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) Kunde 1 0..1 Ticket Name {eindeutig} Telefon TicketNr {eindeutig} Buchung PlatzCode Datum {k1,k2  Kunde: k1.Buchung.Ticket= k2.Buchung.Ticket  k1=k2} SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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

Beispielszenario (2) flugNr von nach ftyp wochent ab an entf ticketNr platz datum name LH458 MUC SFO MDMDFSS K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO MDMDFSS A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC MDMDFSS K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 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 D-D-S E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG D-D-S G 12-AUG-00 Bender_Mr_P LH500 FRA GIG D-D-S C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 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 MDMDFSS A 06-AUG-00 Weinand_Mr_C LH6390 SIN SYD MDMDFSS G 09-SEP-00 Pulkowski_Mr_S LH6391 SYD SIN 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 D--FSS A 04-AUG-00 Nagi_Mr_K LH677 ALY FRA M-M--SS F 23-AUG-00 Nagi_Mr_K LH710 FRA NRT MDMDFSS D 10-SEP-00 Witte_Mr_R LH710 FRA NRT MDMDFSS K 11-AUG-00 Gimbel_Mr_M LH711 NRT FRA MDMDFSS B 26-AUG-00 Gimbel_Mr_M LH778 FRA SIN MDMDFSS K 05-AUG-00 Weinand_Mr_C LH778 FRA SIN MDMDFSS K 08-SEP-00 Pulkowski_Mr_S LH779 SIN FRA MDMDFSS B 20-OCT-00 Pulkowski_Mr_S ... SS 2004 B. König-Ries: Datenbanksysteme

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!). SS 2004 B. König-Ries: Datenbanksysteme

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

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. SS 2004 B. König-Ries: Datenbanksysteme

Funktionale Abhängigkeiten: Beispiele
FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) soll folgende FDs erfüllen: flugNr  von von,nach  entfernung flugNr  nach ticketNr  name flugNr  abflugszeit flugNr,ticketNr  platzCode flugNr  ankunftszeit flugNr,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 SS 2004 B. König-Ries: Datenbanksysteme

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. Sonderfälle: Z=W: XW  YW Z=: XW  Y SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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! SS 2004 B. König-Ries: Datenbanksysteme

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 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 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 SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

Voll funktionale Abhängigkeiten: Beispiel
Alle für FLUGINFO ursprünglich postulierten FDs sind voll funktional bezüglich ihrer Gesamtmenge: flugNr  von von,nach  entfernung flugNr  nach ticketNr  name flugNr  abflugszeit flugNr,ticketNr  platzCode flugNr  ankunftszeit flugNr,ticketNr  datum flugNr  ftypId flugNr,platzCode,datum  ticketNr flugNr  wochentage SS 2004 B. König-Ries: Datenbanksysteme

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 SS 2004 B. König-Ries: Datenbanksysteme

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  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  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  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  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  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, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum} {flugNr, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, {flugNr, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, {flugNr, ticketNr}+ = {flugNr, ticketNr, {flugNr, ticketNr}+ = {flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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

Mehrwertige Abhängigkeiten
Formale Definition: Sei R(A1,A2, ... ,An) Relationstyp mit Attributen A1, A2, ... ,An. Eine mehrwertige Abhängigkeitsbedingung (kurz: MVD) ist ein Ausdruck X  Y mit X, Y  {A1, A2, ... ,An}. Sei Z = R\(XY). Eine Instanz r von R erfüllt die Bedingung X  Y, wenn X  2Y Funktion: Sind t1, t2 Tupel in r mit t1[X] = t2[X], so existiert Tupel t3 mit t3[X]=t1[X], t3[Y]=t1[Y], t3[Z]=t2[Z] (und aus Symmetriegründen Tupel t4 mit t4[X]=t1[X], t4[Y]=t2[Y], t4[Z]=t1[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. SS 2004 B. König-Ries: Datenbanksysteme

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 SS 2004 B. König-Ries: Datenbanksysteme

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 SS 2004 B. König-Ries: Datenbanksysteme

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). SS 2004 B. König-Ries: Datenbanksysteme

Axiome für mehrwertige Abhängigkeiten
Für MVDs gelten erweiterte Armstrong-Axiome: Sei R Relationstyp mit Attributmenge U := {A1, A2, ... ,An} und X, Y, Z beliebige Teilmengen von {A1, A2, ... ,An}. 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. SS 2004 B. König-Ries: Datenbanksysteme

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

Systematisches Finden eines Schlüssels
Sei Relationstyp R mit Attributen A1, A2, ... ,An und Menge  von FDs für R gegeben. Algorithmus zur Bestimmung eines Superschlüssels S für R bzgl. : S :=  while S+  {A1,...,An} do choose Ai  {A1,...,An} \ S+ S := S  {Ai} 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. SS 2004 B. König-Ries: Datenbanksysteme

Finden eines Schlüssels: Beispiel
FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) flugNr  von von,nach  entfernung flugNr  nach ticketNr  name flugNr  abflugszeit flugNr,ticketNr  platzCode flugNr  ankunftszeit flugNr,ticketNr  datum flugNr  ftypId flugNr,platzCode,datum  ticketNr flugNr  wochentage Iteration S S+ Ai 1 {} {} {flugNr} 2 {flugNr} {flugNr,von,nach,abflugszeit,ankunftszeit, {ticketNr} ftypdId,wochentage,entfernung} 3 {flugNr, ticketNr} -- alle Attribute -- SS 2004 B. König-Ries: Datenbanksysteme

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

Anomalien MVD X  Y für Relationstyp R(A1, ... ,An) besagt, dass jede Instanz r natürliche Verbindung semantisch unabhängiger Teilrelationen rXY := XY(r) und rXZ := XZ(r) ist: r = XY(r) ⋈ XZ(r) mit Z = {A1, ... ,An} \ (XY), XZ  {A1, ... ,An}  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. SS 2004 B. König-Ries: Datenbanksysteme

Einfüge-Anomalien Es werde MVD XY und assoziierte Gleichung r = XY(r) ⋈ XZ(r) mit YX und Z = {A1, ... ,An} \ (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. SS 2004 B. König-Ries: Datenbanksysteme

Änderungs-Anomalien Es werde MVD XY und assoziierte Gleichung r = XY(r) ⋈ XZ(r) mit YX und Z = {A1, ... ,An} \ (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. SS 2004 B. König-Ries: Datenbanksysteme

Lösch-Anomalien Es werde MVD XY und assoziierte Gleichung r = XY(r) ⋈ XZ(r) mit YX und Z = {A1, ... ,An} \ (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. SS 2004 B. König-Ries: Datenbanksysteme

Ziel der 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. SS 2004 B. König-Ries: Datenbanksysteme

Schlüssel- und Nichtschlüsselattribute
Definition (technisch, für Normalformenlehre): Sei R(A1,...,An) Relationstyp und  Menge von FDs für R. Ein Attribut Ai heißt Schlüsselattribut von R bzgl. , wenn es einen Schlüsselkandidat S von R bzgl.  mit Ai  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. SS 2004 B. König-Ries: Datenbanksysteme

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? SS 2004 B. König-Ries: Datenbanksysteme

Normalformen FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name) FDs: flugNr  von von,nach  entfernung flugNr  nach ticketNr  name flugNr  abflugszeit flugNr,ticketNr  platzCode flugNr  ankunftszeit flugNr,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. SS 2004 B. König-Ries: Datenbanksysteme

Erste Normalform Relationstyp R(A1,...,An) 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. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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) SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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 SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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

Zerlegung und Konstruktion
Frage 2: Welche Zerlegungen sind korrekt? Zerlegung ersetzt Relationstyp R(A1,...,An) und Menge  von assoziierten Abhängigkeiten durch mehrere einzelne Relationstypen Ri(Ai1,...,Aij) mit Abhängigkeiten i. Attributmengen der einzelnen Ri können überlappen, Vereinigung muss {A1,...,An} ergeben. Statt Instanz r von R werden Projektionen ri : Attribute(Ri) (r) abgespeichert, r wird durch natürliche Verbindung r = r1 ⋈ r2 ⋈ ... ⋈ rk konstruiert. SS 2004 B. König-Ries: Datenbanksysteme

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). SS 2004 B. König-Ries: Datenbanksysteme

Verlustlosigkeit Formale Definition: Sei R(A1,...,An) Relationstyp,  Menge von FDs und MVDs für R, r Instanz von R. Zerlegung {(Ri(Ai1,...,Aij), i) | i = 1,...,k} von (R,) in Teilrelationen Ri mit assoziierten Abhängigkeiten i ist verlustlos, wenn für r gilt: Jede Projektion ri  Ai1,...,Aij (r) erfüllt die Abhängigkeiten in i (1ik). r  r1 ⋈ r2 ⋈ ... ⋈ rk. SS 2004 B. König-Ries: Datenbanksysteme

Abhängigkeitsbewahrung
Formale Definition: Sei R(A1,...,An) Relationstyp,  Menge von FDs und MVDs für R, r Instanz von R. Zerlegung {(Ri(Ai1,...,Aij), i) | i = 1,...,k} von (R,) in Teilrelationen Ri mit assoziierten Abhängigkeiten i ist abhängigkeitsbewahrend, wenn gilt: Sind für 1  i  k Instanzen ri von Ri(Ai1,...,Aij) gegeben, die jeweils i erfüllen, dann muss r1 ⋈ r2 ⋈ ... ⋈ rk die Bedingungen in  erfüllen. r  r1 ⋈ r2 ⋈ ... ⋈ rk. SS 2004 B. König-Ries: Datenbanksysteme

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 abhängigkeitsbewahrend! 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 verlustlos? SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

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. SS 2004 B. König-Ries: Datenbanksysteme

Grundsätzliche Resultate
Theorem: Für jeden Relationstyp R(A1,...,An) und jede Menge  von FDs über {A1,...,An} 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. SS 2004 B. König-Ries: Datenbanksysteme

Algorithmus zur Zerlegung in 3NF (1)
In der Praxis zerlegt man normalerweise in 3. Normalform. Man kann zeigen, dass Bedingung r = Attribute(R1) (r) ⋈ ... ⋈ Attribute(Rk) (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 Ri einen Schlüssel von Ri gemäß i darstellen. SS 2004 B. König-Ries: Datenbanksysteme

// 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 Ri(X,Y) für jede FD X  Y in c, // sofern X  Y nicht bereits durch anderen Relationstyp Rj abgedeckt ist i := 0 for each (X  Y)  c do if j: 1  j  i  (X  Y)  Attribute(Rj) then begin j := j  {X  Y} end else begin i := i +1; Ri := (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(Rj) sind nicht Superschlüssel von R then begin i := i +1; Ri := irgendein Schlüssel von R; i :=  end end if SS 2004 B. König-Ries: Datenbanksysteme

Gewonnene Zerlegung ist i.A. nicht eindeutig, da Wahlfreiheit bzgl. Bildung und Sortierung der kanonischen Überdeckung und Auswahl des Schlüssels im Abschlussschritt besteht. SS 2004 B. König-Ries: Datenbanksysteme

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 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) 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 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) SS 2004 B. König-Ries: Datenbanksysteme

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 := {A1,...,An} \ (XY). Dann gilt XZ  {A1,...,An}  XY. Zerlege R in Relationstypen R1(X,Y) und R2(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. SS 2004 B. König-Ries: Datenbanksysteme

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 R1, R2 Relationstypen und X  Attribute(R1), Y  Attribute(R2) Listen von Attributen mit kompatiblen Domänen, so ist ID Ausdruck der Form R1.X  R2.Y. Instanzen r1, r2 von R1, R2 erfüllen R1.X  R2.Y, wenn X(r1)  Y(r2). SS 2004 B. König-Ries: Datenbanksysteme

Kapitel 4: Datenbankentwurf

Ähnliche Präsentationen

Präsentation zum Thema: "Kapitel 4: Datenbankentwurf"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Kapitel 4: Datenbankentwurf

Ähnliche Präsentationen

Präsentation zum Thema: "Kapitel 4: Datenbankentwurf"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback