Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung
unter dem Förderkennzeichen 16OH21005 gefördert.
Die Verantwortung für den Inhalt dieser Veröffentlichung liegt
beim Autor/bei der Autorin.
In diesem Abschnitt wollen wir uns mit objektorientierten Datenbanken beschäftigen.
Hierzu gehen wir folgenden Fragestellungen nach:
• Warum soll man eine objektorientierte Datenbank einsetzen?
• Welche Probleme stellen sich dabei?
• Welche Lösungsansätze gibt es?
• Wie arbeiten objektorientierte Datenbanken überhaupt?
• Was verstehet man unter objektorientiertes-relationales Mapping?
Der ersten Frage, der wir nachgehen wollen, ist die Frage nach dem „Warum OODBs?“
Bisher haben wir relationale Datenbanken betrachtet und uns ausgiebig mit dem zugrunde liegenden relationalen Modell beschäftigt.
Bei objektorientieren Datenbank steht das OO-Paradigma im Vordergrund.
Die grundlegende Idee dabei ist, dass Anwendungen meist in einer
objektorientierten Sprache erstellt werden. Daher stellt sich die Frage, ob man nicht die Daten selbst dann auch als Objekte in einer Datenbank ablegen kann.
Somit würde sich nicht das Problem stellen, wie man Objekt in relationalen Modellen abbildet.
Anwendungsentwickler bzw. Entwicklerinnen denken in Klassen, Objekten und Beziehungen.
Relationale Datenbanken kennen aber nur Tabellen, Primärschlüssel und Fremdschlüssel.
Damit ergibt sich eine Lücke zwischen der objektorientierten und der relationalen Welt. Dies Lücke wird auch als „Impedance Mismatch“ bezeichnet.
Zum Nachschlagen:
• http://www.service-architecture.com/articles/object-oriented- databases/impedance_mismatch.html
• http://www.odbms.org/wp-content/uploads/2013/11/023.01-Shusman-The- Impedance-Mismatch-2002.pdf
Schauen wir uns also wie erwähnt, diese Lücke einmal genauer an.
Auf der linken Seite der Abbildung sehen Sie die relationale Welt. Dort befinden sich:
• Tabellen
• Spalten
• Zeilen
• Primärschlüssel
• Fremdschlüssel
Auf der rechten Seite sehen Sie die objektorientierte Welt. Dort befinden sich:
• Klassen
• Objekte
• Objekt-Ids
• Vererbung
• Attribute
• Objektreferenzen
Um eine solche Lücke überhaupt nicht erst schließen zu müssen, ist die Idee
entstanden, so etwas wie objektorientiere Datenbanken zu entwickeln.
Hierbei trifft man auf zwei verschiedene Lösungsansätze, die wir uns als nächstes näher ansehen wollen.
Auf der Abbildung erkennen Sie die beiden wesentlichen Lösungsansätze für objektorientierte Datenbanken.
Auf der rechten Seite wird davon ausgegangen, dass man in einer
objektorientierten Datenbank die Objekte, Beziehungen und Vererbung direkt unterstützt wird.
Auf der linken Seite wird ein sogenannter OR-Mapper (Object-Relational
Mapper) verwendet, um die objektorientierte Welt auf eine relationale Datenbank abzubilden.
Schauen wir uns zunächst einmal einige grundlegenden Ideen an, wie eine Abbildung der OO-Welt in eine relationale Welt aussehen könnte.
In der Tabelle sind die einzelnen Konzepte gegenüber gestellt. Die grundlegende Idee der Abbildung ist wie folgt:
• Klassen werden auf Tabellen abgebildet
• Objekte werden auf Zeilen in einer Tabelle abgebildet
• Die Objektidentität wird auf Primärschlüssel abgebildet
• Datentypen aus der jeweiligen Programmiersprache werden auf Datenbank- Datentype für die jeweiligen Spalten abgebildet
• Objektreferenzen werden auf JOIN Bedingungen abgebildet
Eine besondere Herausforderung stellt das Konzept der Vererbung dar.
Wie aus der Abbildung ersichtlich wird, bieten sich hier drei verschiedene Verfahren an.
Verfahren 1)
Hier werden für die jeweiligen Sub-Klassen eigene Tabellen angelegt, in der sowohl die Attribute der Superklasse und der Subklasse in Spalten abgelegt wird.
Verfahren 2)
Bei diesem Ansatz, wird nur eine Tabelle angelegt. In dieser Tabelle werden alle Objekte der Superklasse und der jeweiligen Subklassen abgelegt.
Dies führt unter Umständen zu vielen Spalten, in denen nur wenige Spalten einen Wert enthalten.
Verfahren 3)
Her werden jeweils für die Superklasse und die Subklassen, eigene Tabellen angelegt.
Die Konsequenz ist dabei, dass bei jedem Lesen eines Objektes der Subklasse ein JOIN notwendig ist.
In der Praxis werden sogenannte OR-Mapper eingesetzt, die genau diese Abbildung der OO-Welt auf die relationale Welt lösen.
Eines, der zur Zeit bekanntesten Frameworks ist Hibernate. Es ist eine Open- Source Java Framework, welches die bisher genannten Problem des objekt- relationalen Mapping löst.
Zusätzlich zu dem eigentlichen Mapping findet dort auch eine Verwaltung der einzelnen Datenbank-Sessions sowie ein Caching der Daten statt.
Um auf die unterschiedlichen Datenbanken zugreifen zu können, erlaubt Hibernate die Verwendung von unterschiedlichen JDBC Treibern.
Hibernate unterstützt die bisher betrachteten Ansätze bei dem OR-Mapping in Bezug auf Vererbung. (siehe vorherige Abbildungen).
Diese Abbildung zeigt, nochmals kurz das Mapping unter Verwendung der Begriffe wie sie bei Hibernate verwendet werden.
Der Ansatz „Table per Class Hierarchie“ ist dabei ein sehr guter Kompromiss, wenn es um Einfachheit und Performance geht.
Jeder Ansatz hat seine Vor- und Nachteile.
In dieser Abbildung sind die wichtigsten Artefakte dargestellt, die benötigt werden um zum Beispiel ein Objekt in einer Datenbank abzuspeichern.
1) In einer XML Konfigurationsdatei kann man den Namen des JDBC Drivers und die JDBC URL definieren. Hier kann man auch ggf. den Namen und das Password für den Benutzer hinterlegen, mit dem auf die Datenbank
zugegriffen werden soll. In der Praxis wird man dies jedoch nicht tun, da dies ein Sicherheitsrisiko darstellt. Man wird entweder den Namen verschlüsselt einlesen oder ggf. Single-Sign On verwenden.
2) Nach dem Starten der Java Applikation wird in der Regel in der main() Methode veranlasst, dass die Hibernate-Konfigurationsdatei von Hibernate ausgewertet wird. Hierzu stellt das Hibernate API eine entsprechende Static Methode in der Klasse Configuration bereit.
Das Anlegen von Datenbank Tabellen übernimmt dabei Hibernate ganz alleine.
Zum Nachschlagen:
• http://www.ibm.com/developerworks/library/j-hibernate/
Die Tabelle gibt einen Überblick über die am Markt verfügbaren objektorientierten Datenbanken und deren Verbreitung.
Sie sagt natürlich nichts darüber aus, welche Funktionen und Features unterstützt werden und wie gut das OODB Paradigma unterstützt wird..
Bei der Auswahl einer OODB kommt man wie immer nicht umher eigene Recherchen durchzuführen und die einzelnen OODB Lösungen mit seinen eigenen Anforderungen abzugleichen.
Da sich ein Internationaler Standard bisher noch nicht durchgesetzt hat, gibt es unterschiedliche Lösungsansätze bei den einzelnen Hersteller. Die wichtigsten unterschiedlichen Konzepte wollen wir uns als nächstes näher ansehen.
Je nach Programmiersprache, in der eine Applikation erstellt werden soll, ergeben sich unterschiedliche Konzepte bei der Spracheinbindung.
Hier wollen wir uns die Unterschiede von Objektorientierten-Datenbank näher ansehen, um die einzelnen Programmiermodelle besser verstehen zu können.
Wie Sie in der Abbildung sehen, findet man in der Praxis drei Programmiermodelle.
• By Inheritance
• By Instantiation
• By Reachability
Die einzelnen Programmiermodell wollen wir uns als nächstes näher ansehen.
Programmiermodel BY INHERITANCE
Wie in der Abbildung ersichtlich ist, werden hier alle Klassen, deren Objekte in der ODB gespeichert werden sollen, von einer Superklasse abgeleitet,
Diese Superklasse ist dabei Bestandteil der jeweiligen Hersteller Bibliothek.
Dementsprechend unterscheiden sich die Namen der Superklassen von Hersteller zu Hersteller.
Programmiermodel BY INSTANTIATION
Wie in der Abbildung ersichtlich ist, müssen hier die Klassen, deren Objekte in der ODB gespeichert werden sollen, NICHT von einer Superklasse abgeleitet, Stattdessen, müssen die Objekte mittels spezieller NEW-Operatoren erzeugt werden. Dies ist in dieser Weise nur in C++ üblich/möglich.
Programmiermodel BY REACHABILITY
Wie in der Abbildung ersichtlich ist, unterliegen die Klassen und Objekt keinen besonderen speziellen Vorschriften.
Die Speicherung der Objekte erfolgt über sogenannte „ObjektContainer“. Hierbei handelt es sich um ein Objekt, welches die Speicherung der Objekte übernimmt.
In der Praxis werden Objektorientierten Datenbanken nur in speziellen Aufgabenstellungen eingesetzt. In der Regel sind dies Anwendungen die
„navigierend“ auf Daten zugreifen, wie es für Computer Aided Design (CAD) Anwendungen typisch ist.
EineStandardisierung wurde von der Object Management Group vorangetrieben. Der Standard umfasst dabei folgende Definitionen:
• ODL Object Definition Language für die Definition der Datenmodelle
• OML Object Query Language für das Abfragen von ODBs nach Objekten Jedoch hat sich der Standard nicht auf dem Markt durchsetzen können, da die Nachfrage nach ODBS nicht den Erwartungen entsprach.
Quellen:
• JPA - http://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html
• LINQ - https://msdn.microsoft.com/de-de/library/bb397897.aspx
