# Modellierung – Zusammenfassung
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–112**

---

## 1. Einführung (Folien 1–32)

### 1.1 Definitionen (Folien 3–6)

**Charakteristik der Informationen im Unternehmen:**
- Informationen bilden Entscheidungsgrundlagen
- Informationen können aus unterschiedlichen Quellen stammen
- Qualität hängt von Verfügbarkeit, Korrektheit und Vollständigkeit ab
- Erhebung, Speichern und Verarbeiten erzeugt Aufwände
- Aufgabengebiete sind durch Informationsbeziehungen verknüpft

**Aspekte des Datenmanagements:**
- Architektur (Datenmodellierung)
- Datentechnik (Hardware, Installation, Reorganisation, Sicherung)
- Administration und Datennutzung

**Anforderungen an Datenverwaltung:**
- Zentrale Verwaltung der Daten
- Vermeidung/Einschränkung von Redundanzen
- Vermeidung von Inkonsistenzen
- Gemeinsame Nutzung durch verschiedene Anwendungen
- Datenschutz und Datensicherung
- Datenintegrität
- Datenunabhängigkeit von Anwendungen

**Definitionen:**
- **Daten** = Logisch strukturierte Informationseinheiten
- **Datenbank** = Einrichtung für langfristige sichere Aufbewahrung von Daten

### 1.2 Modellierung (Folien 7–9)

Ein **Modell** ist ein Abbild der realen Welt, das man mit Absicht erstellt, um bestimmte Probleme zu lösen.

**Modellbildungsprozess:**
Reales Problem → Modell → Analyse/Simulation → Theoretische Lösung → Interpretation → Überprüfung → Reale Lösung

**Kriterien eines Modells nach Heinrich Hertz:**
1. **Richtigkeit** — Nicht beweisbar, nur durch Experimente überprüfbar und widerlegbar
2. **Zulässigkeit** — Logisch eindeutig formuliert, ohne Widersprüche
3. **Zweckmäßigkeit** — Keine überflüssigen Anteile; so einfach wie möglich, so kompliziert wie nötig

**Modellierungsansätze:** Verschiedene Modellierungssprachen führen zu verschiedenen semantischen Datenmodellen. Praktische Bedeutung haben insbesondere **Entity-Relationship-Modellierung (ERM)** und **UML**. Gängige Vorgehensweise: Erst ER-Modell, dann Konvertierung in relationales Modell.

### 1.3 Datenhaltung (Folien 10–14)

Zwei grundsätzliche Formen:
1. **Herkömmliche Form (Dateien):** Datenverwaltung in die Anwendung integriert → enormer Entwicklungsaufwand, kaum Datenaustausch
2. **Datenbanken:** Datenbank = Datenmanagement + Daten. DBMS übernimmt Speicherung, Aufruf, Änderungen, Sortieren, Sicherungen

**Vorteile von Datenbanken gegenüber Dateien:**
- Reduktion der Entwicklungskosten
- Flexible Verarbeitung und Darstellung
- Vermeidung von Redundanzen, Inkonsistenzen, Datenverlust
- Zugriffskontrolle
- Mehrbenutzerbetrieb
- Hohe Verfügbarkeit

**Dateien statt Datenbanken empfohlen bei:**
- Sehr kleinen, nicht-kommerziellen Anwendungen
- Systemnahen Anwendungen
- Verschiedenen Testumgebungen
- Groben konzeptuellen Entwicklungen

### 1.4 Architektur (Folien 15–18)

**Client/Server-Architektur:**
- **Client** nimmt die Ressource in Anspruch (z. B. Darstellung)
- **Server** stellt die Ressource zur Verfügung (z. B. Bearbeitung)

**Oracle-Architektur:**
- SQL-Plus, SQL-Developer, Oracle Instant Client → Listener → Dispatcher → DBMS-Instanzen → Datenbestände
- Multi-Tenant-Container und Real Application Cluster (RAC)

**SQLite-Architektur (keine Client/Server-Architektur):**
- DBMS-Instanz direkt in die Anwendung eingebettet
- Datenbestand als Dateien im Dateisystem

### 1.5 Datenbankbenutzer (Folien 19–20)

| Rolle | Aufgaben |
|---|---|
| **DBA (Datenbankadministrator)** | DB-Design, Softwareinstallation/-wartung, Speicherplatzverwaltung, Sicherheitsmechanismen, Backup/Recovery, Reorganisation, Systembeobachtung/Tuning |
| **Anwendungsentwickler** | Systemanalyse, SQL, Standard-Abfragen, Anwendungsentwicklung |
| **Endanwender** | Benutzung erstellter Programme, vorgefertigte/Ad-Hoc-Abfragen, QBE-Werkzeuge |

### 1.6 Entwicklung (Folien 21–24)

- **1960er Jahre:** Jede Anwendung hat eigenes Datenmanagement und eigene Daten
- **1970er Jahre:** Gemeinsames Datenmanagement, aber noch getrennte Datenbestände
- **Heute:** Gemeinsames Datenmanagement und gemeinsame Datenbestände

Zugriff auf Datenbanken erfolgt programmatisch z. B. über **JDBC** (Java Database Connectivity).

### 1.7 Arten von Datenbanken (Folien 25–28)

| Art | Status |
|---|---|
| Hierarchische Datenbanken | Heute selten verwendet |
| Netzartige Datenbanken | Heute selten verwendet |
| Dokumentenbasierte Datenbanken | Selten verwendet (z. B. MongoDB) |
| Key-Value-Datenbanken | Begrenzte Bedeutung (z. B. BerkeleyDB) |
| Objektorientierte Datenbanken | Vorhanden |
| **Relationale Datenbanken** | **Heute fast ausschließlich verwendet** |

**Warum relationale Datenbanken dominieren:**
- Beziehungen und Entitäten werden gleich dargestellt → derselbe Verarbeitungsmechanismus
- Relationale Algebra liefert umfangreiche und fortgeschrittene Operationen
- Alle anderen DB-Typen lassen sich damit emulieren

### 1.8 Prinzipien von E.F. Codd (Folien 29–32)

Die **12 Regeln von Codd** definieren eine relationale Datenbank:

1. Vollständige Verwaltung über relationale Fähigkeiten
2. **Darstellung von Informationen:** Alle Informationen als Werte in Tabellen
3. **Zugriff auf Daten:** Über Tabellenname + Primärschlüssel + Spaltenname
4. **Systematische Behandlung von Nullwerten:** Durchgängig gleich als unbekannt/fehlend
5. **Struktur:** Systemkatalog auf derselben logischen Ebene wie die Daten
6. **Abfragesprache:** Mindestens eine Sprache mit vollständigem Befehlssatz (DDL, DML, Integrität, Autorisierung, Transaktionen)
7. **Aktualisieren von Sichten:** Theoretisch aktualisierbare Sichten müssen vom System aktualisierbar sein
8. **Abfragen und Bearbeiten:** Unterstützung für Einfügen, Aktualisieren und Löschen ganzer Tabellen
9. **Physikalische Datenunabhängigkeit:** Logischer Zugriff unabhängig von physikalischen Methoden
10. **Logische Datenunabhängigkeit:** Tabellenstruktur-Änderungen ohne Einfluss auf Anwendungslogik
11. **Unabhängigkeit der Integrität:** Integritätsregeln in der DB-Sprache definierbar, nicht umgehbar
12. **Verteilungsunabhängigkeit:** Logischer Zugriff unverändert bei verteilten Datenbanken

---

## 2. Mengenlehre (Folie 33)

Die Mengenlehre bildet die mathematische Grundlage der Theorie relationaler Datenbanken. Behandelt in separatem Skript (b_Mengenlehre). Themen: Definition, Eigenschaften, Operationen, Zahlenmengen, Dimensionen.

---

## 3. ANSI-SPARC-Modell (Folien 34–38)

### 3.1 Drei-Schichten-Architektur (Folien 35–37)

Das ANSI-SPARC-Modell gewährleistet Unabhängigkeit der Datenbank von Programmiersprache und Hardware:

| Ebene | Bezeichnung | Inhalt |
|---|---|---|
| **Externe Ebene** | Anwendungs-Ebene | Benutzeroberflächen, Datensichten, API, Schnittstellen. Jede Sicht zeigt nur einen Teil der Daten |
| **Konzeptionelle Ebene** | Logische Ebene | Beziehungen, Daten. Relationales Datenmodell, ERM-Diagramme, Integritätsbedingungen, Zugriffsrechte |
| **Interne Ebene** | Physische Ebene | Art und Form der Speicherung. Dateien, Partitionen, Tablespaces, Zugriffsmechanismen |

### 3.2 Phasen des Datenbankentwurfs (Folie 38)

1. **Anforderungsanalyse** → Spezifikation (Pflichtenheft)
2. **Konzeptueller Entwurf** → Konzeptuelles Schema (ERM)
3. **Logischer Entwurf** → Logisches Schema (Tabellen)
4. **Physischer Entwurf** → Physisches Schema (Datenträger)

---

## 4. Anforderungsanalyse (Folien 39–50)

### 4.1 Kurzfassung (Folien 40–42)

Im Laufe der Anforderungsanalyse wird erfasst:
- Welche Abteilungen mit der DB arbeiten
- Welche Geschäftsprozesse unterstützt werden
- Welche Daten involviert werden
- Wie die Daten strukturiert sind
- Qualitative und quantitative Anforderungen

**Schritte nach A. Kemper:**
1. Identifikation von Organisationseinheiten
2. Identifikation der zu unterstützenden Aufgaben
3. Anforderungs-Sammelplan (zu befragende Personen)
4. Anforderungs-Sammlung
5. Filterung (Verständigkeit und Eindeutigkeit prüfen)
6. Satzklassifikationen (Objekte, Beziehungen, Operationen, Ereignisse)
7. Formalisierung/Systematisierung (ins Pflichtenheft übertragen)

**Ergebnisse der Anforderungsanalyse:**
- **Informationsanforderungen:** Beschreibung von Objekten/Attributen und Beziehungen/Attributen
- **Datenverarbeitungsanforderungen:** Beschreibung von Prozessen

### 4.2 Beispiel: Universitätsschema (Folien 43–46)

Drei Arten von Beschreibungen:

**Objektbeschreibung** (z. B. Uni-Angestellte):
| Attribut | Typ | Länge | Identifizierend | Beispiel |
|---|---|---|---|---|
| PersonalNr | Char | 10 | ja | 1234561234 |
| Gehalt | Dezimal | 8.2 | nein | 9000.11 |
| Rang | String | 4 | nein | W3 |

**Beziehungsbeschreibung** (z. B. prüfen):
- Beteiligte Objekte: Professor (Prüfer), Student (Prüfling), Vorlesung (Lehrstoff)
- Attribute: Datum, Uhrzeit, Note

**Prozessbeschreibung** (z. B. Zeugnisausstellung):
- Häufigkeit, Priorität, benötigte Daten, Datenmenge

### 4.3 Beispiel: Krankenhaus-Modell (Folien 47–50)

Objekte: Ärzte, Pflegepersonal, Patienten mit deren Beziehungen (behandelt, betreut) und Prozessen (Behandlungsplan erstellen).

---

## 5. Konzeptueller Entwurf (Folien 51–87)

### 5.1 Entity-Relationship-Modell (ERM) (Folien 51–54)

Auf Basis der Anforderungsanalyse wird ein konzeptuelles ERM erstellt. Das konkrete DBMS wird noch nicht betrachtet.

**Beispiele:**
- **Uni-Schema:** Studenten, Vorlesungen, Professoren, Assistenten mit Beziehungen hören, prüfen, lesen, arbeitenFür, voraussetzen
- **Krankenhaus-Schema:** Arzt, Patient, Pflegepersonal mit Beziehungen behandelt, betreut

### 5.2 Modellierungsstrukturen in Peter-Chen-Notation (Folie 55)

| Element | Grafische Darstellung | Bedeutung |
|---|---|---|
| **Entitätstypen** | Rechteck | Objekte der realen Welt |
| **Beziehungstypen** | Raute | Bindungen zwischen Entitäten |
| **Attribute** | Oval/Kreis | Charakteristiken von Entitäten und Beziehungen |
| **Funktionalitäten** | Beschriftung an Verbindungslinien | Kardinalität der Beziehungen |
| **Schlüssel** | Unterstrichene Attribute | Identifizierende Attribute |
| **Rollen** | Beschriftung bei rekursiven Beziehungen | Rolle einer Entität in der Beziehung |

### 5.3 Entitätstypen (Folie 56)

Gegenstände sind Objekte der realen Welt, die zu **Gegenstandstypen (Entitätstypen)** abstrahiert werden:
- "Zimmermann", "Merkel", "Meier" → **Mensch**
- "VW", "Mercedes", "BMW" → **Auto**

Man arbeitet ausschließlich mit Entitätstypen (abstrakte Klassen), nicht mit einzelnen Instanzen.

### 5.4 Beziehungstypen (Folie 57)

Beziehungen drücken Bindungen zwischen Entitäten aus. Nicht alle Entitätstypen müssen verbunden sein, aber ein alleinstehender Entitätstyp ohne Beziehung ist verdächtig.

### 5.5 Attribute (Folien 58–62)

**Attributierte Beziehungen:** Wenn beide Entitätstypen semantisch gleiche Attribute haben, werden diese dem Beziehungstyp zugeordnet (z. B. Betrag bei "Kredit geben" zwischen Kunde und Bank).

**Entscheidung Entitätstyp vs. Attribut:**
- Wird etwas durch anderes beschrieben → das Beschriebene ist Entitätstyp, das Beschreibende ist Attribut
- Kann etwas durch nichts weiteres beschrieben werden → es ist ein Attribut

**Attributtypen:**

| Typ | Beschreibung | Beispiel |
|---|---|---|
| **Einfach** | Ein Wert zu einem Zeitpunkt | Name = "Müller" |
| **Mehrwertig** | Mehrere Werte gleichzeitig | Ampel: rot + gelb |
| **Zusammengesetzt** | Besteht aus Teilattributen | Adresse: PLZ + Ort + Straße |
| **Abgeleitet** | Aus anderen Attributen berechnet | Bruttopreis = Netto × (1 + MwSt) |

### 5.6 Schlüssel und Primärschlüssel (Folien 63–65)

- **Schlüssel:** Attributmenge, deren Werte eine Entität eindeutig identifizieren
- **Schlüsselkandidaten:** Mehrere mögliche Schlüssel
- **Primärschlüssel (PK):** Der Kandidat mit minimaler Länge, im ERM unterstrichen
- **Minimaler Schlüssel:** Keine Untermenge des PK bildet selbst einen Schlüssel
- **Wichtig:** Wahl eines anderen PK ändert das gesamte Modell

### 5.7 Rekursive Beziehungen (Folie 66)

Beziehungen zwischen Entitäten desselben Entitätstyps. Dabei werden **Rollen** zugeschrieben.

**Beispiele:**
- Vorlesungen → voraussetzen (Vorgänger/Nachfolger)
- Softwareprodukt → Versionsnummer
- Polizisten → im Zweierteam patrouillieren

### 5.8 Funktionalitäten (Folien 67–76)

Funktionalität gibt an, wie viele Instanzen in einer Beziehung teilnehmen:

| Typ | Beschreibung | Beispiel |
|---|---|---|
| **1:1** | Einer Entität aus E1 entspricht höchstens eine aus E2 (und umgekehrt) | Persönliche Daten ↔ Ansprechdaten |
| **1:N** | Einer aus E1 entsprechen mehrere aus E2, aber einer aus E2 höchstens eine aus E1 | Schüler → Fahrausweise |
| **N:M** | Mehrere aus E1 entsprechen mehreren aus E2 | Studenten ↔ Vorlesungen (hören) |

**Auflösung einer M:N-Beziehung:** Wird in zwei 1:N-Beziehungen aufgebrochen durch Einführung eines neuen Entitätstyps (z. B. Hersteller ↔ Lieferant → Hersteller → Herstlr_Liefrnt ← Lieferant).

### 5.9 (min,max)-Notation (Folien 77–78)

Genauere Angabe der Kardinalitäten als Standardfunktionalitäten:
- **min = 0:** Entitäten, die an keiner Beziehung teilnehmen
- **max = *:** Beliebig viele Entitäten

**Beispiel Polyeder:**
- Polyeder (4,*) — Hülle — (1,1) Flächen
- Flächen (3,*) — Grenze — (2,2) Kanten
- Kanten (2,2) — StartEnde — (3,*) Punkte

### 5.10 Mehrstellige Beziehungen (Folien 79–80)

- **Ternäre Beziehung:** Zwischen 3 Entitätstypen
- **n-äre Beziehung:** Zwischen n Entitätstypen
- Sollten möglichst in binäre Beziehungen umgewandelt werden
- Beispiel: "prüfen" (Student, Vorlesung, Professor) → neuer Entitätstyp "Prüfungen" mit binären Beziehungen

### 5.11 Spezielle Konzepte (Folien 82–87)

#### Komposition / Schwache Entitäten (Folie 83)
Existenz eines Entitätstyps ist von der Existenz eines anderen abhängig (**has-a**).
- Beispiel: Konto existiert nur in Zusammenhang mit einer Bank

#### Generalisierung (Folien 84–86)
Abstraktion auf Ebene der Entitätstypen (**is-a**). Gemeinsame Eigenschaften werden in einen **Obertyp** ausgelagert, spezifische bleiben bei den **Untertypen**.
- Beispiel: Lebensmittel (gültig bis) und Eisenwaren (Garantiefrist) → Obertyp **Produkt** (Bezeichnung, Hersteller)

#### Aggregation (Folie 87)
Verschiedene Entitätstypen bilden in ihrer Gemeinsamkeit einen neuen Entitätstyp (**has-a**).
- Beispiel: Fahrrad besteht aus Rahmen (Rohre, Lenker) und Rad (Speiche, Felge)

---

## 6. Logischer Entwurf (Folien 88–112)

### 6.1 Definitionen (Folien 89–90)

- **Datentyp** = Werte + Operationen (z. B. integer: +, -, *, /, mod)
- **Relation** = Untermenge des kartesischen Produktes mehrerer Datentypen = **Tabelle**
- **Tupel** = Zeile (Record, Datensatz)
- **Feld** = Spalte (Attribut, Eigenschaft)
- **Schema** = Namen aller Felder + Datentypen + Länge + Reihenfolge

### 6.2 Relationale Darstellung (Folien 91–93)

**Vorteile des relationalen Modells:**
- Entitäten und Beziehungen werden gleich als Tabellen dargestellt
- Dieselben algebraischen Operationen für beide
- Mathematisch begründet durch E.F. Codd

**Notation:**
```
RelationsName = { [ Feld1:Datentyp1, Feld2:Datentyp2, ... ] }
```
Beispiel: `Auto = { [ KFZ:string, Modell:string, Gewicht:real, Baujahr:integer ] }`
Primärschlüssel wird unterstrichen.

### 6.3 Konvertierungsregeln ERM → Relational (Folie 93)

**Regeln für Entitätstypen:**
1. Neue Tabelle (Entitäts-Tabelle) bilden
2. Alle Attribute des Entitätstyps inkludieren

**Regeln für Beziehungstypen:**
1. Neue Tabelle (Beziehungs-Tabelle) bilden
2. Primärschlüssel aller verbundenen Entitätstypen inkludieren → bilden i.d.R. den PK der Beziehungstabelle
3. Attribute des Beziehungstyps inkludieren

### 6.4 Vereinfachung der Darstellungen (Folien 94–106)

#### 1:1-Beziehungen (Folien 95–97)
Zwei Optionen:
- **Option A:** Beide Entitäts-Tabellen zu einer Tabelle zusammenführen + Beziehungsattribute. Vorsicht: Datensätze können zu groß werden
- **Option B:** Beziehungs-Tabelle weglassen, PK einer Entitäts-Tabelle als FK in die andere aufnehmen

#### 1:N-Beziehungen (Folien 98–99)
- Beziehungs-Tabelle weglassen
- In die Tabelle auf der **N-Seite** den PK der Tabelle auf der **1-Seite** als **Fremdschlüssel (FK)** einfügen
- Beziehungsattribute ebenfalls in die N-Seiten-Tabelle

#### Schwache Entitäten (Folien 100–101)
- Eigene Tabelle für schwache Entität
- PK der referenzierten (starken) Entität wird **Teil des PK** der schwachen Entität (Unterschied zu normalen 1:N-Beziehungen, wo der FK nicht Teil des PK wird)

### 6.5 Beispiel: Uni-Schema als Tabellen (Folien 102–103)

| Tabelle | Felder |
|---|---|
| Professoren | PersNr, Name, Rang, Raum |
| Studenten | MatrNr, Name, Semester |
| Vorlesungen | VorlNr, Titel, SWS, gelesenVon (FK→Professoren) |
| Assistenten | PersNr, Name, Fachgebiet, Boss (FK→Professoren) |
| hören | MatrNr (FK), VorlNr (FK) |
| voraussetzen | Vorgänger (FK), Nachfolger (FK) |
| prüfen | MatrNr (FK), VorlNr (FK), PersNr (FK), Note |

### 6.6 Wichtige Bemerkung (Folien 109–111)

**Keine Felder/PK/FK willkürlich in Tabellen hinzufügen!** Nur laut Vereinfachungsregeln.

**Ausnahmen:**
- ERM-bezogene Gründe (z. B. PID, MonsterID)
- Auditing/Richtlinien (z. B. "Alle Zeilen müssen fortlaufend nummeriert werden")
- Administrative Gründe (z. B. Fusion großer Datenmengen)
- Anwendungsbezogene Gründe (z. B. OO-DB pflegen PK selbst)

**Kontroverse um künstliche IDs:**
Einige Autoren empfehlen ausdrücklich künstliche IDs, weil:
- PK soll keine semantischen Informationen enthalten
- PK darf sich nicht mit der Zeit ändern
- PK soll einfach aufgebaut sein (nicht aus mehreren Feldern)

Im Unterricht wird auf diese Meinung verzichtet (Verständnis halber), obwohl sie in der Wirtschaft sehr verbreitet ist.

---

## Zusammenfassung der Kernthemen

| Thema | Kernaussage |
|---|---|
| Datenbank vs. Dateien | DB bietet Redundanzvermeidung, Mehrbenutzerbetrieb, Zugriffskontrolle |
| Codds 12 Regeln | Definieren eine relationale DB im strengen Sinne |
| ANSI-SPARC-Modell | Drei Ebenen: extern, konzeptionell, intern → Datenunabhängigkeit |
| Anforderungsanalyse | Objekt-, Beziehungs- und Prozessbeschreibungen erstellen |
| ERM – Peter-Chen | Entitäten (Rechteck), Beziehungen (Raute), Attribute (Oval), Schlüssel (unterstrichen) |
| Funktionalitäten | 1:1, 1:N, N:M; (min,max)-Notation für genaue Kardinalitäten |
| Spezielle Konzepte | Komposition (has-a, schwache Entität), Generalisierung (is-a), Aggregation (has-a) |
| Logischer Entwurf | ERM → Tabellen; Vereinfachung bei 1:1 und 1:N durch Wegfall der Beziehungstabelle |
| Fremdschlüssel | Bei 1:N wird PK der 1-Seite als FK in die N-Seite eingefügt |