Object-relational impedance mismatch

Als Object-relational Impedance Mismatch – oft auch nur Impedance Mismatch – (englisch etwa für objekt-relationale Unverträglichkeit) bezeichnet man ein Problem der Informatik in der Anwendungsentwicklung, das auftritt, wenn Objekte aus einer objektorientierten Programmiersprache in einer relationalen Datenbank gespeichert werden.

Hintergrund

Das Problem entstand, als sich objektorientierte Programmiersprachen in vielen Bereichen durchzusetzen begannen, während die Daten seit Jahrzehnten in relationalen Datenbanken gespeichert werden. Objektorientierte Anwendungen stellen ihre Daten durch Objekte dar. Sollen die Daten gespeichert werden, so liegt es nahe, die Objekte an sich in einer Datenbank zu speichern. Es stellt sich allerdings heraus, dass das relationale Datenbankmodell grundlegende Unterschiede zum objektorientierten Modell aufweist. Diese Unverträglichkeit wird als Impedance Mismatch bezeichnet.

Problembeschreibung

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.^[1]

• Struktur. Ein Objekt enthält sowohl Daten als auch Verhalten. Die entsprechende Klasse kann Teil einer Klassenhierarchie sein.^[2] Das relationale Modell unterstützt keine solchen objektorientierten Konzepte wie Vererbung (Generalisierung und Spezialisierung). Ein Tupel im Sinne eines relationalen Modells stellt lediglich eine Wahrheitsaussage dar.^[1] 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.^[3]
• Identität. Ein Objekt besitzt eine von seinem Zustand (Daten) unabhängige Identität.^[2] Wird eine objekt-orientierte Anwendung zwei mal 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).^[4] 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.^[2] 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^[4]).
• 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.^[5] Die Operationen, die auf einer relationaler Datenbank ausgeführt werden können, arbeiten mengenbasiert, wohingegen Objekte individuell mit anderen kommunizieren (message passing^[2]).

Lösungsansätze

Objektorientierte Datenbank

Die nächstliegende 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.

Objektrelationale Datenbank

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.

Programmiersprache um relationale Funktionen erweitern

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.

O/R-Mapper

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^[1] 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 die Möglichkeit zur Definition neuer Datentypen in objektorientierten Sprachen durch eigene Klassen ein integraler Bestandteil jener.
• 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.

Fazit

Sämtliche bisher existierenden Lösungsansätze bieten keine wirkliche Lösung an, nur eine mehr oder weniger elegante Umgehung des Problems. Egal für welche Lösung man sich entscheidet – solange die Systeme unterschiedlich sind, wird jeder Entwickler früher oder später an den Punkt gelangen, an dem seine Lösung einen oder mehrere der folgenden Punkte nicht mehr erfüllt.^[6]

• Wartbarkeit
• Performance
• Verständlichkeit

Referenzen

1. ↑ ^{a b c} Christopher Ireland, David Bowers, Michael Newton, Kevin Waugh: A Classification of Object-Relational Impedance Mismatch. In: IEEE Computer Society (Hrsg.): Advances in Databases, First International Conference on. 0, März 2009, S. 36-43. doi:10.1109/DBKDA.2009.11.
2. ↑ ^{a b c d} Deborah J. Armstrong: The quarks of object-oriented development. In: Commun. ACM. 49, Nr. 2, Februar 2006, S. 123-128. doi:10.1145/1113034.1113040.
3. ↑ Craig Russell: Bridging the object-relational divide. In: ACM (Hrsg.): Queue. 6, Nr. 3, 28. Juli 2008, S. 18-28. doi:10.1145/1394127.1394139.
4. ↑ ^{a b} Edgar F. Codd: The relational model for database management: version 2. Addison-Wesley Longman Publishing Co., Inc 1990, ISBN 0-201-14192-2
5. ↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design patterns: elements of reusable object-oriented software. Addison-Wesley Professional, 1995.
6. ↑ Ted Neward (26. Juni 2006): The Vietnam of Computer Science. Interoperability Happens. Abgerufen am 2. Juni 2010.

Weblinks

• The Vietnam of Computer Science. blogs.tedneward.com, abgerufen am 15. Oktober 2011 (englisch). 
• Philipp Scheit: Analyse und Lösungen für den Object-relational Impedance Mismatch. Diplomarbeit. 13. Dezember 2010, abgerufen am 15. Oktober 2011 (pdf).