Beispielschema: CREATE TABLE employees ( empno INTEGER, VARCHAR(100), VARCHAR(30)) (1) Verbindungsaufbau. (2) SQL Statement erzeugen

Transkript

1 Stefan Deßloch SQL-Norm und Java 1 Einleitung und Überblick Bei der Entwicklung von Web-basierten Anwendungen für Internet und Intranet kommen sowohl SQL-Datenbanken als auch der Programmiersprache Java Schlüsselpositionen zu, und die Interaktion und Integration von SQL und Java spielen zunehmend eine wichtige Rolle. Bemühungen um eine Synergie bzw. Integration von SQL und Java über die letzten Jahre hinweg haben sich in De-jureund De-facto-Standards wie SQL:1999 [ ], JDBC [White 1999], SQL/ OLB [X , ] und SQLJ [ , ] niedergeschlagen. Dieses Tutorial gibt eine Einführung in die in diesen Foren entwickelten Ansätze, soweit sie das Zusammenspiel von SQL und Java betreffen. Drei Hauptbereiche lassen sich hierfür in der Betrachtung der oben genannten Standards identifizieren. Einführung objektorientierter Konzepte und Erweiterbarkeitsmechanismen in SQL Ein wesentlicher Teil des neuen SQL- Standards (SQL:1999) beschreibt Mechanismen zur Ausführung von Anwendungslogik (Routinen) im Datenbankserver und definiert objekt-relationale Erweiterungen von SQL, die das relationale Modell durch objektorientierte Konzepte erweitern [ ]. Hier ist insbesondere die Kompatibilität bzw. Abbildbarkeit der in SQL und Java definierten Objektmodelle von Interesse. Zugriff auf SQL-Daten und Objekte in Java-Anwendungen Basierend auf SQL-92 (und parallel zur Entwicklung von SQL:1999) wurden Ansätze zum Zugriff auf SQL-Datenbanken definiert. Nachfolgend zur JDBC-Spezifikation materialisierte sich ein Ansatz zur statischen Einbettung von SQL in Java in den sog. SQL Object Language Bindings (SQL/OLB) [X ]. Sowohl JDBC als auch SQL/OLB wurden in neueren Versionen um Konzepte erweitert, die eine einfache Manipulation und Abbildung von SQL-Objekten in Java-Objekte ermöglichen [White 1999, ]. Implementierung von SQL-Objekttypen und -Routinen mit Hilfe von Java Der SQLJ-Standard [ , ] definiert, wie Java-Klassen und -Methoden benutzt werden können, um auf einfache Weise eine portable Implementierung von Routinen in SQL zu erzeugen bzw. Java-Klassen und -Methoden zur direkten Realisierung von Objektverhalten in SQL einzusetzen. Das Tutorial ist wie folgt gegliedert. Zuerst geben wir einen kurzen Überblick über den Datenbankzugriff in JDBC und SQL/OLB, noch auf SQL-92 basierend. Anschließend konzentrieren wir uns auf die in SQL:1999 definierten Konzepte für benutzerdefinierte Routinen (Prozeduren und Funktionen) und die in SQLJ Teil 1 definierte Implementierung von Routinen in Java. In Kapitel 4 beschäftigen wir uns dann mit objektorientierten Konzepten in SQL:1999, deren Nutzung in Java-Anwendungen (in JDBC 2.0 und SQL/OLB definiert) und deren Implementierung in Java, durch SQLJ Teil 2 spezifiziert. 2 Zugriff auf SQL-Datenbanken in Java 2.1 JDBC Der derzeitige De-facto-Standard zum Zugriff auf SQL-Datenbanken in Java ist JDBC [White 1999], eine funktionale Schnittstelle (»call-level interface«), deren Konzepte stark durch den für prozedurale Programmiersprachen etablierten SQL/CLI-Standard [ ] bzw. die als ODBC-Schnittstelle bekannte Implementierung dieses Standards geprägt sind. Die JDBC-Schnittstelle gehört zum Java Core API (ab JDK 1.1) und wird von allen großen Datenbankherstellern unterstützt. Eine detaillierte Betrachtung der JDBC-Schnittstelle ist in [White 1999] zu finden. An dieser Stelle soll ein kleines Beispiel genügen, das den grundlegenden Anwendungsaufbau bei der Benutzung von JDBC illustriert (siehe Beispiel 1). Die JDBC-Spezifikation definiert eine Reihe von Java-Interfaces, die zum Aufbau einer Datenbankverbindung (Schritt 1), Erzeugen von SQL-Befehlen (Schritt 2), zum Ausführen des Befehls (Schritt 3) und zur eventuellen Verarbeitung der Anfrageresultate (Schritt 4) benutzt werden. SQL-Befehle werden in JDBC generell als Java Strings kodiert und über generische Schnittstellen (wie z.b. Statement.executeQuery()) übermittelt. Dadurch steht JDBC-Anwendungen ein Beispielschema: CREATE TABLE employees ( empno INTEGER, name VARCHAR(40), addr VARCHAR(100), dept VARCHAR(30)) (1) Verbindungsaufbau String url = "jdbc:db2:mydatabase"; Class.forName( "COM.ibm.db2.jdbc.app.DB2Driver"); Connection con = DriverManager.getConnection(url, "stefan", "sqljava") (2) SQL Statement erzeugen String sqlstr = "SELECT name, address FROM Employees WHERE empno = 1234"; Statement stmt = con.createstatement( ); (3) SQL Statement ausführen ResultSet rs = stmt.executequery(sqlstr); (4) Resultat verarbeiten rs.next(); String name = rs.getstring(1); String addr = rs.getstring(2); rs.close(); Bsp. 1: JDBC zum Zugriff auf SQL-Datenbanken Datenbank-Spektrum 1/

2 hohes Maß an Flexibilität zur Verfügung, da Befehle zur Laufzeit der Anwendung dynamisch (beispielsweise aufgrund von Benutzereingaben bestimmt) erzeugt und ausgeführt werden können. 2.2 SQL Object Language Bindings Der von JDBC und anderen funktionalen Zugriffsschnittstellen verfolgte Ansatz bietet zwar ein großes Maß an Flexibilität, bringt jedoch auch einige signifikante Nachteile mit sich, auf die nachfolgend noch näher eingegangen werden soll. Ein neuer Standard, genannt SQL Object Language Bindings 1 (SQL/OLB) [X ], hat diese Nachteile beseitigt. SQL/OLB verfolgt den traditionellen Ansatz der statischen Einbettung von SQL-Befehlen in eine Programmiersprache und erreicht damit eine engere Integration bzw. Kopplung von SQL und Java. Beispiel 2 zeigt die SQL/OLB-Version des in Beispiel 1 mit Hilfe von JDBC durchgeführten Datenbankzugriffs. Eingebettete SQL-Befehle werden als sog. SQL/OLB Klauseln spezifiziert (durch das token #sql gekennzeichnet) und von einem Vorübersetzer analysiert und umgewandelt. Java-Variablen (z.b.»name«,»addr«) können als Hostvariablen (mit einem führenden Doppelpunkt versehen) direkt im SQL-Befehl referenziert werden, wodurch sich auf einfache Weise die Übergabe von Parametern bzw. mit Hilfe der»select... INTO«-Syntax die Zuweisung von Anfrageresultaten bewerkstelligen lässt. In Erweiterung des Konzepts der Hostvariablen lassen sich in SQL/OLB auch komplette Ausdrücke 1. Dieser Standard wird oft aus historischen Gründen auch als»sqlj Part 0 eingebettetes SQL in Java«bezeichnet. (1) Verbindungsaufbau String url = "jdbc:db2:mydatabase"; Class.forName( "COM.ibm.db2.jdbc.app.DB2Driver"); DefaultContext.setDefaultContext( new DefaultContext(url, "stefan", "sqljava", false)); (2) SQL Statement ausführen und Resultate verarbeiten String name, addr; #sql {SELECT name, address INTO :name, :addr FROM Employees WHERE empno = 1234; System.out.print(name +, + addr); Bsp. 2: SQL/OLB Einbettung von SQL in Java oder host expressions (z.b. :(a + b)) übergeben. Verbindungen zur Datenbank werden in SQL/OLB durch Verbindungskontexte (connection contexts) repräsentiert, auf die sich SQL/OLB-Klauseln direkt beziehen können. Alternativ kann ein sog. Defaultkontext eingerichtet werden (siehe Schritt 1 in Beispiel 2), auf den SQL/OLB-Klauseln implizit zurückgreifen. Anhand von Beispiel 2 lassen sich die Vorteile von SQL/OLB gegenüber JDBC verdeutlichen. Die engere Spracheinbettung führt zu wesentlich einfacheren und kürzeren Codefragmenten zum Datenbankzugriff. Der SQL/OLB Vorübersetzer kann zur Übersetzzeit auf das Zielschema der Datenbank zugreifen und sowohl die Typkorrektheit als auch die Schemakorrektheit der SQL-Befehle prüfen (d.h. Existenz und Typkompatibilität der Spalten»Employees.name«,»Employees.addr«). Dadurch werden Programmierfehler wesentlich früher im Entwicklungsprozess erkannt. Datenbankhersteller können zusätzliche Optimierungstechniken zur Performanzsteigerung einsetzen, wie z.b. Abspeicherung und Aufruf von vorübersetzten Ausführungsplänen in der Datenbank. Diese Techniken ermöglichen außerdem den Einsatz von statischer SQL-Autorisierung, die Benutzerprivilegien zur Ausführung von (SQLJ-)Programmen unterstützt und eine sinnvolle Alternative zu weiterreichenden Privilegien (wie z.b. volle Lese- und Schreibrechte auf eine Tabelle) bietet. Der einzige Nachteil von SQL/OLB ist die Einschränkung auf statisch eingebettetes SQL. Es ist nicht möglich, SQL-Befehle als Inhalt von SQL/OLB zur Laufzeit dynamisch zu erzeugen. Dieser Nachteil lässt sich allerdings leicht aufgrund der Interoperabilität von SQL/OLB und JDBC umgehen. Das gleiche Anwendungsprogramm kann sowohl SQL/OLB als auch JDBC-Codefragmente enthalten, die über die gleiche Verbindung zur Datenbank auch innerhalb der gleichen Transaktion ablaufen können. Des Weiteren können Iteratoren (SQL/OLB s Mechanismus zum Umgang mit Resultatsmengen) in JDBC result sets umgewandelt werden und umgekehrt. Im Gegensatz zu traditionellen Implementierungen für eingebettetes SQL garantiert SQL/OLB Binärportabilität von Anwendungen über Plattformen und Datenbankhersteller hinweg. Dieses hohe Maß an Portabilität wird unter anderem durch die Portabilitätseigenschaften von Java (kompilierte SQL/OLB-Anwendungen sind»100% pure Java«), die Herstellerunabhängigkeit des Vorübersetzers und die Nutzung von JDBC als Defaultinfrastruktur zur Ausführung der Datenbankzugriffe garantiert. Ein so genanntes»customization framework«erlaubt das Hinzufügen einer beliebigen Anzahl von herstellerspezifischen Optimierungen, die nur auf den entsprechenden Herstellerplattformen zum Einsatz kommen. In der Abwesenheit solcher»customizations«erfolgt der Datenbankzugriff über»standard«jdbc. 3 Benutzerdefinierte Routinen Ein wesentlicher, von vielen als längst überfällig betrachteter Beitrag zur Erweiterbarkeit von SQL-Datenbanksystemen leistete der SQL:1999 Standard durch die Einführung von benutzerdefinierten Routinen, die als Prozeduren oder Funktionen auf dem Datenbankserver oder gar in der Datenbank selbst abgespeichert und durch SQL-Befehle aufgerufen bzw. ausgeführt werden können. In diesem Kapitel betrachten wir zuerst die in SQL:1999 definierten Grundkonzepte für benutzerdefinierte Routinen und konzentrieren uns dann auf die durch SQLJ definierten Konzepte zur portablen Implementierung solcher Routinen in Java. 3.1 SQL:1999-Routinen Der SQL-Standard [ ] definiert das Konzept der in SQL aufgerufe- 26 Datenbank-Spektrum 1/2001

3 CREATE PROCEDURE modify_address (empno INTEGER, addr VARCHAR(100))... CREATE PROCEDURE avgsal ( IN dept VARCHAR(30), OUT avg DECIMAL(10, 2))... CREATE PROCEDURE ranked_emps (dept VARCHAR(30)) DYNAMIC RESULT SETS 1... CREATE FUNCTION city (addr VARCHAR(100)) RETURNS VARCHAR(30)... Bsp. 3: Erzeugen von benutzerdefinierten Routinen in SQL:1999 der Aufruf von vordefinierten Basisfunktionen. Dies wird in Beispiel 4 für die Prozedur»modify_address«und die Funktion»city«verdeutlicht, die hier dazu benutzt wird, den Wohnort eines Angestellten zurückzuliefern. SQL:1999 führt außerdem ein neues Benutzerprivileg (EXECUTE) ein, mit dem die Ausführung von Routinen kontrolliert werden kann. 3.2 SQLJ Teil 1 Routinen in Java nen Routinen (SQL-invoked routines), das im Wesentlichen zwei Routinentypen zur Verfügung stellt Prozeduren (stored procedures) und benutzerdefinierte Funktionen (user-defined functions, UDFs). Routinen können (als externe Routinen) entweder in einer externen Programmiersprache, wie C oder Java, oder aber (als SQL-Routinen) in einer prozeduralen SQL-Erweiterung, die durch den SQL/ PSM-Standard [ ] definiert wird, implementiert werden. Unabhängig von der Implementierung wird für jede Routine im Rahmen von DDL-Befehlen eine Signatur definiert, welche den Namen der Routine und deren Parameter und Resultate anhand von SQL-Datentypen beschreibt. Beispiel 3 enthält eine Reihe von (unvollständigen) Befehlen zum Erzeugen von Routinen, in denen nur die Signatur der jeweiligen Routine spezifiziert ist. (Zusätzliche Klauseln, hier mit»...«angedeutet, werden benötigt, um weitere Eigenschaften bzw. die Implementierung der Routinen zu spezifizieren.). Für Prozeduren und Funktionen gelten hier unterschiedliche Regeln. So werden für Prozeduren (stored procedures) verschiedene Parametermodi unterstützt. Neben den IN-Parametern gibt es so genannte INOUT- und OUT-Parametermodi, durch die eine Prozedur die (von ihr geänderte/gesetzte) Wertebelegung von Parametern an die aufrufende Anwendung zurückgeben kann. Beispielsweise ist für die Prozedur»avg_sal«ein OUT- Parameter»avg«definiert, der das Durchschnittsgehalt aller Angestellten einer Abteilung zurückliefert. Nach dem Aufruf der Prozedur werden die Werte solcher Parameter den beim Aufruf als Argumente verwendeten Variablen oder Parametern zugewiesen. Des Weiteren können stored procedures auch eine beliebige Anzahl von dynamischen Resultatstabellen (dynamic result sets) zurückliefern, die dann von der aufrufenden Applikation genau wie die Resultate von Anfragen weiterverarbeitet werden können (siehe Prozedur»ranked_emps«). Als Teil der Signatur wird für solche Resultatstabellen nur die maximale Anzahl der zurückgegebenen Tabellen spezifiziert. Weder die exakte Anzahl noch die Form der Tabellen (im Sinne von Anzahl und Datentypen der Spalten) wird definiert. Im Gegensatz zu stored procedures haben UDFs nur IN-Parameter und geben genau ein Resultat zurück, dessen Datentyp wohldefiniert ist. Die Funktion»city«beispielsweise extrahiert aus einem (formatierten) Addressfeld den Namen der Stadt und liefert ihn als VARCHAR(20) character string zurück. Das von objektorientierten Programmiersprachen her bekannte Konzept des overloading ist auch für Routinen in SQL unterstützt. Mehrere Funktionen mit dem gleichen Namen dürfen definiert werden, solange die Parameterlisten der Funktionen sich bzgl. der Datentypen der Parameter an mindestens einer Stelle unterscheiden. Für Prozeduren mit gleichem Namen wird jedoch eine unterschiedliche Anzahl von Parametern gefordert. Auch bezüglich der Aufrufsyntax unterscheiden sich Prozeduren und UDFs. Prozeduren werden mit Hilfe des CALL Statements aufgerufen, während der Aufruf von UDFs über die gleiche funktionale Aufrufsyntax (und an den gleichen Stellen) innerhalb beliebiger DML-Befehle (wie z.b. SELECT, INSERT, UPDATE, DELETE) erfolgen kann, wie SQL:1999 enthält keine detaillierte Beschreibung zur Implementierung externer Routinen, unterscheidet jedoch unterschiedliche»parameter styles«eine Definition der Bedeutung und Reihenfolge von Parametern, die beim Aufruf an externe Routinen übergeben werden und die z.b. Informationen über das Auftreten von Nullwerten im SQL-Aufruf enthalten können. Viele Details sind hier den Datenbankherstellern überlassen. Der Teil 1 des SQLJ-Standards, 1999 als separater ANSI/NCITS-Standard erschienen, füllt diese Lücke für Java und ermöglicht damit die portable Implementierung von benutzerdefinierten Prozeduren und Funktionen in Java. Des Weiteren adressiert SQLJ Anforderungen zur datenbankseitigen Speicherung von Javacode, der zur Routinenimplementierung benutzt wird. Das programmiersprachliche Konzept in Java, das dem der Routinen in SQL semantisch am nächsten liegt, ist das der statischen Methode, und auf diese Korrespondenz wird in SQLJ aufgebaut. Routinen werden durch statische Methoden in Java implementiert, wobei eine Methode mit Resultatstyp»void«zur Implementierung von stored procedures genutzt wird (da diese kein designiertes Resultat besitzen). Beispiel 5 demonstriert diese Korrespondenz anhand der Klasse»empRoutines«, deren Methoden»avgSalary«(Resultatstyp void) und»extractcity«zur Implementierung der Prozedur»avgSal«, bzw. der UDF»city«genutzt wird. Des Weiteren müssen die Datentypen der Methodenparameter (und für UDF- Implementierungen der Typ des Resul- CALL modify_address (1234, 5670 Lombard Str., San Francisco ) SELECT city (address) FROM Employees WHERE empno = 1234 Bsp. 4: Aufruf von benutzerdefinierten Routinen in SQL:1999 Datenbank-Spektrum 1/

4 tats) auf die SQL-Datentypen der entsprechenden Routine abbildbar sein. Zur Definition der Abbildbarkeit zieht SQLJ die im Rahmen der JDBC-Spezifikation [White 1999] definierten Typkorrespondenzen heran, die für jeden SQL-Datentyp einen korrespondierenden Basisdatentyp in Java (falls existent) und einen Objektdatentyp definieren. Beispielsweise ist der SQL-Type INTEGER sowohl auf den Java-Typ integer als auch auf die Objektklasse java.lang.integer abbildbar. Dagegen ist für zeichenbasierte Datentypen nur eine Abbildung auf Java-Stringobjekte möglich. Zur Unterstützung der Parametermodi INOUT und OUT für stored procedures bedient man sich einer bekannten Programmiertechnik, die Arraydatentypen einsetzt, um eine beliebige Anzahl von»ausgabeparametern«in Methodenaufrufen zu realisieren. Der Parameter»average«der Methode»avgSalary«ist bspw. vom Type BigDecimal[], korrespondierend zum OUT-Parameter»avg«der Prozedur»avgSal«. Die Implementierung der Methode kann den Wert dieses Parameters durch Zuweisung oder Änderung des (einzigen) Arrayelements setzen, und Java-Klasse implementiert das Verhalten der Prozeduren, UDF: ihn damit der Laufzeitumgebung des DBMS zur Verfügung stellen. 2 Die in Beispiel 5 beschriebene Implementierung demonstriert zusätzlich die Nutzung von SQL/OLB zum Datenbankzugriff innerhalb einer Routine. Die hier verwendete SQLJ Klausel bedient sich des Defaultverbindungskontextes, der in diesem Fall durch die Aufrufumgebung des Datenbanksystems zur Verfügung gestellt wird. Als Alternative zu SQL/OLB kann natürlich auch JDBC verwendet werden. Der nächste Schritt zur lauffähigen SQL-Routine ist das Installieren des (kompilierten) Java-Codes in der Datenbank. SQLJ definiert einen Satz vordefinierter Prozeduren, wie z.b. SQLJ.INSTALL_JAR, welche die Installation und Verwaltung von Java jar-files in der Datenbank ermöglichen. Der in Beispiel 5 verwendete Aufruf geht davon aus, dass der Bytecode der Klasse»empRou- 2. Zur Unterstützung von Resultatstabellen für stored procedures wird eine ähnliche Technik, basierend auf JDBC ResultSets bzw. SQLJ- Iteratoren angewandt. public class emproutines { public static void avgsalary ( String department, BigDecimal[] average) throws SQLException { #sql {SELECT AVG(salary) INTO :average[0] FROM Employees WHERE dept = :department; public static String extractcity (String address) { // code required to extract and return city... Installieren des SQLJ jar-files in der Datenbank: CALL SQLJ.INSTALL_JAR('file:/home/stefan/classes/Emps.jar', 'employee_jar') Vollständige DDL zum Erzeugen der Prozedur, UDF: CREATE PROCEDURE avgsal ( IN dept VARCHAR(30), OUT avg DECIMAL(10, 2)) EXTERNAL NAME employee_jar:employee.emproutines.avgsalary LANGUAGE JAVA PARAMETER STYLE JAVA CREATE FUNCTION city (addr CHAR(100)) RETURNS VARCHAR(30) EXTERNAL NAME employee_jar:employee.emproutines.extractcity LANGUAGE JAVA PARAMETER STYLE JAVA Bsp. 5: Implementierung von benutzerdefinierten Routinen in Java tines«in einem jar-file»emps.jar«gespeichert wurde, und installiert diesen jarfile unter dem Namen»employee_jar«in der Datenbank. Dieser Name kann nun in den DDL-Befehlen zur Definition der stored procedure bzw. UDF benutzt werden, um für die Implementierung in der EXTERNAL NAME-Klausel auf die Klassen und Methoden in diesem jar-file zu verweisen. Des Weiteren werden die Routinen durch die Klauseln LANGUA- GE JAVA und PARAMETER STYLE JAVA als SQLJ-Routinen ausgewiesen. 4 Objektorientierung in SQL und Java Eine der wichtigsten Neuerungen in SQL:1999 [ ] ist das Konzept der benutzerdefinierten, strukturierten Datentypen, oft als objekt-relationales SQL bezeichnet. Eindeutig durch die Entwicklungen im Bereich objektorientierter Datenbanksysteme und Programmiersprachen motiviert, unterstützt SQL:1999 hiermit Konzepte zur strukturierten und verhaltensmäßigen Objektorientierung, um den Anforderungen moderner Anwendungen bzgl. Erweiterbarkeit, semantischer Modellierung und Integration von bzw. Suche über Non-Standard-Datentypen gerecht zu werden. Gerade in der Endphase der Fertigstellung von SQL:1999 war der Erfolg und die Wichtigkeit von Java ein wesentlicher Einfluss auf die Eigenschaften des SQL-Objektmodells, und man setzte alles daran, eine möglichst große Synergie bzw. Abbildbarkeit von Java- und SQL-Objekten zu erlangen. 4.1 Strukturierte Datentypen in SQL Strukturierte Datentypen in SQL ermöglichen die Definition von Objektstruktur (Attributen) und Verhalten (Methoden). Konzeptionell ist das in SQL verfolgte Modell sehr stark dem Klassenmodell in Java angeglichen. SQL unterstützt komplexe Objektstrukturen (d.h., Attributtypen können wiederum strukturierte Datentypen sein), statische und dynamische (Instanz-)Methoden, Konstruktoren und Vererbungsbeziehungen (single inheritance). Methoden können überladen werden (overloading), und geerbte Methoden sind auf der Ebene eines Subtyps reimplementierbar (overriding). Zur Laufzeit wird der Instanzdatentyp eines Objekts 28 Datenbank-Spektrum 1/2001

5 CREATE TYPE Address ( number INTEGER, street VARCHAR(30), city VARCHAR(30), STATIC METHOD country( ) RETURNS CHAR(3), METHOD print() RETURNS VARCHAR(100), METHOD changeaddress (varchar(100)) RETURNS Address SELF AS RESULT) CREATE TYPE BusinessAddress UNDER Address ( company VARCHAR(30),...) Bsp. 6: Definition strukturierter Datentypen in SQL:1999 zur Auswahl der Methodenimplementierung berücksichtigt (i.e. dynamic dispatch), und der Algorithmus zur Methodenauswahl ist semantisch äquivalent zu dem in Java definierten Verfahren. Beispiel 6 illustriert Teile der oben genannten Aspekte. Die gezeigten DDL- Befehle erzeugen einen benutzerdefinierten Typ»Address«mit Attributen»number«,»street«und»city«, einer statischen Methode»country«und dynamischen Methoden»print«, die eine Adresse in eine (druckbare) Zeichenkette umwandeln, und»changeaddress«, die eine solche Zeichenkette verarbeitet und die Adressattribute entsprechend verändert. Des Weiteren wird ein Type»Business- Address«als Subtyp von»address«definiert, mit einem zusätzlichen Attribut»company«. Für diesen Typ wäre auch das Überschreiben der Methoden»print«und»changeAddress«möglich (bzw. ratsam) auf die Details, sowie die Implementierungen der Methoden selbst, verzichten wir hier. Strukturierte Datentypen können auf zwei unterschiedliche Arten zum Einsatz kommen. Zum einen können sie (anstelle eines vordefinierten Typs) als Typ eines Attributs bzw. einer Tabellenspalte verwendet werden (siehe Spalte employees.addr in Beispiel 7). Wichtig ist, dass hierbei das aus der OO-Programmierung bekannte Konzept der Substituierbarkeit gewährleistet bleibt, welches garantiert, dass überall dort, wo eine Instanz eines Typs vorkommen kann, auch eine Instanz eines Subtyps auftreten darf. D.h., die Spalte»addr«kann zur Laufzeit sowohl Instanzen des Typs»Address«als auch Instanzen von Subtypen, wie z.b.»businessaddress«, enthalten. Zusätzlich können strukturierte Datentypen zur Definition von Tabellen (so genannte getypte Tabellen) benutzt werde. Beispielsweise lässt sich der gleiche»address«-datentyp zur Definition einer Tabelle»addresses«verwenden, deren Tabellenspalten selbst nun aufgrund der Typstruktur definiert sind (d.h.,»addresses«hat nun drei Spalten»number«,»street«und»city«). Analog zur Typhierachie lassen sich für getypte Tabellen auch Tabellenhierarchien definieren, wobei eine Subtabelle als logische Teilmenge der Supertabelle betrachtet werden kann (z.b. alle»businessaddresses«sind auch»addresses«). Objekte in getypten Tabellen sind weiterhin durch einen (hierarchieweit eindeutigen) Objektidentifikator (OID) gekennzeichnet, der entweder benutzerdefiniert oder systemdefiniert vergeben werden kann. Diese OIDs bilden des Weiteren die Grundlage für Referenzdatentypen, die zur direkten Modellierung von Referenzbeziehungen zu Objekten in getypten Tabellen benutzt werden können. Leider ist eine detaillierte Diskussion dieser Aspekte im Rahmen dieses Tutorials nicht möglich. Beispiel 7 zeigt weiterhin Befehle zur Datenmanipulation, die neue Objekte in die Datenbank einfügen, existierende Objekte verändern sowie auf Objektinformation zugreifen. Das Erzeugen von Objekten ist, genau wie in Java, über den NEW Operator möglich, der benutzerdefinierte Konstruktormethoden aktiviert bzw. einen system-definierten, parameterlosen Konstruktor ausführt, falls durch den Benutzer kein solcher definiert wurde. Das erste UPDATE Statement illustriert den Aufruf der»changeaddress«- Methode (addr.changeaddress(..)), die ein geändertes Adressobjekt zurückliefert, das Resultat dieses Aufrufs wird dann der Spalte»addr«zugewiesen. Das zweite Statement ändert das»city«-attribut des Adressobjekts und illustriert damit die (Java-konsistente) Syntax zum direkten Zugriff auf Attribute innerhalb eines Objekts. Die gleiche Syntax ist an beliebiger Stelle zum Zugriff auf Objektinformation erlaubt. Aufrufe von statischen Methoden erfolgen mit Hilfe eines»::«-operators (z.b. Address::Country()). Um eine zu starke»überladung«des».«- Operators in SQL zu vermeiden, hat man hier bei der Standardisierung eine syntak- Nutzung als Typ einer Tabellenspalte CREATE TABLE employees ( empno INTEGER, name VARCHAR(40), addr Address, dept VARCHAR(30)) Objekt kreieren/einfügen INSERT INTO employees VALUES(1234, 'John Doe', NEW Address( ), Shipping ) Objekt verändern UPDATE employees SET addr = addr.changeaddress('1234 Parkway Dr., San Leandro') WHERE name = 'John Doe' UPDATE employee SET addr.city = Santa Cruz WHERE empno = 1234 Auf Objektinformation zugreifen SELECT addr.print( ), Address::country() FROM employees WHERE addr.city = 'San Leandro' Objekte zurückliefern SELECT name, addr FROM employees WHERE addr.city = 'Santa Cruz' Bsp. 7: Strukturierte Datentypen in SQL Datenbank-Spektrum 1/

6 tische Inkonsistenz mit Java in Kauf genommen. Wie im letzten SELECT-Befehl illustriert, ist es durchaus auch möglich, anstelle einzelner Attribute die komplette Objektstruktur (z.b. ein Adressobjekt) zurückzuliefern. SQL:1999 definiert zwei Mechanismen, um diese Objektstrukturen auf der Anwendungsseite weiterzuverarbeiten. Zum einen können, genau wie für SQL large objects und array types, so genannte»locators«verwendet werden, welche sozusagen einen Surrogatwert zurückliefern, der anstelle des eigentlichen noch im Datenbankserver befindlichen Objekts in SQL-Befehlen verwendet werden kann. Zum anderen können für jeden strukturierten Datentyp so genannte Transformationsfunktionen und -methoden im Datenbankserver definiert und registriert werden, die ein strukturiertes Objekt in einen vordefinierten Datentyp umwandeln (und umgekehrt). Diese Funktionen werden dann automatisch ausgeführt, wenn eine Instanz des entsprechenden Objekttyps selektiert wird. 4.2 Unterstützung von SQL-Objekten in JDBC und SQL/OLB Die oben genannten Transformationsfunktionen stellen zwar eine gewisse Infrastruktur zur Manipulation von SQL- Objekten in Anwendungen zur Verfügung, überlassen jedoch dem Anwendungsentwickler ein relativ hohes Maß an Eigenarbeit. So muss der Entwickler selbst für ein geeignetes Kodierungsschema sorgen, das im allgemeinen Fall mit heterogenen Datentypen (d.h. Subtypinformation), geschachtelten Objekten und unterschiedlichen Betriebssystemplattformen umgehen muss. Gerade für objektorientierte Sprachen wie Java wünscht man sich aufgrund der Kompatibilität der Objektmodelle einen wesentlich einfacheren und anwenderfreundlicheren Ansatz. Mit diesem Ziel wurden für JDBC [White 1999] Erweiterungen definiert, die eine direkte Abbildung von SQL-Objekttypen auf Java-Klassen ermöglichen 3. Die Abbildungsfunktionalität ba- 3. Als Defaultabbildung (vor allem für dynamische Anwendungen) unterstützt JDBC 2.0 auch die Materialisierung von SQL-Objekten als Java-Vektoren. Hierauf wird an dieser Stelle nicht näher eingegangen. siert auf folgenden grundlegenden Konzepten: Der JDBC Treiber implementiert Java-Interfaces (SQLInput, SQLOutput), die das attributweise Lesen und Schreiben der Objektzustandsinformation ermöglichen. Das interne Format dieser Information ist herstellerabhängig. Der Anwender implementiert zu den SQL-Objekttypen korrespondierende Java-Klassen (oder erweitert existierende Klassen), die ein Java-Interface (SQLData) implementieren, dessen Methoden (readsql(), writesql()) die SQL-Objektzustandsinformation in die internen Zustandsvariablen der Java-Objekte übertragen (und umgekehrt). Diese Methoden nutzen die vom JDBC-Treiber bereitgestellten SQLInput/SQLOutput-Schnittstellen 4. Beispiel 8 zeigt eine solche Java- 4. Die Implementierung dieser Funktionen ist sehr schematisch und lässt sich einfach automatisch generieren (bspw. im Rahmen der Funktionalität von Entwicklungswerkzeugen). Java-Klasse»Residence«Klasse (Residence) und skizziert die Implementierung der readsql/write- SQL-Methoden. Die Klasse»Residence«soll zur Manipulation von SQL»Address«-Objekten genutzt werden. Eine Abbildungstabelle (ein Java- Map-Objekt), die die Korrespondenz zwischen SQL-Typen und Java-Klassen festhält und an einer JDBC-Connection»verankert«wird. Der Zugriff auf das SQL-Objekt vom Typ»Address«, bzw. dessen Materialisierung als»residence«-objekt in Java kann nun aus Benutzersicht durch den gleichen Mechanismus erfolgen, der jeden beliebigen Resultatwert als Java-Objekt materialisiert durch den Aufruf von Result- Set.getObject(). Beim entsprechenden Aufruf in unserem Beispiel (rs.getobject(2)) werden nun die folgenden Schritte (intern) ausgeführt: public class Residence implements SQLData { public int door; public String street; public String city; public void readsql(sqlinput stream,...) throws SQLException { door = stream.readint(); street = stream.readstring(); city = stream.readstring(); public void writesql(sqloutput stream,...) throws SQLException { stream.writeint(door); stream.writestring(street); stream.writestring(city); Zugriff auf strukturierte Objekte in JDBC String name; Residence addr; ResultSet rs = stmt.executequery( "SELECT name, address FROM Employees e WHERE empno = 1234"); rs.next( ); name = rs.getobject(1); Residence addr = (Residence)rs.getObject(2); Zugriff auf strukturierte Objekte in SQL/OLB String name; Residence addr; #sql {SELECT name, address INTO :name, :addr FROM Employees WHERE empno = 1234; Bsp. 8: Zugriff auf strukturierte Objekte in JDBC und SQLJ Der JDBC-Treiber, der mit dem internen SQL-Objektformat vertraut ist, inspiziert den Objektzustand, um den dynamischen Typ des Objekts zu bestimmen. (Es wird vorausgesetzt, 30 Datenbank-Spektrum 1/2001

7 dass der Datenbankserver diese Information in den Objektzustand mit einkodiert.) Mit Hilfe der Abbildungstabelle, die vom Benutzer am JDBC-Connection- Objekt verankert wurde, bestimmt der Treiber die korrespondierende Java-Klasse und instanziiert diese Klasse. Der JDBC-Treiber ruft die readsql- Methode dieses Objekts auf und übergibt den Objektzustand als SQLInput-Objekt. Die readsql- Methode liest die Attribute des SQL- Objekts und setzt die entsprechenden Java-Objektvariablen. Das Objekt wird als Resultat des get- Object()-Aufrufs an die Anwendung weitergegeben. Im umgekehrten Fall (d.h. beim Setzen von Objektparametern durch setobject()) läuft in ähnlicher Weise ein inverser Vorgang ab. Für den SQL/OLB-Standard wurde im Rahmen der ISO-Standardisierung [ ], basierend auf den gleichen JDBC 2.0-Interfaces, ähnliche Funktionalität definiert. Diese ermöglicht in gleicher Weise die Selektion von SQL- Objekten und Materialisierung als Java- Objekte (siehe Beispiel 8). definierten Schnittstellen (wie SQLData), um die Abbildbarkeit bzw. Umwandlung von SQL-Objekten in Java (und umgekehrt) zu ermöglichen. Zum Dritten erweitert SQLJ auf einfache Weise die CREATE TYPE-Syntax von SQL, um die Korrespondenz von SQL zu Java zu beschreiben. In Beispiel 9 haben wir auf einfache Weise die bereits vorgestellte Klasse»Residence«um Methodenschnittstellen erweitert, die als Implementierung der Methoden des bereits vorab beschriebenen SQL-Address-Typs dienen können. Die vollständige Syntax zum Erzeugen des Typs»Address«ist ebenfalls angegeben. Darin wird sowohl auf der Typebene (zwischen Address und Residence) als auch für die einzelnen Methoden die Korrespondenz zwischen SQL und Java über die EXTERNAL NAME-Klausel definiert. Zwei Details seien hier zum Schluss noch kurz erläutert. Zum einen ermöglicht SQLJ, neben der Abbildung von statischen Methoden, die (eingeschränkte) Nutzung von statischen Java-Variablen. Die Klausel EXTERNAL VARIABLE NAME 'country' zur Definition der SQL- Methode»country«nimmt Bezug auf die entsprechende Variable in Java. Diese Klausel führt dazu, dass zur Laufzeit beim Aufruf der SQL-Methode»country«anstelle eines Java-Methodenaufrufs ein Zugriff auf die statische Java-Variable erfolgt. Dies erlaubt den lesenden Zugriff auf statische Variablen, die sehr oft zur Definition von Konstanten benutzt werden. Schreibender Zugriff auf statische Variablen ist nicht unterstützt, und die Effekte eines solchen Zugriffs im Rahmen anderer Methoden ist nicht wohldefiniert bzw. implementierungsabhängig. Im Rahmen von Datenbanksystemen im Mehrbenutzerbetrieb ist das Konzept statischer Variablen schwer nachvollziehbar bzw. definierbar. Aus diesem Grund hat man in SQLJ davon abgesehen. Ein weiteres, wesentlich wichtigeres Detail betrifft die Unterstützung von Methoden, die den Objektzustand verändern. Hier unterscheiden sich SQL-Datenbanken wesentlich von objektorientierten Programmen. In Java tritt eine Zustandsänderung als Seiteneffekt eines Methodenaufrufs auf und materialisiert sich»automatisch«im Objektzustand einer Objektvariablen. Dahingegen unterstützt SQL ein wertbasiertes, funktionales Modell, in dem eine persistente Zustandsänderung nur durch ein explizites UP- DATE-Statement erfolgen kann. Zum Zweck einer Zustandsänderung muss ein Methodenaufruf deshalb eine veränderte 4.3 SQLJ Teil 2 SQL-Typen in Java Die bisher vorgestellten Mechanismen ermöglichen es uns, äquivalente Objektmodelle in Java und SQL aufzubauen, und SQL-Objekte in korrespondierende Java- Objekte umzuwandeln. Ein weiterer Baustein fehlt noch, um das Integrationsbild der Objektmodelle in Java und SQL zu vervollständigen, und dieser wird durch SQLJ Teil 2 [ ] geliefert, der die Implementierung von SQL-Typen in Java definiert. Dadurch wird es uns möglich, das Verhalten (d.h. die Objektmethoden) der SQL-Objekttypen mit Hilfe von Java- Objektmethoden zu implementieren und damit das Objektverhalten innerhalb und außerhalb der SQL-Datenbank auf die gleiche Implementierungsbasis zu stellen. SQLJ Teil 2 ist eine direkte Erweiterung von SQLJ Teil 1. Die gleichen Regeln gelten für die Abbildbarkeit von primitiven Datentypen, die gleichen Prozeduren zur Verwaltung von SQLJ jar-files können benutzt werden. Zusätzlich nutzt SQLJ Teil 2 die durch JDBC 2.0 bereits Java-Klasse public class Residence implements Serializable, SQLData { public int door; public String street; public String city; public static String country = "USA"; public String printaddress( ) {...; public void changeresidence(string adr) {... // parse and update fields... // SQLData methods public void readsql(sqlinput in, String type) {... ; public void writesql(sqloutput out) {... ; SQL DDL CREATE TYPE Address EXTERNAL NAME 'residence_jar:residence' LANGUAGE JAVA ( number INTEGER EXTERNAL NAME 'door', street VARCHAR(30) EXTERNAL NAME 'street', city VARCHAR(30) EXTERNAL NAME 'city', STATIC METHOD country( ) RETURNS CHAR(3) EXTERNAL VARIABLE NAME 'country', METHOD print() RETURNS VARCHAR(100) EXTERNAL NAME 'printaddress', METHOD changeaddress (varchar(100)) RETURNS Address SELF AS RESULT EXTERNAL NAME 'changeresidence' ) Bsp. 9: Implementierung von strukturierten Datentypen mit SQLJ Datenbank-Spektrum 1/

8 Kopie des SELF-Objekts zurückliefern, die dann in einem UPDATE-Befehl zugewiesen werden kann. Dieser fundamentale Unterschied wird durch SQLJ dadurch überbrückt, dass im CREATE TYPE-Befehl Update-Methoden durch eine SELF AS RESULT-Klausel identifiziert werden (wie z.b.»changeaddress«). Durch diese Markierung ist das Datenbanksystem in der Lage, zur Laufzeit die Rückgabe des geänderten Objekts zu übernehmen (unabhängig vom eigentlichen Resultat der Java-Methode). Die Java-Methode die die Zustandsänderung implementiert, kann deshalb weiterhin der in Java üblichen Programmiertechnik folgen und muss nicht selbst für die Rückgabe des geänderten Objekts sorgen. 5 Zusammenfassung Die Synergie und Integration von SQL und Java waren in den letzten Jahren (und sind immer noch) ein wichtiges Ziel in der Entwicklung von Standards. Dieses Tutorial hat die wesentlichen Resultate dieser, in unseren Augen sehr erfolgreichen Bemühungen aufgezeigt. Der einfache Zugriff auf SQL-Daten aus Java-Anwendungen heraus, die Konsistenz der Objektmodelle in SQL und Java, die einfache Abbildbarkeit von SQL-Objekten auf Java-Objekte und nicht zuletzt die direkte Nutzbarkeit von Java-Klassen und -Methoden zur Implementierung von SQL-Objekttypen und Objektverhalten steigern vehement die Produktivität von Anwendungsentwicklern vor allem im Bereich Web-basierter Anwendungen. Die Möglichkeit, Java-Klassen mehr oder minder unverändert als Objekttypen in SQL zu nutzen, bietet eine ideale Voraussetzung zur Wiederverwendung von existierendem Java-Code in der Datenbank, bzw. zur Entwicklung von Java-Klassen, die sowohl auf der Anwendungsschicht bzw. der Middleware-Schicht einer Mehrschichtenarchitektur als auch aus Gründen der Funktionalität und Performanzsteigerung in der Datenbank, integriert in die Anfrageverarbeitung, ablaufen können. Fast alle großen Datenbankhersteller in der Industrie (jedenfalls alle, denen Java wichtig ist) unterstützen heute immer größer werdende Teilmengen der in diesem Tutorial beschrieben Funktionalität, sodass auch dem praktischen Nutzung dieser Technologie nichts mehr im Wege steht. Aus Platzgründen konnten leider viele interessante Aspekte in den betreffenden Standards nicht oder nicht ausführlich genug diskutiert werden. Diese sind unter anderem in den im Literaturanhang aufgelisteten Buchpublikationen [Melton/Eisenberg 2000, Gulutzan/Pelzer 1999, White 1999] im Detail beschrieben. Literatur [Melton/Eisenberg 2000] Melton,J.; Eisenberg, A.: Understanding SQL and Java Together A Guide to SQLJ, JDBC, and Related Technologies, Morgan Kaufmann, [Gulutzan/Pelzer 1999] Gulutzan, P.; Pelzer, T.: SQL-99 Complete, Really : An Example- Based Manual of The New Standards, Cmp Books, [White 1999] White, S.: JDBC Api Tutorial and Reference: Universal Data Access for The Java 2 Platform, Addison Wesley Publishing Company, [ ] ANSI/ISO/IEC Information Technology Database Languages SQL Part 1: Framework (SQL/Framework), 1999 [ ] ANSI/ISO/IEC Information Technology Database Languages SQL Part 2: Foundation (SQL/Foundation), 1999 [ ] ANSI/ISO/IEC Information Technology Database Language SQL- Part 3: Call Level Interface (SQL/CLI), [ ] ANSI/ISO/IEC Information Technology Database Languages SQL Part 4: Persistent Stored Modules (SQL/PSM), [X ] ANSI/NCITS X DEC-1998 Database Languages SQL Part 10: Object Language Bindings (SQL/OLB), [ ] ISO/IEC :2000 Information technology Database languages SQL Part 10: Object Language Bindings (SQL/ OLB), [ ] ANSI/NCITS SEP SQLJ Part 1: SQL Routines using the Java (TM) Programming Language, [ ] ANSI/NCITS NOV SQLJ Part 2: SQL Types using the Java (TM) Programming Language, Stefan Deßloch IBM Silicon Valley Lab dessloch@us.ibm.com 32 Datenbank-Spektrum 1/2001