Datenbanken. Rückblick: Datenbank-Entwurfsprozess. Semantische Datenmodellierung (vgl. Kapitel 2)

Transkript

1 Rückblick: Datenbank-Entwurfsprozess Semantische Datenmodellierung (vgl. Kapitel 2) Überführung des semantischen Datenmodells in das relationale Modell (vgl. Kapitel 3) Das relationale Modell wird in eine normalisierte Form gebracht. 1

2 Normalisierung von relationalen Datenbanken Anomalien: Datenbanken ändern ihren Zustand ständig durch Einfügen, Ändern oder Löschen von Tupeln. Wie wir im 1. Kapitel gesehen haben, sind Inkonsistenzen von Datenbanken, also Zustände, die die Realität nicht richtig wiedergeben, unerwünscht. So führen z.b. Redundanzen häufig zu Inkonsistenzen. Nur bei den genannten Zustandsänderungen können nicht gewünschte Zustände entstehen, die man mit dem Begriff Anomalie bezeichnet. Hingegen braucht das Lesen (also Informieren) nicht im Bezug auf Anomalien betrachtet werden, da Leseoperationen den Datenbank-Zustand nicht verändern. Normalisierung: Die Normalisierung ist ein Vorgehen, das auf vorhandene relationale Datenbanken angewendet werden kann. Das Verfahren garantiert angewendet auf Relationen im Ergebnis eine Menge von Relationen mit der gleichen Semantik wie zu vor, die jedoch normalisiert sind. Die Menge der Relationen nimmt durch den Normalisierungsprozess zu. Mit der Kenntnis der Normalisierung und durch den Prozess der guten Modellierung können Anomalien zu einem großen Teil bereits beim Entstehungsprozess des Datenmodells vermieden werden. Insofern empfiehlt es sich, den Datenmodellierungs-Prozess richtig zu durchlaufen. 2

3 Anomalien (Beispiel): Töpferprodukt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpfermarkt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpfermarkt Erbach 80 Die Einfüge-Anomalie beschreibt eine Anomalie, die auftritt, wenn ein Tupel eingefügt wird. Was passiert, wenn ein neuer Verkaufsmarkt eingefügt werden soll, für den noch keine Produkte existieren? Was passiert, wenn ein neues Produkt erzeugt wird, das noch auf keinem Markt existiert? 3

4 Anomalien (Beispiel): Töpferprodukt Markt Beispiel: Einfügen des Produktes (33033, Schüssel, Gebrauch) in die Tabelle ohne zugehörigen Markt: Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpfermarkt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpfermarkt Erbach Schüssel Gebrauch????????? Problematik (Einfüge-Anomalie): Die neue (letzte) Zeile ist nicht vollständig. Der Teilschlüssel Verkaufsmarkt erhält keinen Wert (nicht zulässig). Angenommen es existiert noch kein Markt, aber sehr viele Produkte: Der benötigte Speicher ist etwa doppelt so hoch wie die Menge der Daten. 4

5 Anomalien (Beispiel): Töpferprodukt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpfermarkt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpfermarkt Erbach 80 Die Änderungs-Anomalie beschreibt eine Anomalie, die auftritt, wenn ein Tupel geändert wird. Was passiert, wenn der Marktstandort eines Verkaufsmarktes (z.b. Odenwälder Töpfermarkt) geändert werden soll? Was passiert, wenn die Funktion eines Produktes (z.b von Deko zu Gebrauch) geändert werden soll? 5

6 Anomalien (Beispiel): Töpferprodukt Markt Beispiel: Ändern des Produktes mit Nummer 20131: Funktion ist jetzt Gebrauch Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpfermarkt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpfermarkt Erbach 80 Problematik (Änderungs-Anomalie): Die zu ändernde Information ist redundant gespeichert, weil jedes Produkt so häufig vorkommt wie es auf Märkten existiert. Obwohl nur eine Änderung in der Realität durchgeführt werden soll, sind hier mehrere (3) Änderungen vorzunehmen. 6

7 Anomalien (Beispiel): Töpferprodukt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpfermarkt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpfermarkt Erbach 80 Die Lösch-Anomalie beschreibt eine Anomalie, die auftritt, wenn ein Tupel gelöscht wird. Was passiert, wenn ein Produkt gelöscht wird? Was passiert, wenn ein Produkt gelöscht wird, das das einzige (aktuelle) auf einem Markt ist? Was passiert, wenn ein Markt gelöscht wird? Was passiert, wenn ein Markt gelöscht wird, auf dem ein Produkt angeboten wird, das auf keinem anderen angeboten wird? 7

8 Anomalien (Beispiel): Töpferprodukt Markt Beispiel: Löschen des Produktes mit Nummer gelöschte Zeilen Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpfermarkt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpfermarkt Erbach 80 Problematik (Lösch-Anomalie): Nur ein Produkt soll gelöscht werden, aber 3 Zeilen müssen dafür wegfallen. Obwohl nur ein Produkt zu löschen ist, wird ein Markt (Rheinischer Tonmarkt) komplett verschwinden, weil dieses Produkt das einzige auf dem Markt war. 8

9 Ursachen der Anomalien Die Ursache von Anomalien liegt in der Redundanz der Daten. Sobald ein Faktum mehrfach (also redundant) gespeichert ist, läuft man Gefahr, bei Änderungen (Löschungen, Einfügungen) Fehler zu machen. Die Tatsache, dass man ein Faktum mehrfach abspeichert (bzw. wie in dem Beispiel abspeichern muss), liegt darin begründet, dass die Relationen ungünstig gewählt werden. So erscheint es bei näherer Betrachtung unsinnig, dass man Produkte und Märkte in einer Relation unterbringt. Das Erkennen von ungünstigen Relationen sollte nicht nur intuitiv erfolgen. Das Konzept der funktionalen Abhängigkeit ermöglicht es, systematisch solche Relationen zu finden. 9

10 Funktionale Abhängigkeit Funktion zwischen einer Menge A und B: Abbildung einer Menge A auf eine Menge B, für die gilt: Für alle a A gibt es genau ein b B. Funktionale Abhängigkeit: Eine Menge B von Attributen B1, B2, Bn ist funktional abhängig von einer Menge A von Attributen A1, A2, An, wenn eine Funktion zwischen A und B besteht, d. h. für alle {a1,a2, an} A gibt es genau ein {b1, b2, bn } B. Mit anderen Worten: In einer Relation ist Attribut(-kombination) B ist funktional abhängig von Attribut(-kombination) A, wenn für gleiche A-Werte jeweils gleiche B-Werte vorhanden sind. Darstellung: A B bedeutet: B hängt funktional von A ab, wobei A und B jeweils ein(e) Attribut(-menge) ist. 10

11 Funktionale Abhängigkeit (Beispiel): A B C Mögliche Aussagen: A B gilt aktuell. Jedoch könnte zu einem anderen Zeitpunkt eine Zeile (1, 3, 3) eingefügt werden, so dass A B nicht mehr gelten würde. B C gilt nicht, da es für den gleichen B-Wert (2) verschiedene C-Werte (3 und 2) gibt. C B gilt aktuell. Jedoch könnte zu einem anderen Zeitpunkt eine Zeile (1, 3, 2) eingefügt werden, so dass C B nicht mehr gelten würde. A, B C gilt nicht, weil es für eine gleiche A,B-Kombination (1, 2) zwei verschiedene C- Werte (3 und 2) gibt. A A gilt immer (trivial). Der Primärschlüssel einer Relation kann über die funktionale Abhängigkeit wie folgt spezifiziert werden: Ein Attribut (oder eine Kombination von Attributen) K heißt Schlüssel einer Relation, wenn für alle Attribute X aus der Relation gilt: K X. Zusätzlich muss gelten, dass keine echte Teilmenge von K diese Bedingung erfüllt (Minimalitätsbedingung). Die funktionale Abhängigkeit wird aktiv definiert (so wie der Schlüssel), d.h. es wird vor Eintragung von Tupeln festgelegt, welche funktionale Abhängigkeiten gelten und anschließend wird bei jedem Eintrag geprüft, ob diese eingehalten werden kann. Falls nicht, wird der Eintrag nicht akzeptiert. 11

12 1. Normalform (1NF) Ein Relationenschema ist in 1. Normalform (1NF), wenn alle Attribute des Schemas elementar (atomar) sind. Dies bedeutet, dass für die Attribute nur einfache, unstrukturierte Attribute erlaubt sind. Listenartige, mengenwertige oder relationenartige Attribute sind nicht erlaubt. Erlaubte Datentypen: integer, real, string (=char(), =varchar()), enum. Nicht erlaubte Datentypen: array, record, list. Nicht erlaubte Datentypen sind ohne Probleme in erlaubte zu überführen: Ein record ist selbst als Relation der record-elemente zu definieren. Ein array oder eine Liste kann durch eine Einführung einer Relation, die über den Schlüssel der Ursprungsrelation verbunden wird, zu erreichen. 12

13 1. Normalform (Beispiel) Lehrbücher ISBN Titel Autor UML Distilled Fowler Kendall Refactoring Fowler Datenbanken Heuer Saake Nicht-atomare Attributwerte sind verboten! Das Attribut Autor erlaubt pro Tupel (also pro Lehrbuch) für die 1NF nur einen Autor. Jedoch sind mehr Autoren pro Buch in der Realität erwünscht. Es ist nicht erlaubt, etwa den Attribut-Typ array () of string zu wählen, da sonst die 1NF-Eigenschaft verletzt wird. 13

14 1. Normalform (Beispiel) Lehrbücher ISBN Titel UML Distilled Refactoring Datenbanken Buchautoren ISBN Autor Fowler Kendall Fowler Heuer Saake Die Lösung liegt in der Ausgliederung des Attributs, das array-artig war. Ein neues Relationenschema wird erzeugt, in der dieses Attribut zusammen mit dem Primärschlüssel aufgenommen wird. Beide Attribute zusammen bilden den Primärschlüssel des neuen Relationenschemas. Der Schlüssel des ursprünglichen Relationenschemas wird in dem neuen Relationenschema Fremdschlüssel. Haben mehrere Autoren an einem Buch mitgeschrieben, so werden für solche Bücher mehrere Zeilen in der neuen Relation aufgenommen. 14

15 1. Normalform (Aufgabe) Gegeben sei das folgende Relationenschema: ProfName Weber Karczewski Vorlesung , Programmieren 1, 6 SWS , Datenbanken, 4 SWS , Datenbanken, 4 SWS 1. Ist dieses Relationenschema in 1. Normalform? Erläutern Sie hierzu kurz die Inhalte des o.a. Schemas. 2. Wenn nicht: Erstellen Sie 1NF-Schemata mit gleicher Semantik. 3. Nachdem Sie die Inhalte identifiziert und die Schamta normalisiert haben: Erstellen Sie ein EERM, das den Sachverhalt ausdrückt. 15

16 2. Normalform (2NF) Ein Relationenschema ist in 2. Normalform (2NF), wenn es in 1. Normalform ist und jedes Nichtschlüsselattribut voll funktional von jedem Schlüssel abhängt (und nicht nur von einem Teil des Schlüssels) Abhängigkeiten von einem Teilschlüssel führen zu Anomalien. Es gilt: Besteht der Schlüssel nur aus einem Attribut und 1NF ist gegeben, dann liegt stets 2NF vor, weil Teilschlüssel-Abhängigkeit nicht möglich ist. 16

17 2. Normalform (Beispiel) Gegeben sei das Anfangsbeispiel Töpferprodukt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Tee-Service Gebrauch Internat. Tonmarkt Strasbourg Kaffee-Service Gebrauch Internat. Tonmarkt Strasbourg Schale Deko Rheinischer Tonmarkt Mainz Schale Deko Odenwälder Töpfermarkt Erbach Schale Deko Internat. Tonmarkt Strasbourg Krug Deko Internat. Tonmarkt Strasbourg Krug Deko Odenwälder Töpfermarkt Erbach 80 Bei einem komplexen Relationenschema sollte man zunächst analysieren, welche Inhalte dargestellt werden. Man muss die Sicht der Anwendung (des Kunden) annehmen, um die Schemata anschließend richtig (normalisiert) zu formen. Dieser Prozess des Re-Engineering funktioniert nur über das Verstehen, was gemeint war. Folgende Schritte eignen sich, um zum Ergebnis zu gelangen: 17

18 2. Normalform (Beispiel) 1. Schritt: Identifizieren der funktionalen Abhängigkeiten: Man erkennt, dass in diesem Schema zwei voneinander unabhängige Entitäten abgebildet sind: Produkte und Märkte. Produkte besitzen eine Nummer, eine Art und eine Funktion. Märkte besitzen einen Namen (Verkaufsmarkt) und einen Standort. Der marktspezifische Preis bezieht sich auf Produkt und Markt gleichermaßen. Hieraus ergeben sich folgende funktionalen Abhängigkeiten: Prod-Nr Produktart; Produktart Funktion; Verkaufsmarkt Marktstandort; Prod-Nr, Verkaufsmarkt marktspez. Preis 2. Schritt: Überprüfen auf die Normalformen 1NF ist gegeben, denn jedes Attribut ist atomar (elementar, keine Listen oder Records). 2NF ist nicht gegeben, denn es gibt einige Attribute, die nicht vom ganzen Schlüssel (voll) funktional abhängen, sondern nur von einem Teil, z.b. Produktart und Funktion hängen nur von Prod-Nr, nicht von Verkaufsmarkt ab, Marktstandort hängt nur von Verkaufsmarkt, nicht von Prod-Nr ab. 18

19 2. Normalform (Beispiel) 3. Schritt: Auflösen der Teilabhängigkeiten durch Aufteilen des Relationenschemas Das Relationenschema muss so aufgetrennt werden, dass die gefundenen Teilabhängigkeiten (2. Schritt) nicht mehr auftreten können. Wir definieren ein Schema mit den vom Teilschlüssel Prod-Nr abhängigen Attributen, ein zweites mit den von Verkaufsmarkt abhängigen Attributen und ein drittes mit den von beiden Teilschlüsseln abhängigen Attributen. Also: Ursprungsschema: Töpferprodukt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Normalisierte Schemata (2NF): Töpferprodukt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort TöpferproduktMarkt Prod-Nr. Verkaufsmarkt Marktspez. Preis 19

20 2. Normalform (Beispiel) 4. Schritt: Überprüfen auf die Verbindungen zwischen den neuen Relationenschemata, so dass gewährleistet ist, dass die Informationen im ursprünglichen Relationenschema noch vorhanden sind. In diesem Schritt muss untersucht werden, dass kein neues Schema isoliert ohne Verbindung zum Rest der Schemata exisitert. Ggfs. muss eine solche Verbindung nachträglich hergestellt werden. Im Beispiel ist in jedem Schema wenigstens eines der beiden Schlüsselattribute des Ursprungsschemas vorhanden. Es ist nur noch dafür zu sorgen, dass entsprechende Fremdschlüssel eingeführt werden. Die Produkt-Nr. in TöpferproduktMarkt wird Fremdschlüssel zur Produkt-Nr. in Töpferprodukt und der Verkaufsmarkt in TöpferproduktMarkt wird Fremdschlüssel zu Verkaufsmarkt in Markt. Töpferprodukt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort TöpferproduktMarkt Prod-Nr. Verkaufsmarkt Marktspez. Preis 20

21 2. Normalform (Beispiel) Folgende Regeln müssen bei diesem Vorgehen zur Normalisierung beachtet werden: Funktionale Abhängigkeiten dürfen bei der Aufteilung in verschiedene Relationenschemata nicht zerlegt werden, d.h. es muss nach der Aufteilung jedes Attribut einer funktionalen Abhängigkeit des Ursprungsschemas in einer der zerteilten Schemata komplett vorhanden sein, also müssen z.b. die Attribute Prod-Nr. und Funktion in einem Schema sein, weil sie gemeinsam in der funktionalen Abhängigkeit Prod-Nr. Funktion vorkommen. Der ursprüngliche Schlüssel des Relationenschemas muss in einem der zerteilten Schemata komplett vorkommen. Der Schlüssel darf also nicht selbst zerteilt werden. Man spricht hier von Verbundtreue. Bei Verletzung der Verbundtreue entstehen isolierte Schemata bei der Zerteilung. Im Beispiel ist in dem Schema TöpferproduktMarkt der ursprüngliche Schlüssel vorhanden (Prod-Nr., Verkaufsmarkt ). 21

22 2. Normalform (Beispiel Verlust der Verbundtreue) Ursprungsschema: Töpferprodukt Markt (ohne das Attribut Markspez. Preis ) Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Mit dem Attribut Marktspez. Preis entfällt auch die funktionale Abhängigkeit Prod-Nr., Verkaufsmarkt Marktspez.Preis Normalisierte Schemata (2NF): Töpferprodukt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort TöpferproduktMarkt Prod-Nr. Verkaufsmarkt Marktspez. Preis 22 Das Schema TöpferproduktMarkt wird nicht mehr benötigt wegen der verlorenen funktionalen Abhängigkeit. Der ursprüngliche Schlüssel ist nicht mehr komplett in einem Schema vorhanden. Die Schemata Töpferprodukt und Markt sind nicht mehr miteinander verbunden. Man kann also nicht mehr abbilden, welches Produkt auf welchem Markt angeboten wird.

23 2. Normalform (Beispiel) Alternativ kann man das Reengineering auch so gestalten, dass man aus dem Ursprungsschema versucht ein EERM zu entwickeln, das den Sachverhalt wiedergibt. In unserem Beispiel kann man vermuten, dass es Produkte gibt, die auf Märkten verkauft werden. Produkt (0,*) (1,*) 1 Markt Produkt (Prod-Nr., Produktart, Funktion) Markt (Verkaufsmarkt, Standort) wirdangebotenauf (Marktspez. Preis) Das EERM wird nach den gelernten Regeln (Kap. 3) überführt in ein relationales Datenmodell. Produkt Markt Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort wirdangebotenauf Prod-Nr. Verkaufsmarkt Marktspez. Preis 23

24 2. Normalform (Aufgabe) Gegeben sei das folgende abstrakte Relationenschema, das nicht in 2NF ist. A B C D E F Schlüssel ist A,B. Es gelten: A,B C; A D; B E; B F Überführen Sie das 2NF-Schema in Schemata, die in 2NF sind. 24

25 3. Normalform (3NF) Ein Relationenschema ist in 3. Normalform (3NF), wenn es in 2. Normalform ist (und somit auch in 1. Normalform) und wenn kein Nichtschlüssel-Attribut transitiv von einem Schlüssel abhängt bzw. alle Nichtschlüssel-Attribute direkt vom Schlüssel abhängen. Indirekte Abhängigkeiten vom Schlüssel über Nichtschlüssel-Attribute führen zu Anomalien. Transitive Abhängigkeiten sind Abhängigkeiten über andere Attribute, also z.b. C hängt transitiv von A ab, wenn es ein B gibt, so dass gilt: A B und B C. 25

26 3. Normalform (Beispiel) Gegeben sei vom Anfangsbeispiel die Relation Töpferprodukt Prod-Nr. Produktart Funktion Tee-Service Gebrauch Kaffee-Service Gebrauch Schale Deko Schale Deko Schale Deko Krug Deko Krug Deko Auch hier (wie bei 2NF) kann man systematisch die 3. Normalform herstellen. 26

27 3. Normalform (Beispiel) 1. Schritt: Identifizieren der funktionalen Abhängigkeiten: Prod-Nr. Produktart; Produktart Funktion ergibt sich aus der bereits bei 2NF vorgenommenen Analyse. 2. Überprüfen auf die Normalformen 1NF ist gegeben, denn jedes Attribut ist atomar (elementar, keine Listen oder Records). 2NF ist gegeben, denn es gibt keine Attribute, die nur von einem Teil des Schlüssels abhängen. Dies ist in diesem Beispiel nicht möglich, da der Schlüssel nur aus einem Attribut besteht. 3NF ist nicht gegeben, da Funktion transitiv von dem Schlüssel Prod-Nr. abhängt. 27

28 3. Normalform (Beispiel) 3. Schritt: Auflösen der transitiven Abhängigkeit(en) Das Relationenschema muss so aufgetrennt werden, dass die gefundene(n) transitive Abhängigkeit(en) (2. Schritt) nicht mehr auftreten können. Wir definieren ein zusätzliches Relationenschema mit dem Attribut, über das die Transitivität entsteht (Produktart ) und dem Attribut, das transitiv vom Schlüssel abhängt (Funktion ). Ersteres wird Schlüssel des neuen Relationenschemas. Das ursprüngliche Relationenschema wird reduziert um das transitiv abhängige Attribut. Das die Transitivität auslösende Attribut wird Fremdschlüssel zu dem neuen Schema. Also: Ursprungsschema: Töpferprodukt Prod-Nr. Produktart Funktion Normalisierte Schemata (3NF): Töpferprodukt ProduktFunktion Prod-Nr. Produktart Produktart Funktion 4. Überprüfung: Keines der Schemta ist isoliert (also nicht erreichbar). 28

29 3. Normalform (Beispiel) Gesamtlösung für das Anfangsmodell Töpferprodukt Markt (nicht normalisiert) Prod-Nr. Produktart Funktion Verkaufsmarkt Marktstandort Marktspez. Preis Normalisierte Schemata (3NF): Töpferprodukt Prod-Nr. Produktart Markt Verkaufsmarkt Marktstandort ProduktFunktion Produktart Funktion TöpferproduktMarkt Prod-Nr. Verkaufsmarkt Marktspez. Preis 29

30 3. Normalform (Aufgabe) Ein Lieferant (L) liefert Teile (T) in einer bestimmten Anzahl (A). Die Teile sind zu liefern an einen Ort (O) des Kunden, der eine Entfernung in Kilometern (K) vom Standort des Lieferanten entfernt ist. LTAOK LNR TNR Anzahl Ort KM-Entf T1 55 Darmstadt T1 44 Darmstadt T2 33 Darmstadt T1 22 Frankfurt 42 Fragen: Welche funktionalen Abhängigkeiten ergeben sich aus dem Text? Ist das Relationenschema in 3NF? Wenn nein: Zerlegen Sie das Schema so, dass anschließend ausschließlich 3NF-Schemata vorhanden sind. Alternative Vorgehensweise: Erstellen Sie ein ER-Diagramm, das den gleichen Sachverhalt ausdrückt und entwickeln Sie daraus Relationenschemata. 30

31 Normalformen (Kritik und praktische Relevanz) Es gibt noch weitere Normalformen (4., 5., Boyce-Codd, konjunktive, Projektion-Verbund), die jedoch in der Praxis weniger relevant sind. Kritik an der Normalisierung wird mitunter geübt. Es wird behauptet: Normalisierung erfordert mehr Speicherplatz. Diese Aussage ist falsch, auch wenn mehr Relationen benötigt werden. Diese sind jedoch kleiner. Normalisierte Relationen sind umständlicher zu handhaben, weil man die Inhalte über so viele Tabellen verteilt. Diese Aussage ist falsch, da es gute Konzepte gibt (z.b. Views), die es ermöglichen, dem Anwender eine einfache Handhabung mit der Menge der Tabellen zu ermöglichen. Normalisierte Tabellen reduzieren die Laufzeit-Performance, da man häufiger einen Vebund zwischen vielen Tabellen vornehmen muss. Dies Aussage ist korrekt, so dass man nach kompletter Normalisierung mitunter eine gezielte Denormalisierung vornimmt, bei der diejenigen Relationen, für die die negativen Auswirkungen der Nicht-Normalisierung (nahezu) ausgeschlossen werden können, wieder zusammengefasst werden. 31 In der Regel wird heute die 3. Normalform verwendet, um die Anomalien zu vermeiden. Bei zu hohem Performance-Verlust, der auf die Normalisierung zurückzuführen ist, wird in seltenen Fällen denormalisiert. Bei Neu-Entwicklungen von Datenbanken versucht man, die Anomalien dadurch zu vermeiden, dass man ein gutes EERM entwirft, bevor man die Relationenschemata erstellt.

32 3. Normalform (Aufgabe) Die folgenden Attribute seien alle in einem Relationenschema zusammengefasst: Kontonummer (K), PLZ (P), Ort (O), Filialnummer (F), Bankname (N), Bankleitzahl (L). Die Attribute hängen folgendermaßen voneinander ab. Durch die Bankleitzahl wird der Bankname festgelegt. Die Postleitzahl legt den Ort fest. Die Filialnummer und die Kontonummer hängen vom Banknamen ab. 1. Zeichnen Sie alle funktionalen Abhängigkeiten auf. Benutzen Sie dabei die Buchstaben in Klammern. 2. Ermitteln Sie den Schlüssel zu dem Relationenschema 3. Begründen Sie, warum das Relationenschema nicht in 2. und nicht in 3. Normalform ist. 4. Zerlegen Sie das Relationenschema in Relationenschemata so, dass diese alle in 3. Normalform sind. 32