Hallo, in diesem Video geht es um Lösungsansätze zur Überwindung der objektrelationalen Fehlanpassung. Ausgangspunkt ist JDBC, um aus einem Java-Programm heraus mit einer relationalen Datenbank zu kommunizieren.

Hier sehen Sie ein Beispiel. Durch dieses Beispiel soll die Anzahl aller Kunden ermittelt werden. Auffällig ist, dass für die Abfrage eines einzelnen Wertes bereits sechs Zeilen Code erforderlich sind. Das liegt daran, dass JDBC keinen direkten Zugriff auf Java-Variablen bietet.

Der manuell codierte Code ist fehleranfällig. Dieser Tippfehler in dem Code wird erst zur Laufzeit erkannt, da JDBC keine Syntaxprüfung von den Zeichenketten vornimmt. Es wird auch keine Prüfung gegenüber dem Datenbankschema vorgenommen. Des Weiteren wird auch keine Prüfung auf

Typkompatibilität durchgeführt. Das heißt, wenn beispielsweise ein Nullwert zurückgegeben wird, so wird nicht geprüft, ob dieser Nullwert richtig konvertiert wird. Das führt dann dazu, dass manuell erstellter JDBC-Code fehleranfällig und wartungsintensiv ist. Insbesondere dann, wenn das Schema

der Datenbank geändert wird. Der nächste Ansatz ist eingebettet SQL, was eigentlich eine Erweiterung von JDBC ist. Das Grundprinzip bei SQLJ ist, dass sie einen Java-Quelltext haben mit zugehörenden SQLJ-Anweisungen.

Diese werden übertragen in einen Java-Quelltext mit zugehörenden JDBC-Aufrufen. Das heißt, die JDBC-Aufrufe werden generiert und gleichzeitig ein SQLJ-Profil angelegt. Das SQLJ-Profil beschreibt die SQL-Befehlsbeschreibung,

die zugehörenden Datenstrukturen und benötigte Funktionsaufrufe. Während des Übersetzungsprozesses wird auch gleichzeitig ein Syntaxcheck durchgeführt gegenüber der Schema der zugehörenden Datenbank. Dadurch können bereits zur Entwicklungszeit Fehler in den

SQL-Befehlen entdeckt werden. Der Java-Quelltext wird dann über den Java-Compiler in Bytecode umgewandelt. Der Code kann dann ausgeführt werden in der SQLJ-Laufzeitumgebung. Die SQLJ-Laufzeitumgebung ist abhängig

von dem jeweiligen Datenmanagementsystem. Der Vorteil der Verwendung von eingebettetem SQL ist, dass direkt Variablen in der Host-Sprache, also hier in Java, genutzt werden können. Das sehen Sie hier an diesem Beispiel.

Oben haben Sie den zugehörenden Java-Code, um beispielsweise die Anzahl aller Kunden zu ermitteln. In den SQLJ-Code sehen Sie, dass sich eine Host-Variable in Java definieren, Anzahl. Dann kommt die Präprozessor-Anweisung mit dem zugehörenden Select-Statement und als Platzhalter Doppelpunkt

Anzahl ist dann die Referenz auf die zugehörende Java-Variate. Dieser Code ist natürlich sehr schön kompakt. Durch den Präprozessor wird dieser Code umgesetzt in ein generiertes JDBC-Code. Hier sehen Sie ein Beispiel eines Updates und dieser Code ist relativ schwer zu lesen. Oben sehen Sie

den zugehörenden Präprozessor-Befehl und den dazu generierten JDBC-Code. Dieser Code ist einerseits schlecht lesbar und andererseits führt das dazu, dass in den eigentlichen Quelltexten lauter Compiler-Fehler durch die

Verwendung bei IDEs angezeigt bekommen, weil diese Präprozessor- Befehl. Ein weiterer Schwachpunkt ist, dass Sie an einen Datenbank-Hersteller über die Verwendung des Präprozessors gebunden sind. Das heißt, wenn Sie

Projekte haben, wo Sie nicht nur auf eine Datenbank zugreifen oder wechselseitig auch auf andere Datenbanken, haben Sie das Problem, dass Sie dann nicht mehr mit diesem Präprozessor eines Herstellers zurechtkommen. Weitere Lösungsansätze ist einmal der Einsatz von objektrelationalen Mapping-Frameworks, welches in einem nächsten Video

behandelt wird. Ein weiterer Ansatz ist die Entwicklung von objektorientierten Datenbanken, bei denen ganz auf der Einsatz des relationalen Modells verzichtet wird. In diesem Fall wird die Programmiersprache, beispielsweise Java, erweitert, um Möglichkeiten der

Persistierung und der Integritätssicherung. Allerdings zeigte sich dabei, dass dieser Ansatz nur für kleine Datenmengen praktikabel ist, da in dem Augenblick, wenn Sie ein Objekt aus der Datenbank laden, gleich alle anderen Objekte, die dieses Objekt referenziert, mitgeladen werden.

Objektorientierte Datenbanken sind damit nur sinnvoll nutzbar, beispielsweise in mobilen Applikationen. Ein weiterer Ansatz ist die Erweiterung des relationalen Modells um Objekte und führt zu der Entwicklung von objektrelationalen Datenbank-Management-Systemen.