Benutzer-Werkzeuge

Webseiten-Werkzeuge


computer:tutorials:sql:normalisierung

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
computer:tutorials:sql:normalisierung [2011/03/03 15:30]
christian
computer:tutorials:sql:normalisierung [2013/05/13 08:01] (aktuell)
christian [3.Normalform]
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 ​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.   * 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 Kundenadresse,​ Kundennotizen und das Feld mit Informationen über die bestellten Artikel wurden in **atomare** Felder aufgeteilt   * Die Felder für den Kundennamen,​ die Kundenadresse,​ Kundennotizen und das Feld mit Informationen über die bestellten Artikel wurden in **atomare** Felder aufgeteilt
   * Die Felder **KND_Notiz** und **KND_Notiz2** sowie **ART1** und **ART2** waren "//​doppelt//",​ es waren zwei Felder mit dem selben informationstechnischen Nutzen - sie sollten Informationen über bestellte Artikel beinhalten. Sie wurden aufgeteilt, für alle Artikelinformationen (//​Bezeichnung,​ Details, Auslaufartikel,​ Preis//) gibt es nun dedizierte Felder.   * Die Felder **KND_Notiz** und **KND_Notiz2** sowie **ART1** und **ART2** waren "//​doppelt//",​ es waren zwei Felder mit dem selben informationstechnischen Nutzen - sie sollten Informationen über bestellte Artikel beinhalten. Sie wurden aufgeteilt, für alle Artikelinformationen (//​Bezeichnung,​ Details, Auslaufartikel,​ Preis//) gibt es nun dedizierte Felder.
 +
 +
 +
 +======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,​Sound,​VGA,​USB|nein|199.99|
 +|2|Max|Mustermann|Mustermann Consulting|Musterstrasse|1|12345|Musterstadt| |10.10.2010|ja|15|Thin-Client NP|1.0 Ghz,​Sound,​VGA+DVI,​USB|ja|179.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** (//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 (//​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:
 +
 +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,​Sound,​VGA,​USB|nein|199.99|
 +|2|Thin-Client NP|1.0 Ghz,​Sound,​VGA+DVI,​USB|ja|179.99|
 +
 +^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 (//​Definition gekaufter Artikeln//)
 +  * 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**,​ **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>​
computer/tutorials/sql/normalisierung.1299162647.txt.gz · Zuletzt geändert: 2011/03/03 15:30 von christian