Datenbanknormalisierung

 

• 1Datenbanknormalisierung
  • 1.1Vorwort
  • 1.2Die fünf Normalformen. Oder waren es doch sieben?
    • 1.2.11. Normalform
      • 1.2.1.1Definition
      • 1.2.1.2Beispiel I
      • 1.2.1.3Zweck/Grund
      • 1.2.1.4Lösung:
      • 1.2.1.5Beispiel II:
      • 1.2.1.6Lösungsansatz I zu Beispiel II
      • 1.2.1.7Lösungsansatz II zu Beispiel II
    • 1.2.22. Normalform
      • 1.2.2.1Definition
      • 1.2.2.2Beispiel
      • 1.2.2.3Zweck/Grund
      • 1.2.2.4Lösung:
    • 1.2.33. Normalform
      • 1.2.3.1Definition
      • 1.2.3.2Beispiel
      • 1.2.3.3Lösung
    • 1.2.4Boyce-Codd-Normalform (BCNF)
      • 1.2.4.1Definition
      • 1.2.4.2Zweck/Grund
      • 1.2.4.3Beispiel
      • 1.2.4.4Lösung
    • 1.2.54. Normalform
      • 1.2.5.1Definition
      • 1.2.5.2Beispiel:
      • 1.2.5.3Lösung:
    • 1.2.65. Normalform
      • 1.2.6.1Definition
  • 1.3Und jetzt? Muss das wirklich alles sein?
  • 1.4Jetzt komm ich aber viel schwerer an meine Daten wieder ran!

Datenbanknormalisierung

Vorwort

Datenbanknormalisierung ist eigentlich ein schreckliches Wort. Normalisierung, das heißt Angleichung an die Masse und das ist wahrscheinlich die schlimmste Form der Gleichmacherei. Warum also diese Gleichmacherei? Meine Anwendung ist schließlich ein Kunstwerk für sich.

Nun, es haben sich ja schon recht viele Leute mit dem Thema Erstellung relationaler Datenbanken beschäftigt. Viele sind auf Probleme und Lösungen gestoßen, und natürlich wurde vieles davon auch publiziert.

Heraus gekommen ist ein Satz von Regeln, "Best Practices", wenn Ihr so wollt, für die Erstellung von Datenlayouts in relationalen Datenbanken. Ziel dieser Regeln ist es, Redundanzen zu vermeiden und einen effizienten Zugriff auf die Daten zu ermöglichen.

Warum Redundanzen vermeiden, werdet Ihr vielleicht fragen. Gut - die Frage ist berechtigt, schließlich ist fast nichts heutzutage so preiswert zu haben, wie Speicherplatz. Trotzdem darf hier nicht nur die Kostenfrage betrachtet werden, sondern es muss auch die Frage des schnellen Zugriffs gestellt werden. Wenn sich Eure Daten in tausendfacher Form an den unterschiedlichsten Stellen befinden, dann muss für jede Suche, für jede Veränderung und für das Hinzufügen jedes neuen Datenwertes ein überdimensionaler Aufwand getrieben werden.

Auch eine anderer Aspekt darf natürlich nicht vergessen werden, und das ist die Frage nach der referentiellen Integrität. Wenn eine Information an fünf Orten steht, dann wird bei einer Änderung schnell auch nur mal einer dieser Orte verändert. Folge sind Strukturprobleme innerhalb der Vernetzung der Daten.

All das - und natürlich die Spezialisierung, die sich mittlerweile in die technische Umsetzung relationaler Datenbankmanagementsysteme eingeschlichen hat - nimmt zwar auf den ersten Blick Freiheiten, auf lange Sicht hat sich die Einhaltung diverser Best Practices aber noch immer für jedes Projekt gelohnt und der Mehraufwand hat sich bisher noch immer rentiert.

Die fünf Normalformen. Oder waren es doch sieben?

Um mit den Inhalten einer Datenbank effizient umgehen zu können, haben sich - wie schon erwähnt - einige Best Practices, namens "Normalformen" etabliert. Diese Normalformen sind allerdings keine Regeln, die alle für sich alleine stehen, sondern die einzelnen Normalformen bauen aufeinander auf. Erfüllt eine Datenstruktur/ein Datenlayout die Normalform 2, so muss sie per Definition auch die Normalform 1 erfüllen, damit alle Kriterien für NF 2 gewahrt sind.

Essentiell für das Verständnis vieler der folgenden Definitionen ist das Verständnis der Begrifflichkeiten Key oder Schlüssel und funktionale Abhängigkeit. Erstere Begriffe werden Synonym verwendet und bezeichnen eine Möglichkeit, bestimmte Datensätze eindeutig zu identifizieren, der zweite wird zur Beschreibung von Logikzusammenhängen zwischen Datenworten innerhalb eines Datensatzes genutzt.

Tipp:
Eine gute technische Erklärung zur Nutzung von Schlüsseln in relationalen Datenbankmanagementsystemen bietet dieses Online-Buch.

Historisch gehen zumindest die ersten 3.5 der im folgenden näher beschriebenen Normalformen auf den Englischen Computerwissenschaftler Edgar F. Codd zurück, die höheren auf die Arbeiten und Publikationen anderer Fachleute, die sich aber zumindest an der Arbeit von Codd orientieren.

In der Praxis relevant sind hauptsächlich die Normalformen eins bis drei, sowie die Boyce-Codd-Normalform. Ein beharren auf die letzten drei Normalformen (4, 5 und 6) ist in der Fachwelt teilweise umstritten, da ihre Anwendung teilweise zu Performance-Problemen im praktischen Einsatz führt.

Das macht die letzten Normalformen allerdings um nichts weniger wichtig. Der generelle Konsens ist wohl, dass auch diese berücksichtigt werden sollten, sofern keine explizite technische Anforderung das aktuellen Anwendungsfalles sie verhindert.

Alle anderen sprechen immer von fünf Normalformen. Warum spricht dieser Artikel von sieben?

Die Begründungen dafür sind denkbar einfach:

Eine der Normalformen - die Boyce-Codd-Normalform - liegt im Sprachgebrauch völlig außerhalb des gewöhnlichen Zählschemas, da viele in ihr einfach nur eine Erweiterung einer bestehenden Normalform sehen.

Das lässt Normalform 6 - diese gewinnt erst seit 2002 Bekanntheitsgrad. Sie kommt allerdings aus einigermaßen berufenem Munde, deshalb wird sie hier der Vollständigkeit halber mit aufgeführt. Ob sie sich in der Praxis durchsetzt? Wir werden sehen.

Nun wollen wir uns die unterschiedlichen Normalformen und Regeln mal im Detail anschauen und mit kleinen Beispielen versehen:

1. Normalform

Definition

In jede Spalte einer Tabelle kommt exakt eine Information, also etwas, das nicht sinnvoll in kleinere Teile zerlegt werden kann.

Beispiel I

Die Adresse "12345 Kleindödelhausen, Hauptstraße 123" steht in einem Textfeld "adresse" innerhalb einer Tabelle.

Zweck/Grund

Selektionen auf Teilinformationen - z.B. "alle Kunden aus Kleindödelhausen" - sind nicht mehr effizient/einfach durchführbar, wenn alle diese Informationen in einer Spalte stehen.

Nehmen wir an, wir haben eine Adresse "Stuttgarter Straße 29, 59067 Hamm" und eine Adresse "Dorfstraße 3, 70173 Stuttgart". Würden wir jetzt daraus alle Adressen in Stuttgart ermitteln wollen, so wäre das nur mit sehr großem Aufwand möglich. Eine Suche adresse LIKE '%Stuttgart%' würde offensichtlich ja auch die Adresse aus Hamm zurück liefern. Der naive Ansatz geht also nicht.

Lösung:

Die Adresse sollte in vier bis fünf Spalten abgelegt werden:

Land (Optional)	PLZ	Ort	Strasse	Hausnummer
Deutschland	59067	Hamm	Stuttgarter Straße	29
Deutschland	70173	Stuttgart	Dorfstraße	1

Übliche Abfragen, wie die nach allen Adressen eines Ortes sind dann leicht realisierbar:

MySQL Quellcode:

SELECT
  Land,
  PLZ,
  Ort,
  Strasse,
  Hausnummer
FROM
  tabelle
WHERE
  Ort = 'Stuttgart'

Beispiel II:

Ein gern gemachter Anfängerfehler ist es, Kommaseparierte Werte in einer einzelnen Spalte der Tabelle zu platzieren. Nehmen wir an, wir wollen eine Liste von Fußballspielern, inklusive Ihrer Positionen erstellen. Häufig entsteht dabei dann so etwas hier:

Spieler

lfdNr	Nachname	Vorname	Positionen
1	Torlos	Toni	Torwart, Verteidiger
2	Knochenbrecher	Kasimir	Innenverteidiger, defensiver Mittelfeldspieler
3	Leichtfuß	Luigi	rechter Verteidiger, linker Verteidiger, Innenverteidiger

Auf den ersten Blick sieht das recht schlank und übersichtlich aus. Neben der Verletzung der ersten Normalform stellt uns das ganze aber vor ein ziemliches Problem. Stellt Euch vor, alle Spieler der Bundesliga wären so in einer Tabelle abgelegt. Jetzt wollen wir von unserer Datenbank wissen, wie viele Innenverteidiger es in unserer Tabelle gibt.

Okay - gehen wir mal ganz naiv an die Sache heran:

SQL Quellcode:

SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  position LIKE '%Innenverteidiger%'

oder alternativ (und nur für das häufig genutzte MySQL):

MySQL Quellcode:

SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  FIND_IN_SET('Innenverteidiger',position)

Oder lasst uns versuchen zu Zählen, wie viele Spieler es mit zwei oder mehr unterschiedlichen Positionen es gibt:

MySQL Quellcode:

SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  (LENGTH(position)-LENGTH(REPLACE(position,',','')))>=1

Damit ist unsere Datenbank dann eine ganze Weile beschäftigt. Wenn Ihr dem Link zur technischen Realisierung von Indexes oben gefolgt seid, dann wisst Ihr jetzt auch warum. Es ist nämlich so, dass die meisten Datenbankmanagementsysteme in solchen Fällen keinen Index nutzen kann.

Ein Index - auch das wisst Ihr jetzt wahrscheinlich schon - ist eine Art Suchkatalog für Daten, der es der Datenbank erspart, jeden Datensatz einzeln anzuschauen. Stellt es Euch vor, wie in einem Lexikon - auch dort gibt es meist einen Appendix mit Inhaltsverzeichnis, der Eure Suche im Buch verschnellern kann.

Es kommt aber noch viel schlimmer. Nehmt an, die Datenbank "lebt" eine Weile. Jetzt hat Toni Torlos zwar seit fünfzehn Jahren im Tor gestanden, Verteidiger hat er aber seit er fünfzehn war nicht mehr gespielt. Wir wollen also die Verteidigerposition aus dem Datensatz des Spielers entfernen.

Spätestens an dieser aufwendigen Abfrage (am Beispiel von MySQL) werdet Ihr sehen, dass das gar nicht so einfach ist:

MySQL Quellcode:

UPDATE
  spieler
SET
  position=REPLACE( /* für Vorkommen in der Mitte und am Ende der Liste */
                    REPLACE( /* für Vorkommen am Anfang der Liste */
                             position,
                             ' Verteidiger,',
                             ''
                           ),
                    ', Verteidiger',
                    ''
                    )
WHERE
  name='Torlos'
  AND vorname='Toni'

Wir betreiben hier also einen riesigen Aufwand, sowohl zum Finden des Wertes, als auch zum Ändern des jeweiligen Datensatzes.

Lösungsansatz I zu Beispiel II

Gut - jetzt wissen wir, aggregierte Informationen innerhalb einer Spalte sind nicht die schlaueste aller Ideen. Wie sieht es also aus, wenn wir einfach ein paar durchnummerierte Spalten vorhalten und diese dann mit den einzelnen Positionen befüllen?

Spieler

lfdNr	Nachname	Vorname	Position1	Position2	Position3
1	Torlos	Toni	Torwart	Verteidiger
2	Knochenbrecher	Kasimir	Innenverteidiger	defensiver Mittelfeldspieler
3	Leichtfuß	Luigi	rechter Verteidiger	linker Verteidiger	Innenverteidiger

Das widerspricht zumindest nicht Codd's Definition der ersten Normalform. Diese Definition verlangt nur die atomizität des Attributs, also dass innerhalb einer Spalte auch nur ein Wert vorkommen kann und darf.

Auch die Normalformen entwickeln sich allerdings weiter und einige relevante Autoren (z.B. Christopher J. Date) haben diese Definition schon viel enger ausgelegt.

Wir wollen uns hier nicht mit den Gelehrten streiten, deshalb konzentrieren wir uns mal auf die technischen Hintergründe, warum der oben gezeigte Ansatz ziemlich problematisch ist und warum es - da ist sich die Fachwelt dann wieder ziemlich einig - diesen Ansatz zu vermeiden gilt.

Nehmen wir an, wir brauchen plötzlich mehr als nur die drei oben gezeigten Positionen, weil ein Spieler nun mal universeller einsetzbar ist:

Jetzt nur die Tabelle anzupassen ist einfach. Konsequenter Weise müssen wir jetzt allerdings auch ran an die Applikation und alle unsere SELECT, UPDATE und INSERT Statements anfassen. Kein schöner Arbeitsaufwand, wie ihr Euch wahrscheinlich denken könnt.

Schauen wir uns das mal an und gehen wir die oben genannten Anwendungsfälle mal Beispielhaft durch:

Anzahl aller Innenverteidiger:

SQL Quellcode:

SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  'Innenverteidiger' IN(position1,position2,position3)

Alle Spieler mit mehr als 2 Positionen:

MySQL Quellcode:

SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  IFNULL(position1,0,1)+IFNULL(position2,0,1)+IFNULL(position3,0,1)>=2

Toni Torlos ist kein Verteidiger mehr:

MySQL Quellcode:

UPDATE
  spieler
SET
  position1=IF(position1='Verteidiger', /* wenn 1. Feld zu ändern */
               position2, /* Feld 2 "nach links schieben" */
               position1  /* ansonsten Feld 1 belassen */
               ),
  position2=IF(positon1='Verteidiger'
               OR position2='Verteidiger', /* wenn 1. oder 2. Feld zu ändern */
               position3, /* Feld 3 "nach links schieben" */
               position2  /* ansonsten Feld 2 belassen */
               ),
  position3=IF(positon1='Verteidiger'
               OR position2='Verteidiger'
               OR position3='Verteidiger', /* Wenn 1., 2. oder 3. Feld zu ändern */
               null,      /* 3. Feld leeren */
               position3  /* ansonsten Feld 3 belassen */
               )
WHERE
  name='Torlos'
  AND vorname='Toni'  /* aber nur beim gesuchten Spieler */

Es sollte offensichtlich sein, dass man a) den Aufstand nicht wirklich betreiben möchte und b) dass man auch so seine Datenank ganz schön sinnlos beschäftigen kann.

Abgesehen davon: Wiederholungsgruppen verstehen sich nicht mit den Normalformen, die im weiteren Verlauf dieses Artikels erklärt werden.

Also:

Warnung:
Lasst bloß die Finger davon!

Lösungsansatz II zu Beispiel II

Zwei Tabellen, eine für die Positionen und eine für die Spieler sind hier der Weg, der keiner bekannten Definition der ersten Normalform wiederspricht:

Spieler

lfdNr	Nachname	Vorname
1	Torlos	Toni
2	Knochenbrecher	Kasimir
3	Leichtfuß	Luigi

Position

SpielerNr	Position
1	Torwart
1	Verteidiger
2	Innenverteidiger
2	defensiver Mittelfeldspieler
3	rechter Verteidiger
3	linker Verteidiger
3	Innenverteidiger

Ganz abgesehen davon, handelt man sich auch weitaus weniger technische Probleme ein, mit diesem Datenmodell:

Anzahl aller Innenverteidiger:

SQL Quellcode:

SELECT
  COUNT(SpielerNr) AS anzahl
FROM
  Positionen
WHERE
  position='Innenverteidiger'

Anzahl aller Spieler mit mehr als 2 Positionen:

MySQL Quellcode:

SELECT
   COUNT(*)
FROM
(
  SELECT
    spielerNr,
    COUNT(position) AS anzahl
  FROM
    spieler
  GROUP BY
    spielerNr
  HAVING
    anzahl>=2
) s

Toni Torlos ist kein Verteidiger mehr:

MySQL Quellcode:

DELETE p
FROM
  spieler s INNER JOIN position p
    ON s.lfdNr=p.spielerNr
WHERE
  s.name='Torlos'
  AND s.vorname='Toni'
  AND p.position='Verteidiger'

Das sieht doch gleich viel einfacher aus, oder?

2. Normalform

Definition

Alle Daten, die nicht Teil des Keys sind, hängen von allen Key-Attributen ab.

Beispiel

In einer Tabelle mit den Spalten "KundenNr", "BestellNr", "KundenName", "KundenAlter" und "Artikel" liegt ein Key auf KundenNr und BestellNr. (Im Beispiel kursiv gekennzeichnet)

KundenNr	BestellNr	Kundenname	KundenAlter	Artikel
1	1	Hans Dampf	18	Brotdose
1	12	Hans Dampf	18	Schnuller
2	23	Reiner Zufall	78	Krückstock
2	23	Reiner Zufall	78	Rollator

Damit wird die zweite NF verletzt, da "KundenName" und "KundenAlter" nur von der KundenNr abhängen, nicht aber direkt von "BestellNr".

Zweck/Grund

Es werden Datenintegritätsverletzungen durch Redundanz möglich, wie z.B. zwei Einträge mit gleicher KundenNr, aber unterschiedlichem KundenNamen oder zwei identische Kunden mit unterschiedlichem Alter.

Außerdem ist zu beachten, dass viel mehr Datensätze angefasst werden müssen, sollte sich ein Name oder Alter mal ändern. (So dann und wann passiert sowas ja durchaus mal. )

Lösung:

Alle Spalten entfernen, die nur von einem Teil des Keys abhängen und in eine eigene Tabelle auslagern. Für das Beispiel oben ergibt sich damit dieses Bild:

Kunden

KundenNr	Kundenname	KundenAlter
1	Hans Dampf	18
2	Reiner Zufall	78

Bestellpositionen

BestellNr	KundenNr	Artikel
1	1	Brotdose
12	1	Schnuller
23	2	Krückstock
23	2	Rollator

Änderungen an Kundendaten können damit dann immer an einer Stelle ausgeführt werden, ohne dass alle bestellten Artikel überhaupt auch nur angesehen werden müssen.

3. Normalform

Definition

Es gibt keine transitiven ("mehrstufigen") Abhängigkeiten zwischen den Nicht-Schlüssel-Spalten einer Tabelle.

Beispiel

In einer Datenbank sollen die Gewinner des jährlich stattfindenden Sportturniere des alt-erwürdigen Klein Kleckersdorfer Hampel-, Hüpf und Springvereins verwaltet werden.

Hierzu liegt der folgende Tabellenentwurf vor:

Gewinner

Turnier	Jahr	Gewinner	Geburtsdatum
Jährliches Hüpfen	2012	Hans Dampf	03.12.1994
Bierglasweitwurf	2012	Hans Dampf	03.12.1994
Jährliches Hüpfen	2011	Reiner Zufall	23.01.1934
Bierglasweitwurf	2011	Hans Dampf	03.12.1994

Als Schlüssel wurden der Turniername und das Jahr der Austragung gewählt. Hier ist klar ersichtlich, dass auch zwischen dem Gewinner und seinem Geburtsdatum (beide nicht Teil des Schlüssels) eine Abhängigkeit besteht.

Normalform 3 lässt diese Abhängigkeit nicht zu, da allerdings alle Attribute zumindest immer auch vom vollständigen Primärschlüssel abhängen, ist Normalform 2 nicht verletzt.

Lösung

Zerlegung der o.g. Tabelle in zwei - einmal die Personen, samt ihrer Attribute, und auf der anderen Seite das Turnier, das Jahr und eine Verknüpfung zur Person:

Gewinner

Turnier	Jahr	PersonID
Jährliches Hüpfen	2012	1
Bierglasweitwurf	2012	1
Jährliches Hüpfen	2011	2
Bierglasweitwurf	2011	1

Personen

PersonID	Name	Geburtsdatum
1	Hans Dampf	03.12.1994
2	Reiner Zufall	23.01.1934

Tipp:
Ob Ihr das soweit verstanden habt, könnt Ihr z.B. anhand von diesem kleinen Online-Quiz ja mal testen.

Boyce-Codd-Normalform (BCNF)

Definition

Die Boyce-Codd-Normalform ist eine strengere Variante der 3.Normalform: jede Spalte, von der eine andere (funktional) abhängig ist, ist Teil des Keys.

Chris Date hat das mal wie folgt recht sprechend formuliert:

Each attribute must represent a fact about the key, the whole key, and nothing but the key.

damit bezieht er sich auf die Steilvorlage von Bill Kent zur 3. Normalform:

Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key.

Der Unterschied dürfte offensichtlich sein: Während die dritte Normalform ihre Einschränkung nur für Nicht-Schlüssel definiert, gelten für die BCNF stärkere Gesetze, da sich auch die Schlüssel der genannten Anforderung beugen müssen.

Zweck/Grund

Beseitigung aller restlichen, redundanten Informationen und Ersatz durch geeignete Relationen.

Beispiel

In der Lösung zur 2. Normalform haben wir einen solchen Fall:
Kunden

KundenNr	Kundenname	KundenAlter
1	Hans Dampf	18
2	Reiner Zufall	78

Bestellpositionen

BestellNr	KundenNr	Artikel
1	1	Brotdose
12	1	Schnuller
23	2	Krückstock
23	2	Rollator

Hier existiert eine Abhängigkeit von KundenNr zu BestellNr - wenn auch nicht aus dem Schema, aber aus den Daten heraus. Die dritte Normalform untersagt diese Abhängigkeit nicht, denn sie bezieht sich ausschließlich auf Attribute, die nicht Teil eines Schlüssels oder Schlüsselkandidaten sind.

Lösung

Abhängigkeiten, die nicht in der Form "Attribut hängt ab von Key" sind, in eine separate Tabelle (inkl. der abhängigen Attribute) auslagern. Also:

Kunden

KundenNr	Kundenname	KundenAlter
1	Hans Dampf	18
2	Reiner Zufall	78

Bestellungen

BestellNr	KundenNr
1	1
12	1
23	2

Bestellpositionen

lfdNr	BestellNr	Artikel
1	1	Brotdose
2	12	Schnuller
3	23	Krückstock
4	23	Rollator

4. Normalform

Definition

Alle voneinander vollständig unabhängigen Attribute werden in getrennten Tabellen gehalten.

Diese Normalform geht auf Ronald Fagin zurück. Hier findet Ihr seine Einführung im Englischsprachigen Original..

Beispiel:

Familien

Familie	VornameKind	Wohnort
Dampf	Hans	Hamm
Zufall	Reiner	Stuttgart

verletzt diese Regel, da es nicht möglich ist, ein Kind anzulegen, ohne einen (neuen?) Ort einzutragen.

Lösung:

Aufteilung in
Kinder

Familie	VornameKind
Dampf	Hans
Zufall	Reiner

und
Wohnorte

Familie	Wohnort
Dampf	Hamm
Zufall	Stuttgart

5. Normalform

Definition

Keine Relation läßt sich in (noch) einfachere Relationen zerteilen, ohne Informationen zu verlieren.

Anders formuliert: es werden nicht mehrere Abhängigkeiten in einer Tabelle erfaßt, wodurch konkrete (mehrstufige) Zuordnungen entstehen. Statt dessen werden alle Relationen in eigene Tabellen zerteilt, wodurch sich teilweise Optionen ergeben, die vorher nicht in der konkret erfaßten Datenstruktur abgebildet waren.

Es wird hier also klar auf die Maximierung der durch die Relationen definierten Optionen gezielt.

Und jetzt? Muss das wirklich alles sein?

Das war evtl. etwas schwer verständlich, hier ist eine ausführlichere Variante, die aber auch noch ziemlich akademisch ist. Und Nein, natürlich muss das nicht alles sein. Das geschriebene sind "Best Practices", von denen man in konkreten Fällen manchmal durchaus auch abweichen kann und muss. Trotzdem hat sich etabliert, zumindest die ersten drei der o.g. Normalformen als Qualitätsmaßstab für ein Datenlayout zu interpretieren. Sollte Deine eigene Datenstruktur also eine dieser Regeln verletzen, dann ist es spätestens jetzt an der Zeit, etwas dagegen zu tun.

Zum besseren Verständnis der Materie sei Euch insbesondere das Anfänger freundliche Kapitel Datenbanken entwickeln aus DSP: Datenbank, MySQL und PHP von Christoph Reeg und Jens Hatlak, sowie der oben schon einmal angesprochene Wikipedia-Artikel zum Thema Normalisierung von Datenbanken ans Herz gelegt. Ebenfalls gut zu lesen sind die Ausführungen von Prof. Dr. Staud von der HS Weingarten zum Thema Relationale Datenmodellierung.

Auch ganz unterhaltsamer Lesestoff - wenn auch teilweise nicht grade für Laien geschrieben - ist Codd's Buch The Relational Model for Database Management (ISBN 0-201-14192-2). Immer wieder stolpert man auch über Temporal Data & the Relational Model von C.J. Date, Hugh Darwen und Nikos Lorentzos (ISBN 1-55860-855-9), zu dessen Qualität der Autor dieses Tutorials allerdings nicht viel erhellendes von sich geben kann.

Jetzt komm ich aber viel schwerer an meine Daten wieder ran!

Tja, der liebe Zugriff...

Natürlich ist es auf den ersten Blick einfacher, wenn alle Daten in einer Tabelle stehen und man mit einem einfachen SELECT ohne viel Fachkenntnisse auf diese Zugreifen kann. Andererseits sind die heutigen relationalen Datenbankmanagementsysteme aber auf genau die in den Normalformen beschriebenen strukturiert verteilten Informationen ausgelegt und können damit für gewöhnlich sehr gut um.

Um dem DBMS jetzt allerdings begreiflich machen zu können, welche Daten in welcher Form abgefragt oder verändert werden sollen, bedarf es ein bisschen Kenntnissen in SQL.

Zumindest mit ein bisschen relationaler Algebra und mit der Theorie von SQL Joins werdet Ihr Euch auseinander setzen müssen, wenn das ganze funktionieren soll.

Wenn Ihr das allerdings hinter Euch habt, dann werdet Ihr schnell merken, dass viele Dinge unter Berücksichtigung der oben beschriebenen Prinzipien nicht nur einfacher, sondern auch bei weitem weniger Fehleranfällig umsetzbar sind.

Ganz abgesehen davon, seid Ihr hier ja aber auch in einem Forum. Wenn Ihr also Probleme bei der Umsetzung Eurer Abfragen auf eine normalisierte Datenstruktur habt, dann findet sich sicherlich hier auch schnell jemand, der Euch bei der Lösung hilft.

Tipp:
Weitere Informationen findet Ihr außerdem in den Tutorials A Visual Explanation of SQL Joins und SQL und relationale Algebra.