Konkurrenz für relationale Systeme

Objekttechniken sind für die Verteilung wie geschaffen

22.05.1992

Mit der bloßen Anschaffung eines verteilten Datenbanksystems ist nur wenig gewonnen. Perspektiven bieten sie erst dann, wenn sie im Rahmen eines unternehmensweiten Konzepts "Verteilte DV" eingesetzt werden. Ulrich Franke* empfiehlt, sich neben den relationalen Produkten auch objektorientierte Datenbanksysteme anzuschauen.

Die aktuelle Situation verteilter Datenbanksysteme ist vor allem dadurch gekennzeichnet, daß verteilte Anwendungen, die auf verteilten Datenbanksystemen aufsetzen, extrem selten sind. Ein Grund dafür ist, daß Datenbanken meist den zentralen DV-Abteilungen zugeordnet werden. Dezentrale Verarbeitung und Datenhaltung ist hier aufgrund der etablierten Infrastruktur der Systeme und Anwendungen noch eher selten.

Außerdem führt die Komplexität verteilter Datenbanksysteme zu Problemen beim Design und der Datenbank-Administration. Hier bringen vor allem die Anforderungen an das System und Netzwerkmanagement zusätzliche Komplexität.

Auch die Heterogenität der Plattformen, Betriebssysteme und nicht zuletzt der Datenbanksysteme ist, wenn überhaupt, nur mit hohem Aufwand zu überbrücken. Selbst die Datenbank-Abfragesprache SQL - sicher von zentraler Bedeutung für die Interoperabilität - löst diese Probleme nicht.

Verteilte Anwendungen setzen in ihrer Konsequenz unternehmensweite Datenmodelle voraus. Im Umfeld der traditionellen Datenbanken fehlen aber leistungsfähige Tools für die unternehmensweite Datenmodellierung, die auch die beschriebene Heterogenität kompensieren und Homogenität für Design und Implementation sicherstellen.

Trotz dieser Probleme wird der Trend zur verteilten DV in Netzwerken mit heterogenen intelligenten Knoten und Servern immer stärker. Bestimmende Faktoren sind:

- mehr Produktivität für komplexere Tätigkeiten,

- grafische Oberflächen und Multimedia sowie

- Downsizing.

Parallel zu diesen technischen Innovationen und ihren Auswirkungen auf die DV-Landschaft entwickeln sich neue Paradigmen, die die beschriebenen Probleme der verteilten Datenbanksysteme und hier insbesondere die Heterogenität und Datenmodellierung lösen können.

Verteilung ohne unternehmensweit gültige Datenmodelle bleibt eine Sackgasse. Hier könnten die Objekttechniken die Basis für globale Datenmodelle bilden. Der Grund: Die auf dieser Technik aufsetzenden Modelle können komplexe strukturierte Gegenstände oder Verfahren unserer Alltagswirklichkeit direkt abbilden.

Diese Fähigkeit geht weit über die Modellierungsmöglichkeiten der existierenden relationalen Datenbanksysteme und ihrer Tools hinaus. Globale objektorientierte Modelle helfen, redundante Inselprojekte zu vermeiden, da dezentrale Anwendungen und ihre Daten bereits Teil globaler Modelle sein können.

Darüber hinaus ist die Objekttechnik mit einer Reihe von Eigenschaften ausgestattet, die auch der Anwendungsentwicklung für verteilte Datenbanksysteme zugutekommen könnte

- Die direkte Abbildung der alltäglichen Anforderungen mit Objekten erhöht zum Beispiel die Effizienz der Anforderungsanalyse und unterstützt das Software-Design.

- Komplexe, aber auch einfach strukturierte Daten können erfaßt, Compound-Objekte als Ganzes manipuliert werden, somit auch ihre Teilobjekte. Compound-Objekte und ihre Organisation in Klassen, die ebenfalls wieder hierarchisch organisiert sein können, bieten umfassende Möglichkeit der Strukturierung.

- Objekt- und Klassenhierarchien zusammen mit Vererbung ermöglichen schnelles Prototyping. Bereits auf dieser Designebene entsteht eine gut kommunizierbare Dokumentation der Modelle. Team-orientiertes Lösen von Teilaufgaben wird optimal unterstützt.

- Einkapselung und Code-Wiederverwendung führen zu besser pflegbaren Anwendungs-Systemen. Dieses Verfahren isoliert Änderungen weitgehend, so daß die Risiken durch Anpassung und Änderung besser kontrolliert werden können. Erleichterte Änderbarkeit und Flexibilität hilft der Unternehmens-DV, dem immer härter werdenden Wettbewerb besser gerecht zu werden.

- Objekte, die in Compound-Objekten und Klassen organisiert sind, lassen sich leicht in dezentrale, verteilte Systeme einbringen.

Globale objektorientierte Datenmodelle haben zur Folge daß heterogene, verteilte Datenbanksysteme - hierarchische, relationale und auch objektorientierte - aus der Sicht verteilter Anwendungen mehr und mehr wie ein homogenes verteiltes Objekt-Datenbanksystem aussehen. Unternehmensweite Datenmodelle, abgebildet in verteilten Objekt-Datenbanksystemen, sind somit eine logische Konsequenz. In der Praxis ist selbstverständlich eine ganze Reihe von Anforderungen zu erfüllen, um Objekt-Datenbanken als Plattform für Homogenisierung und Verteilung einzusetzen.

Es existieren eine Reihe von Eigenschaften, die Objekt-Datenbanksysteme (ODBMS) besonders für verteilte Datenhaltung empfehlen; Stand der Entwicklung, zumindestens bei den neueren ODBMS, ist die direkte Nutzung von Multi-Client-Server-Umgebungen.

Die Eignung für das Client-Server-Konzept

Unterschiede zwischen den verschiedenen Produkten bestehen in der Handhabung und Architektur. Einige Objekt-Datenbanksysteme legen bereits in ihrer Architektur fest, daß eine einzelne Maschine, die sowohl den Client als auch den Server trägt, nur als Sonderfall der Umgebung zu sehen ist. Das heißt, die Verteilung ist durch entsprechende Mechanismen für die Ebene der Modellierung transparent und kann im laufenden Betrieb geändert werden.

Aus Sicht einer verteilten Anwendung muß der Speicherort eines Objektes global bekannt und kontrollierbar sein. Deshalb werden Objekte mit einem eindeutigen Identifier versehen.

Der Zugriff auf Identifier kann ähnlich effizient erfolgen wie bei auf Pointern aufsetzenden Verfahren. Der wesentliche Vorteil ist, daß Identifier netzwerkweit und ohne Abhängigkeiten von Plattformen und Betriebssystemen funktionieren. Die so definierte eindeutige Objekt-Identität ermöglicht ein Arbeiten ohne content-abhängige Keys. Verteilte Anwendungen können so wesentlich einfacher und flexibler strukturiert werden.

Die zentrale Rolle der Speichermethoden

Die Speicherverfahren in einer verteilten Umgebung sind ein sehr wichtiger Bereich. Auch hier bieten Objekt-Identifier klare Vorteile, da Compund-Objekte nur den Identifier ihrer Teilobjekte kennen müssen. Redundante Speicherung wird so ausgeschlossen.

Strukturänderungen an der verteilten Anwendung oder der Systemlandschaft zu einem späteren Zeitpunkt sind somit ohne aufwendige Redesigns nachvollziehbar. Aus Sicht der Anwendung kann jederzeit die optimale Verteilung, auch über Server-Grenzen hinweg, gewählt werden.

Die Zugriffsverfahren sind bedingt durch die Objekt-Charakteristika, ähnlich effizient wie die Speicherverfahren. Die durch Objekte beschriebenen Informationen und Methoden zu ihrer Verarbeitung steuern den Zugriff selbst. Redundante Zugriffe, die bei komplexen Verknüpfungen oft zu ernsten Problemen beim Einsatz relationaler Systeme führen, werden weitgehend vermieden.

Die angesprochenen Speicher- und Zugriffsverfahren sind Schlüssel für die erstaunliche Performance der Objekt-Datenbanken. Jedoch sind außer dem Benchmark anwendungsspezifische Kriterien zu berücksichtigen. Trotzdem ist die Performance ein Schlüsselfaktor für die sinnvolle Implementation komplexer und verteilter Modelle.

Aus den beschriebenen Kriterien läßt sich ableiten, daß ein wesentliches Architekturmerkmal für Objekt-Datenbanksysteme die Anwendungen aller Speicher- und Zugriffsverfahren auf Objektebene ist. Selbstverständlich können und werden intern Caching- oder andere performance-steigernde Verfahren angewendet, aber aus Sicht der Anwendung und der Administration sollten diese Verfahren transparent sein.

Weitere generelle Eigenschaften der Objekt-Datenbanksysteme entsprechen bereits heute den langfristigen Planungen der Unternehmen. Dazu gehören Plattform-Unabhängigkeit, Offenheit für Tools anderer Anbieter und Fortschritte bei der Standardisierung im Rahmen der Object Management Group.

In diesem Zusammenhang ist auch die Diskussion um ein objektorientiertes SQL von Bedeutung. Damit können existierende Daten aus anderen Datenbanksystemen in neuen objektorientierten Anwendungen genutzt werden. Das heißt, Investitonsschutz und Migration sind möglich.

Relationenmodell versus Objekte

Die Arbeitsweise von objektorientierten Datenbanken unterscheidet sich wesentlich von dem der relationalen Systeme. Die dort herbeigeführte Trennung von Daten und Datenbeschreibung ist aufgehoben. Einige der grundlegenden Unterschiede seien hier gegenübergestellt.

Das relationale Modell: Tabellen, Felder, Tuples, starre unflexible Datenhaltung, Joins, redundante Speicherung.

Objekt-Datenbanken: Klassen, Objekte, Attribute, Beziehungen, Komplexität der Umwelt abbildbar, direkter Zugriff durch Objektbeziehungen keine redundante Speicherung nötig.