Inhaltsverzeichnis:
Nachdem sich eine SQL-Datenbank in der dritten Normalform befindet, haben Sie die meisten, aber nicht alle Chancen auf Modifikationsanomalien beseitigt. Normale Formen jenseits des dritten werden definiert, um die wenigen verbleibenden Fehler zu quetschen.
Domänenschlüssel-Normalform (DK / NF)
Boyce-Codd-Normalform (BCNF), vierte Normalform (4NF) und fünfte Normalform (5NF) sind Beispiele für solche Formen. Jede Form eliminiert eine mögliche Modifikationsanomalie, garantiert jedoch nicht die Verhinderung aller möglichen Modifikationsanomalien. Die Domain-Key-Normalform bietet jedoch eine solche Garantie.
Eine Relation ist in der Domänenschlüssel-Normalform (DK / NF) , wenn jede Einschränkung der Relation eine logische Konsequenz der Definition von Schlüsseln und Domänen ist. Eine -Einschränkung in dieser Definition ist eine Regel, die genau genug ist, damit Sie beurteilen können, ob sie wahr ist oder nicht. Ein Schlüssel ist ein eindeutiger Bezeichner einer Zeile in einer Tabelle. Eine Domäne ist die Menge der zulässigen Werte eines Attributs.
Schauen Sie sich diese Datenbank in 1NF an, um zu sehen, was Sie tun müssen, um diese Datenbank in DK / NF zu stellen.
Tabelle: SALES (Kunden-ID, Produkt, Preis)
Schlüssel: Kunden-ID
Einschränkungen:
-
Kunden-ID bestimmt Produkt
-
Produkt ermittelt Preis
-
Kunden-ID muss eine ganze Zahl sein > 1000
Um Constraint 3 durchzusetzen (Customer_ID muss eine ganze Zahl größer als 1000 sein), können Sie einfach die Domäne für Customer_ID definieren, um diese Einschränkung zu integrieren. Damit ist die Einschränkung eine logische Konsequenz der Domäne der CustomerID-Spalte. Das Produkt hängt von der Customer_ID ab und Customer_ID ist ein Schlüssel, sodass Sie kein Problem mit Constraint 1 haben, was eine logische Konsequenz der Definition des Schlüssels ist.
Einschränkung 2 ist ein Problem. Der Preis hängt von (und ist eine logische Konsequenz von) Produkt und Produkt ist kein Schlüssel. Die Lösung besteht darin, die Tabelle VERKÄUFE in zwei Tabellen aufzuteilen. Eine Tabelle verwendet Customer_ID als Schlüssel und die andere verwendet Product als Schlüssel. Die Datenbank befindet sich außer in 3NF auch in DK / NF.
Gestalten Sie Ihre Datenbanken so, dass sie möglichst in DK / NF sind. Wenn Sie dies tun können, führt das Erzwingen von Schlüssel- und Domäneneinschränkungen dazu, dass alle Einschränkungen erfüllt werden und Modifikationsanomalien nicht möglich sind. Wenn die Struktur einer Datenbank so konzipiert ist, dass Sie sie nicht in DK / NF einfügen können, müssen Sie die Integritätsbedingungen in das Anwendungsprogramm schreiben, das die Datenbank verwendet. Die Datenbank selbst garantiert nicht, dass die Bedingungen erfüllt werden.
Abnormale Form
Wie im Leben, so in Datenbanken: Manchmal ist es anormal, sich auszuzahlen.Sie können sich von der Normalisierung mitreißen lassen und zu weit gehen. Sie können eine Datenbank in so viele Tabellen aufteilen, dass das Ganze unhandlich und ineffizient wird. Die Leistung kann stark sinken. Oft ist die optimale Struktur für Ihre Datenbank etwas demormalisiert.
In der Tat sind praktische Datenbanken (die wirklich großen) sowieso fast nie auf DK / NF normalisiert. Sie möchten die von Ihnen entworfenen Datenbanken so weit wie möglich normalisieren, um die Möglichkeit von Datenbeschädigungen zu vermeiden, die sich aus Modifikationsanomalien ergeben.
Nachdem Sie die Datenbank so weit wie möglich normalisiert haben, führen Sie einige Abfragen als Testlauf durch. Wenn die Leistung nicht zufriedenstellend ist, untersuchen Sie Ihr Design, um festzustellen, ob eine selektive Denormalisierung die Leistung verbessern würde, ohne die Integrität zu beeinträchtigen. Durch sorgfältiges Hinzufügen von Redundanz an strategischen Standorten und Entnormalisierung von gerade genug , können Sie eine Datenbank erstellen, die sowohl effizient als auch sicher vor Anomalien ist.
