faecher:informatik:oberstufe:datenbanken:normalisierung:3_normalform:start []

Diese Seite ist nicht editierbar. Du kannst den Quelltext sehen, jedoch nicht verändern. Kontaktiere den Administrator, wenn du glaubst, dass hier ein Fehler vorliegt.
====== 3. Normalform (3NF) ======
<WRAP center important 90%>
Eine Datenbank/Relation befindet sich dann in der dritten Normalform (3NF), wenn die zweite Normalform erfüllt ist und keine so genannten transitiven Abhängigkeiten bestehen.
</WRAP>

Das bedeutet Folgendes: Irgendein Feld eines Datensatzes ist von einem anderen Feld abhängig, das kein Primärschlüssel ist.

Unsere Universaltabelle ist nach den Umformungen der vorigen Abschnitte bereits in der 3NF, dort kann man keine direkten Weiteroptimierungen mehr vornehmen. Zur weiteren Veranschaulichung kann man die folgenden Überlegungen heranziehen:

Wir möchten die Zuverlässigkeit unserer Lieferanten erfassen und legen dazu eine Tabelle an, die die Lieferzeiten und die Zuverlässigkeiten erfassen soll


<code>
TABLE lieferqualitaet
+--+----------+----------------+--------+
|id|lieferzeit|firma           |verlass |
+--+----------+----------------+--------+
| 1|12h       |SupiTrans       |hoch    |
| 2|24h       |SupiTrans       |hoch    |
| 3| 8h       |HyperCompoGlobal|mittel  |
| 4| 4h       |SuperMegaNet    |saumäßig|
| 5|12h       |SuperMegaNet    |saumäßig|
| 6| 8h       |HyperCompoGlobal|mittel  |
| 7|irgendwann|Post AG         |saumäßig|
+--+----------+----------------+--------+
</code>

Hier gibt es eine transitive Abhängigkeit zwischen dem Nichtschlüsselattribut ''firma'' und dem Attribut ''verlass'': Wenn man weiss, wer der Lieferant ist, kann man auch direkt sagen, wie verlässlich dieser ist. Man muss also nicht bei jedem Datensatz mit der Lieferfirma SupiTrans dazuschreiben, dass die Verlässlichkeit "hoch" ist, sondern man könnte ebensogut (und Speicherplatz sparender) auf eine weitere Entität/Tabelle verweisen, in der die Verlässlichkeiten gespeichert sind - das stellt eine redundante Datenspeicherung dar, die man mit Hilfe einer weiteren Tabelle eliminieren kann.

 
<code>
TABLE: verlass
+----------------+--------+
|firma           |verlass |
+----------------+--------+
|SupiTrans       | hoch   |
|HyperCompoGlobal| mittel |
|SuperMegaNet    |saumäßig|
|Post AG         |saumäßig|
+----------------+--------+

TABLE lieferqualitaet
+--+----------+----------------+
|id|lieferzeit|firma           |
+--+----------+----------------+
| 1|12h       |SupiTrans       |
| 2|24h       |SupiTrans       |
| 3| 8h       |HyperCompoGlobal|
| 4| 4h       |SuperMegaNet    |
| 5|16h       |SuperMegaNet    |
| 6| 9h       |HyperCompoGlobal|
| 7|irgendwann|Post AG         |
+--+----------+----------------+
</code>

Hinweise: In "echt" wäre es besser, der Tabelle "verlass" künstliche Surrogat-Schlüssel zu geben und diese als Fremdschlüssel in der zweiten Tabelle anzugeben. Außerdem könnte/sollte man das gezeigte Modell wiederum weiter ergänzen, und die als "String" angegebenen "Verlass-Qualitäten" erst in einer dritten Tabelle ausschreiben. Das verringert erneut die Redundanz und verringert Fehlerquellen, wenn man z. B. einmal "saumäßig" in "schlecht" umändern möchte.

----
{{:aufgabe.png?nolink  |}}
=== (A1) ===

Man kann auch die Lieferzeiten noch in eine weitere Tabelle auslagern - wie könnte man hier vorgehen? Wie sieht die Tabelle ''lieferqualitaet'' anschliessend aus?


----
{{:aufgabe.png?nolink  |}}
=== (A2) ===

Kann man in der  Tabelle ''lieferqualitaet'' die mehrfach auftretenden Herstellernamen ebenfalls durch eine Verbindung auf einen anderen Entitätstyp eliminieren? Wie sieht die Tabelle dann aus?

Ein solche Tabelle nennt man **Beziehungtabelle** - erläutere, warum dieser Name sehr sinnvoll ist.