Universität Paderborn. Fachbereich 17 Mathematik/Informatik Arbeitsgruppe Softwaretechnik Prof. Dr. W. Schäfer Warburger Str Paderborn

Transkript

1 Universität Paderborn Fachbereich 17 Mathematik/Informatik Arbeitsgruppe Softwaretechnik Prof. Dr. W. Schäfer Warburger Str Paderborn JDBC & ODMG Seminarausarbeitung im Rahmen der Projektgruppe Entwicklung eines verteilten multimedia Systems mit Hilfe von Design Pattern im Projekt von Mike Liebrecht Greve Str Paderborn Paderborn, August 2001

2 Inhaltsverzeichnis 1 Einleitung 2 2 JDBC java.sql.drivermanager Treiber java.sql.connection java.sql.statement java.sql.resultset java.sql.resultsetmetadata Fazit JDBC 11 3 ODMG Objektmodell / ODL Datenbanken Objekttypen Objekte Operationen Attribute Transaktionen Object Query Language Java Binding Java ODL Java OML 18 4 Fazit JDBC / ODBC 22 5 Literaturverzeichnis 23 1

3 1 Einleitung Diese Seminararbeit stellt aus Sicht der Programmiersprache Java zwei unterschiedliche Ansätze vor Daten in Datenbanken zu speichern und zu manipulieren. Der erste Ansatz JDBC, oft auch fälschlicherweise Java Database Connectivity genannt, dient als Vermittler zwischen Java und relationalen Datenbanken. Diese Vermittlerrolle ist als Schnittstelle implementiert und seit der Java Version 1.1 Bestandteil der Standard-API. Im Kapitel JDBC werden die wichtigsten Klassen / Interfaces der API vorgestellt, deren Benutzung erläutert, sowie die Einschränkung auf bestimmte Datenformen skizziert. Aus der Beschränkung JDBC s auf SQL-konforme Datenstrukturen wurde das zweite Konzept der objektorientierten Datenbank-Management-Syteme (ODBMS) entwickelt. Dieser Ansatz unterscheidet sich erheblich von JDBC. JDBC ist lediglich eine Schnittstelle die SQL-Aufrufe in Java kapselt. Die Lösung der ODMG (Object Database Management Group) beinhaltet einerseits Schnittstellen zu verschiedenen Programmiersprachen, unter anderem Java (Java-Binding), andererseits aber auch sein eigenes Speicherkonzept. Das heißt als Daten-Speicher dienen nicht SQL-Datenbanken sondern eigens entwickelte objektorientierte Datenbanken. In ihnen werden die Daten als verlinkte Objekte (mit Eigenschaften) gespeichert und nicht in Tabellen wie in relationalen Datenbanken. Aus dieser Art der Speicherung resultieren Vorteile gegenüber JDBC + SQL die im Kapitel ODMG aufgezeigt werden. Anhand des kleinen Beispiels einer Studentenverwaltung wird zu jedem Konzept gezeigt wie über die jeweilige Schnittstelle eine Verbindung zur Datenbank aufgebaut wird und Daten gespeichert, gelöscht oder manipuliert werden können. 2

4 2 JDBC Um aus Programmiersprachen heraus auf SQL-Datenbanken zugreifen zu können gibt es mittlerweile die unterschiedlichsten Ansätze. Zum einen bietet heutzutage fast jeder Datenbankhersteller seine eigene Programmierschnittstelle an, zum anderen gibt es Ansätze wie ODBC (Open Database Connectivity) die eine allgemeine Schnittstelle zum Zugriff auf Datenbanken anbieten. Die Nachteile des ODBC-Ansatzes liegen in der begrenzten Verfügbarkeit (nur auf Windows und Solaris Plattformen) und der Implementierung der Treiber in C++. Die umfassenden Sicherheitsmechanismen der Java-Applets (z.b. Web Anwendungen) werden bei Verwendung von C++ Binärcode ausgehebelt. Daher wurde für Java-Plattformen ein weiterer Ansatz entwickelt: JDBC JDBC ist die Standardschnittstelle zum Zugriff auf SQL-Datenbanken in Java. Seit Java 1.1 ist JDBC Bestandteil der Standard-API. In einen Satz gefasst stellt JDBC Methoden bereit um SQL-Anfragen in Java-Objekte zu kapseln und diese zur Ausführung an SQL-Datenbanken zu übergeben. JDBC besteht aus mehreren Klassen und Schnittstellen, die im Java-Package java.sql zusammengefasst sind. In dieser Seminararbeit stelle ich die Nutzung der 5 wichtigsten Klassen / Schnittstellen der JDBC-API vor: - java.sql.drivermanager Der Treibermanager - java.sql.connection Repräsentiert eine Verbindung zu einer Datenbank - java.sql.statement Kapselt die SQL-Anweisungen die an eine DB gestellt werden - java.sql.resultset Repräsentiert das Ergebnis einer SQL-Anfrage - java.sql.resultsetmetadata Bietet Möglichkeiten die MetaDaten einer Anfrage zu erfragen Als Grundlage meiner Einführung dient folgendes kleines Beispiel einer Studentenverwaltung: Datenbankname Zugriffsart ODBC-Name Server StudiVerwaltung ODBC Studiverw Local Attribute der Tabelle Studenten Vorname Nachname Studiengang MatrNr In den folgenden Kapiteln werden die Java-Anwendungen DBInit, DBRequest, DBUpdate entwickelt. DBInit füllt eine DB mit Daten, DBRequest stellt SQL-Anfragen an die DB StudiVerwaltung und DBUpdate manipuliert vorhandene Datenbestände. 3

5 2.1 Java.sql.DriverManager Der Treibermanager, implementiert in der Klasse java.sql.drivermanager, definiert durch Schnittstellen den Zugriff auf eine Datenbank. Jeder konkrete Treiber zu einer Datenbank implementiert diese Schnittstelle. Alle Methoden dieser Klasse sind vom Typ static (da nur ein Treibermanager pro Anwendung) und lassen sich in folgende 3 Gruppen unterteilen: - Laden und Registrieren von Treibern - Herstellen der Verbindung zur Datenbank - Konfiguration der Verbindung JDBC bietet 2 Varianten an um Treiber in einer Anwendung zu laden. Einmal durch explizites Laden des JDBC-Treibers per Class.forName. Dies ist die am Häufigsten eingesetzte Methode, dabei muss allerdings der Classpath des zu ladenen Treibers bekannt sein. Variante 1: Class c = Class.forName ( oracle.jdbc.driver.oracledriver ); Variante 2 nutzt die Systemeigenschaft sql.drivers. Diese umfasst eine Liste von Treibern, alle durch einen Doppelpunkt getrennt, die bei der Initialisierung des DriverManager automatisch geladen wird. Nach dem Laden des Treibers erfolgt die Registrierung desselbigen beim Treibermanager. Dies geschieht allerdings,transparent für den Programmierer, im Konstruktor des Treibers und muss nicht explizit ausgeführt werden. Da nun der Treiber beim Manager registriert ist, kann eine Verbindung zur Datenbank aufgebaut werden. Dafür stellt die Klasse DriverManager die 3-fach überladene Methode getconnection(..) zur Verfügung: static Connection getconnection (String url) throws SQLException; static Connection getconnection (String url, String user, String pw) throws SQLException; static Connection getconnection (String url, java.util.properties info) throws SQLException; Wie man sieht, brauchen alle 3 Methoden eine URL (Uniform Resource Locator) über die die zu nutzende Datenbank angesprochen wird. Diese hat folgende Struktur: jdbc:<subprotocol>:<subname>. Wobei <subprotcol> den Mechanismus zur Datenbankanbindung (z.b. ODBC) und <subname> den Identifikator der Datenbank bezeichnet. Beispiele(URL): jdbc:odbc:odbc2access jdbc:oracle:thin:@ipl6.upb.de:1521:mydb Als Rückgabe liefert getconnection(..) ein Objekt vom Typ Connection. Dieses Objekt repräsentiert eine Verbindung zur Datenbank. 4

6 Für unsere Java-Anwendungen die alle eine Verbindung zur Datenbank StudiVerwaltung auf unserem lokalen Rechner nutzen wollen, sieht der Quelltext dann wie folgt aus: import java.sql.* ; public class DBRequest { public static void main (String [] args) { try { // Der Treiber für die ODBC-Bridge wird geladen Class c = Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // Aufbau einer Verbindung über den ODBC-Namen Connection con = DriverManager.getConnection("jdbc:odbc:studiverw");... catch (Exception e) { System.out.println( e ) ; Wie das Connection - Objekt weiter genutzt wird um SQL-Anweisungen abzusetzen und Ergebnisse zu verarbeiten ist Gegenstand der Kapitel Statement und ResultSet Treiber Wie oben schon erwähnt müssen zu jedem Datenbank-Management-System Treiber entwickelt werden. Dabei werden die folgenden 4 Arten unterschieden: JDBC-ODBC-Bridge (Typ 1) Hier baut der JDBC-Treiber die Datenbankverbindung über die ODBC-Schnittstelle eines Windows- oder Solaris-Systems auf. Dabei werden die JDBC-Aufrufe in ODBC-Aufrufe umgewandelt. Der Vorteil liegt darin, das kein expliziter Treiber programmiert werden muss, denn man nutzt den vorhandenen ODBC- Treiber. Dies ist aber auch gleichzeitig ein großer Nachteil da externer Binärcode (externe Bibliotheken) verwendet wird und somit das Sicherheitskonzept der Applets umgangen wird. Native-API-Treiber (Typ 2) Hier greift der JDBC-Treiber direkt auf die vom DBMS für Clients bereitgestellten Bibliotheken zur Datenbankanbindung zu. Das heißt er verwendet wie schon bei der Bridge externen Binärcode, was auch zu den schon erwähnten Nachteilen führt. Diese beiden Treibertypen werden aufgrund der Nutzung von externem Binärcode nur als Hilfslösungen angesehen.zu den eigentlichen JDBC-Treibern werden nur die beiden folgenden Typen gezählt: 5

7 JDBC-Net-Treiber (Typ 3) Bei dieser Variante werden die JDBC -Aufrufe durch eine native DBMS-API in Aufrufe für ein spezielles DBMS (z.b. Sybase, Oracle) übersetzt. Dies hat den Vorteil das der JDBC-Treiber nicht mehr auf externen Binärcode zurückgreifen muss und somit vollständig in Java implementiert werden kann, inklusive Sicherheitskonzept. Native-Protokoll-Treiber(Typ 4) Dieser Treiber übersetzt JDBC-Aufrufe direkt in das spezifische Datenbankprotokoll, ohne dazu das Datenbank-API zu nutzen. Die Vorteile sind dieselben wie beim Typ 3 Treiber mit API. Aufgrund der proprietären Protokolle werden Treiber dieser Form meist von den Datenbankherstellern selbst angeboten. 2.2 Java.sql.Connection Ein Objekt des Interfaces Connection repräsentiert eine Verbindung zu einer Datenbank. Eine DB- Anwendung kann jedoch auch mehrere solcher Verbindungen zu einer Datenbank oder zu mehreren Datenbanken öffnen. Über eine dieser geöffneten Verbindungen können dann SQL-Anweisungen an die Datenbank gesendet werden. Die Methoden des Interfaces Connection lassen sich in die 3 Teilbereiche Erzeugen eines Statement- Objektes, Transaktionssteuerung und zusätzliche Funktionen unterteilen. Die zusätzlichen Funktionen umfassen die Methode zur Erzeugung eines DatabaseMetaData-Objektes und die Ausgabe von Warnmeldungen: DatabaseMetaData getmetadata() throws SQLException; SQLWarning getwarnings() throws SQLException; Transaktionssteuerung Nachfolgend sind die wichtigsten Methoden zur Transaktionssteuerung kurz aufgezeigt und erläutert: void commit() throws SQLException; void rollback() throws SQLException; void close() throws SQLException; Mit der Methode commit() wir der DB mitgeteilt das die Transaktion erfolgreich abgeschlossen wurde und die Änderungen in der DB permanent geschrieben werden können. Mit rollback() wird die aktive Transaktion abgebrochen und der ursprüngliche Zustand der DB wieder hergestellt. Die einzige, vom Programmierer häufiger genutzte Methode, close(), dient dazu die aktuelle Verbindung zu beenden und die genutzten Ressourcen freizugeben. 6

8 Erzeugen eines Statement-Objektes Damit unsere DB-Anwendung in der Lage ist SQL-Anweisungen an die Datenbank abzusetzen, müssen wir noch ein Statement - Objekt erzeugen. Dies geschieht mit der Methode createstatement() welche als Rückgabe ein Statement-Objekt liefert: Statement createstatement() throws SQLException; Für unsere Beispielanwendung hat das dann folgendes Aussehen: import java.sql.* ; public class DBRequest { public static void main (String [] args) { try { Class c = Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection con = DriverManager.getConnection("jdbc:odbc:studiverw"); catch (Exception e) { System.out.println( e ) ;... try { //Statement-Objekt erzeugen Statement stmt = con.createstatement(); catch (Exception e) { System.out.println( e ) ; 2.3 java.sql.statement Die Klasse java.sql.statement dient als Schnittstelle für die Verarbeitung einfacher SQL-Anweisungen ohne Parameter. Das heißt über ein Statement-Objekt werden einzelne SQL-Anfragen oder einzelne DDL- bzw. DML-Befehle gekapselt und an die Datenbank abgesetzt. Neben dem Interface Statement bietet JDBC noch java.sql.preparedstatement und java.sql.callablestatement an.preparedstatement erbt von Statement und bietet Funktionen an um SQL-Anfragen vorcompiliert beim DBMS vorzuhalten. Der Vorteil einer solchen Vorgehensweise ist die geringere Laufzeit der schon compilierten Anfrage. Wird die Anfrage an die Datenbank gestellt, müssen lediglich die aktuellen Parameter an die vorcompilierte Anfrage gebunden werden. CallableStatement stellt Funktionen zur Nutzung von gespeicherten Prozeduren zur Verfügung. Eine solche Prozedur muss natürlich zuvor in der Datenbank definiert werden. Hauptbestandteil dieses Kapitels soll aber die Ausführung von einfachen SQL-Befehlen und damit das Interface Statement sein. Statement stellt 3 Methoden bereit um SQL-Statements an eine Datenbank zu senden: ResultSet executequery (String sql) throws SQLException; 7

9 ExecuteQuery wird genutzt um SQL-Anfragen an eine Datenbank zu stellen. Dabei stellt der als String übergebene Parameter die SQL-Anweisung in der Form SELECT a,b,c FROM db WHERE d dar. Das Ergebnis dieser Anfrage wird in einem Objekt vom Typ ResultSet gespeichert. Die Klasse ResultSet stellt die geeigneten Methoden zur Verfügung um das Ergebnis zu verarbeiten. Aber dazu später im Kapitel ResultSet. Wie sieht nun unsere Beispielanwendung DBRequest mit einer SQL-Anweisung aus: Der boolsche Wert der als Rückgabe geliefert wird, gibt an ob das Ergebnis der Anfrage ein ResultSet- Objekt (true) und damit Ergebnis einer SQL-Anfrage ist, oder ein int-wert (false, Ergebnis einer DDL- oder DML-Anweisung). Falls true zurückgegeben wird, kann anhand der Methode getresultset() ein ResultSetimport java.sql.* ; public class DBRequest { public static void main (String [] args) { try { Class c = Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection con = DriverManager.getConnection("jdbc:odbc:studiverw"); catch (Exception e) { System.out.println( e ) ; makedbrequest(con); public static void makedbrequest (Connection con) { Statement stmt = con.createstatement(); //SQL-Anfrage ResultSet rsstudent = stmt.executequery( "SELECT * FROM Studenten" ) ; weitere Verarbeitung des Ergebnisses durch ResultSet stmt.close(); Die Methode int executeupdate (String sql) throws SQLException; dient dazu DDL- und DML-Anweisungen, das heißt CREATE TABLE, UPDATE oder DELETE an die Datenbank zu übermitteln. Wie auch schon bei executequery() erwartet executeupdate() den eigentlichen Befehl als Parameter. Der Rückgabewert int liefert bei DML-Anweisungen die Anzahl der von der Manipulation betroffenen Tupel und bei DDL-Anweisungen immer den Wert 0. boolean execute (String sql) throws SQLException; Die dritte Methode ermöglicht die Ausführung von Anweisungen die mehrere Ergebnisse zurückliefern. Dies kann z.b. bei gespeicherten Prozeduren auftreten, die mehrere DML- oder SQL-Anweisungen ausführen. 8

10 Objekt erzeugt werden. Ob weitere Ergebnisse vorliegen kann der Programmierer anhand der Methode getmoreresults() erfragen. Wird true zurückgegeben so ist das nächste Ergebnis ein ResultSet-Objekt. Bei false handelt es sich um den Rückgabewert einer DDL-, DML-Anweisung. Hier nun die Beispiele DBInit und DBUpdate: DBInit.java... Anbindung an die DB wie gehabt public static void makedbinit (Connection con) { Statement stmt=con.createstatement(); // Erzeugt die Tabelle Studenten stmt.executeupdate( "create table Studenten( Vorname char(15), Nachname char(15), Studiengang char(15), MatrNr int); // Füllt die Tabelle stmt.executeupdate("insert into Studenten values('philipp ','Hoven',Informatik,111111)" ); stmt.executeupdate("insert into Studenten values('mike ','Liebrecht',Informatik,222222)" ); stmt.close() DBUpdate.java... Anbindung an die DB wie gehabt public static void makedbupdate (Connection con) { Statement stmt=con.createstatement(); int count = Stmt.executeUpdate( update Studenten set MatrNr = where Nachname = Liebrecht ); System.out.println ( Anzahl der Änderungen: + count); stmt.close() 2.4 java.sql.resultset Die Ergebnisse einer SQL-Anfrage werden in JDBC in einem ResultSet Objekt gespeichert. Dieses Objekt stellt auch einen Iterator zur Verfügung um über die verschiedenen Tupel der Rückgabe iterieren zu können. Der Zugriff auf die einzelnen Tupel erfolgt über die Methode next(), welche solange true zurückliefert wie Tupel im ResultSet-Objekt vorhanden sind. Zum Zugriff auf die einzelnen Attribute des Tupels stellt java.sql.resultset die Varianten Zugriff über den Spaltenindex und Zugriff über den Namen zur Verfügung. Beide Varianten haben natürlich ihre 9

11 Implementierung als Methoden im java.sql.resultset. Als Beispiel führen wir hier die Methoden zum Zugriff auf ein String-Attribut an. Einmal über den Spaltennamen und einmal über den Spaltenindex: String getstring (String colname) throws SQLException; String getstring (int colindex) throws SQLException; Diese Methoden gibt es natürlich für jeden weiteren primitiven Datentyp (int, double, ). Eine weitere interessante Methode ist findcolumn. Sie liefert den Spaltenindex zu einem gegebenen Spaltennamen. Unsere DBRequest-Anwendung könnte nun mit Ergebnisbehandlung folgendes Aussehen haben: import java.sql.* ; Datenbankanbindung wie gehabt public static void makedbrequest (Connection con) { Statement stmt = con.createstatement(); //SQL-Anfrage ResultSet rsstudent = stmt.executequery( "SELECT * FROM Studenten" ) ; System.out.println( Vorname, Nachname, Matrikelnummer ); while (rsstudent.next()) { System.out.println( rsstudent.getstring(vorname)+, + rsstudent.getstring (Nachname) +, + rsstudent.getint(matrnr)); stmt.close(); 2.5 java.sql.resultsetmetadata Die Klasse ResultSet setzt voraus das die Attributnamen der einzelnen Datenbanken dem Programmierer bekannt sind. Ist dies nicht der Fall so können die fehlenden Informationen über ein Objekt des Typs ResultSetMetaData aus der Datenbank erfragt werden. Ein Objekt dieses Typs bekommt man über die Methode getmetadata() des aktuellen ResultSet-Objektes geliefert:... ResultSet rset = stmt.executequery ( SELECT Vorname, Nachname FROM Studenten ); ResultSetMetaData rsetdata = rset.getmetadata(); 10

12 Auf dieses Objekt können nun die folgenden Methoden angewandt werden um z.b. die Anzahl der Spalten, den Namen jeder Spalte, den Typ der Spalte und die Herkunftstabelle zu erfragen: int getcolumncount() throws SQLException; String gettablename (int col) throws SQLException; int getcolumntype (int col) throws SQLException; String getcolumntypename (int col) throws SQLException; Fazit JDBC Bei JDBC handelt es sich um eine Low-Level-API. Das heißt JDBC erfordert die direkte Benutzung von SQL-Anweisungen. Höhere Konzepte wie etwa die Abbildung von Tabellen auf Java-Klassen werden von JDBC nicht unterstützt. JDBC ist erste Wahl wenn es darum geht gering strukturierte Daten mittels Java- Anwendungen (z.b. Applet per Web) in Datenbanken zu verwalten. Es lassen sich mit wenigen Befehlen Verbindungen zu unterschiedlichen Datenbanken aufbauen und leicht SQL-Statements absetzen. Werden die Daten strukturierter und komplexer so entstehen Probleme wenn diese in SQL-Datenbanken abgelegt werden sollen. Strukturierte Daten und komplexe Beziehungen zwischen Dokumenten können zwar mit Hilfe von joins in SQL-Datenbanken nachgebildet werden, dies aber auf Kosten der Laufzeit. Zu solchen Anwendungen gehören z.b. rechnergest. Ingenieursysteme oder Anwendungen in der Finanzwelt und Telekommunikation. Für sie ist das ACID Prinzip zu statisch da es sich bei solchen Anwendungen hauptsächlich um komplexe Arbeitsabläufe handelt. Es tritt das Problem des Impedance- Missmatch auf. Die Lücke zwischen tabellenorientierter Speicherung und funktionalem Arbeitsablauf (umgesetzt anhand einer objektorientierten Programmiersprache) wird zu groß. Aus dieser Problematik heraus wurden die objektorientierten Datenbank-Management-Systeme entwickelt. 11

13 3 ODMG Die im Fazit zu JDBC aufgeführten Nachteile relationaler Datenbanken in Kombination mit objektorientierten Programmiersprachen führten zu der Entwicklung von objektorienten Datenbank- Management-Systemen. Ziel dieser ODBMS ist es die Speicherung und Verwaltung "komplexer" Objekte ohne aufwendige Transformationen zwischen Datenbanksprache und Programmiersprache der Anwendung zu ermöglichen. Nachdem erst einzelne unterschiedliche ODBMS s auf dem Markt erschienen wurde im Jahr 1991 die ODMG (Object Database Management Group) gegründet. Ihre Mitglieder sind die führenden ODBMS - Hersteller und ihr Ziel ist es einen einheitlichen Standard für objektorientierte Datenbank Management Systeme festzulegen. Der aktuelle Stand ist der ODMG-3.0 Standard. Dieser beinhaltet die folgenden Komponenten: - Objektmodell Das Objektmodell definiert das Datenmodell objektorientierter Datenbanken - Objektspezifikationssprache (ODL / OIF) Die ODL dient zur programmiersprachenneutralen Spezifikation von Klassenstrukturen. Die Object Interchange Format ist eine Sprache zum Austausch von Objekten zwischen verschiedenen ODMG - Datenbanken. - Objektanfragesprache (OQL) Die Object Query Language ist die deklarative Anfragesprache der ODBMS und basiert auf SQL Programmiersprachenanbindungen (C++ Binding, Java-Binding, etc.) Diese Anbindungen dienen dazu Objekte aus z.b. Java, C++ oder Smalltalk auf Objekte der Datenbank abzubilden. 3.1 Objektmodell / ODL Das Objektmodell stellt Konzepte zur Datenbank- und Transaktionsverwaltung, Metaschema, Beziehungen zwischen Objekten, Persistenz von Objekten, Klassenextensionen, Objekte und Literale zur Verfügung. Alle diese Konzepte werden anhand der Sprache ODL definiert. ODL ist eine Spezifikationssprache und somit programmiersprachenneutral. Daraus folgt das z.b. Objekttypen die anhand ODL definiert wurden in verschiedenen Programmiersprachen implementiert werden können. Aufgrund dessen kann ein in ODL spezifiziertes Schema durch eine beliebige ODMGkonforme ODBMS sowie unterschiedlicher Programmiersprachen unterstützt werden. Nachfolgend folgen Erläuterungen zu den wichtigsten Konzepten des Objektmodells, sowie ihrer Spezifikation anhand der ODL: Datenbanken Eine Datenbank ist im ODMG Modell eine Instanz vom Typ Database. Diese Instanzen werden anhand der new() Operation des Interfaces DatabaseFactory erzeugt. Ist das Datenbank-Objekt erzeugt, kann es anhand der im Interface Database spezifizierten Operationen manipuliert werden. Nachfolgend das Interface Database: 12

14 Interface Database { Void open (in String dbname); Void close(); Void bind (in any anobject, in String name); Object unbind (in String name); Object lookup(in String objname); ; Bevor auf irgendwelche Objekte der DB zugegriffen werden kann, muss die DB einen Namen zugeordnet bekommen. Dies geschieht mit Aufruf der Operation open() mit dem DB-Namen als Parameter.Die close() Methode muss von der Anwendung aufgerufen werden wenn keine weiteren Zugriffe auf die DB mehr erfolgen sollen und diese vom ODBMS zu schließen ist. Anhand der bind-operationen kann einem persistenten Objekt ein Name zugeordnet werden. Dieses so benannte Objekt kann dann mittels lookup und dem Namen in der DB gesucht werden Objekttypen Eigenschaften und Verhalten von Objekten werden durch ihren Typ bestimmt. Ein Typ beinhaltet eine unabhängige Spezifikation der Attribute, Operationen und Beziehungen und eine oder mehrere Implementierungen in einer Programmiersprache. Folgende 3 Arten der Typspezifikation stellt das Objektmodell zur Verfügung: - Schnittstellendefinition - Klassendefinition - Literaldefinition Schnittstellendefinition Eine Schnittstelle definiert das Verhalten eines Objektyps anhand der in ihr spezifizierten Operationen (in Programmiersprachen Methoden). Der mit interface definierte Typ ist abstrakter Natur, kann also nicht instantiiert werden. Allerdings können Schnittstellen wie in Java auch mehrfach vererbt werden. Nachfolgend ein kleines Beispiel für eine Schnittstelle in ODL: interface Moveable { void start() raises (MovingException); void stop() raises (StoppedException); void turn(); ; Klassendefinition Eine Klasse definiert das Verhalten sowie den Zustand eines Objekttyps. Das heißt sie spezifiziert das Verhalten des Objektes anhand von Methoden und den Zustand anhand von Attributen. Im Gegensatz zur Schnittstelle sind Objekte dieser Klasse instantierbar. Die Eigenschaft der Mehrfachvererbbarkeit besitzen Klassen jedoch nicht. Auch hier ein kurzes Beispiel in ODL: 13

15 class Car : Moveable { In diesem Beispiel implementiert die Klasse Car die Schnittstelle Moveable. Die Subtyp <-> Supertyp Beziehung zwischen Schnittstelle und implementierende Klasse wird durch den Doppelpunkt gekennzeichnet. Das Objektmodell bietet im Zusammenhang mit Klassen noch 2 weitere wichtige Funktionalitäten: - Extension Eine Extension ist die Menge aller Instanzen eines Typs in einer DB Beispiel: Mit Hilfe einer Extension kann ich nun z.b. folgende Anfrage realisieren: Selektiere mir alle in der DB vorhandenen Fahrzeuge - Schlüssel Anhand eines Schlüssels lassen sich Objekte eindeutig bezüglich bestimmter Attribute indentifizieren. Beispiel: class Auto (extent Fahrzeug) {...; class Auto (extent Fahrzeug, key kennzeichen) { attribute string kennzeichen;...; Literaldefinition Eine Literaldefinition spezifiziert den abstrakten Zustand von Literaltypen (keine Objekttypen). Als Literaltypen gibt es im Objektmodell die auch schon aus Programmiersprachen bekannten primitiven Datentypen boolean, double, long, char etc Objekte Objekte sind Instanzen von Klassendefinitionen. Das ODMG-Modell unterscheidet zwei Arten von Objekten anhand ihrer Lebenszeit. Transiente Objekte, welche vom Laufzeitsystem der Anwendung verwaltet werden und nur solange existieren wie die Anwendung läuft, sowie persistente Objekte welche von dem ODBMS verwaltet werden und über die Laufzeit der Anwendung hinaus bestehen. Das Java- Binding nutzt das Persistenz-Konzept: Persistenz durch Erreichbarkeit. Jedes Objekt welches über das DB-root-Objekt und weiteren Objekten erreicht werden kann ist persistent. Hat ein persistentes Objekt keine Verbindungen zu anderen Objekten so gilt es als nicht persistent und wird gelöscht Operationen In ODL werden Operationen nur durch ihre Signatur definiert. Die Signatur besteht aus dem Typ des Rückgabewertes, dem Bezeichner und der Parameterliste. Der einzige Unterschied im Vergleich zu Java- Methoden ist, das dem Parameter eine Richtung mitgegeben wird: 14

16 interface Moveable {... void turn ( in long direction); Desweiteren können Operationen in ODL genauso wie in Java Exceptions auslösen Attribute Attribute werden in ODL anhand des Schlüsselwortes attribute spezifiziert: class Car { attribute short direction; attribute string vendor; Transaktionen Zur Gewährleistung eines korrekten Mehrbenutzerbetriebes darf natürlich ein Transaktionskonzept nicht fehlen.das ODMG-Modell definiert ihr Transaktionskonzept auf Basis von Sperren. Dabei unterscheidet ODMG 3 Arten von Sperren: - Lesesperren Sie ermöglichen gemeinsame Lesezugriffe auf ein Objekt - Schreibsperren Sie sichern den exklusiven Zugriff auf ein Objekt. Während dieser Sperre kann kein weiterer Zugriff auf das Objekt erfolgen. - Änderungssperren Eine Änderungssperre ist nur verträglich mit einer Lesesperren. Eine Transaktion die zuerst ein Objekt liest um es später zu modifizieren sollte eine Änderungsperre setzen, um spätere Deadlocks zu vermeiden. Das Transaktionskonzept wird nur auf persistente Objekte angewandt. Nachfolgend die Spezifikation des interface Transaction in ODL: Interface Transaction { void begin() raises (TransactionInProgress); void commit() raises (TransactionNotInProgress); void abbort() raises (TransactionNotInProgress); void checkpoint() raises (TransactionNotInProgress); boolean isopen(); void join(); void leave(); ; 15

17 Mit der Operation begin wird die Transaktion explizit gestartet. Mit commit wird die erfolgreiche Transaktion beendet und abort bricht die Transaktion ab und setzt die DB in den ursprünglichen Zustand zurück. Mit join /leave kann sich ein Thread mit einer aktiven Transaktion verbinden bzw. diese wieder verlassen. 3.2 OQL Object Query Language ist die deklarative Datenbankanfragesprache der ODMG. Sie basiert auf dem SQL-92 Standard. OQL erweitert diesen Standard jedoch um die folgenden Konzepte: - Nutzung von Objektidentitäten, Pfadausdrücken und Methoden - Anfragen auf Kollektionen Im Unterschied zu SQL unterstützt OQL die folgenden 3 Arten von Anfragen: - Relationale Anfrage (SQL-Anfrage) SELECT b.kennzeichen FROM Auto b; - Objekterhaltene Anfrage SELECT b FROM AUTO b WHERE b.farbe = Rot ; Hier kann die Anfrage eine Kollektion von existierenden Objekten liefern. - Objekterzeugende Anfrage SELECT Personenkraftfahrzeuge (farbe: b.farbe, kennz: b.kennzeichen) FROM Auto b; Hier werden mit Hilfe der Attribute der Auto-Objekte neue Personenkraftfahrzeug-Objekte erzeugt. In allen der o.a. Anfragen können die aus SQL schon bekannten Funktionen verwandt werden: - Aggregatfunktionen MAX,MIN etc. - Gruppierungsfunktionen ORDER, BY - Quantoren ALL, EXISTS können auf Kollektionen angewandt werden 3.3 Java Binding Anhand des Java Binding definiert die ODMG die Abbildung der Konzepte des Objektmodells auf Elemente (Klassen, Methoden) der Sprache Java. Hauptbestandteile des Java-Binding sind die Java-ODL und die Java-OML. Wie wir schon wissen wird die ODL in ODMG zur Spezifikation von Datenbanken genutzt. Der zweite Ansatz dazu ist Java-ODL: 16

18 3.3.1 Java ODL Java ODL ermöglicht einem Java-Programmierer Datenbankschemata zu erstellen ohne sich in die 2.te Sprache ODL (ODMG) einarbeiten zu müssen. Den Nachteil den man sich durch das Nichtlernen der ODMG-ODL erkauft ist das einige Konzepte des Objektmodells in Java nicht umgesetzt werden können. Es fehlen Schlüsselattribute und explizite Beziehungen. Die restlichen Konzepte des ODMG-Objektmodells werden auf folgende Weise umgesetzt: - Objekttypen und Literale werden auf Java-Klassen und primitive Datentypen abgebildet. - Attribute und Operationen sind identisch mit Attributen und Methoden der jeweiligen Klassen - Exceptions werden direkt auf den selben Mechanismus in Java übertragen - Strukturen werden anhand von Java-Klassen nachgebildet - Extensionen werden nicht unterstützt - Kollektionen werden durch SetOfObject, BagOfObject, ListOfObject und VarrayOfObject realisiert Diese Konzepte werden als Java-Klassen herstellerspezifisch zusammengefasst. So sind die Java- Klassen zu z.b. POET im Package COM.POET.odmg zu finden. Nachfolgend werden wir nun ein kleines Datenbankbeispiel in Java-ODL vorstellen welches auf der objektorientierten Datenbank POET basiert. Als Beispiel nehmen wir Objekte vom Typ Student die in einer POET-DB abgespeichert werden sollen. public class Student { Private String vorname, nachname, studiengang; Prviate int matrnr; Public Student (String vname, String nname, String stgang, int matnr.) { vorname=vname ; nachname=nname ; studiengang=stgang ; matrnr = matnr ; public String getnachname() { return nachname; Um diese Klasse persistenzfähig zu machen, also in einer DB speicherbar, müssen für Datenbanken des Herstellers POET folgende Einträge in der Konfigurationsdatei ptjavac.opt des Präprozessors ptjavac erfolgen: 17

19 /* * Konfigurationsdatei: * ptjavac.opt * * (impliziter) Aufruf durch den Precompiler-Aufruf: * ptjavac -xc *.java */ [schemata\my_dict1] onefile = false [databases\my_db] onefile = false [classes\student] persistent = true ; so heisst das Dictionary (=Schema) ; dieser Eintrag legt den Namen der DB fest ; Hier wird die persistenzfähige Klasse festgelegt ; diese Klasse ist persistent Die oben angeführte Konfigurationsdatei wird vom Präprozessor der POET Datenbank ausgewertet und durch den vorhandenen Eintrag für die Klasse Student wird selbige persistenzfähig gemacht. POET verwendet die Variante mit Präprozessor, d.h. in der Konfiguratiansdatei ptjavac.opt müssen die für die Verarbeitung der Klassen notwendigen Informationen abgelegt sein. Ein weiterer Ansatz ist die Nutzung eines Postprozessor der Java-Bytecode so verändert das diese Klasse persistenzfähig wird. Nachdem nun die Klasse Student persistenzfähig ist und ein Datenbankschema durch den Präprozessor erstellt wurde können nun anhand der Java Object Manipulation Language Objekte erzeugt, gelöscht und manipuliert werden Java-OML In diesem Kapitel werden wir die einzelen Java-Klassen und Methoden kurz vorstellen, die zum Aufbau einer Verbindung zu einer objektorientierten Datenbank benötigt werden. Es folgt erst eine kurze Vorstellung der Klassen Database und Transaction um dann mit einem Anwendungs-Beispiel abzuschließen. Database Die Methoden der Klasse Database werden genutzt um eine Verbindung zu einer DB zu öffnen, zu schließen und um Objekte persistent in der Datenbank zu binden. Ein Datenbank Objekt muss nicht explizit erzeugt werden, da der Präprozessor von POET dies schon erledigt. Dabei werden die Methoden open(), close(), bind() und lookup() eingesetzt: Try { Database db = Database.open ( poet://local/my_db, Database.openReadWrite); // Öffnen der DB my_db.. hier folgen die Datenbankoperationen db.close(); // Schließen der DB catch (ODMGException exc) { exc.printstacktrace(); 18

20 Transaktionen Die Operationen bind () und lookup() werden generell im Rahmen einer Transaktion ausgeführt. Also brauchen wir erst mal ein Transaktionsobjekt: Transaction tx = new Transaction (); Auf Basis dieser Transaktion können dann die dementsprechenden Operationen ausgeführt werden: Transaction txn = new Transaction(); txn.begin(); try { Student mystudent = new Student("Mike","Liebrecht", Informatik, ); db.bind(mystudent, "myname"); //bindet ein Objekt in die DB oder try { // sucht ein persistentes Objekt Student mystudent = (Student) db.lookup ( myname ) Nachdem wir nun die Grundoperationen alle kennen können wir natürlich daraus kleine Java-Datenbank- Anwendungen generieren. Die nachfolgenden Java-Quelltexte Bind, Delete, Lookup implementieren die einfachen Operationen zum Erzeugen, Löschen und Suchen eines Objektes in einer POET Datenbank. import COM.POET.odmg.*; import java.util.*; public class Bind { static void binde(database db) throws ODMGException { Transaction txn = new Transaction(); //DB-Operationen erfolgen immer in einer Transaktion txn.begin(); try { Student mystudent = new Student("Mike","Liebrecht", Informatik, ); db.bind(mystudent, "myname"); // hier wird das Objekt persistent in die DB geschrieben catch (Exception exc) { txn.abort(); throw exc; txn.commit(); // Erfolgreiche Transaktion public static void main(string[] args) throws ODMGException { Database db = Database.open("poet://LOCAL/my_db", Database.openReadWrite); // DB my_db wird geöffnet try {binde(db); finally { db.close(); // DB wir geschlossen 19

21 import COM.POET.odmg.*; public class Delete { static void loesche(database db) throws ODMGException { Transaction txn = new Transaction(); // nur innerhalb einer T txn.begin(); try { // Objekt löschen (man braucht eine Referenz auf das Objekt) ObjectServices.current().delete(db.lookup("myName")); db.unbind("myname"); // Name "myname" wieder freigeben catch (Exception exc) { txn.abort(); // Sperre freigeben, weil Objekt nicht da ist throw exc; // Ausnahme an die Aufrufumgebung melden txn.commit(); // Löschen bestätigen durch Commit public static void main(string[] args) throws ODMGException { Database db = Database.open("poet://LOCAL/my_base1", Database.openReadWrite); try { loesche(db); finally { db.close(); 20

22 import COM.POET.odmg.*; public class Lookup { static void holeobjekt(database db) throws ODMGException { Transaction txn = new Transaction(); // immer innerhalb einer T txn.begin(); try { Student mystudent = (Student)db.lookup("myName"); System.out.println(myStudent); catch (Exception exc) { txn.abort(); // Sperre freigeben, weil Objekt nicht da ist throw exc; // Ausnahme an Aufrufumgebung melden txn.commit(); // T war o.k. public static void main(string[] args) throws ODMGException { Database db = Database.open("poet://LOCAL/my_base1", Database.openReadWrite); try { holeobjekt(db); finally { db.close(); 21

23 4 Fazit JDBC / ODMG Auf Basis der in den beiden Kapiteln einzeln vorgestellten Ansätze lässt sich nun ein Vergleich zwischen JDBC und ODMG darstellen: JDBC + SQL - JDBC ist nur eine Schnittstelle zwischen Java und den relationalen Datenbanken - Daten werden in Tabellen gespeichert (SQL) - Art der Speicherung gut geeignet um große Mengen gering strukturierter Daten zu verwalten - JDBC bietet lediglich eine Kapselung von SQL-Anweisungen, keine Abstraktion, Rückgriff auf SQL - Impedance Missmatch, Tabelle Objektorientierung ODMG - ODMG neu entwickeltes wesentlich umfangreicheres Konzept. Besteht aus objektorientierter DB (incl. Objektmodell etc.) + Schnittstellen zu mehreren Programmiersprachen, unter anderem Java - Daten werden als Objekte (mit ihren Eigenschaften, gekapselt als Attribute, in den Objekten) in einem / mehreren Objektbäumen gespeichert - Durch die Kapselung der Eigenschaften in den Objekten sehr gut geeignet um komplexe, stark strukturierte Daten zu speichern - Anhand des Java-Binding werden Elemente der Sprache Java direkt auf Objekte der Datenbank abgebildet - Durch objektorientierte Speicherung behoben - Verfahren für CASE-SYSTEME nicht geeignet, da keine Modellierung von Spezialisierung, Assoziation etc. möglich 22

24 5 Literaturverzeichnis Zu JDBC: Datenbanken & Java, GunterSaake und Kai-Uwe Sattler, Heidelberg: dpunkt-verlag, 2000 JDBC API Tutorial and Reference, Second Edition, S. White, M. Fisher, R. Cattel, G. Hamilton, M. Hapner, Addison-Wesley 1999 Vorlesung Prof. Böttcher Datenbanken I, Wintersemester 2000/2001 Zu ODMG: Datenbanken & Java, GunterSaake und Kai-Uwe Sattler, Heidelberg: dpunkt-verlag, 2000 The Object Data Standard, ODMG 3.0, Morgan Kaufmann Publishers Vorlesung Prof. Böttcher Datenbanken II, Wintersemester 2000/