Objektrelationale Datenbanken
Werbung
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?
Flächen
pid fid
w1 f1
w1 ...
w1 f6
Kanten
kid FlA FlB
k1 f1 f4
k2 f1 f2
... ... ...
PA
p1
p2
...
PB
p4
p3
...
Punkte
pid X Y
p1 0.0 0.0
p2 1.0 0.0
... ... ...
p8 0.0 1.0
Z
0.0
0.0
...
1.0
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
SELECT e.boss->address.city
FROM emptable e
WHERE e.boss->name like „%isa%“;
• Nur bei getypte Referenzen kann die
Autorisierung zur Übersetzungszeit durchgeführt
werden.
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
Funktion, die nach Webpages zu einem bestimmten
Suchbegriff sucht. (Z.B. durch Aufruf einer
Suchmaschine wie AltaVista, Yahoo oder so.)
CREATE FUNCTION searchWeb(varchar(100))
RETURNS TABLE(url varchar(100),
score Integer,
country varchar(50))
EXTERNAL NAME „altavista.o“
...
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.
