Eigenschaften von Datenbanken • In diesem Abschnitt beschreiben wir wünschenswerte Eigenschaften von Datenbanken, Datenbanken insbesondere Relationenschemata:

– Normalformen, die auf mathematischen Modellen beruhen und Relationenschemata betreffen – Strukturregeln, die global für ein Datenbankschema (und die darin enthaltenen Relationenschemata)) g gelten

• Grundsätzliche sind DB-Schemata, die den Strukturregeln genügen, so aufgebaut, daß sie möglichst einfach genutzt werden d kö können. • Im folgenden betrachten wir immer eine feste Datenbank D: – X ⊆ A sei eine Teilmenge der Attribute einer Relation R – w[X] sei die Projektion des Tupels w ∈ R auf die Attribute aus X (Oft wird i d vereinfachend i f h d Relation R l ti statt t tt Relationenschema R l ti h benutzt) b t t)

1 8. DBS Prof. Jasper

Funktionale Abhängigkeiten •

•

Ein Zusammenhang zwischen Attributen kann über die (in der Miniwelt vorkommenden) Extensionen der Attribute wie folgt definiert werden: Sei X eine Teilmenge der Attribute einer Relation (genauer eines Relationen-schemas) R. Eine zweite Menge Y von Attributen von R heißt f kti funktional l abhängig bhä i von X geschrieben h i b (X → Y (R)), (R)) wenn fü für alle ll T Tupell aus allen möglichen Extensionen (bezüglich der Miniwelt) von R gilt: Gleiche Werte von X implizieren gleiche Werte von Y. X → Y (R) :⇔ ∀ w1, w2 ∈ R: R w1[X] = w2 [X] → w1[Y] = w2 [Y]

Beispiel: Relationen zur einer Verkaufs-Anwendung:

– In der Kunden-Relation ist das Attribut "KName" funktional abhängig g g von dem Attribut "KNr", d.h. zu jeder Kundennummer gehört eindeutig der Name eines Kunden ("rechtseindeutige Relation" oder "Funktion" zwischen "KName" und "KNr"). – In der gleichen Relation ist "KAdr" nicht funktional abhängig von "KName" (es ist durchaus möglich, daß zwei Tupel mit gleichem Namen, aber unterschiedlichen Einträgen g bei "KAdr" existieren). ) 2 8. DBS Prof. Jasper

Primärschlüssel und Normalformen •

• • •

Den Begriff Primärschlüssel kann man mit Hilfe des Begriffs der funkionalen Abhängigkeit wie folgt definieren:

– Ein Primärschlüssel ist eine Menge von Attributen A einer Relation R und – für alle Attribute B aus R, B ∉ A, gilt: A → {B} (R) (B ist funktional von A abhängig) (Eindeutigkeit), und – Wenn |A| > 1 (A enthält mehrere Attribute) Attribute), dann gibt es keine echte Teilmenge von A, von der alle anderen Attribute funktional abhängig sind (Minimalität).

Wichtig c t g ist, st, daß funktionale u t o a e Abhängigkeiten b ä g g e te nicht c t aus der de Extension te s o erkannt werden können, sondern a priori bei der Modellierung der Miniwelt als solche festgelegt werden müssen. Natürlich können Extensionen als Gegenbeispiele für geforderte funktionale Abhängigkeiten dienen. Mit Hilfe der funktionale Abhängigkeiten können jetzt die drei klassischen Normalformen (1. (1 NF, NF 2. 2 NF und 3. 3 NF) definiert werden. werden Es gibt mindestens noch zwei weitere Normalformen (4.NF und 5.NF), die u.a. auf mehrwertige Abhängigkeiten beruhen. Die Normalformen verschärfen sukzessive die Anforderung an Relationen, Üblicherweise haben Relationen "gute" Eigenschaften, wenn sie in 3. NF sind. 3 8. DBS Prof. Jasper

Normalformen 1. NF 2. NF 3. NF 4. NF 5. NF Nur triviale Verbundabhängigkeiten Keine mehrwertigen Abhängikeiten Nur Abhängigkeiten vom Primärschlüssel Nichtschlüsselattribute voll vom Schlüssel abhängig Alle Attributwerte sind atomar Relation in beliebiger Form 8. DBS Prof. Jasper

4

1. Normalform •

•

Eine Relation ist in 1. Normalform (1. NF), wenn alle Attribute einen atomaren Wertebereich besitzen.

– In der obigen Formalisierung des relationalen Datenmodells ist dies trivialerweise erfüllt, da die Elemente der Domänen keine interne Struktur besitzen. Insbesondere sind als benutzerdefinierte Typen im wesentlichen nur "flache" flache Aufzählungstypen möglich. möglich Somit können klassische Strukturen (z. B. Arrays, Records und Listen) nicht für die Konstruktion von Wertebereichen genutzt werden.

Relationen in 1 1. NF können insbesondere Probleme im ZusammenZusammen hang mit Update-Operationen verursachen:

– Als Beispiel betrachten wir die folgende "Bestellung"- Relation: Bestellung = (BeNr, Datum, TeilNr, TeBesch, Anzahl, VPreis) – Dieses Relationenschema muss bezüglich der beiden Problembereiche: • Redundanz und • Update-Anomalien – untersucht werden. Diese beiden sind nicht unabhängig voneinander: Redundanz (z. B. Wiederholung der Teilebeschreibung in jeder Bestellung) stehtt üb ste üblicherweise c e e se im Zusammenhang usa e a g mitt Update Update-Anomalien. o a e 5 8. DBS Prof. Jasper

Update-Anomalien (I) •

Es gibt vier Arten von Update-Anomalien:

1 Änderungsaufwand 1. Wenn sich die Teilebeschreibung ändert, muß sie nicht nur einmal, sondern für alle betroffenen Tupel geändert werden. 2. Inkonsistente Attributwerte Das Schema enthält keine Forderung, daß die Teilebeschreibung eindeutig für jedes Teil sein muß. Daraus können unterschiedliche und damit inkonsistente Beschreibungen zu einem Teil existieren. 3. Unvollständiges Einfügen Da der Primärschlüssel eine Attributkombination ist, müssen für jedes einzufügende Tupel Bestell- und Teilenummer "reale" Werte (keine Nullwerte!) sein sein. In der geänderten Relation kann man keine Teile einfügen, zu der nicht mindestens eine Bestellung vorliegt. (Wie kann man Teile bestellen, die nicht in der Relation existieren?) 4. Löschen mit Informationsverlust Das Löschen einer Bestellung kann dann zu einem (unerwünschten) Informationsverlust führen, wenn danach das bestellte Teil nicht mehr in einem Tupel der Relation existiert. Es gibt dann zu diesem Teil keine T il b Teilebeschreibung h ib mehr. h 6 8. DBS Prof. Jasper

Update-Anomalien (II) • Die hier besprochenen Update-Anomalien resultieren aus der Festlegung von Primärschlüssel und den funktionalen Abhängigkeiten für die Attribute der Relation. • Diese sind für die obige Relation: – BeNr} → {Datum} ("Bestellung wird an einem Tag abgeschlossen.") – {TeilNr} → {TeBesch} ("Ein Teil wird eindeutig beschrieben.") – {BeNr, TeilNr} → {Anzahl, VPreis} ("B t ll ("Bestellmengen können kö nicht i ht gesplittet litt t werden.") d ")

• Die Probleme a) und b) resultieren aus der funktionalen Abhängigkeit b ä g g e {{TeilNr} e } → {{TeBesch}. e esc } Verallgemeinert e a ge e e tritt hier das Problem auf, dass Attribute von einem Teil des Primärschlüssels abhängen können. 7 8. DBS Prof. Jasper

2. Normalform •

•

•

Eine Relation ist in 2. Normalform (2. NF), wenn sie in 1. NF ist und jedes nicht zum Primärschlüssel gehörende Attribut voll vom PrimärPrimär schlüssel (und nicht schon von einer Teilmenge) funktional abhängig ist. Die Update-Anomalien a) und b) treten bei der Beispielsrelation in 2 2. NF nicht auf:

– Im obigen Beispiel ist "TeBesch" von einer Teilmenge des Primärschlüssels nämlich "TeNr" sels, TeNr , funktional abhängig. abhängig

Solche Abhängigkeitsuntersuchungen kann man sehr anschaulich an Abhängigkeitsdiagrammen (für eine Relation) durchführen. Gerichtete Kanten bedeuten Abhängigkeit, Abhängigkeit doppelt umrandete Attribute sind diejenigen des Primärschlüssels:

BeNr

Datum

TeNr e

TeBesch

Anzahl

VPreis 8

8. DBS Prof. Jasper

1. NF ↦ 2. NF •

•

Im obigen Diagramm wird ersichtlich, daß "Datum" nur von "BeNr" und "TeBesch" nur von "TeilNr" abhängig ist (untere Hälfte des Diagramms). In der oberen Hälfte des Diagramms wird deutlich, daß alle Nichtschlüsselattribute vom Primärschlüssel abhängig sind. Die Abhängigkeiten gg in der unteren Hälfte verhindern somit,, dass die Relation in 2.NF ist. Algorithmisch kann die 1. NF in die 2. NF wie folgt überführt werden:

•

Für das obige Beispiel erhält man die folgenden 3 Relationen:

• •

1. Bilde alle nicht-leeren 1 nicht leeren Teilmengen des Primärschlüssels Primärschlüssels. 2. Definiere für jede dieser Teilmengen eine neue Relation mit der Teilmenge als Schlüssel. 3 Füge jedes Nichtschlüsselattribut der ursprünglichen Relation zu der Relation 3. hinzu, von deren Schlüssel es voll abhängt (es gibt genau eins!). 4. Lösche die alte Relation sowie die Relationen, die nur aus einem Primärschlüssel bestehen. – Bestellung(BeNr Datum) – Artikel(TeilNr TeBesch) – Bestelliste(BeNr, TeilNr, Anzahl, VPreis)

9 8. DBS Prof. Jasper

Probleme bei 2. NF •

Das folgende Beispiel zeigt Probleme, die bei Relationen in 2. NF auftreten können: Kunde(KNr, KName, KAdr, VkNr, VkName) Die vier oben beschriebenen Update-Anomalien treten auch hier wieder auf: 1. Änderungsaufwand Die Änderung eines Verkäufernamens muss in allen betroffenen Tupeln durchgeführt werden. 2. Inkonsistente Attributwerte Prinzipiell könnten wieder unterschiedliche Verkäufernamen zu gleichen Verkäufernummern existieren. 3. Unvollständiges Einfügen Ein Verkäufer kann nicht ohne seinen ersten Kunden in die DB eingefügt werden. 4. Löschen mit Informationsverlust Das Löschen des letzten Kunden eines Verkäufers macht diesen in der DB nicht-existent. 10 8. DBS Prof. Jasper

3. Normalform •

Folgende funktionalen Abhängigkeiten sind in der Miniwelt vorhanden:

•

Eine Menge von Attributen X (bzw. (bzw ein Attribut A), A) die (das) eine andere Menge von Attributen Y (bzw. ein Attribut B) funktional bestimmt, also X → Y (bzw. A → B) heißt Determinante. Jeder Primärschlüssel ist damit eine Determinante, Determinante aber auch alle Schlüsselkandidaten (Attributkombinationen, die die Primärschlüsseleigenschaft erfüllen) sind Determinanten. Weiter gibt es Determinanten, die keine Schlüsselkandidaten sind, wie etwa "VkNr" VkNr im obigen Beispiel. Relationen sind in 3. Normalform (3. NF), wenn sie in 2. NF sind, und alle Determinanten Schlüsselkandidaten sind. sind

•

•

1. {KNr} → {KName, 1 {KName KAdr KAdr, VkNr, VkNr VkName} und 2. {VkNr} → {VkName} Die Relation ist in 2. NF, wie man sich leicht überzeugt, jedoch führt die 2. Abhängigkeit {VkNr} → {VkName} zu den o.a. o a Problemen. Problemen Daher wird eine weitere Normalform eingeführt, die sogenannte Determinanten berücksichtigt.

11 8. DBS Prof. Jasper

3. NF Beispiel •

Für die obige Beispielrelation kann wieder das Abhängigkeitsdiagramm betrachtet werden. werden Es sind wieder die Abhängigkeiten in der unteren Hälfte, die zu Konflikten führen.

KNr

KName

KAdr

VkNr

VkName

12 8. DBS Prof. Jasper

2. NF ↦ 3. NF •

Algorithmisch kann die 2. NF in die 3. NF wie folgt überführt werden:

•

Für das obige g Beispiel p ergibt g sich damit aus der ursprünglichen p g "Kunde"-Relation eine um das Attribut "VkNr" reduzierte Relation, sowie eine neue Verkäufer-Relation:

•

1. Bestimme alle Determinanten,, die nicht Schlüsselkandidaten sind. 2. Ermittle für jede Determinate die von ihr abhängigen Attribute. 3. Bilde iterativ für jede Determinante aus 1. eine neue Relation bestehend gg Attributen. Streiche aus der Determinante und den von ihr abhängigen diese Attribute (nicht die Determinante) in der ursprünglichen Relation. Die Determinate wird Primärschlüssel.

– –

Kunde(KNr, ( KName, KAdr, VkNr)) Verkäufer(VkNr, VkName)

–

Der Algorithmus zur Erlangung von Relationen in 3.NF 3 NF ist nicht eindeutig bzgl. des Ergebnisses: Es existiert i.a. auch keine eindeutig 3. NF für Relationen in 1.NF! Ein Beispiel dazu kann man sich leicht konstruieren. (Beachte dabei die Wahlmöglichkeiten bei der Auswahl der zu bearbeitenden Determinante in Schritt S 3.))

Bemerkung:

8. DBS Prof. Jasper

13

Probleme bei 3. NF (I) •

•

DB-Schemata in 3.NF (d. h. alle Relationenschemata sind in 3.NF) können auch noch problematische Eigenschaften haben.

Folgende zwei Beispiele zeigen Probleme mit Relationen, die sich in 3. NF befinden.

I.

Die Dekomposition von

Kunde(KNr, KName, Adr, VkNr, VkName) in zwei Relationen in 3. NF: K nde(KNr KName, Kunde(KNr, KName Adr, Adr VkNr) und nd Verkäufer(KNr, Verkä fer(KNr VkName) erzeugt u.a. folgende Update-Anomalien: 1. Änderungsaufwand Die Änderung eines Verkäufernamens zu einer Verkäufernummer muss in allen betroffenen Tupeln durchgeführt werden. 2. Unvollständiges Einfügen Einfügen eines neuen Verkäufers mit Nummer und Name, der noch keinen Kunden betreut, betreut ist unmöglich unmöglich, da sonst verbotenerweise Nullwerte im Primärschlüssel existieren würden.

Diese Probleme resultieren aus den beiden Abhängigkeiten: •

{ {KNr} } → {{VkNr}} und {VkNr} { } → {{VKName}, } die nicht auf zwei Relationen verteilt wurden (d.h. eine Abhängigkeit pro Relation), sondern über zwei Relationen "transitiv" verteilt sind. Diese Probleme werden nicht durch eine weitere Normalform, sondern durch schärfere Anforderungen an Relationen in 3. NF g nach obigem g behandelt. Dieses Problem taucht bei dem Vorgehen Algorithmus nicht auf, da dort funktionale Abhängigkeiten auf eine Relation beschränkt bleiben (Determinaten werden als Dekompositionskriterium 14 genommen). 8. DBS Prof. Jasper

Probleme bei 3. NF (II) II.

Die Dekomposition von Kunde(KNr, KName, Adr, VkNr, VkName) in zwei Relationen in 3. NF: Kunde(KNr, KName, Adr, VkName) und Verkäufer(VkNr, VkName) bringt folgendes Problem: Wenn zwei Verkäufer den gleichen Namen haben, kann ein natürlicher Verbund (über "VkName") für einen Kunden zwei Verkäufer (unterschiedliche N Nummer, aber b gleicher l i h N Name)) erzeugen. D Dadurch d h entsteht t t ht ein i IInformationsf ti verlust (welcher Käufer ist der richtige?), und der Vorgang heißt informationsverlierende Dekomposition (Gegenteil ist informationserhaltende Dekomposition). Somit ist eine weitere Anforderung an die 3. NF, dass keine informationsverlierende Dekomposition vorliegt.

Wie oben gilt, dass dieses Problem bei Verwendung der angegebenen Normalisierungsschritte o a s e u gssc tte nicht c t auftritt, au t tt, da alle a e abhängigen ab ä g ge Attribute tt bute aus de der ursprünglichen Relation (hier "VkName") gestrichen werden.

•

Fazit: F it Nicht die 3. NF-Eigenschaft allein sichert ein gutes DB-Schema, sondern beim Entwurfsprozess "dynamisch" erreichte Eigenschaften erzeugen ein gutes Schema. 15 8. DBS Prof. Jasper