Relationale Datenbank: Aufbau und Normalisierung

Stell dir einen Onlinehandel vor. Kundendaten, Bestellungen und Produkte werden nicht in einer einzigen langen Liste gesammelt. Sie liegen in mehreren Tabellen, die über passende Schlüsselwerte verbunden sind.

Beispiel für eine Tabelle kunden:

kunden_nr, firma und ort sind Attribute. Die Zeile mit der Nummer 31 ist ein Datensatz. Heidelberg ist ein Attributwert.

Das Schema ist der Bauplan: Es legt Tabellen, Attribute, Datentypen, Schlüssel, Beziehungen und Bedingungen fest. Der aktuelle Tabelleninhalt sind dagegen die gespeicherten Daten.

Eine Kundennummer soll nicht zwei verschiedene Kunden bezeichnen. Deshalb braucht jede Tabelle eine zuverlässige Identifikation.

text kunden(kunden_nr PK, firma, ort) bestellungen(bestell_nr PK, datum, kunden_nr FK)

In bestellungen identifiziert bestell_nr jede Bestellung. kunden_nr verweist auf kunden. So kann das System zu einer Bestellung den richtigen Kunden finden, ohne Firma und Ort in jeder Bestellung erneut zu speichern.

Ein Schlüssel muss nicht immer aus genau einem Attribut bestehen. In einer Bestellposition kann etwa die Kombination (bestell_nr, produkt_nr) eindeutig sein. Das heißt zusammengesetzter Primärschlüssel.

Die Kardinalität beschreibt, wie viele Datensätze auf beiden Seiten einer Beziehung zusammengehören können.

• 1:1: Zu einem Datensatz gehört höchstens ein Datensatz der Gegenseite.
• 1:N: Ein Datensatz der 1-Seite kann mit mehreren Datensätzen der N-Seite verbunden sein.
• N:M: Auf beiden Seiten können jeweils mehrere Datensätze zusammengehören.

Bei Kunde 1:N Bestellung kann ein Kunde mehrere Bestellungen aufgeben. Jede Bestellung gehört in diesem Modell zu genau einem Kunden. Daher steht der Primärschlüssel der 1-Seite als Fremdschlüssel auf der N-Seite:

text kunden(kunden_nr PK, firma) bestellungen(bestell_nr PK, datum, kunden_nr FK)

Bei Bestellung N:M Produkt reicht ein einzelner Fremdschlüssel nicht. Eine Bestellung kann mehrere Produkte enthalten, und ein Produkt kann in mehreren Bestellungen vorkommen. Deshalb entsteht eine Verbindungstabelle:

text produkte(produkt_nr PK, bezeichnung) bestellungen(bestell_nr PK, datum, kunden_nr FK) bestellpositionen(bestell_nr PK/FK, produkt_nr PK/FK, menge)

menge gehört zur Verbindung: Sie sagt, wie oft ein bestimmtes Produkt in einer bestimmten Bestellung vorkommt.

Beginne nicht sofort mit Tabellen. Kläre zuerst, welche Dinge, Ereignisse und Beziehungen im betrachteten Ausschnitt wichtig sind.

1. Entitäten finden: Das sind eindeutig bestimmbare Objekte oder Ereignisse, etwa Kunde, Produkt und Bestellung.
2. Entitätstypen bilden: Gleichartig aufgebaute Entitäten erhalten einen gemeinsamen Bauplan.
3. Attribute und Wertebereiche festlegen: Zum Produkt gehören etwa Bezeichnung und Lagerbestand. Eine Postleitzahl wird als Zeichenkette gespeichert, weil sie keine Rechengröße ist und mit null beginnen kann.
4. Primärschlüssel wählen: Namen eignen sich oft nicht, weil sie doppelt vorkommen oder sich ändern können.
5. Beziehungen und Kardinalitäten bestimmen: Formuliere dazu Regeln wie „Ein Kunde kann mehrere Bestellungen aufgeben“.
6. In Tabellen überführen: Jeder Entitätstyp wird eine Tabelle; 1:N und N:M werden nach den Schlüsselregeln umgesetzt.

Ein Auftrag mit kunden_nr = 99 ist ungültig, wenn es keinen Kunden 99 gibt. Ebenso darf ein Kunde nicht einfach gelöscht werden, solange Bestellungen auf ihn verweisen, sofern keine andere Löschregel festgelegt ist.

Auch Transaktionen schützen den Datenbestand. Eine Transaktion fasst zusammengehörige Änderungen zu einer Einheit zusammen. Die ACID-Eigenschaften verlangen:

• Atomarität: ganz oder gar nicht;
• Konsistenz: festgelegte Regeln bleiben erfüllt;
• Isolation: gleichzeitig laufende Transaktionen stören einander nicht unkontrolliert;
• Dauerhaftigkeit: bestätigte Änderungen bleiben gespeichert.

SQL ist die typische Sprache, um relationale Daten zu definieren, abzufragen und zu verändern. Das Datenbankmanagementsystem, kurz RDBMS, führt solche Anweisungen aus und überwacht unter anderem Schlüsselregeln und gleichzeitige Zugriffe.

Redundanz bedeutet, dass dieselbe Information unnötig mehrfach gespeichert wird. Das kann zu Anomalien führen: Eine Anschrift wird nur in einigen Zeilen geändert, ein neuer Kunde lässt sich ohne Bestellung nicht einfügen oder die letzte Bestellung löscht unbeabsichtigt auch die einzige gespeicherte Kundeninformation.

Normalisierung zerlegt Tabellen anhand funktionaler Abhängigkeiten. A → B bedeutet: Ein Wert von A bestimmt genau einen Wert von B.

Erste Normalform: einzelne Werte

Eine Tabelle ist in der ersten Normalform (1NF), wenn jedes Attribut pro Zeile genau einen atomaren Wert enthält. Eine Zelle wie Produkt = Tisch, Regal wird daher in einzelne Bestellpositionen aufgeteilt.

Zweite Normalform: vom ganzen Schlüssel abhängig

Eine Tabelle ist in der zweiten Normalform (2NF), wenn sie in 1NF ist und jedes Nichtschlüsselattribut vom gesamten zusammengesetzten Primärschlüssel abhängt.

Betrachte:

text positionen(bestell_nr PK, produkt_nr PK, datum, produktname, menge)

Der Schlüssel ist (bestell_nr, produkt_nr). Aber datum hängt nur von bestell_nr ab und produktname nur von produkt_nr. Deshalb werden die Daten getrennt:

text bestellungen(bestell_nr PK, datum) produkte(produkt_nr PK, produktname) positionen(bestell_nr PK/FK, produkt_nr PK/FK, menge)

menge bleibt in positionen, weil sie erst durch die Kombination aus Bestellung und Produkt bestimmt wird.

Dritte Normalform: keine Abhängigkeit über Umwege

Eine Tabelle ist in der dritten Normalform (3NF), wenn sie in 2NF ist und kein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut abhängt.

Nimm diese Tabelle:

text bestellungen(bestell_nr PK, datum, kunden_nr, kundenname)

Es gilt: bestell_nr → kunden_nr und kunden_nr → kundenname. Der Kundenname hängt also nur über einen Umweg von der Bestellnummer ab. Zerlege deshalb:

text kunden(kunden_nr PK, kundenname) bestellungen(bestell_nr PK, datum, kunden_nr FK)

Du bist fertig, wenn du bei einem neuen Fall erst die fachlichen Beziehungen formulierst, dann Schlüssel setzt und anschließend jede Abhängigkeit begründen kannst.