Ableitung von Datenmodellen und Strukturen

In dieser Lerneinheit entwickelst du die Fähigkeit, aus realen Geschäftsprozessen die relevanten Datenstrukturen und Entitäten abzuleiten. Du lernst systematische Methoden kennen, um Geschäftsobjekte zu identifizieren und diese in ein strukturiertes Datenmodell zu überführen. Diese Grundlagen sind essentiell für die spätere Entwicklung von Datenbanken und Softwareanwendungen, die exakt auf die Geschäftsanforderungen zugeschnitten sind.

Einführung

Ein Kunde beauftragt dich: “Wir brauchen ein System zur Verwaltung unserer Online-Bestellungen.” Wo fängst du an? Welche Daten müssen gespeichert werden? Welche Beziehungen bestehen zwischen Kunden, Produkten und Bestellungen?

Vom Chaos zur Struktur: Systematische Ableitung von Datenmodellen — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Ohne einen systematischen Prozess zur Ableitung von Datenmodellen aus Kundenanforderungen entstehen lückenhafte, inkonsistente Systeme, die später aufwändig nachgebessert werden müssen.

Die Ableitung von Datenmodellen und Strukturen ist der Prozess, durch den du aus realen Geschäftsanforderungen die benötigten Datenstrukturen identifizierst und strukturierst. Dieser Prozess bildet die Grundlage für jede kundenspezifische Softwareanwendung.

In dieser Lerneinheit lernst du, wie du systematisch von Kundenanforderungen zu funktionierenden Datenmodellen kommst - welche Methoden du nutzt, welche Entscheidungen du triffst und wie du den Prozess dokumentierst.

Lernziele

Nach dieser Lerneinheit kannst du:

• Aus Kundenanforderungen systematisch Datenstrukturen ableiten
• Den Ableitungsprozess von der Anforderung bis zum Datenmodell durchführen
• Geschäftsprozesse analysieren und relevante Daten identifizieren
• Entscheidungen im Modellierungsprozess begründen und dokumentieren
• Datenmodelle mit Stakeholdern validieren und Feedback einholen

Überleitung

Die Ableitung von Datenmodellen ist kein einmaliger Schritt, sondern ein systematischer Prozess. Von der ersten Anforderung des Kunden bis zum fertigen Datenmodell durchläufst du mehrere Phasen: Anforderungsanalyse, Geschäftsprozessanalyse, Identifikation von Datenobjekten und Strukturierung.

Schauen wir uns an, wie dieser Ableitungsprozess funktioniert und welche Methoden dir dabei helfen.

Der Ableitungsprozess: Von der Anforderung zum Datenmodell

Der Prozess zur Ableitung von Datenmodellen folgt systematischen Schritten:

1. Anforderungen verstehen: Was will der Kunde? Welche Geschäftsprozesse sollen abgebildet werden?

2. Geschäftsobjekte identifizieren: Welche Dinge (Kunden, Produkte, Bestellungen) sind relevant?

3. Datenflüsse analysieren: Welche Daten fließen durch die Prozesse?

4. Struktur festlegen: Wie werden die Daten organisiert und gespeichert?

5. Modell visualisieren: ERDs, Klassendiagramme oder andere Darstellungen nutzen

6. Validieren: Mit Stakeholdern prüfen, ob das Modell die Anforderungen abbildet

Der Schlüssel liegt nicht im Beherrschen der Notationen, sondern im systematischen Vorgehen vom Kundengespräch bis zum funktionierenden Modell.

Geschäftsprozesse analysieren

Geschäftsprozesse zeigen dir, welche Daten du benötigst. Wenn ein Kunde sagt “Ich möchte Bestellungen verwalten”, analysierst du den Bestellprozess:

Beispiel: Bestellprozess

1. Kunde wählt Produkte aus
2. Kunde gibt Lieferadresse an
3. System berechnet Gesamtpreis
4. Kunde bezahlt
5. Bestellung wird versendet

Datenobjekte ableiten:

• Kunde: Wer bestellt? (Name, Adresse, E-Mail)
• Produkt: Was wird bestellt? (Bezeichnung, Preis, Lagerbestand)
• Bestellung: Welche Produkte, wann, wie viel? (Bestelldatum, Gesamtpreis)
• Lieferadresse: Wohin? (Straße, PLZ, Stadt)

Beziehungen erkennen: Ein Kunde kann mehrere Bestellungen aufgeben, eine Bestellung enthält mehrere Produkte.

Stakeholder-Interviews auswerten

Stakeholder-Interviews liefern wertvolle Hinweise auf benötigte Datenstrukturen. Systematisches Vorgehen:

Fragen stellen:

• “Welche Informationen benötigen Sie für Ihre tägliche Arbeit?”
• “Welche Berichte oder Auswertungen brauchen Sie?”
• “Welche Daten erfassen Sie derzeit manuell?”

Substantiv-Methode: Achte auf Substantive in den Antworten - sie sind oft Hinweise auf Datenobjekte:

“Wir verwalten Kunden, die Produkte bestellen. Jede Bestellung hat eine Lieferadresse und einen Status.”

→ Potentielle Datenobjekte: Kunde, Produkt, Bestellung, Lieferadresse, Status

Validierung: Frage nach: “Welche Eigenschaften hat ein Kunde?” “Was macht eine Bestellung aus?”

Use Cases und User Stories analysieren

Use Cases und User Stories sind Goldgruben für Datenanforderungen. Sie beschreiben, was Nutzer mit dem System tun wollen.

Beispiel User Story: “Als Kunde möchte ich Produkte in meinen Warenkorb legen, um sie später zu bestellen.”

Ableitung:

• Akteure: Kunde
• Datenobjekte: Produkt, Warenkorb, Bestellung
• Aktionen: hinzufügen, bestellen

Use Case “Bestellung aufgeben”:

1. Kunde wählt Produkte
2. System zeigt Warenkorb
3. Kunde gibt Lieferadresse ein
4. System berechnet Versandkosten
5. Kunde bestätigt Bestellung

Datenfluss erkennen: Welche Informationen werden an welchen Stellen benötigt? Dies zeigt dir, welche Attribute deine Datenobjekte haben müssen.

Dokumentation des Ableitungsprozesses

Dokumentiere nicht nur das Ergebnis, sondern auch den Prozess:

Was dokumentieren?

1. Anforderungsquelle: Woher stammt die Anforderung? (Interview, User Story, Prozessdokumentation)
2. Identifizierte Datenobjekte: Liste aller erkannten Objekte mit Begründung
3. Verworfene Alternativen: Warum wurde diese Struktur gewählt und nicht eine andere?
4. Annahmen: Welche Annahmen wurden getroffen? (z.B. “Ein Kunde hat max. 3 Lieferadressen”)
5. Offene Fragen: Was muss noch geklärt werden?

Vorteile:

• Nachvollziehbarkeit für spätere Änderungen
• Kommunikation mit Stakeholdern
• Onboarding neuer Teammitglieder

Werkzeuge: Markdown-Dokumente, Confluence, Enterprise Architect, PlantUML

Praktisches Beispiel: Buchverwaltungssystem

Angenommen, du entwickelst ein Buchverwaltungssystem. Welche Geschäftsobjekte sind relevant?

Identifizierte Objekte und ihre Attribute:

• Buch: Titel, Autor, Veröffentlichungsjahr, Genre
• Autor: Name, Geburtsdatum, Nationalität
• Genre: Name

Beziehungen zwischen den Objekten:

• Ein Autor kann mehrere Bücher geschrieben haben (1:N)
• Ein Buch gehört zu genau einem Genre (1:1)

Bücherverwaltungssystem (Bildrechte: Ausbildung in der IT)

⏳ Lädt Dataview-Inhalt...

Visualisierungswerkzeuge im Überblick

Nach der Identifikation von Geschäftsobjekten brauchst du Werkzeuge zur Visualisierung. Die Wahl des richtigen Werkzeugs hängt vom Kontext ab:

Entity-Relationship-Diagramme (ERD):

• Fokus auf Datenbank-Design
• Zeigen Entitäten, Attribute und Beziehungen
• Ideal für relationale Datenbanken

Klassendiagramme (UML):

• Fokus auf objektorientierte Systeme
• Zeigen Klassen, Attribute, Methoden und Vererbung
• Ideal für Software-Architektur

Wichtig für Kundenprojekte: Die Wahl des Werkzeugs beeinflusst nicht nur die Darstellung, sondern auch die Kommunikation mit Stakeholdern. Technische Stakeholder verstehen ERDs, Geschäfts-Stakeholder bevorzugen oft einfachere Darstellungen.

In dieser Lesson: Wir konzentrieren uns auf den Ableitungsprozess, nicht auf die Details der Notationen. ERDs und Klassendiagramme werden in eigenen Lerneinheiten vertieft.

Von Anforderungen zu Entitäten: Praktisches Mapping

Der Schritt von abstrakten Anforderungen zu konkreten Entitäten ist entscheidend. Hier ein systematisches Vorgehen:

Beispiel-Anforderung: “Kunden sollen Produkte bestellen können. Jede Bestellung hat eine Lieferadresse und einen Status.”

Mapping-Prozess:

1. Substantive identifizieren: Kunde, Produkt, Bestellung, Lieferadresse, Status

2. Entitäten vs. Attribute unterscheiden:

   • Entität: Hat eigene Identität und mehrere Eigenschaften (z.B. Kunde hat ID, Name, E-Mail)
   • Attribut: Einfache Eigenschaft ohne eigene Identität (z.B. Status ist Text-Wert)

3. Entscheidung treffen:

   • Kunde → Entität (hat ID, Name, E-Mail, Adresse)
   • Produkt → Entität (hat ID, Bezeichnung, Preis)
   • Bestellung → Entität (hat ID, Datum, Gesamtpreis)
   • Lieferadresse → Entität (hat Straße, PLZ, Stadt - könnte wiederverwendet werden)
   • Status → Attribut von Bestellung (einfacher Text-Wert)

Begründung dokumentieren: Warum ist Lieferadresse eine Entität? Weil ein Kunde mehrere Adressen haben kann und Adressen wiederverwendet werden.

Beziehungen modellieren: Entscheidungen treffen

Nachdem du Entitäten identifiziert hast, musst du deren Beziehungen modellieren. Die Kardinalität beschreibt, wie viele Instanzen einer Entität mit einer anderen in Beziehung stehen.

Die drei Kardinalitätstypen:

1:1 (Eins-zu-Eins)

• Jede Instanz von Entität A ist mit genau einer Instanz von Entität B verbunden und umgekehrt
• Beispiel: Ein Mitarbeiter hat genau einen Firmen-Laptop, ein Laptop gehört genau einem Mitarbeiter
• Wann verwenden? Bei exklusiven Beziehungen, wo jede Seite nur eine Verbindung haben kann
• Hinweis: Oft können 1:1-Beziehungen in eine einzige Tabelle zusammengefasst werden

1:N (Eins-zu-Viele)

• Eine Instanz von Entität A kann mit mehreren Instanzen von Entität B verbunden sein, aber B ist nur mit einem A verbunden
• Beispiel: Ein Kunde hat viele Bestellungen, aber jede Bestellung gehört zu genau einem Kunden
• Wann verwenden? Bei Hierarchien und Zugehörigkeiten (Abteilung → Mitarbeiter, Kategorie → Produkte)
• Implementierung: Fremdschlüssel in der N-Seite verweist auf die 1-Seite

N:M (Viele-zu-Viele)

• Mehrere Instanzen von A können mit mehreren Instanzen von B verbunden sein
• Beispiel: Produkte können in vielen Bestellungen vorkommen, Bestellungen enthalten viele Produkte
• Wann verwenden? Bei flexiblen Zuordnungen ohne feste Hierarchie
• Wichtig: N:M-Beziehungen werden in relationalen Datenbanken durch eine Zwischentabelle aufgelöst (z.B. BestellPosition mit Fremdschlüsseln zu Bestellung und Produkt)

Praktische Entscheidungsfragen:

• Kann ein Kunde mehrere Bestellungen haben? → 1:N
• Kann eine Bestellung mehrere Produkte enthalten UND ein Produkt in mehreren Bestellungen vorkommen? → N:M
• Muss ich historische Daten speichern? → Beeinflusst die Kardinalität (z.B. alte Adressen bei Umzug)

Trade-offs im Kundenprojekt: Normalisierung vs. Performance

Im realen Kundenprojekt musst du Entscheidungen zwischen verschiedenen Ansätzen treffen. Eine zentrale Frage: Wie stark normalisiere ich das Datenmodell?

Normalisierung (Grundidee):

• Daten werden in mehrere Tabellen aufgeteilt, um Redundanz zu vermeiden
• Vorteil: Datenintegrität, kein Duplikat-Problem
• Nachteil: Komplexere Abfragen (viele JOINs), potenziell langsamer

Denormalisierung (Grundidee):

• Daten werden bewusst redundant gespeichert für schnellere Abfragen
• Vorteil: Performance bei Leseoperationen
• Nachteil: Redundanz, Inkonsistenz-Gefahr

Projektentscheidung:

Wann stark normalisieren?

• Viele Schreiboperationen (INSERT, UPDATE, DELETE)
• Datenintegrität ist kritisch (z.B. Finanzsysteme)
• Speicherplatz ist begrenzt

Wann denormalisieren?

• Viele Leseoperationen, wenige Schreibvorgänge (z.B. Reporting)
• Performance ist kritischer als Speicherplatz
• Daten ändern sich selten

Für Kundenprojekte: Diese Entscheidung solltest du transparent mit dem Kunden besprechen und dokumentieren. Die Details zur Normalisierung lernst du in der Lerneinheit “Normalisierung von Datenbanken”.

Validierung mit Stakeholdern: Modelle präsentieren

Ein perfektes Datenmodell nützt nichts, wenn Stakeholder es nicht verstehen oder es die Anforderungen nicht abdeckt. Validierung ist essentiell:

Vorbereitung der Präsentation:

1. Zielgruppe anpassen:

   • Technische Stakeholder: ERDs, Kardinalitäten, Normalisierung
   • Geschäfts-Stakeholder: Vereinfachte Darstellung, Fokus auf Geschäftsobjekte

2. Visualisierung wählen:

   • Nutze einfache Diagramme ohne technischen Jargon für Non-Tech-Stakeholder
   • Zeige konkrete Beispiele: “So würde eine Bestellung mit Produkten aussehen”

3. Szenarien durchgehen:

   • “Kunde X bestellt Produkt Y” funktioniert das Modell?
   • “Was passiert, wenn ein Kunde seine Adresse ändert?” sind die Daten konsistent?

Feedback einholen:

• Frage explizit: “Deckt dieses Modell alle Ihre Anforderungen ab?”
• “Fehlen Informationen, die Sie später benötigen?”
• “Macht die Struktur aus Geschäftssicht Sinn?”

Iterieren: Datenmodelle entstehen selten in einem Durchgang. Nutze das Feedback für Anpassungen.

Häufige Fallstricke beim Ableiten vermeiden

Selbst erfahrene Entwickler machen Fehler beim Ableiten von Datenmodellen. Hier die häufigsten Fallstricke:

1. Zu früh an Implementierung denken:

• Fehler: “Welche Datenbank nutzen wir?” wird vor “Welche Daten brauchen wir?” gefragt
• Lösung: Fokus erst auf fachliches Modell, dann auf technische Umsetzung

2. Attribute als Entitäten modellieren:

• Fehler: “Status” wird eigene Tabelle mit ID, obwohl es nur 3 Werte gibt
• Lösung: Nur Entitäten wenn eigenständige Identität oder wiederverwendbar

3. Beziehungen falsch modellieren:

• Fehler: 1:N statt N:M Ein Produkt ist in einer Bestellung → falsch bei mehreren Bestellungen
• Lösung: Immer beide Richtungen prüfen: “Kann A mehrere B haben? Kann B mehrere A haben?”

4. Historische Daten ignorieren:

• Fehler: “Kunde hat eine Adresse” → Was, wenn Kunde umzieht und alte Bestellungen die alte Adresse haben?
• Lösung: Zeitdimension berücksichtigen

5. Stakeholder-Feedback zu spät einholen:

• Fehler: Komplettes Modell bauen, dann erst vorstellen
• Lösung: Früh validieren, iterativ arbeiten

⏳ Lädt Dataview-Inhalt...

Zusammenfassung und Ausblick

Zusammenfassung

Die Ableitung von Datenmodellen aus Geschäftsanforderungen folgt einem systematischen sechsstufigen Prozess: Anforderungen verstehen, Geschäftsobjekte identifizieren, Datenflüsse analysieren, Struktur festlegen, Modell visualisieren und mit Stakeholdern validieren. Der Prozess beginnt mit der Analyse von Geschäftsprozessen, Stakeholder-Interviews und Use Cases.

Zentrale Methoden der Identifikation:

• Substantiv-Methode: Substantive in Anforderungstexten sind oft Hinweise auf Datenobjekte
• Entitäten vs. Attribute unterscheiden: Entitäten haben eigene Identität und mehrere Eigenschaften, Attribute sind einfache Eigenschaften ohne eigene Identität
• Mapping-Prozess: Systematisches Vorgehen von abstrakten Anforderungen zu konkreten Entitäten

Beziehungen zwischen Entitäten werden durch Kardinalitäten modelliert:

Kardinalität	Bedeutung	Beispiel	Implementierung
1:1 (Eins-zu-Eins)	Jede Instanz ist mit genau einer anderen verbunden	Ein Mitarbeiter hat genau einen Firmen-Laptop	Oft in eine Tabelle zusammenfassbar
1:N (Eins-zu-Viele)	Eine Instanz kann mit mehreren anderen verbunden sein	Ein Kunde hat viele Bestellungen	Fremdschlüssel in der N-Seite
N:M (Viele-zu-Viele)	Mehrere Instanzen können mit mehreren anderen verbunden sein	Produkte in Bestellungen	Zwischentabelle erforderlich

Wichtige Entscheidungen im Kundenprojekt:

• Trade-offs Normalisierung vs. Performance: Balance zwischen Datenintegrität und Abfragegeschwindigkeit finden
• Validierung mit Stakeholdern: Zielgruppengerechte Präsentation (technisch vs. fachlich) und iteratives Vorgehen
• Dokumentation: Nicht nur Ergebnis, sondern auch Anforderungsquellen, verworfene Alternativen, Annahmen und offene Fragen dokumentieren

Häufige Fallstricke vermeiden:

• Nicht zu früh an Implementierung denken
• Attribute nicht als Entitäten modellieren
• Historische Daten berücksichtigen
• Stakeholder-Feedback früh einholen

Als Visualisierungswerkzeuge dienen Entity-Relationship-Diagramme (ERD) für Datenbank-Design und Klassendiagramme (UML) für objektorientierte Systeme.

Ausblick

Mit diesen Methoden kannst du systematisch von Kundenanforderungen zu funktionierenden Datenmodellen gelangen. In der Praxis wendest du diese Fähigkeiten in jedem Softwareprojekt an, das Daten strukturiert speichern muss. Die erlernten Techniken bilden die Grundlage für weiterführende Themen wie die detaillierte Modellierung mit Entity-Relationship-Diagrammen, Datenbankdesign mit SQL und die Normalisierung von Datenbankschemata.

---