hwr-notes/Datenbanken/Zusammenfassungen/b_ModellierungFB - zusammenfassung.md
2026-04-09 11:24:56 +02:00

4.8 KiB
Raw Blame History

Modellierung Fallbeispiel Zusammenfassung

Dozent: A. Zimmermann | HWR Berlin | 2026 | Folien 116


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 25)

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


3. Mini-Welten Entitätstypen (Folien 68)

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 911)

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 1214)

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)