no way to compare when less than two revisions

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

@@ Zeile 1: / Zeile 1: @@
+=====1. Normalform=====
+Die Grundzüge und Methoden der Datenbankmodellierung sind uns bekannt. Trotz Beachtung der bisherigen Entwurfsmuster kann es noch zu ungeeigneten Modellierungen kommen. Gemäß der Erkenntnis, dass nichts praktischer ist als eine gute Theorie, setzen wir uns daher mit den Normalformen auseinander.
+**Beispiel 1:**
+Die ER-Modellierung eines Schulverwaltungssystems hat unter vielen anderen Relationen folgende Schülertabelle erbracht:
+{{nf01.png}}
+**Beispiel 2:**
+Eine Datenbank zur Projektwochenverwaltung enthält folgende Angaben:
+{{nf02.png}}
+**Aufgabe**
+a) Analysiere die verschiedenen Probleme, die es mit diesen Relationen geben kann. Was sind die Ursachen dieser Probleme?\\
+b) Welche Änderungen sollten am Entwurf vorgenommen werden?
+**Lösung**
+In Beispiel 1 sind Name und Adresse zusammen gesetzte Attribute. Beim Namen ist nicht unbedingt erkennbar, was der Vorname und was der Nachname ist. Für ein Anschreiben an die Erziehungsberechtigten wird in der Regel der Vorname des Schülers benötigt. Er kann nicht direkt aus der Datenbank entnommen werden. Ähnliche Probleme gibt es bei der Adresse. Zumindest muss in Straße/Hausnummer und PLZ/Ort getrennt werden, um diese Daten in einen Serienbrief übernehmen zu können.
+Beim zweiten Beispiel sind die Angaben zu den Teilnehmern und zur Zielgruppe nicht atomar. Teilnehmer kann man aufteilen in Min und Max und das Projekt Breakdance kann – ohne eine neue Tabelle anlegen zu müssen – dreimal mit jeweils unterschiedlicher Zielgruppe in die Tabelle eingetragen werden.
+====1. Normalform – Atomare Attribute====
+<WRAP box round>
+Eine Relation ist in 1. Normalform, wenn alle Attributwerte atomar sind.
+</WRAP>
+**Normalisierung**
+. Erweitere die Relation um Spalten. Zerlege die zusammen gesetzten Attribute der Relation in Einzel-Attribute.\\
+Name: Vorname, Nachname\\
+Adresse: Straße_Nr, PLZ_Ort\\
+oder\\
+. Erweitere die Relation um Zeilen. Ergänze bei Attributenwerten mit mehreren Einzelangaben für jeden Einzelwert eine Zeile in der Relation (vgl. nächstes Beispiel).
+=====2. Normalform=====
+Ein Musikfreund hatte für seine CD-Verwaltung zunächst folgende Relation angelegt:
+{{nf03.png}}
+Um diese Relation auf die 1. Normalform zu bringen, hat er sie in folgende Form gebracht:
+{{nf04.png}}
+**Aufgabe**
+a) Welche Probleme gibt es mit dieser neuen Relation?\\
+b) Was ist ein Primärschlüssel der Relation?\\
+c) Wie können die Probleme aus a) behoben werden?
+====Funktionale Abhängigkeit====
+In einer Relation nennt man das Attribut B von einer Attributmenge A funktional abhängig, wenn zu jedem Wert von A genau ein Wert von B gehört. Im Sinne der Mathematik kann man den Zusammenhang zwischen A und B als Funktion f interpretieren f: A &rarr; B. Die funktionalen Abhängigkeiten ergeben sich aus dem sachlogischen Zusammenhang der modellierten Mini-Welt.
+Die Probleme in der CD-Verwaltung rühren daher, dass die Attribute Band und Album nicht vom Primärschlüssel {CD_ID, Titel} sondern schon allein von der CD_ID funktional abhängig sind.
+{{nf05.png}}
+Hinweis: Im Bild sind die Attribute des Primärschlüssels mit einem Oval zusammen gefasst.
+====2. Normalform - partielle funktionale Abhängigkeit====
+<WRAP box round>
+Eine Relation ist in 2. Normalform, wenn sie in 1. Normalform ist und kein Attribut partiell
+vom Primärschlüssel funktional abhängig ist.
+</WRAP>
+**Normalisierung**\\
+Beseitige die partielle Abhängigkeit durch Zerlegung in zwei Relationen. Die partiell abhängigen Attribute werden in eine eigene Relation ausgelagert, zusammen mit dem Teilschlüssel, vom dem sie funktional abhängig sind, als Primärschlüssel.
+<WRAP pre>
+CD(__CD_ID__, Band, Album)\\
+CDTitel(__CD_ID__, __Titel__)
+</WRAP>
+**Aufgabe**\\
+Begründe, dass die oben erkannten Probleme jetzt behoben sind.
+**Hinweis**\\
+Eine partielle Abhängigkeit kann nur vorkommen, wenn sich der Primärschlüssel aus mehreren Attributen zusammensetzt. Durch Einführung eines zusätzlichen organisatorischen Attributs wie CD_ID, Schülernummer o. ä. kann man Primärschlüssel aus einem einzigen Attribut einführen. Relationen mit solchen Primärschlüsseln sind immer in 2. Normalform, weil partielle Abhängigkeiten offensichtlich nicht mehr möglich sind.
+=====3. Normalform=====
+Der  Musikfreund möchte seine CD-Tabelle um das Gründungsjahr der Band erweitern und erhält jetzt folgende Tabelle:
+{{nf06.png}}
+**Aufgabe**\\
+Bestimme einen Primärschlüssel und analysiere die funktionalen Abhängigkeiten.
+**Lösung**\\
+Diese Relation befindet sich in der 2. Normalform. Dennoch werden Informationen redundant gespeichert: das Gründungsjahr einer Band wird für jedes Album einer Band gespeichert. Das kann leicht zu Dateninkonsistenzen führen, weil z. B. für eine Band verschiedene Gründungsjahre gespeichert werden. Die Ursache des Problems liegt darin begründet, dass das Gründungsjahr transitiv vom Primärschlüssel abhängt.
+{{nf07.png}}
+====3. Normalform - transitive funktionale Abhängigkeit====
+<WRAP box round>
+Eine Relation ist in 3. Normalform, wenn sie in 2. Normalform ist und keine
+transitiven funktionalen Abhängigkeiten vorliegen.
+</WRAP>
+**Normalisierung**\\
+Beseitige die transitive Abhängigkeit durch Zerlegung in zwei Relationen. Die erste Relation enthält den Primärschlüssel und alle direkt davon abhängigen Attribute. Die zweite Relation besteht aus den transitiv abhängigen Attributen, zusammen mit den Attributen, von denen sie funktional abhängig sind.
+<WRAP pre>
+CD(__CD_ID__, Band, Album)
+Banddaten(__Band__, Gründungsjahr)
+</WRAP>
+=====Aufgaben=====
+**Normalisierung einer Büchertabelle**\\
+Für eine Schulbibliothek wurde folgende Büchertabelle entworfen:
+{{nf08.png}}
+a) Bringe die Relation durch Ergänzung weiterer Datensätze auf die erste Normalform.\\
+b) Was ist der Schlüssel der modifizierten Relation?\\
+c) Analysiere die funktionalen Abhängigkeiten und stelle sie grafisch dar.\\
+d) Bringe die Relation durch Normalisierung auf die 2. Normalform.\\
+e) Erzeuge durch Zerlegung in weitere Relationen die 3. Normalform.\\
+**Unterricht-Lehrer-Relation**
+{{FD2.png}}
+a) Analysiere die hier dargestellte Relation.\\
+b) Gib einen geeigneten Primärschlüssel für diese Relation an.\\
+c) Analysiere die in der Relation vorkommenden funktionalen Abhängigkeiten und stelle sie grafisch dar.\\
+d) Normalisiere die Relation, d. h. zerlege sie in Relationen, die der dritten Normalform genügen.\\
+**Patientenverwaltung**\\
+Der Chefarzt schlägt folgende Patiententabelle vor: Patient(P#, Name, GebDatum, Untersuchungsdatum, Adresse, Größe, Gewicht, Blutdruck, Diagnose, Therapie, Diagnose, Therapie, Belegung).
+Ein Patient kann mehrmals behandelt werden. Beim Blutdruck sind der systolische und der diastolische zu unterscheiden. Bei der Belegung sind diese Angaben wichtig: Privat- bzw. Kassenpatient, RaumNr, Station und Zimmerkategorie.
+a) Bringe die Relation auf die 1. Normalform. \\
+b) Analysiere die funktionalen Abhängigkeiten und stelle sie grafisch dar.\\
+c) Beseitige erst die partiellen, dann die transitiven Schlüsselabhängigkeiten, um die 3. Normalform zu erreichen.