Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

01.10.1993

Real existierendes DB2 ohne die dazugehoerige Theorie Relationale Systeme koennen Objektstrukturen nachbilden Von Hermann Schmitt*

Der Trend geht sicherlich in Richtung echter objektorientierter Datenbanksysteme. Um die vorhandenen relationalen Datenbanksysteme weiter nutzen zu koennen, ist es fuer eine gewisse Uebergangszeit aber sinnvoll, diese zu objektorientierten Datenbanksystemen umzufunktionieren.

Das relationale Datenbankmodell passt nicht zur objektorientierten Methode. Im Grunde ist es doch so, dass das Design-Kriterium fuer die Theorie der relationalen Datenbanken die moeglichst umfangreiche Auswertbarkeit der Daten nach allen denkbaren Gesichtspunkten war. Die starke Aufgliederung der Daten nach den Normalisierungsregeln traegt der Forderung nach umfassender Auswertbarkeit Rechnung, macht aber den Zugriff auf die Daten oft sehr ineffizient.

Ein grosser Nachteil der relationalen Systeme ist zudem, dass die Datenbank selbst nichts darueber aussagt, wie die einzelnen Teile (Tabellenzeilen) sachlich zusammengehoeren. Zwar liesse sich die Theorie der relationalen Datenbanken dahingehend erweitern, dass sie diese Zusammenhaenge einbezieht. Dies ist aber bislang kaum realisiert worden.

In gewissem Sinn eine Rueckkehr zur Netzdatenbank

Ausserdem scheint bei der Entwicklung der Relationen-Theorie auch die Absicht eine Rolle gespielt zu haben, die Datenbank so aufzubauen, dass die Abfragesprache einfach zu designen und zu programmieren ist. Dieser Gesichtspunkt ist fuer die Datenbankanbieter sicherlich relevant.

Fuer die objektorientierten Datenbanken steht der Objektbegriff im Vordergrund. Das Objekt muss die logische Einheit der Speicherung sein, weitere Untergliederungen sind unter dem Gesichtspunkt der Objektorientierung nicht geboten.

Zusammenhaenge zwischen Objekten werden durch Objektidentifikationen spezifiziert. Hiermit kehren wir in gewissem Sinne wieder zu den Netzwerk-Datenbanken zurueck. Ein wesentlicher Unterschied ist aber der, dass die Pointer in den objektorientierten Datenbanken Datenfelder im Objekt sind, waehrend sie bei den Netzwerk-Datenbanken nicht vom Anwender direkt ansprechbar und veraenderbar waren. Infolgedessen liessen sich die Pointer meist nur mit grossem Aufwand aendern; ausserdem waren sie starken Einschraenkungen unterworfen.

Datenkapselung kollidiert mit der Auswertbarkeit

In vielen der alten DB-Systemen mussten die Pointer eine einfache Hierarchie darstellen, weshalb die Datenbanken nur nach einem einzigen Gesichtspunkt untergliedert waren. Deshalb wurden diese Systeme auch hierarchisch genannt.

Die objektorientierte Methode sagt nun nichts aus ueber die Auswertbarkeit der Daten nach unterschiedlichen Gesichtspunkten - ja, es besteht hier sogar ein gewisser Widerspruch: Beim objektorientierten System sollen die Daten nur mittels Methoden angesprochen werden, waehrend eine allumfassende Auswertungsmoeglichkeit den direkten Zugriff auf alle Daten erfordert. Moeglicherweise stehen naemlich gar nicht fuer alle Auswertungs-Gesichtspunkte geeignete Methoden zur Verfuegung.

An dieser Stelle ist es wohl angebracht, einmal zu fragen, inwieweit die allgemeine Auswertungsmoeglichkeit der Daten in den einzelnen Anwendungssystemen von Bedeutung ist. Im Grossen und Ganzen handelt es sich bei dieser allgemeinen Auswertungsmoeglichkeit sicherlich um einen wesentlichen Gesichtspunkt, dem Rechnung getragen werden muss, auch wenn er nicht unbedingt zur objektorientierten Methode passt.

Die Loesung kann aber auch nicht darin bestehen, die Datenbank nur mit dem Ziel zu entwerfen, dass sie eine allgemeine Auswertbarkeit und den Zugriff mit einer einfachen Abfragesprache erlaubt. Vielmehr muss die Auswertungssprache auf komplexere Datenaggregate anwendbar sein - auch um den Preis, dass auf gewisse Auswertungsmoeglichkeiten verzichtet wird.

Als Alternative bleibt ja auch noch die Moeglichkeit, dass unterschiedliche Datenbanktypen fuer unterschiedliche Zwecke verwendet werden. Es ist heutzutage gang und gaebe, relationale Datenbanken lediglich fuer Abfragen zu benutzen - von Daten, die aus IMS-Datenbanken sowie aus einfachen Filesystemen periodisch oder auch nur bei Bedarf in das relationale System eingebracht werden.

Ein Pluspunkt ist der hohe Entwicklungsstand

In einer Hinsicht koennen die relationalen Datenbank-Management- Systeme allerdings eine wichtige Rolle spielen: Sie haben wohl den hoechsten allgemeinen Entwicklungsstand und sind weit verbreitet, wenn sie auch in Wirklichkeit oft nur in sehr beschraenktem Masse genutzt werden.

Diese Systeme weisen eine hohe Zuverlaessigkeit auf, was bei den objektorientierten Produkten wohl noch nicht als sicher angenommen werden kann. Sie eignen sich nicht nur hervorragend fuer konkurrierende Zugriffe, sondern bieten auch Schutz vor unberechtigtem Eindringen und Datenverlusten. Aus diesen Gruenden bietet es sicher eine Reihe von Vorteilen, wenn es gelingt, die relationalen Datenbanksysteme zu objektorientierten Datenbanken umzufunktionieren.

Ausserdem muss in diesem Fall kein neues Datenbanksystem angeschafft werden; bekanntlich stellen solche Systeme eine relativ teure Investition dar. Weitere Kosten, die sich auf diesem Weg einsparen lassen, wuerden fuer die Ausbildung an einem weiteren DBMS und fuer die Verwaltung zweier parallel betriebener Systeme - beispielsweise fuer die Benutzerverwaltung und die Sicherung der Daten - anfallen.

Um dieses Konzept in die Praxis umzusetzen, muss jedoch klar unterschieden werden zwischen der Theorie der relationalen Datenbanken und den real existierenden relationalen Datenbanksystemen: Die relationalen Systeme sollen - soweit dies moeglich ist - als Mittel zur Speicherung objektorientierter Datenbanken genutzt werden. Das laesst sich aber nur bewerkstelligen, wenn die Theorie der relationalen Datenbanksysteme hinfaellig wird.

Besonders interessant fuer die Mainframe-Anwender

Interessant ist diese Vorgehensweise vor allem fuer die Anwender von IBM-Grossrechnern. Auf dieser Hardware ist Datenbanksoftware naemlich besonders teuer, und objektorientierte Datenbanken stehen noch kaum zur Verfuegung.

Als relationales DBMS kommt dabei typischerweise das IBM-Produkt DB2 zum Einsatz, das unter dem Betriebssystem MVS laeuft. Die einfachste Form, DB2 fuer die Speicherung von Objekten zu nutzen, ist die, jeder Klasse eine Tabelle zuzuordnen, und die Daten jedes Objekts der Klasse in einer Zeile dieser Tabelle zu speichern.

Ein Objekt kann aber auch mehrere Tabellenzeilen in einer Tabelle belegen, beziehungsweise zu einer Klasse koennen auch mehrere Tabellen gehoeren. Wichtig ist, dass alle Tabellenzeilen eines Objekts die Objektidentifikation enthalten. Ausserdem sollte eine Tabelle nur Daten enthalten, die zur selben Klasse gehoeren. Andernfalls ist keine Enkapsulation gegeben. Beziehungen zwischen den Objekten werden so dargestellt, dass Objektidentifikationen innerhalb der Daten eines Objekts auf die Objekte mit diesen Identifikationen verweisen.

Die Moeglichkeiten der Attributdefinition sind bei DB2-Tabellen - im Vergleich beispielsweise zu Cobol-Programmen - eher beschraenkt. So gibt es zum Beispiel keine Array-Definition. Der Grund liegt darin, dass solche Konstrukte in der Theorie der relationalen Datenbanken nicht vorgesehen sind.

In den meisten Faellen werden die erlaubten Definitionsmoeglichkeiten aber ausreichen. Wer ueber diese Moeglichkeiten hinausgehen will, kann auf zwei Arten vorgehen, welche hier anhand des Array-Beispiels erlaeutert werden sollen: Die erste Moeglichkeit ist, ein Array durch mehrmalige Definition der gleichen Variable - zum Beispiel Mon1, Mon2 ... Mon12 - in der Tabellenzeile aufzubauen. Bei den Programmen, die diese Attribute benutzen, koennte dann wieder ein Array definiert werden.

Umstellung auf ein RDBMS wird abgebremst

Die zweite Moeglichkeit besteht darin, gemaess den Regeln der relationalen Datenbanken eine zweite Tabelle zu definieren, in der dann jede Tabellenzeile im Wesentlichen einen einzigen Array-Wert enthaelt. Beide Tabellen muessten die Objektidentifikation als Schluessel enthalten. Vom objektorientierten Ansatz betrachtet wuerden beide Tabellen zur selben Klasse gehoeren.

Weiter ist es ein Erfordernis der Praxis, dass auch die nach der objektorientierten Methode neu entwickelten Programme auf die gemaess der Relationen-Theorie strukturierten sowie die in einfachen Filesystemen gespeicherten Daten zugreifen koennen. Hierbei wird oft uebersehen, dass immer noch viel weniger Daten in relationalen Datenbanken als in IMS-Datenbanken oder einfachen Filesystemen abgelegt sind. Die Hinwendung zur objektorientierten Methode wird dazu fuehren, dass die Umstellung auf relationale Datenbanksysteme abgebremst und nicht mehr als Endziel angesehen wird.

Es ist sicher nicht zu empfehlen, alle entsprechend der relationalen Theorie gespeicherten Daten sozusagen in einer Grossaktion auf objektorientierte Datenbanken umzusetzen. Dieser Aufwand waere naemlich sehr hoch, weil alle Programme, die die Daten ansprechen, geaendert werden muessten.

Ausserdem ist damit zu rechnen, dass sich bei einer solchen Umstellung Fehler einschleichen. Und auf der anderen Seite entstuende daraus kaum ein sichtbarer Vorteil - zumindest nicht fuer das Management ausserhalb der Datenverarbeitung.

Im allgemeinen ein langwieriger Prozess

Davon abgesehen schliesst die hier beschriebene Vorgehensweise keineswegs die Moeglichkeit aus, allmaehlich die Speicherung der Daten in objektorientierten Datenbanken zu erreichen. Dazu sollten auch die unter dem Gesichtspunkt der relationalen Theorie gespeicherten Daten konzeptionell in Klassen und Objekte gegliedert werden - aber ohne die physische Speicherung zu aendern.

In neuen Programmen lassen sich diese Daten dann in der Form von Klassen und Objekten ansprechen. Spezielle Methoden dieser Objekte muessen den Zugriff auf ein Objekt eventuell in Zugriffe auf Teile mehrerer Datenbank-Tabellen umsetzen. Es ist zu erwarten, dass mit der Zeit immer mehr Programme in objektorientierter Form vorliegen werden und die Programme der alten Form langsam aussterben. Dann kann man die Daten als Objekte speichern. Dies ist aber im allgemeinen ein langwieriger Prozess.

*Hermann Schmitt ist Leiter IS-Planung beim Landschaftsverband Rheinland in Koeln.