Viele meiner Studienkollegen und -Kolleginen spart sich während des Studiums der Informationswissenschaft das Kapitel über die Datenbanksysteme (aus unserer Informationswissenschaftler-„Bibel“ mit dem Kürzel ‚KSS‘). Die Folge ist die Verwendung unterschiedlicher Datenbank-ähnlichen-Tools fernab des „state of the art“. Dabei ist das so einfach… Es mag seltsam klingen, aber meiner Erfahrung nach haben vor allem Humanisten und Frauen mit diesem „Denksystem“ ein Problem. [Bitte beachten Sie: Dies ist nicht abwertend gemeint, sondern widerspiegelt meine Erfahrung und einen für mich unerklärlichen Zusammenhang.] Deshalb möchte ich es so darstellen, dass jeder es verstehen kann.
Für die Entstehung relationaler Datenbanksysteme ist vor allem die Idee der Normalisierung von Werten in einer Datenbank verantwortlich. Man möchte den Zustand erreichen, dass ein bestimmter Wert wie „25,8“ oder „rot“ nur einmal vorkommt – also nicht redundant (mehrfach) abgespeichert wird. Man benutzt einen Stellvertreter – die ID. Eine ID ist meist nummerisch und zwar deshalb, weil es für die Datenbank einfach ist, die nächte freie ID (für einen neuen Wert) zu generieren. Sie zählt einfach eins hoch (die_höchste_ID+1). Dies nennt man oft ‚autoincrement‘. Dies hat den Vorteil, dass das Schloss (die Burg) vom Schloss (in der Tür) unterschieden werden kann. Außerdem ist eine nummerische ID einfacher zu verarbeiten (weil kürzer) als lange Zeichenketten.
Das Erste, was Sie sich aus diesem Abschnitt merken sollen, ist die Tatsache, dass jeder Wert etwas eigenständiges ist. Die Farbe Rot ist nicht einfach nur ein „Anhängsel“ eines Autos. Rot ist ein eigener Wert, genau wie das Auto selbst! Beide gehen Koalitionen ein und sind niemals Bestandteile voneinander. Natürlich kann man nicht das Rot selbst sehen, weil es nur in Verbindung mit einem Träger vorkommt (wie Forma und Materia beim Aristoteles). Trotzdem: Auch wenn rot ein Adjektiv oder Adverb ist, ist es etwas eigenständiges, nichts minderwertiges…
Nun zum ersten Beispiel: wir erfassen Automarken mit den möglichen und üblichen Eigenschaften (Sprit, Farbe)
- Ferrari: Benziner; rot
Jetzt wird es aber kompliziert:
- Golf: Diesel oder Benziner; rot, blau oder silber
Was ist das Problem? Wir haben nur die Eigenschaft „Sprit“ (für einen Wert) und die Eigenschaft „Farbe“ (nicht „Farben“). Was ist die Lösung? Wir bauen für jedes der drei Dinge eigene Tabelle: eine für das Auto, eine für den Sprit und eine für die Farbe. Ferrari bekommt die ID 1 und Golf die ID 2. Es ergibt sich die Sprit-Tabelle (Sprit = AutoID):
- Benzin = 1
- Benzin = 2
- Diesel = 2
Schon mal besser. Jeder Wert kommt selbständig vor (die erste Normalform) anstatt ein Glied einer Kette zu sein. „Benzin“ kommt als Wert sowohl dem Ding mit der ID 1 (Ferrari) als auch dem Anderen Ding mit der ID 2 (Golf) zu. Da mehrere Werte einem Ding zukommen können, nennt man diese Relation 1-zu-m (ein Auto aber mehrere Sprit-Arten möglich).
In SQL kann man es so zusammenbringen: „Select * from Auto,Sprit where Auto.ID=Sprit.AutoID“. Schon haben wir das gleiche wie oben… (Farben lassen wir mal aus)
Doch etwas stimmt da noch nicht. Haben wir nicht von Vermeidung von Redundanzen gesprochen? Warum muss „Benzin“ zwei mal drin vorkommen? Richtig! Es gibt nur ein „Benzin“ (na gut es gibt ja noch „Super“ – aber das lassen wir lieber mal…). Benutzen wir mal Stellvertreter. Benzin wird durch „1“ und Diesel durch „2“ repräsentiert – aber nur unter der Voraussetzung, dass sie so behandelt werden wie Autos. Damit haben wir die Tabelle „Sprit“ (ID, Spritart):
- 1 = Benzin
- 2 = Diesel
Damit erreichen wir die „zweite Normallform“. Die Koalition (oder richtiger: „Relation“) dieser beiden Dinge halten wir in einer dritten Tabelle namens „AutoUndSprit“ fest. Sie beinhaltet nur die AutoID und die SpritID:
- 1 = 1
- 2 = 1
- 2 = 2
„Ferrari“, „Golf“, „Benzin“ und „Diesel“ kommen nur noch einmal vor, aber nicht ihre Stellvertreter. In der dritten Tabelle können beliebige Werte aus der Auto-Tabelle auf die Werte aus der Sprit-Tabelle treffen. Und das so oft wie sie wollen. So einen Mischmasch nennt man auch fachmännisch eine m-zu-n-Relation (beliebig viele Autos können [rein theoretisch] beliebig viele Sprit-Arten fahren und umgekehrter Weise können beliebig viele Sprit-Arten in beliebig viele Auto-Typen getankt werden). Das Nennt man die „dritte Normalform“. Und so sieht die „Zusammenstellung“ aus:
- Ferrari = „1“ ; „1“ = „1“ ; „1“ = Benzin
- Golf = „2“ ; „2“ = „1“ ; „1“ = Benzin
- Golf = „2“ ; „2“ = „2“ ; „2“ = Diesel
Und so würde das SQL aussehen: „Select * from Auto,AutoUndSprit,Sprit where Auto.ID=AutoUndSprit.AutoID and AutoUndSprit.SpritID=Sprit.ID“. Was hinter „where“ kommt, ist genau das, was in der Zusammenstellung mit „;“ als Trenner zwischen Tabellen ausgezichnet wurde.
Wenn Sie jetzt Gleiches mit den Farben hinbekommen, haben Sie alles Verstanden und können sich als Kenner ralationaler Datenbanken (wie z.B. MySQL) bezeichnen.
Und hier ein Hinweis auf die richtige Lösung:
- Ferrar = „1“ ; „1“ = „1“ ; „1“ = rot
- Golf = „2“ ; „2“ = „1“ ; „1“ = rot
- Golf = „2“ ; „2“ = „2“ ; „2“ = blau
- Golf = „2“ ; „2“ = „3“ ; „3“ = silber