SS 2004 B. König-Ries: Datenbanksysteme 4-1
Kapitel 4: Datenbankentwurf
Einführung
UML Modellierung
Schematransformation
Normalisierung
SS 2004 B. König-Ries: Datenbanksysteme 4-2
Kapitel 4: Datenbankentwurf
Einführung
UML Modellierung
Schematransformation
Normalisierung
SS 2004 B. König-Ries: Datenbanksysteme 4-3
Einordnung (1)
ElementareZustandsräume
Konstruktoren fürZustandsräume
Operatoren
Datenmodell
KonkreterZustandsraum
Konkrete Konsistenz-bedingungen
DB-Schema
Konkrete Zustände(schemaverträglich )
Transaktionsproze-duren
Datenbasis
GrundsätzlicheOrganisation des
DBMS
Organisation der DBfür eine bestimmte
Miniwelt
Beschreibung einesbestimmten Zustands
der Miniwelt
DB-Entwurf DB-Betrieb
SS 2004 B. König-Ries: Datenbanksysteme 4-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
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-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
A B C A B A B C D
?
Miniwelt
SemantischeLücke
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-8
Lösung (2)
Anforderungen an Semantisches Datenmodell: Ausdrucksmächtigkeit Aspekt-Vielfalt Klare Semantik Standardisierung Werkzeugunterstützung
Logisches Schema
A B C A B A B C D
Miniwelt
Konzeptuelles(semantisches)Schema
vonnach
1 1
1..
0..5
Strecke
Entfernung
1..
Flughafen
FlughCode {eindeutig}StadtLandName
Zeitzone
1..
1..
0..
1
Flugzeugtyp
FtypId {eindeutig}NameFirst
BusinessEconomy
Flug
FlugNr {eindeutig}Wochentage
Kunde
Name {eindeutig}Telefon
Passagier
TicketNr {eindeutig}
WirdGeflogenMIt
Gibt SitzeinteilungVorFür
Bedient
AbflugszeitAnkunftszeit
PlatzCodeDatum
1..
Buchung0..1
{Strecke.von Flug.Bedient.von}
1
1..
hatBuchung
SemantischesDatenmodell
LogischesDatenmodell
SS 2004 B. König-Ries: Datenbanksysteme 4-9
Lösung (3)
Logisches Schema
A B C A B A B C D
Miniwelt
Konzeptuelles(semantisches)Schema
vonnach
1 1
1..
0..5
Strecke
Entfernung
1..
Flughafen
FlughCode {eindeutig}StadtLandName
Zeitzone
1..
1..
0..
1
Flugzeugtyp
FtypId {eindeutig}NameFirst
BusinessEconomy
Flug
FlugNr {eindeutig}Wochentage
Kunde
Name {eindeutig}Telefon
Passagier
TicketNr {eindeutig}
WirdGeflogenMIt
Gibt SitzeinteilungVorFür
Bedient
AbflugszeitAnkunftszeit
PlatzCodeDatum
1..
Buchung0..1
{Strecke.von Flug.Bedient.von}
1
1..
hatBuchung
SemantischesDatenmodell
LogischesDatenmodell
RelationalesDatenmodell
UML(intuitiv)
Erweitert relational(formal)
makroskopischeBetrachtung
mikroskopischeBetrachtung
Überarbeitung
Schematransformation
SS 2004 B. König-Ries: Datenbanksysteme 4-10
Kapitel 4: Datenbankentwurf
Einführung
UML Modellierung
Schematransformation
Normalisierung
SS 2004 B. König-Ries: Datenbanksysteme 4-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)
SS 2004 B. König-Ries: Datenbanksysteme 4-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(interactiondiagrams)
Verhaltens-diagramme(behaviordiagrams)
Struktur-diagramm
SS 2004 B. König-Ries: Datenbanksysteme 4-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:
KundeName: stringTelNr: string
buchen (FlugNr: string, Datum: date)stornieren (FlugNr: string, Datum: date)
SS 2004 B. König-Ries: Datenbanksysteme 4-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}
SS 2004 B. König-Ries: Datenbanksysteme 4-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
SS 2004 B. König-Ries: Datenbanksysteme 4-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:
Flug Flugzeugtyp
SS 2004 B. König-Ries: Datenbanksysteme 4-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:
Flug FlugzeugtypWirdGeflogenMit
Gibt SitzeinteilugVorFür
SS 2004 B. König-Ries: Datenbanksysteme 4-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:
Kunde Ticket
Flug
platzCode: stringdatum: date
Buchung
SS 2004 B. König-Ries: Datenbanksysteme 4-19
UML-Klassendiagramm: Assoziationen (4)
Assoziationen belassen viel Spielraum für die Modellierung. Gleiche Sachverhalte können unterschiedlich modelliert werden:
Kunde Flug
TicketNr: stringplatzCode: stringdatum: date
Bucht
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
1.. 1Flug Flugzeugtyp
WirdGeflogenMit
Gibt SitzeinteilungVorFür
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
1 0..1
1..5
Kunde Ticket
Flug
platzCode: stringdatum: 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!
SS 2004 B. König-Ries: Datenbanksysteme 4-22
UML-Klassendiagramm: Assoziationen (7)
Anbindung von Zusicherungen an Assoziationen:
{k1,k2Kunde:k1.Buchung.TicketNr = k2.Buchung.TicketNr
k1=k2}
Alternativ: Das selbe Ticket gehört unabhängig vom
Flug zu genau 1 Kunden!
1 0..1
1..5
Kunde Ticket
Flug
platzCode: stringdatum: date
Buchung
SS 2004 B. König-Ries: Datenbanksysteme 4-23
UML-Klassendiagramm: Assoziationen (8)
Rolle: Sichtweise eines Objektes durch das gegenüberliegende Objekt.
Besonders bei reflexiven Assoziationen interessant.
Flug
Anschlussflug
Ankommend
0..
1
Abgehend
SS 2004 B. König-Ries: Datenbanksysteme 4-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
0..
1
Abgehend
SS 2004 B. König-Ries: Datenbanksysteme 4-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 .
Flughafen Terminal Flugsteig1..5 1..20
SS 2004 B. König-Ries: Datenbanksysteme 4-26
vonnach
1 1
1..
1..5
1..
1..1WirdGeflogenMit
Gibt SitzeinteilungVorFür
0..11
AbflugszeitAnkunftszeit
PlatzCodeDatum
Buchung
Flugzeugtyp
FtypId {eindeutig}NameFirst
BusinessEconomy
Flug
FlugNr {eindeutig}WochentageEntfernung
Ticket
TicketNr {eindeutig}
Kunde
Name {eindeutig}Telefon
Flughafen
FlughCode {eindeutig}StadtLandName
Zeitzone
{k1,k2 Kunde:k1.Buchung.Ticket= k2.Buchung.Ticket k1=k2}
UML-Klassendiagramm: Beispiel
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-28
Kapitel 4: Datenbankentwurf
Einführung
UML Modellierung
Schematransformation
Normalisierung
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-30
Abbildung UML-Schema Rel. Schema (2)
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 4-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 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 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-33
vonnach
1 1
1..
1..5
1..
1..1WirdGeflogenMIt
Gibt SitzeinteilungVorFür
0..11
AbflugszeitAnkunftszeit
PlatzCodeDatum
Buchung
Flugzeugtyp
FtypId {eindeutig}NameFirst
BusinessEconomy
Flug
FlugNr {eindeutig}WochentageEntfernung
Ticket
TicketNr {eindeutig}
Kunde
Name {eindeutig}Telefon
Flughafen
FlughCode {eindeutig}StadtLandName
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)
SS 2004 B. König-Ries: Datenbanksysteme 4-34
vonnach
1 1
1..
0..5
1..
1..1WirdGeflogenMIt
Gibt SitzeinteilungVorFür
0..11
AbflugszeitAnkunftszeit
PlatzCodeDatum
Buchung
Flugzeugtyp
FtypId {eindeutig}NameFirst
BusinessEconomy
Flug
FlugNr {eindeutig}WochentageEntfernung
Ticket
TicketNr {eindeutig}
Kunde
Name {eindeutig}Telefon
Flughafen
FlughCode {eindeutig}StadtLandName
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)
SS 2004 B. König-Ries: Datenbanksysteme 4-35
Kapitel 4: Datenbankentwurf
Einführung
UML Modellierung
Schematransformation
Normalisierung
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-38
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 4-39
Beispielszenario (2)flugNr von nach ftyp wochent ab an entf ticketNr platz datum name ----------------------------------------------------------------------------------------...LH458 MUC SFO 744 MDMDFSS 1220 1445 9130 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 MDMDFSS 1220 1445 9130 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 MDMDFSS 1355 0990 9130 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 MDMDFSS 1355 0990 9130 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 MDMDFSS 1330 1410 654 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 MDMDFSS 1330 1410 654 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 -D-D-S- 2235 0530 9585 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 -D-D-S- 2235 0530 9585 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 -D-D-S- 2235 0530 9585 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 -D-D-S- 2235 0530 9585 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH501 GIG FRA 340 --M-F-S 1325 0550 9585 7216087337 02K 22-SEP-00 Nimis_Mr_J LH6390 SIN SYD 744 MDMDFSS 2015 0550 6298 7216083911 82A 06-AUG-00 Weinand_Mr_C LH6390 SIN SYD 744 MDMDFSS 2015 0550 6298 7216084065 24G 09-SEP-00 Pulkowski_Mr_S LH6391 SYD SIN 744 MDMDFSS 1550 2150 6298 7216084065 54J 20-OCT-00 Pulkowski_Mr_S LH6488 SFO HNL D10 MDMDFSS 1745 2204 3853 7216084066 03A 01-SEP-00 Schmitt_Mrs_B LH6489 HNL SFO D10 MDMDFSS 2125 0520 3853 7216084066 02A 22-SEP-00 Schmitt_Mrs_B LH676 FRA ALY 319 -D--FSS 1330 1825 2741 7216087336 12A 04-AUG-00 Nagi_Mr_K LH677 ALY FRA 319 M-M--SS 0745 1100 2741 7216087336 15F 23-AUG-00 Nagi_Mr_K LH710 FRA NRT 744 MDMDFSS 1350 0745 9360 7216082757 34D 10-SEP-00 Witte_Mr_R LH710 FRA NRT 744 MDMDFSS 1350 0745 9360 7216083495 01K 11-AUG-00 Gimbel_Mr_M LH711 NRT FRA 744 MDMDFSS 1010 1450 9360 7216083495 02B 26-AUG-00 Gimbel_Mr_M LH778 FRA SIN 744 MDMDFSS 2215 1605 10264 7216083911 83K 05-AUG-00 Weinand_Mr_C LH778 FRA SIN 744 MDMDFSS 2215 1605 10264 7216084065 33K 08-SEP-00 Pulkowski_Mr_S LH779 SIN FRA 744 MDMDFSS 2305 0545 10264 7216084065 56B 20-OCT-00 Pulkowski_Mr_S ...
SS 2004 B. König-Ries: Datenbanksysteme 4-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!).
SS 2004 B. König-Ries: Datenbanksysteme 4-41
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\(XY). 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 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-43
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 entfernungflugNr nach ticketNr name flugNr abflugszeit flugNr,ticketNr platzCodeflugNr ankunftszeit flugNr,ticketNr datumflugNr ftypId flugNr,platzCode,datum ticketNrflugNr 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 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-45
Armstrong-Axiome: Beispiele
Reflexivität: Es gilt stets von,nachvon.
Expansivität: Aus flugNrnach folgt flugNr,vonnach.
Transitivität: Aus flugNr,platzCode,datumticketNr und ticketNrname folgt
flugNr,platzCode,datumname. Vereinigung:
Aus flugNrvon und flugNrnach folgt flugNrvon, nach.
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-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 XYZ XY XZ 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 XY XZ XYZ zusammen.
SS 2004 B. König-Ries: Datenbanksysteme 4-48
Kanonische Überdeckung: Beispiel
flugNr vonflugNr nachflugNr abflugszeitflugNr ankunftszeitflugNr ftypIdflugNr wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
Erste drei Schritte entfallen!
SS 2004 B. König-Ries: Datenbanksysteme 4-49
flugNr vonflugNr nachflugNr abflugszeitflugNr ankunftszeitflugNr ftypIdflugNr wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
Kanonische Überdeckung: Beispiel
flugNr von, nach, abflugszeit, ankunftszeit, wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
flugNr von, nach, abflugszeit, ankunftszeit, wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
flugNr von, nach, abflugszeit, ankunftszeit, wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCode, datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
flugNr von, nach, abflugszeit, ankunftszeit, wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCode, datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-51
Voll funktionale Abhängigkeiten: Beispiel
Alle für FLUGINFO ursprünglich postulierten FDs sind voll funktional bezüglich ihrer Gesamtmenge:flugNr von von,nach entfernungflugNr nach ticketNr name flugNr abflugszeit flugNr,ticketNr platzCodeflugNr ankunftszeit flugNr,ticketNr datumflugNr ftypId flugNr,platzCode,datum ticketNrflugNr wochentage
SS 2004 B. König-Ries: Datenbanksysteme 4-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
SS 2004 B. König-Ries: Datenbanksysteme 4-53
Hülle einer Attributmenge: Beispiel
flugNr vonflugNr nachflugNr abflugszeitflugNr ankunftszeitflugNr ftypIdflugNr wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
{flugNr, ticketNr}+ =
{flugNr, ticketNr,flugNr vonflugNr nachflugNr abflugszeitflugNr ankunftszeitflugNr ftypIdflugNr wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
{flugNr, ticketNr}+ =
{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage,
flugNr vonflugNr nachflugNr abflugszeitflugNr ankunftszeitflugNr ftypIdflugNr wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
{flugNr, ticketNr}+ =
{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung,
flugNr vonflugNr nachflugNr abflugszeitflugNr ankunftszeitflugNr ftypIdflugNr wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
{flugNr, ticketNr}+ =
{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name,
flugNr vonflugNr nachflugNr abflugszeitflugNr ankunftszeitflugNr ftypIdflugNr wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
{flugNr, ticketNr}+ =
{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum
flugNr vonflugNr nachflugNr abflugszeitflugNr ankunftszeitflugNr ftypIdflugNr wochentagevon,nach entfernungticketNr nameflugNr,ticketNr platzCodeflugNr,ticketNr datumflugNr,platzCode,datum ticketNrvon,nach,abflugszeit flugNr
{flugNr, ticketNr}+ =
{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum}
SS 2004 B. König-Ries: Datenbanksysteme 4-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 FDflugNr,datum filmtitel
kann nicht gefordert werden, da auf Fernflügen evt. mehrere Filme gezeigt werden.
Lösung: Mehrwertige AbhängigkeitflugNr,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 4-55
Beispielinstanz FLUGINFO mit Filmtiteln (div. Attribute weggelassen):FlugNr von nach Ftyp Filmtitel TicketNr Platz Datum Name ----------------------------------------------------------------------------------------LH458 MUC SFO 744 Casablanca 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 - 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 - 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi 7216087338 19D 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 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 - 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 - 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi 7216087338 19D 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 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 - 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 - 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi 7216087338 19D 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 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 Play it again, Sam 7216080815 81K 03-SEP-00 Lockemann_Mr_P LH458 MUC SFO 744 The Maltese Falcon 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH458 MUC SFO 744 The Big Sleep 7216082080 81A 01-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Psycho 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 The Birds 7216082080 84K 19-AUG-00 Hillebrand_Mr_G LH459 SFO MUC 744 Casablanca 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH459 SFO MUC 744 Play it again, Sam 7216084066 04A 23-SEP-00 Schmitt_Mrs_B LH4616 FRA LHR AB6 - 7216080816 20A 01-AUG-00 Simpson_Mr_B LH4616 FRA LHR AB6 - 7216083968 05E 02-AUG-00 Lockemann_Mr_P LH500 FRA GIG 340 Star Wars 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 The Empire Strikes Back 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Return of the Jedi 7216080817 19E 12-AUG-00 Weinand_Mr_C LH500 FRA GIG 340 Star Wars 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 The Empire Strikes Back 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Return of the Jedi 7216083970 19G 12-AUG-00 Bender_Mr_P LH500 FRA GIG 340 Star Trek 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Wrath of Khan 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 The Search for Spock 7216087337 01C 02-SEP-00 Nimis_Mr_J LH500 FRA GIG 340 Star Wars 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 The Empire Strikes Back 7216087338 19D 12-AUG-00 Kuhn_Mrs_E LH500 FRA GIG 340 Return of the Jedi 7216087338 19D 12-AUG-00 Kuhn_Mrs_E
Mehrwertige Abhängigkeiten (2)
SS 2004 B. König-Ries: Datenbanksysteme 4-56
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\(XY). 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 4-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
SS 2004 B. König-Ries: Datenbanksysteme 4-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
SS 2004 B. König-Ries: Datenbanksysteme 4-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\(XY). (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 4-60
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 4-61
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 4-62
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} dochoose 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 4-63
Finden eines Schlüssels: Beispiel
FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name)flugNr von von,nach entfernungflugNr nach ticketNr name flugNr abflugszeit flugNr,ticketNr platzCodeflugNr ankunftszeit flugNr,ticketNr datumflugNr ftypId flugNr,platzCode,datum ticketNrflugNr 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 4-64
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 4-65
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} \ (XY), 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 4-66
Einfüge-Anomalien
Es werde MVD XY und assoziierte Gleichung
r = XY(r) ⋈ XZ(r)
mit YX und Z = {A1, ... ,An} \ (XY) 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 4-67
Änderungs-Anomalien
Es werde MVD XY und assoziierte Gleichung
r = XY(r) ⋈ XZ(r)
mit YX und Z = {A1, ... ,An} \ (XY) 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 4-68
Lösch-Anomalien
Es werde MVD XY und assoziierte Gleichung
r = XY(r) ⋈ XZ(r)
mit YX und Z = {A1, ... ,An} \ (XY) 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 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-70
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 4-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?
SS 2004 B. König-Ries: Datenbanksysteme 4-72
Normalformen
FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name)
FDs:flugNr von von,nach entfernungflugNr nach ticketNr name flugNr abflugszeit flugNr,ticketNr platzCodeflugNr ankunftszeit flugNr,ticketNr datumflugNr ftypId flugNr,platzCode,datum ticketNrflugNr 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 4-73
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 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-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)
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-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
SS 2004 B. König-Ries: Datenbanksysteme 4-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äreBUCHUNG (flugNr, ticketNr, platzCode, datum)
nicht in BCNF wegen(flugNr, platzCode, datum) ticketNr.
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-81
Normalformen in der Übersicht
1NF
2NF
3NF
BCNF
4NF
Alle Relationen
Nichtschlüsselattributehängen voll funktionalvon jedem Schlüssel ab
Nichtschlüsselattributehängen funktional nurvon Superschlüsseln ab Keine FDs außer
Schlüsselabhängigkeiten
Keine MVDs außer Schlüsselabhängigkeiten
SS 2004 B. König-Ries: Datenbanksysteme 4-82
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 4-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).
SS 2004 B. König-Ries: Datenbanksysteme 4-84
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
(1ik). r r1 ⋈ r2 ⋈ ... ⋈ rk.
SS 2004 B. König-Ries: Datenbanksysteme 4-85
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 4-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) entfernungticketNr 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?
SS 2004 B. König-Ries: Datenbanksysteme 4-87
Inkorrekte Zerlegung: Beispiel
Weitere Zerlegung von FLUG in Teilrelationen
FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit) inFLUGTAGE (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 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-89
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 4-90
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 4-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 Ri(X,Y) für jede FD X Y in c,// sofern X Y nicht bereits durch anderen Relationstyp Rj abgedeckt isti := 0for 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} endend 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 := endend if
SS 2004 B. König-Ries: Datenbanksysteme 4-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.
SS 2004 B. König-Ries: Datenbanksysteme 4-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) entfernungticketNr 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) entfernungticketNr 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) entfernungticketNr 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) entfernungticketNr 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) entfernungticketNr name
FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit)BUCHUNG (flugNr, ticketNr, platzCode, datum)FLUGSTRECKE (von, nach, entfernung)TICKET (ticketNr, name)
SS 2004 B. König-Ries: Datenbanksysteme 4-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 := {A1,...,An} \ (XY). 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 4-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 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).