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

• » Home
• »Sql-Tutorial
• » Tabellen als Relationen

• 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_NR	A_NAME	A_PREIS	A_STUECK	DATUM	V_NAME	V_ANSCH
  1	Oberhemd	39,80	40	24.06.1999	Meyer, Emil	Wendeweg 10, 2800 Bremen
  2	Mantel	360,00	10	24.06.1999	Meier, Franz	Kohlstr. 1, 2800 Bremen
  3	Oberhemd	44,20	70	24.06.1999	Meyer, Emil	Wendeweg 10, 2800 Bremen
  4	Oberhemd	44,20	20	25.06.1999	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
  5	Mantel	360,00	35	25.06.1999	Meier, Franz	Kohlstr. 1, 2800 Bremen
  6	Hose	110,50	35	24.06.1999	Meyer, Emil	Wendeweg 10, 2800 Bremen
  7	Hose	110,50	5	24.06.1999	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
  8	Oberhemd	39,80	10	24.06.1999	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
  9	Oberhemd	44,20	20	25.06.1999	Meyer, Emil	Wendeweg 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:

  lfNr	Liefer-Nr	Datum	Artikel (E)	Lieferant	EP	Zahl	Artikel (V)	Empfänger	EP	Zahl
  1	24	15.2.2003	Hosen, blau	FA Muster-Liefer GbR, Nürnberg	39.90	50
  2	24	15.2.2003	Hose, braun	FA Muster-Liefer GbR, Nürnberg	39.90	50
  3	27	16.2.2003					Hosen	Max Müller, Berlin	49.90	10
  4	28	17.2.2003	Hemden	FA Groß-Handel AG, Hamburg	18.40	30
  5	28	17.2.2003	Hemden	FA Groß-Handel AG, Hamburg	18.40	40
  6	35	18.2.2003					Hemden	Lisa Mayer, München	23.90	5

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.