Ein relationales Datenmodell aus Anforderungen entwerfen

Aus einer Anforderung soll eine verlässliche Datenstruktur werden

Die Weiterblick Akademie organisiert Workshops für ihre Kundinnen und Kunden. Bisher pflegt das Team Termine und Anmeldungen in einer gemeinsamen Tabelle. In jeder Zeile stehen Name und E-Mail-Adresse einer teilnehmenden Person, Titel und Dauer des Workshops, Raumdaten, Termin und Anmeldestatus.

Das funktioniert für die ersten Termine. Danach entstehen Widersprüche. Ändert sich die E-Mail-Adresse einer Person, muss das Team sie in mehreren Zeilen korrigieren. Wird ein Workshop umbenannt, bleiben alte Schreibweisen in einzelnen Anmeldungen stehen. Auch die maximale Personenzahl eines Raums wird immer wieder kopiert.

Dein Auftrag ist, aus den fachlichen Anforderungen ein relationales Datenmodell zu entwerfen. Nach dieser Lektion kannst du:

• geeignete Entitäten und Attribute erkennen,
• Primär- und Fremdschlüssel festlegen,
• Beziehungen und Kardinalitäten begründen,
• Redundanzen mit den ersten drei Normalformen prüfen,
• den Entwurf gegen konkrete fachliche Fragen zurückprüfen.

Du brauchst keine SQL-Kenntnisse. Wir planen hier die Struktur der Daten. Die Befehle zum Erstellen oder Abfragen einer Datenbank kommen erst nach diesem Entwurf.

Lies Anforderungen zuerst als Aussagen über Dinge

Die Weiterblick Akademie beschreibt ihren Bedarf so:

1. Ein Workshop hat einen Titel und eine Dauer in Minuten.
2. Zu einem Workshop kann es mehrere Termine geben. Jeder Termin gehört genau zu einem Workshop.
3. Jeder Termin findet in genau einem Raum statt. Ein Raum kann für viele Termine verwendet werden.
4. Eine teilnehmende Person kann sich für mehrere Termine anmelden. Zu einem Termin können sich mehrere Personen anmelden.
5. Zu jeder Anmeldung werden Anmeldedatum und Status gespeichert.

Ein Entitätstyp beschreibt fachlich gleichartige Dinge, über die Daten gespeichert werden. Workshop, Termin, Raum und Teilnehmende sind deshalb erste Kandidaten. Ein einzelner Workshop mit dem Titel “Netzwerke für Einsteiger” wäre eine konkrete Entität dieses Typs.

Ein Attribut beschreibt eine Eigenschaft. titel ist ein Attribut des Workshops, startzeit gehört zum Termin und max_plaetze zum Raum. Ein Attribut gehört dorthin, wo seine Bedeutung entsteht. Die Raumkapazität ist keine Eigenschaft eines Termins, auch wenn sie bei der Terminplanung gebraucht wird.

Schlüssel geben Datensätzen eine eindeutige Identität

Ein Name ist selten ein verlässlicher Schlüssel. Zwei Personen können denselben Namen tragen. Eine E-Mail-Adresse kann sich ändern. Auch zwei Workshop-Titel dürfen gleich klingen, obwohl unterschiedliche Angebote gemeint sind.

Ein Primärschlüssel identifiziert jeden Datensatz einer Tabelle eindeutig. Für unser Modell verwenden wir technische Kennungen wie workshop_id, termin_id, raum_id und teilnehmer_id. Die Kennung bleibt stabil, auch wenn sich ein beschreibendes Attribut ändert.

Ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle. Im Termin stehen deshalb workshop_id und raum_id als Fremdschlüssel. Sie drücken aus, welcher Workshop angeboten wird und in welchem Raum der Termin stattfindet.

So sieht der erste relationale Entwurf in kompakter Form aus:

• WORKSHOP: Primärschlüssel workshop_id; Attribute titel und dauer_minuten
• RAUM: Primärschlüssel raum_id; Attribute bezeichnung und max_plaetze
• TERMIN: Primärschlüssel termin_id; Fremdschlüssel workshop_id und raum_id; Attribut startzeit
• TEILNEHMENDE: Primärschlüssel teilnehmer_id; Attribute name und email
• ANMELDUNG: zusammengesetzter Primärschlüssel und zugleich Fremdschlüssel aus termin_id und teilnehmer_id; Attribute angemeldet_am und status

Die Anmeldung hat einen zusammengesetzten Primärschlüssel. Erst die Verbindung aus Termin und teilnehmender Person ist eindeutig. Damit kann eine Person nicht zweimal für denselben Termin angemeldet werden. Für andere fachliche Regeln könnte auch eine eigene anmeldung_id sinnvoll sein. Dann bräuchte die Kombination aus termin_id und teilnehmer_id zusätzlich eine Eindeutigkeitsregel.

Kardinalitäten beschreiben, wie viele Verbindungen erlaubt sind

Eine Kardinalität sagt, wie viele Datensätze auf beiden Seiten einer Beziehung vorkommen dürfen oder müssen. Dafür liest du die fachliche Aussage in beide Richtungen.

Beim Workshop und Termin lautet sie:

• Ein Workshop kann noch keinen, einen oder mehrere Termine haben.
• Jeder Termin gehört genau zu einem Workshop.

Das ist eine 1:n-Beziehung. Der Fremdschlüssel steht auf der n-Seite, also in TERMIN.

Zwischen Teilnehmenden und Terminen besteht zunächst eine n:m-Beziehung. Eine Person kann viele Termine besuchen, und ein Termin kann viele Anmeldungen haben. In einem relationalen Modell wird diese Beziehung über die Zwischentabelle ANMELDUNG aufgelöst. Dadurch entstehen zwei 1:n-Beziehungen. Gleichzeitig erhält die Beziehung einen Ort für eigene Attribute wie angemeldet_am und status.

Normalisierung reduziert vermeidbare Abhängigkeiten

Normalisierung ist eine Prüfung des Tabellenentwurfs. Sie hilft, Daten nicht unnötig zu wiederholen und Änderungs-, Einfüge- oder Löschfehler zu vermeiden. Die Normalformen sind kein Selbstzweck. Sie machen Abhängigkeiten sichtbar, die sonst leicht übersehen werden.

Erste Normalform: Ein Feld enthält einen einzelnen Wert

In der ersten Normalform sind Attributwerte atomar für den vorgesehenen Gebrauch. Eine Spalte teilnehmende_emails mit dem Inhalt lea@example.de; sami@example.de wäre ungeeignet. Anzahl und Position der Werte wären nicht verlässlich, und einzelne Anmeldungen ließen sich schlecht bearbeiten.

Die Tabelle ANMELDUNG speichert stattdessen jede Verbindung als eigenen Datensatz. So kann die Anwendung eine einzelne Anmeldung eindeutig finden, ändern oder löschen.

Zweite Normalform: Daten hängen vom gesamten Schlüssel ab

Die zweite Normalform ist besonders bei zusammengesetzten Schlüsseln relevant. In ANMELDUNG besteht der Schlüssel aus termin_id und teilnehmer_id. status und angemeldet_am beschreiben genau diese Kombination.

Der name einer Person hängt dagegen nur von teilnehmer_id ab. Der Workshop-Titel hängt über den Termin letztlich vom Workshop ab. Beide Angaben gehören deshalb nicht als Kopien in ANMELDUNG.

Dritte Normalform: Nichtschlüsselattribute hängen nicht voneinander ab

Die dritte Normalform räumt Abhängigkeiten zwischen beschreibenden Attributen auf. Würde TERMIN neben raum_id auch raum_bezeichnung und max_plaetze speichern, hingen diese Werte nicht direkt vom Termin ab. Sie hängen vom Raum ab. Darum liegen sie in RAUM und werden über raum_id zugeordnet.

Ähnlich verhält es sich mit workshop_titel und dauer_minuten. Diese Angaben gehören zu WORKSHOP. Ein neuer Titel wird dadurch an einer Stelle gepflegt und gilt für alle zugehörigen Termine.

Prüfe das Modell gegen die ursprünglichen Fragen

Ein Diagramm kann formal sauber aussehen und trotzdem am Auftrag vorbeigehen. Deshalb formulierst du vor der Umsetzung konkrete Fragen, die das Modell beantworten muss:

• Welcher Workshop findet an einem bestimmten Termin statt?
• In welchem Raum liegt der Termin, und wie viele Plätze hat er?
• Welche Personen sind für einen Termin angemeldet?
• Für welche Termine hat sich eine bestimmte Person angemeldet?
• Welchen Status hat eine konkrete Anmeldung?
• Kann dieselbe Person versehentlich zweimal für denselben Termin angemeldet werden?

Gehe jede Frage über Tabellen, Schlüssel und Beziehungen entlang. Für die erste Frage führt TERMIN.workshop_id zu WORKSHOP. Für die Teilnehmerliste führt ANMELDUNG.termin_id zu den zugehörigen teilnehmer_id-Werten und von dort zu TEILNEHMENDE.

Prüfe danach Sonderfälle und Grenzen. Darf ein Workshop ohne Termin angelegt werden? Darf ein Termin ohne Raum existieren? Muss eine E-Mail-Adresse eindeutig sein? Was geschieht mit Anmeldungen, wenn ein Termin abgesagt wird? Das Datenmodell liefert nicht automatisch die Antworten. Es macht aber sichtbar, wo fachliche Regeln entschieden und später technisch abgesichert werden müssen.

Entwirf ein Modell für eine Gerätewartung

Was du aus dem Entwurf mitnimmst

Ein Datenmodell entsteht aus fachlichen Aussagen. Entitäten bündeln Dinge mit eigener Identität. Attribute beschreiben sie. Primärschlüssel identifizieren Datensätze, während Fremdschlüssel Beziehungen abbilden und auf vorhandene Datensätze verweisen.

Kardinalitäten werden in beide Richtungen gelesen. Eine n:m-Beziehung braucht im relationalen Modell meist eine Zwischentabelle. Diese Tabelle kann zusätzlich Eigenschaften der Verbindung aufnehmen.

Normalisierung prüft, ob Werte atomar sind und ob Attribute vom richtigen Schlüssel abhängen. Die Rückprüfung ergänzt diese formale Sicht. Sie zeigt, ob das Modell die fachlichen Fragen beantwortet und an welchen Stellen noch Regeln geklärt werden müssen.

Quellenbasis und Abgrenzung

Die Einordnung in Lernfeld 5 folgt dem KMK-Rahmenlehrplan. Die Berufsbildposition A4 der Fachinformatikerausbildungsverordnung nennt das Unterscheiden von Datenbankmodellen und das Erstellen von Abfragen. A10 trägt das Festlegen von Programmspezifikationen. Der AP1-Prüfungskatalog nennt Grundlagen relationaler Datenbanken und einfache ER-Modelle. Er zeigt die Themenbreite, garantiert aber keine Aufgabe in einem bestimmten Prüfungstermin.

Der fachrichtungsspezifische Prüfungskatalog für Anwendungsentwicklung führt das Ableiten von Datenmodellen aus Anforderungen, ER- und relationale Modelle sowie die Normalisierung bis zur dritten Normalform weiter. Eine Beispielprüfung von Winter 2023 wurde nur verwendet, um die wiederkehrende Aufgabenform zu erkennen: Aus fachlichen Angaben werden Tabellen, Schlüssel und Kardinalitäten abgeleitet. Szenario, Begriffe, Daten und Lösung dieser Lektion sind neu formuliert.

Diese Lektion behandelt den fachlichen und logischen Entwurf eines einfachen relationalen Datenmodells. Sie führt keine SQL-Befehle aus und behandelt keine Datenbankinstallation, Indizes oder Transaktionen. Ein Entity-Relationship-Modell beschreibt Daten und ihre Beziehungen. UML deckt dagegen mehrere Diagrammarten für Softwaresysteme ab; ein UML-Klassendiagramm ist deshalb nicht automatisch ein relationales Datenmodell. Auch Sonderfälle der Normalisierung, Denormalisierung und physische Leistungsoptimierung liegen außerhalb dieser Einführung.

Belegmatrix

• Entitäten und Attribute ableiten: LF5 sowie A4 und A10 bilden den Ordnungsmittelbezug. Rahmenlehrplan, Ausbildungsverordnung und beide Prüfungskataloge tragen das Ableiten einer Datenstruktur aus einer fachlichen Aufgabe. Einstieg, Zuordnung und Workshop-Szenario machen die Fähigkeit beobachtbar.
• Primär- und Fremdschlüssel festlegen: LF5 und T1 bilden den gemeinsamen Bezug; der fachrichtungsspezifische Katalog und das abstrahierte Aufgabenmuster vertiefen ihn. Tabellensicht, Diagramm und Quiz bilden die Anwendung.
• Kardinalitäten begründen: Der AP1-Katalog trägt einfache ER-Modelle. Der FIAE-Katalog und das abstrahierte Aufgabenmuster tragen Beziehungen und Kardinalitäten im relationalen Modell. Diagramm und Quiz verlangen das Lesen in beide Richtungen.
• Redundanzen erkennen: LF5 bildet den Lernfeldbezug. Der FIAE-Katalog trägt die erste bis dritte Normalform. Erklärung und Fehlersuche machen Teil- und transitive Abhängigkeiten an einem neuen Szenario sichtbar.
• Entwurf zurückprüfen: Rahmenlehrplan und A10 tragen die handlungsorientierte Ableitung aus Anforderungen. Baustein- und Transferaufgabe verbinden Anforderungen, Modell, Normalisierung und fachliche Rückprüfung.