10. Datenbank- Design

Transkript

1 10. Datenbank- Design Objektrelationale Abbildung 1

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

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

4 Relationales DB-System RDBS basiert auf Relationen Wird in Tabellen abgebildet Einfach und flexibel Name der Tabelle/Relation Attribute/Felder/ Spalten Book Id Title Year 1 XML kurz und gut XML für Einsteiger 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. 4

5 Objektrelationale Abbildung Zusammenhang zwischen OO-Klassen und RDB- Tabellen 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 5

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

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

8 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) 2 Einstieg in XML Galileo (GaC: 2011) 3 Java und XML Galileo (GaC: 2009) 1. Simon St. Laurent 2. Michael Fitzgerald 1. Helmut Vonhoegen 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. 8

9 Erste Normalform Mögliche Lösung Id BookTitle Publisher PTLA Year A-Nr Firstname Name 1 XML kurz und gut 1 XML kurz und gut 2 Einstieg in XML 3 Java und XML 3 Java und XML O'Reilly ORe Simon St. Laurent O'Reilly ORe Michael Fitzgerald Galileo GaC Helmut Vonhoegen Galileo GaC Michael Scholz Galileo GaC 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. 9

10 Zweite Normalform Eine Relation ist in der zweiten Normalform, wenn die erste Normalform gilt und kein Nichtschlüssel- Attribut 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

11 Zweite Normalform Verletzung der zweiten Normalform Id BookTitle Publisher PTLA Year A-Nr Firstname Name 1 XML kurz und gut 1 XML kurz und gut 2 Einstieg in XML 3 Java und XML 3 Java und XML O'Reilly ORe Simon St. Laurent O'Reilly ORe Michael Fitzgerald Galileo GaC Helmut Vonhoegen Galileo GaC Michael Scholz Galileo GaC 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. 11

12 Zweite Normalform Mögliche Lösung Book Id BookTitle Publisher PTLA Year 1 XML kurz und gut O'Reilly ORe Einstieg in XML Galileo GaC Java und XML Galileo GaC 2009 In der Book Tabelle haben wir jetzt nur noch den Primär- Schlüssel Id von welchem alle Spalten abhängig sind. Author B-Id und A-Nr bilden zusammen einen Primär- Schlüssel, von welchem die beiden anderen Spalten abhängig sind. B-Id A-Nr Firstname Name 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. 12

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

14 Dritte Normalform Verletzung der dritten Normalform: Book Id BookTitle Publisher PTLA Year 1 XML kurz und gut O'Reilly ORe Einstieg in XML Galileo GaC 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. 14

15 Dritte Normalform Mögliche Lösung Book Id BookTitle Publisher Year 1 XML kurz und gut Einstieg in XML Java und XML Author Publisher 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). 15

16 Objekt-Relationale Abbildung Abbilden von Klassen und Relationen 16

17 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 Id Name Nr Start End State 1 Java finished 2 XML cancelled 3 OOAD finished 17

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

19 Abbilden auf nur eine Tabelle Person Id Type Name Address DateOfBirth State 1 TN Hans Muster null 2 DZ Gabi Blau 41 Null parttime 3 TN Willi Grau 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. 19

20 Abbilden jeder konkreten Klasse auf je eine Tabelle Dozent Id Name Address State 1 Gabi Blau 41 parttime Teilnehmer Id Name Address DateOfBirth 1 Hans Muster Willi Grau 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 Abbilden jeder Klasse auf je eine Tabelle Person Id Name Address 1 Hans Muster Gabi Blau 41 3 Willi Grau 12 Dozent Teilnehmer Id P-Id State 1 2 parttime Id P-Id DateOfBirth 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 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. 22

23 Abbilden einer 1:1 Assoziation Stundenplan Id Wochentag Beginn Ende 1 Montag 8:30 16:30 2 Kurs Id Name Stundenplan_FK 1 Java 1 2 Oder integriert: Kurs Id Name Wochentag Beginn Ende 1 Java Montag 8:30 16:30 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 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 Abbilden einer 1:n Assoziation Dozent Id Name Adresse 1 Josef Muster 2 Kurse 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. 24

25 Abbilden einer n:m Assoziation Teilnehmer Id Name GebDatum 1 Hans Muster 2 Kurs Id Name 1 Java 2 XML Kurs_ Teilnehmer Kurs_FK Teilnehmer_FK 2 1 Assoziations-Tabelle 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 Abbilden eines Koordinators Dozent Teilnehmer Id Name DateOfBirth 1 Hans Muster 2 Kurs Id Name 1 Java 2 XML Registrierung Course_FK Teilnehmer_FK State 2 1 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. 26

27 Reflexive Assoziation Bsp: Stückliste Folder Id Name Date Folder_FK 1 root null 2 usr bin 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