Kapitel 13: Objekt-Relationale Datenbanken

Werbung
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
Herunterladen