Object-relational impedance mismatch

Objektorientierte Anwendungen kapseln ihre Daten in Objekten. Sollen die Daten gespeichert werden, so bieten sich unter anderem die Tabellen einer relationalen Datenbank an. Es stellt sich allerdings heraus, dass das relationale Datenbankmodell grundlegende Unterschiede zum objektorientierten Modell aufweist.

Die mangelnde Passgenauigkeit der Behandlung von Daten in objektorientierten Programmiersprachen und in relationalen Datenbanken erfordert komplizierte bidirektionale Abbildungen. Dies wird seit Anfang der 1980er Jahre als Impedance Mismatch bezeichnet.^[1]

Das Problem liegt in den unterschiedlichen Paradigmen der beiden Systeme begründet. So lässt sich ein Objekt durch vier grundlegende Eigenschaften charakterisieren:

• Identität
• Zustand
• Verhalten
• Kapselung

Ein relationales System hingegen leitet sich aus der relationalen Algebra ab und speichert Wahrheitsaussagen in sog. Relationen. Eine Relation könnte z. B. so aussehen: {Name, Firma}. Diese Relation entspricht einer Behauptung der Form: „Es existiert eine Person mit Namen NAME, die bei einer Firma FIRMA arbeitet“. Ein Tupel ist eine Wahrheitsaussage innerhalb der Relation, die z. B. so aussieht: {John Doe, ACME} (Es gibt einen John Doe, der bei ACME arbeitet.). Ein Tupel setzt sich wiederum aus Attributen (Name und Firma) zusammen. Durch Verknüpfung von Relationen lassen sich neue Relationen bilden und damit neue Wahrheitsaussagen ableiten, wie z. B. die Antwort auf „Wie viele Personen gibt es, die bei ACME arbeiten?“.

Eine nähere Betrachtung der beiden Paradigmen zeigt, dass es einige Unterschiede gibt.^[2]

• Struktur. Ein Objekt enthält sowohl Daten als auch Verhalten. Die entsprechende Klasse kann Teil einer Klassenhierarchie sein.^[3] Das relationale Modell unterstützt keine solcher objektorientierten Konzepte wie Vererbung (Generalisierung und Spezialisierung). Ein Tupel im Sinne eines relationalen Modells stellt lediglich eine Wahrheitsaussage dar.^[2] Betrachtet man eine Klasse-Subklasse-Beziehung, so wird im objektorientierten Modell lediglich ein Objekt zur Darstellung der Daten benötigt, wohingegen redundanzfreie Darstellungen im relationalen Modell zwei Tupel benötigen.^[4]
• Identität. Ein Objekt besitzt eine von seinem Zustand (Daten) unabhängige Identität.^[3] Wird eine objektorientierte Anwendung zweimal ausgeführt, so besitzt das gleiche Objekt (im Sinne seines Zustands) unterschiedliche Identitäten. Ebenfalls unterscheiden sich zwei datengleiche Objekte in einem Programmablauf durch deren Identitäten. Im Gegensatz dazu ist die Identität eines Tupels durch dessen Daten bestimmt (bzw. durch den Primärschlüssel, der sich aus den Daten des Tupels ergibt).^[5] Ein Tupel kann also jederzeit anhand seiner Daten eindeutig identifiziert werden, was für ein Objekt nicht gilt.
• Datenkapselung. Ein Objekt schützt seine Daten vor Veränderungen bzw. grenzt durch Methoden (das Verhalten) die Art, wie Daten verändert werden können, ein.^[3] Ein Objekt gibt also die Möglichkeit, Daten in wohldefinierten Wegen zu verändern. Im Gegensatz dazu existieren keine solchen Schutzmechanismen im relationalen Modell (viele Datenbankhersteller erweitern den SQL-Standard, um Wege zu schaffen, dies zu erreichen, allerdings ist dies kein grundlegender Bestandteil des relationalen Modells^[5]).
• Arbeitsweise. Die Daten einer relationalen Datenbank werden durch Transaktionen von einer verbundenen Anwendung modifiziert. Dies erinnert stark an das prozedurale Programmieren, dessen charakteristische Eigenschaft die Trennung von Daten und Verhalten ist. Das objektorientierte Modell gruppiert logisch zusammenhängendes Verhalten mit für dieses Verhalten relevanten Daten in Objekten. Eine objektorientierte Anwendung kann als Netzwerk interagierender Objekte gesehen werden.^[6] Die Operationen, die auf einer relationalen Datenbank ausgeführt werden können, arbeiten mengenbasiert, wohingegen Objekte individuell mit anderen kommunizieren (message passing^[3]).

Es existieren verschiedene Lösungsansätze mit unterschiedlichen Vor- und Nachteilen^[7].

Bei der Speicherung von Daten in schemafreien Datenbanken kann jeder Datensatz eine andere innere Struktur haben. Der Anwendungsentwickler bildet seine Anwendungsdaten nicht mehr auf ein normalisiertes Relationenmodell ab; stattdessen haben die Datensätze unterschiedliche Felder oder es wird auf eine hierarchische Datenstruktur abgebildet; oft auch denormalisiert. Die Reibungsverluste durch den Object-Relational Impedance Mismatch entfallen und es entstehen Kosten durch einen anderen Impedance Mismatch.

Eine naheliegende Lösung ist, die relationale Datenbank durch eine objektorientierte Datenbank zu ersetzen. Die programmatische Handhabung wird dadurch erleichtert, komplexe Abfragen können aber sehr kompliziert werden. Des Weiteren stößt man damit bei Geschäftsführung und Datenbankadministratoren oft auf Ablehnung, da die Daten fest mit dem Objekt verdrahtet sind und nicht ohne die dazugehörige Anwendung sichtbar gemacht werden können. Etwaiges Mapping entfällt komplett.

Viele der namhaften Hersteller erweiterten ihre relationalen Datenbankprodukte mit objektorientierten Features zu einem objektrelationalen Datenbankmanagementsystem (ORDBMS). Damit reagieren sie auf die Nachfrage nach objektorientierten Datenbanken. Bestehende Architekturen mit relationalen Datenbanken können durch diese Upgrades erhalten bleiben und bieten dem Entwickler eine objektorientierte Sicht auf die Daten. Der Impedance Mismatch wird damit größtenteils umgangen, je nach Datenbanksystem muss aber immer noch auf Mapping zugegriffen werden.

Damit wird das Problem rückwärts gelöst. Durch die relationale Unterstützung der verwendeten Sprache (z. B. Embedded SQL) ist kein Mapping mehr notwendig. Diese Lösung widerstrebt allerdings vielen OOP-Entwicklern, da sie die Verwendung von Objekten meist einschränkt.

Ein objektrelationaler Mapper ist eine Schicht zwischen der Anwendung und der Datenbank. Er kümmert sich um das komplette Mapping zwischen Objekten und Tabellen. Dieser Vorgang ist für den Entwickler unsichtbar. Heutige Mapper sind sehr performant – bei steigender Komplexität ergeben sich daraus allerdings eine Vielzahl weiterer Probleme. Je spezieller die Lösung ist, desto häufiger muss der Entwickler bestimmen, wie das Mapping zwischen den Welten geschehen soll. Dies kann mitunter äußerst kompliziert werden.

Ein O/R-Mapper muss Probleme auf verschiedenen Ebenen lösen. Ein Ansatz^[2] beschreibt vier Ebenen:

• Paradigma. Ein Paradigma in diesem Kontext ist ein Konzept zur Repräsentierung von Daten. Objektrelationales Mapping muss die Unterschiede der Paradigmen überwinden können. In dem vorhergehenden Abschnitt wurden diese bereits erläutert.
• Sprache. Eine Sprache wird verwendet, um ein Modell durch ein Paradigma auszudrücken. Häufig verwendete objektorientierte Programmiersprachen sind z. B. Java und C#. Relationale Datenbanken werden mittels SQL angesprochen. Ein wesentlicher Unterschied zwischen diesen ist deren Typensystem. Der SQL-Standard definiert gewisse einfache Datentypen, die zur Speicherung von Daten verwendet werden können. Um komplexe Daten zu speichern, werden eigene Tabellen benötigt. Im Gegensatz dazu ist in objektorientierten Sprachen die Möglichkeit zur Definition neuer Datentypen durch eigene Klassen ein integraler Bestandteil.
• Schema. Ein Schema ist ein in einer konkreten Sprache ausgedrücktes Modell. Quellcode und Datenbankskripts können als Schema einer objektrelationalen Anwendung gesehen werden. Die meisten O/R-Mapper benötigen eine gewisse Art von Konfiguration (häufig eine Mapping-Datei), um die Unterschiede der Schemata zu überwinden. Es ist zu beachten, dass die Entwickler des objektorientierten Schema im Regelfall darauf achten, dass mit den Objekten leicht komplexe Businesslogik abgebildet werden kann, während ein Datenbankdesigner normalerweise darauf bedacht ist, Redundanz zu vermeiden und Leistung zu optimieren (z. B. durch Normalisierung des Datenbankschemas).
• Instanz. Instanz in diesem Kontext bedeutet konkrete Daten. Diese Ebene beschäftigt sich hauptsächlich mit Problemen wie Zugriff und Modifikation der Daten sowie Konvertierung verschiedener Datentypen etc.

1. ↑ C. Copeland, D Maier: Making smalltalk a database system. In: ACM SIGMOD Records. vol. 14, 2, 1984, S. 316–325.
2. ↑ ^{a b c} Christopher Ireland, David Bowers, Michael Newton, Kevin Waugh: A Classification of Object-Relational Impedance Mismatch. In: Advances in Databases, First International Conference on. IEEE Computer Society, 2009, ISBN 978-0-7695-3550-0, S. 36–43, doi:10.1109/DBKDA.2009.11. 
3. ↑ ^{a b c d} Deborah J. Armstrong: The quarks of object-oriented development. In: Commun. ACM. Band 49, Nr. 2, Februar 2006, ISSN 0001-0782, S. 123–128, doi:10.1145/1113034.1113040. 
4. ↑ Craig Russell: Bridging the object-relational divide. In: Queue. Band 6, Nr. 3. ACM, 28. Juli 2008, ISSN 1542-7730, S. 18–28, doi:10.1145/1394127.1394139. 
5. ↑ ^{a b} Edgar F. Codd: The relational model for database management: version 2. Addison-Wesley Longman Publishing, Boston, MA, USA 1990, ISBN 0-201-14192-2 (acm.org [PDF; 27,3 MB]). 
6. ↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design patterns: elements of reusable object-oriented software. Addison-Wesley Professional, 1995.
7. ↑ Ted Neward: The Vietnam of Computer Science. In: Ted Neward's Blog. 26. Juni 2006, abgerufen am 2. Juni 2010 (englisch). 

• Ted Neward: The Vietnam of Computer Science. In: Ted Neward's Blog. 26. Juni 2006, abgerufen am 15. Oktober 2011 (englisch).