Mailinglisten-Archive |
Mathias schrieb am Sonntag, den 5. September 1999:
> Eine Frage: Kann mir jemand vielleicht die "Normalformen" in einem
> "verständlichen" deutsch erläutern?
> Habe Probleme diese aus der Literatur zu verstehen!
Ich probier's mal ... :-)
1. Normalform (1NF)
-------------------
Wenn jedes Feld einer Tabelle nur genau einen Wert enthält, also
atomar und nicht mengenwertig ist, ist das die 1. Normalform.
Nicht in 1NF ist zum Beispiel eine MySQL-Tabelle, die Felder mit dem
Typ SET enthält. Oder wenn man Textfelder dazu verwendet, Listen von
Werten zu speichern.
Es zählt also nicht der rein technische Feldtyp, sondern wie man die
Felder vom Datenbankdesign her verwendet!
2. Normalform (2NF)
-------------------
Schlüsselkandidat, Schlüssel:
Datensätze in relationalen Datenbanken haben innerhalb der Tabelle
keine feste Nummer oder Reihenfolge, sondern sind nur durch den
Inhalt der Felder festgelegt. In diesem strengen Sinn kann es also
keine zwei Datensätze mit gleichem Inhalt geben. (Ich geh später noch
darauf ein, warum das bei MySQL doch vorkommen kann ...)
Statt immer vom gesamten Datensatz zu reden, überlegt man sich
natürlich, ob nicht evtl. der Inhalt nur eines Teils der Felder oder
sogar nur eines Feldes genügt, um den ganzen Datensatz festzulegen.
Als Beispiel eine Tabelle, die Immobilien auflistet:
Name | Straße | PLZ | Ort | Makler | Tel
--------------------+-----------+-------+--------+--------+--------
Wohnheim St. Helena | Burgweg 1 | 87654 | Hausen | 1 | 089/123
Domizil Altersruh | Gasse 5 | 34567 | Wohnar | 2 | 078/345
Wohnheim St. Helena | Allee 2 | 12345 | Orting | 3 | 023/656
Schöner Wohnen | Ring 3 | 34343 | Öden | 1 | 089/123
Der Name allein genügt sicher nicht, um einen Datensatz eindeutig zu
identifizieren, da die Wohnanlagen in verschiedenen Städten durchaus
mal gleiche Namen haben können (innerhalb der gleichen Stadt
vermeidet das die Immobilienfirma). Die Kombination von Name, PLZ
und Ort - kurz geschrieben: (Name,PLZ,Ort) - dagegen ist geeignet:
mit z.B. der Angabe (Wohnheim St. Helena,12345,Orting) ist eindeutig
der 3. Datendatz oben identifiziert. Allerdings geht's noch kürzer
nur mit (Name,PLZ), da sich der Ort ja eindeutig aus der PLZ ergibt.
Somit ist (Name,PLZ) ein möglicher Schlüssel für diese Tabelle.
Genauso gut ginge aber auch die Kombination (Straße,PLZ), denn pro
Adresse kann es ja auch nicht mehr als eine Immobilie geben.
Sowohl (Name,PLZ) als auch (Straße,PLZ) sind somit Schlüssel-
kandidaten, denn mit beiden Kombinationen kann man schon den ganzen
Datensatz identifizieren und mit weniger Feldern geht's nicht.
In relationalen Datenbanksystemen muß man für jede Tabelle einen
Schlüssel bestimmen - das ist dann ein beliebiger der möglichen
Schlüsselkandidaten.
2NF:
Die 2. Normalform bedeutet nun, daß nicht nur der Datensatz als
ganzes vom Schlüssel abhängt, sondern auch zur Bestimmung jedes
einzelnen Feldes nicht schon ein Teil des Schlüssel genügt.
("immer ganzer Schlüssel")
In anderen Worten: wenn schon ein Teil des Schlüssel genügt, um den
Inhalt eines anderen Feldes zu bestimmen, dann ist das nicht 2NF.
(Das heißt auch: wenn der Schlüssel einer Tabelle nur aus einem
einzigen Feld besteht, ist die Tabelle automatisch in 2NF!)
Beispiel: Man braucht nicht die Kombination (Name,PLZ) oder
(Straße,PLZ), um den Ort zu wissen, es genügt PLZ - denn aus der
Postleitzahl ergibt sich (normalerweise) eindeutig der Ortsname.
Um bei einem Beispiel wie dem obigem dann doch 2NF zu erreichen,
teilt man die Tabelle einfach in mehrere auf, die dann jeweils in 2NF
sind.
Hier wäre das eine gekürzte Tabelle "Immobilien":
Name | Straße | PLZ | Makler | Tel
--------------------+-----------+-------+--------+--------
Wohnheim St. Helena | Burgweg 1 | 87654 | 1 | 089/123
Domizil Altersruh | Gasse 5 | 34567 | 2 | 078/345
Wohnheim St. Helena | Allee 2 | 12345 | 3 | 023/656
Schöner Wohnen | Ring 3 | 34343 | 1 | 089/123
Und eine neue Tabelle "Orte":
PLZ | Ort
------+-------
87654 | Hausen
34567 | Wohnar
12345 | Orting
34343 | Öden
3. Normalform (3NF)
-------------------
Eine Tabelle ist in 3NF, wenn sie bereits in 2NF ist und zusätzlich
gilt, daß jedes Feld (außer den Schlüsselfeldern selbst) auch direkt
von den Schlüsselfeldern abhängen muß.
("nur direkt vom Schlüssel")
("keine Abhängigkeiten zwischen Nichtschlüsselfeldern")
In anderen Worten: Wenn ein Nicht-Schlüssel-Feld von einem oder
mehreren Nicht-Schlüssel-Felder abhängt, ist das keine 3NF!
Beispiel: Die Telefonnummer des Maklers ergibt sich zwar auch
eindeutig aus (Name,PLZ) oder (Straße,PLZ), da zu jeder Immobilie
genau ein Makler gehört und dieser genau eine Telefonnummer hat, aber
eigentlich ergibt sich die Telefonnummer auch schon eindeutig aus der
Nummer des Maklers. Somit ist das Nicht-Schlüssel-Feld Tel vom
Nicht-Schlüssel-Feld Makler abhängig, die 3NF gilt nicht.
Um in einem solchen Fall die 3NF zu erreichen, teil man die Tabellen
weiter auf.
Hier wäre das eine nochmal gekürzte Tabelle "Immobilien":
Name | Straße | PLZ | Makler | Tel
--------------------+-----------+-------+--------+--------
Wohnheim St. Helena | Burgweg 1 | 87654 | 1 | 089/123
Domizil Altersruh | Gasse 5 | 34567 | 2 | 078/345
Wohnheim St. Helena | Allee 2 | 12345 | 3 | 023/656
Schöner Wohnen | Ring 3 | 34343 | 1 | 089/123
Und eine neue Tabelle "Makler":
MaklerID | Tel
---------+--------
1 | 089/123
2 | 078/345
3 | 023/656
1 | 089/123
Ist die Erklärung verständlich?
Streng genommen sollte man eigentlich nicht von Tabellen und Feldern
sprechen, sondern von Relationen und Attributen, weil die Normalformen
Teil des mathematischen Relationenmodells bei Datenbanken sind. Reine
Tabellen sind laxer als Relationen und können z.B. auch mehrere
identische Zeilen beinhalten, wenn eine solche Tabelle keinen
Primärschlüssel besitzt. Relationen dagenen haben immer einen
Schlüssel.
Einen recht verständlichen Text von Gerhard Knorz zu den Normalformen
findest Du übrigens im WWW unter
<URL: http://www.k-n-o-r-z.de/publ/skript/db96/rdbenfl5.htm >.
Ciao,
Martin
--
Martin Ramsch <m.ramsch_(at)_computer.org> <URL: http://home.pages.de/~ramsch/ >
PGP KeyID=0xE8EF4F75 FiPr=52 44 5E F3 B0 B1 38 26 E4 EC 80 58 7B 31 3A D7
---
*** Abmelden von dieser Mailingliste funktioniert per E-Mail
*** an mysql-de-request_(at)_lists.4t2.com mit Betreff/Subject: unsubscribe
php::bar PHP Wiki - Listenarchive