Von der 1. zur 2. Normalform – woran erkenne ich eine partielle Abhängigkeit?

AnnaWInf

Hi zusammen, ich komm bei der Normalisierung ins Straucheln. Die 1. Normalform (atomare Werte) krieg ich hin, und die 3. verstehe ich vom Prinzip. Aber der Schritt 1. NF → 2. NF und diese „partielle Abhängigkeit“ will mir einfach nicht in den Kopf.

Woran erkenne ich konkret, dass ich eine Tabelle in die 2. NF aufteilen muss? Am liebsten an einem Beispiel.

DanielIT

Der Knackpunkt: Die 2. NF ist nur dann ein Thema, wenn du einen zusammengesetzten Primärschlüssel hast (also aus mehreren Spalten). Bei einem einzelnen Schlüsselfeld bist du automatisch schon in der 2. NF.

Beispiel: Tabelle Bestellposition mit dem Schlüssel (BestellNr, ArtikelNr) und den Spalten Menge, Artikelbezeichnung, Kundenname.

Menge hängt von der ganzen Kombination ab (voll funktional abhängig) – korrekt.
Artikelbezeichnung hängt nur von der ArtikelNr ab, also nur von einem Teil des Schlüssels. Das ist die partielle Abhängigkeit.
Kundenname hängt nur von der BestellNr ab – auch partiell.

Regel: Sobald ein Nicht-Schlüsselattribut nur von einem Teil des zusammengesetzten Schlüssels abhängt, lagerst du es aus.

Tobi89

Daniels Beispiel ist perfekt. Zum „Woran erkenne ich es“: Frag bei jedem Nicht-Schlüsselattribut „Brauche ich wirklich den kompletten Schlüssel, um diesen Wert eindeutig zu bestimmen?“

Ja, den ganzen Schlüssel → bleibt in der Tabelle.
Nein, ein Teil reicht → raus in eine eigene Tabelle (z. B. Artikel-Tabelle mit ArtikelNr + Bezeichnung).

Der praktische Grund dahinter ist die Redundanz: In der unnormalisierten Version steht die Artikelbezeichnung bei jeder Bestellung erneut. Änderst du sie mal, musst du sie überall ändern (Update-Anomalie). Nach der Aufteilung steht sie genau einmal. Genau das ist der Sinn der Übung.

DanielIT

Zur 2. Normalform noch ein Beispiel aus einem echten Projekt, weil der abstrakte „partielle Abhängigkeit“-Begriff dann sofort klick macht: Wir hatten eine Tabelle Bestellposition (BestellNr, ArtikelNr, Menge, Artikelbezeichnung, Einzelpreis) mit dem zusammengesetzten Schlüssel (BestellNr, ArtikelNr).

Das Problem: Artikelbezeichnung und Einzelpreis hängen nur von der ArtikelNr ab, nicht von der ganzen Bestellung. Ergebnis: Jede Bestellung, die denselben Artikel enthielt, wiederholte den Namen – und als ein Artikel umbenannt wurde, war er in hunderten Zeilen inkonsistent (klassische Update-Anomalie). Nach dem Auslagern in eine eigene Artikel-Tabelle stand der Name genau einmal. Genau dafür ist die 2. NF da.

Von der 1. zur 2. Normalform – woran erkenne ich eine partielle Abhängigkeit?

Jetzt mitmachen!

Letzte Beiträge

Passwörter speichern: Warum hasht man sie, statt sie zu verschlüsseln – und wozu dann noch ein „Salt“? 2

Unit-Test, Integrationstest, Abnahmetest – wer testet eigentlich was, und was hat das Pflichtenheft damit zu tun? 3

Schnittstellen zwischen zwei Systemen – warum ist der Datenaustausch in der Praxis so aufwendig? 2

Standardsoftware kaufen oder selbst entwickeln lassen – nach welchen Kriterien entscheide ich Make-or-Buy? 2

IT-Sicherheit: Vertraulichkeit, Integrität, Verfügbarkeit – wo ordne ich Verschlüsselung, Signatur und Backup jeweils ein? 2

Geschäftsprozess modellieren: EPK oder BPMN – und wann nehme ich XOR, UND oder ODER? 3

Lastenheft und Pflichtenheft – wer schreibt eigentlich was, und warum trennt man das überhaupt? 2

Drei-Schichten-Architektur – warum trennt man Oberfläche, Logik und Datenhaltung überhaupt? 3

ERP-System – was macht das eigentlich konkret, und warum reicht dafür nicht eine gute Excel-Lösung? 3

GROUP BY und HAVING – wann filtere ich mit WHERE und wann erst nach der Gruppierung? 3

Passwörter speichern: Warum hasht man sie, statt sie zu verschlüsseln – und wozu dann noch ein „Salt“?

Unit-Test, Integrationstest, Abnahmetest – wer testet eigentlich was, und was hat das Pflichtenheft damit zu tun?

Schnittstellen zwischen zwei Systemen – warum ist der Datenaustausch in der Praxis so aufwendig?

Standardsoftware kaufen oder selbst entwickeln lassen – nach welchen Kriterien entscheide ich Make-or-Buy?

IT-Sicherheit: Vertraulichkeit, Integrität, Verfügbarkeit – wo ordne ich Verschlüsselung, Signatur und Backup jeweils ein?

Über Study-Board.de