26_8335_902-OODB-Entwicklungstendenz - Offene

1
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?
2
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.
Im nächsten Schritt wollen wir uns genau diese Problem bei der Abbildung näher
ansehen.
3
Anwendungsentwickler bzw. Entwicklerinnen denken in Klassen, Objekten und
Beziehungen.
Relationale Datenbanken kennen aber nur Tabellen, Primärschlüssel und
Fremdschlüssel.
4
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-orienteddatabases/impedance_mismatch.html
• http://www.odbms.org/wp-content/uploads/2013/11/023.01-Shusman-TheImpedance-Mismatch-2002.pdf
5
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
6
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.
6
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.
7
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 DatenbankDatentype für die jeweiligen Spalten abgebildet
• Objektreferenzen werden auf JOIN Bedingungen abgebildet
8
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.
9
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 OpenSource Java Framework, welches die bisher genannten Problem des objektrelationalen 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.
10
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.
11
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.
3) Nach der Auswertung der Hibernate Konfigurations-Datei kennt nun
Hibernate alle Details, um auf die Datenbank zugreifen zu können.
4) In der Praxis werden Java Annotationen verwendet, um Hibernate
mitzuteilen, wie das OR–Mapping erfolgen soll. Diese Annotationen sind
natürlich nur bei den Java Klassen notwendig, dessen Objekt in der
Datenbank gespeichert werden sollen.
5) Wird nun versucht über das Hibernate API ein Objekt in der Datenbank zu
speichern, wertet Hibernate die entsprechenden Annotationen aus und kann
damit über eine JDBC Schnittstelle die Speicherung veranlassen.
12
Das Anlegen von Datenbank Tabellen übernimmt dabei Hibernate ganz alleine.
Zum Nachschlagen:
• http://www.ibm.com/developerworks/library/j-hibernate/
12
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.
Quellen:
• http://db-engines.com/en/ranking/object+oriented+dbms
Zum Nachlesen:
• http://www.odbms.org/wpcontent/uploads/2013/11/icoodb2010Grossniklaus.tutorial.pdf
13
Je nach Programmiersprache, in der eine Applikation erstellt werden soll, ergeben
sich unterschiedliche Konzepte bei der Spracheinbindung.
14
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.
15
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.
16
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.
17
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.
18
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.
Eine Standardisierung 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.
Siehe hierzu auch :
https://www.researchgate.net/publication/269990280_A_Comparison_Study_Of_
Object-Oriented_Database_Management_Systems
Zum Nachschlagen:
• ODMG: http://www.odbms.org/odmg-standard/
19
Quellen:
• JPA - http://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html
• LINQ - https://msdn.microsoft.com/de-de/library/bb397897.aspx
20
21
22