Grundlagen der Datenbankensysteme

Prof. Dr. Ziawasch Abedjan Seite 1

Der Relationale Entwurf

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 2

 Überblick
1. Das Relationale Modell
2. Von ER-Diagrammen zu Relationenschemata
3. Konvertierung von Spezialisierung

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 3

Die Relation in der Mathematik

■ Eine Relation R ist eine Menge von n-Tupeln.

■ Dinge, die in der Relation R zueinander stehen, bilden ein n-Tupel, das Element von R ist.
■ Teilmenge des Kartesischen Produkts
□ R Í A1 ×… × An
□ A1 ×… × An := {(a1,…, an) | a1ÎA1Ù … Ùan ÎAn}

■ Für Datenbanken:
□ Mengen A1,…, An sind Domänen (Wertebereiche)
– Z.B.: Integer, String, String, Boolean, usw.
– Entspricht Spalten einer Tabelle
□ Tupel (a1,…, an) sind die Datenwerte
– Z.B. (4, Abedjan, Berlin, m)
– Entspricht Zeilen einer Tabelle

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 4

Die Relation

■ Konzeptuell ist eine Datenbank eine Menge von Tabellen.

□ Relation zwischen Werten der Attributdomänen
□ Tabellen = Relationen Titel Jahr Länge Typ
Basic Instinct 1992 127 Farbe
Total Recall 1990 113 Farbe
Dead Man 1995 121 s/w

■ Die Relation ist das einzige Konstrukt des relationalen Modells

□ Sehr einfach
□ Einfach in einer DB abzubilden (zwei-dimensional)
□ Relationen können nicht nur Entities sondern auch Relationships darstellen.
□ Entspricht oft unserer Vorstellung der Daten
□ Ist das abstrakte Modell hinter SQL

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 5

Elemente des Relationalen Modells

§ Datenbankschema
§ Besteht aus einem oder mehreren Relationenschemata.
§ Relationenschema
§ Name der Relations sowie Liste der Attribute mit Domäne
§ Weitere Einträge in der Tabelle: Die „Relation“
§ Besteht aus keinem oder mehr Tupeln.
§ Eine Zeile der Tabelle: Tupel
§ Die Tupel bilden eine Menge (nicht eine Liste).
§ Eine Spaltenüberschrift: Attribut
§ Attribute bilden eine Menge (nicht eine Liste).
§ Ein Eintrag: Attributwert
§ Atomar
§ Stammt aus einer elementaren Domäne (Integer, String, …)

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 6

Elemente einer Relation

Relationenname Primärschlüssel
Fremdschlüssel
Attribute

R A1 … An S B1 … Bn Relationenschema

… …

… Relation …
Tupel
… …

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 7

Formal

■ Domänen D1, …, Dn
■ Relation R Í D1 x … x Dn

■ Beispiel
□ Relationenschema: Film(Titel, Jahr, Länge, Typ)
□ Domänen: String, Integer, Integer, String
□ Tupel: (Star Wars, 1977, 124, farbig)

http://www.stainlesssteeldroppings.com
Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 8
Edgar F. Codd
§ http://en.wikipedia.org/wiki/Edgar_F._Codd
§ Promotion an der University of Michigan Ann Arbor
§ Entwicklung des Relationalen Modells bei IBM (Almaden)
§ „A Relational Model of Data for Large Shared Data Banks" (1970)
§ Artikelserie
§ Literaturhinweis:
§ The Database Relational Model: A Retrospective Review and Analysis:
§ A Historical Account and Assessment of E. F. Codd's Contribution to
the Field of Database Technology
§ Chris J. Date
§ ISBN: 0-201-61294-1 (9.99 EUR)

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 9

Beiträge von Codd (nach C.J.Date)

■ Transformation des Datenmanagement zu einer Wissenschaft

□ Entsprechende Klarheit und Strenge
■ Nicht nur das relationale Modell, sondern überhaupt das Konzept eines Datenmodells
□ Unterscheidung zwischen Modell und Implementierung
■ Relationale Algebra und relationales Kalkül
■ Informell: Anfragesprache Alpha
□ Angelehnt: SEQUEL von Chamberlin und Boyce
□ Vorgänger von SQL
■ Funktionale Abhängigkeiten
■ Normalformen
□ Erste bis dritte Normalform

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 10

Ziawasch Abedjan | Grundlagen
der Datenbanksysteme

Seite 11
Ziawasch Abedjan | Grundlagen
der Datenbanksysteme

Seite 12
Ziawasch Abedjan | Grundlagen
der Datenbanksysteme

Seite 13
Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 14
 Überblick
1. Das Relationale Modell
2. Von ER-Diagrammen zu Relationenschemata
3. Konvertierung von Spezialisierung

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 15

Logischer Entwurf
■ Sprachmittel: Datenmodell des ausgewählten DBMS Anforderungsanalyse
□ z.B. DB2, Oracle, … => relationales Modell
□ Tamino => XML Konzeptioneller
Entwurf
■ Vorgehensweise
□ (Automatische) Transformation des konzeptionellen Schemas
Verteilungsentwurf
– z.B. ER in relationales Modell
□ Verbesserung des relationalen Schemas anhand von Gütekriterien
– Normalisierung, Redundanzvermeidung, … Logischer Entwurf

■ Ergebnis: logisches Schema, z.B. Sammlung von Relationenschemata

Datendefinition

Physischer Entwurf

Implementierung
und Wartung

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 16

Ziele der Abbildung ER ® relationales Modell

■ Darstellung aller Informationen des ER-Diagramms

■ Exaktheit
□ Das Datenbankschema kann genauso viele Instanzen wie das ER-Diagramm darstellen.
□ Das Datenbankschema kann nicht mehr Instanzen als das ER-Diagramm darstellen.
– Integritätsbedingungen müssen weiterhin gelten

■ Erhaltung und Einhaltung der Informationskapazität!

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 17

 Kapazitätserhöhende Abbildung
SName VName

Studios leitet Vorsitzende

Relationenschema: R = {SName, VName}

Schlüsselmenge: { {SName} } Schlüsselmenge: { {SName}, {VName} }

SName VName SName VName SName VName

Fox Iger Fox Murdoch Fox Murdoch Ziawasch Abedjan | Grundlagen
der Datenbanksysteme
Disney Iger Disney Iger Disney Iger

kapazitätserhöhend kapazitätserhaltend

Seite 18
 Kapazitätsvermindernde Abbildung
Name Titel

Schauspieler*in spielt_in Film

Relationenschema: R = {Name, Titel}

Schlüsselmenge: { {Name} } Schlüsselmenge: { {Name, Titel} }

Name Titel Name Titel Name Titel
Sharon Basic Sharon Basic Sharon Basic
Stone Instinct Stone Instinct Stone Instinct
Ziawasch Abedjan | Grundlagen
Michael Basic Michael Basic Sharon Total der Datenbanksysteme

Douglas Instinct Douglas Instinct Stone Recall

Michael Basic
kapazitäts-
kapazitätsvermindernd Douglas Instinct
erhaltend
Seite 19
Grundalgorithmus

1. Wandle jeden Entitytypen in eine Relation mit den gleichen Attributen um.
2. Wandle jeden Relationshiptypen in eine Relation um mit:
□ Zugehörige Attribute des Relationshiptypen
□ Schlüsselattribute der beteiligten Entitytypen
3. Verfeinere den Entwurf
1. Zusammenlegung von Relationen
2. Normalisierung

■ Ausnahmen
□ Schwache Entitytypen
□ IST Relationships

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 20

Entitytyp ® Relation
■ Name des Entitytyps ® Name der Relation
■ Attribute des Entitytyps ® Attribute der Relation
■ Diese Relation bildet in keiner Weise Relationships ab.
Name
Titel Jahr spielt_in Schauspieler*in
Adresse
Film
Name
besitzt Studio
Länge Typ
Adresse

■ Film(Titel, Jahr, Länge, Typ)

■ Schauspieler(Name, Adresse)
■ Studio(Name, Adresse)

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 21

Relationshiptyp ® Relation

■ Attribute
□ Attribute des Relationshiptyps selbst
□ Für jeden beteiligten Entitytypen: Füge deren Schlüsselattribut(e) als Attribute hinzu

■ Doppelte Attributnamen
□ Umbenennungen sind nötig!

■ Falls ein Entitytyp in mehreren Rollen beteiligt ist

□ Entsprechend oft die Schlüsselattribute übernehmen
□ Geeignete Umbenennungen sind dann sogar nötig

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 22

Relationshiptyp ® Relation

spielt_in Name
Titel Jahr Schauspieler*in
Adresse
Film Rolle
Name
Studio
Länge Typ besitzt
Adresse

■ spielt_in(Titel, Jahr, SchauspielerInName,

SchauspielerInAdresse, Rolle)
■ besitzt(Titel, Jahr, StudioName)

■ Umbenennungen hier nur zur Klarheit

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 23

Relationshiptyp ® Relation

■ ist_unter_Vertrag(Titel, Jahr, SchauspielerName,

SchauspielerAdresse, StudioName)
Titel Jahr
Name
ist_unter_Vertrag Schauspieler*in
Film
Adresse
Name
Länge Typ Studio
Adresse
■ ist_unter_Vertrag(Titel, Jahr, SchauspielerName,
SchauspielerAdresse, Stammstudio,
ProduzierendesStudio, Gehalt)

Titel Jahr Gehalt

Name
ist_unter_Vertrag Schauspieler*in
Film
Adresse
Stammstudio Produzierendes Name
Studio
Länge Typ
Studio Adresse
Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 24
Zusammenlegen von Relationen

■ Man kann folgende Relationen kombinieren:

□ Die Relation für einen Entitytypen E
□ mit der Relation eines 1:n Relationshiptypen R, falls E auf den n-Seite liegt.
■ Neue Relation enthält also
□ Alle Attribute von E
□ Alle Attribute von R
– inkl. Schlüssel des anderen Entitytypen

Film besitzt Studio

Titel Jahr Name

Typ
Adresse
Länge

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 25

Zusammenlegen von Relationen
1:n-Relationships
Film besitzt Studio

Titel Jahr Länge Typ Name Adresse

Film besitzt Studio
Titel Jahr Länge Typ Titel Jahr studioName Name Adresse
Basic Instinct 1992 127 Farbe Basic Instinct 1992 Fox Fox Hollywood
Total Recall 1990 113 Farbe Total Recall 1990 Disney Disney Hollywood
Dead Man 1995 121 s/w Dead Man 1995 Paramount Paramount Los Angeles

Film Ziawasch Abedjan | Grundlagen

der Datenbanksysteme
Titel Jahr Länge Typ studioName
Basic Instinct 1992 127 Farbe Fox
Total Recall 1990 113 Farbe Disney
Dead Man 1995 121 s/w Paramount
Seite 26
Zusammenlegen von Relationen
1:1-Relationships
SName VName

Studios leitet Vorsitzende

Studios leitet Vorsitzende

SName SName VName VName
Fox Fox Murdock Murdock
Disney Disney Iger Iger

þ þ
Studios Vorsitzende Studios Vorsitzende Ziawasch Abedjan | Grundlagen
der Datenbanksysteme
SName VName VName SName SName VName
Fox Murdock Murdock Fox Fox Murdock
Disney Iger Iger Disney Disney Iger
Seite 27
Zusammenlegen von Relationen
n:m-Relationships -> Falsch
Film spielt_in Schauspieler*in Name

Adresse
Titel Jahr Länge Typ spielt_in
Film Titel Jahr Name
Titel Jahr Länge Typ Total Recall 1990 Sharon Stone
Basic Instinct 1992 127 Farbe Basic Instinct 1992 Sharon Stone
Total Recall 1990 113 Farbe Total Recall 1990 Arnold
Dead Man 1995 121 s/w Dead Man 1995 Johnny Depp

Film
Titel Jahr Länge Typ Name
Ziawasch Abedjan | Grundlagen
der Datenbanksysteme
Total Recall 1990 113 Farbe Sharon Stone
Basic Instinct 1992 127 Farbe Sharon Stone
Total Recall 1990 113 Farbe Arnold
ý
Dead Man 1995 121 s/w Johnny Depp
Seite 28
Schwache Entitytypen

■ Drei Besonderheiten
□ Die Relation eines schwachen Entitytypen S muss nicht nur die eigenen Attribute, sondern auch die
Schlüsselattribute aller Entitytypen, die über unterstützende Relationshiptypen erreicht werden, enthalten.
□ Alle Relationen für Relationshiptypen, die S in Beziehung mit anderen Entitytypen setzen, müssen ebenfalls alle
diese Attribute enthalten.
□ Ein unterstützender Relationshiptyp muss hingegen gar nicht durch eine Relation abgebildet werden.
– Begründung wie eben: 1:n

Datum

Kamera
nutzt

Nummer Name Adresse

Crew arbeitet_für Studio

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 29

Schwache Entitytypen

Nummer Name Adresse

Crews arbeitet_für Studios

■ Studios(Name, Adresse)
■ Crews(Nummer, Name)
■ arbeitet_für(Nummer, Name1, Name2)

sind gleich

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 30

Schema-Teilmengen

■ Beispiel
□ Personen(Name, SSN)
□ Steuerzahler*in(Name, SSN, Betrag)
■ Schema von Personen ist Teilmenge des Schemas von Steuerzahler.
■ Aber: Instanzen können sich unterscheiden
□ Steuerzahler*in Í Personen (jeder Steuerzahler ist eine Person)

■ Beispiel
□ Schauspieler*in(Name, Adresse)
□ Studios(Name, Adresse)
■ Schemata sind sogar identisch, aber Instanzen grundverschieden.
■ D.h.: Gleiche oder überlappende Schemas können/sollen nicht immer zusammengelegt werden.

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 31

Schwache Entitytypen
Name Titel Typ
Schauspieler*in Film
Adresse Jahr Länge

Schauspieler*in_von Film_von

Vertrag
Gehalt
Studio_von
Name

Adresse Studio
■ Studio(Name, Adresse)
■ Schauspieler*in(Name, Adresse)
■ Film(Titel, Jahr, Typ, Länge)
■ Vertrag(Schauspieler*inName, StudioName, Titel, Jahr, Gehalt)

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 32

Schwache Entitytypen
Titel Jahr Gehalt
Name Adresse

Film ist_unter_Vertrag Schauspieler*in

Name
Länge Typ Studio
Adresse

■ Studio(Name, Adresse)
■ Schauspieler*in(Name, Adresse)
■ Film(Titel, Jahr, Typ, Länge)
■ ist_unter_Vertrag(Schauspieler*inName, StudioName, Titel, Jahr, Gehalt)

■ Was fällt auf?

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 33

 Überblick
1. Das Relationale Modell
2. Von ER-Diagrammen zu Relationenschemata
3. Konvertierung von Spezialisierung

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 34

Wdh. Spezialisierung
■ Annahmen
□ Es gibt ein Wurzel-Entitytyp der IST-Hierarchie.
Länge Titel Jahr Typ
□ Der Wurzel-Entitytyp hat einen Schlüssel, der alle
Entitys der gesamten Hierarchie identifiziert.
□ Ein Entity kann aus mehreren Komponenten der
Hierarchie bestehen. Film

IST IST

Zeichentrickfilm Krimi

zu Schauspielern Stimmen Waffen

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 35

Drei Strategien

■ Im ER-Stil
□ Für jeden Entitytypen E der Hierarchie erzeuge eine Relation mit den Schlüsselattributen des Wurzel-
Entitytypen und den Attributen von E.

■ Objekt-orientierter Stil
□ Ein Entity gehört zu genau einer Klasse.
□ Für jeden möglichen Teilbaum der Hierarchie, der auch die Wurzel enthält, erzeuge eine Relation mit allen
Attributen der beteiligten Entitytypen.

■ Null-Werte Stil
□ Erzeuge eine einzige Relation für die gesamte Hierarchie. Ein Entity wird durch ein Tupel repräsentiert mit Null-
Werten für Attribute, die der Entity nicht besitzt.

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 36

ER-Stil
■ Film(Titel, Jahr, Länge,Typ)
■ Krimi(Titel, Jahr, Waffen) Länge Titel Jahr Typ
■ Zeichentrickfilm(Titel, Jahr)

■ Anmerkungen Film
□ Die IST-Relationship selbst erhält keine Relation.
□ Geerbte Schlüsselattribute werden für weitere Beziehungen
benötigt. IST IST
□ Es gibt vier verschiedene Filmsorten.
□ Jeder Film hat ein Tupel in der Relation Filme.
□ Ein konkreter Film (z.B. Roger Rabbit) kann Tupel in allen Zeichentrickfilm Krimi
drei Relationen haben.
Waffen
Stimmen

Ziawasch Abedjan | Grundlagen der Datenbanksysteme

zu Schauspielern Seite 37
ER-Stil – Feinheiten
■ Film(Titel, Jahr, Länge,Typ)
■ Krimi(Titel, Jahr, Waffen) Länge Titel Jahr Typ
■ Zeichentrickfilm(Titel, Jahr)
■ Stimmen(Titel, Jahr, Name)
■ Schema von Zeichentrickfilm ist Teilmenge des Schemas von Film
Stimmen.
□ Kann man es weglassen?
□ Nein: Stumme Zeichentrickfilme! IST IST

Zeichentrickfilm Krimi

Waffen
Stimmen

Ziawasch Abedjan | Grundlagen der Datenbanksysteme

zu Schauspieler*in Seite 38
Objekt-orientierter Stil
■ Erzeuge Relation für jeden Teilbaum.
Länge Titel Jahr Typ
■ Diese Relation repräsentiert die Entities, die genau diese
Komponenten der Hierarchie besitzen.
□ Objekte gehören zu genau einer Klasse.
Film
■ Vier Teilbäume
□ Nur Filme
□ Filme und Zeichentrickfilme
IST IST
□ Filme und Krimis
□ Filme und Zeichentrickfilme und Krimis
■ Film(Titel, Jahr, Länge, Typ) Zeichentrickfilm Krimi
■ FilmZ(Titel, Jahr, Länge, Typ)
Waffen
■ FilmK(Titel, Jahr, Länge, Typ, Waffen) Stimmen
■ FilmZK(Titel, Jahr, Länge, Typ, Waffen)

zu Schauspieler*in
Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 39
Objekt-orientierter Stil – Feinheiten

■ Film(Titel, Jahr, Länge, Typ) Länge Titel Jahr Typ

■ FilmZ(Titel, Jahr, Länge, Typ)
■ FilmK(Titel, Jahr, Länge, Typ, Waffen)
Film
■ FilmZK(Titel, Jahr, Länge, Typ, Waffen)

■ Kann man Film und FilmZ zusammenführen? IST IST

■ Kann man FilmK und FilmZK zusammenführen?
■ Wie viele Relationen für Stimmen benötigt man? Zeichentrickfilm Krimi
□ Nur eine:
Stimmen(Titel, Jahr, Name) Waffen
Stimmen

zu Schauspieler*in
Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 40
Mit Nullwerten
■ Eine einzige Relation mit allen Attributen. Länge Titel Jahr Typ
■ Film(Titel, Jahr, Länge, Typ, Waffen)

Film
■ Nicht-Krimis haben NULL-Wert als Attributwert für Waffen.

■ Feinheiten IST IST

□ Stumme Zeichentrickfilme und Krimis ohne Waffen sehen aus
wie „normale“ Filme.
Zeichentrickfilm Krimi

Waffen
Stimmen

zu Schauspieler*in

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 41

Vergleich der drei Stile
■ Anzahl an Relationen (bei n Entitytypen) Länge Titel Jahr Typ

□ Null-Stil: Nur eine Relation

□ ER-Stil: n Relationen
Film
□ OO-Stil: O(2n-1) Relationen

■ Speicherbedarf IST IST

□ OO-Stil: Minimaler Speicherbedarf
– Nur ein Tupel pro Entity
Zeichentrickfilm Krimi
– Jeweils nur so viele Attribute wie nötig
□ Null-Stil: Auch nur ein Tupel pro Entity Waffen
– Aber: Lange Tupel mit möglicherweise vielen Null-Werten Stimmen
□ ER-Stil: Viele Tupel pro Entity
– Aber nur Schlüsselattribute werden wiederholt. zu Schauspieler*in

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 42

Vergleich der drei Stile
■ Anfragebearbeitung Länge Titel Jahr Typ
□ Joins über viele Relationen sind teuer.
□ Þ Null-Werte im Vorteil
□ Welche Filme aus 1999 sind länger als 150 Minuten? Film
– ER-Stil: Antwort direkt möglich
– OO-Stil: Anfrage an alle vier Relationen
□ Welche Waffen wurden in Zeichentrickfilmen, die länger als
IST IST
150 Minuten sind, verwendet?
– ER-Stil: Alle drei Relationen sind relevant:
1. Filme für die Länge Zeichentrickfilm Krimi
2. Zeichentrickfilme für die Tatsache, dass es ein
Zeichentrickfilm ist Waffen
3. Krimis für die Waffe Stimmen
– OO-Stil: Anfrage nur an FilmeZK()
zu Schauspieler*in

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 43

Zusammenfassung – relationaler Datenbankentwurf

■ Relationales Modell
■ Schemata
■ Von Entitytypen zu Relationen
■ Von Relationshiptypen zu Relationen
■ Von IST-Hierarchien zu Relationen
■ Zusammenlegung

Ziawasch Abedjan | Grundlagen der Datenbanksysteme Seite 44