Daten verwalten - die denormalisierte Tabelle als Ausgangspunkt für die Definition der Relationen / des Tabellenschemas

  • Aufgabe einer Datenbank ist es, alle Informationen zu einer Thematik zusammenzutragen. Hierbei kann es sich um sämtliche Geschäftsvorfälle einer Firma oder um ein privates Werkzeug-Archiv handeln. Bei der Firma sollen alle Mitarbeiter-, Lieferanten- und Kundendaten sowie jede einzelne Bestellung erfaßt werden. Das private Werkzeug-Archiv bestehe aus tausenden von Gegenständen, gegliedert in diverse Kategorien, verteilt auf verschiedene Kästen und Regale.
  • Sollen all diese Informationen erfaßt werden, so kann dies nach einem einfachen Schema realisiert werden: Zu jedem Detail gibt es eine Spalte. Findet irgendeine Aktivität statt, so wird eine Zeile hinzugefügt und die bei dieser Aktivität ermittelten Informationen in die zur Zeile gehörenden Zellen eingetragen. Alle bei diesem Geschäftsvorfall nicht benötigten Zellen bleiben leer. Eine solche Tabelle kann auch als vollständig denormalisierte Tabelle bezeichnet werden.
  • Beispiel 1:

    U_NRA_NAMEA_PREISA_STUECKDATUMV_NAMEV_ANSCH
    1Oberhemd39,804024.06.1999Meyer, EmilWendeweg 10, 2800 Bremen
    2Mantel360,001024.06.1999Meier, FranzKohlstr. 1, 2800 Bremen
    3Oberhemd44,207024.06.1999Meyer, EmilWendeweg 10, 2800 Bremen
    4Oberhemd44,202025.06.1999Schulze, FritzGemüseweg 3, 2800 Bremen
    5Mantel360,003525.06.1999Meier, FranzKohlstr. 1, 2800 Bremen
    6Hose110,503524.06.1999Meyer, EmilWendeweg 10, 2800 Bremen
    7Hose110,50524.06.1999Schulze, FritzGemüseweg 3, 2800 Bremen
    8Oberhemd39,801024.06.1999Schulze, FritzGemüseweg 3, 2800 Bremen
    9Oberhemd44,202025.06.1999Meyer, EmilWendeweg 10, 2800 Bremen

    Dieses Beispiel scheint relativ klar strukturiert zu sein, so daß man eine solche denormalisierte Tabelle rasch in drei Tabellen zerlegen könnte. Werden allerdings tagesaktuelle Preise berücksichtigt, so stellt sich die Frage, ob der Preis in die Artikel- oder in die Umsatztabelle eingetragen wird.

  • Beispiel 2:

    lfNrLiefer-NrDatumArtikel (E)LieferantEPZahlArtikel (V)EmpfängerEPZahl
    12415.2.2003Hosen, blauFA Muster-Liefer GbR, Nürnberg39.9050
    22415.2.2003Hose, braunFA Muster-Liefer GbR, Nürnberg39.9050
    32716.2.2003HosenMax Müller, Berlin49.9010
    42817.2.2003HemdenFA Groß-Handel AG, Hamburg18.4030
    52817.2.2003HemdenFA Groß-Handel AG, Hamburg18.4040
    63518.2.2003HemdenLisa Mayer, München23.905

Merkmale und Nachteile einer vollständig denormalisierten Tabelle

  • Einerseits läßt sich offenkundig jede Information in eine solcherart strukturierte, sehr viele Spalten umfassende Tabelle einsortieren. Wird die Archivierung zusätzlicher Informationen gewünscht, so genügt es, weitere Zeilen hinzuzufügen und diese gegebenenfalls leer zu lassen. Jede Datenbank könnte sich theoretisch damit begnügen, eine einzige, nach diesem Muster strukturierte Tabelle zu enthalten. Im extremsten Fall würde die Tabelle eine einzige große Textspalte enthalten, in welcher sämtliche Informationen der Reihe nach aufgeführt wären. Andererseits weist diese Form der internen Darstellung offensichtliche Nachteile auf, die im folgenden zu diskutieren sind.
  • Die Redundanz dieser Beispiele ist offenkundig. So werden im ersten Beispiel dieselben Adressdaten mehrfach aufgeführt, so daß bei einer Änderung einer Adresse mehrere gleichlautende Zellen gesucht und umgeschrieben werden müssten. In solch einem Fall spricht man von einer Update-Anomalie. Dann könnte es zwei verschiedene Personen mit demselben Vor- und Nachnamen geben, so daß bei der dem Update vorgeschalteten Suche mehrere Adressen gefunden und anschließend geändert werden. Eindeutige Personen sollten eindeutig charakterisierbar sein.
  • Werden im Beispiel 2 alle Hosen gesucht, so muß mit einer Platzhaltersuche gearbeitet werden, die nach 'Hose*' oder '*Hose*' sucht und den '*' als Platzhalter nutzt. Denn die Zelle 'Einkauf: Artikel' enthält mehrere Informationen gleichzeitig. Interessiert nur eine Teilinformation, so ist unbekannt, wo diese steht (am Anfang oder in der Zellenmitte), so daß der zu suchende Ausdruck von beiden Seiten her durch einen Platzhalter ergänzt werden muß. Ein vergleichbares Problem existiert bei der Suche nach Ortschaften. Eine Person, die als Nachname ein Wort hat, das gleichzeitig als Ort eingetragen ist, würde bei der Suche nach dem Ort gefunden werden.
  • Eine solche Tabelle scheint nur Text zu enthalten. Damit könnte in die Datumszelle auch Text eingetragen oder bei den Preisangaben anstelle des Punktes ein Komma als Trennzeichen verwendet werden, so daß der Wert nicht mehr korrekt für Rechenoperationen verwendet werden kann.
  • Das Beispiel 2 umfaßt derzeit nur Bestellungen und Lieferungen. Würde die Lieferung an 'Lisa Mayer' gelöscht oder storniert werden, so würden auch die Adressangaben verschwinden, obwohl diese vielleicht noch notwendig sind. Dies wird als Delete-Anomalie benannt. Eine Alternative bestünde darin, 'Lisa Mayer' ohne eine Lieferung einzutragen. Damit dürfen die für eine Lieferung zwingend notwendigen Felder nicht mit NOT NULL deklariert sein, das DBMS kann nicht die Konsistenz der Eingabe sicherstellen. Wäre dagegen eine Bestellung zwingend, so wäre dies ein Beispiel für eine Insert-Anomalie. Selbst bei der Zulässigkeit einer Person ohne Bestellung ist unklar, ob die Daten in die Spalte 'Lieferant' oder 'Empfänger' einzutragen sind. Schließlich ist der Fall denkbar, daß eine Firma sowohl Lieferant als auch Empfänger ist oder an eine als Mitarbeiter eingetragene Person Waren gesandt werden.
  • Liefert die Firma 'Muster-Liefer' verschiedenfarbige Hosen, so kann diese Information ignoriert werden. Damit ist es später unmöglich, die Einkaufs- und Verkaufszahlen nach den Farben der Hosen aufzuschlüsseln. Wird diese Information zusätzlich abgelegt, so müssen auch sämtliche Adressdaten erneut eingegeben werden, so daß die Wahrscheinlichkeit von Eingabefehlern steigt. Ein Verschreiber 'FI Muster-Liefer' würde bei einer Textsuche nach 'FA Muster-Liefer*' zum Verschwinden dieses Datensatzes führen.
  • Die beiden Lieferungen am 15.02.2003 betreffen verschiedene Artikel. Die zwei Lieferungen vom 17.02.2003 dagegen könnten zu einer Lieferung mit 70 Stück zusammengefaßt werden, da die Zellwerte, mit Ausnahme der Spalte 'Stückzahl', identisch sind und bei der Stückzahl die Addition zweier Einzelinformationen sinnvoll ist.
Offenkundig produziert ein solches Design diverse Probleme und fehlerhafte Auswertungen. Zwar wäre im Gegensatz zu jedem Archiv in Papierform eine reine Textsuche möglich. Jedoch müßten die Ergebnisse erneut per Hand geprüft werden, jede fehlerhafte Eingabe läßt sich nur durch die Kontrolle der Originalzelle ermitteln. Deshalb würde ein solches, denormalisiertes Design all jene Vorzüge einer edv-gestützten Datenarchivierung zunichte machen.

Die folgenden Seiten beschäftigen sich deshalb mit den datenbank-typischen Techniken, eine solche denormalisierte Tabelle in mehrere kleinere Tabellen zu zerlegen.

Link zur hiesigen Seite als QR-Code

Kontaktformular:

Schreiben Sie mir und wir bauen gemeinsam Ihre neue Web-Datenbank!

Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.

© 2003-2023 Jürgen Auer, Berlin.