10. Datenbank Design 1

Transkript

1 1

2 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. 2

3 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. 3

4 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. 4

5 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 5

6 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. 6

7 7

8 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). 8

9 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. 9

10 10

11 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. 11

12 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. 12

13 13

14 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. 14

15 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). 15

16 16

17 17

18 18

19 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. 19

20 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. 20

21 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. 21

22 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. 22

23 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 23

24 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. 24

25 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). 25

26 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. 26

27 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). 27