| Titel | Inhalt | Suchen | Index | API | Go To Java 2, Zweite Auflage, Handbuch der Java-Programmierung |
| << | < | > | >> | Kapitel 42 - Datenbankzugriffe mit JDBC | |
Wir wollen uns in diesem Abschnitt zunächst mit der grundsätzlichen Architektur von JDBC und datenbankbasierten Java-Anwendungen vertraut machen. Anschließend werden die wichtigsten Bestandteile der JDBC-Schnittstelle vorgestellt und ihre jeweilige Funktionsweise kurz erläutert. Der nächste Abschnitt illustriert und verfeinert die Konzepte dann an einem praktischen Beispiel, bei dem eine Datenbank zur Speicherung von Verzeichnissen und Dateien entworfen, mit Daten gefüllt und abgefragt wird. Zum Abschluß werden wir einige spezielle Probleme besprechen und auf die Besonderheiten gebräuchlicher JDBC-Treiber eingehen.
Dieses Kapitel ist typisch für die weiterführenden Themen in diesem Buch. JDBC ist ein sehr umfassendes Gebiet, das auf den zur Verfügung stehenden Seiten nicht vollständig behandelt werden kann. Wir verfolgen statt dessen einen pragmatischen Ansatz, bei dem wichtige Grundlagen erläutert werden. Mit Hilfe von Beispielen wird ihre praktische Anwendbarkeit demonstriert. Insgesamt müssen aber viele Fragen offen bleiben, die durch die Lektüre weiterer Dokumentationen geschlossen werden können. Dazu zählen beispielsweise Trigger, Blobs und Stored Procedures, die Erweiterungen in JDBC 2.0 oder die Entwicklung eigener JDBC-Treiber.
Kurz nachdem die Version 1.0 des Java Development Kit vorlag, begann die Entwicklung einer einheitlichen Datenbankschnittstelle für Java-Programme. Anstelle des von vielen Entwicklern erwarteten objektorientierten Ansatzes verfolgten die Designer dabei das primäre Ziel, die große Zahl vorhandener SQL-Datenbanken problemlos anzubinden. In konzeptioneller Anlehnung an die weitverbreitete ODBC-Schnittstelle wurde daraufhin mit JDBC (Java Database Connectivity) ein standardisiertes Java-Datenbank-Interface entwickelt, das mit der Version 1.1 fester Bestandteil des JDK wurde.
JDBC stellt ein Call-Level-Interface zur SQL-Datenbank dar. Bei einer solchen Schnittstelle werden die SQL-Anweisungen im Programm als Zeichenketten bearbeitet und zur Ausführung an parametrisierbare Methoden übergeben. Rückgabewerte und Ergebnismengen werden durch Methodenaufrufe ermittelt und nach einer geeigneten Typkonvertierung im Programm weiterverarbeitet.
Dem gegenüber steht ein zweites Verfahren, das als Embedded SQL (ESQL) bezeichnet wird. Hierbei werden die SQL-Anweisungen mit besonderen Schlüsselwörtern direkt in den Java-Quelltext eingebettet, und die Kommunikation mit dem Java-Programm erfolgt durch speziell deklarierte Host-Variablen. Damit der Java-Compiler durch die eingebetteten SQL-Anweisungen nicht durcheinandergebracht wird, müssen sie zunächst von einem Präprozessor in geeigneten Java-Code übersetzt werden. Während Embedded-SQL insbesondere bei Datenbankanwendungen, die in C oder C++ geschrieben sind, sehr verbreitet ist, spielt es in Java praktisch keine Rolle und konnte sich gegenüber JDBC nicht durchsetzen.
JDBC ist keine eigene Datenbank, sondern eine Schnittstelle zwischen einer SQL-Datenbank und der Applikation, die sie benutzen will. Bezüglich der Architektur der zugehörigen Verbindungs-, Anweisungs- und Ergebnisklassen unterscheidet man vier Typen von JDBC-Treibern:
Während die Typ-1- und Typ-2-Treiber lokal installierte und konfigurierte Software erfordern (die jeweiligen ODBC- bzw. herstellerspezifischen Treiber), ist dies bei Typ-3- und Typ-4-Treibern normalerweise nicht der Fall. Hier können die zur Anbindung an die Datenbank erforderlichen Klassendateien zusammen mit der Applikation oder dem Applet aus dem Netz geladen und ggfs. automatisch aktualisiert werden. Nach der Veröffentlichung von JDBC gab es zunächst gar keine Typ-3- oder Typ-4-Treiber. Mittlerweile haben sich aber alle namhaften Datenbankhersteller zu Java bekannt und stellen auch Typ-3- oder Typ-4-Treiber zur Verfügung. Daneben gibt es eine ganze Reihe von Fremdherstellern, die JDBC-Treiber zur Anbindung bekannter Datenbanksysteme zur Verfügung stellen.
Mit JDBC können sowohl zwei- als auch drei- oder höherstufige Client-Server-Systeme aufgebaut werden (Multi-Tier-Architekturen). Während bei den zweistufigen Systemen eine Aufteilung der Applikation in Datenbank (Server) und Arbeitsplatz (Client) vorgenommen wird, gibt es bei den dreistufigen Systemen noch eine weitere Schicht, die zwischen beiden Komponenten liegt. Sie wird gemeinhin als Applikations-Server bezeichnet und dient dazu, komplexe Operationen vom Arbeitsplatz weg zu verlagern. Der Applikations-Server ist dazu mit dem Datenbank-Server verbunden und kommuniziert mit diesem über ein standardisiertes Protokoll (z.B. JDBC). Den Arbeitsplätzen stellt er dagegen höherwertige Dienste (z.B. komplette Business-Transaktionen) zur Verfügung und kommuniziert mit ihnen über ein spezielles Anwendungsprotokoll (z.B. HTTP, RMI, CORBA oder andere).
JDBC übernimmt die Aufgabe eines »Transportprotokolls« zwischen Datenbank und Anwendung und definiert damit zunächst noch nicht, welche SQL-Kommandos übertragen werden dürfen und welche nicht. Tatsächlich verwendet heute jede relationale Datenbank ihren eigenen SQL-Dialekt, und eine Portierung auf eine andere Datenbank ist nicht selten aufwendiger als ein Wechsel des Compilers.
Um einen minimalen Anspruch an Standardisierung zu gewährleisten, fordert SUN von den JDBC-Treiberherstellern, mindestens den SQL-2 Entry-Level-Standard von 1992 zu erfüllen. Mit Hilfe einer von SUN erhältlichen Testsuite können die Hersteller ihre JDBC-Treiber auf Konformität testen. Da praktisch alle großen Datenbanken in ihrer Funktionalität weit über besagten Standard hinausgehen, ist bei Verwendung dieser Features möglicherweise mit erheblichem Portierungsaufwand zu rechnen.
| Titel | Inhalt | Suchen | Index | API | Go To Java 2, Zweite Auflage, Addison Wesley, Version 2.0 |
| << | < | > | >> | © 2000 Guido Krüger, http://www.gkrueger.com | |