Ludwig Maximilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Datenbanksysteme I Wintersemester 2005/2006 Kapitel 13: Objekt-Relationale Datenbanken Vorlesung: Dr. Matthias Schubert Übungen: Elke Achtert, Arthur Zimek Skript © 2006 Matthias Schubert http://www.dbs.informatik.uni-muenchen.de/Lehre/DBS Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Grenzen des Relationalen Modells (1) 2 • 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 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Geometrisches Modellieren: Beschreibung von Polyedern durch ihre Begrenzungen (Boundary Representation) Hülle Flächen Begrenzung Polyeder FlächenID Kanten KantenID 4 PolyederID Start/Ende Punkte PunktID Beispiel (2) Im relationalen Model benötigt man also folgende Relationen: Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Polyeder PolyederID Volumen … … … … Poly-5 100.0 … … … … Flächen FlächenID Umfang … f1 40.0 … f2 40.0 … … … … Kanten KantenID … k-1 … Länge … 100.0 … … … … … Punkte 5 PunktID X Y Z p1 0.0 0.0 0.0 p2 10.0 0.0 0.0 … ... ... … Hülle PolyederID FlächenID Poly-5 f1 Poly-5 f2 … … Start/Ende Begrenzung FlächenID KantenID … … f1 k1 f1 k2 f1 k3 … … KantenID PunktID … … k1 p1 k1 p2 k2 p3 … … Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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) ) ) ) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Objektorientierte Datenbanken (1) 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. 9 Objektorientierte Datenbanken (2) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Beispiel: (Pseudo Code) 10 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 Objektorientierte Datenbanken (3) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Modellierung von Beziehungen: 11 Tleft R Tright • Beziehungen zwischen Objekten werden mit Referenzen modelliert. Möglichkeit 2: Möglichkeit 1: Typ: Dozent hält: {Vorlesung} Möglichkeit 3: Typ: Dozent … Typ: Vorlesung … Typ: hält Dozent Vorlesung Typ: Dozent … Typ:Vorlesung Dozent Typ: Vorlesung … • Einstiegpunkte: Ein Einstiegspunkt unterstützt nur einen Typ von Anfrage → Unterstützung mehrerer Einstiegpunkte Objektorientierte Datenbanken (4) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Problem mit mehreren Einstiegspunkten 12 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. Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Objektorientierte Datenbanken (5) 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ß. 13 Objektorientierte Datenbanken (6) Aufbau der Adressabbildung mit log. Identifikatoren: Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken ROT 14 id1 attr1: attr2:id10 attr3:id77 … ObjId mm-addr … id1 … … id10 … id11 … … … POT id77 attr1: attr2:id 14 … ObjId mm-addr … … id77 … … … id10 attr4:.. attr6:.. … Hauptspeicher Sekundärspeicher Objektorientierte Datenbanken (7) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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. 15 Objektorientierte Datenbanken (8) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Aufbau der Adressabbildung mit log. Identifikatoren: 16 id1 attr1: attr2:id10 attr3:id77 … id77 attr1: attr2:id 14 … id10 attr4:.. attr6:.. … Hauptspeicher Sekundärspeicher Problem: Man muß wissen welche anderen Objekte ein Objekt referenzieren, wenn dessen Speicherort geändert wird. Objektorientierte Datenbanken (9) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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. ROT id1 ObjId id1 … id10 id11 … attr1: attr2:id10 attr3:id77 … mm-addr … … … … … id10 attr4:.. attr6:.. … POT attr1: id77 attr2:id 14 ObjId … id77 … mm-addr … … … Hauptspeicher Sekundärspeicher … 17 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Objekt-Relationale Datenbanken (2) 20 • 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. Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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(‘11-11-1956‘,‘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 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken • 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) Vorsicht: Das referenzierte Objekt kann auch ungültig werden. (Dangling References) 24 Objekt-Relationale Datenbanken (7) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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; • Aufruf 25 Select a.normalize() from rational where.. Objekt-Relationale Datenbanken (8) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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 Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken 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) Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Beispiel mengenwertige Attribute: 28 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; Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Objekt-Relationale Datenbanken (11) 29 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’; Ergebnis: Name -----------------------------Neptune Datenbanksysteme I Kapitel 13: Objekt-Relationale Datenbanken Zusammenfassung 30 • 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