Objektorientierte Datenbanksysteme

Objektorientierte Datenbanksysteme
•
Konzepte
•
•
•
Objekt-Datenbanken
Objekt-relationale und erweiterte relationale DBS
SQL3
DBS1 2004
OODBS
Seite 1
Klöditz
Hochschule Anhalt (FH)
Grundidee
•
Datenbanktechnologie ist Querschnittstechnologie der
Informatik; breite Anwendung
•
Ingenieurwesen
– CIM (Computer Integrated Manufacturing)
– PPS (ProduktionsPlanungsSysteme)
– CAD (Computer Aided Design): VLSI-Entwurf, Bau- und
Konstruktionspläne
– CASE (Computer Aided Software Engineering)
– GIS (Geographic Information Systems)
•
•
Biologie
Chemie
• Umwelttechnik
• ...
è Nicht-Standard-Anwendungen
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 2
Charakteristika
von Nicht-Standard-Anwendungen
•
komplexe Datenobjekte, oft mit hierarchischer Struktur
•
•
•
raumbezogen Anfragen auf Geometrie-Objekte
Anfragen bezogen auf Unterobjekte von komplexen Objekten
lange Transaktionen mit anderen Eigenschaften als ACIDTransaktionen
neue Datentypen (Bilder, große Textexemplare) mit
anwendungsspezifischen Operationen
•
DBS1 2004
OODBS
Seite 3
Klöditz
Hochschule Anhalt (FH)
Lösungsansätze
•
Einbau von oo Eigenschaften in relationale DBS führt zu objektrelationalen DBS
•
•
Einbindung in SQL: SQL3
Entwicklung experimenteller Prototypen
–
–
–
–
–
–
–
–
•
ORION von MCC
OPENOODB von Texas Instruments
IRIS von HP
ODE von AT&T
GEMSTONE
ONTOS
ARDENT
POET
Einsatz bisher vorwiegend innerhalb entsprechender z.B. CADSysteme oder GIS
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 4
Objektorientierte Konzepte (1)
•
Objekt
–
–
–
–
•
hat Zustand (Wert) und Verhalten (Operationen)
komplexe Datenstruktur
spezifische Operationen
kann in OODB persistent gespeichert werden und ist damit
mehrfach nutzbar (im Unterschied zu OOPL)
OODBMS
– realisieren (analog zu RDBMS) Indexierung,
Nebenläufigkeitskontrolle und Wiederanlauf
– besitzen Schnittstellen zu OOPL
– liefern (vom System generierten) Objekt-Identifikator (OID) zur
Sicherung der direkten Entsprechung von Realwelt und DB, der
Integrität und der leichten Identifizierbarkeit
DBS1 2004
OODBS
Seite 5
Klöditz
Hochschule Anhalt (FH)
Objektorientierte Konzepte (2)
•
Kapselung
– Instanzvariablen sind im Objekt gekapselt
– Zugriff nur über vordefinierte Operationen (wird in den meisten
Systemen unterlaufen)
– Operation besteht aus
• Signatur (Schnittstelle mit Operationsnamen und Parametern) und
• Methode (Rumpf mit der Implementierung der Operation)
•
Vererbung
– erlaubt Definition von Typen, die Teile der Struktur und der
Operationen von zuvor definierten Typen übernehmen
– vereinfacht die Entwicklung und gestattet Wiederverwendung
•
Darstellung von Beziehungen
– wegen vollst. Kapselung zunächst nur durch Methoden
beschreibbar
– jetzt (ODMG-Standard 2.0) durch Umkehrreferenzen (OID's
zusammenhängender Objekte im Objekt enthalten)
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 6
Objektorientierte Konzepte (3)
•
Versionsverwaltung
sollte unterstützt werden
•
Schema-Evolution
sollte möglich sein (analog ALTER TABLE)
Operator-Polymorphismus, Operator-Überladung
(gleiche Operationen für verschiedene Objekttypen;
Anpassung automatisch)
•
DBS1 2004
OODBS
Seite 7
Klöditz
Hochschule Anhalt (FH)
Objekt-Identität
•
durch OID garantiert
•
•
•
•
•
vom System generiert, für Nutzer nicht sichtbar
dient zur Identifizierung und Referenzierung
ist unveränderlich
wird auch nach Löschen des Objektes nicht wiederverwendet
sollte nicht von Objekt-Eigenschaften (änderbar) abhängen und
auch nicht die physische Adresse des Objektes sein (wird in
manchen OODBS so realisiert aus Performancegründen)
Realisierung meist über große int-Zahlen und Hash-Tabellen zur
Adressrechnung
•
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 8
Objekt-Struktur
•
Zustand (aktueller Wert) eines Objektes wird aus anderen
Objekten (oder Werten) mit Typkonstruktoren gebildet
•
Objekt wird dargestellt als (i, c, v)
– i = Objekt-Identifikator
– c = Typkonstruktor
– v = Objekt-Zustand (aktueller Wert)
•
•
Typkonstruktoren sind z.B. Atom, Tupel, Menge, Liste, Bag,
Array, ...
beliebige Verschachtelung zulässig
DBS1 2004
OODBS
Seite 9
Klöditz
Hochschule Anhalt (FH)
Beispiel: Objekt Abteilung
Atom
Tupel
o8
Menge
ANAME ABTNR MGR STANDORT ANGESTELLTE PROJEKTE
i 5:
Atom
v5
o5
i 4:
Atom
v4
o4
i 9:
Tupel
v9
o9
i 7:
Menge
v7
i 10 :
Menge
v10
o7
,
i 1:
Atom
v1
o1
Houston
MANAGER
i 2:
Atom
v2
Bellaire
o10
i 11 :
Menge
v11
,
o2
o11
,
i 3:
Atom
v3
o3
Sugarland
i 15 : ...
Tupel
,
,
i 16 : ...
Tupel
i 17 : ...
Tupel
,
MGR_ANFANGSDATUM
i 16 : ...
Tupel
i 12 :
Tupel
VNAME
Klöditz
Hochschule Anhalt (FH)
INITIAL
i 17 : ...
Tupel
o12
NNAME ...
...
ABT
DBS1 2004
OODBS
Seite 10
Objektbeschreibung Abteilung
o1 = (i1, Atom, 'Houston')
o2 = (i2, Atom, 'Bellaire')
o3 = (i3, Atom, 'Sugarland')
o4 = (i4, Atom, 5)
o5 = (i5, Atom, 'Research')
o6 = (i6, Atom, '1990-05-22')
o7 = (i7, Menge, {i1, i 2, i 3})
o8 = (i8, Tupel, <ANAME: i 5, ABTNUMMER: i 4 , STANDORT: i 7,
ANGESTELLTE: i 10 , PROJEKTE: i 11>)
o9 = (i9, Tupel, <MANAGER: i 12, MGR_ANFANGSDATUM: i 6>)
o10 = (i10, Mange, {i12 , i 13 , i 14})
o11 = (i11, Menge, {i15 , i 16 , i 17})
o12 = (i12, Tupel, <VNAME: i 18, INITIAL: i 19 , NNAME: i 20, ..., ABT: i 8>)
...
DBS1 2004
OODBS
Seite 11
Klöditz
Hochschule Anhalt (FH)
Definition von Objekt-Typen
•
•
•
define type Angestellter:
tuple (
vname:
initial:
nname:
...
abt:
define type Datum:
tuple (
jahr:
monat:
tag:
define type Abteilung
tuple
aname:
abtnummer:
mgr:
standort:
angestellte:
projekte:
•
string;
char;
string;
Abteilung;
);
integer;
integer;
integer;
);
string;
integer;
tuple ( manager:
Angestellter;
anfangsdatum: Datum; );
set (string);
set (Angestellter);
set (Projekt);
);
...
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 12
Kapselung
•
•
•
•
•
•
•
bei relationalen DBMS nicht üblich
Verhalten (Werte) hier ausschließlich durch objektbezogene
Operationen zugreifbar: löschen, hinzufügen, aktualisieren,
holen, Berechnungen ausführen, ...
Nutzer sieht nur Operationen-Schnittstelle:
Name und Parameter der Operation
oo Prinzipien zu starr; bei Datenbanken oft sichtbare und
verborgene Attribute; auf sichtbare kann mit OQL zugegriffen
werden
Aktualisierung i.d.R. verborgen; Integritätssicherung dort
eingebaut
Objekttyp-Definition dann zusammen mit den Operationen als
Klasse
häufige Operationen: Konstruktor, Destruktor, Modifier, Retrieval
DBS1 2004
OODBS
Seite 13
Klöditz
Hochschule Anhalt (FH)
Vererbung
•
Typhierarchien und Vererbung werden unterstützt
•
Beispiel:
Typ PERSON
Subtyp ANGESTELLTER
Subtyp STUDENT
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 14
ODMG, ODL, OQL
•
ODMG-Standard (1993, 1997)
–
–
–
–
•
Objekt-Modell
Objekt-Definitionssprache ODL
Objekt-Anfragesprache OQL
Bindings zu Programmiersprachen (C++, Smalltalk, Java)
Objekt-Modell besteht aus
– Objekten: OID, Name, Lebensdauer, Struktur
– Literalen: Wert ohne OID
•
ODL
– Klassendefinitionen
•
OQL
select d.dname
from d in departments
where d.college = 'Engineering';
DBS1 2004
OODBS
Seite 15
Klöditz
Hochschule Anhalt (FH)
Konzeptueller ODB-Entwurf
•
Unterschiede zum relationalen Datenmodell
– Behandlung von Beziehungen:
in ODB OID-Referenzen (auch als Sammlungen) in einer oder in
beiden Richtungen
– Abbildung von Vererbung:
in ODB direkt vorhanden, bei RDB analog Regel 8
– Definition von Operationen:
in ODB frühzeitig notwendig
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 16
Vom EER-Diagramm zum ODB-Schema
•
Aus jedem EER-Entitytyp oder jeder Subklasse wird eine ODLKlasse
•
Für jede binäre Beziehung werden Beziehungseigenschaften
oder Referenzattribute zu den ODL-Klassen hinzugefügt
Für jede Klasse werden entsprechende Operationen erstellt
Eine Subklassen-ODL-Klasse erbt Typ und Methoden der
Superklasse
Schwache Entity-Typen werden wie reguläre behandelt
Abbildung von Kategorien ist schwierig
•
•
•
•
DBS1 2004
OODBS
Seite 17
Klöditz
Hochschule Anhalt (FH)
Oracle
Objektrelationale Eigenschaften (1)
•
Definition von eigenen Datentypen (Objekttypen)
create type telnr_type
as object (telnr varchar(15));
•
Darstellung mehrwertiger Attribute als VARRAY
create type telefon_liste
as varray(5) of telnr_type;
create type kunden_type
as object (kname varchar(20),
telnummern telefon_liste);
create table kunde of kunden_type;
select kname, telnummern
from kunde;
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 18
Oracle
Objektrelationale Eigenschaften (2)
•
Verwendung verschachtelter Tabellen
– Attribute eines Objekts können selbst Objekte sein
create type telnr_type
as object (telnr varchar(15), beschreibung varchar(10));
create type telefon_liste
as table of telnr_type;
–
–
–
–
Definition von kunden_type und kunde bleiben unverändert
verschachtelte Tabellen haben variable Länge
auf die einzelnen Elemente kann zugegriffen werden
Indexe können erstellt werden
DBS1 2004
OODBS
Seite 19
Klöditz
Hochschule Anhalt (FH)
Oracle
Objektrelationale Eigenschaften (3)
•
Objekt-Views
•
Verwaltung großer Objekte
– erzeugen virtuelle Objekte in einer sonst relationalen Datenbank
–
–
–
–
BLOB: Binary Large Object
CLOB: Character large Object
BFILE: außerhalb der datenbank gespeichertes Binary File
NCLOB: MultiByte-CLOB mit fester Breite
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 20
SQL3
•
Standard besteht aus
–
–
–
–
SQL/Framework, SQL/Foundation, SQL/Bindings, SQL/Object
neue Teile bezüglich zeitlicher Transaktionsaspekte von SQL
SQL Call Level Interface (CLI)
SQL Persistent Stored Modules (PSM)
DBS1 2004
OODBS
Seite 21
Klöditz
Hochschule Anhalt (FH)
SQL3 (2)
•
SQL/Foundation
–
–
–
–
–
–
–
–
•
neue Datentypen
neue Prädikate
relationale Operationen
Cursor
Regeln, Trigger
benutzerdefinierte Typen
Transaktionsfähigkeiten
stored procedures
SQL/CLI
– Regeln für die Ausführung von Anwendungscode
– neue Art der Sprachbindung (dynamisches SQL)
– etwa 50 Routinen z.B. für Verbindungsaufbau,Zuweisung und
Freigabe von Ressourcen, Kontrollmechanismen zur Beendigung
von Transaktionen, ... (analog ODBC-Standard)
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 22
SQL3 (3)
•
SQL/PSM
– spezifiziert Möglichkeiten zur Aufgabenteilung zwischen Client und
Server
•
SQL/Bindings
– embedded SQL erweitert um zusätzliche Ausnahmesituationen
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 23
Neue Operationen und Konzepte in SQL3
•
neue Operationstypen
– SIMILAR für die Verarbeitung regulärer Ausdrücke zur
Zeichenkettenbearbeitung
– UNKNOWN erweitert Boolesche werte bei vergleichen
– lineare Rekursion für rekursive Anfragen
•
neue Konzepte
– Rolle: bestimmt die Autorisierung von Rechten
– Trigger: aktive Regeln für INSERT, DELETE und UPDATE zu
BEFORE oder AFTER
– Trigger-Granularität: auf Zeilen- oder Anweisungsebene
– Programmiersprachen-Werkzeug: SQL-Routinen
• CALL / RETURN
• BEGIN / END
• FOR / END_FOR, LOOP / END_LOOP, WHILE / END_WHILE,
REPEAT / UNTIL / END_REPEAT
• CASE / END_CASE, IF / THEN / ELSE / END_IF
•
integrierte Funktionen
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 24
Objektrelationale Unterstützung von SQL3
•
neue Datentypen:
– Boolesche Zeichen
– große binäre Objekte (LOB), Object-Locator
•
Objekte:
–
–
–
–
–
–
benutzerdefinierte Datentypen
Typkonstruktoren
Kollektionstypen
benutzerdefinierte Funktionen und Prozeduren
Unterstützung großer Objekte
Trigger
DBS1 2004
OODBS
Seite 25
Klöditz
Hochschule Anhalt (FH)
Objektrelationale Unterstützung von SQL3 (2)
Objekt-Typen: Row- / Tupel-Typen
create row type emp _row _type (
name varchar(30),
hiredate date
);
create row type comp_row_type (
compname varchar (20),
location varchar (20)
);
create table employee of type emp _row_type;
create table company of type comp _row_type;
create row type employment _row_type (
employee ref (emp_row _type ),
company ref (comp_row _type )
);
create table employment of type employment_row_type;
select employment..employee..name
from employment
where employment ..company..location = 'New York';
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 26
Objektrelationale Unterstützung von SQL3 (3)
Objekt-Typen: Abstrakte Datentypen (ADT)
create type <type-name> (
Komponentenattribute mit den einzelnen Typen
Deklaration der Funktionen EQAL und LESS THAN
Deklaration weiterer Funktionen (Methoden)
);
•
•
•
•
Konstruktor-, Observer- und Mutator-Funktionen
Typ-Äquivalenz wird auf Namens- und auf Strukturebene
definiert
Attribut-Kategorien: public, private, protected
Vererbung, Überladen sind geregelt
DBS1 2004
OODBS
Seite 27
Klöditz
Hochschule Anhalt (FH)
Kritik an OODBMS
[DATE 2000]
•
•
•
•
•
•
•
keine wohldefinierte einheitliche Theorie, terminologische
Verwirrung; Kompatibilität ist ein echtes Problem
keine formalen Datenbank-Entwurfsmethoden wie z.B.
Normalisierung; Ergebnis sind ineffiziente Systeme
keine einfachen Abfragemöglichkeiten; Zugriff nur über
vordefinierte Methoden
keine allgemeinen Integritätsregeln, nur über Methoden
(abhängig von DB-Entwicklern)
navigierende Abfragen
Verwaltung von Objektidentitäten, keine einheitliche
Interpretation, hoher Aufwand
z.T. durch ODMG-Standards und UML beseitigt, allerdings
bisher nicht vollständig umgesetzt
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
OODBS
Seite 28