Datenbankdesign - Normalisierung

Transkript

1 1 Datenbankdesign - Normalisierung In einer Datenbank sollen Daten einer realen Welt abgebildet werden. Dazu ist es notwendig, die Struktur des zu bearbeitenden Teilausschnittes in einem möglichst getreuen Modell darzustellen. Es gibt zwei grundlegende Methoden die dazu dienen, einen Teilausschnitt der realen Welt zu modellieren und für die Darstellung in einer Datenbank aufzubereiten. Das Ergebnis der Modellierung ist eine Menge von Relationen mit zugehörigen Attributen. Diese können dann in die jeweilige Struktur der Datenbank transformiert werden. Die hier dargestellte Methode ist die Normalisierung. Die Methode der Entity- Relationship-Modellierung soll hier nur erwähnt werden. Beide Methoden unterscheiden sich in der Vorgehensweise. Das Entity-Relationship-Modell ist eine Top-Down-Methode (von oben nach unten). Sie wird eingesetzt, wenn die Menge der Attribute noch nicht klar ist, oder die Datenbank mehrere hundert Attribute enthalten soll. Die Normalisierung wird eingesetzt, wenn die Attribute und deren Abhängigkeiten bekannt sind, und daraus die Relationen entwickelt werden sollen. Das heißt, es wird von der untersten Ebene ausgegangen und zur obersten Ebene hin gearbeitet. Diese Vorgehensweise wird Bottom-Up (von unten nach oben) genannt. Unter Normalisierung versteht man das Aufteilen von Attributen in Relationen, so dass diese den Normalisierungsregeln entsprechen. Warum ist das notwendig? Durch die Normalisierung entstehen Relationen, die Keine überflüssigen Redundanzen enthalten Damit wird zum einen der Aufwand bei Änderungen in der Datenmenge reduziert. Eine Kundenadresse muss nur einmal verändert werden, und nicht an verschiedenen Stellen mehrfach. Zum anderen wird das Speichervolumen der Daten minimiert, wenn Werte nur einmal abgespeichert werden, und nicht x-mal. Frei von Update-Anomalien sind Unter Update-Anomalien versteht man nicht beabsichtigte Auswirkungen auf

2 2 die Daten bei Änderungsoperationen (Einfügen, Ändern, Löschen). Die Notwendigkeit der Umstrukturierung von Relationen verringern Bevor die Datenbank aufgebaut werden kann, muss die Struktur in Form von Relationen und ihrer Attribute festgelegt sein. Diese sollte so definiert werden, dass spätere Änderungen nicht mehr notwendig sind. Damit sind dann auch entsprechende Anwendungsprogramme bezüglich der verwendeten Datenstrukturen nicht so änderungsanfällig. Es gibt heute mehr als fünf Normalisierungsregeln, die aber in der Praxis nicht alle von Bedeutung sind. Diese fünf bauen hierarchisch aufeinander auf: 1NF, 2NF, 3NF, 4NF, 5NF, wobei NF für Normalform und BCNF für Boyce/Codd Normalform stehen. In jeder Normalisierungsstufe werden die Relationen auf bestimmte Merkmale hin untersucht. Erfüllt eine Relation diese Anforderungen nicht, wird sie normalisiert. Das heißt, sie wird so zerlegt, dass die entstehenden Teilrelationen die Bedingungen erfüllen. Erste Normalform Eine Relation ist in der ersten Normalform, wenn alle Attribute nur einen Wert enthalten. D.h., in jedem Feld darf nur ein Wert stehen und jeder Satz hat eine feste Länge. Zweite Normalform Eine Relation ist in der zweiten Normalform, wenn sie sich in der ersten Normalform befindet und jede Attribut, das nicht zum Schlüssel gehört, vom gesamten Schlüssel abhängig ist Es darf kein Attribut geben, das nur von einem Teil des Schlüssels abhängig ist. Unter Abhängigkeit versteht man, dass zu einem Wert des einen Attributes genau ein Wert des anderen Attributs (oder Schlüssel) gehört. Zum Beispiel ist das Einstellungsdatum eines Angestellten abhängig von diesem (Namen oder Personalnummer). Dritte Normalform Eine Relation ist in der dritten Normalform, wenn sie sich in der zweiten Normalform befindet und es keine Abhängigkeiten zwischen Attributen gibt, die nicht zum Schlüssel gehören. Sie würde diese Anforderung nicht erfüllen, wenn z.b. das Attribut Einstellungsdatum vom Attribut Name abhängig wäre und beide Attribute nicht im Schlüssel enthalten sind.

3 3 Um diese Regeln zu verdeutlichen, werden im folgenden Abschnitt die Relationen eines Beispiels zur Auftragsverwaltung betrachtet: Anhand einer Beispielwelt wird die Vorgehensweise bei der Normalisierung dargestellt. Die Beispielwelt ist ein Ausschnitt aus der Auftragsverwaltung Ausgangspunkt ist eine Firma, die Sportartikel vertreibt. Sie hat einen Kundenstamm, an den sie eine Reihe von Produkten verkauft. Die Kunden bestellen die Ware bei der Firma über Aufträge. Ein Auftrag kann mehrere Positionen umfassen. Pro Position wird ein bestimmter Artikel in der zu bestellenden Menge angegeben. Das heißt, dass pro Auftrag verschiedene Produkte bestellt werden können. Ein Produkt hat keinen festen Preis. Der Preis pro Produkt gilt immer nur für einen bestimmten Zeitraum. Dabei kann zu einem Zeitpunkt nur genau ein Preis aktuell sein. Aus dieser Beschreibung ergeben sich folgende Ausgangsrelationen: Ausgangslage: Aufträge: AuftragsNr KundenNr BestellDatum LieferDatum RechnungsNr Kommentar PositionsNr Verkaufspreis Menge Produkte: Bezeichnung Beschreibung Listenpreis Mindestpreis

4 4 PreisGültigAb PreisGültigBis Kunden: KundenNr KundenName Ort Straße Kreditrahmen Diese drei Relationen müssen nun anhand der oben gegebenen Normalformdefinitionen untersucht werden. Erste Normalform Hier muss geprüft werden, ob die Werte der einzelnen Attribute der Relation mehr als einen Wert enthalten können. Aufträge Als Beispielwerte können dienen: Auftra gnr Kunde nnr Bestell Datum Liefer Datum Rechnun gsnr Komment ar Positions Nr Produk tnr Kunde npreis Meng e ,90 15 Daraus ist ersichtlich, dass keines der Attribute mehr als einen Wert enthält. Das heißt, alle Attribute sind atomar und die Sätze haben eine feste Länge, d.h. es existieren keine Wiederholungsgruppen. Die Relation Aufträge ist deshalb in der 1.NF. Produkte Als Beispielwerte dienen hierzu: Produkt Nr Bezeichnung Beschreibung ListenPrei s MindestPre is PreisGültigA b PreisGültigB is

5 Kaisers Schlittschuh e Herren keine Sonderkondition en 99,90 78, Auch hier sind in allen Attributen nur einzelne Werte angegeben. Die drei Wörter Kaisers Schlittschuhe Herren des Attributs Bezeichnung stellen einen Wert dar und nicht drei verschiedene Wertebelegungen. Damit ist auch diese Relation in der 1.NF, Kunden Beispielwerte hierzu sind: KundenNr KundenName Ort Straße KreditRahmen 100 Inter Sport Düsseldorf Bilker Allee Jedes Attribut enthält nur einen Wert. Auch hier gilt wieder, dass die Werte Inter Sport und Bilker Allee 120 in sich immer nur einen Wert verkörpern, und nicht zwei bzw. drei verschiedene Werte. Die Relation Kunden ist in der 1.NF, Zweite Normalform Für die 2.NF muss getestet werden ob alle Attribute der Relation, die nicht zum Schlüssel gehören, vom gesamten Schlüssel abhängig sind oder nur von einem Teil des Schlüssels. Dazu müssen zuerst einmal die Primärschlüssel (oben nur Schlüssel genannt) bekannt sein. Aufträge Zum Schlüssel gehören die Attribute AuftragsNr und PositionsNr, da jede einzelne Position innerhalb eines Auftrags eindeutig identifizierbar sein muss. Betrachtet man nun die einzelnen Attribute in Bezug auf ihr Verhältnis zu den beiden Schlüsselattributen, so fällt auf, dass die Attribute KundenNr, BestellDatum, LieferDatum, RechnungsNr und Kommentar nur von der AuftragsNr abhängen, aber nicht von der PositionsNr. Für alle Positionen eines Auftrages sind diese Daten gleich. Deshalb ist die Relation Aufträge nicht in der 2.NF. Um dies zu erreichen, muss die Relation normalisiert werden, d.h. sie muss zerlegt werden. Da die oben genannten Attribute nicht von der PositionsNr abhängig sind, teilt man die Relation einfach in zwei Relationen auf: eine Relation, bei der alle

6 6 Attribute von AuftragsNr und PositionsNr abhängig sind und eine andere, bei der die Attribute nur an die AuftragsNr geknüpft sind. Damit ergeben sich: Aufträge: AuftragsNr KundenNr BestellDatum LieferDatum RechnungsNr Kommentar Positionen: PositionsNr Verkaufspreis Menge Der Schlüssel der Relationen setzt sich aus den Attributen AuftragsNr und PositionsNr zusammen. Alle Attribute dieser Relation sind von beiden Schlüsseln abhängig. Diese Relation ist deshalb in der 2.NF. In der Relation Aufträge besteht der Schlüssel nur aus der Spalte AuftragsNr. Sie ist schon deshalb in der 2.NF, da es keine Möglichkeit gibt, dass die anderen Attribute von wenigem als diesem Schlüssel abhängig sind. Produkte Der Schlüssel der Relation Produkte besteht aus den Attributen und PreisGültigAb, da für jedes Produkt in Abhängigkeit vom Datum unterschiedliche Preise vorgegeben sind. Da die Attribute Bezeichnung und Beschreibung nur von der abhängig sind, nicht aber vom PreisGültigAb, befindet sich diese Relation nicht in der 2.NF. Daraus folgt, dass sie normalisiert werden muss. Aus der Relation Produkte ergeben sich die beiden Relationen:

7 7 Produkte: Bezeichnung Beschreibung Preise: ListenPreis MindestPreis Menge PreisGültigAb PreisGültigBis Der Schlüssel der Relation Produkte wird durch das Attribut gebildet. Bei Preise setzt sich der Schlüssel aus und PreisGültigAb zusammen. Damit sind beide Relationen in der 2. NF. Kunden Den Schlüssel der Relation Kunden ist die KundenNr. Da der Schlüssel nur aus einem Attribut besteht, ist diese Relation on der 2.NF: Dritte Normalform Die Relationen sind in der 3.NF, wenn sie in der 2.NR sind und es keine Abhängigkeiten zwischen den Attributen gibt, die nicht zum Schlüssel gehören. Aufträge Die Relation Auftrage befindet sich in der 3. NF, da es keine Abhängigkeiten zwischen den Attributen gibt.

8 8 Positionen Diese Relation ist in der 3. NF, da es keine Abhängigkeiten zwischen, VerkaufsPreis und Menge gibt. Aus der selbst kann z.b. nicht der VerkaufsPreis abgeleitet werden. Produkte Die Relation Produkte befindet sich in der 3. NF, da es keine Abhängigkeiten zwischen den Attributen gibt. Preise Die Relation Preise ist ebenfalls in der 3. NF. Es gibt keine Abhängigkeiten zwischen den Attributen ListenPreis, MindestPreis und PreisGültigBis. Kunden Da es auch hier keine Abhängigkeiten zwischen den Attributen gibt, ist diese Relation in der 3. NF. Damit soll dieses Beispiel zur Illustration der Normalisierung abgeschlossen sein. In der Praxis wird aus den schon vorne genannten Gründen kaum über die 3. NF hinaus normalisiert. Merksatz: The key, the whole key and nothing but the key - so help me Codd.