imported>Neutronstar2: /* Prinzip */

2023-01-19T21:25:26Z

Prinzip

Neue Seite

'''Objektrelationale Abbildung''' ({{enS|object-relational mapping}}, ''ORM'') ist eine Technik der [[Softwareentwicklung]], mit der ein in einer [[Objektorientierte Programmiersprache|objektorientierten Programmiersprache]] geschriebenes [[Anwendungsprogramm]] seine [[Objekt (Programmierung)|Objekte]] in einer [[Relationale Datenbank|relationalen Datenbank]] ablegen kann. Dem Programm erscheint die Datenbank dann als [[objektorientierte Datenbank]], was die Programmierung erleichtert. Implementiert wird diese Technik normalerweise mit [[Klassenbibliothek]]en, wie beispielsweise [[Entity Framework]] für [[.Net-Framework]]-/[[.NET (Plattform)|.NET]]-Programmiersprachen, [[Hibernate (Framework)|Hibernate]] für die Programmiersprache [[Java (Programmiersprache)|Java]], [[Doctrine (PHP)|Doctrine]] für [[PHP]], [[SQLAlchemy]] für [[Python (Programmiersprache)|Python]], [[Active Record]] für [[Ruby (Programmiersprache)|Ruby]] oder Diesel für [[Rust (Programmiersprache)|Rust]]. Für [[Java (Programmiersprache)|Java]] gibt es auch eine standardisierte Schnittstelle, die [[Jakarta Persistence API]].

== Prinzip ==
Objektorientierte Programmiersprachen (OOP) kapseln Daten und Verhalten in Objekten, hingegen legen relationale Datenbanken Daten in Tabellen ab. Die beiden Paradigmen sind grundlegend verschieden. So kapseln Objekte ihren Zustand und ihr Verhalten hinter einer Schnittstelle und haben eine eindeutige Identität. Relationale Datenbanken basieren dagegen auf dem mathematischen Konzept der [[Relationale Algebra|relationalen Algebra]]. Dieser konzeptionelle Widerspruch wurde in den 1990er Jahren als ''[[object-relational impedance mismatch]]'' bekannt.<ref name="RDMDBobjectmis">{{Internetquelle |autor=Ted Neward |url=http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx |titel=The Vietnam of Computer Science |hrsg=Interoperability Happens |datum=2006-06-26 |archiv-url=https://web.archive.org/web/20180122225729/http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx |archiv-datum=2018-01-22 |abruf=2010-06-02 |sprache=en |offline=1}}</ref>

Um den Widerspruch aufzulösen oder zumindest zu mildern, wurden verschiedene Lösungen vorgeschlagen, beispielsweise [[objektorientierte Datenbank]]en oder die Erweiterung von Programmiersprachen um relationale Konzepte (z. B. [[Embedded SQL]]). Die direkte ''objektrelationale Abbildung'' von Objekten auf Relationen hat den Vorteil, dass einerseits die Programmiersprache selbst nicht erweitert werden muss und andererseits relationale Datenbanken als etablierte Technik in allen Umgebungen als ausgereifte [[Software]] verfügbar sind. Nachteil dieses dem OOP-Paradigma entgegenkommenden Ansatzes ist, dass die Stärken und Fähigkeiten von relationalen Datenbanken teilweise nicht genutzt werden, was sich in suboptimaler Leistung niederschlagen kann.

== Grundlegende Techniken ==
Im einfachsten Fall werden [[Klasse (Objektorientierung)|Klassen]] auf [[Datenbanktabelle|Tabellen]] abgebildet, jedes Objekt entspricht einer Tabellenzeile und für jedes [[Attribut (Programmierung)|Attribut]] wird eine Tabellenspalte reserviert. Die Identität eines Objekts entspricht dem [[Primärschlüssel]] der Tabelle. Hat ein Objekt eine [[Referenz (Programmierung)|Referenz]] auf ein anderes Objekt, so kann diese mit einer Fremdschlüssel-Primärschlüssel-Beziehung in der Datenbank dargestellt werden.

Der Begriff ''Shadow Information'' („Schatteninformation“) bezeichnet zusätzliche Daten, die ein Objekt benötigt, um [[Persistenz (Informatik)|persistent]] abgelegt zu werden.<ref name="Ambler.228-229" /> Dazu gehören [[Primärschlüssel]] – speziell wenn es sich um [[Surrogatschlüssel]] ohne fachliche Bedeutung handelt – sowie Hilfsdaten für die Zugriffssteuerung, beispielsweise [[Zeitstempel]].

== Abbildung von Vererbungshierarchien ==
[[Datei:Single Table Inheritance.svg|mini|Tabelle pro Vererbungshierarchie]]
[[Datei:Class Table Inheritance.svg|mini|Tabelle pro Unterklasse]]
[[Datei:Concrete Table Inheritance.svg|mini|Tabelle pro konkrete Klasse]]

Es gibt im Wesentlichen drei verschiedene Verfahren, um [[Vererbung (Programmierung)|Vererbungshierarchien]] auf Datenbanktabellen abzubilden. Einige Frameworks bieten weitere Variationen und Vermischungen dieser drei Grundverfahren.<ref>{{Internetquelle |url=http://docs.jboss.org/hibernate/orm/4.1/manual/en-US/html/ch10.html |titel=Chapter 10. Inheritance Mapping |werk=Hibernate Reference Documentation |hrsg=Red Hat Middleware, LLC |datum=2012 |abruf=2012-07-31 |sprache=en}}</ref>

; Tabelle pro Vererbungshierarchie<ref name="PoEAA" />
: (auch ''{{lang|en|Single Table}}'', ''einzelne Tabelle'') Bei diesem Verfahren werden alle Attribute der Basisklasse und aller davon abgeleiteten Klassen in einer gemeinsamen Tabelle gespeichert. Zusätzlich wird ein sogenannter „Diskriminator“ in einer weiteren Spalte abgelegt, der festlegt, welcher Klasse das in dieser Zeile gespeicherte Objekt angehört. Attribute von abgeleiteten Klassen dürfen bei diesem Ansatz aber in den meisten Fällen nicht mit einem NOT-NULL-[[Constraint]] versehen werden. Außerdem können Beschränkungen der Anzahl erlaubter Spalten pro Tabelle diesen Ansatz bei großen Klassen bzw. Klassenhierarchien vereiteln.
; Tabelle pro Unterklasse<ref name="PoEAA" />
: (auch ''Joined'' oder ''{{lang|en|Class Table}}'') Bei diesem Verfahren wird eine Tabelle für die Basisklasse angelegt und für jede davon abgeleitete Unterklasse eine weitere Tabelle. Ein Diskriminator wird nicht benötigt, weil die Klasse eines Objekts durch eine 1-zu-1-Beziehung zwischen dem Eintrag in der Tabelle der Basisklasse und einem Eintrag in einer der Tabellen der abgeleiteten Klassen festgelegt ist.
; Tabelle pro konkrete Klasse<ref name="PoEAA" />
: (auch ''Table per Class'' oder ''{{lang|en|Concrete Table}}'') Hier werden die Attribute der abstrakten Basisklasse in die Tabellen für die konkreten Unterklassen mit aufgenommen. Die Tabelle für die Basisklasse entfällt. Der Nachteil dieses Ansatzes besteht darin, dass es nicht möglich ist, mit einer Abfrage Instanzen verschiedener Klassen zu ermitteln.

Ein weiteres Verfahren ist die Abbildung von Strukturen (Beziehungen, Vererbung) und Daten in generellen Tabellen ''{{lang|en|General Tables}}''. Dabei enthält die gesamte Datenbank genau 5 Tabellen: Eine für Klassen, eine für Beziehungen (einschließlich Vererbungsbeziehungen), eine für Attribute, eine für Instanzen (der Klassen) und eine für Werte (der Attribute).<ref>[http://www.agiledata.org/essays/mappingObjects.html#MapToGenericStructure Map Classes To A Generic Table Structure]</ref> Dieses Verfahren hat allerdings in der Praxis kaum Bedeutung.

== Literatur ==
* {{Literatur
|Autor=Scott W. Ambler
|Titel=Agile Database Techniques
|Verlag=Wiley & Sons
|Datum=2003
|ISBN=0-471-20283-5
|Online=[http://www.agiledata.org/essays/mappingObjects.html agiledata.org]
|Abruf=2007-10-22}}

== Einzelnachweise ==
<references>
<ref name="Ambler.228-229">
{{Literatur
|Autor=Scott W. Ambler
|Titel=Agile Database Techniques
|Datum=2003
|Seiten=228–229}}
</ref>
<ref name="PoEAA">
{{Literatur
|Autor=Martin Fowler
|Titel=Patterns of Enterprise Application Architecture
|Verlag=Addison-Wesley-Longman
|Ort=Amsterdam
|Datum=2002
|ISBN=0-321-12742-0}}
</ref>
</references>

[[Kategorie:SQL]]
[[Kategorie:Objektorientierte Programmierung]]

Objektrelationale Abbildung - Versionsgeschichte

imported>Neutronstar2: /* Prinzip */