Leistungen
Leistungen
Überblick
Leistungsangebot
Kernkompetenzen
Schulungsthemen
In-House-Schulungen
Offene .NET-Seminare
Offene WPS-Seminare
Beratung
Coaching
Support
Softwareentwicklung
Entwickler-Vermittlung
.NET/Visual Studio
TFS/ALM/Scrum
Webprogrammierung
PowerShell
Konditionen
Anfrage/Kontakt
Beratung/Coaching
Beratung/Coaching
Beratungsthemen
Coaching
Unsere Berater
Referenzkunden
Konditionen
Angebotsanfrage
In-House-Schulungen
In-House-Schulungen
Überblick
Themen/Fachgebiete
Schulungskonfigurator
Konzepte
.NET/Visual Studio
C#
VB.NET
ASP.NET
Moderne Webanwendungen
TFS/ALM/Scrum
PowerShell
Konferenzvortraege
Referenzkunden
Unsere Trainer
Konditionen
Angebotsanfrage
Offene Schulungen
Offene Schulungen
Überblick .NET-Seminare
.NET/C#-Basisseminar
WPF (Desktop)
ASP.NET/AJAX (Web)
WCF/WF (SOA)
ADO.NET/EF (Data)
Windows PowerShell
.NET, C#, VB, Visual Studio
.NET, C#, VB, Visual Studio
Startseite
Beratung/Training
Offene .NET-Seminare
Einführung
Lexikon
Artikel
Bücher
Klassenreferenz
Programmiersprachen
Entwicklerwerkzeuge
Softwarekomponenten
World Wide Wings Demo
Codebeispiele
Scripting
ASP.NET
.NET 2.0
.NET 3.0/3.5
.NET 4.0/4.5
Community
Forum
Kommerzielle Leistungen
ASP.NET
ASP.NET
Startseite
Lexikon
Sicherheit
Konfiguration
Global.asax
Tracing
Technische Beiträge
Klassenreferenz
Programmiersprachen
Entwicklerwerkzeuge
Softwarekomponenten
PowerShell
PowerShell
Überblick
Beratung
In-House-Schulungen
Öffentliche Schulungen
Codebeispiele
Commandlet Extensions
Offene PowerShell-Seminare
Inhouse-Seminare
Windows
Windows
Startseite
Windows Runtime (WinRT)
Windows PowerShell
Windows Scripting
Windows-Schulungen
Windows-Lexikon
Windows-Forum
Windows Scripting
Windows Scripting
Startseite
Lexikon
FAQ
Buecher
Architektur
Skriptsprachen
Scripting-Hosts
Scripting-Komponenten
COM/DCOM/COM+
ADSI
WMI
Scripting-Tools
WSH-Editoren
Codebeispiele
ASP.NET
.NET-Scripting
Forum
Links
Kommerzielle Leistungen
Service
Service
Website-FAQ
Anmeldung/Login
Leser-Registrierung
Gast-Registrierung
Nachrichten/RSS
Newsletter
Foren
Weblog
Lexikon
Downloads
Support
Kontakt
Literaturtipps
Publikationen
Publikationen
Redaktionsbüro
Bücher
Fachartikel
Leser-Portal
Autoren gesucht!
Rezensionen
Über uns
Über uns
Holger Schwichtenberg
Team
Referenzkunden
Kundenaussagen
Referenzprojekte
Partner
Site Map
Weitere Websites
Tag Cloud
Impressum
Rechtliches

Erklärung des Begriffs: Objekt-Relationales Mapping (ORM)
Was ist Objekt-Relationales Mapping (ORM)?

Zurück zur Stichwortliste



Begriff Objekt-Relationales Mapping
Abkürzung ORM
Synonyme/Aliase

Erläuterung des Begriffs Objekt-Relationales Mapping

In der Datenbankwelt sind relationale Datenbanken vorherschend, in der Programmierwelt sind es Objekte. Objekt-Relationales Mapping (ORM) ist die Abbildung von Objekten im Hauptspeicher auf Datensätze in relationalen Datenbanktabellen zum Zwecke der Objektpersistenz.
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.
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. Die unterschiedliche Art der Datenspeicherung zwischen Objektmodell und relationalem Modell werden in der Fachwelt als "Impedance Mismatch" oder "Semantic Gap" bezeichnet.
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.
Dies 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 Objekt-Relationale Mapping (ORM) 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 enthält 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 in den letzten Jahren daran gesetzt, diese Arbeit zu vereinfachen mit Hilfsbibliotheken und Werkzeugen. Dies war die Geburtsstunde vieler ORM-Werkzeuge, die in der Entwicklerumgangssprache in der Regel einfach als "OR-Mapper" bezeichnet werden. 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 eine der drei Punkte gegen "einen OR-Mapper geschrieben" austauschen wollten. Anders ist die Vielfalt der ähnlichen Lösungen kaum erklärbar. Neben den öffentlich bekannten ORM-Werkzeugen für .NET findet man in den Softwareschmieden zahlreiche hauseigene Lösungen.
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!".
Mehr als 20 Werkzeuge aus dem kommerziellen und nicht-kommerziellen Umfeld teilen sich bisher den Markt. Die große Vielfalt an Produkten führte bisher dazu, dass keiner der Drittanbieter eine überragende Marktposition einnehmen konnte.
Mit LINQ-to-SQL und dem ADO.NET Entity Framework bietet Microsoft selbst aber inzwischen sogar zwei verschiedene Produkte an. Microsoft hat aber inzwischen verkündet, dass die Weiterentwicklungsbemühungen sich allein auf das ADO.NET Entity Framework konzentieren. LINQ-to-SQL unterliegt vielen Einschränkungen, insbesondere ist damit nur der Zugang zu Microsoft SQL Server möglich.

Artikel in gedruckten Medien

  • Persistenz-Tool für .NET: OBJ.NET
     (DotNetPro - Das .NET-Magazin für Entwickler, 2005)
  • Von Tabelle zu Formular: TierDeveloper
     (DotNetPro - Das .NET-Magazin für Entwickler, 2005)
  • Querverweise zu anderen Begriffen im Lexikon

    ADO.NET Entity Framework
    Microsoft SQL Server
    LINQ-to-SQL
    Objektmenge
    SQL Server
    DataReader
    Vererbung
    Dokumente
    Datenbank
    DataSet


    Dienstleistungen:

    Beratung/Consulting zu Objekt-Relationales Mapping

    Support zu Objekt-Relationales Mapping

    Schulungen zu diesem Thema: