Datenbankmanagementsysteme

(DBMS)

Vorlesung 03
Sommersemester 2020
Dr. Stefan Hanenberg
Universität Duisburg-Essen

basierend auf dem Skript von Prof. Dr. Rainer Unland

 Eine kurze Wiederholung….
Wiederholung
 Von der Realwelt zum Datenbankmodell
Realwelt
wird überführt
Wiederholung

Semantisches Datenmodell
(auch konzeptuelles Datenmodell)

wird überführt

Relationales Datenmodell
(auch logisches Datenmodell)

DBMS – SoSe 2020 –Stefan Hanenberg Wiederholung Kapitel 2 3

 Von der Realwelt zum Datenbankmodell
Realwelt
wird überführt
1.Grundsätze
Wiederholung

Semantisches Datenmodell
2.Techniken
(auch konzeptuelles Datenmodell)
3.Notationen

DBMS – SoSe 2020 –Stefan Hanenberg Wiederholung Kapitel 2 4

 Von der Realwelt zum Datenbankmodell
Grundsätze
Realwelt 1. Grundsatz Richtigkeit
2. Grundsatz Relevanz
wird überführt 3. Grundsatz Wirtschaftlichkeit
Wiederholung

4. Grundsatz Klarheit
Semantisches Datenmodell
(auch konzeptuelles Datenmodell) Techniken
1. Reduktion
2. Dekomposition, Komposition
3. Abstraktion
4. Assoziation
5. Generalisierung
DBMS – SoSe 2020 –Stefan Hanenberg Wiederholung Kapitel 2 5
 Von der Realwelt zum Datenbankmodell
Notation
Realwelt 1. ER-Modellierung
2. UML-Klassendiagramm
wird überführt • Klasse = Entitätstyp
Wiederholung

• Beziehungen
Semantisches Datenmodell • Assoziationen
(auch konzeptuelles Datenmodell)

DBMS – SoSe 2020 –Stefan Hanenberg Wiederholung Kapitel 2 6

 Was fehlt?
Realwelt
wird überführt
Wiederholung

Semantisches Datenmodell
(auch konzeptuelles Datenmodell)

wird überführt

Relationales Datenmodell
(auch logisches Datenmodell)

DBMS – SoSe 2020 –Stefan Hanenberg Wiederholung Kapitel 2 7

 Ende der Wiederholung.
Wiederholung

Kapitel 1 – Einführung und Übersicht

Kapitel 3: Transformation von Modellen in
Datenbankschemata
Kapitel 3.1 – Transformation in abstrakte Schemata
Transformation von Modellen in Schemata
• Ziele
• Präsentation des abstrakten Datenmodells in eine Form, die sehr nah dran ist
an dem Modell, was von Datenbankmanagementsystem verwaltet werden
kann
• Überführung von semantischem Datenmodell in abstraktes Datenmodell
sollte „möglichst schematisch“ (d.h. mit feststehenden Regeln) erfolgen, um
Nachvollziehbarkeit zu erhöhen

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 10
10
Relationales Datenbankschema
• Datenbankschema
• einer Menge von Tabellen (Relation)
• Jede Tabelle hat
• einen Namen, der die Tabelle identifiziert
• Eine Menge von Attributen (Spalten) mit atomaren (!) Datentypen
• Attributnamen sind in Relation eindeutig
• Eine (nicht leere) Menge von Attributen, die eine Zeile eindeutig identifizieren
(diese Menge wird Primärschlüssel genannt)
• Möglicherweise eine Menge von Mengen von Attributen, die Zeilen (!)
anderer Tabellen identifizieren (jede dieser Attributmengen wird
Fremdschlüssel genannt)
• Die Zeilen einer Relation (konkrete Daten) werden Tupel genannt
DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 11
11
Typen in Relationalen Datenbanksystemen
• atomare Datentypen:
INTEGER REAL
CHAR [Zahl] BOOLEAN (meist nicht)
DATE, TEXT
Bytestring beliebiger Länge

• Operationen auf atomaren Datentypen:

• +, -, /, *, mod, =, ...

• Tabellen repräsentieren zusammengesetzte Typen

• Operationen auf Tabellen:

• Erzeugen, Löschen, Ändern (Tupel oder Menge von Tupeln)

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 12
12
 Beispielrelation: Mitarbeiter Attribut (Name
und Datentyp)

Tabellenname Attributemenge

Primärschlüssel
Tupel (Zeile der Relation, d.h. (keine 2 Zeilen mit gleichem
Attribute mit Werten) Wert in diesem Attribut
DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 13
Beispielrelation: Abteilung + Mitarbeiter
Fremdschlüssel
auf Relation
Mitarbeiter
(dort Primärschlüssel)

Referenz auf Tupel

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 14
Primärschlüssel können mehr als ein Attribut umfassen

• Abbildung von Mitarbeitern, die in einem Projekt arbeiten

• Sowohl ProjektNr als auch MitarbeiterNr können einzeln mehrfach
vorkommen (z.B. ProjektNr 123456 oder MitarbeiterNr 4711), aber
Tupel ProjektNr und MitarbeiterNr sind eindeutig

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 15
Häufig verwendete (vereinfachte)
Relationenschreibweise
• Relation(Attribut1, Attribut 2, …)
• Datentypen werden weggelassen
• Primärschlüssel werden einfach unterstrichen
• Fremdschlüssel werden gestrichelt unterstrichen

Mitarbeiter(mitarbeiterNr, vorname, nachname, gehalt)

Abteilung(abtID, bezeichnung, leiter)
ArbeitetInProjekt(projektNr, mitarbeiterNr)

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 16
Transformation Entitätstypen und
Beziehungstypen
• Transformation von Entitytypen
• Jeder Entitytyp wird in eine Relation übersetzt.
• Der Name bleibt unverändert.
• Alle Attribute werden übernommen.
• Primärschlüssel werden durch Unterstreichung kenntlich gemacht.
• Fremdschlüssel können durch gestrichelte Unterstreichungen
kenntlich gemacht werden.
• Transformation von Beziehungstypen
• Sie werden als eigene Relation oder als Attribut in das logische
Datenmodell aufgenommen.

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 17
Transformation binärer 1:1-Beziehungstypen
• Nehmen beide Entitytypen optional am Beziehungstypen teil, so bedeutet
dies, dass Abteilungen von einem Mitarbeiter geleitet werden können, aber
durchaus auch Abteilungen existieren können, die keinen Leiter besitzen.
Ebenso können Mitarbeiter existieren, die keiner Abteilung zugeordnet
sind.

Mitarbeiter Mitarbeiter(MitarbeiterNr, Name, ..., AbtNr)

1 Abteilung(AbtNr, AbtName, ....)
leitet
Alternativ:
1

Abteilung Mitarbeiter(MitarbeiterNr, Name, ...)

Abteilung(AbtNr, AbtName, ..., MitarbeiterNr)

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 18
Transformation binärer 1:1-Beziehungstypen
• In dieser Variante ist die Teilnahme aller Abteilungen am Beziehungstyp
bindend. Jede Abteilung muss von einem Mitarbeiter geleitet werden, aber
nicht jeder Mitarbeiter muss auch Abteilungsleiter sein. In diesem Fall muss
die MitarbeiterNr als Fremdschlüssel in die Relation Abteilung aufgenommen
werden und darf nicht die Nullmarke annehmen.
Mitarbeiter Mitarbeiter(MitarbeiterNr, Name: varChar, ...)
(0,1) Abteilung(AbtNr, AbtName, ..., MitarbeiterNr)
leitet
(1,1)

Abteilung

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 19
Transformation binärer 1:n-Beziehungstypen
• Auch bei diesem Beispiel soll der Unterschied in der Transformation
optionaler und totaler Teilnahmen an einem Beziehungstypen verdeutlicht
werden. In der ersten Ausprägung des Beispiels kann jeder Kunde mehrere
Rechnungen erhalten. Rechnungen sind dabei einem oder keinem Kunden
zugeordnet.
Kunde Kunde(KundenNr, Name, Vorname, ...)
1 Rechnung(RechNr, Datum, ..., KundenNr)
erhält
N

Rechnung

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 20
Transformation binärer n:m-Beziehungstypen
• <N:M>-Beziehungstypen werden grundsätzlich in eine eigene Relation
transformiert. In diesem Beispiel kann ein Kunde verschiedene Artikel
bestellen und jeder Artikel kann von beliebig vielen Kunden bestellt werden.

Kunde Kunde(KundenNr, Name, Vorname, ...)

N Artikel(ArtikelNr, Bezeichnung, ...)
bestellt
bestellt bestellt(KundenNr, ArtikelNr, Bestellmenge, ...)
Bestelltmenge
M

Artikel

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 21
Transformation rekursiver Beziehungstypen
• Transformation rekursiver Beziehungstypen
• Für <1:1> und <1:N> Beziehungstypen wird der umbenannte Primärschlüssel
in die bereits bestehende Relation eingefügt (bei 1:1 kann beidseitig oder
wahlweise eingefügt werden, bei 1:N nur auf der N-Seite).
• Bei einer Kardinalität <N:M> muss eine zusätzliche Relation erstellt werden.

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 22
Transformation unärer 1:1-Beziehungstypen
• Ein Mitarbeiter kann mit einem anderen Mitarbeiter verheiratet sein.

Mitarbeiter Mitarbeiter (MitarbeiterNr, Name, ..., PartnerNr, Datum)

1 1
istVerheiratetMit

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 23
Transformation unärer 1:n-Beziehungstypen
• Ein Mitarbeiter kann Vorgesetzter mehrerer Mitarbeiter sein. Jeder
Mitarbeiter hat ausschließlich einen Vorgesetzten.

Mitarbeiter Mitarbeiter (MitarbeiterNr, Name,..., VorgesetzterNr)

N 1
istVorgesetzter

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 24
Transformation unärer n:m-Beziehungstypen
• Jeder Artikel kann verschiedene Bauteile besitzen. Ein Bauteil kann
Bestandteil in mehreren Artikel sein.

Artikel Artikel(ArtikelNr, Bezeichnung, ...)

istBauteilVon(ArtikelNrOberteil, ArtikelNrBauteil)
M M
istBauteilVon

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 25
Transformation von
Generalisierungshierarchien
• Im Falle einer Generalisierung kann der Diskriminator explizit modelliert
werden und ist Bestandteil des generischen Entitytypen. In diesem Beispiel
entscheiden seine Werte über die Zugehörigkeit eines Entities vom Typ
Person zu den disjunkten Klassen Geschäftspartner und Mitarbeiter.

Person(PersonNr, Name, Vorname, ..., Status)

Geschäftspartner(PersonNr, Land, MwSt, ...)
Mitarbeiter(PersonNr, Einstellungsdatum, Gehalt, ...)

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 26
Transformation von
Generalisierungshierarchien
• Bei Subtypenhierarchien ist der Diskriminator lediglich implizit im Modell
vorhanden, d.h. in dem Beispiel existieren zwar ein oder mehrere Attribute im
Entitytyp Geschäftspartner, die entscheiden, ob ein Entity zum Entitytyp
Kunde, Lieferant oder gar zu beiden gehört, aber diese werden nicht im ER-
Diagramm dargestellt.

Geschäftspartner(PersonNr, Rabatt, MwSt, ...)

Kunde(PersonNr, Bonität, ...)
Lieferant(PersonNr, Skonto, ...)

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 27
Allgemein zu Übersetzung in DB-Schema
• Wichtig
• Die hier vorgestellten Übersetzungen von ER-Diagram in Datenbankschema sind nur
Leitfäden

• Mögliche Abweichungen
• 1:1-Beziehungen in eine Tabelle darstellen
• 1:n-Beziehungen in einer Tabelle darstellen
• ….

DBMS – SoSe 2020 –Stefan Hanenberg Kapitel 3.1 – Transformation in abstraktes Schema 28