Ein Ansatz für ein Konzept Objektrelationaler

Ein Ansatz für ein Konzept Objektrelationaler Datenbanksysteme
Ich möchte mit diesem Skript einen eigenen Ansatz für Objektrelationale Datenbanksysteme
beschreiben. Meine Idee ist es, das Konzept der Relationalen Datenbanken weitestgehend
beizubehalten und die Objektorientierten Prinzipien dort lediglich hineinzuinterpretieren, um ein
Verständnis für die bereits vorhandenen Verbindungen beider Konzepte zu schaffen. Darüber hinaus
werden notwendige Erweiterungen erarbeitet, um eine echte Unterstützung der Objektorientierung in
Relationalen Datenbanksystemen zu erreichen.
Für relationale Datenbanken ist charakteristisch, dass sie einzig und allein aus Relationen
zusammengesetzt sind. Ein Tupel wird dabei durch einen Primärschlüssel eindeutig definiert. Die
Beziehungen zwischen den Relationen werden durch Fremdschlüssel hergestellt. Ein
objektorientierter Aufsatz darf diese Prinzipien nicht verletzen!
Die Grundkonzepte der Objektorientierung lauten Datenabstraktion, Datenkapselung, Vererbung und
Polymorphismus. Diese Konzepte sind nun auf relationale Datenbanken zu übertragen. Des Weiteren
muss geklärt werden, was bei relationalen Datenbanken ein Objekt, ein Attribut, eine Methode und
was eine Klasse ist.
Beginnen wir mit Letzterem: Eine Klasse entspricht einer Relation. Die Attribute einer Klasse
entsprechen den Attributen einer Relation. Dadurch wären die Daten einer Klasse im Sinne der
objektorientierten Programmierung beschrieben. Was ist aber mit den Methoden? Wie ist der Zugriff
auf diese Daten geregelt? Nun ja, dafür gibt es die Datenbankzugriffssprache SQL, genauer gesagt
DML. Die Methoden, sind für jede Klasse gleich. Sie heißen „insert“, „update“, „delete“ und „select“.
Dass nicht für jede Klasse eigene Methoden definiert werden sollen hat zwei Gründe. Zum einen wird
dadurch die Einfachheit der Relationalen Datenbanken erhalten und zum zweiten ist die
Notwendigkeit dafür überhaupt nicht gegeben, wenn man sich vor Augen führt, dass ein DBMS zur
Verwaltung von Datenbeständen, nicht aber zur Programmierung eines operativen
Anwendungssystems dient. Hier muss man zwischen der Anwendungsentwicklung und dem
Datenmanagement strikt unterscheiden.
Zu den vier Grundkonzepten der OOP: Die Datenabstraktion ist die Bildung von Klassen zur
Beschreibung von Objekten. Da eine Relation per Definition eine Klasse ist und eine Relation mit SQL
selbstverständlich angelegt, geändert und gelöscht werden kann, ist diesem Konzept mit dem bereits
vorhandenen Mitteln vollends genüge getan.
Die Datenkapselung bezeichnet die Zugriffskontrolle auf die Daten. Auch dies ist durch SQL schon mit
Hilfe des „grant“-Befehls abgedeckt. Zudem hilft das Transaktionsprinzip, um gegen Inkonsistenzen
gewappnet zu sein. Und zu guter letzt ist ein direkter Zugriff auf die Attribute generell nicht möglich.
Dies ist schon bei rein relationalen Datenbanken nur per SQL bzw. genauer formuliert über die
„Methoden“ der DML möglich.
Von Vererbung spricht man in der Objektorientierten Programmierung, wenn eine Klasse die Attribute
und Methoden einer anderen Klasse übernimmt bzw. erbt. So muss in der erbenden Klasse, in der
„abgeleiteten Klasse“, lediglich das Spezielle dieser Klasse definiert werden, nicht aber das
Allgemeine, das bereits in der vererbenden Klasse, der „Basisklasse“, definiert ist. Um die Vererbung
in relationalen Datenbanken zu integrieren muss zunächst klar sein, dass es sich bei der Beziehung
zwischen Basisklasse und abgeleiteter Klasse um eine 1:1-Beziehung handelt – nie um eine 1:nBeziehung! Ein Beispiel, um die Vererbung von Klassen inhaltlich in Relationen abzubilden, sei im
Folgenden aufgezeigt:
Mitarbeiter
Nr
Name
Vorname
Angestellter
Nr
Gehalt
Arbeiter
Nr
Stundenlohn
Es erben die Relationen „Angestellter“ und „Arbeiter“ von der Relation „Mitarbeiter“ die allgemeinen
Felder „Name“ und „Vorname“. Im Speziellen wird bei einem Angestellten ein „Gehalt“ definiert; ein
Arbeiter erhält einen „Stundenlohn“. Die Beziehungen zur „Basisrelation“ werden in den „abgeleiteten
Relationen“ über den Fremdschlüssel „Nr“ definiert, wie es das Konzept der relationalen Datenbanken
vorsieht. Bei 1:1-Beziehungen ist der Fremdschlüssel zugleich auch der Primärschlüssel der Relation.
So erfolgt die Abbildung der Attribute in Relationen im Sinne der Objektorientierung reibungslos,
jedoch muss nun noch möglich sein, dass der Datenzugriff diese Vererbung unterstützt. Das bedeutet,
dass der Zugriff beispielsweise auf „Angestellter“ so erfolgen kann, als beinhalte diese Relation außer
den Attributen „Nr“ und „Gehalt“ auch noch „Name“ und „Vorname“. Ein „select * from Angestellter“ soll
demnach alle vier Felder listen. Das würde er derzeit mit SQL nicht machen. Möchte man mit
vorhandenen Mitteln das vorgegebene Ziel erreichen, wäre dieser SELECT-Befehl nötig:
SELECT mitarbeiter.nr, name, vorname, gehalt
FROM mitarbeiter INNER JOIN angestellter ON mitarbeiter.nr = angestellter.nr;
Hierbei kann von einer wirklichen Unterstützung der Objektorientierung durch SQL nicht die Rede
sein. Ein Vorschlag meinerseits für Abhilfe ist, eine besondere Art von Fremdschlüssel-Beziehung zu
erlauben, die eine Vererbung markiert. Benannt könnte diese Beziehung IS-A-Beziehung werden –
nachdem Bjarne Stroustrup, Erfinder von C++, zwischen Objekten eine „IS-A“- und eine „HAS-A“Beziehung erkannte. Die Ausweisung als Vererbung soll zur Folge haben, das SQL die abgeleitete
Relation so behandelt, als seien die Felder der Basisrelation, bis auf dessen Primärschlüssel, direkt
dort definiert. Angepasst müssten dementsprechend sämtliche DML-Befehle werden. Nun ist geklärt,
wie die Vererbung von Attributen zu verstehen ist, aber nicht die von Methoden. Dazu gibt es auch
nicht viel zu sagen, wenn man bedenkt, dass alle existierenden Methoden „insert“, „update“, „delete“
und „select“ sind, diese generisch sind, also ohnehin für alle Relationen gelten. Relationenbezogene
Methoden wurden bereits weiter oben ausgeschlossen und müssen deshalb hier nicht diskutiert
werden.
Als letztes gilt es sodann den Polymorphismus unter den Hut der relationalen Datenbanken zu
bringen. Der Begriff „Polymorphismus“ kommt aus dem griechischen und bedeutet wörtlich übersetzt
„Vielgestaltigkeit“. Das bedeutet in der OOP, dass ein Objekt eines bestimmten Typs auch unter der
Deklaration eines verwandten Typs verarbeitet werden kann. Anhand des obigen MitarbeiterBeispiels, bedeutet das, dass Objekte bzw. Tupel vom Typ „Angestellter“ auch als „Mitarbeiter“
verarbeitet werden können, z.B. eine Mitarbeiterliste erstellt werden kann, obwohl die Objekte
eigentlich „Angestellte“ oder „Arbeiter“ sind. Also „select * from mitarbeiter“ muss z.B. akzeptiert
werden, was selbstverständlich wegen unserer generischen DML-Methoden der Fall ist.
Polymorphismus wird demnach implizit unterstützt, wenn die Vererbung möglich ist. Viel schwieriger
wäre es hierbei SQL so zu manipulieren, dass der Polymorphismus nicht unterstützt wird.
Alles in Allem gestaltet es sich nicht besonders schwierig, um SQL auf Objektorientierung zu trimmen.
Lediglich für die Vererbung muss ein besonderer Beziehungstyp bei 1:1-Beziehungen definierbar sein.
Die weiteren Konzepte der Objektorientierung widersprechen denen der Relationalen Datenbanken
ohnehin nicht und müssen nur richtig verknüpft werden.
Meiner Ansicht nach reicht diese SQL-spezifische Erweiterung für die Unterstützung der
Objektorientierung aus. Natürlich kann man auch darüber nachdenken, in einzelnen Attributen von
Relationen komplexe Objekte statt der einfachen Datentypen zuzulassen. Dies zieht aber meiner
Meinung nach nur eine umfangreiche Verkomplizierung von SQL nach sich und macht so das genial
einfache Konzept Relationaler Datenbanken unnötig schwer verwendbar. Zudem bringt dies kaum
Vorteile. Ein schlichter Aufsatz in Richtung Objektorientierung genügt völlig.
Christian Silberbauer