Das Buch im HTML-Format

Für unbestimmte Zeit bieten Addison-Wesley und André Minhorst den kompletten Inhalt des Buchs als Download an. Schauen Sie rein und informieren Sie sich über den Inhalt! Und wenn Ihnen das Buch nützlich erscheint und Sie glauben, dass Sie etwas gelernt haben oder durch das Gelesene sogar etwas Zeit und somit Geld bei Ihrer Arbeit einsparen konnten, können Sie sich ja beim Autor und beim Verlag revanchieren - beispielsweise durch den Kauf dieses Buchs.

Am schönsten wäre es natürlich, wenn Sie das Buch direkt hier bestellen - Sie erhalten das Buch dann direkt vom Verlag, und der Autor und Verlag haben dann noch mehr davon, als wenn Sie es anderswo kaufen.

Danke für Ihr Interesse!

2.3.1 Die erste Normalform

2.3.2 Die zweite Normalform

Die zweite Normalform besagt, dass alle Felder einer Tabelle vom Primärschlüssel beziehungsweise vom ganzen Primärschlüssel abhängig sein müssen. »Ganzer« Primärschlüssel bezieht sich auf Tabellen mit mehreren Primärschlüsseln - das hört sich im ersten Augenblick unlogisch an, aber folgendes Beispiel wird verdeutlichen, wie das gemeint ist.

Im Beispiel aus Abbildung 2.35 verwaltet jemand Kunden und Projekte in einer Excel-Tabelle. Jeder Datensatz dieser Tabelle ist durch die Kombination der Felder KundeID und ProjektID eindeutig identifizierbar.

Wenn man die Felder der Tabelle auf ihre Abhängigkeit vom Primärschlüssel untersucht, stellt man schnell fest, dass nicht alle vom »ganzen«, also zusammengesetzten Primärschlüssel, abhängen. Die Kundendaten sind zwar vom Primärschlüsselfeld KundeID abhängig, aber nicht vom Feld ProjektID.

Dadurch kann derselbe Kunde mehrmals in der Tabelle auftreten. Der in Abbildung 2.35 dargestellte Zustand heißt Redundanz. Unter diesen Bedingungen ist die Konsistenz der Daten gefährdet. Sobald man Informationen zu einem Kunden nur in einem der Datensätze ändert, ist die Konsistenz dahin und die Integrität der Daten verloren.

Abbildung 2.35: Tabelle mit zwei Primärschlüsseln

Wie leicht aus einer Tabelle mit redundanten Daten Inkonsistenzen entstehen können, zeigt Abbildung 2.36. Hier wurde in einem neuen Datensatz der Name des Kunden falsch geschrieben. Die Inkonsistenz würde sich hier bemerkbar machen, wenn man alle Projekte nach dem Kunden »Addison-Wesley« filtert. Der letzte Eintrag mit dem Kundennamen ohne Bindestrich würde nicht angezeigt.

Überführung der Daten in die zweite Normalform

Die Gefahr von Redundanzen und Inkonsistenzen lässt sich beheben, indem Sie die Daten so auf mehrere Tabellen aufteilen, dass alle Felder der Tabellen vom jeweiligen Primärschlüsselfeld beziehungsweise vom aus mehreren Feldern zusammengesetzten Primärschlüssel abhängen. Im obigen Beispiel gibt es zwei Primärschlüssel - KundeID und ProjektID -, die beide abhängige Felder aufweisen. Die Notwendigkeit einer zweiten Tabelle ist offensichtlich.

Die beiden Tabellen sehen wie in Abbildung 2.37 aus.

Abbildung 2.36: Tabelle mit inkonsistenten Daten

Abbildung 2.37: Tabellen mit ausschließlich vom Primärschlüssel abhängigen Feldern

Jetzt fehlt allerdings die Information, welches Projekt zu welchem Kunden gehört. Da in der Regel jedes Projekt nur für einen Kunden durchgeführt wird, halten Sie diese Information in der Tabelle tblProjekte fest, indem Sie per Fremdschlüsselfeld auf den jeweiligen Primärschlüssel der Tabelle tblKunden verweisen.

Abbildung 2.38 zeigt die Tabelle tblProjekte mit dem neuen Fremdschlüsselfeld, das mit dem Primärschlüsselfeld der Tabelle tblKunden verknüpft ist.

Abbildung 2.38: Beziehung zwischen den Tabellen tblKunden und tblProjekte

Nächster Abschnitt:

2.3.3 Die dritte Normalform

© 2006-2008 André Minhorst Alle Rechte vorbehalten.