Kapitel 13: Objekt-Relationale Datenbanken

Transkript

1 Ludwig Maximilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Wintersemester 2005/2006 Kapitel 13: Objekt-Relationale Datenbanken Vorlesung: Dr. Matthias Schubert Übungen: Elke Achtert, Arthur Zimek Skript 2006 Matthias Schubert Grenzen des Relationalen Modells (1) Bis jetzt lag der Fokus der Vorlesung auf Standardanwendungen: übersichtliche Datenobjekte z.b. Belege, Materialbestände, Vorlesungen kurze Transaktionen: Änderung weniger Datensätze viele Benutzer: mehrere 100 Mitarbeiter arbeiten gleichzeitig auf der Datenbank 2

2 Grenzen des Relationalen Modells (2) Für Nicht-Standard Anwendungen ist das relationale Model ungeeignet: Verwaltung CAD-Bauteile, Chip-Design Eigenschaften von Nicht-Standard Anwendungen: komplexe Objekte: 3D Bauteile, Proteine, Multimedia.. verschiedene Repräsentationen: Voxeldarstellung, Polygondarstellung, Einhaltung von zusätzlichen Konsistenzbedingungen: 3D Objekte dürfen nur gedreht, nicht skaliert werden. Wiederverwendung von vorhandenen Basis-Bausteinen: Bauteile bestehen aus anderen Teilen. Beispiel: Typ Würfel hat vieles mit Typ Quader gemeinsam 3 Beispiel (1) Geometrisches Modellieren: Beschreibung von Polyedern durch ihre Begrenzungen (Boundary Representation) Hülle Flächen Begrenzung Polyeder FlächenID Kanten Start/Ende PolyederID Punkte KantenID PunktID 4

3 Beispiel (2) 5 Im relationalen Model benötigt man also folgende Relationen: Polyeder PolyederID Volumen Poly Flächen FlächenID Umfang f f Kanten KantenID Länge k Punkte PunktID X Y Z p p Hülle PolyederID FlächenID Poly-5 f1 Poly-5 f2 Start/Ende KantenID PunktID k1 p1 k1 p2 k2 p3 Begrenzung FlächenID KantenID f1 k1 f1 k2 f1 k3 Beispiel (3) 6 Aufwendige Anfragen: Finde die Koordinaten aller Punkte von Polyederen, deren Volumen >= 10 ist! select X,Y,Z from Punkte where PunktID in( select PunktID from Start/Ende where KantenID in( select KantenID from Begrenzung where FlächenID in ( select FlächenID from Hülle where PolyederID in ( select PolyederID from Polyeder where Volumen > 10.0) ) ) )

4 Schwächen des Relationalen Modells Bei nicht Nicht-Standard Anwendungen: Aufspaltung logischer Objekte (kein gekapselter Zugriff) Künstliche Schlüssel (Verwaltung künstlicher Schlüssel weitgehend durch den Benutzer) Keine Beziehungen zwischen den Relationen (z.b. Is-A Beziehung,) keine Modellierung des Verhaltens (nur in Anwendungslogik/Stored Procedures) 7 Lösungsansätze 8 Objektorientierte Datenbank eigenes Datenmodell, das auf Objekten aufsetzt meist sehr ähnlich zu objektorientierten Programmiersprachen wie JAVA mit persistenten Objekten. Objekt-Relationale Datenbank Erweiterung des Relationalen Modells um nicht atomare Datentypen. Verwendung von etablierten Lösungen zu Concurrency Control, Transaktionsverwaltung Zugriff über Tupel oder Referenzen innerhalb eines Objekts

5 Objektorientierte Datenbanken (1) 9 Daten werden als Objekte modelliert: Objektklassen werden aus 1. elementaren Datentypen (Integer, Byte, Double) 2. anderen Objekten 3. Mengen von diesen gebildet. Objektverhalten wird durch Methoden modelliert. Objekte sind gekapselt: Zugriff über öffentliche Schnittstelle Implementierung bleibt den Benutzern verborgen. Vererbung, Überladung, Polymorphie, Im Prinzip werden hier alle objektorientierten Konstrukte und Möglichkeiten angeboten, wie bei JAVA oder C++. Syntax und genaue Realisierung hängen vom jeweiligen Datenbanksystem ab. Objektorientierte Datenbanken (2) Beispiel: (Pseudo Code) persistent type Vertex is public body[x,y,z: float] operations implementation end type Vertex; Objekttypen modellieren Entities und ihr Verhalten. Neue Objekte entstehen durch Instanziieren der Typen. Es können 2 Objekte mit identischen Eigenschaften instanziiert werden. Zugriff auf Teilobjekte über Referenz (kein Join nötig!) Mengen von Teilobjekten: Arrays und Listen im Objekt 10

6 Objektorientierte Datenbanken (3) Modellierung von Beziehungen: 11 T left R T right Beziehungen zwischen Objekten werden mit Referenzen modelliert. Möglichkeit 1: Möglichkeit 2: Typ: Dozent Typ: Vorlesung Typ: Dozent hält: {Vorlesung} Möglichkeit 3: Typ: Dozent Typ: hält Dozent Vorlesung Typ: Vorlesung Typ:Vorlesung Dozent Einstiegpunkte: Ein Einstiegspunkt unterstützt nur einen Typ von Anfrage Unterstützung mehrerer Einstiegpunkte Objektorientierte Datenbanken (4) Problem mit mehreren Einstiegspunkten Bei Änderung in einer Repräsentation der Beziehung müssen die anderen Repräsentationen vom Datenbanksystem ebenfalls geändert werden. Beipiel: Ändere den Dozenten für die Vorlesung DBS I von Prof. Kriegel zu Prof. Böhm! 1. Umlegen der Referenz Vorlesung-Objekt 2. Erzeugen einer Referenz in der Liste der Vorlesung von Prof. Böhm. 3. Löschen der Referenz in der Liste der Vorlesungen bei Prof. Kriegel. 12

7 Objektorientierte Datenbanken (5) 13 Objektidentifikation mit logischen Objektidentifikatoren Es soll prinzipiell möglich sein unterschiedliche Objekte mit den selben Werten zu instanziieren. (Keine wertabhängigen Schlüssel wie im rel. Modell) Eine künstliche ObjektID entspricht also einem künstl. Primärschlüssel im relatioalen Modell. Auffinden des Speicherorts eines Objekts über Tabellen: 1. Resident Object Table (ROT): Abbilden der log. Objektidentifikatoren auf Hauptspeicheradressen. 2. Persisdent Object Table (POT): Abbilden der log. Obj. ID auf Sekundärspeicheradressen. Meist sehr groß. Objektorientierte Datenbanken (6) Aufbau der Adressabbildung mit log. Identifikatoren: id 1 id 77 attr1: attr2:id10 attr3:id77 attr1: attr2:id 14 ROT ObjId mm-addr id 1 id 10 id 11 POT ObjId mm-addr id 77 id 10 attr4:.. attr6:.. Hauptspeicher Sekundärspeicher 14

8 Objektorientierte Datenbanken (7) 15 Objektidentifikation mit phys. Identifikatoren Bei OO-Programmiersprachen werden Objekte über ihre Adresse im Hauptspeicher identifiziert. Vorteil: Objektidentifikator erlaubt schnellen Zugriff auf Objekt Anwendung in Datenbanken mit persistenten Objekten ist allerdings problematisch: Objekte, die nicht gerade im Hauptspeicher sind, können nur durch die Adresse auf der Festplatte identifiziert werden. Umlegen aller Referenzen ist notwendig, wenn sich Speicherort eines Objekts ändert. Objektorientierte Datenbanken (8) Aufbau der Adressabbildung mit log. Identifikatoren: 16 id 1 id 77 attr1: attr2:id10 attr3:id77 attr1: attr2:id 14 attr4:.. attr6:.. Problem: Man muß wissen welche anderen Objekte ein Objekt referenzieren, wenn dessen Speicherort geändert wird. id 10 Hauptspeicher Sekundärspeicher

9 Objektorientierte Datenbanken (9) Pointer Swizzling Idee: Vertauschen der Referenzen auf die ROT durch die tatsächliche Adresse im Hauptspeicher. Bei Speicherung auf der Platte verwendet man Unswizzling. D.h. die Referenz werden wieder in log. IDs. übersetzt. id 1 attr1: attr2:id10 attr3:id77 id 77 attr1: attr2:id 14 ObjId id 1 id 10 id 11 ObjId id 77 ROT mm-addr POT mm-addr id 10 attr4:.. attr6:.. Hauptspeicher Sekundärspeicher 17 Objektorientierte Datenbanken (10) 18 Es gibt mehrere kommerzielle, objektorientierte DBMS z.b.: ObjectStore, DB4O, Versant.. Es hat sich keine einheitliche Anfragesprache, wie SQL durchgesetzt. Meist nur bei sehr speziellen Anwendungen im Einsatz. Transaktionsverwaltung, Anfrageoptimierung, und Mehrbenutzerbetrieb sind meist nicht so ausgereift, wie in den marktführenden relationalen Datenbanksystemen. Objektorientierte Konzepte wurden in den letzten Jahren stark in die großen kommerziellen System wie ORACLE, DB2, SQL-Server, integriert. => Objekt-Relationale Datenbanken

10 Objekt-Relationale Datenbanken (1) Objekt-Relationale Datenbanken verwenden sowohl Konstrukte des relationalen als auch des objektorientierten Datenmodells. Einführung von benutzerdefinierten Objekttypen, die wie atomare Datentypen behandelt werden. Ein Objekttyp kann ebenfalls mengenwertige Operationen enthalten. Objektidentifikation i.d.r. über logische Objektidentifikatoren (künstl. Schlüssel) Abspeichern von Objekten in Objekt-Relationen (Das Basiskonzept zu Verwaltung von Daten bleibt die Relation) 19 Objekt-Relationale Datenbanken (2) Wie bereits erwähnt ist objektorientierte Datenmodellierung mittlerweile Teile vieler relationaler DBMS: ORACLE, DB2, Informics, Postgress, Auch hier existiert kein einheitlicher Sprachstandard. Allerdings verwenden die unterschiedlichen Produkte Erweiterung von SQL und ihren eigenen Programmiersprachen (z.b. PL/SQL). Im folgenden werden einige Objekt-Relationale Konstrukte anhand von ORACLE 9i und der ORACLE spezifischen Programmiersprache PL/SQL vorgestellt. 20

11 Objekt-Relationale Datenbanken (3) Einführung von Objekten über User defined Data Types: Beispiel: CREATE TYPE person AS OBJECT( P_ID number, Vorname VarChar2(128), NachName VarChar2(128), Geburtsdatum date, Job job_description_type); - Objekttypen werden in der Datenbank ähnlich zu Relationen gespeichert (Data Dictionary Objekt) - Ein Objekttyp kann (hier: job_description_type ) als Domaine für eine Relation verwendet werden. 21 Objekt-Relationale Datenbanken (4) Eine weitere Verwendungsmethode stellen so genannte Objekttabellen dar. Beispiel: CREATE TABLE persons OF person(p_id Primary Key); Verwendung: INSERT INTO persons VALUES( person(1, Joe, Camel, to_date( , dd-mm-yyyy ), job_description_type( Programmierer,)); Selektion: Ergebnis ist Objekt SELECT value(p) from persons p where p.job.description = Programmierer ; Selektion: Ergebnis ist Tupel SELECT * from persons p where p.job.description = Programmierer ; 22

12 Objekt-Relationale Datenbanken (5) Manchmal braucht man einen objektorientierten Zugriff auf eine Relation. Object-Views CREATE TABLE person_tab ( P_ID number, Vorname VarChar2(128), NachName VarChar2(128), Geburtsdatum date, Job job_description_type); Anlegen der Object-View: CREATE VIEW person_object_view OF person WITH OBJECT IDENTIFIER(P_ID) AS SELECT * FROM person_tab 23 Objekt-Relationale Datenbanken (6) Referenzen emöglichen direkten Bezug auf Objekte in anderen Tabellen CREATE TYPE Deparment AS OBJECT( DepartmentNR number, chef REF person SCOPE is Angestellte); Zusatz SCOPE IS beschränkt die referenzierten Objekte auf die Tabelle Angestellte. Vorteile gegenüber Fremdschlüssel: Zugriff über Punktnotation (z.b. dept.chef.p_id =12342) direkter Zugriff auf Row-Objekt (sehr effizient) 24 Vorsicht: Das referenzierte Objekt kann auch ungültig werden. (Dangling References)

13 Objekt-Relationale Datenbanken (7) Methoden Modellieren das Verhalten der Objekte. Deklaration CREATE TYPE rational AS OBJECT( nom INTEGER, den INTEGER, MEMBER PROCEDURE normalize, ) CREATE TYPE BODY Rational AS MEMBER PROCEDURE normalize IS g INTEGER, BEGIN g:= gcd(self.num,self.den); num :=num/g; num :=num/g; End normalize; END; 25 Aufruf Select a.normalize() from rational where.. Objekt-Relationale Datenbanken (8) Vererbung Anlegen von Untertypen CREATE TYPE person_type as OBJECT (ssn number, name VARCHAR(128), address VARCHAR2(30)) NOT FINAL; CREATE TYPE STUDENT_type UNDER person_type (deptid NUMBER, major VARCHAR2(30)) NOT FINAL; UNDER kennzeichnet die Vaterklasse. nur einfache Vererbung und keine mehrfach Vererbung. NOT FINAL bedeutet, dass Untertypen erlaubt sind. Überladung von vererbten Methoden ist erlaubt. Verwendung: INSERT INTO person_tab (student_typ(1, Hans Mustermann,..,12, Informatik ); 26

14 Objekt-Relationale Datenbanken (9) Mengenartige Datentypen Um 1:n oder n:m Beziehung objektorientiert darzustellen werden mengenartige Datentypen/Attribute zugelassen. 2 Arten können verwendet werden: 1. VARRAY: Array aus fest spezifizierter Anzahl an Einträgen. Kann bei Überlauf vergrößert werden. Speicherung als Binary Large Object (BLOB). 2. NESTED TABLE: Dynamische Datenstruktur beliebiger Größe. Manipulation über SQL. Speicherung in Datenbanktabellen (storage tables). 27 Objekt-Relationale Datenbanken (10) 28 Beispiel mengenwertige Attribute: CREATE TYPE satellite_t AS OBJECT ( name VARCHAR2(20), diameter NUMBER); CREATE TYPE nt_sat_t AS TABLE OF satellite_t; CREATE TYPE va_sat_t AS VARRAY(100) OF satellite_t; CREATE TYPE planet_t AS OBJECT ( name VARCHAR2(20), mass NUMBER, satellites1 va_sat_t, satellites2 nt_sat_t); CREATE TYPE nt_pl_t AS TABLE OF planet_t;

15 Objekt-Relationale Datenbanken (11) CREATE TABLE stars(name VARCHAR2(20),age NUMBER, planets nt_pl_t) NESTED TABLE planets STORE AS planets_tab (NESTED TABLE satellits STORE AS sattelites_tab); Zugriff auf mengenartige Attribute: INSERT INTO stars VALUES('Sun',23, nt_pl_t( planet_t('neptune',10, nt_sat_t(satellite_t('proteus',67), satellite_t('triton',82) ) ), planet_t('jupiter', 189, nt_sat_t(satellite_t('callisto',97), satellite_t('ganymede', 22)))); --Select Statement SELECT p.name FROM stars s, TABLE(s.planets) p, TABLE(p.satellites) t WHERE t.name = Proteus ; 29 Ergebnis: Name Neptune Zusammenfassung Objektorientierte und objekt-relationale Datenbanken lösen viele Probleme bei der Verwaltung komplexer Objekte Verwendung des objektorientierten Paradigmas wenig standardisierte Produkte keine allgemeine Verbesserung der Modellierung, sondern eher eine Verschiebung der Prioritäten Objektorientierung erlaubt viele Möglichkeiten für nicht Standardanwendungen 30