JDBC. Udo Kelter

Transkript

1 JDBC Udo Kelter Zusammenfassung dieses Lehrmoduls JDBC (Java Database Connectivity) ist eine Schnittstelle, über die von Java-Programmen aus auf die Inhalte relationaler Datenbanken zugegriffen werden kann. Dieses Lehrmodul stellt die wichtigsten Funktionen vor. Insb. wird die Frage beantwortet, wie mit einer typsicheren Sprache wie Java die Ergebnisse von Abfragen, deren Typ man nicht statisch bestimmen kann, verarbeitet werden können. Vorausgesetzte Lehrmodule: obligatorisch: Einführung in SQL Stoffumfang in Vorlesungsdoppelstunden: 1.0 1

2 JDBC 2 Inhaltsverzeichnis 1 Motivation 3 2 Aufbau einer Verbindung zum Datenbankserver JDBC-Treiber laden Connection-Objekt erzeugen SQL-Statements SQL-Statement-Objekte erzeugen executeupdate executequery ResultSets ResultSet als lineare Liste Cursors (Positionsmarken) Positionierbare ResultSets Auslesen eines Tupels Automatisch aktualisierte ResultSets Änderbare ResultSets Motivation Ändern eines Tupels Löschen von Tupeln Einfügen von Tupeln Vorübersetzte Statements 12 7 Fehlerbehandlung 14 Index Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer oder gedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenommen werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarf der expliziten Genehmigung. Die jeweils aktuellste Version ist über erreichbar.

3 JDBC 3 1 Motivation Viele einfache ad-hoc-abfragen zu einer bestehenden relationalen Datenbank können mit wenigen Abfragen über einen interaktiven Kommandointerpreter, den jedes DBMS-Produkt mitliefert, erledigt werden. Für komplexere Abfragen und erst recht umfängliche Änderungen von Daten in einer Datenbank ist eine derartige interaktive, also manuelle Vorgehensweise nicht geeignet. Stattdessen sollte bzw. muß von einem (laufenden) Programm aus auf die Datenbank zugegriffen werden. Hierbei treten folgende Detailprobleme auf: Aufbau und Überwachung einer Verbindung zum Datenbankserver die Konversion von Daten in der Datenbank in den Laufzeitobjekten der jeweiligen Programmiersprache und umgekehrt. In der Regel weisen die Typsysteme der Datenbank und der Programmiersprache erhebliche Unterschiede auf. Besonders schwierig ist speziell für Abfragen die Entwicklung einer Laufzeit-Datenstruktur, die die zurückgelieferte (Ergebnis-) Relation implementieren kann. die Gestaltung geeigneter und leicht nutzbarer APIs für sämtliche SQL-Kommandos die Fehlerbehandlung. Im Prinzip kann z.b. bei der üblichen Prozeßarchitektur von DBMS-Laufzeitumgebungen jederzeit die Verbindung zum DBMS-Serverprozeß gestört sein. Fast alle vorstehenden Detailprobleme müssen spezifisch für die jeweilige Programmiersprache gelöst werden. Daher existieren für die gängigen Programmiersprachen jeweils eigene Anbindungen, um von Programmen in dieser Sprache auf eine relationale Datenbank zugreifen zu können. Man kann ganz grob zwei Arten von Anbindungen unterscheiden: reine APIs bzw. Bibliotheken: die Bibliotheken werden zu dem Programm, das eine Datenbank benutzt, nach dessen Kompilierung hinzugebunden. Die Funktionen der Bibliothek werden durch manuell erstellte Aufrufe benutzt. Derartige APIs werden auch als

4 JDBC 4 Treiber (driver) bezeichnet, in Analogie zum Anschluß von Plattenlaufwerken. Ein Entwickler hat hier viele Gestaltungsmöglichkeiten, muß sich aber auch um viele Details kümmern. Präprozessoren und automatisierte Konversionen: Die Konversion von Daten und andere Details werden hier durch einen Präprozessor automatisiert, der insb. die Datenstrukturen analysiert, die persistent gemacht werden sollen, und entsprechende Tabellen definiert und API-Aufrufe generiert. Auf der einen Seite wird hier viele manuelle Programmierung vermieden, andererseits muß man i.d.r. zunächst ein komplexes Framework verstehen. In diesem Lehrmodul stellen wir ein API für die Sprache Java vor, JDBC. JDBC (Java Database Connectivity) ist... the industry standard for database-independent connectivity between the Java programming language and a wide range of SQL databases and other tabular data sources, such as spreadsheets or flat files. 1 2 Aufbau einer Verbindung zum Datenbankserver 2.1 JDBC-Treiber laden Ein Datenbankprodukt, das JDBC unterstützt, muß eine eigene Implementierung des APIs mitliefern. Dieser Treiber wird identifiziert durch Paket- und Klassennamen, beispielsweise: org.postgresql.driver. Der Treiber muß als erstes zum Benutzerprogramm hinzugebunden und geladen werden, und zwar mit einem Kommando der Form Class.forName(driver class);. Beispiel: Class.forName("org.postgresql.Driver"); 1 Quelle:

5 JDBC Connection-Objekt erzeugen Damit das laufende Applikationsprogramm mit dem DBMS-Serverprozeß kommunizieren kann, muß eine Kommunikationsverbindung zwischen beiden Prozessen hergestellt werden. Zur Laufzeit werden solche Verbindungen durch Connection-Objekte repräsentiert. Deklariert wird eine derartiges Objekt wie folgt Connection con = null; Um die Verbindung tatsächlich aufzubauen, muß die Operation getconnection benutzt werden, die der DriverManager zur Verfügung stellt. Muster: con = DriverManager.getConnection(db, user, passw); Die Parameter von getconnection sind wie folgt anzugeben: db user Die Datenbank ist in folgender Syntax anzugeben: protokoll://rechnername/dateipfad Beispiel: jdbc:postgresql://pi81.informatik.uni-siegen.de/dbs1 Dieses Beispiel zeigt, daß Protokolle aufeinander aufbauen können. Oft wird z.b. ein Java-API auf Basis eines schon existierenden C-APIs implementiert. Benutzername passw Passwort Wenn die Operation getconnection erfolgreich ausgeführt wurde, kann anschließend auf die Datenbank zugegriffen werden. 3 SQL-Statements 3.1 SQL-Statement-Objekte erzeugen Letztlich will man SQL-Kommandos ausführen. Hierzu müssen zunächst Objekte erzeugt werden, die die SQL-Kommandos repräsentieren. Diese Objekte haben den vordefinierten Typ Statement. Hierbei sind mehrere Schritte zu trennen:

6 JDBC 6 1. ein Statement-Objekt erzeugen und initialisieren 2. eine Anweisung eintragen 3. die enthaltene Anweisung ausführen (ggf. mehrfach) Ein Statement-Objekt kann mit der Operation createstatement erzeugt und initialisiert werden: Statement stmt; stmt = con.createstatement(); Im Zustand des Statement-Objekts ist vermerkt, zu welcher Verbindung es gehört. Daher braucht die Verbindung nicht mehr jedesmal erneut angegeben zu werden. Mit einem initialisierten Statement-Objekt können nun beliebige SQL-Kommandos durchgeführt werden. Im einfachsten Fall wird das SQL-Kommando textuell als Argument übergeben und ausgeführt. Wegen der unterschiedlichen Rückgaben sind hier zwei Fälle zu unterscheiden: Abfragen: Zurückgeliefert wird hier eine Tabelle. Dementsprechend gibt es eine Operation zur Ausführung einer Abfrage, die eine Tabelle liefert (executequery). Alle anderen SQL-Kommandos: Diese sind mit der Operation executeupdate durchzuführen. 3.2 executeupdate executeupdate ist für alle SQL-Kommandos zu benutzen, die eine Datenbank ändern (insb. create table, insert, delete,...). Die Syntax ist: int executeupdate(string sql) Beispiel: int num = stmt.executeupdate("insert..."); executeupdate liefert einen Integer-Wert zurück, der bestimmte Informationen über das Ausführungsergebnis darstellt:

7 JDBC 7 ggf. die Zahl der eingefügten / gelöschten / geänderten Tupel 0 bei create table und u.ä. Kommandos 3.3 executequery In JDBC ist eine Tabelle durch die Klasse ResultSet implementiert. executequery liefert daher einen solchen ResultSet. Beispiel: ResultSet result = stmt.executequery("select..."); Es gibt mehrere Arten von ResultSets, die wir i.f. vorstellen. 4 ResultSets 4.1 ResultSet als lineare Liste Eine Tabelle ist konzeptuell betrachtet eine Kollektion von Tupeln. Es gibt unterschiedliche Methoden, Kollektionen zu implementieren. Die einfachste Form ist eine lineare Liste, dies ist auch das Standardverhalten von executequery. D.h. das Java-Kommando ResultSet result = stmt.executequery("select..."); erzeugt eine lineare Liste (wozu der Name ResultSet nicht so ganz paßt) von Tupeln (rows). Lineare Listen kann man jeweils nur sequentiell von vorne bis zum Ende durchlaufen. Die Klasse ResultSet bietet hierzu die Operation next an. Beispiel: while(result.next()) { verarbeite aktuelles Tupel } 4.2 Cursors (Positionsmarken) Jeder ResultSet hat als Teil seines Zustands einen Cursor, also eine aktuelle Position in der Liste. Gedanklich besteht die Menge der Cursorpositionen aus den Positionen zwischen zwei aufeinanderfolgenden Tupeln und der Position vor dem ersten und nach dem letzten Tupel. Bei n Tupeln im ResultSet gibt es also n + 1 Cursorpositionen; diese sind von 0 bis n durchnumeriert.

8 JDBC 8 Initial steht der Cursor vor dem ersten Tupel. Die Operation next bezieht sich implizit auf den Cursor des ResultSets. Der Haupteffekt von next besteht darin, den Cursor eine Position weiter zu verschieben. Aktuelles Tupel. Für jede Cursorposition p > 0 ist ein aktuelles Tupel definiert, und war das Tupel, das sozusagen zwischen den Cursorpositionen p 1 und p steht. Die Tupel eines ResultSets sind auf diese Weise von 1 bis n durchnumeriert. Nur auf das aktuelle Tupel kann zugegriffen werden, hierauf gehen wir später genauer ein. 4.3 Positionierbare ResultSets Wenn man ein Abfrageergebnis nur unverändert ausgibt, reicht eine lineare Liste völlig aus. Wenn man hingegen den ResultSet wiederholt durchsuchen muß oder einzelne Tupel z.b. anhand ihrer Positionsnummer direkt lokalisieren will, ist eine wiederholte lineare Suche ineffizient. Statt als lineare Liste können ResultSets daher als beliebig positionierbare ( scrollbare ) Kollektion erzeugt werden; hierzu ist in der Operation createstatement das Argument ResultSet. TYPE SCROLL INSENSITIVE anzugeben. Beispiel: stmt = con.createstatement( ResultSet.TYPE_SCROLL_INSENSITIVE); result = stmt.executequery("select..."); Für einen solchen positionierbaren ResultSet stehen diverse Positionierungsoperationen, und zwar 2 : relative Veränderungen der aktuellen Cursorposition: next(), previous(), relative(int) 2 Details s. JDBC-Tutorial, Abschnitt Cursors /tutorial/jdbc/basics/retrieving.html#cursors bzw. Spezifikation der Klasse ResultSet

9 JDBC 9 absolute Veränderungen: first(), beforefirst(), last(), afterlast(), absolute(int) Mit der Operation int getrow() kann die Nummer der aktuellen Cursorposition bestimmt werden. Mit absolute(int) kann man später zu dieser Cursorposition zurückkehren. 4.4 Auslesen eines Tupels Man steht beim Zugriff von Programmen auf Datenbanken vor dem generellen Problem, daß die Typwelten, insb. die elementaren Datentypen und die Typkonstruktoren, nicht übereinstimmen. Im Fall von Java ist hier zusätzlich relevant, daß Java grundsätzlich als typsichere Sprache gestaltet ist, d.h. der Typ von Objekten kann bereits beim Compilieren bestimmt werden, was extreme softwaretechnische Vorteile bei der Identifikation von Fehlern bietet. Im krassen Widerspruch dazu steht die geringe Typsicherheit von SQL. Die Abfrage SELECT * FROM r liefert eine Tabelle eines Typs, der erst zur Laufzeit bestimmt werden kann. Weiterhin sind diverse Detailinformationen über die Datentypen der Spalten einer Tabelle aus den Abfragen nicht erkennbar. Beispielsweise kann der Compiler bei einer Abfrage executequery("select A FROM r") statisch nicht wissen, welchen Typ die Spalte A hat. Noch weniger weiß der Compiler, wenn der String, der die Abfrage definiert, dynamisch erzeugt wird und von vorherigen interaktiven Eingaben abhängt. Daher muß letzten Endes ein Entwickler explizit angeben, welche Typen die Spalten eines zurückgelieferten ResultSets haben. Technisch wird dieses Problem dadurch gelöst, daß die Attribute des aktuellen Tupels einzeln durch typspezifische Kopieroperationen gelesen und z.b. auf Laufzeitvariablen übertragen werden. Die Operationsnamen dieser Kopieroperationen haben die Form getxxx, worin XXX ein Typname ist, z.b. getint, getstring usw. Eigenschaften dieser Operationen: Sie beziehen sich auf das aktuelle Tupel.

10 JDBC 10 Sie lesen den Wert eines Attributs des aktuellen Tupels. Sie liefern einen Wert vom Typ XXX zurück. Hierbei werden ggf. Werte implizit konvertiert(!), was u.u. nicht beabsichtigt war. Als Entwickler muß man also den Typ des Attributs kennen und die passende get-operation benutzen. Für alle get-operationen existieren jeweils zwei Varianten, wie das gewünschte Attribut identifiziert wird: getxxx(string): anhand des Namens getxxx(int): anhand der Position (1,...) Beispiele: name = result.getstring("vorname"); plz = result.getint(5); Alle get-operationen sind in der Spezifikation der Klasse Result- Set genauer beschrieben. 4.5 Automatisch aktualisierte ResultSets Wenn ein ResultSet nach den bisherigen Verfahren durch ein executequery erzeugt wird, ist sein Inhalt eine Kopie der Daten aus der DB zum Zeitpunkt der Abfrage. Wenn sich die Datenbank danach ändert, bleibt der ResultSet unverändert, d.h. der ResultSet gibt ggf. den aktuellen Stand der Daten nicht mehr richtig wieder. In vielen Fällen ist es wünschenswert, daß der ResultSet sich automatisch an Änderungen in der Datenbank anpaßt. Die Lösung dieses Problems sind sensitive ResultSets, die mit dem Argument ResultSet. TYPE SCROLL SENSITIVE in der Operation createstatement erzeugt werden. Beispiel: stmt = con.createstatement( ResultSet.TYPE_SCROLL_SENSITIVE); result = stmt.executequery("select...");

11 JDBC 11 5 Änderbare ResultSets 5.1 Motivation Die bisher eingeführten ResultSets waren unveränderlich, es sind nur lesende Operationen erlaubt. Oft wäre es aber praktisch, einen Result- Set zu durchlaufen und dabei bestimmte Attribute einzelner oder aller Tupel sofort nach dem Lesen zu verändern. Theoretisch kann man für jede einzelne Änderung ein update-kommando mit executeupdate durchführen. Dies wäre allerdings sehr umständlich und ineffizient. Eine elegantere Lösung sind änderbare ResultSets 3. Um einen änderbaren ResultSet zu erzeugen, ist die Operation createstatement mit dem Argument ResultSet.CONCUR UPDATABLE aufzurufen. Beispiel: stmt = con.createstatement( ResultSet.CONCUR_UPDATABLE); result = stmt.executequery("select..."); 5.2 Ändern eines Tupels In einem änderbaren ResultSet können die Attribute des aktuellen Tupels mit updatexxx-operationen verändert werden, z.b. updateint, updatestring usw. Diese sind analog zu den getxxx-operationen konzipiert. Eigenschaften der updatexxx- Operationen: Sie beziehen sich implizit auf das aktuelle Tupel. XXX ist ein Typname. Der 1. Parameter ist der Name (Typ: string) oder die Nummer (Typ: integer) des gewünschten Attributs. Der 2. Parameter ist vom Typ XXX, er enthält den neuen Wert des Attributs. Auch hier werden ggf. Werte implizit konvertiert, was u.u. nicht beabsichtigt war. Der Rückgabewert ist void. 3 Nach einer Änderung ist der Begriff ResultSet eigentlich nicht mehr korrekt.

12 JDBC 12 Beispiele: result.updatestring("vorname", "Hans"); result.updateint(5,57076); Alle update-operationen sind in der Spezifikation der Klasse ResultSet beschrieben. Die Änderungen einzelner Attribute werden nicht sofort in die Datenbank übertragen, sondern nur gesammelt pro Tupel mit der Operation updaterow(). 5.3 Löschen von Tupeln Die Operation deleterow() löscht das aktuelle Tupel im ResultSet und in der Datenbank. 5.4 Einfügen von Tupeln Das Einfügen von Tupeln in einen ResultSet wird durch eine spezielle zusätzliche Cursorposition und ein zugehöriges virtuelles Einfüge- Tupel ( insert row ) unterstützt. Zunächst muß man mit der Operation movetoinsertrow() den Cursor auf das Einfüge-Tupel setzen: result.movetoinsertrow(); Danach kann man mit den update-operationen Attribute dieses Tupels ändern. Wenn man damit fertig ist, fügt man mit der Operation insertrow() das neue Tupel in den ResultSet und in die Datenbank ein: result.insertrow(); Danach kann man mit der Operation movetocurrentrow() den Cursor wieder an die Stelle zurücksetzen, den er vor Ausführung des movetoinsertrow() hatte. 6 Vorübersetzte Statements Wenn man viele Daten ändert, sind änderbare ResultSets i.d.r. die beste Methode. Änderbare ResultSets werden aber nicht von allen Systemen unterstützt, dann bleibt nichts anderes übrig als mit einzelnen

13 JDBC 13 Änderungskommandos zu arbeiten. Dies ist relativ rechenaufwendig, weil bei der Übersetzung des Kommandotextes jedesmal erneut alle üblichen Prüfungen auf korrekte Syntax, Vorhandensein der Bezeichner usw. durchgeführt werden müssen. Dieser Aufwand ist vermeidbar, wenn immer wieder fast das gleiche SQL-Kommando ausgeführt wird, und zwar mithilfe vorübersetzter Statements (Prepared Statements). Ein vorübersetzbares Statement ist ein Kommando-Text, der an den Stellen, wo ein Eingabeparameter (ein Bezeichner oder eine Konstante) erwartet wird, ein Fragezeichen enthält. Man kann dies auch als eine Funktionsdeklaration betrachten, jedes Fragezeichen steht für einen Parameter. Beispiel: String insertcmd = "INSERT INTO lieferungen " + "(Kundennummer, Lieferadresse, Betrag, Datum) " + "VALUES (?,?,?, )"; In diesem Beispiel wird die Eintragung mehrerer Lieferungen am in die Relation lieferungen vorbereitet. Vorübersetztende Statements werden in 3 Phasen definiert und ausgeführt: 1. Der vorzuübersetzende Text wird mit der Operation preparestatement übersetzt, zurückgeliefert wird ein Objekt vom Typ PreparedStatement. Beispiel: PreparedStatement psinsertlfg; psinsertlfg = con.preparestatement(insertcmd); 2. Die offenen Stellen, sozusagen die Parameter des PreparedStatements, werden gefüllt, s.u. 3. Nach Setzen der Werte aller Parameter wird das vervollständigte PreparedStatement mit der Operation executeupdate ausgeführt. Beispiel: psinsertlfg.executeupdate(); Setzen der Parameter eines PreparedStatements. Hierzu dienen setxxx-kommandos, die für Objekte des Typs Preparedc 2016 Udo Kelter Stand:

14 JDBC 14 Statement definiert sind. Analog wie bei den getxxx-kommandos steht XXX auch hier wieder für einen elementaren Datentyp. Die setxxx-kommandos haben 2 Parameter: 1. die Nummer des offenen Eingabeparameters 2. den zu benutzenden Wert, der vom Typ XXX sein muß Beispiele: psinsertlfg.setint (1, ); psinsertlfg.setstring (2, "Bahnhofstr. 55"); Weitere Details s. 7 Fehlerbehandlung Wie schon früher erwähnt sind bei jedem Datenbankzugriff prinzipiell immer Fehler möglich, z.b. Syntaxfehler oder der Verlust der Verbindung zum DBMS-Serverprozeß. Alle Datenbankzugriffe müssen daher selbst bei ersten Übungsaufgaben in try/catch-blöcken gekapselt werden. Eine detaillierte Behandlung aller Fehlerursachen ist relativ aufwendig und kann ggf. Teile der Applikationslogik beinhalten. Bei ersten Übungen kann man auf eine detaillierte Fehlerbehandlung zunächst verzichten. Alle SQL-Zugriffsoperationen werfen Exceptions vom Typ SQLException. Über diese exception-objekte können diverse Informationen über die Art des Fehlers herausgefunden werden. Die Klasse SQLException bietet hierzu folgende Operationen an: getmessage() liefert eine verbale Beschreibung des Fehlers getsqlstate() liefert einen Fehlercode gemäß dem ANSI- bzw. ISO- Standard geterrorcode() liefert einen herstellerspezifischen Fehlercode, dessen Bedeutung in der Produktdokumentation definiert sein muß. Bei einen Datenbankzugriff können i.a. mehrere SQLExceptions

15 JDBC 15 auftreten. Deren Abhängigkeitsstruktur kann mit Hilfe der Operation getcause() abgefragt werden. Warnungen. Neben Fehlern können Datenbankzugriffe auch Warnungen produzieren. Während ein Fehler die nicht erfolgreiche Ausführung eines SQL-Kommandos anzeigt und ggf. zu einem Programmabbruch führt, treten Warnungen auch bei einer erfolgreichen Ausführung des Kommandos auf. Beispielsweise kann bei einer Konversion von Datenwerten ein Rundungsfehler aufgetreten sein. Warnungen müssen mit der Operation getwarnings abgerufen werden. Diese Operation ist u.a. für die Klassen Connection, Statement, PreparedStatement und ResultSet definiert, also bei allen Objekten aufrufbar, die Ergebnis von Datenbankzugriffen sind. Analog zu Fehlern sind Informationen über die Warnung abrufbar, und ein Datenbankzugriff kann mehrere Warnungen verursachen. Weitergehende Informationen SQLExceptions bzw. Warnungen s. u.a. zum Auslesen der Liste der