hwr-notes/Datenbanken/Zusammenfassungen/b_ModellierungFB - zusammenfassung.md

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

---

## 1. Überblick (Folie 1)

Das Fallbeispiel behandelt die **Modellierung einer Rechnung** und folgt dem Schema:
1. Beispiel-Rechnungen betrachten
2. Mini-Welten beschreiben
3. Konzeptuellen Entwurf für jede Mini-Welt erstellen
4. Logischen Entwurf für jede Mini-Welt erstellen
5. Fazit

---

## 2. Beispiel-Rechnungen (Folien 2–5)

Es werden verschiedene reale Rechnungen als Ausgangspunkt gezeigt, aus denen die relevanten Entitätstypen und Beziehungen abgeleitet werden.

---

## 3. Mini-Welten – Entitätstypen (Folien 6–8)

Aus den Rechnungen werden **mindestens 3 Entitätstypen** identifiziert:

### Artikel
- Artikelnummer (kann fehlen)
- Beschreibung (immer vorhanden)
- Einzelpreis (Netto)
- MwSt-Satz und MwSt-Betrag

### Rechnungsposition
- Reihenfolgenummer (kann fehlen, aber wichtig)
- Menge / Anzahl der Artikel

### Rechnung (übergeordnet)
- Rechnungsnummer
- Datum
- Gesamtsumme (abgeleitetes Attribut)
- MwSt-Betrag der ganzen Rechnung (abgeleitetes Attribut)

**Hinweis:** Kundeninformation wird bewusst vernachlässigt. Es gibt viele abgeleitete Attribute.

### Formale Notation

Entitätstypen als Mengen:
```
E = { e } = { [ Attr1, Attr2, ..., AttrN ] }
```

**Feste Entitätstypen (in beiden Mini-Welten gleich):**
```
Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
Artikel = { [ ArtNr, ArtBezeichnung, EP, MwStSatz ] }
```

**Beziehungen:**
- Rechnung **besteht aus** Rechnungspositionen
- Rechnungsposition **beinhaltet** Artikel

---

## 4. Mini-Welt 1 (Folien 9–11)

### Ansatz
Alle Rechnungen werden **durchgehend** betrachtet. Gleiche Kombinationen [RechnPosNr, Menge] werden **zusammengefasst** (laut Mengenlehre nach G. Cantor: keine doppelten Elemente).

**Beispiel:** Wenn in Rechnung A die erste Zeile 2 Tastaturen enthält und in Rechnung B die erste Zeile 2 Drucker, ist für beide nur ein Element [1, 2] zuständig.

```
Rechnungsposition = { [ RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
```

### Konzeptueller Entwurf (Folie 10)

| Beziehung | Funktionalität |
|---|---|
| Rechnung — besteht aus — Rechnungsposition | **M : N** |
| Rechnungsposition — beinhaltet — Artikel | **N : 1** |

### Logischer Entwurf (Folie 11)

```
Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
Artikel = { [ ArtNr, EP, MwStSatz, ArtBezeichnung ] }
Rechnungsposition = { [ RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
besteht_aus = { [ RgNr, RechnPosNr, Menge ] }
beinhaltet = { [ ArtNr, RechnPosNr, Menge ] }
```

**Vereinfachung** (1:N-Beziehung "beinhaltet" auflösen):
```
Rechnungsposition = { [ ArtNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
```
Dabei wird ArtNr als Fremdschlüssel eingefügt.

---

## 5. Mini-Welt 2 (Folien 12–14)

### Ansatz
**Alle** Rechnungspositionen aus allen Rechnungen werden individuell erfasst, auch wenn [RechnPosNr, Menge] gleich sind. Da Duplikate nach Cantor nicht zulässig sind, wird ein neues Attribut **LaufendeNummer (LfndNr)** eingeführt.

**Konsequenz:** Mehr Entitäten im Entitätstyp, mehr Redundanz, aber die **Zuordnung jeder Position zu einer Rechnung bleibt erhalten** (anders als in Mini-Welt 1, wo sie verloren geht).

```
Rechnungsposition = { [ LfndNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
```

### Konzeptueller Entwurf (Folie 13)

| Beziehung | Funktionalität |
|---|---|
| Rechnung — besteht aus — Rechnungsposition | **1 : N** |
| Rechnungsposition — beinhaltet — Artikel | **N : 1** |

### Logischer Entwurf (Folie 14)

```
Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
Artikel = { [ ArtNr, EP, MwStSatz, ArtBezeichnung ] }
Rechnungsposition = { [ LfndNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
besteht_aus = { [ RgNr, LfndNr ] }
beinhaltet = { [ ArtNr, LfndNr ] }
```

**Vereinfachung** (beide 1:N-Beziehungen auflösen):
```
Rechnungsposition = { [ ArtNr, RgNr, LfndNr, RechnPosNr, Menge,
                        Zwischensumme, ZwischenMwSt ] }
```

**Hinweis:** LfndNr wird nicht für Verknüpfungen (Join-Prädikat) verwendet, hat wenig Semantik, muss aber gepflegt werden.

---

## 6. Fazit (Folie 15)

Beide Mini-Welten bilden den Sachverhalt ab. Welches Modell besser ist, hängt von den zuvor angeforderten Kriterien ab (z. B. Leistung/Geschwindigkeit).

**Empfehlung:**
- Beide Modelle implementieren
- Antwortzeiten bei größerem Datenumfang vergleichen
- Häufigste Abfragen vergleichen, seltene ebenfalls

---

## Vergleich der Mini-Welten

| Aspekt | Mini-Welt 1 | Mini-Welt 2 |
|---|---|---|
| Beziehung Rechnung↔Position | M:N | 1:N |
| Duplikate | Keine (zusammengefasst) | Individuell (via LfndNr) |
| Zuordnung Position→Rechnung | Geht verloren | Bleibt erhalten |
| Redundanz | Weniger | Mehr |
| Tabellen nach Vereinfachung | 3 + besteht_aus | 3 (alles in einer) |