Erste Normalform – Wikipedia

before-content-x4

Erste Normalform ((1NF) ist eine Eigenschaft einer Beziehung in einer relationalen Datenbank. Eine Beziehung liegt genau dann in der ersten Normalform vor, wenn die Domäne jedes Attributs nur atomare (unteilbare) Werte enthält und der Wert jedes Attributs nur einen einzigen Wert aus dieser Domäne enthält.[1] Die erste Definition des Begriffs in einem Konferenzpapier von Edgar Codd aus dem Jahr 1971 definierte eine Beziehung als erste Normalform, wenn keine ihrer Domänen Mengen als Elemente enthält.[2]

Die erste Normalform ist eine wesentliche Eigenschaft einer Beziehung in einer relationalen Datenbank. Bei der Datenbanknormalisierung wird eine Datenbank in Bezug auf Beziehungen in Standardnormalformen dargestellt, wobei die erste Normalität eine Mindestanforderung ist.

Die erste Normalform erzwingt diese Kriterien:[3]

Beispiele[edit]

Die folgenden Szenarien veranschaulichen zunächst, wie ein Datenbankdesign möglicherweise gegen die erste normale Form verstößt, gefolgt von Beispielen, die den Anforderungen entsprechen.

Designs, die gegen 1NF verstoßen[edit]

In der folgenden Tabelle sind die Namen und Telefonnummern der Kunden aufgeführt. Eine Anforderung ist jedoch zu behalten mehrere Telefonnummern für einige Kunden. Die einfachste Möglichkeit, diese Anforderung zu erfüllen, besteht darin, zuzulassen, dass die Spalte “Telefonnummer” in einer bestimmten Zeile mehr als einen Wert enthält:

Kunde
Kundennummer Vorname Nachname Telefonnummer
123 Pooja Singh 555-861-2025, 192-122-1111
456 San Zhang (555) 403-1659 Durchwahl 53; 182-929-2929
789 John Damhirschkuh 555-808-9633

Die Telefonnummernspalte enthält mehrere Telefonnummern in einem einzigen Wert. In der ersten Zeile sind beispielsweise zwei Telefonnummern durch Komma getrennt. Die Spaltenwerte sind nicht atomar: Es kann in zwei Zahlen unterteilt werden. Dies verletzt die erste Normalform.

Eine offensichtliche Lösung besteht darin, mehr Spalten einzuführen:

Kunde
Kundennummer Vorname Nachname Telefonnummer1 Telefonnummer2
123 Pooja Singh 555-861-2025 192-122-1111
456 San Zhang (555) 403-1659 Durchwahl 53 182-929-2929
789 John Damhirschkuh 555-808-9633

Technisch gesehen verstößt diese Tabelle nicht gegen die Anforderung, dass Werte atomar sein müssen. Informell bilden die beiden Telefonnummernspalten jedoch immer noch eine “sich wiederholende Gruppe”: Sie wiederholen das, was konzeptionell dasselbe Attribut ist, nämlich eine Telefonnummer. Eine willkürliche und damit bedeutungslose Reihenfolge wurde eingeführt: Warum wird 555-861-2025 in die Spalte Telefonnummer1 und nicht in die Spalte Telefonnummer2 eingefügt? Es gibt keinen Grund, warum Kunden nicht mehr als zwei Telefonnummern haben könnten, also wie viele TelefonnummernN. Spalten sollte es geben? Es ist nicht möglich, nach einer Telefonnummer zu suchen, ohne eine beliebige Anzahl von Spalten zu durchsuchen. Wenn Sie eine zusätzliche Telefonnummer hinzufügen, muss die Tabelle möglicherweise durch Hinzufügen einer neuen Spalte neu organisiert werden, anstatt nur eine neue Zeile (Tupel) hinzuzufügen. (Der Nullwert für Telefonnummer 2 für Kunde 789 ist ebenfalls ein Problem.)

Designs, die 1NF entsprechen[edit]

Um das Modell in die erste normale Form zu bringen, teilen wir die Zeichenfolgen, mit denen wir unsere Telefonnummerninformationen gespeichert haben, in “atomare” (dh unteilbare) Entitäten auf: einzelne Telefonnummern. Und wir stellen sicher, dass keine Zeile mehr als eine Telefonnummer enthält.

Kunde
Kundennummer Vorname Nachname Telefonnummer
123 Pooja Singh 555-861-2025
123 Pooja Singh 192-122-1111
456 San Zhang 182-929-2929
456 San Zhang (555) 403-1659 Durchwahl 53
789 John Damhirschkuh 555-808-9633

Beachten Sie, dass die “ID” in dieser Lösung bei doppelten Kunden nicht mehr eindeutig ist. Um eine Zeile eindeutig zu identifizieren, müssen wir eine Kombination aus (ID, Telefonnummer) verwenden. Der Wert der Kombination ist eindeutig, obwohl jede Spalte separat wiederholte Werte enthält. Die Möglichkeit, eine Zeile (Tupel) eindeutig zu identifizieren, ist eine Anforderung von 1NF.

Ein alternatives Design verwendet zwei Tabellen:

Kundenname
Kundennummer Vorname Nachname
123 Pooja Singh
456 San Zhang
789 John Damhirschkuh
Kundentelefonnummer
Telefonnummer ID Kundennummer Telefonnummer
1 123 555-861-2025
2 123 192-122-1111
3 456 (555) 403-1659 Durchwahl 53
4 456 182-929-2929
5 789 555-808-9633

Spalten enthalten in diesem Design nicht mehr als eine Telefonnummer. Stattdessen wird jeder Link zwischen Kunde und Telefonnummer in einer eigenen Zeile angezeigt. Verwenden von Kundennummer als Schlüssel a eins zu viele Es besteht eine Beziehung zwischen dem Namen und den Nummerntabellen. Eine Zeile in der “übergeordneten” Tabelle, Kundenname, kann mit vielen Telefonnummernzeilen in der “untergeordneten” Tabelle verknüpft werden, Kundentelefonnummer, aber jede Telefonnummer gehört einem und nur einem Kunden. (In der “realen” Welt wäre dies keine gute Annahme.) Es ist erwähnenswert, dass dieses Design die zusätzlichen Anforderungen für die zweite und dritte Normalform erfüllt.

Atomizität[edit]

Edgar F. Codds Definition von 1NF bezieht sich auf das Konzept der ‘Atomizität’. Codd gibt an, dass “die Werte in den Domänen, in denen jede Beziehung definiert ist, in Bezug auf das DBMS atomar sein müssen”.[4] Codd definiert einen Atomwert als einen Wert, der “vom DBMS nicht in kleinere Teile zerlegt werden kann (mit Ausnahme bestimmter Sonderfunktionen)”.[5] Dies bedeutet, dass eine Spalte nicht in Teile mit mehr als einer Art von Daten unterteilt werden sollte, sodass die Bedeutung eines Teils für das DBMS von einem anderen Teil derselben Spalte abhängt.

Hugh Darwen und Chris Date haben vorgeschlagen, dass Codds Konzept eines “atomaren Wertes” nicht eindeutig ist und dass diese Mehrdeutigkeit zu weit verbreiteter Verwirrung darüber geführt hat, wie 1NF verstanden werden sollte.[6][7] Insbesondere der Begriff eines “Werts, der nicht zerlegt werden kann” ist problematisch, da er zu implizieren scheint, dass nur wenige, wenn überhaupt, Datentypen atomar sind:

  • Eine Zeichenfolge scheint nicht atomar zu sein, da das RDBMS normalerweise Operatoren bereitstellt, um sie in Teilzeichenfolgen zu zerlegen.
  • Eine Festkommazahl scheint nicht atomar zu sein, da das RDBMS normalerweise Operatoren bereitstellt, um sie in ganzzahlige und gebrochene Komponenten zu zerlegen.
  • Eine ISBN scheint nicht atomar zu sein, da sie Sprache und Herausgeberkennung enthält.

Datum legt nahe, dass “der Begriff der Atomizität hat keine absolute Bedeutung“:[8][9] Ein Wert kann für einige Zwecke als atomar angesehen werden, für andere Zwecke jedoch als Zusammenstellung grundlegenderer Elemente. Wenn diese Position akzeptiert wird, kann 1NF nicht in Bezug auf die Atomizität definiert werden. Spalten eines denkbaren Datentyps (von Zeichenfolgentypen und numerischen Typen bis zu Array- und Tabellentypen) sind dann in einer 1NF-Tabelle akzeptabel – obwohl dies möglicherweise nicht immer wünschenswert ist. Beispielsweise kann es wünschenswerter sein, eine Spalte “Kundenname” in zwei separate Spalten als Vorname, Nachname zu trennen.

1NF-Tabellen als Darstellungen von Beziehungen[edit]

Nach der Definition von Date liegt eine Tabelle genau dann in der ersten Normalform vor, wenn sie “zu einer Beziehung isomorph” ist, was insbesondere bedeutet, dass sie die folgenden fünf Bedingungen erfüllt:[10]

  1. Es gibt keine Reihenfolge von oben nach unten für die Zeilen.
  2. Es gibt keine Reihenfolge von links nach rechts für die Spalten.
  3. Es gibt keine doppelten Zeilen.
  4. Jeder Zeilen- und Spaltenschnittpunkt enthält genau einen Wert aus der entsprechenden Domäne (und sonst nichts).
  5. Alle Spalten sind regulär [i.e. rows have no hidden components such as row IDs, object IDs, or hidden timestamps].

Ein Verstoß gegen eine dieser Bedingungen würde bedeuten, dass die Tabelle nicht streng relational ist und daher nicht in der ersten normalen Form vorliegt.

Beispiele für Tabellen (oder Ansichten), die diese Definition der ersten Normalform nicht erfüllen würden, sind:

  • Eine Tabelle, der eine eindeutige Schlüsselbeschränkung fehlt. Eine solche Tabelle könnte unter Verstoß gegen Bedingung 3 doppelte Zeilen aufnehmen.
  • Eine Ansicht, deren Definition die Rückgabe der Ergebnisse in einer bestimmten Reihenfolge vorschreibt, sodass die Zeilenreihenfolge ein wesentlicher und aussagekräftiger Aspekt der Ansicht ist. (Solche Ansichten können nicht mit SQL erstellt werden, das dem SQL: 2003-Standard entspricht.) Dies verstößt gegen Bedingung 1. Die Tupel in echten Beziehungen sind nicht in Bezug zueinander angeordnet.
  • Eine Tabelle mit mindestens einem nullbaren Attribut. Ein nullbares Attribut würde gegen Bedingung 4 verstoßen, wonach jede Spalte genau einen Wert aus der Domäne ihrer Spalte enthalten muss. Dieser Aspekt von Bedingung 4 ist umstritten. Es markiert eine wichtige Abkehr von Codds späterer Vision des relationalen Modells.[11] die explizit für Nullen vorgesehen.[12] Die erste Normalform, wie sie von Chris Date definiert wurde, erlaubt Attribute mit Beziehungswert (Tabellen innerhalb von Tabellen). Date argumentiert, dass beziehungswertige Attribute, mit denen eine Spalte in einer Tabelle eine Tabelle enthalten kann, in seltenen Fällen nützlich sind.[13]

Siehe auch[edit]

Weitere normale Formulare finden Sie in der Navigationsleiste unten auf der Seite.

Verweise[edit]

  1. ^ Elmasri, Ramez; Navathe, Shamkant B. (Juli 2003). Grundlagen von Datenbanksystemen (Vierte Ausgabe). Pearson. p. 315. ISBN 0321204484. Es gibt an, dass die Domäne eines Attributs nur enthalten darf atomar (einfach, unteilbar) Werte und dass der Wert eines Attributs in einem Tupel a sein muss Einzelwert aus der Domäne dieses Attributs.
  2. ^ Codd, EF (Oktober 1972). Weitere Normalisierung des relationalen Datenbankmodells. Datenbanksysteme. Courant Institute: Prentice-Hall. ISBN 013196741X. Eine Beziehung ist in erste Normalform wenn es die Eigenschaft hat, dass keine seiner Domänen Elemente enthält, die selbst festgelegt sind.
  3. ^ Watt, Adrienne; Eng, Nelson (2014). Datenbank Design (2. Aufl.). Victoria, BC: BCcampus.
  4. ^ Codd, EF Das relationale Modell für die Datenbankverwaltung Version 2 (Addison-Wesley, 1990).
  5. ^ Codd, EF Das relationale Modell für die Datenbankverwaltung Version 2 (Addison-Wesley, 1990), p. 6.
  6. ^ Darwen, Hugh. “Attribute mit Beziehungswert; oder wird die echte erste Normalform bitte aufstehen?”, In CJ Date und Hugh Darwen, Relationale Datenbankschriften 1989-1991 (Addison-Wesley, 1992).
  7. ^ Date, CJ (2007). Was erste Normalform wirklich bedeutet. Datum in der Datenbank: Schriften 2000–2006. Apress. p. 108. ISBN 978-1-4842-2029-0. ‘[F]oder viele Jahre “, schreibt Date,” war ich genauso verwirrt wie jeder andere. Was noch schlimmer ist, ich habe mein Bestes (Schlimmstes?) Getan, um diese Verwirrung durch meine Schriften, Seminare und andere Präsentationen zu verbreiten. ‘
  8. ^ Date, CJ (2007). Was erste Normalform wirklich bedeutet. Datum in der Datenbank: Schriften 2000–2006. Apress. p. 112. ISBN 978-1-4842-2029-0.
  9. ^ Datum, CJ (6. November 2015). SQL und relationale Theorie: Schreiben von genauem SQL-Code. O’Reilly Media. S. 50–. ISBN 978-1-4919-4115-7. Abgerufen 31. Oktober 2018.
  10. ^ Date, CJ (2007). Was erste Normalform wirklich bedeutet. Datum in der Datenbank: Schriften 2000–2006. Apress. S. 127–128. ISBN 978-1-4842-2029-0.
  11. ^ Date, CJ (2009). “Anhang A.2”. SQL und relationale Theorie. O’Reilly. Codd definierte das relationale Modell erstmals 1969 und führte erst 1979 Nullen ein
  12. ^ Date, CJ (14. Oktober 1985). “Ist Ihr DBMS wirklich relational?” Computerwelt. Nullwerte … [must be] Unterstützung in einem vollständig relationalen DBMS zur systematischen Darstellung fehlender und nicht anwendbarer Informationen, unabhängig vom Datentyp. (die dritte von Codds 12 Regeln)
  13. ^ Date, CJ (2007). Was erste Normalform wirklich bedeutet. Datum in der Datenbank: Schriften 2000–2006. Apress. S. 121–126. ISBN 978-1-4842-2029-0.

Weiterführende Literatur[edit]


after-content-x4