Objekte, Entitäten und der “Impedance Mismatch”

Hier ein Beitrag für Datenmodellierungsexperten von Jens Gassner, unserem Experten für Datenmodellierung:

Zusammenfassung: „Entität“ und „Objekt“ sind die Schlüsselwörter dieses Beitrags. Die Unterschiede zwischen diesen Konzepten sind wohlbekannt und werden mit dem Schlagwort „impedance mismatch“ bezeichnet. Hier wird aber das Gemeinsame beider Welten belegt und gezeigt, wie diese Sichtweise einen Beitrag zur begrifflicher Klarheit und zur Verringerung von Modellierungskosten in IT-Projekten leisten kann.

„An entity is an object that doesn’t know how to behave.“ Das ist nur eine der möglichen Antworten auf die Frage nach dem Zusammenhang zwischen Objekten und Entitäten. Eine andere Reaktion ist einfach ein etwas süffisantes Grinsen. Offenbar liegt zwischen Objekt und Entität eine Art Wasserscheide: „Entität“ riecht altbacken, während „Objekt“ Modernität signalisiert. Und in der Tat gibt es wohl kaum eine aktuelle Idee oder Diskussion in der Informatik, die nicht auf dem Gedankengut und dem Vokabular der Objektorientierung aufbaut.

Tabelle zum „Impedance Mismatch“

Die Tabelle nennt einige der Unterschiede, während das bonmot am Anfang – es stammt übrigens von Bachmann, Proponent eines frühen Modellierungswerkzeugs – eher Wert auf das legt, was die beiden Welten verbindet.

Ein Gedankenexperiment: Sie sollen eine Anwendung für ein Sachgebiet Ihrer Wahl bauen. Die Bitte an Sie ist, im Kopf ein Klassendiagramm dafür zu entwerfen, und dann ein Entity-Relationship-Diagramm. Oder umgekehrt, je nach dem, aus welcher der beiden Denkrichtungen Sie kommen. Vergleichen Sie Ihre Klassen und Ihre Entitäten.

Mein Ergebnis: Ein hoher Grad an Übereinstimmung auf einem wesentlichen Teilbereich der Diagramme. Es gibt „Kästchen und Striche“, es gibt die „Zahlen“ an den Strichen. Einige der objektorientierten Kästchen tragen dieselben Überschriften wie ihre Kollegen auf der Entitäts-Seite. An diesen Stellen passt das Netzwerk der Striche gut zueinander und es stimmt auch viel vom Inhalt überein; die Namen für die Datenelemente. Aber bei den Klassen gibt es mehr Einträge: Den Entitäten fehlen die „Methoden“, d.h. im Gegensatz zum Objekt macht die Entität keine Aussage über ihr Verhalten, daher der Bachmannsche Spruch.

Jetzt werfen wir einen Blick auf die Stellen in den Diagrammen, an denen keine Übereinstimmung herrscht.

Objekt, aber keine Entität: Schauen Sie sich auch einmal die Objekte an, zu denen Sie keine Entitäten finden. Das sind Objekte, die für Verarbeitung der Daten oder die Interaktion mit dem Benutzer gebraucht werden. Auch das Eingabefenster auf dem Bildschirm ist in der objektorientierten Denkweise ein Objekt. Um solche Objekte kümmert sich die Modellierung von Entitäten nicht, da zählt nur das, was hinterher in der Datenbank landen soll. Das Klassendiagramm bezieht sich also auf einen größeren Themenbereich als das E/R-Diagramm.

Entität, aber keine Objekt: Umgekehrt gibt es Entitäten, zu denen Sie kein Objekt finden. Aber nur auf den ersten Blick. Bei genauerem Hinsehen finden Sie die fehlenden Daten als Teil anderer Objekte: Die Daten eines Objekts können ineinander verschachtelt sein – anders als bei einer Entität. Für die mächtigeren Datensturkturen ist aber ein Preis zu bezahlen. Ich komme später darauf zurück.

Objekt als weiterentwickelte Entität: Es spricht also einiges dafür, Objekte für eine Weiterentwicklung von Entitäten zu halten. Das ist kein Wunder: Die Entitäten waren zuerst da. Aber auf dem Weg von der Entität zum Objekt ist auch etwas verloren gegangen, nämlich der Schlüssel. „Ein Objekt ist eine Entität, die ihren Schlüssel sucht …“

Schlüssel schaffen Klarheit: Ein Schlüssel identifiziert eine Entität über Dateninhalte. Wer jemals Schlüssel zusammen mit den künftigen Anwendern eines System festgelegt hat, der wird erstens froh sein, wenn er das Ergebnis zusammenhängend aufschreiben kann, for future reference, und wenn er auch Budgetverantwortung hat, wird er zweitens dankbar dafür sein, diese Diskussion geführt zu haben, solange noch nichts programmiert ist.

Objekte werden einfach durchnummeriert – so kommen die obigen Diskussionen später auf, vielleicht zu spät.

Weiter unten in diesem Text werden wir uns dieses Thema aus einem anderen Blickwinkel ansehen. Vorerst schauen wir uns praktische Situationen an, die eine Durchgängigkeit zwischen Objekt und Entität wünschbar erscheinen lassen.

Ein extremes Beispiel für „Objekt = Entität“: Ich war letztens bei der Vorstellung eines Werkzeugs zur Code-Generierung. Man steckt ein graphisch spezifiziertes Modell in den Generator und bekommt eine eine lauffähige Java-Applikation heraus, mit eingeschränktem Funktionsumfang (create, retrieve, update, delete). Die Teilnehmer der Veranstaltung durften sich neue features für die nächste Version des Generators wünschen. Das Ergebnis: Ein Datenbank-Reverser. Dieser liest die Datenstrukturen einer lebendigen Datenbank und macht daraus einen Teil der Eingabe für den Generator. Darüber hinaus braucht der Generator nicht mehr viel, um seine Java-Applikation zu erzeugen. Auf den erzeugten Code kann man aufbauen, fehlende Funktionen einbauen.

Wer sich so einen Datenbank-Reverser wünscht, muss wohl der Meinung sein, dass es praktische Zwecke gibt, für die egal ist, ob das Rechteck Entität oder Objekt heißt.

Datenmodellierung mit objektorientiertem Tool: Ich befasse mich mit Programmen zur Übertragung von Modellen zwischen Modellierungstools.

Bei den weitaus meisten Klassenmodellen, die auf meinem Schreibtisch landen, handelt es sich um Datenmodelle, die mit einem objektorientierten Modellierungswerkzeug erfasst wurden. Wie kommt das?

Häufig wird bei Fachkonzepten ein objektorientiertes Modellierungswerkzeug eingesetzt, weil das Fachkonzept über die Daten hinaus auch die Abläufe durchbuchstabieren will. Danach baut man die Datenbank. Das können die objektorientierten Tools nicht so gut. Also kommt meist der Wunsch auf, die modellierten Klassen in ein Datenbank-Werkzeug zu übertragen. Der Modell-Transfer liefert dort etwas ab, was als Ausgangspunkt für das Datenbank-Design taugt.

Leider macht sich an dieser Stelle die gedankliche Barriere zwischen Objekt und Entität negativ bemerkbar.

UML kennt keine Schlüssel – unter anderem. Der Standard für objektorientierte Modellierung heißt UML – Unified Modelling Language. Vor UML gab es eine Vielzahl objektorientierter Systematiken, UML hat den Anspruch, diese zu vereinheitlichen, daher das „U“ im Namen. Entitäten und Relationships und besonders Schlüssel sind bei dieser Vereinheitlichung aber außen vor geblieben.

Problem gelöst? Nicht ganz. Jeder spezielle Zweck benötigt, jede Organisation schafft ihr eigenes Profil, und im Rahmen eines Projekts werden unterschiedliche Zwecke verfolgt und es sind verschiedene Organisationen beteiligt. Jede Zeit schafft sich ihren eigenen Turm zu Babel.

JJG