Objektrelationale Datenbanken
Erweiterung von relationalen
Datenbanksystemen mit OO Features
Objekte und Datenbanken
• Neue Anwendungen und neue Arten von Daten
– Text, Audio / Video, Landkarten – Hierarchien (Land, Region, Stadt) – Sensordaten, Messreihen
• Komplexe Funktionen
– Graustufenanlayse, FFT, Wegplanung, ...
• Unterschiedliche Arten von Daten und Funktionen sollten in einer Anfrage nutzbar sein:
Wieviele Landkarten zeigen den Weg von M nach PA
• Mächtigeres Modell, Erweiterbare Datenbanken
Nachteile Relationaler Datenbanken
• Jeder Polyeder besteht aus mindestens vier Flächen
• Jede Fläche hat mindestens drei Kanten
• Jede Kante berührt mindestens drei Eckpunkte
• Frage: Wie rotiert man einen Würfel?
f6 w1
...
w1
f1 w1
fid pid
...
...
...
...
...
p3 p2
f2 f1
k2
p4 p1
f4 f1
k1
PB PA
FlB FlA
kid
Flächen Kanten
1.0 1.0
0.0 p8
...
...
...
...
0.0 0.0
1.0 p2
0.0 0.0
0.0 p1
Z Y
X pid
Punkte
Nachteile Relationaler Datenbanken
• Struktur eines Polyeders steckt nur implizit in der DB
• Operationen wie „Rotation“ sind schwer zu programmieren.
Man muss die einzelnen Punkte ändern.
• Eine Ausführung solcher Operationen ist sehr ineffezient:
– Join zwischen (mindestens) drei Tabellen – Acht verschiedene Update Operationen
• Lösung:
– Erlaube die Definition komplexer Objekte in der Datenbasis – Speichere die Definition von Operationen in der Datenbasis
Objektorientierte Datenbanken
• Forschung seit 1984; viele schöne Ergebnisse
• Erste Produkte seit Ende der achtziger Jahre (Versant, GemStone, ObjectStore, O2, Poet)
• ODMG Standard 2.0: Cattell 1997
• Anwendungen: CAD, einige andere Nischen
• Kein großer kommerzieller Erfolg
Probleme: nicht robust genug, skalieren nicht, schlecht bei Anfragen, nur gut bei „Navigation“
• Literatur: Kemper, Moerkotte 1994
Objektrelationale Datenbanken
• Laguna Beach Report 1990 (Stonebraker et al.)
• Erste Produkte seit ca. 1997
Informix Universal Server, Oracle 8i, IBM UDB
• Versuch, Mächtigkeit von OO Datenbanken mit Robustheit von relationalen Datenbanken zu
kombinieren
• Inkrementeller Ansatz, Einbau von OO Features in bestehende relationale Datenbankprodukte
• Standard: SQL 99 (aktuell), noch nicht alles drin
• Literatur: Chamberlin 96, Using the New DB2
Objektrelationale Datenbanken
• Large Objects
• Benutzerdefinierte Typen
• Objektidentität, Objektreferenzen
• Mengenwertige Attribute (Kollektionstypen)
• Vererbung
• Benutzerdefinierte Funktionen
• ADTs (Data Blades, Extenders, Cartridges)
Hinweis: Wir verwenden die IBM UDB Konventionen
Large Objects
• „varchars“ können max. 4096 Bytes groß werden
• Für größere Felder (z.B. Videos) stellt IBM sogenannte Blobs zur Verfügung
• Einstellungen: Komprimierung, TA-Verwaltung
CREATE TABLE personalWebPage(
url varchar(100),
picture blob(100K) NOT LOGGED COMPACT, html clob(20K) NOT LOGGED COMPACT
);
Arbeiten mit Blobs
• Es gibt wesentliche Einschränkungen
– Keine Indexe
– Keine Vergleichsoperationen: like, <, ...
– Kein „distinct“, „group by“ oder „max“
• Die eigentlichen Daten kann man in einer separaten Datei speichern und bearbeiten. In diesem Fall
wird nur ein Locator in der Datenbank gespeichert
• Mit Locators kann man auch in
Anwendungsprogrammen arbeiten
• Interessant werden Blobs nur mit anderen Features
Distinct Types
• Einfachste Form eines benutzerdefinierten Typs
• Dient dazu eine „strenge“ Typisierung zu erzielen
• Explizite Casts zum Basistyp und zurück werden aber unterstützt
CREATE DISTINCT TYPE dollar AS DECIMAL(9,2);
CREATE DISTINCT TYPE euro AS DECIMAL(9,2);
CREATE TABLE product(
name varchar(100), USAsales dollar, Esales euro);
Distinct Types
• Folgende Queries sind zunächst illegal
(mit benutzerdefinierten Funktionen kann man sich aber elegant behelfen)
SELECT *
FROM product
WHERE Esales > USAsales;
SELECT name, sum(Esales + USAsales) FROM product
GROUP BY name;
Komplexe Typen
• Beliebige Strukturen sind vorstellbar (ähnliche zu „struct“ in C)
• Können in einer Tabelle als Spaltentyp auftreten
CREATE TYPE emp(
name varchar(30), salary euro,
picture blob(100K))
CREATE TYPE manager(
name varchar(30), history clob(100K), salary dollar)
CREATE TABLE project(
leiter manager,
schriftführer emp)
Anfragen mit komplexen Typen
• Konstruktoren und Zugriffsfunktionen werden implizit vom System erzeugt
INSERT INTO project(leiter, schriftführer)
VALUES( manager(„Lisa“, [], dollar(30000), emp(„Heini“, euro(20000), []));
SELECT *
FROM project p
WHERE p.leiter.name like „%isa%“;
Row Types
• Komplexer Typ für eine Zeile einer Tabelle
• Witz: Kombination mit „Reference Types“
CREATE ROW TYPE manager(name varchar(100));
CREATE ROW TYPE emp(
name varchar(100), boss REF(manager));
CREATE TABLE mantable;
CREATE TABLE emptable(
PRIMARY KEY name,
SCOPE FOR boss IS mantable);
Objektidentität, Referenzen
• Nur „top-level“ Tupel (also Instanzen von Row Types) haben eine Identität
• Die Identität ist unabhängig vom Wert des Tupels (anders als Fremdschlüsselkonzept!)
• In der Regel wird die Implementierung von
Referenzen und Objektidentifikatoren vom System implizit durchgeführt.
• Referenzen können einen „scope“ haben (getypt) (Wenn möglich, sollte man das immer machen)
• Verfolgung von Referenzen durch Pfadausdrücke
Pfadausdrücke
• Nur bei getypte Referenzen kann die
Autorisierung zur Übersetzungszeit durchgeführt werden.
SELECT e.boss->address.city FROM emptable e
WHERE e.boss->name like „%isa%“;
Mengenwertige Attribute
• Zusätzlicher Konstruktor für Kollektionen
• Wird von IBM noch nicht unterstützt.)
• Oracle 8i unterstützt z.B. „VARRAY“
• (Reines) ODMG unterstützt Mengen, Bags und Listen
CREATE TYPE dept(
name varchar(100), mitarbeiter {emp});
SELECT d.name, (SELECT * FROM emp e
WHERE e.works_in = d.name) FROM deptTable;
Vererbung
• Ein Row Type kann von einem oder mehreren Row Types abgeleitet werden
• Dabei erbt ein Typ alle Attribute des Obertyps
• Substituierbarkeit bei Referenzen ist gegeben
CREATE ROW TYPE emp(name, salary);
CREATE ROW TYPE manager UNDER emp(bonus);
CREATE TABLE emptable OF emp;
CREATE TABLE mantable OF manager UNDER emptable;
Bemerkung
• Row Types sind ein Artifact von OR-Systemen.
• (Reine) objektorientierte Modelle sind einfacher:
– Es gibt nur eine Form von Komplexen Typen
– Es können beliebig Instanzen (Objekte) erzeugt werden – Die Menge aller Instanzen eines Types wird Klasse
genannt (Analogon zur Tabelle)
• Wieso geht SQL hier diesen Weg???
Funktionen
Es gibt drei Arten von Funktionen
• Built-in: z.B. +, <, avg, max, IS NULL, ...
• System-generated:
– Z.B. CAST-Funktionen für Distinct Types
• User-defined:
– Sourced scalar functions
– Externale scalar functions, Methoden – Table functions
Sourced Functions
• Wird vorwiegend für distinct types verwendet
• Definition beruht auf einer anderen Funktion (built-in, system-generated oder user-defined)
CREATE FUNCTION +(money, money) RETURNS money SOURCE + (DECIMAL(), DECIMAL())
CREATE FUNCTION sum(money) RETURNS money SOURCE sum(DECIMAL())
Sourced Functions
CREATE DISTINCT TYPE money as DECIMAL(9,2);
CREATE TABLE emp(
name varchar(100), salary money,
bonus money );
SELECT sum(salary + bonus) FROM emp;
External Scalar Functions
• Sehr nützlich, um etwas komplexere
Berechnungen durchzuführen, für die SQL nicht geeignet ist
• Werden bei IBM DB2 in C, Java, OLE formuliert
• Liefern als Ergebnis einen skalaren Wert; dies kann allerdings auch ein Wert eines UDT sein
• Vom Server ausgeführt für gute Performance
• Viele kleine Besonderheiten zu beachten
• Kann von allen Benutzern derselben DB in Anfragen verwendet werden
External Scalar Functions
CREATE FUNCTION deltaTage(date, date) RETURNS Integer EXTERNAL NAME „/home/kossmann/deltaTage.o“
LANGUAGE C DETERMINISTIC
FENCED ... <weitere Optionen>
PARAMETER STYLE DB2SQL NO SQL;
Bestimme Aufträge mit mehr als 10 Tagen Lieferverzug
SELECT * FROM order
WHERE deltaTage(o.promisedShipDate, CURRENTDATE) > 10;
Besonderheiten
• Deterministic oder External Action (z.B. eMail) Dies kann den Optimierer beeinflussen.
• Fenced / Unfenced Läuft die Funktion im selben Adressraum wie das Datenbanksystem
• NULL call Was passiert, wenn ein Nullwert als Parameter übergeben wird
• Typkompatiblität Es gelten die üblichen Regeln;
z.B. smallint -> int
• Scratchpad Bewahre Zustand zwischen zwei
Aufrufen (z.B. seed eines Zufallsgenerators). Hat evtl. Auswirkungen auf parallele Ausführungen!
Implementierung der C Funktion
SQL_API_FN deltaTage(
char * date1In, /* erstes Datum */
char * date2In, /* zweites Datum */
int * out, /* Ergebnis */
short * nullDate1In, /* ist NULL? */
short * nullDate2In, /* ist NULL? */
short * nullOut, /* Ergebnis = null? */
char * sqlState, /* Fehlercode */
char * message /* Fehlermedlung */) { ...
}
Methoden
• Besondere skalare Funktionen, die als Parameter eine Referenz eines Row Types bekommen und somit „vererbt“ werden können
• Im Grunde aber etwas „misslich“
CREATE FUNCTION raise (r REF(emp)) RETURNS euro
LANGUAGE SQL RETURN
CASE r->status
WHEN EXEMPT THEN r->salary * 1.2 ELSE r->salary * 1.1
END;
Table Functions
• Besondere externe Funktionen, deren Ergebnis eine Tabelle ist
• Können somit in der FROM Klausel von SQL Anfragen oder in Subanfragen verwendet werden
• Implementierung: eine C Funktion, die mit jedem Aufruf ein neues Tupel liefert.
• Sehr nützlich, um Daten die außerhalb des DBMS liegen, zu integrieren (z.B. Daten von Webseiten)
• Mechanismen und Deklarationen (fast) genauso wie bei „External Skalar Functions.“
Table Functions
CREATE FUNCTION searchWeb(varchar(100)) RETURNS TABLE(url varchar(100),
score Integer,
country varchar(50)) EXTERNAL NAME „altavista.o“
...
Funktion, die nach Webpages zu einem bestimmten Suchbegriff sucht. (Z.B. durch Aufruf einer
Suchmaschine wie AltaVista, Yahoo oder so.)
Table Functions
Suche alle deutschen Webpages zum Thema „Köln“
SELECT w.url,
FROM TABLE(searchWeb(„Köln“)) w WHERE w.country = „Germany“
Table Functions
Suche Webpages zum Wohnort von Studenten?
Geht das so???
SELECT s.name, w.url,
FROM Student s, TABLE(searchWeb(s.city)) w;
SELECT s.name, (SELECT w.url
FROM TABLE(searchWeb(s.city)) w) FROM Student s;
Stored Procedures
• Stored Procedures sind ein Mechanismus, um
Anwendungsprogramme auf dem Datenbankserver zu registrieren.
• Idee: Man spart sich Overhead, wenn das
Anwendungsprogramm viele kleine Aufrufe an das Datenbanksystem hat und wenig Eingaben von
einem Benutzer erwartet.
• VORSICHT: Das ist kein besonderes OR Feature.
Hier geht es „nur“ um Performance.
Data Blades, Extenders, ...
• Schnittstelle im Datenbankkern zur „first-class“
Unterstützung neuer Datentypen und besonderer Zugriffsfunktionen
• Bild: Ein Datenbanksystem ist ein Bündel von
Steckplätzen für Data Blades. „Tabelle“ ist quasi nur ein Beispiel eines Data Blades.
• Beispiele: Landkarten, Zeitreihen, ...
• Wichtig: es können auch innerhalb des Data Blades auch Indexe bereitgestellt werden
• Business: Data Blades auch von Drittanbietern
Fazit
• Trend: Die Datenbankhersteller bauen OO Features in ihre Systeme ein.
• Es gibt noch keine hinreichenden Standards
– SQL 99 hat noch Lücken – SQL 3 ist noch nicht fertig – ODMG ist quasi tot
• Selbst wenn es einen Standard geben wird, wird es Jahre dauern, bis die Systeme ihn
implementiert haben. Es ist auch fraglich, ob sich alle daran halten werden: IBM und Oracle gehen bereits eigene Wege. Microsoft macht gar nichts.
