3. Erweiterbarkeit von Datenbanksystemen

3. Erweiterbarkeit von Datenbanksystemen
Allgemeine Aspekte der Erweiterbarkeit
3. Erweiterbarkeit von Datenbanksystemen
• Kritik an traditionellen DB-Systemen: Armut an Datentypen und Funktionen
• Datenbankanwendungen verlangen in zunehmendem Maße nach der M öglichkeit
des Speicherns und Verarbeitens von Objekten, die
– sehr groß sind (Texte, Bilder, Videos) oder
– ein komplexes Verhalten haben (Komponenten im Entwurf).
• Die hierzu notwendigen Konzepte sind nicht im voraus absehbar und schwierig in
ein einheitliches Datenmodell integrierbar.
☞ Erweiterbare Datenbanksysteme bieten die Möglichkeit, spezifische zusätzliche
Datentypen mit zugehörigen Funktionen in ein DB-System zu integrieren.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
53
3. Erweiterbarkeit von Datenbanksystemen
Allgemeine Aspekte der Erweiterbarkeit
• Die traditionellen Vorteile relationaler Systeme sind nicht inkompatibel mit einem
reichhaltigen und erweiterbarem System von Datentypen und Funktionen.
• Objektrelationale Systeme kombinieren
– deklarative Anfragesprachen wie SQL und multiple Sichten auf die Daten mit
– der Fähigkeit, neue Datentypen und Funktionen zum Speichern und Manipulieren von Objekten zu definieren.
☞ In objektrelationalen DB-Systemen wird mehr von der Semantik der gespeicherten
Daten erfaßt.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
54
3. Erweiterbarkeit von Datenbanksystemen
Allgemeine Aspekte der Erweiterbarkeit
Ebenen der Erweiterbarkeit
Neue Typen und Funktionen sollen auf jeder Ebene unterstützt werden k önnen:
•
•
•
•
Von der Bereitstellung neuer Typen auf der konzeptuellen Ebene
über die Integration zugehöriger Funktionen in SQL (externe Ebene)
über die Bereitstellung spezieller Speicherstrukturen
bis zur Optimierung von Zugriffen (interne Ebene).
Beispiel: Datentyp zur Repräsentation von Polygonen
• Auf der konzeptuellen Ebene muß der Datentyp definierbar sein, so daß er z.B. als
Attributstyp in einer Relation verwendbar ist.
• Funktionen bzw. Prädikate für Polygone (z.B. “Punkt liegt in Polygon”) müssen definierbar und in SQL integrierbar sein, so daß sie für Anfragen nutzbar sind.
• Spezielle Speicher- und Zugriffsstrukturen müssen die effiziente Auswertung einer
Funktion wie “Punkt liegt in Polygon” unterstützen.
☞ Die Erweiterbarkeit der internen Ebene ist der schwierigste Teil.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
55
3. Erweiterbarkeit von Datenbanksystemen
Allgemeine Aspekte der Erweiterbarkeit
Wir betrachten zunächst die Erweiterung auf konzeptioneller und externer Ebene:
☞ Benutzerdefinierte Funktionen
☞ Benutzerdefinierte Aggregatfunktionen
☞ Tabellenfunktionen
☞ Benutzerdefinierte Typen
Im nächsten Kapitel werden wir die Voraussetzungen für die Erweiterbarkeit auf der
internen Ebene kennenlernen.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
56
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Benutzerdefinierte Funktionen (UDF)
Hierbei handelt es sich um Funktionen,
• die vom Benutzer erzeugt und
• unter Verwendung einer speziellen Anweisung (create function) in eine Datenbank integriert werden.
• Für die Programmierung von UDFs wird üblicherweise C eingesetzt.
• Die UDFs erweitern den Vorrat an SQL-Funktionen.
• Es kann sich hierbei um eine skalare Funktion, eine Aggregatsfunktion oder eine
Tabellenfunktion handeln.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
57
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Integration von benutzerdefinierten Funktionen in eine DB:
DBS−Kern
Aufruf
Funktions−API
Built−In Funktionen
Benutzerdef. Funkt.
dynamisches Binden
Deklaration der
Funktion
Dyn. Bibliothek
Compilierung/
Erzeugung dyn. Bibliothek
Create Function Anw.
C Quelle
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
58
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Die Integration besteht aus zwei Schritten:
1. Implementierung
Auf Basis eines standardisierten APIs wird eine C-Funktion erstellt, übersetzt und
in einer dynamischen Bibliothek (shared object) abgelegt.
2. Deklaration
Mit Hilfe einer create function Anweisung wird die UDF dem Datenbanksystem bekannt gemacht. Hierdurch steht eine entsprechende SQL-Funktion zur
Verfügung.
Bei erstmaliger Benutzung der UDF/SQL-Funktion wird die dynamische Bibliothek
an den DB-Kern gebunden und die betreffende C-Funktion aufgerufen.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
59
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
UDF-Implementierung für skalare Funktionen
In DB2 gelten folgende Konventionen für eine C-Funktion, die als Implementierung
einer skalaren UDF dienen soll:
void funcname( TYP1 * in1, TYP2 * in2, ... ,
/* IN, N-fach */
TYP * returnValue,
/* OUT */
short * ind1, short * ind2, ... , /* IN, N-fach */
short * null indicator,
/* OUT */
char * sqlstate,
/* OUT */
char * funcName,
/* IN */
char * specName,
/* IN */
char * message
/* OUT */
);
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
60
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Erläuterungen zu den Parametern:
1. Die ersten N Parameter der C-Funktion entsprechen den N Parametern der zugehörigen SQL-Funktion. Die Werte sind in entsprechende C-Typen konvertiert.
Es werden grundsätzlich Zeiger übergeben.
2. Zeiger auf den Rückgabewert
3. Indikatorvariablen für die N Eingabeparameter
4. Indikatorvariable für den Rückgabewert
5. char[6], null-terminiert, zur Rückgabe von SQLSTATE, ist initialisiert mit
"00000\0".
6. Voller qualifizierter Name der aufgerufenen SQL-Funktion. Dies macht es m öglich,
daß mehrere UDFs durch die gleiche C-Funktion implementiert werden.
7. spezifischer Name zur Unterscheidung bei der Überladung von Funktionsnamen;
macht es ebenfalls möglich, daß mehrere UDFs durch die gleiche C-Funktion implementiert werden.
8. char[70], null-terminiert zur Übergabe einer Fehlermeldung an die SQLCA (Feld
sqlerrmc).
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
61
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Zuordnung zwischen SQL- und C-Datentypen für UDFs (DB2):
SQL-Datentyp
Smallint
Integer
Decimal(p,s)
Real
Double
Char(n)
Varchar(n)
Date
Time
Timestamp
Blob(n), Clob(n)
Lokator für Blob, Clob
C-Datentyp
short
long
—
float
double
char[n+1], null-terminiert
char[n+1], null-termiert
char[11], null-terminiert, yyyy-mm-dd
char[9], null-terminiert, hh.mm.ss
char[27], null-terminiert, yyyy-mm-dd-hh.mm.ss.nnnnnn
struct { unsigned long length; char data[n]; }
unsigned long
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
62
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Beispiel: UDF in DB2 zur Berechnung des Quadrats einer Zahl, siehe auch HomePage (Datei square.c).
#include <sqlsystm.h>
void SQL_API_FN square( long * in, long * retval,
short * indicator, short * retind,
char * sqlstate, char * fnname,
char * specname, char * message )
{
*retval = *in * *in;
}
Erzeugung der dynamischen Bibliothek:
gcc -c -fpic -I/usr/IBMdb2/V7.1/include square.c
gcc -shared -o square.so square.o
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
63
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
PostgreSQL:
#include <postgres.h>
#include <fmgr.h>
PG_FUNCTION_INFO_V1( square );
Datum square( PG_FUNCTION_ARGS )
{
int x = PG_GETARG_INT32( 0 );
int rc = x * x;
PG_RETURN_INT32( rc );
}
Erzeugung der dynamischen Bibliothek:
$ gcc -c -fpic -I/usr/local/src/postgresql-7.2.1/src/include/ square.c
$ gcc -shared -o square.so square.o
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
64
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
UDF-Deklaration (skalar)
Typischerweise werden die folgenden Dinge für eine skalare UDF in deren Deklaration
festgelegt:
• Name und Signatur
• Typ des Rückgabewertes
• Externer Name, d.h. Pfad der dynamischen Bibliothek und Funktionsname
• Implementierungssprache
• Behandlung von Null-Werten
Ist das Ergebnis null falls einer der Parameter den Wert null hat?
• abgeschirmte Ausführung
Soll die Ausführung der Funktion im gleichen Adressraum wie der Datenbankprozess stattfinden?
• deterministische Ausführung
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
65
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Ist garantiert, ob die Funktion bei identischen Parameterwerten identische Ergebnisse liefert?
• weitere Dinge sind DBS-spezifisch
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
66
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Deklaration der UDF square in DB2:
create function square( double )
returns double
external name ’square.so!square’
deterministic
no external action
not fenced
not null call
language c
no sql
parameter style db2sql
allow parallel;
--------------
Name und Signatur
Typ Rueckgabe
Externer Name
Resultat ist funktional
abhaengig von den Parametern
keine Interaktion
mit der Aussenwelt
keine abgeschirmte Ausfuehrung
kein Aufruf wenn Parameter null
verwendete Implementierungssprache
in DB2 obligatorisch
obligatorisch fuer UDFs in C
parallele Ausfuehrung moeglich
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
67
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Deklaration der UDF square in PostgreSQL:
create function square( real )
returns real
as ’/home2/pbecke2m/postgres/square/square.so’, ’square’
language ’c’
with ( isstrict, iscachable );
Beispiel: Nutzung der UDF square:
SELECT id2, square( b_length )
FROM
wfb.countries
WHERE id1 = ’GM’
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
68
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Funktionsresolution
• Der Name der UDF kann ein Schema enthalten. Ebenso kann beim Aufruf ein
Schemaname angegeben werden (qualifizierter Funktionsname).
• Nachteile der Verwendung qualifizierter Funktionsnamen:
– lang, umständlich
– Anwendungen sollten nicht von einem speziellen Schema, in dem die Funktionen liegen, abhängig sein.
• Fehlt der Schemanamen, dann werden die Schemata des sogenannten Funktionspfades nach einer anwendbaren Funktionen durchsucht.
• Vorbelegung des Funktionspfades: SYSIBM, SYSFUN, USER
• Änderung: SET CURRENT FUNCTION PATH
• Eine Funktion ist auf einen gegebenen Aufruf anwendbar, falls:
– der Funktionsname mit dem im Aufruf genannten übereinstimmt und
– die Argumente des Aufrufs in die Parameter dieser Funktion propagierbar sind.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
69
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
• Propagierbar bedeutet, daß
– der Datentyp jedes Funktionsparameters entweder mit dem Datentyp des entsprechenden Aufrufsarguments übereinstimmt oder
– die Aufrufargumente entlang von Konversionspfaden in die Typen der Funktionsparameter umgewandelt werden können.
• Wichtige Konversionspfade:
– Smallint → Integer → Decimal → Real → Double
– Char → Varchar → Long → Varchar → Clob
• Die Datentypen Blob, Date, Time und Timestamp erfordern eine exakte Übereinstimmung.
• Länge, Genauigkeit sowie Anzahl von Nachkommastellen werden bei der Überprüfung der Anwendbarkeit ignoriert, für die Anwendung der Funktion findet aber
eine Konversion statt.
• Auf dem Funktionspfad können sich nun mehrere anwendbare Funktion befinden.
• Die Funktionsresolution sorgt für die Auswahl einer möglichst “guten” Funktion.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
70
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Ablauf der Funktionsresolution:
1. Zunächst wird die Menge aller anwendbaren Funktionen bestimmt.
2. Betrachte die Argumente des Aufrufs von links nach rechts. Für jedes Argument
werden die Funktionen eliminiert, die in bezug auf den Konversionspfad nicht die
“beste verfügbare” Übereinstimmung liefern.
3. Bleibt mehr als eine Funktion übrig, wird die Funktion aus dem Schema genommen, das zuerst im Funktionspfad auftritt.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
71
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Beispiel und Übung zu UDFs
☞ Erweiterung einer Datenbank um Funktionen für approximatives String-Matching
(fuzzy matching)
Definition:
• Für zwei Strings x und y ist die Editierdistanz (Edit Distance) edit(x, y) definiert
als die kleinste Anzahl an Einfüge- und Löschoperationen, die notwendig sind, um
x in y zu überführen.
• Läßt man zusätzlich auch die Ersetzung eines Symbols zu, so spricht man von
einer Levenstein-Metrik (Levenshtein Distance) lev(x, y).
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
72
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Beispiel: Für x = abcabba und y = cbabac gilt:
edit(x, y) = 5
abcabba −→ bcabba −→ cabba −→ cbba −→ cbaba −→ cbabac
lev(x, y) = 4
abcabba −→ cbcabba −→ cbabba −→ cbaba −→ cbabac
☞ Lösungsansatz zur Berechnung: dynamische Programmierung
☞ genauer: berechne die Distanz der Teilstrings x[1 . . . i] und y[1 . . . j] auf der Basis bereits berechneter Distanzen.
Im folgenden sei m = |x| und n = |y| und es gelte m ≤ n.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
73
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Die Tabelle LEV sei definiert durch:
LEV [i, j] := lev(x[1 . . . i], y[1 . . . j]) mit 0 ≤ i ≤ m, 0 ≤ j ≤ n
Die Werte für LEV [i, j] können mit Hilfe der folgenden Rekursionsformeln berechnet
werden:
• LEV [0, j] = j für 0 ≤ j ≤ n, LEV [i, 0] = i für 0 ≤ i ≤ m
• LEV [i, j] = min{ LEV [i − 1, j] + 1,
LEV [i, j − 1] + 1,
LEV [i − 1, j − 1] + δ(x[i], y[j])}

0 falls a = b
• δ(a, b) =
1 sonst
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
74
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Beispiel: Darstellung von LEV als Matrix für x = cbabac und y = abcabbbaa:
c
b
a
b
a
c
0
1
2
3
4
5
6
a
b
c
a
b
b
b
a
a
1
1
2
2
3
4
5
2
2
1
2
2
3
4
3
2
2
2
3
3
3
4
3
3
2
3
3
4
5
4
3
3
2
3
4
6
5
4
4
3
3
4
7
6
5
5
4
4
4
8
7
6
5
5
4
5
9
8
7
6
6
5
5
Die zugehörigen Umwandlungen lauten:
cbabac −→ ababac −→ abcabac −→ abcabbac −→ abcabbbac −→ abcabbbaa
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
75
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Funktionen
Beachtenswerte Punkte bei UDFs
☞ Die UDF sollte reentrant sein, d.h. es sollten keine statischen Variablen benutzt
werden. So wird gewährleistet, daß die UDF gleichzeitig von verschiedenen Applikationen benutzt werden kann.
☞ Falls die UDF dynamisch Speicher allokiert, sollte dieser vor dem Ausstieg freigegeben werden. Ausnahme: Scratchpad-Funktionen, später mehr
☞ Niemals exit() für die Beendigung der UDF verwenden!
☞ Auch kein printf() oder scanf()!
☞ Für Implementierungen in C++ extern "C" als Teil der Funktionsdeklaration angeben.
☞ Beim Debugging einer UDF kann eine Datei auf dem Server für die Protokollierung
verwendet werden.
Hierbei muß auf die Zugriffsrechte geachtet werden, denn der Server-Prozeß l äuft
nicht unter der eigenen Benutzerkennung.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
76
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
Tabellenfunktionen
• Eine Tabellenfunktion ist eine UDF, die eine Tabelle statt eines skalaren Wertes als
Ergebnis liefert.
• Tabellenfunktionen dienen dazu, Daten, die ausserhalb der Datenbank liegen, in
relationaler Form zur Verfügung zu stellen.
• Durch die Bereitstellung einer Tabellenfunktionen können solche Daten mit Daten
innerhalb einer Datenbank verknüpft und mittels SQL analysiert werden.
• Damit läßt sich die Ausdruckskraft von SQL auf Daten aus ganz unterschiedlichen
Quellen anwenden.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
77
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
Nutzung von Tabellenfunktionen in SQL:
• Tabellenfunktion werden in der FROM-Klausel einer SQL-Anfrage verwendet.
• Die Syntax lautet:
FROM TABLE( tabfunktion( para1, ... ) ) AS tabellenname
• Damit wird durch tabellenname die Ergebnisrelation des Aufrufs der Tabellenfunktion tabfunktion mit den angegebenen Parametern referenziert.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
78
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
• Beispiel: Die UDF passwd() sei eine Tabellenfunktion, die Informationen über die
Benutzer eines Rechnersystems bereitstellt (siehe /etc/passwd).
Informationen über den DB2-Instance Benutzer könnten dann mit der folgenden
SQL-Anfrage ermittelt werden:
SELECT *
FROM TABLE( passwd() ) AS passwd
WHERE name = ’db2inst1’
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
79
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
Deklaration von Tabellenfunktionen
Zur Deklaration einer Tabellenfunktion wird eine create function-Anweisung benutzt,
die sich aber in den folgenden Punkten zu der Deklaration von skalaren Funktionen
unterscheidet:
1. Die RETURNS-Klausel enthält das Schlüsselwort TABLE gefolgt von der Definition für
eine Tabelle analog zu create table.
2. Die FINAL CALL-Klausel ist obligatorisch. Diese Klausel sorgt dafür, daß ein zus ätzlicher Parameter, der sogenannte Call-Indicator, an die Implementierung übergeben wird, der zur Steuerung des Cursor-Konzeptes dient.
3. Die Option SCRATCHPAD sorgt dafür, daß die Funktion mit einem Bereich im Speicher versehen wird, über den Informationen von einem Funktionsaufruf zum
nächsten erhalten werden können.
Ein Zeiger auf diesen Bereich wird als zusätzlicher Parameter an die C-Funktion
übergeben.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
80
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
4. Die Angabe von DISALLOW PARALLEL ist obligatorisch, da Tabellenfunktionen immer
auf einem einzelnen Knoten ausgewertet werden.
5. Die Bedeutung von NOT NULL CALL ist, daß eine leere Tabelle als Resultat unterstellt wird, wenn einer der Parameter ein Null-Wert ist.
6. Mit der CARDINALITY-Klausel kann eine Schätzung für die Größe der Ergebnistabelle angegeben werden. Dies ist für den Optimierer von Bedeutung.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
81
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
Beispiel: Deklaration für die Tabellenfunktion passwd():
create function passwd()
returns table ( name
varchar(8),
passwd varchar(13),
uid
integer,
gid
integer,
gecos
varchar(50),
dir
varchar(128),
shell
varchar(50) )
external name
’/home/pb/vorlesungen/database/db2/passwd/passwd.so!password’
deterministic
no external action
language c
fenced
parameter style db2sql
no sql
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
82
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
scratchpad
final call
disallow parallel
cardinality 50;
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
83
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
Implementierung von Tabellenfunktionen
Im Vergleich zur Implementierung von skalaren Funktionen gibt es die folgenden Unterschiede:
1. Ein einzelner Aufruf der C-Funktion zu einer Tabellenfunktion liefert ein Tupel der
Ergebnisrelation. Zur Berechnung der Ergebnisrelation wird die C-Funktion mehrmals analog zum Cursor-Konzept aufgerufen.
2. Der sogenannte Call-Indicator gibt die zugehörige Cursor-Operation (OPEN,
FETCH, CLOSE) beim Aufruf der C-Funktion an.
3. Mit Hilfe des Scratchpads können Informationen von einem Aufruf der Funktion
zum nächsten Aufruf verwahrt werden. Die Daten im Scratchpad bleiben für die
Dauer der Ausführung einer SQL-Anweisung erhalten.
Das Scratchpad ist ein 100 Byte
großer Bereich.
struct sqludf_scratchpad
{
unsigned long length;
char
data[100];
};
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
84
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
Reicht dies nicht aus, kann man dynamisch Speicher allokieren und einen Zeiger
auf den allokierten Speicher im Scratchpad verwahren.
4. Die C-Funktion liefert statt eines einzelnen Wertes pro Aufruf ein ganzes Tupel der
Ergebnisrelation. Dementsprechend ändern sich die Parameterkonventionen.
5. Das Ende der Ergebnisrelation wird von der C-Funktion durch den Wert 02000 für
SQLSTATE angezeigt.
Werte des Call-Indicators:
• SQL TF OPEN: Vorbereitende Aktionen, Öffnen von Dateien, Allokation von Speicher, Initialisierung des Scratchpads
• SQL_TF_FETCH: Rückgabe eines Tupels der Ergebnistabelle (SQLSTATE 00000),
oder Anzeige des Endes der Ergebnisrelation (SQLSTATE 02000), Update des
Scratchpads
• SQL_TF_CLOSE: Aufräumaktionen, Schließen von Dateien, Freigabe von Speicher
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
85
3. Erweiterbarkeit von Datenbanksystemen
Tabellenfunktionen
Parameterkonventionen:
void funcname( input SQL parameters,
return column parameters,
input null indicators,
return null indicators,
SQLSTATE,
SQL function name,
specific name,
error message,
scratchpad,
final call indicator
);
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
IN */
OUT */
IN */
OUT */
OUT */
IN */
IN */
OUT */
IN */
IN */
Beispiel: Tabellenfunktion passwd() ✎
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
86
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Aggregatfunktionen
Benutzerdefinierte Aggregatfunktionen
• Aggregatfunktionen (oder Spaltenfunktionen) bilden die Werte einer Spalte einer
Ergebnistabelle auf einen singulären Wert ab.
• Bekannte Aggregatfunktionen sind die SQL-Funktionen SUM, MIN, MAX, COUNT.
• Möchte man Funktionen für eine selbst definierte Zusammenfassung von Werte
implementieren, braucht man geeignete Konzepte der Erweiterung.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
87
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Aggregatfunktionen
Eine Aggregatfunktion ist gekennzeichnet durch:
1. Basisdatentypen: Dies sind die Datentypen T1 , . . . , Tn der zu verarbeitenden
Werte.
2. Datentyp der Zustandsvariablen: Die Zustandsvariable ist vom Typ S .
3. Initialwert: Startwert für die Zustandsvariable s ∈ S .
4. Zustands übergangsfunktion: Funktion δ : S ×T1 ×. . . Tn −→ S . Sie bildet den
aktuellen Wert der Zustandsvariable sowie die Parameterwerte auf einen neuen
Wert für s ab.
5. Ergebnistyp: Typ A des Aggregationsergebnisses
6. Finalfunktion: Eine Funktion ω : S −→ A, die nach dem letzten Zustandsübergang aufgerufen wird und s auf das Ergebnis der Aggregation abbildet.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
88
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Aggregatfunktionen
Beispiele:
Eine Aggregatfunktion zur Berechnung
der euklidischen Norm einer Spalte wäre
definiert durch:
•
•
•
•
n = 1, T1 = S = A = double
s=0
δ(s, p) := s + p2
√
ω(s) := s
Das Skalarprodukt für zwei Spalten wäre
gegeben durch:
•
•
•
•
n = 2, T1 = T2 = S = A = double
s=0
δ(s, p1, p2) := s + p1 · p2
ω(s) := s
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
89
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Aggregatfunktionen
Definition einer Aggregatfunktion in PostgreSQL:
CREATE AGGREGATE name (
sfunc = Funktionsname ,
basetype = Datentyp ,
stype = Datentyp ,
finalfunc = Funktionsname ,
initcond = ’Initialwert ’
)
Bemerkungen:
• Die Aggregation kann sich nur auf eine Spalte beziehen, d.h. es gilt immer n = 1.
• basetype gibt den Basisdatentyp und den Ergebnistyp an, d.h. es gilt immer T 1 =
A.
• stype ist der Typ der Zustandsvariablen.
• sfunc bezeichnet eine UDF als Zustandsübergangsfunktion δ .
• finalfunc bezeichnet eine UDF als Finalfunktion ω (optional).
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
90
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Aggregatfunktionen
• Die Angabe eines Startwertes für s mittels initcond ist ebenfalls optional.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
91
3. Erweiterbarkeit von Datenbanksystemen
Benutzerdefinierte Aggregatfunktionen
Aggregatfunktionen in DB2:
• Aggregatfunktionen sind zunächst übliche mit create funtion deklarierte UDFs.
• Dies hat gegenüber PostgreSQL den Vorteil, daß die Aggregatfunktion mehr als
einen Paramter haben kann.
• Da mittels der Option SCRATCHPAD Informationen von einem Funktionsaufruf zum
nächsten erhalten werden können, kann somit s auf dem Scratchpad repräsentiert
werden.
Die Implementierung von δ entspricht der Logik zum Update des Scratchpads.
• Durch Auswertung des FINAL CALL Parameters kann s geeignet initialisiert werden.
• Problematisch ist die Implementierung von ω . Diese kann nicht innerhalb der UDF
erfolgen.
Stattdessen muß die UDF in eine geeignete vordefinierte Aggregatfunktion beim
Aufruf gekapselt werden.
Unter Umständen gibt es solche eine geeignete Aggregatfunktion aber nicht.
Datenbanksysteme: Weiterf ¨uhrende Konzepte — FH Bonn-Rhein-Sieg, WS 05/06
92