Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- computer:tutorials:sql:normalisierung [2011/03/03 15:57] – [2.Normalform] 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:
-  * 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 ließen. Das Feld **KND_Name** lässt sich in zwei seperate Felder für den Vor- und Nachnamen des Kunden aufteilen, ferner vereint das Feld **KND_Adresse** neben der Adresse auch die Hausnummer, die PLZ und den Ortnamen. Die Spalte **Artikel** enthält neben der Artikelbezeichnung auch die Artikeldetails und Anzahl der erworbenen Artikel. Alle Bestellungspositionen werden mittels Komma getrennt aufgelistet - die Einzelpreise werden auf ähnliche Art und Weise mittels Komma getrennt und aufgelistet.
+  * Es gibt Werte, die sich weiter teilen lassen.
+    * Das Feld **KND_Name** lässt sich in zwei seperate Felder für den Vor- und Nachnamen des Kunden aufteilen
+    * Das Feld **KND_Adresse** vereint neben der Adresse auch die Hausnummer, die PLZ und den Ortnamen.
+    * Es gibt zwei Felder **ART_1** und **ART_2** - diese enthalten neben der Artikelbezeichnung noch Artikeldetails, den Einzelpreis und die Anzahl der erworbenen Artikel
+      * Da es nur zwei Spalten gibt, können Bestellungen nur zwei Positionen umfassen - oder alle Posistionen müssen in die beiden Spalten geschrieben werden
   * 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 58: / Zeile 62: @@
   * Erfüllung der 1.Normalform
   * 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:
@@ Zeile 68: / 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|
-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:
-Tabellen für:
+Dedizierte Tabellen für:
   * Kunden
   * Artikel
@@ Zeile 101: / Zeile 111: @@
 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
@@ Zeile 107: / Zeile 117: @@
 ======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**, **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**, und nicht vom Kunden abhängig. Dieses Feld wird also in einer weiteren dedizierten Tabelle ausgelagert:
+^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.
+<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>

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge