Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- computer:tutorials:sql:normalisierung [2011/03/03 16:16] – [3.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 113: / 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.
-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^^^^^^^^
@@ Zeile 124: / Zeile 134: @@
 |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