Startseite   Sonstiges	Sonstiges Modellieren - Redundanz - Normalformen Herzlichen Glückwunsch - das erste Große Kapitel hast du geschafft, nämlich das Modellieren von Datenbanken. Alles was jetzt noch kommt ist nicht mehr schwierig. Im nächsten großen Block werden wir uns der Umsetzung des Klassendiagramms am Computer zuwenden. Das geht schematisch und erfordert keinerlei Nachdenken mehr. Bevor es aber damit weitergeht, muss ich dir noch etwas über Redundanz und Normalformen erzählen. Nur wenn du dieses letzte Kapitel der Datenbankmodellierung einigermaßen verstanden hast, wirst du in der Lage sein, gute Datenbanken zu programmieren. Redundanz Datenbanken bestehen, das ist dir seit dem ersten Kapitel klar, nur aus Tabellen. In diesen Tabellen werden die Daten gespeichert. Redundanz bedeutet, dass ein und dieselbe Information zweimal abgespeichert ist. Das ist nicht schön! Und das liegt nicht nur daran, dass dadurch unnötig Speicherplatz vergeudet wird. Die modernen Rechner besitzen ja meist viel mehr Speicher als benötigt wird. Ärgerlich ist dies deshalb, weil ein Datensatz verändert werden kann und dann die Information zweimal vorliegt, man aber nicht weiss, welch Information die richtige ist. Beispiel gefällig? Der Wohnort eines Kunden Sonic sei München. Wir haben ihn mehrmals in einer Tabelle stehen. Sonic zieht um von München nach Berlin und wir ändern die Information nur einmal. Schon haben wir den Salat! Es gibt aber noch einen weiteren Grund, warum redundante Informationen schlecht sind. Ein weiteres Beispiel: Unser Unternehmen habe 1000 Mitarbeiter, davon sind 600 bei der AOK gesetzlich krankenversichert. In der Klasse Mitarbeiter haben wir daher als Attribute für jeden Mitarbeiter den Namen der Krankenkasse und den aktuellen Beitragssatz der AOK eingegeben. Ändert sich nun der Beitragssatz der AOK, so muss der Beitragssatz 600 Mal geändert werden. Besser wäre es, die Krankenkasse wäre eine eigene Klasse mit den Attributen Name und Beitragssatz und diese Klasse wäre durch eine Beziehung mit den Mitarbeitern verbunden. Dann muss der Beitragssatz nämlich nur einmal geändert werden - was für eine Zeitersparnis! Außerdem ist unsere Datenbank dann wartungsärmer und es schleichen sich nicht so viele Fehler ein. Das gilt z.B. auch für den Wohnort. Viele Datenbanken haben daher auch für den Wohnort eine eigene Klasse vorgesehen, was durchaus sinnvoll ist. Aber vorsicht: Es gibt auch ein Zuviel an Klassenbildung. Jede Straße, jedes Geburtsdatum usw. als eigene Klasse einzurichten erfordert immer wieder eigene Beziehungen zwischen den Klassen. Dies kann die Datenbank sehr leicht unübersichtlich werden lassen. Auch dann schleichen sich leicht Fehler ein. Wenn du dich ein wenig länger mit Datenbanken beschäftigt hat, wirst du ganz automatisch ein Gefühl dafür entwickeln, wie gute Datenbanken modelliert werden. Normalformen Normalformen sind die Bezeichnung für den Zustand einer Datenbank, um Redundanz möglichst zu vermeiden. Es gibt mehrere Normalform-Hierarchien und auch z.T. relativ aufwändige Verfahren, wie man aus jeder Datenbank eine Datenbank in Normalform machen kann. Ich erspare mir an dieser Stelle aber weitere Einzelheiten und gebe euch einfach ein paar Tipps für das Gestalten guter Datenbanken. 1. In jedem Attribut sollte nur eine Information stehen! Name und Ort sind zwei Attribute und nicht eines! 2. Mehrere Attribute, die voneinander abhängig sind, sollten in einer extra Klasse stehen, z.B. sind der Name der Krankenkasse und der Beitragssatz voneinander abhängig. Daher sollten diese in einer eigenen Klasse stehen und nicht Attribute der Klasse Mitarbeiter sein. 3. Anfänger machen oft den Fehler, dass im Klassendiagramm die Beziehung als Attribut einer Klasse eingetragen wird. Das sollte unterbleiben. Also wenn ich eine Klasse Mitarbeiter und eine Klasse Krankenversicherung habe, darf von der Krankenversicherung kein Attribut in der Klasse Mitarbeiter auftauchen! Die Beziehung stellt die Verbindung zwischen beiden Klassen bereits dar! Copyright 2003 - Letzte Änderung am 4. September 2004