Objekt-Relationales Mapping (ORM)

Eintrag zuletzt aktualisiert am: 24.05.2022

In der Datenbankwelt sind relationale Datenbanken vorherschend, in der Programmierwelt sind es Objekte. Zwischen den beiden Welten gibt es erhebliche semantische und syntaktische Unterschiede, die man unter dem Begriff "Impedance Mismatch" (zu deutsch: Unverträglichkeit, vgl. [https://dict.leo.org/englisch-deutsch/impedance%20mismatch]) oder "Semantic Gap" (zu deutsch: demantische Lücke) zusammenfasst
Kern des objektorientierten Programmierens (OOP) ist die Arbeit mit Objekten als Instanzen von Klassen im Hauptspeicher. Die meisten Anwendungen haben dabei auch die Anforderung, in Objekten gespeicherte Daten dauerhaft zu speichern, insbesondere in Datenbanken. Grundsätzlich existieren objektorientierte Datenbanken (OODB), die direkt in der Lage sind, Objekte zu speichern. Aber objektorientierte Datenbanken haben bisher nur eine sehr geringe Verbreitung. Der vorherrschende Typus von Datenbanken sind relationale Datenbanken, die jedoch Datenstrukturen anders abbilden als Objektmodelle.
Um die Handhabung von relationalen Datenbanken in objektorientierten Systemen natürlicher zu gestalten, setzt die Software-Industrie seit Jahren auf O/R-Mapper (auch: OR-Mapper oder ORM geschrieben). O steht dabei für objektorientiert und R für relational. Diese Werkzeuge bilden demnach Konzepte aus der objektorientierten Welt, wie Klassen, Attribute oder Beziehungen zwischen Klassen auf entsprechende Konstrukte der relationalen Welt, wie zum Beispiel Tabellen, Spalten und Fremdschlüssel, ab. Der Entwickler kann somit in der objektorientierten Welt verbleiben und den O/R-Mapper anweisen, bestimmte Objekte, welche in Form von Datensätzen in den Tabellen der relationalen Datenbank vorliegen, zu laden bzw. zu speichern. Wenig interessante und fehleranfällige Aufgaben, wie das manuelle Erstellen von INSERT-, UPDATE- oder DELETE-Anweisungen übernimmt hierbei auch der O/R-Mapper, was zu einer weiteren Entlastung des Entwicklers führt.

Zwei besonders hervorstechende Unterschiede zwischen Objektmodell und Relationenmodell sind N:M-Beziehungen und Vererbung. Während man in einem Objektmodell eine N:M-Beziehung zwischen Objekten durch eine wechselseitige Objektmenge abbilden kann, benötigt man in der relationalen Datenbank eine Zwischentabelle. Vererbung kennen relationale Datenbanken gar nicht. Hier gibt es verschiedene Möglichkeiten der Nachbildung, doch dazu später mehr.

ORM in der .NET-Welt

Wenn ein .NET-Entwickler aus einer Datenbank mit einem DataReader oder DataSet Daten einliest, dann betreibt er noch kein ORM. DataReader und DataSet sind zwar .NET-Objekte, aber diese verwalten nur Tabellenstrukturen. DataReader und DataSet sind aus der Sicht eines Objektmodells untypisierte, unspezifische Container. Erst wenn ein Entwickler spezifische Klassen für die in den Tabellen gespeicherten Strukturen definiert und die Inhalte aus DataSet oder DataReader in diese spezifischen Datenstrukturen umkopiert, betreibt er ORM. Solch ein "händisches ORM" ist für den Lesezugriff (gerade bei sehr breiten Tabellen) eine sehr aufwändige, mühselige und eintönige Programmierarbeit. Will man dann auch noch Änderungen in den Objekten wieder speichern, wird die Arbeit allerdings zur intellektuellen Herausforderung, denn man muss erkennen können, welche Objekte verändert wurden, da man sonst ständig alle Daten wieder speichert, was in Mehrbenutzerumgebungen ein Unding ist.
Während in der Java-Welt das ORM-Wekrzeuge schon sehr lange zu den etablierten Techniken gehört, hat Microsoft diesen Trend lange verschlafen bzw. es nicht vermocht, ein geeignetes Produkt zur Marktreife zu führen. ADO.NET in .NET 1.0 bis 3.5 enthielt keinen ORM, sondern beschränkt sich auf den direkten Datenzugriff und die Abbildung zwischen XML-Dokumenten und dem relationalen Modell.
Viele .NET-Entwickler haben sich daher daran gesetzt, diese Arbeit zu vereinfachen mit Hilfsbibliotheken und Werkzeugen. Dies war die Geburtsstunde eine großen Vielfalt von ORM-Werkzeuge für .NET. Dabei scheint es so, dass in dem geflügelten Wort, dass ein Mann in seinem Leben einen Baum gepflanzt, ein Kind gezeugt und ein Haus gebaut haben sollte, viele .NET-Entwickler die Punkte um "einen OR-Mapper geschrieben" ergänzt haben (wobei der Autor dieses Buchs sich davon nicht freisprechen kann, weil er auch keine OR-Mapper geschrieben hat). Anders ist die Vielfalt der ähnlichen Lösungen kaum erklärbar. Neben den öffentlich bekannten ORM-Werkzeugen für .NET findet man in den Unternehmen zahlreiche hauseigene Lösungen.
Bekannte öffentliche ORM für .NET von Drittanbietern (z.T. Open Source) sind:
 nHibernate
 Genome
 LLBLGenPro
 Wilson
 Subsonic
 OBJ.NET
 .NET Data Objects (NDO)
 Dapper
 PetaPoco
 Massive
 Developer Express XPO
 Telerik Data Access (alias Open Access) * 2016 eingestellt

Neben den aktiven Entwicklern von ORM-Werkzeugen für .NET und den passiven Nutzern gibt eine noch größere Fraktion von Entwicklern, die ORM bisher nicht einsetzen. Meist herrscht Unwissenheit, die auch nicht aufgearbeitet wird, denn es herrscht das Motto "Wenn Microsoft es nicht macht, ist es auch nicht wichtig!".
Mit LINQ-to-SQL und dem ADO.NET Entity Framework sowie Entity Framework bietet Microsoft selbst aber inzwischen sogar drei verschiedene Produkte an. Microsoft hat aber inzwischen verkündet, dass die Weiterentwicklungsbemühungen sich allein auf das Entity Framework Core konzentieren.