12. Objektrelationale Aspekte in SQL:1999

12.
S
S
12.1 Datentypen in SQL:1999
Objektrelationale Aspekte in
SQL:1999
π
Allgemein:
Erweiterung der klassischen RDBMS-Funktionalität
P
Trigger
P
Rekursive Anfragen
P
Änderungen über Sichten (UNION, JOIN)
π
Neue vordefinierte Datentypen:

BOOLEAN

CLOB (s. Abschnitt 12.1.8)

BLOB (s. Abschnitt 12.1.8)
Benutzerdefinierte Typen

„
Objektrelationale Erweiterungen

P
Datentypen
P
Einfache Vererbung
P
P
basieren auf vordefinierten Typen
Strukturierte Typen
„
Attribute (alle Typen)
„
Methoden
Routinen
„
Kapselung
Imperative Sprachkonstrukte
ν
Objektidentität
„
Einfache Vererbung
„
Substituierbarkeit
„
Tabellenhierarchien
ν
View-Hierarchien („Object Views“)
S
Schemaevolution
S
Anbindung an Wirtssprachen
S
Distinct-Typen
Einbindung externer Daten
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
π
12-1
Konstruierte Typen

Referenztypen

Tupeltypen

Arraytypen
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-2
π
12.1.1 Distinct-Typen
π
μ
π
π
CREATE TYPE SchuhGrTyp AS INTEGER FINAL
Distinct-Typ übernimmt physische Repräsentation des
Quelltyps
CREATE TABLE Personen
( PersID
INTEGER,
Alter
AlterTyp,
SchuhGr SchuhGrTyp )
Distinct-Typ ist nicht mit dem Quelltyp „kompatibel“:
ν
keine Substituierbarkeit (z. B. für Funktionsparameter)
ν
keine Vergleichbarkeit (explizite Typumwandlung erforderlich)
Die folgenden Anfragen sind z. B. nicht zulässig:
SELECT *
FROM Personen
WHERE SchuhGr > Alter
Können zur Definition von Tabellenspalten und Attributen
eines strukturierten Typs (s. u.) verwendet werden
UPDATE Personen
SET
Alter = Alter + 10
WHERE PersID = 1234
Verwendungszweck:
μ
μ
π
CREATE TYPE AlterTyp AS INTEGER FINAL
Basieren auf einem vordefinierten Typ (Quelltyp)
μ
Beispiel 12-2:
Es sind explizite Typumwandlungen erforderlich:
Vermeidung unsinniger Operationen (z. B. Addition von Alter
und Schuhgröße einer Person)
SELECT *
FROM Personen
WHERE SchuhGr > CAST(Alter AS SchuhGrTyp)
Erzeugung von Typen mit spezifischem Verhalten (durch
Definition spezieller Routinen für den Distinct-Typ)
UPDATE Personen
SET
Alter = Alter + CAST(10 AS AlterTyp)
Beispiel 12-1:
Definition eines Distinct-Typs GeldTyp als 10-stellige Dezimalzahl mit 2
Nachkommastellen
π
Auf einem Distinct-Typ lassen sich Routinen definieren, die
nur auf Instanzen dieses Typs anwendbar sind.
π
Beispiel 12-3:
CREATE TYPE GeldTyp AS DECIMAL(10,2) FINAL
Die Klausel FINAL ist obligatorisch: Ein Distinct-Typ kann keine Subtypen
(s. u.) besitzen.
π
CREATE TYPE AudioTyp AS BLOB FINAL
Instanzen von Distinct-Typen, die auf demselben Quelltyp
basieren, können nicht „gemischt“ in Ausdrücken (z. B.
Vergleichen) verwendet werden.
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
CREATE TYPE BildTyp AS BLOB FINAL
CREATE FUNCTION InvertFarbe(b BildTyp) RETURNS BildTyp ...
CREATE PROCEDURE Abspielen(a AudioTyp) ...
12-3
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-4
π
12.1.2 Strukturierte Typen
π
Aggregation vorhandener Typen zu einem neuen Typ
Strukturierte Typen sind gekapselt
μ
Zugriff auf einzelne Attribute des Typs nur über spezielle
Methoden
μ
Automatische Generierung zweier Methoden für jedes Attribut
eines strukturierten Typs durch das System:
Beispiel 12-4:
CREATE TYPE AdressTyp AS
( Strasse VARCHAR(30),
HausNr INTEGER,
PLZ
INTEGER,
Stadt
VARCHAR(20) DEFAULT 'Mannheim')
NOT FINAL
ν
Anmerkung:
Die Klausel NOT FINAL ist obligatorisch: Ein strukturierter Typ kann
stets Subtypen (s. u.) besitzen.
π
ν
Attribute eines strukturierten Typs können beliebige Typen
haben:
μ
vordefinierte Typen
μ
benutzerdefinierte Typen
μ
μ
ν
Distinct-Typen
ν
andere strukturierte Typen (beliebige Verschachtelung möglich)
„Observer“-Methode zum Lesen eines Attributwerts
λ
hat denselben Namen wie das zugeordnete Typattribut
λ
liefert bei Anwendung auf eine Instanz des strukturierten Typs
den entsprechenden Attributwert zurück
„Mutator“-Methode zum Ändern eines Attributwerts
λ
hat denselben Namen wie das zugeordnete Typattribut
(Überladung!)
λ
setzt das entsprechende Attribut einer Instanz des
strukturierten Typs auf den der Methode übergebenen Wert
Durch Vergabe von Ausführungsrechten für Observer- und
Mutator-Methoden kann präzise festgelegt werden, wer auf
einzelne Typattribute zugreifen darf.
konstruierte Typen
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-5
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-6
π
12.1.2.1 Strukturierte Typen als Spaltentypen
Beispiel 12-5:
Jeder soll das Attribut PLZ einer Instanz des Typs AdressTyp lesen können.
Dazu notwendig: Vergabe des Ausführungsrechts für die Observer-Methode
von PLZ.
GRANT EXECUTE ON METHOD PLZ() FOR AdressTyp
TO PUBLIC
Jeder soll das Attribut HausNr einer Instanz des Typs AdressTyp lesen und
ändern können.
Dazu notwendig: Vergabe der Ausführungsrechte für die Observer- und
Mutator-Methode von HausNr.
π
Beispiel 12-6:
CREATE TABLE Angestellte
( PersNr
INTEGER,
Name
VARCHAR(40),
Adresse
AdressTyp,
Gehalt
GeldTyp )
Abfrage der kompletten Adresse eines Angestellten:
SELECT Adresse
FROM Angestellte
WHERE PersNr = 3333
GRANT EXECUTE ON METHOD HausNr()
FOR AdressTyp TO PUBLIC
Abfrage der PLZ eines Angestellten mit Hilfe der Observer-Methode von
PLZ:
GRANT EXECUTE ON METHOD HausNr(INTEGER)
FOR AdressTyp TO PUBLIC
SELECT Adresse.PLZ()
FROM Angestellte
WHERE PersNr = 3333
Anwendung von Observer- und Mutator-Funktionen: s. u.
Die leere Klammer kann auch weggelassen werden:
π
SELECT Adresse.PLZ
FROM Angestellte
WHERE PersNr = 3333
Nutzung eines strukturierten Typs auf zwei verschiedene
Arten:
μ
als Typ einer Tabellenspalte
Ändern der Hausnummer eines Angestellten mit Hilfe der Mutator-Methode
von HausNr:
Tabellentupel enthalten selbst wieder ein Tupel als Attribut
(„tupelwertige“ Attribute; sub-strukturierte Attribute)
μ
UPDATE Angestellte
SET
Adresse = Adresse.HausNr(77)
WHERE PersNr = 3333
als Typ einer Tabelle (typisierte Tabelle)
Dafür lässt sich kürzer schreiben:
strukturierter Typ legt das Schema der Tabelle fest
UPDATE Angestellte
SET
Adresse.HausNr = 77
WHERE PersNr = 3333
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-7
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-8
π
Erzeugen neuer Instanzen eines strukturierten Typs mit Hilfe
der Konstruktor-Funktion des Typs
μ
wird automatisch vom System generiert
μ
hat denselben Namen wie der strukturierte Typ
μ
π
erzeugt beim Aufruf eine Instanz des Typs, die für jedes
Attribut den Default-Wert enthält (falls kein Default-Wert für ein
Attribut definiert: NULL)
Beispiel 12-7:
INSERT INTO Angestellte
VALUES
( 3333, 'Hans Klein', AdressTyp(), CAST(6850 AS GeldTyp) )
12.1.2.2 Typisierte Tabellen
π
Tabellen, deren Schema durch einen strukturierten Typ
festgelegt wird
π
Jedes Attribut des strukturierten Typs entspricht einer Spalte
der typisierten Tabelle
π
Tupel der typisierten Tabelle sind Instanzen des
zugrundeliegenden Typs (Tupelobjekte)
π
Beispiel 12-8:
CREATE TYPE AngestTyp AS
( PersNr INTEGER,
Name
VARCHAR(40),
Adresse AdressTyp,
Gehalt
GeldTyp)
NOT FINAL
Das Attribut Adresse des neuen Angestelltentupels hat nun den Wert
(NULL, NULL, NULL, 'Mannheim').
Auf das Ergebnis des Konstruktors können direkt Mutator-Methoden
angewendet werden1:
CREATE TABLE Angestellte2 OF AngestTyp
(REF IS OidSpalte SYSTEM GENERATED)
INSERT INTO Angestellte VALUES
( 4444,
'Franz Groß',
AdressTyp().Strasse('Weitweg').HausNr(23).PLZ(68165),
CAST(8650 AS GeldTyp))
Angestellte2 enthält damit Instanzen des Typs AngestTyp.
Jedem Tupelobjekt der typisierten Tabelle Angestellte2 wird vom System
eine OID (object identifier) zugewiesen, die in der zusätzlichen Spalte
OidSpalte gespeichert wird.
Das Attribut Adresse dieses Angestelltentupels hat den Wert
('Weitweg', 23, 68165, 'Mannheim').
1 Bei der Anwendung von Observer- und Mutator-Methoden wird im folgenden stets
angenommen, dass die entsprechenden Ausführungsrechte vorhanden sind.
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-9
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-10
π
Vorteile typisierter Tabellen (gegenüber normalen):
12.1.3 Objektidentität und Referenztypen
μ
π
Jedem Tupelobjekt einer typisierten Tabelle wird beim Einfügen
in die Tabelle eine eindeutige, unveränderliche Object-ID (OID)
zugeordnet
Definition mehrer Tabellen mit demselben Schema
CREATE TABLE Angestellte3 OF AngestTyp
(REF IS OidSpalte SYSTEM GENERATED)
π
π
μ
Speicherung von Tupelobjekten mit Objektidentität (s. u.)
π
Speicherung der OID in einer zusätzlichen Spalte
μ
Definition von Tabellenhierarchien (s. u.)
π
OID erlaubt die Referenzierung des Tupelobjekts von anderer
Stelle (z. B. anderen Tupeln bzw. Tupelobjekten) aus
Zugriff auf typisierte Tabellen wie auf normale Tabellen
Beispiel 12-9:
μ
Zuweisung eines Referenztyps an eine Tabellenspalte bzw. ein
Attribut eines strukturierten Typs
μ
Referenztyp legt den strukturierten Typ fest, dessen Instanzen
durch Referenzen dieses Typs referenziert werden können
μ
„Wert“ einer Referenz = OID des referenzierten Objekts
INSERT INTO Angestellte2 (PersNr, Name, Adresse, Gehalt)
VALUES
(4444, 'Franz Groß',
AdressTyp().Strasse('Weitweg').HausNr(23).PLZ(68165),
CAST(8650 AS GeldTyp))
π
SELECT Name
FROM Angestellte2
WHERE PersNr = 4444
Anmerkung: In Tabellenspalten gespeicherte Instanzen
strukturierter Typen besitzen keine OID und können nicht
referenziert werden
π
3 Arten der OID-Generierung
μ
systemgeneriert
System generiert beim Einfügen eines Tupelobjekts in eine typisierte
Tabelle automatisch eine eindeutige OID
μ
benutzergeneriert
Benutzer gibt beim Einfügen eines Tupelobjekts selbst eine OID an
μ
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-11
abgeleitet
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-12
OID-Wert des neuen Tupelobjekts basiert auf einem anderen Attribut
(bzw. Attributkombination) des Objekts (Attribut(kombination) muss
Schlüsseleigenschaft bzgl. der typisierten Tabelle haben)
π
π
Referenzen, die dereferenziert werden sollen, müssen einen
Scope besitzen
μ
legt die typisierte Tabelle fest, in der sich die referenzierten
Tupelobjekte befinden müssen
μ
ermöglicht eine effiziente Auswertung von Dereferenzierungen
in Anfragen (referenzierte Zieltabelle schon zur
Übersetzungszeit der Anfrage bekannt!)
μ
ermöglicht statische Auswertung von Benutzerrechten (ist
Zugriff auf die Tabelle gestattet?)
Beispiel 12-10:
CREATE TYPE AbtTyp AS
( AbtNr
INTEGER,
AbtName VARCHAR(20),
Budget
GeldTyp)
NOT FINAL
REF IS SYSTEM GENERATED
Die OID-Werte von Tupelobjekten des Typs AbtTyp werden vom System
generiert (Default).
CREATE TYPE AngestTyp AS
( PersNr
INTEGER,
PersName VARCHAR(40),
Gehalt
GeldTyp,
AbtRef
REF(AbtTyp))
NOT FINAL
REF USING INTEGER
Beispiel 12-11:
Definition von typisierten Tabellen basierend auf den oben definierten Typen
CREATE TABLE Abteilungen OF AbtTyp
(REF IS AbtOID SYSTEM GENERATED)
Die OID-Werte der Tupelobjekte in Abteilungen werden vom System
generiert.
CREATE TABLE Angestellte OF AngestTyp
( REF IS AngOID USER GENERATED,
AbtRef WITH OPTIONS SCOPE Abteilungen)
Die OID-Werte von Tupelobjekten des Typs AngestTyp werden vom
Benutzer angegeben (Datentyp: INTEGER).
Anmerkung: Von PersNr abgeleitete OID-Werte könnten durch die Klausel
REF FROM (PersNr) erreicht werden.
Tupelobjekte des Typs AngestTyp enthalten eine Referenz auf ein
Tupelobjekt des Typs AbtTyp.
Die OID-Werte der Tupelobjekte in Angestellte werden vom Benutzer
angegeben.
Anmerkung: Wäre AngestTyp oben mit REF FROM (PersNr) definiert
worden (d. h. abgeleitete OIDs), müsste eine darauf basierende Tabelle etwa
wie folgt definiert werden:
CREATE TABLE Angestellte2 OF AngestTyp
( REF IS AngOID DERIVED,
PersNr WITH OPTIONS UNIQUE NOT NULL,
AbtRef WITH OPTIONS SCOPE Abteilungen)
1:n-Beziehung zwischen Abteilungen und Angestellten.
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
π
12-13
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-14
Das AbtRef-Attribut eines in Angestellte gespeicherten Tupelobjekts darf
nur Abteilungsobjekte referenzieren, die in der Tabelle Abteilungen
gespeichert sind.
SELECT abt.AbtName
FROM
Angestellte ang, Abteilungen abt
WHERE ang.AbtRef = abt.AbtOID
AND ang.PersNr = 1111
12.1.3.1 Umgang mit Referenzen in Anfragen
π
Funktion DEREF zur Dereferenzierung einer Referenz
π
Beispiel 12-12:
SELECT DEREF(AbtRef)
FROM Angestellte
WHERE PersNr = 1111
Es wird ein komplettes Abteilungsobjekt zurückgeliefert.
π
Zugriff auf einzelne Attribute eines referenzierten Objekts mit
Hilfe des Dereferenzierungsoperators '→'
π
Beispiel 12-13:
SELECT AbtRef→AbtName
FROM
Angestellte
WHERE PersNr = 1111
Dasselbe Ergebnis liefert:
SELECT abt.AbtName
FROM
Abteilungen abt
WHERE 1111 = ( SELECT ang.PersNr
FROM Angestellte ang
WHERE ang.AbtRef = abt.AbtOID )
Ebenso:
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-15
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-16
Ändern der Abteilungszuordnung eines Angestellten:
Dereferenzierung innerhalb der WHERE-Klausel:
SELECT PersName
FROM
Angestellte
WHERE AbtRef→AbtNr = 123
UPDATE Angestellte
SET
AbtRef = ( SELECT AbtOID
FROM Abteilungen
WHERE AbtNr = 123 )
WHERE PersNr = 1112
Dasselbe Ergebnis liefert:
SELECT PersName
FROM
Angestellte ang, Abteilungen abt
WHERE ang.AbtRef = abt.AbtOID
AND abt.AbtNr = 123
Löschen aller Angestellten einer Abteilung:
DELETE FROM Angestellte
WHERE AbtRef→AbtNr = 123
Einfügen einer neuen Abteilung in die Tabelle Abteilungen:
INSERT INTO Abteilungen (AbtNr, AbtName, Budget) VALUES
(124, 'Forschung', CAST(5000000 AS GeldTyp))
π
Die Angabe referentieller Integritätsbedingungen für
Referenzen ist möglich
π
Beispiel 12-14:
Das System generiert automatisch eine OID für das neue Abteilungsobjekt.
Einfügen eines neuen Angestellten (der Abteilung 124) in Tab. Angestellte:
INSERT INTO Angestellte
(AngOID, PersNr, PersName, Gehalt, AbtRef) VALUES
( CAST(314159 AS REF(AngestTyp)),
1112,
'Willy Wurm',
CAST(8300 AS GeldTyp),
(SELECT AbtOID FROM Abteilungen WHERE AbtNr = 124))
CREATE TABLE Projekte
( ProjNr
INTEGER,
ProjName VARCHAR(30),
ProjLeiter REF(AngestTyp)
SCOPE Angestellte
REFERENCES ARE CHECKED
ON DELETE RESTRICT
Die Löschung eines referenzierten Angestelltenobjekts wird damit vom
System zurückgewiesen (Alternativen z. B.: SET NULL; NO ACTION)
Der Benutzer muss selbst einen OID-Wert für das neue Angestelltenobjekt
angeben (hier: INTEGER-Wert 314159).
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-17
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-18
12.1.4 Vererbung in Typ- und Tabellenhierarchien
π
Vererbung von Eigenschaften
12.1.4.1 Typhierarchien
μ
π
Ableitung von Subtypen aus bestehendem strukturiertem Typ
π
Subtypen erben Repräsentation (Attribute) und Verhalten
(Operationen) des Supertyps
π
Beispiel 12-15:
zwischen (strukturierten) Typen:
Subtypen erben von Supertypen
μ
zwischen (typisierten) Tabellen
Subtabellen erben von Supertabellen
π
CREATE TYPE PersonTyp AS
( PersNr
INTEGER,
Name
VARCHAR(40),
Adresse
AdressTyp)
INSTANTIABLE
NOT FINAL
nur einfache Vererbung!
CREATE TYPE AngestTyp UNDER PersonTyp AS
( Gehalt
GeldTyp,
Abteilung VARCHAR(30))
INSTANTIABLE
NOT FINAL
PersonTyp
AngestTyp
ManagerTyp
CREATE TYPE ManagerTyp UNDER AngestTyp AS
( HandyNr VARCHAR(15))
INSTANTIABLE
NOT FINAL
AngestTyp erbt die Attribute PersNr, Name und Adresse von PersonTyp
und definiert zwei neue: Gehalt und Abteilung.
ManagerTyp erbt diese fünf Attribute von AngestTyp und definiert ein
neues: HandyNr.
ManagerTyp hat damit sechs Attribute
AngestTyp erbt außerdem alle auf PersonTyp definierten Operationen, und
ManagerTyp erbt alle Operationen von AngestTyp und PersonTyp.
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-19
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-20
Von allen drei Typen können Instanzen gebildet werden (INSTANTIABLE).
π
π
12.1.4.2 Tabellenhierarchien
Definition abstrakter Typen mit Hilfe der Klausel
NOT INSTANTIABLE
π
Ableitung von Subtabellen aus bestehender typisierter Tabelle
μ
keine Instanzen möglich
π
Subtabellen erben Eigenschaften der Supertabelle, z. B.:
μ
dienen nur als „Vorlage“ für abgeleitete Typen
Prinzip der Ersetzbarkeit (Substitutionsprinzip)
Eine Instanz eines Subtyps kann in jedem Kontext benutzt
werden, wo eine Instanz des Supertyps erwartet wird.
μ
μ
Spalten (insbesondere die OID-Spalte)
μ
Constraints (NOT NULL, PRIMARY KEY, CHECK usw.)
μ
Scopes
μ
Default-Werte für Spalten
π
Supertabelle beinhaltet (logisch) alle Tupelobjekte ihrer
Subtabellen
π
Enge Kopplung von Typ- und Tabellenhierarchie:
Als Parameter von Operationen:
Auf dem Supertyp definierte Operationen lassen sich auf
Instanzen des Subtyps anwenden.
μ
Ist B eine direkte Subtabelle von A, so muss der Typ von B
auch direkter Subtyp des Typs von A sein
In Tabellenspalten:
Eine auf dem Supertyp basierende Tabellenspalte muss auch
Instanzen des Subtyps aufnehmen können.
π
Beispiel 12-16:
Auf der oben definierten Typhierarchie basierende Tabellenhierarchie:
CREATE TABLE Personen OF PersonTyp
( REF IS PersOID SYSTEM GENERATED,
PersNr WITH OPTIONS PRIMARY KEY)
CREATE TABLE Angestellte OF AngestTyp UNDER Personen
( Gehalt WITH OPTIONS
CHECK (Gehalt > CAST(2000 AS GeldTyp)))
CREATE TABLE Manager OF ManagerTyp UNDER Angestellte
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-21
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-22
PersonTyp
Tabelle Manager:
Personen
ν
Subtabelle von Angestellte
is-a
is-a
ν
basiert auf dem Typ ManagerTyp
AngestTyp
Angestellte
AngestTyp
ν
is-a
is-a
besitzt die Spalten PersOID, PersNr, Name, Adresse, Gehalt,
Abteilung und HandyNr
ν
erbt Systemgenerierung für OIDs, Primärschlüsseleigenschaft für
PersNr und CHECK-Constraint auf Gehalt
ManagerTyp
Manager
Typhierarchie
Tabellenhierarchie
Die drei Tabellen dürfen nicht als unabhängige Tupelmengen betrachtet
werden:
Abb. 12-1: Tabellenhierarchie mit korrespondierender
Typhierarchie
Tabelle Personen:
ν
Wurzeltabelle der Tabellenhierarchie
ν
basiert auf dem Typ PersonTyp
ν
besitzt die Spalten PersOID, PersNr, Name und Adresse
ν
legt PersOID als Spalte für systemgenerierte OIDs fest
ν
legt PersNr als Primärschlüssel fest
ν
Jedes Tupel in Manager ist gleichzeitig auch Tupel von Angestellte
bzw. Personen.
ν
Der in Personen definierte Primärschlüssel muss über die gesamte
Tabellenhierarchie hinweg eindeutig sein.
ν
Das heißt, es kann keine Tupel mit gleicher PersNr in verschiedenen
Tabellen der Tabellenhierarchie geben.
ν
Allgemein: Primärschlüsseldefinition nur in der Wurzeltabelle einer
Tabellenhierarchie erlaubt.
Tabelle Angestellte:
ν
Subtabelle von Personen
ν
basiert auf dem Typ AngestTyp
ν
besitzt die Spalten PersOID, PersNr, Name, Adresse, Gehalt und
Abteilung
ν
erbt Systemgenerierung für OIDs
ν
erbt Primärschlüsseleigenschaft für PersNr
ν
definiert einen CHECK-Constraint auf der Spalte Gehalt
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-23
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-24
12.1.4.3 Anfragen über Tabellenhierarchien
π
Anfragen an eine Supertabelle beziehen sich im Allgemeinen
auch auf alle Subtabellen dieser Tabelle
π
Beispiel 12-17:
π
Ein INSERT-Befehl bezieht sich stets nur auf die im Befehl
genannte Tabelle.
π
Beispiel 12-19:
INSERT INTO Angestellte (PersNr, Name, Adresse, Gehalt, Abteilung)
VALUES
( 3333, 'Hans Klein',
AdressTyp().Strasse(''Weitweg').HausNr(23).PLZ(68165),
CAST(8650 AS GeldTyp),
'Forschung')
fügt ein Tupel in die Tabelle Angestellte ein.
SELECT * FROM Personen
π
ν
liefert alle Tupel der drei Tabellen Personen, Angestellte und
Manager zurück
ν
projiziert diese Tupel auf diejenigen Spalten, die in der Tabelle
Personen existieren (PersNr, Name, Adresse)
ν
d. h. Angestellte und Manager werden als „normale“ Personen
betrachtet (ohne die zusätzlichen Attribute)
ν
Dem Ergebnis ist nicht anzusehen, welche Tupel aus welchen
Tabellen stammen.
π
UPDATE- und DELETE-Befehle wirken sich dagegen auch
auf Subtabellen aus.
π
Beispiel 12-20:
UPDATE Angestellte
SET
Gehalt = Gehalt * 1.1
WHERE Abteilung = 'Forschung'
DELETE
WHERE
Zum Ausschluss von Subtabellen in Anfragen: Schlüsselwort
ONLY
FROM Angestellte
Gehalt < CAST(2000 AS GeldTyp)
Beide Befehle wirken sich auf alle Tupel in Angestellte und Manager aus
(zur Beschränkung auf eine Tabelle: wieder ONLY)
DELETE FROM ONLY(Angestellte) ...
π
Beispiel 12-18:
SELECT * FROM ONLY(Personen)
liefert alle Personen, die nicht gleichzeitig auch Angestellte oder Manager
sind
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-25
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-26
12.1.5 Typisierte Views
CREATE TABLE Personen OF PersonTyp
(REF IS PersOID USER GENERATED)
π
Erweiterung des relationalen View-Mechanismus
CREATE TABLE Angestellte OF AngestTyp UNDER Personen
π
Basieren wie typisierte Tabellen auf einem strukturierten Typ
π
Hierarchien von typisierten Views möglich
π
Beispiel 12-21:
CREATE TABLE Professoren OF ProfTyp UNDER Angestellte
CREATE TABLE Abteilungen OF AbtTyp
( REF IS AbtOID USER GENERATED
Manager WITH OPTIONS SCOPE Angestellte)
ALTER TABLE Angestellte
ALTER COLUMN Abteilung
ADD SCOPE Abteilungen
Gegeben seien folgende Typ- und Tabellenhierarchien:
CREATE TYPE PersonTyp AS
( PersNr
INTEGER,
Name
VARCHAR(40),
Adresse
AdressTyp)
NOT FINAL
REF USING INTEGER
Nun: Erstellen einer Object-View-Hierarchie, die
CREATE TYPE AngestTyp UNDER PersonTyp AS
( Gehalt
GeldTyp)
NOT FINAL
CREATE TYPE ProfTyp UNDER AngestTyp AS
( HandyNr VARCHAR(15))
NOT FINAL
CREATE TYPE AbtTyp AS
( Name
VARCHAR(20),
Budget
GeldTyp,
Manager
REF(AngestTyp))
NOT FINAL
REF USING INTEGER
PersonTyp
Manager
AbtTyp
AngestTyp
Abteilung
ProfTyp
ALTER TYPE AngestTyp
ADD ATTRIBUTE Abteilung REF(AbtTyp)
Professoren ausblendet
μ
Abteilungen mit kleinem Budget (<= 1.000.000 ausblendet)
μ
nur auf den Namen von Personen und Abteilungen zugreifen lässt
μ
die Referenzen zwischen Abteilungen und Angestellte beibehält
CREATE TYPE ViewAbtTyp AS
( Name
VARCHAR(20))
NOT FINAL
REF USING INTEGER
PersonTyp
Manager
AbtTyp
AngestTyp
Abteilung
CREATE TYPE ViewPersonTyp AS
( Name
VARCHAR(40))
NOT FINAL
REF USING INTEGER
CREATE TYPE ViewAngestTyp UNDER ViewPersonTyp AS
( Abteilung REF(ViewAbtTyp))
NOT FINAL
Das Referenz-Attribut Abteilung muss nachträglich zu AngestTyp
hinzugefügt werden, da der referenzierte Typ AbtTyp zum Zeitpunkt der
Definition von AngestTyp noch nicht existierte.
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
μ
12-27
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-28
ALTER TYPE ViewAbtTyp
ADD ATTRIBUTE Manager REF(ViewAngestTyp)
View-Hierarchie:
CREATE VIEW ViewAbteilungen OF ViewAbtTyp
(REF IS oid USER GENERATED)
AS SELECT ViewAbtTyp(INTEGER(AbtOID)), Name,
ViewAngestTyp(INTEGER(Manager))
FROM Abteilungen
WHERE Budget > 1000000
CREATE VIEW ViewPersonen OF ViewPersTyp
(REF IS oid USER GENERATED)
AS SELECT ViewPersTyp(INTEGER(PersOID)), Name
FROM ONLY(Person)
CREATE VIEW ViewAngestellte ViewAngestTyp
UNDER ViewPersonen
(Abteilung WITH OPTIONS SCOPE ViewAbteilungen)
AS SELECT ViewAngestTyp(INTEGER(PersOID)), Name,
ViewAbtTyp(INTEGER(Abteilungen))
FROM ONLY(Angestellte)
ALTER VIEW ViewAbteilungen
ALTER COLUMN Manager
ADD SCOPE ViewAngestellte
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-29
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-30
12.1.6 Tupeltypen
Beachte:
ν
ν
Explizite Umwandlung von benutzergenerierten OIDs und Referenzen
in die richtigen Typen erforderlich
Automatische Generierung von zwei Umwandlungsfunktionen für
jeden strukturierten Typ:
λ
λ
ν
π Bezug: Tabellen bzw. Typen mit tupelwertigem Attribut
gestatten Typumwandlungen zwischen einer Referenz auf diesen
Typ und dem dieser Referenz zugrundeliegenden Typ (festgelegt
durch die REF-USING-Klausel)
λ
π
Funktionsnamen stimmen mit den Namen des strukturierten bzw.
zugrundeliegenden Typs überein.
μ
Implizite Deklaration
Beispiel 12-22:
CREATE TABLE Angestellte
( PersNr INTEGER,
Name
VARCHAR(40),
Adresse ROW( Strasse VARCHAR(30),
HausNr INTEGER,
PLZ
INTEGER,
Stadt
VARCHAR(20) ),
Gehalt
GeldTyp)
zunächst Umwandlung der Abteilungs-OID (Typ: REF(AbtTyp))
in einen INTEGER-Wert (zugrundeliegender Typ)
dann Umwandlung dieses INTEGER-Werts in eine OID vom Typ
REF(ViewAbtTyp)
Explizite Deklaration (⇒ Deklaration strukturierter Typ)
Verwendung eines Tupelkonstruktors ROW()
ViewAbtTyp(INTEGER(oid)) in der ersten View-Definition
bedeutet also:
λ
μ
π
Zugriff auf Komponenten des Tupeltyps über Punktnotation
π
Beispiel 12-23:
SELECT ang.Adresse.PLZ FROM Angestellte ang
π
Mittels ROW() lassen sich auch Tupel-Instanzen erzeugen:
π
Beispiel 12-24:
UPDATE Angestellte
SET
Adresse = ROW('Weitweg', 23, 12345, 'Kleinheim')
WHERE PersNr = 3333
π
Anmerkung:
Die Struktur einer typisierten Tabelle kann nicht mit Hilfe von
ROW festgelegt werden (strukturierter Typ erforderlich)
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-31
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-32
12.1.7 Arrays
π
π
Definition von Array-Typen zur Verwendung für
Tabellenspalten oder Typattribute
π
Lesen und Schreiben von Array-Elementen durch direkte
Indizierung
π
Beispiel 12-27:
SELECT BuchListe[10]
FROM
Entleihungen
WHERE CARDINALITY(BuchListe) >= 10
Beispiel 12-25:
Definition einer Tabelle Entleihungen, die zu einem Entleiher eine Liste
(Array) von entliehenen Buchtiteln speichert
UPDATE Entleihungen
SET
BuchListe[4] = 'Schlank in 7 Tagen'
WHERE Entleiher = 'Fritz Klein'
CREATE TABLE Entleihungen
( Entleiher VARCHAR(40) PRIMARY KEY,
BuchListe VARCHAR(50) ARRAY[20])
π
Umwandlung eines Arrays in eine einspaltige Tabelle mit
UNNEST
π
Beispiel 12-28:
In der Spalte BuchListe können damit maximal 20 Buchtitel für jeden
Entleiher gespeichert werden.
π
π
Erzeugen von Array-Werten mit Hilfe des Konstruktors
ARRAY
Ermittlung aller Entleiher, die 'Das Boot' ausgeliehen haben:
SELECT e.Entleiher
FROM Entleihungen e, UNNEST(e.BuchListe) Buch(Titel)
WHERE Buch.Titel = 'Das Boot'
Beispiel 12-26:
Erklärung:
INSERT INTO Entleihungen VALUES
('Fritz Klein', ARRAY['Der Schakal', 'Die Reblaus', 'Nur Du allein'])
UPDATE Entleihungen
SET
BuchListe = BuchListe || ARRAY['Dick und Doof', 'Das Boot']
WHERE Entleiher = 'Fritz Klein'
1. Umwandlung der BuchListe eines Entleihungstupels e in eine einspaltige
Tabelle
2. Binden dieser Hilfstabelle an eine Relationsvariable Buch mit
Spaltenname Titel
3. Zugriff auf die Titel-Spalte in der WHERE-Klausel
Anmerkung:
Es gibt auch die Möglichkeit, sich die Positionsnummern der Array-Elemente
mit ausgeben zu lassen (WITH ORDINALITY)
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-33
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-34
π
12.1.8 Große Objekte (LOBs)
Operationen auf LOBs
μ
π
Zwei neue Datentypen:
μ
BLOB (Binary Large Object)
μ
CLOB (Character Large Object)
π
LOBs werden direkt in der Datenbank verwaltet
π
LOB-Größe wird bei der Spaltendefinition festgelegt
π
Beispiel 12-29:
μ
CREATE TABLE Buecher
(BuchID
INTEGER,
Titel
VARCHAR(200),
Zusammenfassung CLOB(32K),
BuchText
CLOB(20M),
FilmZumBuch
BLOB(2G))
π
π
π
LOBs werden bei SELECTs, INSERTs und UPDATEs wie die
anderen Datentypen behandelt
μ
Zur Speicherung der LOBs müssen ausreichend große Puffer
in der Anwendung angelegt werden
μ
Kann bei sehr großen LOBs zu Problemen führen (s. u.)
π
Beispiel 12-30:
EXEC SQL SELECT Zusammenfassung, BuchText, FilmZumBuch
INTO Puffer, GroßerPuffer, RiesigerPuffer
FROM Buecher
WHERE Titel = ‚Moby Dick‘;
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-35
nicht erlaubt für LOBs:
ν
Vergleichsoperatoren (<, >)
ν
Primär- und Fremdschlüssel-Constraints
ν
GROUP BY, ORDER BY
ν
Mengenoperationen (UNION, INTERSECT, EXCEPT)
ν
Joins (LOB als Join-Spalte)
erlaubt:
ν
LIKE-Prädikat
ν
Konkatenation (Aneinanderhängen)
ν
Zeichenkettenfunktionen wie SUBSTRING, POSITION,
LENGTH
ν
Benutzerdefinierte Funktionen auf LOB-Typen
Problem: Große LOBs in Anwendungsprogrammen schwer
zu verwalten
μ
Anlegen riesiger Puffer notwendig
μ
Programme wollen evtl. nur auf Teile eines LOBs zugreifen
Lösung: LOB-Lokatoren
μ
Lokator = Referenz (Größe: 4 Byte) auf einen LOB-Wert
μ
Anwendung deklariert eine Lokator-Variable zur Speicherung
solcher Referenzen
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-36
μ
π
Lokatoren können überall benutzt werden, wo auch ein LOBWert auftauchen kann
Beispiel 12-31:
12.2 Benutzerdefinierte Routinen
π
EXEC SQL BEGIN DECLARE SECTION;
SQL TYPE IS BLOB_LOCATOR FilmLok;
EXEC SQL END DECLARE SECTION;
EXEC SQL
SELECT FilmZumBuch
INTO :FilmLok
FROM Buecher
WHERE Titel = ‚Moby Dick‘
π
π
π
LOB-Lokatoren können nicht nur komplette LOBs, sondern
auch Teile davon referenzieren (i. Allg.: beliebige LOBAusdrücke)
μ
Beschreibung des Verhaltens von Objekten
μ
Konsistenter Umgang mit den Objekten
Daher:
μ
Datenbank sollte nicht nur als Ablageort passiver Datensätze
fungieren
μ
sondern auch die Speicherung und Ausführung von
Operationen erlauben
Beispiel 12-32:
π
SELECT SUBSTRING(BuchText,
POSITION(‚Kapitel 1‘ IN BuchText),
POSITION(‚Kapitel 2‘ IN BuchText) POSITION(‚Kapitel 1‘ IN BuchText))
FROM Buecher
INTO :Kap1Lok
WHERE Titel = ‚Moby Dick‘;
π
Neue Datentypen benötigen entsprechende Operationen
Anmerkung:
Vorteil gegenüber der Codierung in Anwendungsprogrammen:
μ
Von der Datenbank verwaltetet Programmcode kann von allen
Anwendungsprogrammen verwendet werden (sogar von
interaktiven Benutzern)
μ
Ändert sich das Verhalten von bestimmten Daten, müssen nur
die in der Datenbank gespeicherten Operationen angepasst
werden.
Lokatoren sind auch für Arrays verfügbar
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-37
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-38
π
3 Arten von benutzerdefinierten Routinen in SQL:1999
μ
μ
ν
Prozeduren
ν
liefern keinen Rückgabewert
ν
können nicht innerhalb von SQL-Anfragen aufgerufen werden
ν
Aufruf durch speziellen CALL-Befehl
ν
greifen auf Daten in der Datenbank zu und nehmen i. d. R.
auch Änderungen vor
ν
überladbar, Auswahl der richtigen Version auf Grund der
bestpassenden statischen Parametertypen
ν
Zweck weniger die Bereitstellung von Operationen für
Datentypen, sondern die Vermeidung von Netzwerktransfers in
C/S-Umgebungen durch Zusammenfassung von SQL-Befehlen
λ
Client-Anwendung übergibt Kontrolle an Datenbank-Prozedur
λ
Prozedur führt gewünschte Operationen auf dem
Datenbankserver aus
λ
Übergabe der Kontrolle zurück an die Anwendung
μ
12-39
liefern einen Rückgabewert
ν
können überall in Anfragen aufgerufen werden, wo ein
Ausdruck erwartet wird, dessen Typ mit dem Typ des
Rückgabewerts übereinstimmt
ν
ermöglichen damit die Anpassung der Anfragesprache an den
gewünschten Anwendungsbereich
ν
effizienter Umgang mit benutzerdefinierten Datentypen in der
Anfragesprache durch Anwendung typspezifischer Funktionen
ν
greifen i. d. R. nicht auf Daten in der Datenbank zu
ν
π
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
Funktionen
λ
SQL garantiert keine bestimmte Ausführungsreihenfolge für
Prädikate
λ
Prädikate werden in manchen Fällen überhaupt nicht ausgeführt
(z. B. Disjunktion von Prädikaten)
λ
Damit ist unklar, ob bzw. wann eine innerhalb eines Prädikats
aufgerufene Funktion ausgeführt wird (und deshalb sollten in
Funktionen keine Änderungen in der DB vorgenommen werden)
überladbar, Auswahl der richtigen Version auf Grund der
bestpassenden statischen Paramtertypen
Methoden
ν
sind spezielle Funktionen
ν
sind einem benutzerdefinierten (strukturierten) Typ zugeordnet
ν
besitzen ein (in der Parameterliste unsichtbares) Argument
SELF des benutzerdefinierten Datentyps
ν
überladbar und überschreibbar, aktueller Typ von SELF
bestimmt zur Laufzeit die konkrete Methode
ν
Aufruf über Punktnotation (Objekt.Methode(...))
Implementierung von Routinen durch SQL oder Wirtssprache
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-40
DETERMINISTIC: Funktion liefert bei einem Aufruf mit denselben
Argumenten auch dasselbe Ergebnis (Ergebnis muss daher ggf.
nicht nochmals berechnet werden)
12.1.1 SQL-Routinen
π
Ausbau von SQL zur Programmiersprache 2
π
Einbettung herkömmlicher SQL-Befehle in Kontrollstrukturen wie
Verzweigungen oder Schleifen
π
direkte Zuweisung von in der Datenbank gespeicherten Werten
(auch NULL-Werten) an entsprechend definierte SQL-Variable
12.2.1.1
π
Definition von SQL-Routinen
Beispiel 12-33:
Funktion zur Berechung der Fakultät (n! = 1*2*...*n) einer (positiven)
Ganzzahl n
CREATE FUNCTION Fakultaet(n INTEGER)
RETURNS INTEGER
LANGUATE SQL
DETERMINISTIC
BEGIN
DECLARE fak INTEGER DEFAULT 1;
DECLARE i INTEGER;
SET i = n;
REPEAT
SET fak = fak * i;
SET i = i - 1;
UNTIL i = 1
END REPEAT;
RETURN fak;
END
2 Definiert im SQL-Teilstandard SQL/PSM (Persistent Stored Modules)
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-41
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-42
π
Beispiel 12-34:
Prozedur zur Erhöhung des niedrigeren Gehalts zweier Angestellter (gegeben:
Personalnummer) in der Datenbank um 10 Prozent
CREATE PROCEDURE ErhNiedGeh
(PNr1 INTEGER, PNr2 INTEGER)
LANGUAGE SQL
BEGIN
IF
( SELECT Gehalt
FROM Angestellte
WHERE PersNr = PNr1)
>
( SELECT Gehalt
FROM Angestellte
WHERE PersNr = PNr2)
THEN
UPDATE Angestellte SET Gehalt = Gehalt*1.1
WHERE PersNr = PNr2;
ELSE
UPDATE Angestellte SET Gehalt = Gehalt*1.1
WHERE PersNr = Pnr1;
END IF;
END
12.2.1.2
Aufruf von SQL-Routinen
π
SQL-Funktionen können überall in einem SQL-Befehl
aufgerufen werden, wo Ausdrücke (des Typs des
Rückgabewerts der Funktion) erlaubt sind.
π
Beispiel 12-35:
SELECT Fakultaet(IntSpalte)
FROM Tabelle
π
SQL-Prozeduren werden über einen speziellen CALL-Befehl
aufgerufen (aus einer SQL-Routine oder einem
Anwendungsprogramm heraus)
π
Beispiel 12-36:
Innerhalb einer SQL-Routine:
DECLARE PersNr1, PersNr2 INTEGER;
SET PersNr1 = 1111;
SET PersNr2 = 2222;
CALL ErhNiedGeh(PersNr1, PersNr2)
Innerhalb eines Anwendungsprogramms:
EXEC SQL CALL ErhNiedGeh(:PNr1, :PNr2);
PNr1 und PNr2 seien dabei zwei entsprechend definierte IntegerHostvariablen.
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-43
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-44
π
Beispiel 12-38: Methode für einen strukturierten Typ
Methodensignatur muss zusammen mit dem Typ definiert werden:
12.1.1.1
π
π
Behandlung benutzerdefinierter Datentypen
Prozedurales SQL ideal zum Umgang mit in der Datenbank
definierten Datentypen geeignet
μ
direktes Einlesen von Instanzen dieser Typen in SQLVariablen
μ
Verwendung als Parameter und Rückgabewerte von SQLRoutinen
METHOD Gehaltserhoehung()
RETURNS Geldtyp
LANGUAGE SQL
DETERMINISTIC
Definition eines Subtyps mit überschreibender Methode:
CREATE TYPE ManagerTyp UNDER AngestTyp AS
( HandyNr VARCHAR(15)
NOT FINAL
Beispiel 12-37: Variablen für strukturierte Typen
Gegeben sei der oben definierte strukturierte Typ AdressTyp und die Tabelle
Angestellte
DECLARE MeineAdresse AdressTyp
OVERRIDING METHOD Gehaltserhoehung()
RETURNS Geldtyp
Implementierung der beiden Methoden:
CREATE METHOD Gehaltserhoehung()
RETURNS GeldTyp
FOR AngestTyp
BEGIN
RETURN SELF.Gehalt * CAST(0.1 AS GeldTyp)
END
SELECT Adresse INTO MeineAdresse
FROM
Angestellte
WHERE PersNr = 3333
Auf die Komponenten einer Variablen strukturierten Typs wird über
Punktnotation zugegriffen:
CREATE METHOD Gehaltserhoehung()
RETURNS GeldTyp
FOR ManagerTyp
BEGIN
RETURN SELF.Gehalt * CAST(0.2 AS GeldTyp)
END
SET MeineAdresse.PLZ = 12345
UPDATE Angestellte
SET
Adresse = MeineAdresse
WHERE PersNr =3333
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
CREATE TYPE AngestTyp AS
( PersNr INTEGER,
Name
VARCHAR(40),
Gehalt
GeldTyp)
NOT FINAL
12-45
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-46
12.2.2 Externe Routinen
12.2.2.1
Allgemeines
π
Implementierung von Datenbank-Routinen in einer
Wirtssprache (z. B. C)
π
Vorteile gegenüber SQL-Routinen:
π
μ
Wiederverwendbarkeit bestehenden 3GL-Codes
μ
höhere Funktionalität der Wirtssprache
μ
evtl. höhere Performanz bei der Ausführung
12.2.2.2
Registrierung externer Routinen
π
Externe Routinen sollen wie SQL-Routinen von SQL aus
aufrufbar sein.
π
D. h., beim Aufruf einer externen Routine werden SQL-Typen
als Parameter übergeben
π
Auch eventuelle Rückgabewerte sollen einen SQL-Typ
besitzen
π
Problem: Externe Routine kann mit SQL-Typen nichts
anfangen.
Nachteile
μ
Impedance Mismatch (keine exakte Korrespondenz zwischen
Datentypen der Programmiersprache und der Datenbank)
π
Daher: Abbildung zwischen SQL-Typen und Typen der
Programmiersprache notwendig.
μ
evtl. Sicherheitsprobleme (wenn externe Routine im selben
Adressraum wie der Datenbankserver ausgeführt wird)
π
Für vordefinierte Typen: Standardabbildungen auf
verschiedene Wirtssprachen.
π
z. B. für Wirtssprache C:
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-47
μ
Abbildung SQL-Typ INTEGER auf C-Typ long
μ
Abbildung SQL-Typ REAL auf C-Typ float
μ
usw.
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-48
π
Damit: Registrierung von externen Routinen in der Datenbank
möglich, die mit vordefinierten Datenbanktypen umgehen
können
π
Beispiel 12-39:
Gegeben sei eine C-Funktion mit der folgenden Signatur:
float Func(long Par);
Diese kann wie folgt in der Datenbank registriert werden:
CREATE FUNCTION SqlFunc (x INTEGER)
RETURNS REAL
LANGUAGE C
DETERMINISTIC
NO SQL
RETURNS NULL ON NULL INPUT
EXTERNAL NAME 'usr/lib/mathlib!Func'
Danach kann die externe Funktion wie eine SQL-Funktion in
Anfragen verwendet werden
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-49
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-50
12.3 Anbindung von SQL an Wirtssprachen
π
Eingebettetes statisches SQL
π
Dynamisches SQL
π
π
π
CLI: genormte Call-Schnittstelle
π
Neue Notwendigkeit: Kommunikation auf Objektebene
π
Umwandlung von Datentypen bei Transfer zwischen DBMS
und Wirtssprache
μ
Definition von sog. Transformationsfunktionen für
benutzerdefinierte Datentypen
μ
2 Arten:
ν
ν
μ
μ
μ
beschreibt (bisher nur) in Java eingebettetes SQL (SQLJ)
μ
benutzerfreundliche Integration der SQL-Befehle ins JavaProgramm
Beispiel 12-40:
Ausgabe des mengenwertigen Ergebnisses einer SQL-Anfrage in Java (mit
Hilfe eines Iterators)
from-sql: bildet den Wert eines benutzerdefinierten Typs auf
einen Wert eines vordefinierten SQL-Typs ab
#sql iterator PatientenIter(String Name, float Gewicht);
PatientenIter Patient;
#sql Patient =
{ SELECT PatName AS „Name“, PatGewicht AS „Gewicht“
FROM PatientenTabelle
WHERE PatAlter BETWEEN :MinAlter AND :MaxAlter
ORDER BY PatGewicht DESCENDING};
while (Patient.next()) {
System.out.println(Patient.Name() + „ wiegt “ + Patient.Gewicht());
}
π
Direkte Abbildung von benutzerdefinierten SQL-Typen auf
Java-Klassen und umgekehrt
π
Beispiel 12-41:
to-sql: bildet den Wert eines vordefinierten SQL-Typs auf einen
Wert eines benutzerdefinierten Typs ab
Umwandlung zwischen vordefinierten SQL-Typen und Typen
der Wirtssprache dann nach festem Schema (vgl. Abschnitt
12.2.2.2)
Problem: Strukturierte Typen in SQL werden einfach auf
Zeichenfolgen in der Wirtssprache abgebildet (innere Struktur
geht verloren)
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
Neuer Teilstandard: SQL/OLB (Object Language Binding)
12-51
SQL:
Java:
CREATE TYPE Adresse (
Strasse VARCHAR(100),
HausNr INTEGER,
Stadt
VARCHAR(50))
public class Adresse {
public String Strasse;
public int HausNr;
public String Stadt;}
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-52
12.4 Abschließende Bemerkungen
π
SQL:1999 verbessert das Zusammenspiel mit objektorientierten Programmiersprachen – insbesondere durch die
speziellen Language Bindings – in erheblichem Maße.
... allerdings weniger „nahtlos“ als ooDBMS
π
SQL:1999 „klebt“ immer noch stark am „flachen“ Relationenmodell
π
Komplex strukturierte Attributwerte werden als „special
animals“ behandelt und sind nur relativ schwach in die
Sprache integriert.
π
„Complex objects“, wie z. B. der Roboter sind damit nicht
adäquat handhabbar
... sehr viel DBMS-Funktionalität müsste „von Hand“ in Form von
Functionen nachimplementiert werden.
π
DBMS-Ansatz von SQL:1999 i. W. immer noch rein serverbasiert.
... die Probleme (Client/Server) für technisch/wissenschaftliche
Anwendungen bleiben damit weitgehend bestehen.
1
© G. Specht Datenbanksysteme
12. Objektrelationale Aspekte in SQL:1999
12-53