10. Datenbank

10. DatenbankDesign
Objektrelationale Abbildung
10. Datenbank Design
1
Eigenschaften einer Datenbank
Persistenz
Daten gehen bei Programmende nicht verloren
Zuverlässigkeit
Konsistenz, Integrität, Unversehrtheit, Effizienz
Unabhängigkeit
Eigene Programmiersprache, eigenes System
Abstraktion
Kommunikation über Schnittstelle
Datenschutz
Kein unberechtigter Zugriff
Mehrfachbenutzung
Die Hauptaufgabe einer Datenbank besteht darin, Daten so lange
zu speichern bis diese explizit überschrieben oder gelöscht
werden. Also auch über das Ende (ev. sogar der Lebenszeit)
einer Applikation hinaus.
Die Daten müssen konsistent (vollständig und widerspruchsfrei),
integer (unverfälscht, sicher), unversehrbar (geschützt vor
absichtlicher oder unabsichtlicher Veränderung) gespeichert
werden und effizient wieder lesbar sein.
Um die Langlebigkeit der Daten zu gewähren, muss die
Verwaltung der Daten unabhängig von den benutzenden
Applikationen geschehen (Programmiersprache). Ausserdem
will der Applikationsentwickler sich nicht um die technischen
Details der Datenbank kümmern müssen, sondern auf einer
höheren, abstrakten Schnittstelle auf die DB zugreifen können.
Die Daten der Datenbank müssen vor unberechtigtem Zugriff
geschützt werden können, anderseits soll aber jeder
berechtigte Anwender (ev. auch mehrere gleichzeitig) auf die
Daten zugreifen können.
10. Datenbank Design
2
Datenbankmodell
Eigenschaften der Datenelemente
Typ, Länge, Wertebereich, …
Struktur
Tabellenstruktur, Schlüssel, Beziehungen
Konsistenz-Bedingungen
Eindeutigkeit/Vorhandensein von Werten
Ein Datenbankmodell ist die theoretische Grundlage für eine
Datenbank und bestimmt, auf welche Art und Weise Daten in
einem Datenbanksystem gespeichert und bearbeitet werden
können.
Jedem Datenbanksystem muss darum ein Datenbankmodell
zugrunde liegen, in welchem die DB Struktur (Tabellen), die
Typen der Elemente, die Konsistenzbedingungen, … festgelegt
sind.
10. Datenbank Design
3
Relationales DB-System
RDBS basiert auf Relationen
Wird in Tabellen abgebildet
Einfach und flexibel
Attribute/Felder/
Spalten
Name der Tabelle/Relation
Book
Id
Title
Year
1
XML kurz und gut
2006
2
XML für Einsteiger 2002
3
…
Tupel/
Zeilen
Relationale Datenbanksysteme sind sehr einfach und flexibel und
darum heute die am häufigsten benutzten DB Systeme.
Ihr Nachteil ist allerdings, dass sie die OO-Konzepte nicht eins zu
eins abbilden können.
10. Datenbank Design
4
Objektrelationale Abbildung
Zusammenhang zwischen OO-Klassen und RDBTabellen
ORM
???
???
???
???
???
Objektorientierte Programmiersprachen kapseln Daten und
Verhalten in Objekten, relationale Datenbanken hingegen
legen Daten in Tabellen ab. Ausserdem stellt nicht jede Menge
von Tabellen eine relationale Datenbank dar.
Die beiden Paradigmen OO und RDB sind grundlegend
verschieden. Es braucht darum einen Mechanismus, wie man
eine Abbildung zwischen Klassen(-Strukturen) und relationalen
Tabellen finden kann.
ORM: object-relational mapping
10. Datenbank Design
5
DB Normalformen
Eine DB mit redundanten Daten ermöglicht, dass
bei Daten-Änderungen die mehrfach enthaltenen
Daten inkonsistent werden.
Anomalien, Widersprüche
Speicherplatz-Verschwendung
Redundanzen vermeiden durch Normalisierung
Das Ausmass, in denen ein Datenbankschema
gegen Anomalien gefeit sein kann
erste, zweite, dritte, ... Normalform
Damit eine Menge von Tabellen (ein Datenbankschema) eine
brauchbare Relationale Datenbank darstellt, müssen einige
Regeln erfüllt sein. Diese sind bekannt unter dem Begriff DB
Normalformen.
10. Datenbank Design
6
Erste Normalform
Jedes Attribut der Relation muss einen atomaren
Wertebereich haben.
Zusammengesetzte oder geschachtelte
Wertebereiche sind nicht erlaubt.
Kein Attributwertebereich kann in weitere
(sinnvolle) Teilbereiche aufgespaltet werden
Beispiel: Adresse darf nicht als Attribut verwendet werden,
sondern muss in PLZ, Ort, Straße und Hausnummer
aufgeteilt werden.
10. Datenbank Design
7
Erste Normalform
Verletzung der ersten Normalform
Publikation aus Verlag, Kürzel und Jahr
Mehrere Autoren (mit Reihenfolge)
ID BookTitle
Published
Author
1
XML kurz und gut
O'Reilly
(ORe:2006)
1. Simon St. Laurent
2. Michael Fitzgerald
2
Einstieg in XML
Galileo
(GaC: 2011)
1. Helmut Vonhoegen
3
Java und XML
Galileo
(GaC: 2009)
1. Michael Scholz
2. Stephan Niedermeier
Keine Selektion oder Sortierung nach Erscheinungs-Jahr
möglich
Autoren können nicht einfach aufgelistet werden.
Die (geordnete Liste der) Autoren darf nicht in ein einzelnes Feld
abgespeichert werden. Das Erscheinungsjahr ist in dieser
Form nicht vernünftig abfragbar.
10. Datenbank Design
8
Erste Normalform
Mögliche Lösung
Id
BookTitle
Publisher PTLA Year A-Nr Firstname Name
1
XML kurz
und gut
O'Reilly
ORe
2006
1
Simon
St. Laurent
1
XML kurz
und gut
O'Reilly
ORe
2006
2
Michael
Fitzgerald
2
Einstieg in
XML
Galileo
GaC
2011
1
Helmut
Vonhoegen
3
Java und
XML
Galileo
GaC
2009
1
Michael
Scholz
3
Java und
XML
Galileo
GaC
2009
2
Stephan
Niedermeier
Diese Lösung hat allerdings immer noch Schwächen: Wir haben
jetzt Buch 1 und 3 doppelt in der Datenbank. Ausserdem ist es
schwierig zu prüfen, ob die Autorennummern (A-Nr) eindeutig
(und vollständig) sind.
10. Datenbank Design
9
Zweite Normalform
Eine Relation ist in der zweiten Normalform, wenn
die erste Normalform gilt und kein NichtschlüsselAttribut voll funktional abhängig von einer echten
Teilmenge eines Schlüsselkandidaten ist.
Das heisst: Von einer beliebigen Teil-Menge von
Attributen (Spalten), die keine Schlüsselfunktion
haben, kann nicht auf den Wert anderer Attribute
geschlossen werden.
10. Datenbank Design
10
Zweite Normalform
Verletzung der zweiten Normalform
Id
BookTitle
Publisher PTLA Year A-Nr Firstname Name
1
XML kurz
und gut
O'Reilly
ORe
2006
1
Simon
St. Laurent
1
XML kurz
und gut
O'Reilly
ORe
2006
2
Michael
Fitzgerald
2
Einstieg in
XML
Galileo
GaC
2011
1
Helmut
Vonhoegen
3
Java und
XML
Galileo
GaC
2009
1
Michael
Scholz
3
Java und
XML
Galileo
GaC
2009
2
Stephan
Niedermeier
Die Spalten Id und A-Nr bilden einen (Primär-) Schlüssel.
Buchtitel, Publisher und Year sind von der Id abhängig, nicht
aber von der Nummer des Autors.
Die Id des Buchs identifiziert vollständig die Spalten Buchtitel,
Publisher und PTLA, das heisst, diese sind vom zweiten
Schlüssel unabhängig. Damit wird aber die zweite Normalform
verletzt.
Der zweite Schlüssel A-Nr identifiziert zusätzlich (nur noch) den
Namen des Autors.
10. Datenbank Design
11
Zweite Normalform
Mögliche Lösung
Book
Id BookTitle
Publisher
PTLA Year
1
XML kurz und gut
O'Reilly
ORe
2006
2
Einstieg in XML
Galileo
GaC
2011
3
Java und XML
Galileo
GaC
2009
In der Book Tabelle
haben wir jetzt nur
noch den PrimärSchlüssel Id von
welchem alle
Spalten abhängig
sind.
Author B-Id A-Nr Firstname Name
B-Id und A-Nr bilden
zusammen einen PrimärSchlüssel, von welchem
die beiden anderen
Spalten abhängig sind.
1
1
Simon
St. Laurent
1
2
Michael
Fitzgerald
2
1
Helmut
Vonhoegen
2
2
Michael
Scholz
3
1
Stephan
Niedermeier
B-Id ist jetzt in der Autoren-Tabelle ein Fremdschlüssel, welcher
auf den Primärschlüssel der Book-Tabelle verweist. Ausserdem
bilden jetzt B-Id und A-Nr zusammen einen Primärschlüssel für
die Autoren-Tabelle.
Allerdings ist auch hier noch keine Redundanzfreiheit
gewährleistet. Ein Autor, welcher mehrere Bücher geschrieben
hat, wird in dieser Darstellung mehrfach aufgelistet.
10. Datenbank Design
12
Dritte Normalform
Die dritte Normalform ist erfüllt, wenn sich das
Relationen-Schema in der zweiten Normalform
befindet, und kein Nichtschlüsselattribut von
einem Schlüsselkandidaten transitiv abhängt.
Ein Nichtschlüsselattribut darf also nicht von einer
Menge von Nichtschlüsselattributen, sondern nur
direkt von einem Primärschlüssel abhängig sein.
10. Datenbank Design
13
Dritte Normalform
Verletzung der dritten Normalform:
Book
Id BookTitle
Publisher
PTLA
Year
1
XML kurz und gut
O'Reilly
ORe
2006
2
Einstieg in XML
Galileo
GaC
2011
3
Java und XML
Galileo
GaC
2009
Die Spalte PTLA hängt direkt von der Spalte Publisher ab.
Beim Ändern des Publishers müsste auch die PTLA Spalte
geändert werden.
PTLA ist unabhängig von der Book Id und hängt allein vom
Publisher ab. Publisher ist aber kein Schlüsselattribut für Buch.
Darum ist hier die dritte Normalform verletzt.
10. Datenbank Design
14
Dritte Normalform
Mögliche Lösung
Book
Id
BookTitle
Publisher
Year
1
XML kurz und gut
1
2006
2
Einstieg in XML
2
2011
3
Java und XML
2
2009
Publisher
Author
Id
B-Id
Firstname
Name
1
1
Simon
St. Laurent
2
1
Michael
Fitzgerald
3
2
Helmut
Vonhoegen
4
3
Michael
Scholz
5
3
Stephan
Niedermeier
Id Publisher
PTLA
1
O'Reilly
ORe
2
Galileo
GaC
Durch Auslagern der Publisher in eine eigene Tabelle ist PTLA
direkt vom Primärschlüssel des Publishers abhängig, d.h. die
dritte Normalform ist gewährleistet.
Die Autoren-Tabelle enthält hier einen Fremdschlüssel auf die
Buch-Tabelle. Dies funktioniert hier gut, da jeder Autor nur
einem Buch zugeordnet ist. Um einem Autor mehrere Bücher
zuzuordnen, bräuchte es eine separate Assoziations-Tabelle
(siehe Folie weiter hinten).
10. Datenbank Design
15
Objekt-Relationale
Abbildung
Abbilden von Klassen und
Relationen
10. Datenbank Design
16
Abbilden von Klassen
Operationen werden nicht abgebildet.
Atomare Attribute erscheinen als Spalte in der
Tabelle mit (möglichst) demselben Typ
Die Tabelle wird um einen Primär-Schlüssel
ergänzt
Course
10. Datenbank Design
Id
Name
Nr
Start
End
State
1
Java
10
3
12.1.2011
2.7.2011
finished
2
XML
41
3.10.201
0
1.1.2011
cancelle
d
3
OOAD
12
15.2.2011
9.8.2011
finished
17
Abbilden von Vererbung
Es gibt verschiedene Möglichkeiten,
Generalisierungs-Hierarchien abzubilden
Abbilden der ganzen Hierarchie auf nur eine
Tabelle
Abbilden nur der konkreten Klassen auf je eine
Tabelle
Abbilden jeder Klasse auf je eine separate Tabelle
10. Datenbank Design
18
Abbilden auf nur eine Tabelle
Person
Id
Type
Name
Address
DateOfBirt
h
State
1
TN
Hans Muster
103
12.1.1985
null
2
DZ
Gabi Blau
41
Null
partTime
3
TN
Willi Grau
12
15.2.1990
null
Teilnehmer
Dozent
Dieser Ansatz ist zwar sehr einfach, der Zugriff auf die Daten ist
schnell, da alle Daten in der gleichen Tabelle liegen. Weitere
Subklassen sind einfach einzufügen, es müssen nur die
entsprechenden Spalten angefügt werden.
Der Ansatz hat aber den Nachteil dass viele der Attribute auf null
gesetzt werden müssen (alle, welche im speziellen Subtyp
nicht vorkommen). Ausserdem sind bei einer Änderung
innerhalb der Hierarchie (z.B. Ergänzen einer Klasse um ein
weiteres Attribut) immer alle Objekte der Hierarchie betroffen.
Dieser Ansatz ist geeignet für Hierarchien geringer Tiefe mit
wenig verschiedenen Klassen.
Die Spalte Type enthält den eigentlichen Datentyp, hier also
entweder Teilnehmer oder Dozent. Person kann als Type
vorkommen, ausser wenn die Basisklasse abstrakt (oder ein
Interface) ist.
10. Datenbank Design
19
Abbilden jeder konkreten Klasse
auf je eine Tabelle
Dozent
Teilnehmer
Id
Name
Address
1
Hans Muster
103
12.1.2011
2
Willi Grau
12
15.2.2011
Id
Name
1
Gabi
Blau
Address
41
State
partTime
DateOfBirt
h
Hier wird jede konkrete Klasse auf eine separate Tabelle
abgebildet. Jede Tabelle hat einen eigenen Primär-Schlüssel
(Id). Auch hier ist der Zugriff effizient, da jeder Zugriff nur eine
Tabelle betrifft. Der Nachteil ist, dass bei einer Änderung der
abstrakten Oberklasse (hier Person) alle davon betroffenen
Tabellen geändert werden müssen.
Dieser Ansatz ist daher am ehesten geeignet, wenn die
Basisklasse nur wenig Attribute besitzt.
10. Datenbank Design
20
Abbilden jeder Klasse auf je eine
Tabelle
Dozent
Person
Id
Name
1
Hans Muster
103
2
Gabi Blau
41
3
Willi Grau
12
Id
P-Id
State
1
2
partTime
Address
Teilnehmer
Id
P-Id
DateOfBirth
1
1
12.1.2011
2
3
15.2.2011
Dieser Ansatz entspricht am besten dem Objektorientierten
Konzept. Änderungen in der Basisklasse hat keine
Änderungen in den „abgeleiteten“ Tabellen zur Folge. Neue
Attribute in den Subklassen betreffen nur die eigene Tabelle.
Der Nachteil ist, dass sehr viele Tabelle entstehen und die
Abfragen aufwändiger werden, da bei dieser Variante die
Informationen in verschiedenen Tabellen liegen.
10. Datenbank Design
21
Abbilden von Assoziationen
Unterscheiden nach Multiplizität
1:1
1:n
n:m
Assoziationen einer Relationalen DB sind immer
bidirektional.
Je nach Multiplizität der Assoziation wählen wir eine andere Art
der Abbildung.
Im Gegensatz zum Objektorientierten Modell können wir in einer
DB immer beide Richtungen einer Assoziation finden. Je nach
Realisierung brauchen wir einfach eine andere SQL-Abfrage.
10. Datenbank Design
22
Abbilden einer 1:1 Assoziation
Stundenplan
Id
Weekday
StartTime
EndTime
1
Monday
8:30
16:30
2
Course
Id
Name
Stundenplan_F
K
1
Java
1
… …
2
Oder integriert:
Course
Id
Name Weekday
StartTime
EndTime
1
Java
8:30
16:30
Monday
2
1:1 Assoziationen können durch Verschmelzen der Informationen
in eine einzige Tabelle abgebildet werden. Dies ist die
kompakteste und effizienteste Umsetzung.
Falls man das nicht möchte, kann die Assoziation mit Hilfe eines
Fremdschlüssels realisiert werden. Bei der gerichteten
Assoziation von Course zu Stundenplan bietet sich ein
Fremdschlüssel Stundenplan_FK in der Course Tabelle an.
Das umgekehrte (Fremdschlüsssel Course_FK in StundenplanTabelle) wäre aber genau so möglich.
Die SQL Abfrage für die Wochentage aller Kurse wäre dann etwa
select c.Name, s.Weekday from Stundenplan s, Course c
where c.Stundenplan_FK = s.Id
10. Datenbank Design
23
Abbilden einer 1:n Assoziation
Dozent
Id
Name
Address
1
Josef Muster
…
2
Course
Id
Name Dozent_FK … …
1
Java
1
2
Bei einer 1:n Assoziation wird der Fremdschlüssel in die Klasse
eingefügt, welche die Multiplizität 1 hat. Hier: jeder Kurs hat
(nur) einen Dozenten, Dozenten können mehrere Kurs halten.
10. Datenbank Design
24
Abbilden einer n:m Assoziation
Course
Teilnehmer
Id
Name
1
Hans Muster
DateOfBirth …
Id
Name … …
1
Java
2
XML
2
Course_ Teilnehmer Course_FK Teilnehmer_FK
2
Assoziations-Tabelle
1
Zum Abbilden einer n:m Assoziation benötigen wir eine
zusätzliche Tabelle für die Tupel der Fremdschlüssel.
Course_Teilnehmer ist eine sogenannte Assoziations-Tabelle
(associative table).
10. Datenbank Design
25
Abbilden eines Koordinators
Dozent
Course
Teilnehmer
Id
Name
1
Hans Muster
DateOfBirth …
Id
Name … …
1
Java
2
XML
2
Registrierung
Course_FK Teilnehmer_FK
2
1
State
active
Die Koordinator-Klasse verbindet (indirekt) zwei Klassen durch
eine n:m Assoziation, trägt aber zusätzliche Informationen (hier
ein state-Attribut). Auch diese wird mit einer
Assoziationstabelle (mit zusätzlichen Spalten für die
Koordinator-Attribute) realisiert.
10. Datenbank Design
26
Reflexive Assoziation
Bsp: Stückliste
Folder
Id
Name Date
Folder_FK … …
1
root
10.1.2008
null
2
usr
1.12.2008
1
3
bin
1.12.2008
1
… …
Zum Abbilden einer reflexiven (rekursiven) Assoziation kann ein
Fremdschlüssel benutzt werden, welcher auf den
Primärschlüssel der eigenen Tabelle zeigt. Dieser ist für die
Root-Elemente der Hierarchie leer (null).
10. Datenbank Design
27