Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Modellierungs-Ebenen: konzeptionell → logisch → physisch
WAS, WIE, WOMIT. Die 3-Ebenen-Architektur trennt fachliche Inhalte, technische Struktur und konkrete Implementation. Klausurpflicht in 9/15 Modellierungs-Modulen, Standard in DB-Design (ANSI-SPARC 1975) und in ARIS.
Die Idee in einem Satz
Modellierungs-Ebenen: Drei abstraktions-Stufen, konzeptionell (was), logisch (wie), physisch (womit), um fachliche Modelle von technischer Implementation zu trennen.
Die 3 Ebenen im Detail
1. Konzeptionelle Ebene (Conceptual Data Model, CDM)
Frage: WAS wird modelliert?
- Sprache der Fachexperten
- Frei von technischen Details
- Stabil über Technologie-Wechsel
- Modelliert reale Welt: Objekte, Beziehungen, Geschäftsprozesse
Sprachen:
- ER-Diagramm (Datenmodellierung)
- UML-Klassendiagramm
- BPMN (Prozessmodellierung)
- EPK (ARIS)
Beispiel: "Ein Kunde bestellt ein Produkt. Das Produkt hat einen Preis."
2. Logische Ebene (Logical Data Model, LDM)
Frage: WIE wird es technisch strukturiert?
- Technik-spezifisch (z.B. relational)
- Aber unabhängig vom konkreten System (DBMS)
- Sprache der DB-Architekten / Designer
Sprachen:
- Relationen-Schema (Tabellen + Spalten + Fremdschlüssel)
- Klassen-Hierarchie (für OOP-Systeme)
- Service-Architektur (für Microservices)
Beispiel (relational):
Kunde (KundeID PK, Name, Email)
Bestellung (BestellID PK, KundeID FK, Datum)
3. Physische Ebene (Physical Data Model, PDM)
Frage: WOMIT wird es konkret implementiert?
- Konkretes System (PostgreSQL, MongoDB, Oracle)
- Mit Indexen, Datentypen, Partitionierung, Konfiguration
- Sprache der Entwickler / DBAs / DevOps
Sprachen:
- SQL-DDL für relationale DBs
- NoSQL-Schema (z.B. JSON Schema für MongoDB)
- Konkrete Programmiersprachen
Beispiel (PostgreSQL DDL):
CREATE TABLE Kunde (
KundeID SERIAL PRIMARY KEY,
Name VARCHAR(100) NOT NULL,
Email VARCHAR(255) UNIQUE
);
CREATE INDEX idx_kunde_email ON Kunde(Email);
Historischer Hintergrund: ANSI-SPARC (1975)
Der ANSI-SPARC Architektur-Vorschlag (1975) führte die 3-Ebenen-Architektur ein:
- External Schema (User-Views), wie sehen einzelne Nutzer-Gruppen die Daten?
- Conceptual Schema, was sind die Daten (logisch)?
- Internal Schema, wie sind die Daten gespeichert (physisch)?
Datenunabhängigkeit:
- Logische Datenunabhängigkeit: Änderungen am konzeptionellen Schema verändern External Schemas nicht (z.B. neue Spalte in DB ohne View-Anpassung).
- Physische Datenunabhängigkeit: Änderungen am internen Schema (Index, Speicher) verändern konzeptionelles nicht.
ARIS-Bezug
Im ARIS-Haus (Scheer 1992) entspricht das Modellierungs-Ebenen-Konzept den 3 Ebenen:
- Fachkonzept ≈ konzeptionell (WAS)
- DV-Konzept ≈ logisch (WIE)
- Implementierung ≈ physisch (WOMIT)
Die 3 Ebenen werden auf alle 5 ARIS-Sichten (Daten / Funktion / Organisation / Steuerung / Leistung) angewendet → 5 × 3 = 15 Modellierungs-Felder.
Forward-Engineering vs. Reverse-Engineering
| Richtung | Beschreibung |
|---|---|
| Forward Engineering | Konzept → Logisch → Physisch. Standard-Vorgehen beim Neubau. |
| Reverse Engineering | Physisch → Logisch → Konzept. Bei Legacy-Systemen, Reengineering. |
| Round-Trip Engineering | Synchronisation zwischen Ebenen, Tool-unterstützt (z.B. ERwin, Enterprise Architect). |
Datenunabhängigkeit als Designprinzip
Das Trennen der Ebenen ist nicht akademisch, es ermöglicht Investitions-Schutz:
- WAS überlebt Technologie-Wechsel: Konzeptionelles Modell ist stabil. Ein Online-Shop hat heute, morgen, in 20 Jahren noch Kunden + Bestellungen + Produkte.
- WIE ist Technologie-spezifisch: Relational, NoSQL, GraphDB, wechseln möglich.
- WOMIT ändert sich oft: Oracle → PostgreSQL → CockroachDB. Cloud-Migration. Etc.
Wenn Konzept und Physisch direkt verkoppelt wären, würde jede DBMS-Migration das gesamte Modell brechen.
Modellierungs-Werkzeuge nach Ebene
| Ebene | Werkzeuge |
|---|---|
| Konzeptionell | ER-Studio, Sparx Enterprise Architect, draw.io, Lucidchart |
| Logisch | dbdiagram.io, ERwin, MySQL Workbench (Designer-Modus) |
| Physisch | DBMS-Tools (pgAdmin, DataGrip), CI/CD-Migrations (Prisma, Flyway, Liquibase) |
Klausur-Faustregeln
1. 3 Ebenen: konzept → logisch → physisch. WAS → WIE → WOMIT.
2. Konzeptionell = Fachexperte, technisch frei. ER-Diagramm + UML-Klassendiagramm typisch.
3. Logisch = relational (oder NoSQL etc.), DBMS-unabhängig. Relationen-Schema mit PK/FK.
4. Physisch = konkrete DDL mit Datentypen + Indexen.
5. ANSI-SPARC 1975, Original-Vorschlag für 3-Ebenen.
6. Datenunabhängigkeit: logisch (Konzept ↔ View) + physisch (Konzept ↔ Speicher).
Häufige Stolpersteine
1. Konzeptionell mit Logisch verwechseln. ER-Diagramm ist KONZEPT (mit Entitäten + Beziehungen). Relationen-Schema ist LOGISCH (mit Tabellen + PK/FK). Beide sehen ähnlich aus, sind aber semantisch verschieden.
2. Logisch mit Physisch verwechseln. Relationen-Schema (logisch) hat KEINE konkreten Datentypen, keine Indexe, keine DBMS-Spezifika. Sobald Datentypen rein → physisch.
3. ANSI-SPARC mit ARIS verwechseln. ANSI-SPARC: DB-Architektur (External/Conceptual/Internal). ARIS: Unternehmens-Architektur (5 Sichten × 3 Ebenen). Beide haben 3-Ebenen-Konzept, sind aber verschieden.
4. Datenunabhängigkeit als Magie betrachten. Nicht automatisch, DBMS muss View-Mechanismus + Mapping-Layer bieten. Bei NoSQL oft weniger Unabhängigkeit.
5. Forward Engineering als einzigen Weg sehen. Reverse Engineering ist Standard bei Legacy-Systemen. Round-Trip ist ideal aber schwierig.
6. ER-Diagramm direkt zu SQL übersetzen. Sollte über logische Ebene (Relationen-Schema) erfolgen. Übersprungene Ebene = verlorene Dokumentation.
Interaktiv verstehen
Modellierungs-Ebenen-Pyramide
Klick auf eine Ebene zeigt Fokus, Zielgruppe, Modellierungs-Sprachen und konkretes Beispiel (Online-Shop-Datenmodell).
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Bei "Welche Modellierungs-Ebene?" IMMER 3-Fragen-Test: 1) Geht es um Fachinhalte ohne Technik? → konzeptionell. 2) Geht es um relationale/NoSQL-Struktur ohne konkretes DBMS? → logisch. 3) Geht es um SQL-DDL / spezifisches DBMS / Indexe? → physisch. Klassiker: ER-Diagramm = konzeptionell, Relationen-Schema = logisch, CREATE TABLE = physisch.
Praxis-Übung
Modellierungs-Ebenen, Praxis-Übung
6 Aufgaben zu Zuordnung von Modellen, ANSI-SPARC und Datenunabhängigkeit.
Klausurfragen mit Lösungen (6)
- F1.Welche Modellierungs-Ebene gibt es laut Standard NICHT?
Antwort: Strategische Ebene
Erklärung: Standard-Modellierungs-Ebenen: konzeptionell (CDM) + logisch (LDM) + physisch (PDM). 'Strategische Ebene' ist KEIN Standard-Modellierungs-Ebenen-Begriff (gibt's in Business-Architektur, aber nicht in Datenbank-Modellierung). Klausur-Klassiker.
- F2.Welche Sprache passt typisch zur konzeptionellen Ebene?
Antwort: ER-Diagramm
Erklärung: ER-Diagramm = konzeptionelle Ebene (Entitäten + Beziehungen, frei von Technik). SQL-DDL + PostgreSQL-Spezifika = physisch. Relationen-Schema mit PK/FK = logisch. ER kann mit UML-Klassendiagramm gemischt werden (auch konzeptionell). Klausur-Standard.
- F3.Ordne Modell-Beispiel der richtigen Ebene zu.
Zuordnungen:
- ER-Diagramm → Konzeptionell
- Relationen-Schema (Tabellen + PK/FK) → Logisch
- CREATE TABLE mit Indexen → Physisch
- UML-Klassendiagramm → Konzeptionell
Erklärung: Standard-Zuordnung: konzeptionell = ER-Diagramm + UML-Klassendiagramm (Entitäten/Klassen + Beziehungen). Logisch = Relationen-Schema (Tabellen + PK/FK, ohne Datentypen). Physisch = SQL-DDL (mit Datentypen, Indexen, DBMS-Spezifika). Faustregel: konzept = nur Wesen, logisch = Struktur (relational/OOP), physisch = konkrete Implementation.
Typ: Zuordnung
- F4.Was bedeutet 'logische Datenunabhängigkeit' nach ANSI-SPARC?
Antwort: Änderungen am konzeptionellen Schema verändern External-Views nicht zwingend
Erklärung: Logische Datenunabhängigkeit (ANSI-SPARC 1975): Änderungen am konzeptionellen Schema (z.B. neue Spalte) verändern External Schemas (User-Views) nicht, wenn das DBMS einen guten View-Mechanismus hat. Pendant: Physische Datenunabhängigkeit (Index-/Speicher-Änderungen verändern konzeptionell nicht). Beide ermöglichen Investitions-Schutz.
- F5.Forward Engineering geht von konzept zu physisch, Reverse Engineering den umgekehrten Weg.
Antwort: Wahr
Erklärung: RICHTIG. Forward Engineering: WAS → WIE → WOMIT (konzept → logisch → physisch). Standard-Vorgehen beim Neubau. Reverse Engineering: WOMIT → WIE → WAS (physisch → logisch → konzept). Üblich bei Legacy-Systemen ohne Doku. Round-Trip Engineering: bidirektional synchronisiert (Tools wie Enterprise Architect, ERwin).
Typ: Wahr/Falsch
- F6.Welche Aussage zur 3-Ebenen-Architektur (ANSI-SPARC 1975) ist FALSCH?
Antwort: Alle 3 Schemas müssen identisch sein
Erklärung: FALSCH ist Aussage D. Die 3 Schemas sind ABSICHTLICH UNTERSCHIEDLICH, das ist der Witz von ANSI-SPARC: Trennung ermöglicht Datenunabhängigkeit. External Schemas zeigen nutzer-spezifische Sichten (z.B. Manager sieht aggregierte Daten, Sachbearbeiter sieht Details). Conceptual Schema ist die universelle Logik-Sicht. Internal Schema beschreibt Speicher (Indexe, Partitionierung).
Klausur-Quiz
Modellierungs-Ebenen, Klausur-Quiz
6 typische Klausurfragen zu ANSI-SPARC und Modellierungs-Ebenen.
Klausurfragen mit Lösungen (6)
- F1.Welche Frage beantwortet die konzeptionelle Modellierungs-Ebene?
Antwort: WAS?
Erklärung: Konzeptionell = WAS (fachlich modelliert). Logisch = WIE (technische Struktur, DBMS-unabhängig). Physisch = WOMIT (konkretes DBMS, Datentypen, Indexe). WANN ist kein Standard-Ebenen-Konzept. Eselsbrücke: Was-Wie-Womit von oben nach unten.
- F2.Wer entwickelte den Vorschlag der 3-Ebenen-Architektur für Datenbanken?
Antwort: ANSI-SPARC (1975)
Erklärung: ANSI-SPARC: American National Standards Institute, Standards Planning and Requirements Committee, 1975. Vorschlag für 3-Ebenen-DB-Architektur (External / Conceptual / Internal Schema) + Datenunabhängigkeit. Codd = relationales Modell (1970). Scheer = ARIS (1992). Date = DB-Lehrbücher.
- F3.Die {{1}} Ebene ist Sprache der Fachexperten ohne Technik. Die {{2}} Ebene beschreibt z.B. Tabellen und Fremdschlüssel ohne konkretes DBMS. Die {{3}} Ebene enthält konkrete SQL-DDL mit Datentypen + Indexen. {{4}}-SPARC (1975) führte diese 3-Schichten-Trennung als Standard ein.
Lösungen pro Lücke:
- {{1}}: konzeptionelle / konzept
- {{2}}: logische / logisch
- {{3}}: physische / physisch
- {{4}}: ANSI
Erklärung: Standard-Modellierungs-Ebenen: konzeptionell (WAS) → logisch (WIE) → physisch (WOMIT). ANSI-SPARC 1975 hat das als 3-Schichten-DB-Architektur etabliert (External/Conceptual/Internal). Diese 4 Fakten sind DB-Klausur-Standard.
Typ: Lückentext
- F4.Bringe die Modellierungs-Ebenen in der korrekten Forward-Engineering-Reihenfolge (von abstrakt zu konkret).
Richtige Reihenfolge:
- Konzeptionelle Ebene (ER-Diagramm)
- Logische Ebene (Relationen-Schema mit PK/FK)
- Physische Ebene (CREATE TABLE in PostgreSQL)
Erklärung: Forward Engineering: WAS → WIE → WOMIT. 1) Konzept (ER-Diagramm, fachlich). 2) Logisch (Relationen-Schema, technik-spezifisch aber DBMS-frei). 3) Physisch (CREATE TABLE in konkretem DBMS mit Datentypen + Indexen). Jeder Schritt verfeinert. Reverse Engineering geht den umgekehrten Weg (z.B. bei Legacy-Systemen).
Typ: Reihenfolge
- F5.Was bietet 'physische Datenunabhängigkeit' nach ANSI-SPARC?
Antwort: Änderungen am internen Schema (Indexe, Speicher) verändern das konzeptionelle Schema NICHT
Erklärung: Physische Datenunabhängigkeit: Änderungen am internen Schema (DB-Indexe, Partitionierung, Speicher-Engine) verändern das konzeptionelle Schema NICHT. Beispiel: neuer Index hinzufügen → kein Code-Change in Anwendungs-Schicht. Logische Datenunabhängigkeit (Pendant): Änderungen am konzeptionellen Schema verändern External Views nicht (z.B. neue Spalte → bestehende Views funktionieren weiter).
- F6.Im ARIS-Modell von Scheer entsprechen 'Fachkonzept / DV-Konzept / Implementierung' den 3 Modellierungs-Ebenen konzeptionell / logisch / physisch.
Antwort: Wahr
Erklärung: RICHTIG. ARIS (Scheer 1992) übernimmt 3-Ebenen-Idee: Fachkonzept = konzeptionell (WAS, EPK/ERM), DV-Konzept = logisch (WIE, BPMN/Relationen-Schema), Implementierung = physisch (WOMIT, BPMS/SQL-DDL). Diese 3 Ebenen werden auf alle 5 ARIS-Sichten angewendet → 5 × 3 = 15 Modellierungs-Felder. Klausur-Klassiker bei ARIS-Fragen.
Typ: Wahr/Falsch
