Philipp Cimiano AG Semantische Datenbanken und Wissensverarbeitung

Transkript

1 Einführung in Datenbanken - Objekt-Orientierte Datenbanken - Philipp Cimiano AG Semantische Datenbanken und Wissensverarbeitung 1 Probleme mit dem relationalen Modell Das Typsystem des relationalen Modells ist sehr eingeschränkt. Es werden z.b. keine komplexen Datentypen unterstützt. Außerdem gibt es im relationalen Modell keine explizite Vererbung. Das E-R unterstützt zwar Vererbung, aber diese kann im relationalen Modell nicht direkt umgesetzt werden. 2

2 Das Objektrelationale Modell Das sogenannte Objektrelationale Modell erweitert das relationale Modell um: komplexe Datentypen Vererbung Objektorientierung (z.b. Definition von Methoden für Objekte usw.) 3 Motivation Probleme mit dem Typsystem: wenn das Typsystem des DBMS und das der Programmiersprache (z.b. Java, C++) nicht übereinstimmten, dann ist es sehr schwierig die Datenbank in Applikationen zu verwenden: Es müssen ständig Typen konvertiert werden (Fallunterscheidungen!) Es müssen aus der Datenbank komplexe Datentypen erzeugt werden und umgekehrt. 4

3 Komplexe Datentypen Wir können im Objektrelationalen Modell komplexe Datentypen wie folgt erzeugen: create type Name as ( firstname varchar(20), lastname varchar(20)) final Wobei final besagt, dass wir keine Untertypen erzeugen können! 5 Beispiel: komplexer Datentyp Adresse create type Address as ( street varchar(20), city varchar(20), zipcode varchar(9)) not final 6

4 Verwendung von komplexen Datentypen 7 Wir können nun komplexe Datentypen in der Definition von anderen komplexen Datentypen verwenden: create type CustomerType as ( name Name, address Address, dateofbirth date) not final Und nun erzeugen wir eine Tabelle, die diesen komplexen Datentypen verwendet: create table customer of CustomerType Definition von Methoden Als weiteres objektorientiertes Merkmal können wir Methoden auf den komplexen Datentypen definieren: create type CustomerType as ( name Name, address Address, dateofbirth date) not final method ageondate(date date) returns interval year; 8

5 Impementierung von Methoden 9 Solche Methoden müssen natürlich auch in der Datenbank implementiert werden: create instance method ageondate (date date) returns interval year for CustomerType begin return ondate self.dateofbirth; end Wobei self sich natürlich auf die Instanz bezieht, auf der die Methode aufgerufen wird (analog zu this in Java) Verwendung von Methoden in Anfragen Nun können wir z.b. folgende Anfrage stellen: select name.lastname, ageondate(current_date) from customer 10

6 Erzeugung von Instanzen von komplexen Datentypen mittels Konstruktoren Um nun Instanzen von komplexen Datentypen erzeugen zu können brauchen wir Konstruktoren. Solche Konstruktoren werden durch sogenannte constructor functions realisiert. Sie sehen wie folgt aus: create function Name(firstname varchar(20), lastname varchar (20)) returns Name begin set self.firstname = firstname; set self.lastname = lastname; end 11 Erzeugung von neuen Objekten Wir können nun neue Objekte einfach mit new erzeugen: new Name( John, Smith ) 12

7 Einfügen von Objekten in eine Tabelle Beim Einfügen von Objekten in eine Tabelle erzeugen wir dann neue Objekte mit dem Konstruktor: insert into Customer values (new Name ( John, Smith ), new Address( 20 Main St., New York, ), date ) 13 Typvererbung Im objektrelationalen Modell haben wir tatsächlich eine explizite Typvererbung: create type Person ( name varchar(20), address varchar(20)) 14 create type Student under Person (degree varchar(20), department varchar(20)) create type Teacher under Person (salary integer, department varchar(20))

8 Vererbung Ein Subtyp erbt natürlich alle Attribute und alle Methoden von dem entsprechenden Supertyp. Es können Methoden natürlich auch neu definiert werden. Man sagt dann die Methode ist überschrieben. Ein Subtyp kann im Prinzip von mehrere Supertypen erben. Man spricht dann von multipler Vererbung (multiple inheritance). SQL unterstützt aber nur einfache Vererbung (sowie Java). 15 Tabellenvererbung Wir können nun auch Tabellen voneinander erben lassen: create table people of Person create table students of Student under people; create table teachers of Teacher under people; 16

9 Implikationen der Vererbung von Tabellen Wenn wir Tabellen vererben, dann muss der Typ der Sub- Tabelle ein Subtyp des Typs der Super-Tabelle sein. Wenn wir Tabellen vererben, dann ist jedes Tupel in der Sub-Tabelle auch automatisch in der Super-Tabelle (wichtig für Anfragen!). 17 Wenn wir ein Tupel aus der Super-Tabelle löschen, dann ist es aus allen Sub-Tabellen automatisch auch gelöscht, z.b. durch: delete from people where P Beschränkungen zur Vererbung von Tabellen Es müssen bestimmte Bedingungen bei der Vererbung von Tabellen erfüllt sein: Definition (Entsprechung von Tupeln): Ein Tupel t entspricht einem Tupel t in einer Super-Tabelle gdw. beide (t und t ) auf den vererbten Attributen die gleichen Werte haben. 18

10 Konsistenzbedingungen für Vererbung von Tabellen Konsistenzbedingung 1: Ein Tupel aus der Super-Tabelle kann höchstens einem Tupel aus einer bestimmten Sub- Tabelle entsprechen. Wir können dann keine zwei verschiedenen Studenten (Sub- Tabelle von Person) haben mit dem gleichen Namen und Adresse haben. 19 Konsistenzbedingungen für Vererbung von Tabellen Konsistenzbedingung 2: Ein Tupel in einer Sub-Tabelle darf höchstens einem Tupel (in einer Super-Tabelle) entsprechen (keine multiple Vererbung also). 20

11 Arrays, Multisets, Kollektionen SQL untersützt Arrays (seit SQL:1999) und Multisets (seit SQL:2003). Beispiel: Nehmen wir an, wir wollen Bücher modellieren mit ihrem Titel, Autoren (geordnet), Schlagwörtern (ungeordnet) und Verleger. 21 Bsp: Modellierung von Büchern Bücher haben einen Titel (String) Bücher haben eine Liste von Autoren (geordnet) Bücher haben eine Menge von Schlagwörtern (ungeordnet) Bücher haben einen Verlag (Name, Ort) 22

12 Modellierung von Büchern 23 create type Publisher as (name varchar(20), branch varchar(20)) create type Book as (title varchar(20), authors varchar(20) array [10], pub_date date, publisher Publisher, keywords varchar(20) multiset) create table books of Book Einfügen von Tupeln in die Tabelle `books insert into books values ( Compilers, array[ Smith, Jones ], new Publisher( McGraw-Hill, New York ), multiset[ parsing, analysis ]) 24

13 Anfragen von Kollektionen Um auf einzelne Elemente in einer Kollektion zugreifen zu können (in einer Anfrage), gibt es das Schlüsselwort unnest : select title from books where database in (unnest(keyword_set)) Diese Anfrage liefert dann die Titel aller Bücher zurück, die `database als eines der Schlüsselwörter haben. 25 Anfragen von Arrays über Position Wir können natürlich auch auf bestimmte Positionen in einem Array gezielt zugreifen: select authors[1], authors[2], authors[3] from books where title= Database System Concepts 26

14 Identität in Objekt-Orientierten Datenbanken Wir müssen natürlich Objekte eindeutig und explizit identifizieren. Wir wollen eine sogenannte persistente Identität herstellen, so dass Objekte über Applikationen und Ausführungen von bestimmten Programmen hinweg eindeutig identifiziert und gespeichert werden können. Wir brauchen natürlich auch IDs um Verweise auf andere Objekte einzuführen. 27 Referenzen auf Objekte in anderen Tabellen Wir können in einer Tabelle Referenzen auf Objekte in anderen Tabellen erzeugen (Fremdschlüssel). Eine Abteilung hat z.b. einen Leiter. Dieser Leiter ist eine Person und sollte in der Tabelle Person enthalten sein. Wir halten also für jedes Objekt vom Typ Abteilung eine Referenz auf ein Objekt des Typs Person. 28

15 Referenzen auf andere Objekte Eine Referenz auf ein anderes Objekt erstellt man in objektrelationalen Versionen von SQL so: create type Department ( name varchar(20), ) head ref(person) scope people create table departments of Department d.h. Department referenziert ein Objekt vom Typ Person in der Tabelle people. 29 Persistente Speicherung von solchen Referenzen Um solche Referenzen persistent speichern zu können brauchen wir also IDs. Wir können entweder die ID für ein Objekt von dem DBMS selbst generieren lassen: create table people of Person ref is person_id system generated Oder explizit vom Anwender bei der Erzeugung eines Objektes angeben lassen: create table people of Person ref is person_id user generated 30

16 Persistente Programmiersprachen Eine persistente Programmiersprache ist eine Programmiersprache, die erweitert ist um Konstrukte, um Daten persistent speichern zu können. Persistent bedeutet hier, dass die Daten unabhängig von einer bestimmten Ausführung eines Programms explizit abgelegt werden. Bisher haben wir SQL immer in Java eingebettet. Da spricht man von embedded SQL, d.h. wir betten SQL Befehle in eine Programmiersprache ein. 31 Unterschiede zwischen persistenten Programmiersprachen und embedded SQL Bei persistenten Programmiersprachen stimmt das Typsystem der Programmiersprache und der Datenbank überein (im Gegensatz zu eingebettetem SQL) Bei eingebetteten Programmiersprachen muss der Anwender sich um die persistente Speicherung der Objekte kümmern (d.h. Schreiben in die Datenbank) oder aktualisieren der Daten nach Änderung in der Datenbank. 32

17 Arten der Persistenz (in OO Systemen) Es gibt verschiedene Arten wie man Persistenz von Daten in persistenten Programmiersprachen realisieren kann: Persistente Klassen: Wenn bestimmte Klassen als persistent definiert werden, dann werden alle erzeugten Objekte auch persistent abgespeichert. Persistenz bei Erzeugung: Man gibt bei der Erzeugung eines Objektes an, ob es persistent abgespeichert werden soll oder nicht. Markierung: man kann während der Laufzeit Objekte als persistent kennzeichnen. 33 Bsp: Das Java Data Objects (JDO) Framework Das JDO Framework stellt eine Schicht dar, mit der Entwickler die persistente Speicherung von Objekten in Java realisieren können. 34

18 JDO Architektur 35 Verschiedene Arten von Klassen JDO stellt im Wesentlichen auch ein Typsystem von Klassen zur Verfügung: Persistent-capable: Klassen, die persistent gespeichert werden können. Persistence-aware: Klassen, die persistent-capable Klassen manipulieren und z.b. ihren Status bzg. Persistenz ändern können. Normal: normale Java Klassen 36

19 Bemerkungen Java Data Objects (JDO) Persistenz durch Markierung: Es wird eine Methode des sogenannten PersistenceManagers aufgerufen, um mit makepersistent(object) Objekte persistent zu machen. Die Extension von Klassen (d.h. alle Elemente die die Klasse instantiieren) werden persistent abgespeichert. Uniforme Referenz: Es wird in der Programmiersprache nicht unterschieden, ob man auf ein persistentes Objekt oder auf ein Objekt im Speicher zugreift (Methodenaufrufe, Punkt-Notation etc.) 37 Beispiele PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(props); PersistenceManager pm = pmf.getpersistencemanager(); Employee emp = new Employee("Sarah Jones", 23, ); pm.makepersistent(emp); 38

20 Verwendung von JDO 1. Klassen werden ganz normal spezifiziert und implementiert. 2. Durch Metadaten in XML definiert man das Persistenzverhalten (welche Daten persistent gespeichert werden sollen etc.) 3. Die Klassen werden anhand der Metadaten automatisch erweitert (entweder direkt der source code oder bytecode). 4. Das Framework muss an das DBMS angepasst werden. 5. Ein Datenbankschema muss erstellt werden. 39 Spezifikation einer Klasse public class Book { private String name; private Author author; public Book(String name, Author author) { this.name = name; this.author = author; } protected Book() {} public String getname() { return name; } public void setname(string name) { this.name = name; } public Author getauthor() { return author; } public void setauthor(author author) { this.author = author} } 40

21 Metadata in XML <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE jdo SYSTEM "jdo.dtd"> <jdo> <package name="com.corejdo.examples.model"> <class name="book"> <field name="author persistence-modifier="persistent"/> </class> </package> </jdo> 41 Verwendung von JDO 42 JDO ist ein Framework und kann mit verschiedenen DBMS Systemen verwendet werden. Ein Vertreiber eines DBMS (z.b. Oracle) kann nun das JDO Framework für das eigene DBMS implementieren und vertreiben. Anwender können nun beliebig zwischen verschiedenen Implementierungen des JDO Frameworks wechseln (Javacode muss nicht geändert werden!). Für jede Implementierung des JDO Frameworks können unterschiedliche Informationen in den Metadaten angegeben werden (z.b. in welcher relationalen Tabelle ein Objekt gespeichert werden soll).