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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
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.
Modellierungs-Ebenen: Drei abstraktions-Stufen — konzeptionell (was), logisch (wie), physisch (womit) — um fachliche Modelle von technischer Implementation zu trennen.
Frage: WAS wird modelliert?
Sprachen:
Beispiel: "Ein Kunde bestellt ein Produkt. Das Produkt hat einen Preis."
Frage: WIE wird es technisch strukturiert?
Sprachen:
Beispiel (relational):
Kunde (KundeID PK, Name, Email)
Bestellung (BestellID PK, KundeID FK, Datum)
Frage: WOMIT wird es konkret implementiert?
Sprachen:
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);
Der ANSI-SPARC Architektur-Vorschlag (1975) führte die 3-Ebenen-Architektur ein:
Datenunabhängigkeit:
Im ARIS-Haus (Scheer 1992) entspricht das Modellierungs-Ebenen-Konzept den 3 Ebenen:
Die 3 Ebenen werden auf alle 5 ARIS-Sichten (Daten / Funktion / Organisation / Steuerung / Leistung) angewendet → 5 × 3 = 15 Modellierungs-Felder.
| 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). |
Das Trennen der Ebenen ist nicht akademisch — es ermöglicht Investitions-Schutz:
Wenn Konzept und Physisch direkt verkoppelt wären, würde jede DBMS-Migration das gesamte Modell brechen.
| 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) |
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).
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.
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.
6 Aufgaben zu Zuordnung von Modellen, ANSI-SPARC und Datenunabhängigkeit.
Klausurfragen mit Lösungen (6)
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.
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.
Zuordnungen:
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
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.
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
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).
6 typische Klausurfragen zu ANSI-SPARC und Modellierungs-Ebenen.
Klausurfragen mit Lösungen (6)
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.
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.
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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).
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