Objektorientierter Datenbankentwurf

Der klassische Datenbankentwurf modelliert Objekte und ihre Attribute, klassifiziert diese in Entity-Typen und stellt die entworfenen Entity-Typen miteinander in verschiedene Beziehungen. Dabei wurden Normalisierungsverfahren zur Redundanzvermeidung analog dem Relationenmodell ausgenutzt. Die ER-Modelle unterscheiden sich in der Anzahl der unterstützten Konzepte (etwa Typkonstruktoren, Is-a-Beziehungen,...). Sie werden beim klassische Software-Entwurf zum Entwurf der Datenstrukturen eingesetzt, Verfahren wie Strukturierte Analyse dagegen zum Entwurf der Funktionen. Die Integration der datenorientierten und funktionsorientierten Sicht ist hier nur eingeschränkt möglich.

Datenbankentwurf und Software-Entwurf werden durch die objektorientierte Modellierung miteinander integriert. Man identifiziert Objekte, die ihre Attribute und Methoden, klassifiziert sie in Klassen und ordnet die Klassen in mehreren Hierarchien an:

1. in der Klassenhierarchie ist eine Klasse Ku Unterklasse einer anderen Klasse Ko, wenn die Menge der Objekte in Ku eine Teilmenge der Objektmenge von Ko ist.
2. in der Typenhierarchie ist eine Klasse Ku deren Attribute und Methoden einen Typ Tu haben, unterhalb der Klasse Ko mit Typ To, falls Tu mehr oder speziellere Komponenten hat als To.
3. In der Implementierungshierarchie ist eine Klasse Ku Unterklasse von Ko, falls Ku, die Implementierungsumgebung (also Attribute und Methoden) von Ko erbt und für eigene Attribute und Methoden verwenden kann.
4. In der Komponentenhierarchie ist eine Klasse Kk Komponente einer anderen Klasse K, wenn K ein Attribut vom Typ der Klasse KK besitzt. Im Gegensatz zu den anderen Hierarchien können diese Komponentenbeziehungen auch zyklisch werden.
5. In der Instanzenhierarchie ist eine Klasse Ki Instanz einer (Meta-)Klasse Km, wenn Ki Element der Objektmenge der Klasse km ist.

Objektorientierte Programmiersprachen unterstützen die Hierarchien 3 und 4, eventuell auch 5. Die Klassenhierarchie ist eine Spezialität der objektorientierten Datenbankmodelle (s.u.).

Außer in Hierarchien können Klassen in objektorientierten Modellen noch in Bereiche gruppiert werden. Diese Bereiche werden etwa Subsysteme, subjects oder cluster genannt.

Verfahren zur objektorientierten Modellierung eines Anwendungsbereiches kann man auftrennen in die objektorientierte Analyse (OOA, was soll modelliert werden ?) und den objektorientiert Entwurf (object-oriented design, OOD, wie soll es modelliert werden ?). Die gängigen Verfahren können wiederum in Adaptionen von bekannten daten- oder funktionsorientierten Entwurfsverfahren, eine Mischung aus beiden Verfahren (etwa oder eigenständige Verfahren für objektorientierte Modelle eingeteilt werden. In OOA und OOD müssen drei Problembereiche berücksichtigt werden:

• die Modellierung von Strukturen, etwa Klassen und ihre Anordnung in Hierarchien,
• die Modellierung von Funktionen, etwa die Methoden der einzelnen Klassen, sowie
• die Modellierung des Gesamtverhaltens des Systems.

Während etwa sich auf die Analyse von Strukturen beschränkt, werden in auch die Funktionen modelliert. Die Spezifikation des Gesamtverhaltens ist in diesem Verfahren nur unzureichend berücksichtigt.

Ein Schritt in diese Richtung sind Verfahren zur Spezifikation des dynamischen Verhaltens einer Datenbankanwendung. Diese sind teilweise noch unabhängig von objektorientierten Modellen. In werden etwa dynamische Integritätsbedingungen beschrieben, die die Spezifikation der Evolution einer Datenbank über ihre gesamte Lebensdauer hinweg liefern können. Diese Spezifikation kann in ein relationales Datenbankschema umgesetzt werden, wenn im verwendeten Datenbanksystem Trigger-Mechanismen zur Verfügung stehen, die bei Eintreten bestimmter Ereignisse und unter bestimmten Bedingungen die in der Spezifikation festgelegten Aktionen ausführen können. in wird diese Technik auf objektorientierte Datenbanken ausgeweitet, indem die Lebensläufe einzelner Objekte in temporaler Logik spezifiziert werden.

Speziell für objektorientierte Datenbankmodelle gibt es noch einige zusätzliche Eigenschaften, die in den bisher vorgestellten OOA-, OOD- oder Spezifikationsverfahren noch nicht berücksichtigt wurden. So muß der objektorientierte Datenbankentwurf

1. den Entwurf von Klassenhierarchien unterstützen, d.h. die Teilmengenbeziehung zwischen den Objektmengen zweier Klassen kontrollieren (in herkömmlichen objektorientierten Modellen gibt es keine Teilmengenbeziehung, da ein Objekt nur zu genau einer Klasse gehören darf),
2. die Objekt-Evolution ermöglichen, d.h. den kontrollierten Wechsel eines Objektes zwischen den verschiedenen Klassen einer Klassenhierarchie (Rollenwechsel des Objektes)
3. die Schema-Evolution ermöglichen, d.h. die kontrollierte Veränderung des objektorientierten Datenbankschemas unter weitgehender Beibehaltung der unter dem alten Schema gespeicherten Objekte und ihrer Informationen, und
4. durch Anfragen oder Sichten abgeleitete Klassen in den Entwurf mit einbeziehen.

Die Punkte 2 und 3 werden durch die langfristig ausgerichteten Datenbankanwendungen nötig: im Gegensatz u objektorientierten Programmiersprachen, die Objekte während eines Programmablaufs modellieren, muß durch die Forderung der Persistenz die Evolution eines Objektes beziehungsweise eines ganzen Datenbankschemas möglich sein.

Der Punkt 4 ist ein typisches Datenbank-Feature: Informationen können nicht nur in gespeicherter Form vorliegen sondern auf vielfältige Weise durch Anfragen oder Sichtdefinitionen abgeleitet werden. Diese abgeleiteten Klassen werden in herkömmlichen Entwurfstechniken noch im Schema direkt spezifiziert und "blähen" in vielen Fällen das Datenbankschema unnötig durch redundante Informationen auf.

Der objektorientierte Datenbankentwurf integriert den bisher getrennten Entwurf von Strukturen und Funktionen eines Systems. Zusätzlich kann das Gesamtverhalten des Systems etwa durch dynamische Integritätsbedingungen spezifiziert werden. Die Integration dieser drei Bereiche ist nicht immer vollständig gelungen. Weiterhin sind bisher einige datenbankspezifische Bereiche wie Objekt-Evolution und abgeleitete Klassen in den eher auf objektorientierte Programmiersprachen zugeschnittene Verfahren noch nicht ausreichend berücksichtigt.

1. Booch, G.: Object-Oriented Design - with Applications. Redwood City, CA: Benjamin/Cummings 1991
2. Coad, P., Yourdon, E.: Object-Oriented Analysis, Englewood Cliffs: Prentice-Hall 1991
3. Ferstl, O.K., Sinz, E.J.: Ein Vorgehensmodell zur Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM), Wirtschaftsinformatik 6, 477-491 (1991)
4. Heuer, A.: Objektorientierte Datenbanken - Konzepte, Modelle, Systeme. Bonn: Addison-Wesley 1992
5. Lipeck, U.W.: Dynamische Integrität von Datenbanken - Grundlagender Spezifikation und Überwachung. Informatik-Fachberichte, Band 209, Berlin: Springer 1989
6. Saake, G.: Descriptive specification of database object behaviour. Data Knowl. Eng. 6, 47-73 (1991)
7. Thalheim, B.: Konzepte des Datenbank-Entwurfs, in: G. Vossen, K.-U. Witt (Hrsg.): Entwicklungstendenzen bei Datenbank-Systemen, Kapitel 1, S. 1-48. München: Oldenbourg 1991

Dr. Andreas Heuer
Institut für Informatik,
TU Clausthal
Erzstraße 1
W-3392 Clausthal-Zellerfeld

© 1993 Informatik Spektrum, Springer-Verlag Berlin Heidelberg