10. Datenbank Design

10. Datenbank Design
1
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
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
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
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
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
10. Datenbank Design
7
Die (geordnete Liste der) Autoren darf nicht in ein einzelnes Feld abgespeichert werden.
Das Datumsfeld ist in dieser Form nicht gut benutzbar (Mischung aus Monat und Jahr,
kein richtiges Datum).
10. Datenbank Design
8
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
10. Datenbank Design
10
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
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
10. Datenbank Design
13
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
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
10. Datenbank Design
16
10. Datenbank Design
17
10. Datenbank Design
18
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
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
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
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
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 Stundenplan-Tabelle) 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
Bei einer 1:m 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
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
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
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