Datenbankmodellierung: ER-Modell und Tabellen

Stell dir vor, eine Schule möchte Beiträge und Kommentare in einem sozialen Netzwerk speichern. Bevor Tabellen angelegt werden, muss geklärt werden:

• Welche Dinge und Ereignisse sind wichtig?
• Welche Eigenschaften sollen gespeichert werden?
• Wie hängen die Dinge zusammen?
• Welche fachlichen Regeln gelten?

Ein Datenmodell beantwortet diese Fragen in einer vereinfachten, geordneten Form. Es dient als Entwurf für die spätere Datenbank.

Ein sinnvoller Modellierungsprozess verläuft in vier Schritten:

1. Anforderungen untersuchen: Welche Daten werden benötigt und wofür?
2. Konzeptuelles Modell entwerfen: Entitäten, Attribute und Beziehungen beschreiben.
3. Logisches Modell bilden: Tabellen, Primärschlüssel und Fremdschlüssel festlegen.
4. Physisches Modell planen: Den Entwurf an ein konkretes Datenbankmanagementsystem anpassen.

Bei Kontodaten könnte eine Beispieltabelle so wirken, als gehöre jedes Konto genau einem Kunden. Eine Fachperson kann jedoch erklären, dass ein Gemeinschaftskonto mehrere Inhaber haben darf. Dadurch ändert sich das Modell.

Gleichartig aufgebaute Entitäten werden zu einem Entitätstyp zusammengefasst. Der Entitätstyp Benutzer beschreibt beispielsweise alle Benutzer. In einer relationalen Datenbank wird daraus meist eine Tabelle; jede einzelne Entität entspricht einer Zeile.

Ein Name ist meist kein verlässlicher Primärschlüssel: Mehrere Personen können gleich heißen und ein Name kann sich ändern. Eine künstlich vergebene BenutzerID eignet sich besser.

Ein Schlüssel kann auch aus mehreren Attributen bestehen. Bei täglichen Kontoständen identifiziert der Tag allein keinen Datensatz. Erst die Kombination aus Konto und Tag ist eindeutig.

Eine Beziehung beschreibt einen fachlichen Zusammenhang zwischen Entitäten. Beispielsweise verfasst ein Benutzer einen Beitrag.

Die Kardinalität gibt an, wie viele Entitäten auf beiden Seiten beteiligt sein dürfen oder müssen.

Zusätzlich ist die Optionalität wichtig. Sie beantwortet, ob eine Beziehung bestehen muss. Ein Beitrag muss beispielsweise einem Benutzer gehören. Ein neu angelegter Benutzer kann dagegen noch keinen Beitrag verfasst haben.

Im relationalen Modell werden Entitätstypen zu Tabellen. Beziehungen entstehen durch Fremdschlüssel.

Bei einer 1:n-Beziehung wird der Primärschlüssel der 1-Seite als Fremdschlüssel in die Tabelle der n-Seite übernommen.

Für das soziale Netzwerk ergibt sich:

• Benutzer(BenutzerID PK, Name, E-Mail)
• Beitrag(BeitragID PK, Inhalt, Datum, BenutzerID FK)
• Kommentar(KommentarID PK, Inhalt, Datum, BenutzerID FK, BeitragID FK)

PK kennzeichnet einen Primärschlüssel, FK einen Fremdschlüssel. In Beitrag zeigt BenutzerID auf den Verfasser. In Kommentar zeigen zwei Fremdschlüssel auf den Verfasser und den kommentierten Beitrag.

Eine n:m-Beziehung lässt sich nicht durch einen einzigen Fremdschlüssel korrekt darstellen. Dafür wird eine Verbindungstabelle benötigt.

Beispiel Kontoinhaber:

• Kunde(KundenID PK, Name)
• Konto(KontoID PK, Kontotyp)
• Kontoinhaber(KundenID PK/FK, KontoID PK/FK)

Die Kombination aus KundenID und KontoID kann den zusammengesetzten Primärschlüssel der Verbindungstabelle bilden.

Hat die Beziehung eine eigene Eigenschaft, wird diese ebenfalls in der Verbindungstabelle gespeichert. Zwischen Küche und Möbel gehört beispielsweise die Anzahl in die Tabelle Moeblierung.

Ein Auftrag kann mehrere Produkte enthalten, und ein Produkt kann in mehreren Aufträgen vorkommen. Zwischen Auftrag und Produkt besteht deshalb eine n:m-Beziehung. Außerdem gehört jeder Auftrag genau zu einem Kunden.

Schritt 1: Entitäten und Attribute festlegen

• Kunde: KundenID, Firma
• Auftrag: AuftragsID, Auftragsdatum
• Produkt: ProduktID, Bezeichnung, Lagerbestand
• Auftragsposition: PositionsID, Positionsnummer, Menge

Schritt 2: Beziehungen bestimmen

• Kunde zu Auftrag: 1:n
• Auftrag zu Produkt: n:m
• Die Verbindung Auftragsposition löst diese n:m-Beziehung in zwei 1:n-Beziehungen auf.

Schritt 3: Relationales Schema bilden

• Kunde(KundenID PK, Firma)
• Auftrag(AuftragsID PK, Auftragsdatum, KundenID FK)
• Produkt(ProduktID PK, Bezeichnung, Lagerbestand)
• Auftragsposition(PositionsID PK, Positionsnummer, Menge, AuftragsID FK, ProduktID FK)

Die Menge gehört nicht allgemein zum Auftrag und nicht allgemein zum Produkt. Sie beschreibt, wie oft ein bestimmtes Produkt in einem bestimmten Auftrag vorkommt. Deshalb steht sie in Auftragsposition.

Schritt 4: Integrität prüfen

Referentielle Integrität bedeutet: Jeder gesetzte Fremdschlüsselwert muss auf einen vorhandenen Schlüsselwert verweisen. Eine Auftragsposition darf also keine nicht vorhandene AuftragsID oder ProduktID enthalten.

Wird ein Kunde noch von Aufträgen referenziert, kann er nicht einfach gelöscht werden, sofern keine passende Löschregel festgelegt wurde.

Normalisierung ordnet Attribute und Tabellen so, dass unnötige Wiederholungen und daraus entstehende Widersprüche vermieden werden.

Solche Widersprüche heißen Anomalien:

• Änderungsanomalie: Eine mehrfach gespeicherte Information wird nur an einigen Stellen geändert.
• Einfügeanomalie: Eine Information lässt sich erst speichern, wenn eine andere, noch nicht vorhandene Information ergänzt wird.
• Löschanomalie: Beim Löschen einer Zeile geht unbeabsichtigt eine weitere Information verloren.

Erste Normalform

Eine Tabelle erfüllt die erste Normalform, wenn jedes Feld genau einen einzelnen Wert enthält. Eine Liste mehrerer Songs in einer Zelle verletzt diese Regel. Jeder Song benötigt eine eigene Zeile.

Zweite Normalform

Eine Tabelle erfüllt die zweite Normalform, wenn sie in der ersten Normalform ist und jedes Nichtschlüsselattribut vom gesamten zusammengesetzten Primärschlüssel abhängt.

Angenommen, Pruefungsergebnis hat den Schlüssel aus SchuelerID und KursID. Der Schülername hängt nur von SchuelerID ab, der Kursname nur von KursID. Beide gehören deshalb in eigene Tabellen.

Dritte Normalform

Eine Tabelle erfüllt die dritte Normalform, wenn sie in der zweiten Normalform ist und kein Nichtschlüsselattribut ein anderes Nichtschlüsselattribut bestimmt.

Stehen Schule und Schulleitung beide in einer Schülertabelle, wird die Schulleitung bei jedem Schüler derselben Schule wiederholt. Besser ist:

• Schueler(SchuelerID PK, Name, SchulID FK)
• Schule(SchulID PK, Schulname, Schulleitung)

Der Weg führt vom fachlichen Problem zum relationalen Schema: Du untersuchst Anforderungen, bestimmst Entitäten und Schlüssel, modellierst Beziehungen, überführst sie in Tabellen und prüfst anschließend Redundanz sowie Integrität.

Wenn du alle drei Entscheidungen begründen kannst, beherrschst du den Kern der Datenbankmodellierung: Du kannst einen Realitätsausschnitt in ein nachvollziehbares, relationales Schema übersetzen.