Eigenschaften von Datenbanken, insbesondere

Transkript

1 Eigenschaften von Datenbanken In diesem Abschnitt beschreiben wir wünschenswerte Eigenschaften von Datenbanken, insbesondere Relationenschemata: Normalformen, die auf mathematischen Modellen beruhen und Relationenschemata betreffen Strukturregeln, die global für ein Datenbankschema (und die darin enthaltenen Relationenschemata) )gelten Grundsätzliche sind DB-Schemata, die den Strukturregeln genügen, so aufgebaut, daß sie möglichst einfach genutzt werden 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 vereinfachend Relation statt tt Relationenschema benutzt) t) 1

2 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 funktional abhängig von X geschrieben (X Y(R)) (R)), wenn für alle Tupel aus allen möglichen Extensionen (bezüglich der Miniwelt) von R gilt: Gleiche Werte von X implizieren gleiche Werte von Y. X Y(R) : w 1, w 2 R: w 1 [X] = w 2 [X] w 1 [Y] = w 2 [Y] Beispiel: Relationen zur einer Verkaufs-Anwendung: In der Kunden-Relation ist das Attribut "KName" funktional abhängig ggvon 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 bei "KAdr" existieren). 2

3 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), dann gibt es keine echte Teilmenge von A, von der alle anderen Attribute funktional abhängig sind (Minimalität). Wichtig ist, daß funktionale Abhängigkeiten g nicht aus der Extension 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. NF, 2. NF und 3. NF) definiert 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

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

5 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" Aufzählungstypen 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. NF können insbesondere Probleme im Zusammen- 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) steht t üblicherweise e im Zusammenhang a mit Update-Anomalien. a e 5

6 Update-Anomalien (I) Es gibt vier Arten von Update-Anomalien: 1. Änderungsaufwand 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. 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 Teilebeschreibung ib mehr. 6

7 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} ("Bestellmengen können nicht gesplittet t werden.") Die Probleme a) und b) resultieren aus der funktionalen Abhängigkeit gg {TeilNr} {TeBesch}. esc Verallgemeinert e e tritt hier das Problem auf, dass Attribute von einem Teil des Primärschlüssels abhängen können. 7

8 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ä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. NF nicht auf: Im obigen Beispiel ist "TeBesch" von einer Teilmenge des Primärschlüs- sels, nämlich "TeNr", funktional abhängig. Solche Abhängigkeitsuntersuchungen kann man sehr anschaulich an Abhängigkeitsdiagrammen (für eine Relation) durchführen. Gerichtete Kanten bedeuten Abhängigkeit, doppelt umrandete Attribute sind diejenigen des Primärschlüssels: BeNr Datum TeNr TeBesch Anzahl VPreis 8

9 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: 1. Bilde alle nicht-leeren Teilmengen des 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 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. Für das obige Beispiel erhält man die folgenden 3 Relationen: Bestellung(BeNr Datum) Artikel(TeilNr TeBesch) Bestelliste(BeNr, TeilNr, Anzahl, VPreis) 9

10 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

11 3. Normalform Folgende funktionalen Abhängigkeiten sind in der Miniwelt vorhanden: 1. {KNr} {KName, KAdr, 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. Problemen. Daher wird eine weitere Normalform eingeführt, die sogenannte Determinanten berücksichtigt. Eine Menge von Attributen X (bzw. ein Attribut 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, aber auch alle Schlüsselkandidaten (Attributkombinationen, die die Primärschlüsseleigenschaft erfüllen) sind Determinanten. Weiter gibt es Deter- minanten, die keine Schlüsselkandidaten sind, wie etwa "VkNr" im obigen Beispiel. Relationen sind in 3. Normalform (3. NF), wenn sie in 2. NF sind, und alle Determinanten Schlüsselkandidaten sind. 11

12 3. NF Beispiel Für die obige Beispielrelation kann wieder das Abhängigkeitsdia- gramm betrachtet werden. Es sind wieder die Abhängigkeiten in der unteren Hälfte, die zu Konflikten führen. KNr KName KAdr VkNr VkName 12

13 2. NF 3. NF Algorithmisch kann die 2. NF in die 3. NF wie folgt überführt werden: 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 aus der Determinante und den von ihr abhängigen gg Attributen. Streiche diese Attribute (nicht die Determinante) in der ursprünglichen Relation. Die Determinate wird Primärschlüssel. Für das obige Beispiel ergibt sich damit aus der ursprünglichen "Kunde"-Relation eine um das Attribut "VkNr" reduzierte Relation, sowie eine neue Verkäufer-Relation: Kunde(KNr, KName, KAdr, VkNr) Verkäufer(VkNr, VkName) Bemerkung: Der Algorithmus zur Erlangung von Relationen in 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 3.) 13

14 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: Kunde(KNr, KName, Adr, VkNr) und Verkäufer(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, ist 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 behandelt. Dieses Problem taucht bei dem Vorgehen nach obigem Algorithmus nicht auf, da dort funktionale Abhängigkeiten auf eine Relation beschränkt bleiben (Determinaten werden als Dekompositionskriterium genommen). 14

15 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 Nummer, aber gleicher Name) erzeugen. Dadurch entsteht ein Informationsverlust (welcher Käufer ist der richtige?), und der Vorgang heißt informationsverlierende Dekomposition (Gegenteil ist informationserhaltende Dekompo- sition). 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 nicht auftritt, tt, da alle abhängigen ge Attribute aus der ursprünglichen Relation (hier "VkName") gestrichen werden. Fazit: Nicht die 3. NF-Eigenschaft allein sichert ein gutes DB-Schema, sondern beim Entwurfsprozess "dynamisch" erreichte Eigenschaften erzeugen ein gutes Schema. 15