Normalisierung einer Datenbank am konkreten Beispiel – Anwendungsentwickler-Podcast #144

Wir gehen ein komplettes Beispiel zur Normalisierung einer relationalen Datenbank durch in der einhundertvierundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Probeabo bei Audible (Affiliate)

Inhalt

Theoretische Grundlagen

  • Wir normalisieren Datenbanken um Redundanzen zu vermeiden, die zu Anomalien führen können. Mehr dazu in Podcast-Episode 18.
  • Grundlagen wie Schlüssel, Kardinalitäten usw. erkläre ich in Podcast-Episode 17.
  • Merksatz: „The key, the whole key, and nothing but the key.“

Beispieldaten

Wir verwenden ein „klassisches“ Beispiel, das so oder ähnlich in vielen IHK-Prüfungen genutzt wird.

  • Umfeld: Kunden bestellen Artikel aus verschiedenen Artikelgruppen.
  • Ein Kunde kann mehrere Bestellungen durchführen. Eine Bestellung wird immer von genau einem Kunden getätigt.
  • Zu den Kunden werden Name und Adresse erfasst.
  • Jede Bestellung hat ein Bestelldatum.
  • In einer Bestellung können mehrere Artikel enthalten sein. Ein Artikel kann auch in mehreren Bestellungen auftauchen.
  • Artikel haben eine Bezeichnung und einen Preis.
  • Ein Artikel kann zu genau einer Artikelgruppe gehören. Eine Artikelgruppe kann mehrere Artikel enthalten.
  • Artikelgruppen haben eine Bezeichnung und einen Rabatt.

Ausgangssituation (nicht normalisiert)

  • Alle Bestellungen stehen in einer einzelnen Tabelle. Jede Bestellung steht komplett inkl. mehrerer Artikel in einer Zeile. Die Adresse steht komplett in einem einzigen Attribut.
  • Beispiele für Probleme: Viele Redundanzen (z.B. Adressen, Artikelbezeichnungen), Sortierung nach Ort ist nicht möglich, Selektion aller gekaufter Fernseher ist nicht möglich.

Nicht normalisierte Tabelle mit Kunden, Bestellungen und Artikeln

1. Normalform

  • Definition: Es gibt 1) nur atomare Attribute und 2) keine Wiederholungsgruppen.
  • „the key“: Alle Datensätze sind eindeutig über einen Primärschlüssel identifizierbar.
  • Durch 2) werden Redundanzen zunächst eingeführt, da aus einer Zeile nun mehrere Zeilen mit redundanten Inhalten werden.
  • Vorgehen: Nicht-atomare Attribute auf mehrere Spalten aufteilen. Wiederholungsgruppen auf mehrere Zeilen aufteilen.
  • Ein Datensatz ist über einen zusammengesetzten Schlüssel aus drei Attributen identifizierbar.
  • Redundanzen: Kunden-, Bestell- und Artikeldaten sind jeweils mehrfach vorhanden.
  • Ursache: Tabelle enthält drei Konzepte (Kunde, Bestellung, Artikel), die alle nur von Teilen des Schlüssels abhängen und nicht vom gesamten.

Tabelle mit Kunden, Bestellungen und Artikeln in 1. Normalform

2. Normalform

  • Definition: (1. Normalform erfüllt und) alle Attribute sind voll funktional vom Primärschlüssel abhängig.
  • „the whole key“: Alle Attribute hängen vom gesamten Schlüssel ab (und nicht nur von seinen Teilen).
  • Vorgehen: Alle drei Konzepte auf einzelne Tabellen aufteilen. Fremdschlüssel für Referenzen einführen. Zuordnungstabelle Position mit zusammengesetztem Schlüssel aus Fremdschlüsseln einführen.
  • m:n-Beziehungen werden aufgelöst.
  • Menge gehört an die Kombination aus Bestellung und Artikel und weder an das eine noch das andere allein.
  • Redundanzen: Artikelgruppe und Rabatt gehören zusammen und sind mehrfach vorhanden.
  • Ursache: Rabatt hängt von Artikelgruppe ab und nicht von der Artikelnummer (=transitive Abhängigkeit).

Tabellen mit Kunden, Bestellungen und Artikeln in 2. Normalform

3. Normalform

  • Definition: (2. Normalform erfüllt und) es gibt keine transitiven Abhängigkeiten.
  • „and nothing but the key“: Kein Nicht-Schlüssel-Attribut hängt von einem anderen Nicht-Schlüssel-Attribut ab.
  • Vorgehen: Artikelgruppe in eigene Tabelle extrahieren und Fremdschlüssel für Referenz einführen.
  • 1:n-Beziehungen werden aufgelöst.

Tabellen mit Kunden, Bestellungen, Artikeln und Artikelgruppen in 3. Normalform

Ergebnis

  • Jede Tabelle enthält genau ein Konzept.
  • Keine Daten sind mehr redundant.
  • In jeder Tabelle gibt es einen eindeutigen Primärschlüssel.
  • Fremdschlüssel werden für Referenzen auf Datensätze in anderen Tabellen verwendet.

Literaturempfehlungen

Zum Einstieg ins Thema Datenbanken inkl. Modellierung, Normalisierung und SQL empfehle ich Einstieg in SQL* von Michael Laube.

Einstieg in SQL: Für alle wichtigen Datenbanksysteme: MySQL, PostgreSQL, MariaDB, MS SQL. Ohne Vorkenntnisse einsteigen! (Affiliate)*

Links

Aktuelle Stellenangebote in Vechta

Du bist auf der Suche nach einem neuen Job und könntest dir vorstellen, mein:e neue:r Kolleg:in zu werden? Dann bewirb dich jetzt bei der ALTE OLDENBURGER Krankenversicherung AG in Vechta.

Portrait von Stefan Macke
Polyglot Clean Code Developer
Über den Autor
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

7 comments on “Normalisierung einer Datenbank am konkreten Beispiel – Anwendungsentwickler-Podcast #144

  1. Reza sagt:

    Hi
    Wollte ich gerne als PDF habe ist das möglich?

  2. Stefan Macke sagt:

    Was möchtest du als PDF haben?

  3. Matthias sagt:

    Danke für die Erklärung, Stefan! 🙂

  4. Jonathan sagt:

    Hallo Stefan

    Danke für die schöne Aufteilung und Beschreibung von der 0. Normalform auf die 3. Normalform.
    Was mich allerdings stört ist die Spalte Rabatt, der an den PK Artikelgruppe gekoppelt ist, also hat man automatisch 10% Rabatt, wenn man einen Artikel aus der Artikelgruppe Elektronik bzw. Peripherie bestellt?
    Würde es da Sinn machen eine neue Tabelle Rabatt einzuführen?

    Außerdem könnten auch bestimme Kunden (Mitarbeiter, Unternehmen) Rabatte bekommen?

    Beste Grüße
    Jonathan

  5. Stefan Macke sagt:

    Hallo Jonathan, je nach Datenmodell kann es sinnvoll sein, deine Ergänzungen durchzuführen. Aber das Beispiel ist natürlich einfach gewählt, um die Grundlagen zu erklären. Allerdings wäre eine Tabelle Rabatt wohl unsinnig, denn was soll darin stehen? Rabatt-ID 1, Rabatt-Satz 10%. Welche Felder sind hier sonst noch sinnvoll? Du kannst auch einfach die 10 als Wert für Rabatt in die Tabellen eintragen.

  6. Diaa sagt:

    Hello Stefen,

    vielen lieben Dank für Ihre Mühe und die sehr gute Materialen.
    Hiere habe ich eine Frage:
    Warum brauchen wir die Kundennummer-Attribute in 1. NF als Primärschlüssel?
    Meiner Meinung nach reicht es die Bestellungsnummer & Artikelnummer, um einen Datensatz deutlich zu identifizieren.

    Noch einen Wunsch:
    Schwierigkeiten habe ich immer bei der IHK-Aufgaben, den Primärschlüssel in 2.NF herauszufinden 🙁
    z.B. eine Tabele besteht aus folgenden Spalten:

    Bestell-Nr. Datum Lieferant Artikel Menge Einzelpreis

    Was sollte der Primärschlüssel sein? Könnten Sie uns vielleicht einen Tip uns geben?

    Vielen Dank nochmal

  7. Stefan Macke sagt:

    Hallo Diaa,

    da hast du recht! Im Beispiel wäre ein Datensatz mit Bestellnummer und Artikelnummer bereits eindeutig identifiziert! Ich habe die Kundennummer nur dazugenommen, um zu zeigen, dass eigentlich drei „Dinge“ in einer Tabelle verwurstet werden.

    Zu deinem Beispiel: Die gezeigte Tabelle ist nicht in der 2. Normalform! Bestellung/Artikel (und ggfs. Artikel/Lieferant) sind m:n-Beziehungen, die in der 2. NF bereits aufgelöst sein müssten. Daher hast du auch Schwierigkeiten, den Schlüssel zu bestimmen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax