Objektorientierung wird für Datenbanken immer bedeutsamer. CAD/CAM-Anwendungen und Datenmodellierung im kommerziellen Bereich belegen dies eindrucksvoll. Relationale Datenbanksysteme tun sich in dieser Hinsicht allerdings schwer.
Objektorientierung kann unter den Aspekten "Structure" (passiv) und "Behaviour" (aktiv) gesehen werden. Beim Gedanken an ein Datenbankschema steht der "Structure" Aspekt im Vordergrund. Innerhalb des "Structure"-Aspekts sollen hier zwei Fragen herausgegriffen werden:
1. Wie lassen sich in relationalen Datenbanken komplexe Objekte (Abstraktionsprinzip Generalisierung / Zerlegung) behandeln?
2. Wie lassen sich in relationalen Datenbanken Typhierarchien (Abstraktionsprinzip Generalisierung/Spezialisierung) behandeln?
Die Hoffnungen auf eine elegante Behandlung müssen jedoch in beiden Fallen gedämpft werden.
Denken wir einmal nicht an komplexe physische Objekte wie Pkws, die aus Motor, Karosserie und so weiter bestehen, sondern an Datenobjekte wie Kunden, die unter anderem aus Kundennummer und Adresse bestehen. Auf der Typebene (class) entspricht in der relationalen Datenbank dem Ganzen eine Tabelle. Die unmittelbaren Bestandteile sind die Spalten der Tabelle. Auf der Individuenebene (instance) entspricht dem Ganzen ein Tupel, und die unmittelbaren Bestandteile sind atomare Werte.
Dem Beispiel folgend bildet man also eine Tabelle namens Kunde mit Spalten namens Kundennummer, Adresse und so weiter. Nun hat eine Adresse wiederum unmittelbare Bestandteile, etwa Postleitzahl, Ort und Straße. Die Konsequenz müßte sein, als Spalten selbst wieder Tabellen zuzulassen. Dies gestatten aber nur NF2-Datenbanksysteme, welche kaum kommerziell verfügbar sind.
Meist wird man das Problem in der Weise lösen, daß auf den Begriff Adresse, da Bestandteil auf einer mittleren Ebene, im Datenbankschema verzichtet wird. Der Begriff Adresse ist auch nicht als Name einer View sinnvoll einsetzbar, sondern höchstens als eigene Basistabelle, und letztere Alternative wird man unter anderem der Performance zu opfern haben.
Vielleicht ist es ganz gut, daß man bereits bei solch einfachen "Structure"-Konstellationen in Schwierigkeiten gerät, denn damit treten Probleme des "Behaviour"-Aspekts in den Hintergrund. Das wären zum Beispiel Modalitäten der Existenz von Bestandteilen als eigene Objekte, Umkehrbarkeit der Ganzes-Bestandteil-Verknüpfung, "Umgestalten" von Objekten nach Regeln, durch wen sich welche Bestandteile eines Objekts wann umgestalten lassen.
Die Diskussion um die geeignetste Formalisierung solcher Regeln, darunter sogenannte Lange Transaktionen, ist interessant. Doch je genauer man zu formalisieren sucht, desto mehr nähert man sich politischen Kommunikationsprotokollen an. Als Steigerungsform wäre etwa eine Formalisierung von Verhandlungsregeln Ó la Wiener Kongreß denkbar, mit Ländern als Designobjekte.
Bei der Datenmodellierung im kommerziellen Bereich spielen Typhierarchien eine wesentliche Rolle. So bilden die Begriffe Interessent Kunde, Neukunde eine Typhierarchie: Kunde ist eine Spezialisierung von Interessent; Neukunde ist eine Spezialisierung von Kunde. Die Attribute des in der Hierarchie höher stehenden Typs, das heißt des allgemeineren Begriffs, vererben sich auf tieferstehende Typen, auf speziellere Begriffe.
Relationale Datenbanken tun sich hier schwer. Man kann nicht behaupten, das Abstraktionsprinzip Generalisierung/Spezialisierung würde überhaupt nicht unterstützt, denn es gibt ja Datentypen mit Kompatibilitätsregeln, zum Beispiel "integer" als Spezialbegriff von "decimal". Jedoch auf der Ebene der selbstdefinierbaren Begriffe hapert es mit der Vererbung von Attributen.
Wie sollen die Begriffe "Interessent" und "Kunde" am besten in Tabellen und/oder Views abgebildet werden? Verlockend wäre es aus Sicht der Attributvererbung, "Interessent" als Basistabelle zu haben, mit "Kunde" als View über "Interessent" und einer weiteren Basistabelle, die nur die kundenspezifischen Attribute als Spalten enthält plus Übernahme des Primärschlüssels der "Interessent " -Tabelle .
Ein solcher View müßte natürlich update-fähig sein, obwohl Join-View es theoretisch auch wäre. Jedoch bieten kommerzielle relationale DBMS die update-Fähigkeit von Join-Views bisher grundsätzlich nicht an. Es verbleiben zwei Alternativen:
1. "Interessent" und "Kunde" jeweils als eigene Basistabelle, kein View: Für die Objektidentität - ein Kunde x ist stets zugleich ein Interessent x - haben somit die Anwendungsprogramme Sorge zu tragen.
2. Nur eine Basistabelle: Dabei werden die kundenspezifischen Attribute zu optionalen, das heißt NULLablen Spalten. Die Aussage, daß alle diese Spalten aus dem gleichen Grund NULLable sind, geht verloren. Um beide Begriffe "Interessent" und "Kunde" im Schema zu behalten, müßte man die Basistabelle "Kunde" nennen und darüber einen View "Interessent" bilden. In verfügbaren DBMS haben update-fähige Views nämlich oft weniger Spalten (Attribute) als eine Basistabelle, jedoch niemals mehr.
Es ist interessant zu beobachten, wie Case-Tools mit dem Problem umgehen, wenn sie das Daten-Design umfassen. Manche von ihnen subsummieren Typhierarchien unter die gewöhnlichen Beziehungen zwischen Entitytypen. Diejenigen Tools, die differenzieren, verhalten sich beim Designvorschlag für ein konkretes relationales Schema unterschiedlich. Einige optieren für die oben beschriebene erste Alternative, andere für die zweite. Dabei bleiben die Konstellationen stets auf rein baumförmige Typhierarchien beschränkt, die "Multiple-Inheritance" Frage stellt sich gar nicht.
Auch in der kommerziellen Datenwelt spielen komplexe Objekte und Typhierarchien eine wesentliche Rolle. Beim Übergang vom Datenmodell zu einem relationalen Schema sieht sich der Designer mit der nichttrivialen Aufgabe einer bestmöglichen Abbildung konfrontiert. Dies gehört zum Preis, der für die vielfältigen Vorzüge von auf dem relationalen Modell basierenden DBMS zu entrichten ist.
*Peter Walleitner ist selbständiger Unternehmensberater in Greiling.