Vorläufig
Die Definition der Normalform (die aus der Darstellung der „weiteren Normalisierung des relationalen Datenbankmodells“ im Jahr 1971 als erste Normalform bekannt ist ) und die Definition des relationalen Paradigmas selbst wurden 1970 in dem wissenschaftlichen Artikel veröffentlicht, der eine starke Form lieferte Grundlage für die Praxis der Datenbankverwaltung, dh „Ein relationales Datenmodell für große gemeinsam genutzte Datenbanken“ (RM der Kürze halber), erstellt von Dr. EF Codd , einem Turing-Preisträger und der Autorität in Bezug auf den relationalen Rahmen.
Ja, es gibt viele Erklärungen, Interpretationen, Darstellungen, Abweichungen und Meinungen zu Dr. Codds Text, aber ich persönlich halte mich lieber an die Originalquelle und empfehle dringend, dass Sie sie selbst analysieren, damit Sie Ihre eigenen Schlussfolgerungen ziehen können.
Ich verstehe das RM sicherlich nicht in seiner Gesamtheit, aber was ich davon verstehe, erlaubt es mir, seine Exzellenz, Vision, Absicht und Reichweite zu schätzen, und obwohl man Jahrzehnte später feststellen kann, dass es einige leichte Ungenauigkeiten aufweist, verringern sie sich nicht. in jeder Hinsicht sein Genie und Eleganz. Auf seinem Gebiet hat der RM den Test der Zeit auf einzigartige Weise bestanden und ist unerreicht geblieben.
Das Hervorheben der oben genannten Ungenauigkeiten wäre - unter Verwendung eines gemeinnützigen Begriffs - unfair , da dieses wegweisende Material aus beträchtlicher Entfernung einige Verfeinerungen und Erweiterungen erforderte, ja, aber der Hauptteil der Arbeit war von Grund auf solide sehr Konzeption (und in der Tat machte Dr. Codd die meisten - wenn nicht alle - solcher Verfeinerungen und Erweiterungen selbst).
Ich lese das RM ständig neu, um mein Verständnis für diese außergewöhnliche Wissensquelle zu verbessern (und meine Wertschätzung dafür wächst mit jedem erneuten Lesen). Ziel ist es, auf den Schultern der Riesen zu stehen.
Beziehungen und Tabellen
Da Beziehungen abstrakte Ressourcen sind, stellte sich Dr. Codd die Nützlichkeit ihrer Darstellung in tabellarischer Form vor (er verwendete zunächst den Begriff „Array-Darstellung“, später jedoch „Tabelle“ oder „R-Tabelle“) Die Benutzer, Designer und Administratoren einer relationalen Datenbank (RDB) können sich ihnen vertrauter oder konkreter nähern . Daher ist es im Kontext einer RDB-Implementierung gültig, die Tabelle als Abkürzung für die Beziehung zu verwendensolange diese Tabelle für eine tatsächliche Beziehung steht. Dieses Merkmal ist - obwohl offensichtlich - ziemlich bedeutsam, da es vor der Bewertung, ob eine Tabelle eine Beziehung darstellt, die der ersten Normalform (1NF) entspricht oder nicht, genau eine Beziehung darstellen muss.
Das RM enthält natürlich die Eigenschaften, die eine Tabelle haben muss, um festzustellen, ob es tatsächlich eine Beziehung darstellt, aber ich werde hier eine informelle und unprätentiöse Interpretation darüber anbieten (eine andere, ja!):
- Es muss einen Namen haben (jede bestimmte Beziehung in einer Datenbankstruktur muss vom Rest unterschieden werden).
- Jede ihrer Zeilen muss genau ein Tupel der relevanten Beziehung darstellen.
- Die Reihenfolge der Zeilen ist überhaupt nicht wichtig.
- Jede ihrer Spalten muss einen Namen haben, der für die Bedeutung genau einer Domäne der betreffenden Beziehung steht, und dieser Name muss sich von den Namen der übrigen Spalten der Tabelle unterscheiden (eine Spalte muss eindeutig differenziert sein und tragen eine besondere Bedeutung und, ja, die Rolle, die ein Datenbankmodellierer und die Geschäftsexperten spielen, um jeden Bereich von Bedeutung mit Genauigkeit zu definieren, ist von größter Bedeutung.
- Die Reihenfolge seiner Spalten hat keine Bedeutung.
- Alle Zeilen müssen die gleiche Anzahl von Spalten haben.
- Es muss mindestens eine Spalte oder eine Kombination von Spalten enthalten, die jedes der über Zeilen dargestellten Tupel eindeutig identifiziert. Auf diese Weise müssen alle Zeilen unterschiedlich sein (ja, dies unterstreicht die Wichtigkeit, mindestens einen KEY deklariert zu haben, und wenn zwei oder mehr KEYs vorhanden sind, sollte einer aus pragmatischen Gründen als PRIMARY definiert werden, während der Rest sein kann als ALTERNATIV eingestuft; aber ja, bevor die Entscheidung getroffen wurde, war jeder der SCHLÜSSEL ein „Kandidat“ für eine Definition als PRIMÄR).
Eine Tabelle zu haben, die tatsächlich eine Beziehung darstellt, ist entscheidend, da das Ergebnis wiederum eine Tabelle ist, die eine Beziehung darstellt, wenn sie Manipulationsoperationen relationaler Art durchläuft. Auf diese Weise ist das Verhalten dieser Tabelle vorhersehbar .
Atomdomänen (Spalten)
In den ersten Abschnitten des RM stellt Dr. Codd verschiedene Beispiele für Beziehungen vor, um einige Konzepte vorzustellen. Um die Bedeutung der Atomdomäne zu verstehen , beginnen wir mit dem folgenden Auszug aus dem RM, in dem einige relevante Punkte aufgeführt sind:
Bisher haben wir Beispiele für Beziehungen diskutiert, die in einfachen Domänen definiert sind - Domänen, deren Elemente atomare (nicht zerlegbare) Werte sind. Nichtatomare Werte können im relationalen Rahmen diskutiert werden. Daher können einige Domänen Beziehungen als Elemente haben. Diese Beziehungen können wiederum auf nicht einfachen Domänen usw. definiert werden.
Auf diese Weise kann man sagen, dass jede der oben genannten Expository-Beziehungen in eine von zwei Arten passt , entweder Art A oder Art B :
Art A gruppiert nur Relationen (Tabellen), die mit Domänen (Spalten) strukturiert sind, die in jedem ihrer Tupel (Zeilen) ausschließlich einfache Werte enthalten , dh solche Domänen (Spalten) enthalten keine Relationen (Tabellen) als Werte, die in Dieser Kontext bedeutet, dass die Werte atomar sind, da sie nicht nacheinander in neue Beziehungen (Tabellen) zerlegt werden können . Daher sind die Beziehungen dieser Klasse diejenigen, die normalisiert sind , dh sie entsprechen 1NF, ihre Form ist wünschenswert.
Art B wird ausschließlich durch Relationen (Tabellen) integriert, die eine oder mehrere Domänen (Spalten) haben, die Relationen als Werte in jedem jeweiligen Tupel (Zeile) enthalten, und dies bedeutet, dass diese Werte nichtatomar sind, da sie anschließend in neue Relationen zerlegt werden können (Tabellen), dh sie sind zerlegbar . Somit sind die Beziehungen dieser Art nicht normalisiert, dh sie verletzen 1NF, sie liegen in einer unerwünschten Form vor.
Normalisierung
Dr. Codd führt den Abschnitt über die Normalisierung im RM mit dem folgenden Absatz ein:
Eine Beziehung, deren Domänen alle einfach sind, kann im Speicher durch ein zweidimensionales spaltenhomogenes Array der oben diskutierten Art dargestellt werden. Eine kompliziertere Datenstruktur ist für eine Beziehung mit einer oder mehreren nicht einfachen Domänen erforderlich. Aus diesem Grund (und anderen unten zu zitierenden Gründen) erscheint die Möglichkeit, nicht einfache Domänen zu eliminieren, eine Untersuchung wert! Tatsächlich gibt es ein sehr einfaches Eliminierungsverfahren, das wir als Normalisierung bezeichnen werden.
Dann zeigt er weiter:
Eine Gruppe von Beziehungen, in denen eine nicht normalisiert ist (sie hat Domänen, die Beziehungen als Werte enthalten, dh sie sind nichtatomar; dh sie sind nicht einfach).
Eine Gruppe von Beziehungen, die normalisiert sind (dh eine, die zerlegt wurde; dh eine, deren Domänen mit Beziehungswerten in einfache unterteilt wurden, was bedeutet, dass sie atomar sind).
Und dann beschreibt er das Verfahren, um normalisierte Beziehungen von nicht normalisierten zu erhalten.
In dieser Hinsicht sind die Beziehungen, die er zur Veranschaulichung einer Normalisierungsübung und der Übungsbeschreibung selbst verwendet hat, ziemlich klar, und ich empfehle erneut, dass Sie sie selbst analysieren (und ich hoffe auch, dass dies einige Leser dazu ermutigt, sich mit dem Text auseinanderzusetzen).
Nacheinander zeigt er an:
Weitere Operationen normalisierender Art sind möglich. Diese werden in diesem Artikel nicht behandelt.
Und diese Operationen, dh die zweite und dritte Normalform (2NF und 3NF), werden tatsächlich in "Weitere Normalisierung des relationalen Datenbankmodells" und wie oben erwähnt nach der Präsentation (und dem späteren Drucken und Veröffentlichen) dieses Papiers detailliert beschrieben wurde die ursprüngliche Normalform als erste Normalform bekannt.
Wie ein Praktiker beobachten kann, führt eine nicht normalisierte Beziehung (Tabellen) zu einer (fast immer unnötigen) Faltung in RDB-Implementierungen.
Eine Beziehung, die 1NF erfüllt, erleichtert die Definition von Einschränkungen und Datenmanipulationsoperationen, die mithilfe einer Datensprachsprache implementiert werden können, die weniger komplex ist als die für nicht normalisierte Beziehungen (Tabellen) erforderliche, wie Dr. Codd in den folgenden Zeilen ausführt:
Die Übernahme eines relationalen Datenmodells, wie oben beschrieben, ermöglicht die Entwicklung einer universellen Datensprachsprache auf der Grundlage einer angewandten Prädikatenrechnung. Ein Prädikatenkalkül erster Ordnung reicht aus, wenn die Sammlung von Beziehungen in normaler Form vorliegt. Eine solche Sprache würde einen Maßstab für die Sprachkraft aller anderen vorgeschlagenen Datensprachen liefern und wäre selbst ein starker Kandidat für die Einbettung (mit entsprechender syntaktischer Modifikation) in eine Vielzahl von Hostsprachen (Programmierung, befehls- oder problemorientiert). […]
[…]
Die Universalität der Datensprachsprache liegt in ihrer Beschreibungsfähigkeit (nicht in ihrer Rechenfähigkeit).
Die Verwirrung
Aus meiner Sicht ist die Verwirrung aufgrund (a) des oben erwähnten Überschusses an Interpretationen, Erklärungen usw. über 1NF und des RM selbst und aufgrund (b) weiterer Versuche, 1NF neu zu definieren , die besagen, dass Beziehungen bestehen, entstanden bei Domänen, die Werte enthalten, die wiederum Beziehungen sind, die 1NF entsprechen, solange sie ein einzelner Wert für jedes entsprechende Tupel sind.
Meine Meinung zu Ihren anderen Punkten
Es sollte keine Beziehung zwischen Zeilen geben, außer dass sie denselben Überschriften entsprechen.
Ich bin nicht sicher, ob ich die Absicht dieser Aussage richtig verstehe, aber abgesehen von der Übereinstimmung mit denselben Überschriften muss eine Verbindung zwischen den (Tupel-) Zeilen einer Beziehung (Tabelle) bestehen, da jede von ihnen eine Behauptung über a sein sollte besonderes Vorkommen des spezifischen Entitätstyps (definiert im Hinblick auf den interessierenden Geschäftskontext), den die Beziehung (Tabelle) darstellen soll.
Es sollte auch keine Beziehung zwischen Spalten geben, aber ich glaube, dass dies das Thema höherer Normalformen ist.
Ich weiß nicht , ob ich richtig die Bedeutung dieser Aussage zu interpretieren bin entweder aber in der Tat, und in Übereinstimmung mit meiner Antwort auf den vorherigen Aspekt, es muss auch eine Beziehung zwischen den Domänen (Spalten) einer Relation (Tabelle) sein Genau deshalb handelt es sich um eine Beziehung (die wesentliche Struktur des relationalen Modells und einer konkreten RDB-Implementierung).
Zum Beispiel in Bezug auf die hypothetische Beziehung (Tabelle)
Salary (PersonNumber, EffectiveDate, Amount)
das Tupel (Reihe)
würde die Bedeutung vermitteln
The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z
Daher muss jedes Tupel (Zeile) der SalaryBeziehung (Tabelle) in die Struktur der oben gezeigten Behauptung passen, und der Unterschied wäre das Ersetzen der relevanten Domänen- (Spalten-) Werte, aber es muss eine Beziehung zwischen (a) bestehen. alle SalaryDomänen (Spalten) und auch zwischen (b) alle ihre entsprechenden Werte in Bezug auf jedes Tupel (Zeile); Eine solche Beziehung ist unverzichtbar.
Höhere Normalformen (2NF und 3NF) sind nützlich, um funktionale Abhängigkeiten zwischen Domänen (Spalten) einer Beziehung (Tabelle) zu beseitigen. Sie helfen dabei, unerwünschte Verbindungen zwischen Domänen (Spalten) zu vermeiden , da diese unerwünschten Verbindungen die Einführung von Aktualisierungsanomalien ermöglichen . Sowohl 2NF als auch 3NF sind hilfreich, um die Solidität der Struktur der Beziehungen (Tabellen) in einer bestimmten RDB-Implementierung zu testen.
