LU04a - Konzeptionelles vs. Logisches Schema

Eine Datenbank zu designen ist wie ein Haus zu bauen – ohne durchdachten Bauplan geht es nicht. Erst die Planung, dann die Umsetzung (in SQL).

Stellen wir uns vor, wir sollen ein Haus bauen. Bevor die Handwerker loslegen, passiert einiges:

• Zuerst sprechen wir mit der Bauherrschaft: Was soll das Haus können? Wie viele Zimmer? Soll eine Garage dabei sein? Welche Vorstellungen gibt es vom Budget oder vom Stil?
• Danach macht die Architektin oder der Architekt einen Bauplan: Räume, Türen, Fenster, Treppen, vielleicht auch schon, wo Strom- oder Wasserleitungen verlaufen.
• Erst im letzten Schritt kommen die Handwerker:innen und legen genau fest, welche Materialien wo eingesetzt werden (z. B. Beton für tragende Wände, Holz für Türen, Kabel für Strom).

Genau so funktioniert auch das Design einer Datenbank:

• Zuerst klären wir: Welche Informationen sollen gespeichert werden? (fachliche Sicht)
• Dann machen wir einen Plan: Welche Objekte gibt es und wie hängen sie zusammen?
• Am Ende folgt die technische Umsetzung: Tabellen, Primär- und Fremdschlüssel, Datentypen.

Das konzeptionelle Schema ist wie der Bauplan: Es zeigt die Objekte (Entitäten), ihre Eigenschaften (Attribute) und die Beziehungen – aber noch ohne technische Details.

Beispiel:

• Entität Film (Attribute: Titel, Jahr)
• Entität Regisseur (Attribute: Name)
• Beziehung: *dreht* zwischen Film und Regisseur

Charakteristik:

• Fokus: Welche Objekte gibt es und wie hängen sie zusammen?
• Nur grobe Attribute sichtbar
• Ideal, um mit Anwender:innen oder Auftraggeber:innen zu sprechen
• Hierfür eignet sich ein ERD in Chen-Notation ¹⁾

Im nächsten Schritt übersetzen wir den Bauplan in eine technische Skizze: Das logische Schema. Hier sehen wir schon, wie die Datenbank als Tabellen aussieht.

Beispiel:

• Film (FilmID PK, Titel VARCHAR, Jahr INT, RegisseurID FK)
• Regisseur (RegisseurID PK, Name VARCHAR)
• Beziehung: 1 Regisseur ↔ n Filme

Charakteristik:

• Fokus: Technische Umsetzung
• Entitäten werden zu Tabellen
• Attribute werden zu Spalten mit Datentypen
• Primärschlüssel (PK) und Fremdschlüssel (FK) klar markiert
• Kardinalitäten (1:1, 1:n, n:m) sichtbar
• Direkte Vorbereitung für die Umsetzung der Datenbank mit SQL

Bei einem Haus legen wir fest, aus welchem Material die einzelnen Teile bestehen sollen (z. B. Beton für tragende Wände, Glas für Fenster, Holz für Türen). Ähnlich ist es bei den Spalten einer Tabelle (bzw. den Attributen einer Entität): Damit eine Datenbank stabil, effizient und sinnvoll funktioniert, müssen wir den passenden Datentyp für jede Spalte wählen.

• INT = ganze Zahlen (z. B. 1, 2, 3, … 99554, 99555). → Eignet sich für IDs oder Stückzahlen, die immer ganze Werte haben.
• FLOAT oder DOUBLE = Kommazahlen mit ungefährer Genauigkeit. → Gut für Messwerte, die eine gewisse Toleranz erlauben (z. B. Temperaturen, Sensorwerte).
• DECIMAL(n,m) = Kommazahlen mit exakter Genauigkeit. → Ideal für Geldbeträge, Preise oder Rechnungen (z. B. DECIMAL(10,2) für Werte bis 99.999.999,99).
• VARCHAR(n) = Texte mit variabler Länge (z. B. Namen, Beschreibungen). → VARCHAR(50) für kurze Titel, VARCHAR(255) für längere Beschreibungen.
• DATE = speichert nur ein Datum (YYYY-MM-DD).
• DATETIME = speichert Datum und Uhrzeit (YYYY-MM-DD hh:mm:ss). → Gut für Bestelldatum, Lieferzeitpunkt etc.

Die Wahl des „Materials“ (der richtigen Datentypen) ist entscheidend:

• Mit dem richtigen Datentyp bleibt die Datenbank robust (keine widersprüchlichen Werte),
• effizient (keine unnötige Speicherplatzverschwendung)
• und praxisnah (z. B. exakte Preise statt ungenauer Rundungen).

Auf der nächsten Seite schauen wir uns die Crow's Foot Notation genauer an.