Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
| computer:tutorials:sql:normalisierung [2011/03/03 15:30] – christian | computer:tutorials:sql:normalisierung [2013/05/13 08:01] (aktuell) – [3.Normalform] christian | ||
|---|---|---|---|
| Zeile 36: | Zeile 36: | ||
| Der oben angezeigt Entwurf erfüllt keine der drei Bedingungen - die Gründe sind: | Der oben angezeigt Entwurf erfüllt keine der drei Bedingungen - die Gründe sind: | ||
| - | * Es sind Spalten mit gleichen Inhalten vorhanden - es gibt zwei Spalten für Kundennotizen und bestellte Artikel: **KND_Notiz** und **KND_Notiz2**. | + | * Es sind Spalten mit gleichen Inhalten vorhanden - es gibt zwei Spalten für Kundennotizen und bestellte Artikel: **KND_Notiz** und **KND_Notiz2** sowie **ART_1** und **ART_2**. |
| - | * Es gibt Werte, die sich weiter teilen | + | * Es gibt Werte, die sich weiter teilen |
| + | * Das Feld **KND_Name** lässt sich in zwei seperate Felder für den Vor- und Nachnamen des Kunden aufteilen | ||
| + | * Das Feld **KND_Adresse** | ||
| + | | ||
| + | * Da es nur zwei Spalten gibt, können Bestellungen nur zwei Positionen umfassen | ||
| * Es gibt doppelte Einträge - die letzten beiden Datensätze sind identisch - hier hat sich der Entwickler wohl vertippt und somit eine unnötige Redundanz erschaffen. Solche Mehrfach-Einträge lassen sich mit dem Verwenden eines **Primärschlüssels** vermeiden. | * Es gibt doppelte Einträge - die letzten beiden Datensätze sind identisch - hier hat sich der Entwickler wohl vertippt und somit eine unnötige Redundanz erschaffen. Solche Mehrfach-Einträge lassen sich mit dem Verwenden eines **Primärschlüssels** vermeiden. | ||
| Zeile 51: | Zeile 55: | ||
| * Die Felder für den Kundennamen, | * Die Felder für den Kundennamen, | ||
| * Die Felder **KND_Notiz** und **KND_Notiz2** sowie **ART1** und **ART2** waren "// | * Die Felder **KND_Notiz** und **KND_Notiz2** sowie **ART1** und **ART2** waren "// | ||
| + | |||
| + | |||
| + | |||
| + | ======2.Normalform====== | ||
| + | Die zweite Normalform liegt vor, wenn die folgenden Bedingungen erfüllt werden: | ||
| + | * Erfüllung der 1.Normalform | ||
| + | * alle Spalten sind vom Primärschlüssel abhängig | ||
| + | * alle Informationen werden an einer Stelle und nicht mehrfach gesichert (//keine Datenredundanz// | ||
| + | |||
| + | Diese Bedingungen werden vom aktuellen Entwurf nicht erfüllt: | ||
| + | ^ID^KND_Vorname^KND_Nachname^KND_Firma^KND_Strasse^KND_HausNr^KND_PLZ^KND_Ort^KND_Notiz^BST_Datum^BST_Bezahlt^ART_Anzahl^ART_Bez^ART_Details^ART_Auslauf^ART_Preis^ | ||
| + | |1|Max|Mustermann|Mustermann Consulting|Musterstrasse|1|12345|Musterstadt| |10.10.2010|ja|10|Thin-Client BAER|1.6 Ghz, | ||
| + | |2|Max|Mustermann|Mustermann Consulting|Musterstrasse|1|12345|Musterstadt| |10.10.2010|ja|15|Thin-Client NP|1.0 Ghz, | ||
| + | |3|Theodor|Tester|Test-Solutions AG|Testweg|16|55353|Testort|Offene Rechnung|15.02.2011|nein|1|Thin-Client BAER|1.6 Ghz, | ||
| + | |||
| + | Es sind Spalten vorhanden, die nicht vom Primärschlüssel **ID** (//Kunde//) abhängig sind: | ||
| + | * 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 (// | ||
| + | |||
| + | Diese Tabelle muss in mehrere Tabellen aufgeteilt werden - ein korrekter Ansatz wäre: | ||
| + | |||
| + | Dedizierte Tabellen für: | ||
| + | * Kunden | ||
| + | * Artikel | ||
| + | * Bestellungen | ||
| + | * Bestellungspositionen | ||
| + | |||
| + | ^KUNDEN^^^^^^^^^ | ||
| + | ^KND_Nr^KND_Vorname^KND_Nachname^KND_Firma^KND_Strasse^KND_HausNr^KND_PLZ^KND_Ort^KND_Notiz^ | ||
| + | |1|Max|Mustermann|Mustermann Consulting|Musterstrasse|1|12345|Musterstadt| | | ||
| + | |2|Theodor|Tester|Test-Solutions AG|Testweg|16|55353|Testort|Offene Rechnung Nr.3| | ||
| + | |||
| + | ^ARTIKEL^^^^^ | ||
| + | ^ART_Nr^ART_Bezeichnung^ART_Details^ART_Auslauf^ART_Einzelpreis^ | ||
| + | |1|Thin-Client BAER|1.6 Ghz, | ||
| + | |2|Thin-Client NP|1.0 Ghz, | ||
| + | |||
| + | ^BESTELLUNGEN^^^^ | ||
| + | ^BST_Nr^KND_Nr^BST_Datum^BST_Bezahlt^ | ||
| + | |1|1|10.10.2010|ja| | ||
| + | |2|2|15.02.2011|nein| | ||
| + | |||
| + | ^BESTELL_POS^^^^ | ||
| + | ^BPOS_Nr^BST_Nr^ART_Nr^BPOS_Anzahl^ | ||
| + | |1|1|1|10| | ||
| + | |2|1|2|15| | ||
| + | |3|2|1|1| | ||
| + | |||
| + | Was wurde geändert? | ||
| + | * Es gibt nun seperate Tabellen für Kunden, Artikel, Bestellungen und Bestellungspositionen (// | ||
| + | * Alle Informationen in den Tabellen sind vom Primärschlüssel abhängig | ||
| + | |||
| + | |||
| + | |||
| + | ======3.Normalform====== | ||
| + | Die dritte Normalform liegt vor, wenn die folgenden Bedingungen erfüllt werden: | ||
| + | * Erfüllung der 2.Normalform | ||
| + | * Auslagerung aller Felder die inhaltlich nicht vom Primärschlüssel abhängig sind | ||
| + | |||
| + | Die Tabellen **ARTIKEL**, | ||
| + | |||
| + | Der Grund ist das Feld **KND_Ort**. Der Name eines Orts ist von seiner zugehörigen Postleitzahl, | ||
| + | |||
| + | ^KUNDEN^^^^^^^^ | ||
| + | ^KND_Nr^KND_Vorname^KND_Nachname^KND_Firma^KND_Strasse^KND_HausNr^KND_Ort^KND_Notiz^ | ||
| + | |1|Max|Mustermann|Mustermann Consulting|Musterstrasse|1|1| | | ||
| + | |2|Theodor|Tester|Test-Solutions AG|Testweg|16|2|Offene Rechnung Nr.3| | ||
| + | |||
| + | ^ORTE^^^ | ||
| + | ^ORT_Nr^ORT_PLZ^ORT_Name^ | ||
| + | |1|12345|Musterstadt| | ||
| + | |2|55353|Testort| | ||
| + | |||
| + | Orte werden nun in einer dedizierten Tabelle gesichert - eine Verknüpfung zu den Kundeninformationen erfolgt über einen Fremdschlü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.</ | ||