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

SS 2004 B. König-Ries: Datenbanksysteme 4-1

Kapitel 4: Datenbankentwurf

Einführung

UML Modellierung

Schematransformation

Normalisierung



Einführung

UML Modellierung


Normalisierung


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


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


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.


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


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.


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


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


Zeitzone

1..

1..

0..

1

Flugzeugtyp


BusinessEconomy

Flug

FlugNr {eindeutig}Wochentage

Kunde


Passagier


WirdGeflogenMIt


Bedient


PlatzCodeDatum

1..

Buchung0..1

{Strecke.von Flug.Bedient.von}

1

1..

hatBuchung

SemantischesDatenmodell

LogischesDatenmodell

RelationalesDatenmodell

UML(intuitiv)

Erweitert relational(formal)

makroskopischeBetrachtung

mikroskopischeBetrachtung

Überarbeitung




Einführung

UML Modellierung


Normalisierung


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)


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


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)


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}


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


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



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



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



Assoziationen belassen viel Spielraum für die Modellierung. Gleiche Sachverhalte können unterschiedlich modelliert werden:

Kunde Flug

TicketNr: stringplatzCode: stringdatum: date

Bucht



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




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


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!



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


Buchung



Rolle: Sichtweise eines Objektes durch das gegenüberliegende Objekt.

Besonders bei reflexiven Assoziationen interessant.

Flug

Anschlussflug

Ankommend

0..

1

Abgehend



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


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


vonnach

1 1

1..

1..5

1..

1..1WirdGeflogenMit


0..11


PlatzCodeDatum

Buchung

Flugzeugtyp


BusinessEconomy

Flug

FlugNr {eindeutig}WochentageEntfernung

Ticket


Kunde


Flughafen


Zeitzone

{k1,k2 Kunde:k1.Buchung.Ticket= k2.Buchung.Ticket k1=k2}

UML-Klassendiagramm: Beispiel


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.



Einführung

UML Modellierung


Normalisierung


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.



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.



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.



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.


vonnach

1 1

1..

1..5

1..

1..1WirdGeflogenMIt


0..11


PlatzCodeDatum

Buchung

Flugzeugtyp


BusinessEconomy

Flug


Ticket


Kunde


Flughafen


Zeitzone


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.



vonnach

1 1

1..

0..5

1..

1..1WirdGeflogenMIt


0..11


PlatzCodeDatum

Buchung

Flugzeugtyp


BusinessEconomy

Flug


Ticket


Kunde


Flughafen


Zeitzone


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)




Einführung

UML Modellierung


Normalisierung


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.


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.


Beispielszenario (1)

Sei Ergebnis der UML-Schematransformation die Relation

FLUGINFO (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung, ticketNr, platzCode, datum, name)


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 ...


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!).


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.


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.


Funktionale Abhängigkeiten: Beispiele


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


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.


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.


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.


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.


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!



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


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.


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


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


Hülle einer Attributmenge: Beispiel


{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, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage,



{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung,



{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name,



{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum



{flugNr, ticketNr, von, nach, abflugszeit, ankunftszeit, ftypId, wochentage, entfernung, name, platzCode, datum}


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.


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)


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.


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


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


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).


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.


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.


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.


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 --


Schlüssel von FLUGINFO

Durch Ausprobieren erhält man Menge aller Schlüssel von FLUGINFO: {flugNr,ticketNr} {flugNr,platzCode,datum}


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.


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.


Änderungs-Anomalien


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.


Lösch-Anomalien


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.


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.


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.


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?


Normalformen


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.


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.


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.


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)


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.


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


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.


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.


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.


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


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.


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).


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.


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.


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?


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.


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.


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.


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.



// 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



Gewonnene Zerlegung ist i.A. nicht eindeutig, da Wahlfreiheit bzgl. Bildung und Sortierung der kanonischen Überdeckung und Auswahl des Schlüssels im Abschlussschritt besteht.


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


FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit)


FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit)BUCHUNG (flugNr, ticketNr, platzCode, datum)


FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit)BUCHUNG (flugNr, ticketNr, platzCode, datum)FLUGSTRECKE (von, nach, entfernung)


FLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit)BUCHUNG (flugNr, ticketNr, platzCode, datum)FLUGSTRECKE (von, nach, entfernung)TICKET (ticketNr, name)


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.


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 2004B. König-Ries: Datenbanksysteme4-1 Kapitel 4: Datenbankentwurf Einführung UML Modellierung...

Documents

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