Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
computer:tutorials:sql:normalisierung [2013/05/13 07:51] christian [1.Normalform] |
computer:tutorials:sql:normalisierung [2013/05/13 08:01] (aktuell) christian [3.Normalform] |
||
|---|---|---|---|
| Zeile 62: | Zeile 62: | ||
| * Erfüllung der 1.Normalform | * Erfüllung der 1.Normalform | ||
| * alle Spalten sind vom Primärschlüssel abhängig | * alle Spalten sind vom Primärschlüssel abhängig | ||
| - | * alle Informationen werden an einer Stelle und nicht mehrfach gesichert | + | * alle Informationen werden an einer Stelle und nicht mehrfach gesichert (//keine Datenredundanz//) |
| - | + | ||
| Diese Bedingungen werden vom aktuellen Entwurf nicht erfüllt: | Diese Bedingungen werden vom aktuellen Entwurf nicht erfüllt: | ||
| Zeile 72: | Zeile 70: | ||
| |3|Theodor|Tester|Test-Solutions AG|Testweg|16|55353|Testort|Offene Rechnung|15.02.2011|nein|1|Thin-Client BAER|1.6 Ghz,Sound,VGA,USB|nein|199.99| | |3|Theodor|Tester|Test-Solutions AG|Testweg|16|55353|Testort|Offene Rechnung|15.02.2011|nein|1|Thin-Client BAER|1.6 Ghz,Sound,VGA,USB|nein|199.99| | ||
| - | Es sind Spalten vorhanden, die nicht vom Primärschlüssel **ID** abhängig sind - so sind beispielsweise die Artikel keineswegs vom Primärschlüssel abhängig. | + | Es sind Spalten vorhanden, die nicht vom Primärschlüssel **ID** (//Kunde//) abhängig sind: |
| - | Abgesehen davon, dass die Tabelle sehr unübersichtlich ist, werden Informationen mehrfach definiert (//beispielsweise die Kunden- und Artikelinformationen//) und sind somit anfällig für [[anomalie|Anomalien]]. | + | * BST_Datum |
| + | * BST_Bezahlt | ||
| + | * ART_Anzahl | ||
| + | * ART_Bez | ||
| + | * ART_Details | ||
| + | * ART_Auslauf | ||
| + | * ART_Preis | ||
| + | |||
| + | Abgesehen davon, dass die Tabelle sehr unübersichtlich ist, werden Informationen mehrfach definiert (//beispielsweise die Kunden- und Artikelinformationen, unnötige Datenredundanz//) und sind somit anfällig für [[anomalie|Anomalien]]. | ||
| Diese Tabelle muss in mehrere Tabellen aufgeteilt werden - ein korrekter Ansatz wäre: | Diese Tabelle muss in mehrere Tabellen aufgeteilt werden - ein korrekter Ansatz wäre: | ||
| - | Tabellen für: | + | Dedizierte Tabellen für: |
| * Kunden | * Kunden | ||
| * Artikel | * Artikel | ||
| Zeile 105: | Zeile 111: | ||
| Was wurde geändert? | Was wurde geändert? | ||
| - | * Es gibt nun seperate Tabellen für Kunden, Artikel, Bestellungen und Bestellungspositionen ((//Definition von gekauften Artikeln//) | + | * Es gibt nun seperate Tabellen für Kunden, Artikel, Bestellungen und Bestellungspositionen (//Definition gekaufter Artikeln//) |
| * Alle Informationen in den Tabellen sind vom Primärschlüssel abhängig | * Alle Informationen in den Tabellen sind vom Primärschlüssel abhängig | ||
| Zeile 117: | Zeile 123: | ||
| Die Tabellen **ARTIKEL**, **BESTELLUNGEN** und **BESTELL_POS** liegen bereits in der dritten Normalform vor - lediglich die Tabelle **KUNDEN** liegt noch nicht in der dritten Normalform vor. | Die Tabellen **ARTIKEL**, **BESTELLUNGEN** und **BESTELL_POS** liegen bereits in der dritten Normalform vor - lediglich die Tabelle **KUNDEN** liegt noch nicht in der dritten Normalform vor. | ||
| - | Der Grund ist das Feld **KND_Ort**. Der Name eines Orts ist von seiner zugehörigen Postleitzahl, **KND_PLZ**, abhängig. Dieses Feld wird also ausgelagert: | + | Der Grund ist das Feld **KND_Ort**. Der Name eines Orts ist von seiner zugehörigen Postleitzahl, **KND_PLZ**, und nicht vom Kunden abhängig. Dieses Feld wird also in einer weiteren dedizierten Tabelle ausgelagert: |
| ^KUNDEN^^^^^^^^ | ^KUNDEN^^^^^^^^ | ||
| Zeile 128: | Zeile 134: | ||
| |1|12345|Musterstadt| | |1|12345|Musterstadt| | ||
| |2|55353|Testort| | |2|55353|Testort| | ||
| + | |||
| + | Orte werden nun in einer dedizierten Tabelle gesichert - eine Verknüpfung zu den Kundeninformationen erfolgt über einen Fremdschlüssel. | ||
| <note>In dieser Tabelle wird explizit ein eigener Primärschlüssel definiert. Die Spalte **ORT_PLZ** eignet sich nicht als Primärschlüssel. | <note>In dieser Tabelle wird explizit ein eigener Primärschlüssel definiert. Die Spalte **ORT_PLZ** eignet sich nicht als Primärschlüssel. | ||
| Warum? Ganz einfach - Postleitzahlen können auch durchaus mit einer 0 beginnen, in einem solchen Fall würde die 0 abgeschnitten werden und zu Fehlinformationen führen.</note> | Warum? Ganz einfach - Postleitzahlen können auch durchaus mit einer 0 beginnen, in einem solchen Fall würde die 0 abgeschnitten werden und zu Fehlinformationen führen.</note> | ||