docs: add obsidian hwr docs

Datenbanken/Zusammenfassungen/b_ModellierungFB - zusammenfassung.md

@@ -0,0 +1,157 @@
+# 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) |