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.
Link zur hiesigen Seite als QR-Code
Kontaktformular:
Schreiben Sie mir und wir bauen gemeinsam Ihre neue Web-Datenbank!
Mit dem Klick auf den Button stimmen Sie zu, daß Cookies in Ihrem Browser gespeichert werden. Informationen zu den gespeicherten Cookies finden Sie unter Datenschutz#Cookies.Bei Fragen zur Technik wenden Sie sich bitte an Server-Daten - Web-Datenbank-Lösungen