Normalformen: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 10: | Zeile 10: | ||
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. 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, 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. 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. | ||
== | == 1. 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. | |||
Die | 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: | ||
''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. | |||
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. | |||
[GRAFIK] | |||
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. | |||
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. | |||
[GRAFIK] | |||
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. |
Version vom 20. Februar 2009, 20:22 Uhr
Bei der Aufgabe, eine Datenbank anzulegen, wird man mit mehreren Problemen 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 Studentenadresse wesentlich einfacher, wenn die betreffenden Daten nur in der Tabelle Student 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, 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. 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.
1. 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.
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:
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. 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.
[GRAFIK]
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.
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.
[GRAFIK]
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.