Normalformen: Unterschied zwischen den Versionen

Aus IV1
Keine Bearbeitungszusammenfassung
K Textersetzung - „mussswiki.idv.edu“ durch „mussswiki.idb.edu“
 
(17 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
<!--<yambe:breadcrumb>Datenbanken|Datenbanken</yambe:breadcrumb>-->
<div class='noprint'><yambe:breadcrumb>Datenbanken|Datenbanken</yambe:breadcrumb></div>
{{Kurzform|Der Aufbau relationaler Datenbanken, ersichtlich in den Inhalten ihrer Tabellen und deren Beziehungen untereinander, zielt in erster Linie auf die Vermeidung von Redundanzen ab. Sogenannte Normalformen können als Gesetze zur Konstruktion von Tabellen betrachtet werden, deren Einhaltung zur weitgehenden Vermeidung von Redundanzen führen. Die Normalformen sind Gegenstand des folgenden Lernschrittes.}}
{{Kurzform|Der Aufbau relationaler Datenbanken, ersichtlich in den Inhalten ihrer Tabellen und deren Beziehungen untereinander, zielt in erster Linie auf die Vermeidung von Redundanzen ab. Sogenannte Normalformen können als Gesetze zur Konstruktion von Tabellen betrachtet werden, deren Einhaltung zur weitgehenden Vermeidung von Redundanzen führen. Die Normalformen sind Gegenstand des folgenden Lernschrittes.}}


Zeile 13: Zeile 13:
* Wie viele Spalten sollen in welcher Tabelle angelegt werden?
* Wie viele Spalten sollen in welcher Tabelle angelegt werden?


Die Antwort auf diese Fragen gibt mitunter die sogenannte '''Normalisierung'''. Mit Hilfe der Regeln der Normalisierung wird es möglich, die Datenbank ideal zu strukturieren. Dadurch werden '''Redundanzen''' vermieden: Diese erfordern nämlich nicht nur einen größeren Speicherbedarf, sondern führen auch zu einer erhöhten Fehleranfälligkeit, beispielsweise bei Wartungstätigkeiten. Sollen Daten, die an mehr als einem Speicherort vorhanden sind, geändert werden, müssen diese Änderungen an allen Speicherorten auf exakt die gleiche Art und Weise vorgenommen werden. So ist beispielsweise die Änderung einer Studentenadresse wesentlich einfacher, wenn die betreffenden Daten nur in der Tabelle ''Student'' gespeichert sind und nicht auch noch an anderen Orten innerhalb der Datenbank.
Die Antwort auf diese Fragen gibt mitunter die sogenannte '''Normalisierung'''. Mit Hilfe der Regeln der Normalisierung wird es möglich, die Datenbank ideal zu strukturieren. Dadurch werden '''Redundanzen''' vermieden: Diese erfordern nämlich nicht nur einen größeren Speicherbedarf, sondern führen auch zu einer erhöhten Fehleranfälligkeit, beispielsweise bei Wartungstätigkeiten. Sollen Daten, die an mehr als einem Speicherort vorhanden sind, geändert werden, müssen diese Änderungen an allen Speicherorten auf exakt die gleiche Art und Weise vorgenommen werden. So ist beispielsweise die Änderung einer Kundenandresse wesentlich einfacher, wenn die betreffenden Daten nur in der Tabelle ''Kunde'' gespeichert sind und nicht auch noch an anderen Orten innerhalb der Datenbank.


== Normalisieren der Tabellen ==
== Normalisieren der Tabellen ==


Bei der Überführung der Objektklassen in Tabellen sind diese daraufhin zu prüfen, ob sie Abhängigkeiten der Felder untereinander bzw. Redundanzen aufweisen, die meist zu Disintegritäten führen. Normalisiert wird, indem man schrittweise überprüft, ob die gebildeten Tabellen den Bedingungen der Normalformen entsprechen. Im Verlaufe dieses Normalisierungsprozesses kommt es zu einer Reduzierung der Redundanzen, parallel dazu jedoch auch zu einer Vermehrung der Anzahl der Tabellen. Immer dann, wenn Redundanzen entdeckt werden, führt dies zur Bildung neuer Tabellen, die über die Schlüsselfelder miteinander verbunden werden (siehe [[Beziehungen in Datenbanken]]). Die Anpassung der Tabellen an die Normalformen dient auch der mengentheoretischen Grundlage von SQL. Die Anwendung von drei Normalformen wird aus Gründen des Antwortzeitverhaltens der Datenbank empfohlen. Es gibt zwar insgesamt fünf Normalformen, aber die vierte Normalform, die auch als Boyce Codd-Normalform (BCNF) bezeichnet wird, sowie die fünfte Normalform werden in der Praxis nur selten angewendet.
Bei der Überführung der Objektklassen in Tabellen sind diese daraufhin zu prüfen, ob sie Abhängigkeiten der Felder untereinander bzw. Redundanzen aufweisen. Normalisiert wird, indem man schrittweise überprüft, ob die gebildeten Tabellen den Bedingungen der Normalformen entsprechen. Im Verlauf dieses Normalisierungsprozesses kommt es zu einer Reduzierung der Redundanzen, parallel dazu jedoch auch zu einer Vermehrung der Anzahl der Tabellen. Immer dann, wenn Redundanzen entdeckt werden, führt dies zur Bildung neuer Tabellen, die über die Schlüsselfelder miteinander verbunden werden (siehe [[Beziehungen in Datenbanken]]). Die Anpassung der Tabellen an die Normalformen dient auch der mengentheoretischen Grundlage von SQL. Die Anwendung von drei Normalformen wird aus Gründen des Antwortzeitverhaltens der Datenbank empfohlen. Die Datenbanktheorie unterscheidet zwar weitere Normalformen, diese werden aber in der Praxis nur selten angewendet.


== Erste Normalform: Entfernen von Wiederholgruppen ==
== Erste Normalform: Entfernen von Wiederholgruppen ==


Jedes Feld darf im Datensatz '''nur einmal''' vorkommen. Gibt es mehrere Felder vom '''gleichen Typ''', so müssen diese in einer '''eigenen Relation''' gespeichert werden.
Jedes Feld darf im Datensatz '''nur einmal''' vorkommen. Gibt es mehrere Felder vom '''gleichen Typ''', so müssen diese in einer '''eigenen Tabelle''' gespeichert werden.


Die Überführung der Objektklasse ''Auftrag'' in eine Tabelle (Relation) könnte der verbalen Beschreibung des Geschäftsmodells entsprechend „Jeder Auftrag kann mehrere Bücher enthalten, die jeweils in beliebiger Menge geordert werden können“ bzw. in Anlehnung an das ER-Diagramm folgende Struktur aufweisen:
Die Überführung der Objektklasse ''Auftrag'' in eine Tabelle könnte der verbalen Beschreibung des Geschäftsmodells entsprechend „Jeder Auftrag kann mehrere Bücher enthalten, die jeweils in beliebiger Menge geordert werden können“ bzw. in Anlehnung an das ER-Diagramm folgende Struktur aufweisen:


* ''Auftrag'' (Nr, Kundennummer, Datum, Positionsnummer, Buchnummer, Menge, Positionsnummer, Buchnummer, Menge, ...)
* ''Auftrag'' (Nr, Kundennummer, Datum, Positionsnummer, Buchnummer, Menge, Positionsnummer, Buchnummer, Menge, ...)


Da ein Auftrag in der Regel mehrere unterschiedliche Bücher in unterschiedlichen Mengen enthält, kommen die Felder ''Positionsnummer'', ''Buchnummer'' und ''Menge'' mehrfach vor, was der 1. Normalform widerspricht.
Da ein Auftrag in der Regel mehrere unterschiedliche Bücher in unterschiedlichen Mengen enthält, kommen die Felder ''Buchnummer'' und ''Menge'' mehrfach vor, was der ersten Normalform widerspricht. Die Konsequenz daraus ist die Auslagerung der Wiederholgruppen in eine eigene Tabelle ''Auftragspos'' (abgeleitet von Auftragsposition) und die Verbindung der Tabellen über entsprechende Schlüsselfelder.
Die Konsequenz ist demnach die Auslagerung der Wiederholgruppen in eine eigene Tabelle ''Auftragspos'' (abgeleitet von Auftragsposition) und die Verbindung der Tabellen über die Schlüsselfelder.


[[Bild:Datenmodell_3.gif]]
[[Bild:Datenmodell_3.gif]]


Das Feld ''Nr'' in der Tabelle ''Auftrag'' (''Auftrag.Nr'') ist Schlüsselfeld der Tabelle ''Auftrag'' und wird daher mit dem Feld ''Auftragspos.Auftragsnummer'' verbunden. Die Namen der beiden Felder unterscheiden sich zwar, aber der Inhalt ist in beiden Fällen ident. Hier zeigt sich eine unvermeidbare Redundanz in relationalen Datenbanken, weshalb man auch von '''kontrollierter Redundanz''' und nicht von redundanzfrei spricht.
Das Feld ''Nr'' in der Tabelle ''Auftrag'' (''Auftrag.Nr'') ist das Schlüsselfeld der Tabelle ''Auftrag'' und wird daher mit dem Feld ''Auftragsnummer'' der Tabelle Auftragsposition verbunden. Die Namen der beiden Felder unterscheiden sich zwar, aber der Inhalt ist in beiden Fällen ident. Hier zeigt sich eine unvermeidbare Redundanz in relationalen Datenbanken, weshalb man auch von '''kontrollierter Redundanz''' und nicht von redundanzfrei spricht.


Für die Erfüllung der im (detaillierten) Geschäftsmodell beschriebenen Aufgaben (z. B. Rechnungslegung) sind detaillierte Daten über die Bücher (z. B. der Preis) erforderlich. Wie auch aus dem ER-Diagramm ersichtlich ist, gibt es eine Verbindung zwischen der Tabelle ''Auftrag'' und der Tabelle ''Buch'' über die neu gebildete Tabelle ''Auftragspos''. Die Notwendigkeit zur Neubildung einer Tabelle zwischen ''Auftrag'' und ''Buch'' ist auch aus ihrer m:n-Beziehung ableitbar.
Für die Erfüllung der im Geschäftsmodell beschriebenen Aufgaben (z. B. Rechnungslegung) sind detaillierte Daten über die Bücher (z. B. der Preis) erforderlich. Wie auch aus dem ER-Diagramm ersichtlich ist, gibt es eine Verbindung zwischen der Tabelle ''Auftrag'' und der Tabelle ''Buch'' über die neu gebildete Tabelle ''Auftragspos''. Die Notwendigkeit zur Neubildung einer Tabelle zwischen ''Auftrag'' und ''Buch'' ist auch aus ihrer m:n-Beziehung ableitbar.


[[Bild:Datenmodell_4.gif]]
[[Bild:Datenmodell_4.gif]]
Zeile 44: Zeile 43:
Zu den Bedingungen der 1. Normalform gilt zusätzlich: In Relationen mit einem Kombinationsschlüssel muss jedes Feld vom gesamten Kombinationsschlüssel abhängen. Felder, die nur von einem Teil des Schlüssels abhängen, werden mit diesem als Schlüssel in einer eigenen Relation gespeichert.
Zu den Bedingungen der 1. Normalform gilt zusätzlich: In Relationen mit einem Kombinationsschlüssel muss jedes Feld vom gesamten Kombinationsschlüssel abhängen. Felder, die nur von einem Teil des Schlüssels abhängen, werden mit diesem als Schlüssel in einer eigenen Relation gespeichert.


Die Tabelle ''Auftragspos'' besitzt einen Kombinationsschlüssel, wie in der Abbildung zuvor ersichtlich ist. Da aber der Entwurf der vorliegenden Datenbank mit der (korrekten?) Erstellung eines ER-Diagramms begonnen hat, befinden sich in dieser Tabelle keine Felder, die der 2. Normalform widersprechen. Es können jedoch in Frage kommende Erweiterungen der gegenständlichen Tabelle als Erläuterung am Beispiel herangezogen werden.
Die Tabelle ''Auftragspos'' besitzt einen Kombinationsschlüssel, wie in der Abbildung zuvor ersichtlich ist. Da aber der Entwurf der vorliegenden Datenbank mit der Erstellung eines ER-Diagramms begonnen hat, befinden sich in dieser Tabelle keine Felder, die der 2. Normalform widersprechen. Es können jedoch in Frage kommende Erweiterungen der gegenständlichen Tabelle als Erläuterung am Beispiel herangezogen werden.


Geht man z. B. davon aus, dass nicht alle Positionen eines Auftrags sofort geliefert werden können und sind Teillieferungen geplant, so wäre das Datum der Auslieferung (wohlgemerkt der gesamten bestellten Menge, keine Teilmengen) ein Feld, welches die Bedingung der 2. Normalform erfüllte.
Geht man z. B. davon aus, dass nicht alle Positionen eines Auftrags sofort geliefert werden können und sind Teillieferungen geplant, so wäre das Datum der Auslieferung (wohlgemerkt der gesamten bestellten Menge, keine Teilmengen) ein Feld, welches die Bedingung der 2. Normalform erfüllte.
Zeile 50: Zeile 49:
Für den Fall, dass Preisnachlässe in Form von Rabatten gewährt werden, könnte ein weiteres Feld mit der Bezeichnung ''Rabatt'' angefügt werden. Diese Art der Gewährung von Rabatten bedeutet, dass der Preisnachlass einmalig und nur für ein bestimmtes Produkt gewährt wird. Ebenso könnte ein Feld ''Rabatt'' der Tabelle ''Buch'', der Tabelle ''Kunde'' oder der Tabelle ''Auftrag'' angefügt werden, ohne die Normalformen zu verletzen. Die Bedeutung der alternativen Platzierung ist jedoch sehr unterschiedlich. Das Feld ''Rabatt'' in der Tabelle ''Kunde'' bewirkt, dass alle Einkäufe des jeweiligen Kunden mit einem Preisnachlass versehen werden, während das besagte Feld in der Tabelle ''Buch'' Preisnachlässe für alle Kunden nach sich zieht.
Für den Fall, dass Preisnachlässe in Form von Rabatten gewährt werden, könnte ein weiteres Feld mit der Bezeichnung ''Rabatt'' angefügt werden. Diese Art der Gewährung von Rabatten bedeutet, dass der Preisnachlass einmalig und nur für ein bestimmtes Produkt gewährt wird. Ebenso könnte ein Feld ''Rabatt'' der Tabelle ''Buch'', der Tabelle ''Kunde'' oder der Tabelle ''Auftrag'' angefügt werden, ohne die Normalformen zu verletzen. Die Bedeutung der alternativen Platzierung ist jedoch sehr unterschiedlich. Das Feld ''Rabatt'' in der Tabelle ''Kunde'' bewirkt, dass alle Einkäufe des jeweiligen Kunden mit einem Preisnachlass versehen werden, während das besagte Feld in der Tabelle ''Buch'' Preisnachlässe für alle Kunden nach sich zieht.


Diese Variationsmöglichkeiten zeigen deutlich, dass die formale Korrektheit einer relationalen Datenbank nicht ohne das zu Grunde liegende Geschäftsmodell überprüft werden kann.
Diese Variationsmöglichkeiten zeigen deutlich, dass die formale Korrektheit einer relationalen Datenbank nicht ohne das zugrundeliegende Geschäftsmodell bzw. deren Prozesse überprüft werden kann.


== Dritte Normalform: Vermeidung von transitiven Abhängigkeiten ==
== Dritte Normalform: Vermeidung von transitiven Abhängigkeiten ==
Zeile 59: Zeile 58:


Berücksichtigt man die Zustellbezirke der Post, so kann festgestellt werden, dass jeder Postleitzahl eindeutig ein Zustellbezirk (zur zeitweiligen Verwirrung auch "Ort" genannt) zugeordnet werden kann. Das Feld ''Ort'' hängt demnach vom Feld ''Plz'' ab und muss ausgelagert werden.
Berücksichtigt man die Zustellbezirke der Post, so kann festgestellt werden, dass jeder Postleitzahl eindeutig ein Zustellbezirk (zur zeitweiligen Verwirrung auch "Ort" genannt) zugeordnet werden kann. Das Feld ''Ort'' hängt demnach vom Feld ''Plz'' ab und muss ausgelagert werden.
Die ohne Berücksichtigung der 3. Normalform also falsch abgeleitete Tabellen wären:
Die ohne Berücksichtigung der 3. Normalform also falsch konstruierte Tabellen wären:


* ''Verlag'' (Kurzbezeichnung, Name, Kundennummer, Strasse, Plz, Ort)
* ''Verlag'' (Kurzbezeichnung, Name, Kundennummer, Strasse, Plz, Ort)
* ''Kunde'' (Nr, Vorname, Nachname, Strasse, Plz, Ort)
* ''Kunde'' (Nr, Vorname, Nachname, Strasse, Plz, Ort)


Sie werden des Feldes ''Ort'' entledigt und es entsteht eine neue Tabelle mit der Bezeichnung ''PLZ'', die – wie soll es anders sein – über das Schlüsselfeld ''Plz'' mit ihrer ursprünglichen Heimat verbunden werden.
Adressen werden des Feldes ''Ort'' entledigt und es entsteht eine neue Tabelle mit der Bezeichnung ''PLZ'' und den Spalten Plz, Ort und Region.


Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur:
Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur:
Zeile 82: Zeile 81:


== Zitiervorschlag ==
== Zitiervorschlag ==
''Mittendorfer'' in ''Pils'', Informationsverarbeitung I (21.9.2009), Datenbanken#Überschrift (mussswiki.idv.edu/iv1)
''Mittendorfer'' in ''Höller'', Informationsverarbeitung I, Normalformen (mussswiki.idb.edu/iv1)

Aktuelle Version vom 1. Oktober 2018, 14:09 Uhr

<yambe:breadcrumb>Datenbanken|Datenbanken</yambe:breadcrumb>
Der Aufbau relationaler Datenbanken, ersichtlich in den Inhalten ihrer Tabellen und deren Beziehungen untereinander, zielt in erster Linie auf die Vermeidung von Redundanzen ab. Sogenannte Normalformen können als Gesetze zur Konstruktion von Tabellen betrachtet werden, deren Einhaltung zur weitgehenden Vermeidung von Redundanzen führen. Die Normalformen sind Gegenstand des folgenden Lernschrittes.



Der Sinn der Normalisierung

Bei der Aufgabe, eine Datenbank anzulegen, wird man mit mehreren Fragen konfrontiert.

  • Wie viele Tabellen sind sinnvoll?
  • Was soll darin dargestellt werden?
  • Wie viele Spalten sollen in welcher Tabelle angelegt werden?

Die Antwort auf diese Fragen gibt mitunter die sogenannte Normalisierung. Mit Hilfe der Regeln der Normalisierung wird es möglich, die Datenbank ideal zu strukturieren. Dadurch werden Redundanzen vermieden: Diese erfordern nämlich nicht nur einen größeren Speicherbedarf, sondern führen auch zu einer erhöhten Fehleranfälligkeit, beispielsweise bei Wartungstätigkeiten. Sollen Daten, die an mehr als einem Speicherort vorhanden sind, geändert werden, müssen diese Änderungen an allen Speicherorten auf exakt die gleiche Art und Weise vorgenommen werden. So ist beispielsweise die Änderung einer Kundenandresse wesentlich einfacher, wenn die betreffenden Daten nur in der Tabelle Kunde gespeichert sind und nicht auch noch an anderen Orten innerhalb der Datenbank.

Normalisieren der Tabellen

Bei der Überführung der Objektklassen in Tabellen sind diese daraufhin zu prüfen, ob sie Abhängigkeiten der Felder untereinander bzw. Redundanzen aufweisen. Normalisiert wird, indem man schrittweise überprüft, ob die gebildeten Tabellen den Bedingungen der Normalformen entsprechen. Im Verlauf dieses Normalisierungsprozesses kommt es zu einer Reduzierung der Redundanzen, parallel dazu jedoch auch zu einer Vermehrung der Anzahl der Tabellen. Immer dann, wenn Redundanzen entdeckt werden, führt dies zur Bildung neuer Tabellen, die über die Schlüsselfelder miteinander verbunden werden (siehe Beziehungen in Datenbanken). Die Anpassung der Tabellen an die Normalformen dient auch der mengentheoretischen Grundlage von SQL. Die Anwendung von drei Normalformen wird aus Gründen des Antwortzeitverhaltens der Datenbank empfohlen. Die Datenbanktheorie unterscheidet zwar weitere Normalformen, diese werden aber in der Praxis nur selten angewendet.

Erste Normalform: Entfernen von Wiederholgruppen

Jedes Feld darf im Datensatz nur einmal vorkommen. Gibt es mehrere Felder vom gleichen Typ, so müssen diese in einer eigenen Tabelle gespeichert werden.

Die Überführung der Objektklasse Auftrag in eine Tabelle könnte der verbalen Beschreibung des Geschäftsmodells entsprechend „Jeder Auftrag kann mehrere Bücher enthalten, die jeweils in beliebiger Menge geordert werden können“ bzw. in Anlehnung an das ER-Diagramm folgende Struktur aufweisen:

  • Auftrag (Nr, Kundennummer, Datum, Positionsnummer, Buchnummer, Menge, Positionsnummer, Buchnummer, Menge, ...)

Da ein Auftrag in der Regel mehrere unterschiedliche Bücher in unterschiedlichen Mengen enthält, kommen die Felder Buchnummer und Menge mehrfach vor, was der ersten Normalform widerspricht. Die Konsequenz daraus ist die Auslagerung der Wiederholgruppen in eine eigene Tabelle Auftragspos (abgeleitet von Auftragsposition) und die Verbindung der Tabellen über entsprechende Schlüsselfelder.

Das Feld Nr in der Tabelle Auftrag (Auftrag.Nr) ist das Schlüsselfeld der Tabelle Auftrag und wird daher mit dem Feld Auftragsnummer der Tabelle Auftragsposition verbunden. Die Namen der beiden Felder unterscheiden sich zwar, aber der Inhalt ist in beiden Fällen ident. Hier zeigt sich eine unvermeidbare Redundanz in relationalen Datenbanken, weshalb man auch von kontrollierter Redundanz und nicht von redundanzfrei spricht.

Für die Erfüllung der im Geschäftsmodell beschriebenen Aufgaben (z. B. Rechnungslegung) sind detaillierte Daten über die Bücher (z. B. der Preis) erforderlich. Wie auch aus dem ER-Diagramm ersichtlich ist, gibt es eine Verbindung zwischen der Tabelle Auftrag und der Tabelle Buch über die neu gebildete Tabelle Auftragspos. Die Notwendigkeit zur Neubildung einer Tabelle zwischen Auftrag und Buch ist auch aus ihrer m:n-Beziehung ableitbar.

Die Auftragspos.Nr der Tabelle Auftragspos ist als Primärschlüssel nicht zu gebrauchen, sie dient lediglich der Kennzeichnung der einzelnen Auftragspositionen eines Auftrages, z. B. zum Zwecke der Reihung auf Lieferscheinen oder Rechnungen. Der Primärschlüssel der Tabelle Auftragspos setzt sich vielmehr aus den Feldern Auftragspos.Auftragsnummer und Auftragspos.Buchnummer zusammen. Es handelt sich um einen Kombinationsschlüssel. Auch dieses Auftreten von Kombinationsschlüsseln ist für die normalformengerechte Auflösung von m:n-Beziehungen typisch.

Zweite Normalform: Entfernen von Attributen, die nur von einigen der identifizierenden Attribute abhängen

Zu den Bedingungen der 1. Normalform gilt zusätzlich: In Relationen mit einem Kombinationsschlüssel muss jedes Feld vom gesamten Kombinationsschlüssel abhängen. Felder, die nur von einem Teil des Schlüssels abhängen, werden mit diesem als Schlüssel in einer eigenen Relation gespeichert.

Die Tabelle Auftragspos besitzt einen Kombinationsschlüssel, wie in der Abbildung zuvor ersichtlich ist. Da aber der Entwurf der vorliegenden Datenbank mit der Erstellung eines ER-Diagramms begonnen hat, befinden sich in dieser Tabelle keine Felder, die der 2. Normalform widersprechen. Es können jedoch in Frage kommende Erweiterungen der gegenständlichen Tabelle als Erläuterung am Beispiel herangezogen werden.

Geht man z. B. davon aus, dass nicht alle Positionen eines Auftrags sofort geliefert werden können und sind Teillieferungen geplant, so wäre das Datum der Auslieferung (wohlgemerkt der gesamten bestellten Menge, keine Teilmengen) ein Feld, welches die Bedingung der 2. Normalform erfüllte.

Für den Fall, dass Preisnachlässe in Form von Rabatten gewährt werden, könnte ein weiteres Feld mit der Bezeichnung Rabatt angefügt werden. Diese Art der Gewährung von Rabatten bedeutet, dass der Preisnachlass einmalig und nur für ein bestimmtes Produkt gewährt wird. Ebenso könnte ein Feld Rabatt der Tabelle Buch, der Tabelle Kunde oder der Tabelle Auftrag angefügt werden, ohne die Normalformen zu verletzen. Die Bedeutung der alternativen Platzierung ist jedoch sehr unterschiedlich. Das Feld Rabatt in der Tabelle Kunde bewirkt, dass alle Einkäufe des jeweiligen Kunden mit einem Preisnachlass versehen werden, während das besagte Feld in der Tabelle Buch Preisnachlässe für alle Kunden nach sich zieht.

Diese Variationsmöglichkeiten zeigen deutlich, dass die formale Korrektheit einer relationalen Datenbank nicht ohne das zugrundeliegende Geschäftsmodell bzw. deren Prozesse überprüft werden kann.

Dritte Normalform: Vermeidung von transitiven Abhängigkeiten

Zu den Bedingungen der 2. Normalform gilt zusätzlich: Felder, die nicht Teil des Schlüssels sind, dürfen nicht untereinander abhängig sein; ist dies der Fall, so müssen diese in einer eigenen Relation gespeichert werden.

Gemäß dem angestellten ER-Diagramm fehlen dem Datenmodell noch die entsprechenden Tabellen für die Kunden und Verlage. Beide enthalten Felder für die Adresse, nämlich Plz, Ort und Straße (Letzteres enthält auch die Hausnummer).

Berücksichtigt man die Zustellbezirke der Post, so kann festgestellt werden, dass jeder Postleitzahl eindeutig ein Zustellbezirk (zur zeitweiligen Verwirrung auch "Ort" genannt) zugeordnet werden kann. Das Feld Ort hängt demnach vom Feld Plz ab und muss ausgelagert werden. Die ohne Berücksichtigung der 3. Normalform also falsch konstruierte Tabellen wären:

  • Verlag (Kurzbezeichnung, Name, Kundennummer, Strasse, Plz, Ort)
  • Kunde (Nr, Vorname, Nachname, Strasse, Plz, Ort)

Adressen werden des Feldes Ort entledigt und es entsteht eine neue Tabelle mit der Bezeichnung PLZ und den Spalten Plz, Ort und Region.

Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur:

Literatur

Quellen

R. Elmasri, S. B. Navathe: Grundlagen von Datenbanksystemen. Ausgabe Grundstudium. Pearson Studium 2005


Weiterführende Links

Zitiervorschlag

Mittendorfer in Höller, Informationsverarbeitung I, Normalformen (mussswiki.idb.edu/iv1)