Frage an KI: Was waren die Lessons Learned.

Hier ist eine Diskussion der fachlichen „Lessons Learned“ aus den vorliegenden Abschlussberichten zu Datenmodellierungsprojekten. Die Quellen zeigen übereinstimmend, dass die fachlichen Erkenntnisse weniger technischer Natur (Bedienung der Software) waren, sondern vielmehr die logische Strukturierung, sprachliche Präzision und Abstraktionsfähigkeit betrafen.

Zusammenfassende Analogie: Man kann die in den Quellen beschriebenen Lessons Learned mit dem Unterschied zwischen dem Zeichnen einer Landkarte und dem Planen einer Reiseroute vergleichen. Anfangs versuchten viele Gruppen, die Route (den Prozess/Ablauf) zu zeichnen – also wann man wo abbiegt. Die fachliche Kern-Erkenntnis der Datenmodellierung war jedoch, dass sie stattdessen die Landkarte (die Struktur) erstellen müssen: Sie definieren, wo Städte (Entitäten) liegen und welche Straßen (Beziehungen) sie verbinden, unabhängig davon, wer wann darüber fährt. Erst wenn die Karte präzise vermessen ist (Attribute und Definitionen), können sich Systeme darauf sicher bewegen.

1. Präzision der Sprache als Fundament der Modellierung

Ein zentrales und wiederkehrendes „Aha-Erlebnis“ über fast alle Gruppen hinweg ist die Erkenntnis, dass Alltagssprache für die Datenmodellierung unzureichend ist.

Definitionen statt Annahmen: Mehrere Gruppen stellten fest, dass scheinbar klare Begriffe wie „Mitarbeiter“, „Dienst“ oder „Standort“ von verschiedenen Teammitgliedern unterschiedlich interpretiert wurden. Fachlich bedeutete dies, dass vor der eigentlichen Modellierung ein Glossar oder ein gemeinsames Verständnis erarbeitet werden musste, da sonst Missverständnisse die Struktur gefährdeten.

Die Bedeutung der Verben (Beziehungen): Ein technisches Modell steht und fällt mit der Benennung der Beziehungen. Die Gruppen lernten, dass generische Verben wie „hat“ oder „gehört zu“ keine fachliche Aussagekraft besitzen. Stattdessen sind präzise Formulierungen wie „ist zugeteilt zu“ oder „erfordert“ notwendig, um die Realität korrekt abzubilden.

Leserichtung und Logik: Die „Lesbarkeit“ des Modells wurde als wichtiges Validierungsinstrument identifiziert. Sätze müssen laut gelesen logisch klingen (z. B. Prüfung auf Absurdität wie „Ein Zielort bietet eine Bewertung an“). Dabei war die Leserichtung oft kontraintuitiv zur Modellierungsrichtung, was ein bewusstes sprachliches Durchdenken erforderte.

2. Abgrenzung: Datenmodell vs. Prozessmodell

Eine der fachlich tiefgreifendsten Erkenntnisse war die Unterscheidung zwischen statischen Datenstrukturen und dynamischen Abläufen.

Lösen vom Prozessdenken: Studierende neigten anfangs dazu, den zeitlichen Ablauf (z. B. eine Taxifahrt) abzubilden. Fachlich korrekt ist jedoch die Modellierung der beteiligten Objekte (Fahrzeug, Kunde, Fahrt), nicht des Ablaufs selbst. Die Erkenntnis, dass ein Informationsmodell kein Prozessmodell ist, war entscheidend, um unnötige Komplexität und Redundanzen zu vermeiden.

Struktur vor Lösung: Es zeigte sich, dass man Informationen präzise strukturieren muss, bevor man in technischen Lösungen oder Software-Prozessen denkt.

3. Entitäten, Attribute und Normalisierung

Auf der granularen Ebene der Modellierung (Entitäten und Attribute) wurden spezifische fachliche Kompetenzen aufgebaut:

Entscheidung Entität vs. Attribut: Ein häufiges Problem war die semantische Abgrenzung. Ist der „Standort“ oder die „Vertragsart“ eine eigene Entität oder nur eine Eigenschaft? Die Gruppen lernten, dass dies von der fachlichen Notwendigkeit abhängt (z. B. wurde „Standort“ zur Entität, da er weitere Eigenschaften wie Land und Adresse umfasst).

Fachliche Schlüssel statt künstlicher IDs: Ein großer „Aha-Moment“ war für eine Gruppe die Entdeckung, dass man nicht immer künstliche IDs (ID1, ID2) benötigt. Fachliche Attribute (z. B. Studiengang + Jahrgang) reichen oft aus, um Datensätze eindeutig zu identifizieren, was den Blick auf die Datenstruktur grundlegend veränderte.

Redundanzvermeidung: Das Auftauchen identischer Attribute in verschiedenen Entitäten (z. B. Abholadresse und Zielort beide mit Adress-Attributen) wurde als Warnsignal für schlechtes Design erkannt. Die fachliche Lösung war hier die Auslagerung in eine eigene Entität „Adresse“.

Atomare Attribute: Es wurde gelernt, dass Attribute keine überlagerten Werte enthalten dürfen (z. B. eine ID, die gleichzeitig Ort und Typ kodiert), um eine saubere Datenqualität zu gewährleisten.

4. Komplexitätsmanagement und Detailtiefe

Die Quellen verdeutlichen, dass einfache Sachverhalte bei genauer Betrachtung oft eine überraschende Komplexität entfalten.

Zunahme der Entitäten: Was als einfaches Modell begann (z. B. 8 Entitäten), wuchs durch notwendige Präzisierung oft an (z. B. auf 12 Entitäten), um ein stabiles Fundament zu bilden.

Abhängigkeiten: Die Vernetzung der Entitäten (z. B. im Curriculum zwischen Modul, Prüfung und Semester) erwies sich als deutlich verzwickter als angenommen.

Reduktion auf das Wesentliche: Gleichzeitig lernten Gruppen, Grenzen zu ziehen und nicht die gesamte Realität 1:1 abzubilden, sondern nur die für den Kontext relevanten logischen Zusammenhänge.

5. Werkzeuge vs. Denkweise

Abschließend zeigen die Berichte, dass das verwendete Tool (Dataspot) zwar hilfreich für die Visualisierung und Konsistenzprüfung war, aber die intellektuelle Arbeit nicht abnehmen konnte.

Validierung: Das Tool half, Inkonsistenzen aufzudecken, aber die „Denkarbeit“ und das „Zerdenken“ der Beziehungen mussten vorher im Kopf oder auf dem Whiteboard (z. B. Miro) geschehen.
Trennung von Konzept und Implementierung: Erfolgreiche Projekte trennten oft die konzeptionelle Phase (Diskussion, Skizze) klar von der technischen Implementierung im Tool.