1
Übung DatenbanksystemeMapping ER/Relationales
Modell

• 13.11.2002

2
Motivation zum Mapping

• Warum machen wir Mapping ?
• gt Wir haben in ER modelliertdie meisten DB sind
  relational
• Wieso nicht gleich Relational ?
• Vereinfachung des Modellierens
• Abstraktion
• Keine zu frühe Optimierung
• gt Ähnlich UML vs. Java/C
• E/R führt leicht zu guten relationalen Modellen

3
Grundlagen zum Mapping

• Unterschiedliche Darstellung
• E/R Entitities und Beziehungen
• Relationales Modell nur Tabellen
• Faustregeln
• Entities gtTabellen
• Beziehungen gt Tabellen
• Geht aber oft auch einfacher
• Mehr Details im relationalen Modell
• Schlüssel verpflichtend
• Datentypen
• Integritätsbedingungen (nicht heute)

4
Abbildungsregeln Entitites

• Entities auf Relationen
• Entity E mit Attributen Ai aus Domänen Di (1 i
  k)? k-stellige Relation E(A1D1, ..., AkDk).
• Wir brauchen die Typen Domänen
• Wir brauchen einen oder mehrere Schlüssel
• Schwache Entitäten

• Beispiel
• Platz (Nummer integer, Klasse integer,
  Raucher bool, Fenster bool)

5
Aufgabe 1 Umsetzen des Bahnbeispiels

• 1. Schritt starke Entities umsetzen
• Station (Name string)
• Aufschlag_Rabatt (Benennung string,
  Einheitstring, Betrag integer)
• Wagen (Wagennummer integer)

6
Afg1 Schwache Entitites

• Schlüssel der Abhängigkeitspartner einbetten
• Platz (Wagennummerinteger,
  Platznummerinteger, Klasseinteger,
  Raucher boolean, Fenster boolean)
• Platz abhängig von Wagen Wagennummer einbetten,
  Schlüssel !
• Verbindung (Ankunft time, Abfahrt time, Tag
  date, faehrt_von string, faehrt_nach
  string, Zugnummer integer)
• Dreimal abhängig (Zug, 2 x Station), also auch
  mehrfach einbetten
• Ticket (Preis integer, Ticketnummer integer)
• Problemfall kein eigener Schlüssel,
  nm-Abhängigkeitengt künstlicher Schlüssel
  notwendig

7
Abbildungsregeln Relationen (1)

• Frage voraus
• Wie finden wir die beteiligten Elemente an einer
  Relation, nach dem wir sie in Tabellen gesplittet
  haben ?
• Wir machen Selektionen und Joins
• Abbildung nach Beziehungstyp
• 11-Beziehung
• Relationship R zwischen 2 Entities E und F.?
  keine Relation aus R, stattdessen Primärschlüssel
  von E in Relation in F oder umgekehrt.

8
Beispiel 11

• 1. Variante Prof bei Lehrstuhl
• Prof (Namestring, Rangstring)
• Lst (Namestring, FGebiet string, leitet
  string)
• 2. Variante Lehrstuhl bei Prof
• Lst (Namestring, FGebiet string)
• Prof (Namestring, Rangstring, leitet string)

Entitäten als Tabellen Lst (Namestring,
FGebiet string) Prof (Namestring, Rangstring)
9
Abbildungsregeln Relationen (2)

• 1n-Beziehung
• Relationship R zwischen 2 Entities E und F.?
  Keine Relation R, statt dessen Primärschlüssel
  von E in Relation F als Fremdschlüssel aufnehmen.
  Fall R eigene Attribute hat, müssen diese auch in
  F aufgenommen werden.

10
Beispiel 1n
Einbettung Fremdschlüssel Wagen (Nummer
integer) Platz (Nummer integer, Klasse
bool, Wagennummer integer)
Entitities als Tabellen Platz (Nummer integer,
Klasse bool) Wagen (Nummer integer)
11
Abbildungsregeln Relationen (2)

• 1n-Beziehung
• Relationship R zwischen 2 Entities E und F.?
  Keine Relation R, statt dessen Primärschlüssel
  von E in Relation F als Fremdschlüssel aufnehmen.
  Fall R eigene Attribute hat, müssen diese auch in
  F aufgenommen werden.
• Gibt es Ausnahmen, bei denen man doch eine
  Relation verwendet ?
• Ja, wenn die Beziehung nur sehr wenige Einträge
  hat, da wir dann sehr viele leere Einträge in F
  bekommen
• gt Optimierung, im Normalfall erst einmal
  Einbettung machen

12
Abbildungsregeln Relationen (3)

• nm-Beziehung (auch 3er, 4er, ... Beziehungen)
• Relationship R zwischen Entities E1, ..., En.?
  Relation R, deren Attribute aus den
  Primärschlüsseln von Ei (1 i k) bestehen.
• Gleiche Attributnamen durch Umbenennung eindeutig
  machen.
• Falls R eigene Attribute hat, diese hinzunehmen.

13
Beispiel nm
Separate Tabelle Berechnet (Ticketnummer
integer, Benennung string) Ursprungsrela
tionen bleiben unverändert bestehen
! Anfragen Welche Rabatte habe ich auf mein
Ticket 190091 bekommen? Welche Tickets haben
einen Twen-Ticket-Rabatt bekommen ?
Entities als Tabellen Ticket (Ticketnummer
integer) Aufschlag_Rabatt (Benennung string)
14
Afg1 Relationen (1)

• Fährt_von, Fährt_nach
• Fremdschlüsseleinbettung (Stationsname) in
  Verbindung.
• Gehört_zu
• Fremdschlüsseleinbettung (Zugnummer) in Tabelle
  Verbindung.
• Enhält
• Fremdschlüsseleinbettung (Wagennummer) in Tabelle
  Platz.
• Teil_von
• Setzt_voraus
• Aufschlag_Rabatt (Benennung string,
  Einheitstring, Betraginteger,
• setzt_voraus string)
• Wagen (Wagennummer integer,
• Zugnummer integer, Position integer)
• Attribute kann man auch einbetten

15
Afg1 Relationen (2)

• Schliesst_aus
• (Ausschliessender string,
• Ausgeschlossener string)
• Verbindungstabelle mit beiden Schlüsseln
• Gilt_fuer (Ankunft time, Abfahrt time, Tag
  date, faehrt_von string, faehrt_nach string,
  Zugnummer integer,
• Ticketnummer integer)
• Berechnet (Ticketnummer integer,
• Benennung string)

16
Afg1 Relationen(3)

• reserviert
• (Ticketnummerinteger,
• Ankunft time, Abfahrt time,Tag date,
  faehrt_von string, faehrt_nach string,
  Zugnummer integer,
• Wagennummerinteger, Platznummerinteger,
• Preis integer)
• Mehrwertigen Beziehung Fremdschlüssel aus allen
  beteiligten Entities, gt alle zusammen Schlüssel
• Attribute auch einbetten

17
Afg1 Generalisierung

• Mehr Details zu Generalisierung im Aufgabe 3
• Zug (Zugnummer integer)
• Nahverkehrszug (Zugnummer integer,
  Fahrrad_erlaubt boolean)
• Zugnummer in Zug und Nahverkehrs gleich, damit
  Zusammenbau
• Fernzug (Zugnummer integer, Speisewagen
  boolean, Name string, Benennung string)
• Benennung kommt von der Beziehung
  Bestimmt_Aufschlag
• Fertig ?

18
Generalisierung im rel. Modell

• Vom Konzept her nicht unterstützt
• flache Tabellen vs. Hierarchie
• Aber Generalisierung ist auch nur eine (1N)
  Beziehung
• 1. Variante (wie auch in Afg1)
• Separate Tabellen, Schlüsseleinbettung
• Andere Idee Spezialisierung hat alle Attribute
  der Generalisierung
• 2. Variante alle Attribute in die
  Spezialisierung drücken
• 3. Variante alles in eine Tabelle
  einsammeln(speziell für diese Übung)

19
Aufgabe 3 Generalisierung

• 1. Variante
• Fahrzeug (Rahmennr,AnzPlätze,Besitzer)
• Fahrrad (AnzGänge,
• Rahmennr)
• KFZ (Antriebsart,Leistung,
• Rahmennr)
• LKW (Zuladung,
• Rahmennr)
• gt Rahmennummer hält die Teiltabellen zusammen

20
Afg3a 2. Ansatz

• Fahrrad (AnzGänge ,
• Rahmennr, AnzPlätze,Besitzer)
• KFZ (Antriebsart, Leistung ,
• Rahmennr, AnzPlätze, Besitzer)
• LKW (Zuladung,
• Antriebsart, Leistung,
• Rahmennr, AnzPlätze, Besitzer)
• Fahrzeuge, die weder Fahrrad, KFZ noch LKW sind
• Fahrzeug (Rahmennr,AnzPlätze,Besitzer)

21
Afg3a 3. Ansatz

• Fahrzeug (Rahmennr, AnzPlätze, Besitzer,
• AnzGänge,
• Antriebsart, Leistung,
• Zuladung,
• Typ)
• gt Die Attribute der Spezialiserungen werden alle
  mitgenommen
• gt Typ notwendig zur Unterscheidung des einzelnen
  Typen

22
Afg3 Zugriff auf LKW-Daten

• 1. Variante
• Fahrzeug
• KFZ
• LKW
• 2. Variante
• LKW
• 3. Variante
• P Rahmennr, AnzPlätze, Besitzer, Antriebsart,
  Leistung, Zuladung (sTypLKW (Fahrzeug))

• Fahrzeug
• (Rahmennr, AnzPlätze,Besitzer)
• KFZ (Antriebsart,Leistung,
• Rahmennr)
• LKW (Rahmennr,Zuladung)
• LKW (Rahmennr, AnzPlätze, Besitzer, Antriebsart,
  Leistung Zuladung)
• Fahrzeug (Rahmennr, Typ, AnzPlätze, Besitzer,
  AnzGänge, Besitzer, Antriebsart, Leistung
  Zuladung)

23
Afg3 Zugriff auf alle Fahrzeuge

• 1. Tabelle pro Entity
• Fahrzeug
• 2. Pushdown
• pRahmennr,AnzPlätze,Besitzer Fahrrad ?
  pRahmennr,AnzPlätze,Besitzer KFZ ?
  pRahmennr,AnzPlätze,Besitzer LKW
• Wenn Fahrzeug ausser Fahrrad, KFZ, LKW, dann auch
  
• ? Fahrzeug
• 3. Pullup
• p Rahmennr,AnzPlätze,Besitzer (Fahrzeug)

• Fahrzeug
• (Rahmennr, AnzPlätze,Besitzer)
• Fahrrad (Rahmennr,AnzGänge)
• KFZ (Rahmennr,Antriebsart,Leistung)
• LKW (Rahmennr,Zuladung)
• Fahrzeug (Rahmennr,AnzPlätze,Besitzer)
• Fahrzeug (Rahmennr, Typ, AnzPlätze, Besitzer,
  AnzGänge, Besitzer, Antriebsart, Leistung
  Zuladung)

24
Afg3 Was ist besser ?

• Entscheidungskriterium
• Welche Anfragen sind häufiger
• a) auf Spezialisierung (LKW)
• 2. Variante besser, da nur Tabelle lesen
• 1. Variante braucht Join
• b) auf Generalisierung
• 1. Variante besser, nur eine Tabelle lesen
• 2. Variante muss alle Tabellen lesen und
  kombinieren
• 3. Variante braucht zu viel Platz und ist zu
  inflexibel

25
Aufgabe 2 Alternative Schlüssel

• Motivation Wertbasierte Schlüssel manchmal sehr
  groß, besonders zusammengesetzte Schlüssel
• Alternative Künstliche Schlüssel
• z.B. durchlaufende Nummer, UUID vergeben

26
Afg 2 Alternative Schlüsseldarstellung

• Klassisch
• Station (Name string)
• Verbindung (Ankunft time, Abfahrt time, Tag
  date, faehrt_von string, faehrt_nach
  string, Zugnummer integer)
• Ticket (Preisinteger, Ticketnummer integer)
• Gilt_fuer (Ankunft time, Abfahrt time, Tag
  date, faehrt_von string, faehrt_nach string,
  Zugnummer integer, Ticketnummer integer)
• OID
• Station (Bahnhof_ID integer, Name string)
• Verbindung (Verbindungsnummer integer, Ankunft
  time, Abfahrt time, Tag date, faehrt_von
  integer, faehrt_nach integer, Zugnummer
  integer)
• Ticket (Preisinteger, Ticketnummer integer)
• Gilt_fuer (Verbindungsnummerinteger,
  Ticketnummer integer)

27
Afg2 Abschätzung für Einzeltupel (1)

• Platzbedarf klassisch
• Station (Name string)
• gt 15 Byte
• Verbindung (Ankunft time, Abfahrt time, Tag
  date, faehrt_von string, faehrt_nach
  string, Zugnummer integer)
• gt 22215154 Byte
• Ticket (Preisinteger, Ticketnummer integer)
• gt 24 Byte
• Gilt_fuer (Ankunft time, Abfahrt time, Tag
  date, faehrt_von string, faehrt_nach string,
  Zugnummer integer, Ticketnummer integer
• gt (22215154)4

28
Afg2 Abschätzung für Einzeltupel (2)

• Platzbedarf OID-Ansatz
• Station (Bahnhof_ID integer, Name string)
• gt 215 Byte 17 Byte
• Verbindung (Verbindungsnummer integer, Ankunft
  time, Abfahrt time, Tag date, faehrt_von
  integer, faehrt_nach integer, Zugnummer
  integer)
• gt 4222224 18 Byte
• Ticket (Preisinteger, Ticketnummer integer)
• gt 24 Byte 6 Byte
• Gilt_fuer (Verbindungsnummerinteger,
  Ticketnummer integer)
• gt44 8 Byte

29
Gesamtdatenmenge

• Durch die richtige Schlüsselwahl Ersparnis
  um mehr als Faktor 4 !
• Extrembeispiel, aber Anwendung im Data
  Warehousing
• Gibt es auch Nachteile dieser Methode ???