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.

13.12.1991 - 

Objektorientierte DB-Systeme: Fakten und Trends

Kürzere Entwicklungszeiten und besseres Laufzeitverhalten

Daß konventionelle Methoden immer weiter verbessert werden, ist normal; allein, diese Optimierungen können häufig nur graduelle Verbesserungen bringen. Den Ausweg aus der Softwarekrise, also den ersehnten Qualitätssprung, stimulieren sie nicht. Hier versprechen Objekttechnologien auch im Datenbanksektor einen realitätsnahen und intuitiven Ansatz, der bisherigen Technologien überlegen ist und der die DV-Welt entscheidend verändern kann.

Über die Krise der heutigen Software-Entwicklung wurde bereits viel geredet und geschrieben, wenig dagegen über ihre tatsächlichen Ursachen. Einer der wichtigsten Gründe für diese Krise kommt aus der DV-Technik selbst: Es ist der immens wachsende Bedarf an Informationsverarbeitung und neuen Softwarelösungen. Dazu kommt die steigende Komplexität der Entwicklungen, bedingt durch die Verbreitung von grafischen Benutzeroberflächen, komplexen Multiuser-, Multitasking- und Netzwerk-Betriebssystemen - nicht zu vergessen die durch diese Komplexität exponential steigenden Investitionen. Heutzutage sind Megaprojekte mit 20 und mehr Software-Entwicklern und mehreren Hunderttausend, wenn nicht gar Millionen "Lines of code" keine Seltenheit mehr.

Neue Werkzeuge für neue Anforderungen

Grafische Benutzerschnittstellen, Multiuser- und Multitasking-Systeme, lokale und weite Netzwerke stellen neue Anforderungen, die mit alten Programmierwerkzeugen nicht zu lösen sind. Software-Entwickler und damit die gesamte Software-Industrie sind deshalb gezwungen, umzudenken und neue Lösungsansätze zu suchen. Einer dieser Ansätze heißt Objekttechnologie. In den USA und in Japan sieht man bereits die Vorteile der Objektorientierung in der Software-Entwicklung. Besonders in Japan - der Industrienation, die vor allen Dingen die Fertigung perfektioniert hat - wurde klar erkannt, daß durch Objektorientierung wiederverwendbare Teile, ähnlich einem Mikrochip in der Elektronik, zu produzieren sind. Das gilt auch für objektorientierte Datenbanksysteme. Sie bieten die Möglichkeit, im Einklang mit objektorientierten Programmiersprachen wesentlich effizienter Daten und Objekte in interaktiven Umgebungen und Netzwerken zu verwalten.

Wie und warum Objekttechnologie diese Veränderungen bewirken kann, verdeutlicht ein Blick auf die Theorie: Bisherige Programmier- und Datenbankmodelle sind eindimensional und basieren im wesentlichen auf Informationseinheiten. Diese Einheiten bestehen im kleinsten Fall aus einem Bit oder aus einer Anzahl von Bytes, die zu einem Datensatz (Record) zusammengefaßt werden können. Natürliche Beziehungen, das heißt Relationen zwischen diesen Einheiten, werden künstlich über Nummernkreise codiert und so rechnergerecht aufbereitet.

Objektorientierte Systeme dagegen können aufgrund des Klassenmodells Vererbungsbeziehungen direkt abbilden. Objekte sind immer eindeutig - das heißt, sie besitzen enge eigene Identität - sind deshalb in der Lage, direkte Verbindungen untereinander aufzubauen. Objektorientierung durchbricht so die eindimensionale und satzorientierte Sicht auf Daten. Dieses Programmiermodell ermöglicht dem Entwickler, daß er komplexe Objekte modelliert. Es zwingt zur Aggregation von Einzelteilen, die auch in Wirklichkeit, das heißt in unserer realen Welt, zusammengehören. Niemand käme beispielsweise auf die Idee, sein Auto (komplexes Objekt), um es in die Garage (Datenbank) zu stellen, in Einzelteile (Spalten, Records) zu zerlegen und beim Herausholen wieder zusammenzusetzen; doch so arbeiten herkömmliche Datenbanksysteme.

Im Gegensatz zu allen anderen Datenbankmodellen - den hierarchischen Netzwerken oder relationalen Datenbanken - haben sich objektorientierte Datenbanksysteme (OODBS) aus den Programmiersprachen heraus entwickelt. OODBS sind deshalb eine Kombination aus Altem und Neuem. Sie sind ein Hybrid aus einem persistenten, das bedeutet dauerhaften Speicher für Objekte und einem objektorientierten Progammiersystem beziehungsweise einer objektorientierten Programmiersprache. Hinzu kommen die Eigenschaften eines konventionellen Datenbanksystems wie Nebenläufigkeit, Transaktionen, Verwaltung großer Datenmengen und gezielter Abfragemöglichkeiten.

Systeme, die diese Anforderungen erfüllen, werden als rein objektorientierte Datenbanksysteme bezeichnet. Sie ergänzen die Funktionalität einer Programmiersprache mit der Funktionalität eines vollwertigen Datenbanksystems. Ausführlich dargelegt wurde dieser Ansatz Ende 1989 von einer Reihe von Datenbankwissenschaftlern (Dittrich et al.) im "OODBS-Manifesto".

Anbieter bisheriger konventioneller Datenbanktechnologie verfolgen dagegen einen anderen Ansatz, der in der Ergänzung des bisherigen Datenmodells um Objekte besteht. Hier muß man jedoch klar unterscheiden zwischen der Verwaltung von sogenannten Blobs (binary large objects) und Ansätzen wie Postgres (der universitären Weiterentwicklung von (..)gres) oder dem Aims-Projekt (Advanced Information Management System) des IBM-Forschungszentrums in Heidelberg. Die beiden letzten Projekte arbeiten an einer Erweiterung der relationalen Datenbanksprache SQL, sowohl in der Datendefinition als auch in der Manipulation und Abfrage. Blobs dagegen übernehmen keinerlei Semantik in das Datenmodell und stellen somit eigentlich keine Objektorientierung dar.

Schließlich gibt es noch den Ansatz, die Programmierung konventioneller Datenbanksysteme objektorientiert vorzunehmen. Dies ist natürlich grundsätzlich möglich, basiert jedoch einzig und allein auf der Programmentwicklung und nicht auf dem zu verwaltenden Datenmodell.

Ein virtueller Objektraum entsteht

Das Leistungspotential objektorientierter Datenbanksysteme entsteht durch die vollständige Abbildung des objektorientierten Klassenmodells in der Datenbank. Damit entsteht für den Programmentwickler ein virtueller Objektraum, der sich nicht wie bisher nur auf seinen Arbeitsspeicher beschränkt, sondern die gesamte Kapazität seines Rechners ausnutzen kann. Gegenüber dem Einsatz von konventionellen Datenbanksystemen bedeutet das für den Programmierer: Er muß beim Speichern nicht mehr mühselig Objekte in ihren Einzelteilen auf der Platte ablegen beziehungsweise beim Laden aus den Einzelteilen zusammensetzen, um sie von der Platte in seinen Hauptspeicher zu transferieren. Die gesamte Semantik und alle Relationen eines Objektes verwaltet das objektorientierte Datenbanksystem völlig selbstständig und unabhängig von seiner Komplexität.

Einsatz in einem Textilunternehmen

Ein Beispiel aus der Praxis macht dies deutlicher Betrachten wir einen Ausschnitt aus einem modernen Warenwirtschaftssystem: Ein Textilunternehmen produziert und liefert seine Produkte an eigene Einzelhandelsgeschäfte, die diese im Ladenverkauf an den Endkunden veräußern. Neben der Abbildung von Warenbewegungen und Zahlungsverkehr den konventionellen Aufgaben eines Warenwirtschaftssystems - soll die Software Informationen für die Unternehmensplanung liefern. Dies soll durch bessere Controlling-Möglichkeiten und Marketing-relevante Auswertungen erreicht werden. Außerdem sollen bei der Implementierung des Systems Standardisierungen wie die Edifact-Norm Berücksichtigung finden.

Zunächst ein Blick auf das Design der Applikation und ein Exkurs in objektorientierte Analyse und Design: Eine Methode des objektorientierten Designs unterteilt die benötigten Klassen in sogenannte Material- und Werkzeugklassen. Materialklassen tragen Informationen, die zum Beispiel in einem Datenbanksystem verwaltet werden können. Werkzeugklassen bearbeiten die Materialklassen, zum Beispiel in Form einer Anzeige oder einer Auswertung. So könnten Anzeigen unabhängig vom Modell implementiert werden und beispielsweise eigene Ansichten für GUIs, zeichenorientierte Terminals oder Hardcopies realisiert werden.

Betrachten wir nun die Materialklasse "Artikel". Diese scheinbar einfache Klasse ist der Kern für alle Auswertungen bezüglich der Warenströme und des Marketings des Unternehmens. Aufgrund des breit gefächerten Angebotes ist eine Diversifizierung des Artikelstammes dringend notwendig. So muß zwischen Textilien, Accessoires, Gepäck und Schuhen eine Unterscheidung getroffen werden. Außerdem sind Artikel zu Kombinationen, zu Outfits, sogenannten Farbthemen und Kollektionen zusammenzufassen. Die grundsätzlichen Unterschiede zwischen den Warengruppen und die Beziehungen zu Marketing-relevanten Informationseinheiten wie Outfits, Farbthemen oder Kollektionen sind einer ständigen Weiterentwicklung im Rahmen der Unternehmensentwicklung unterzogen. Des weiteren gehören zu jedem Artikel Eintragungen in den verschiedenen Lägern des Unternehmens. In den Lägern müssen Verweise auf Dispositionen, Abverkaufsquoten etc. verwaltet werden. Diese verweisen wiederum auf andere Aktivitäten wie Budgetplanungen, Order, Bestellungen etc. Schließlich soll der Datenaustausch zwischen der Zentrale des Unternehmens und den Einzelhandelsgeschäften auf der Basis der Norm Edifact realisiert werden. Edifact ist im Prinzip ein transaktionsorientiertes Protokoll, das auf der Basis von spezifizierten Segmenten standardisiert Warenströme und Geldtransfer beschreibt. Im hier beschriebenen Fall wurde festgestellt, daß der vorliegende Normentwurf nur 80 Prozent der vorhandenen Information abdeckte und spezifische Erweiterungen notwendig wurden. Diese konnten dank eines objektorientierten Entwurfes in spezialisierten Klassen der Basisnorm realisiert werden.

Aber zurück zum eigentlichen Datenbankdesign. Obwohl das beschriebene Modell nur etwa zehn Prozent des realen Entwurfes beschreibt, wird deutlich, wie komplex ein heutiges Informationssystem gestaltet werden muß, ohne die Möglichkeiten der Erweiterungen und Modifizierungen grundsätzlich auszuschließen. Die Materialklasse "Artikel" besteht aus einem Klassenbaum, der ausgehend von einem Basis-Artikel die spezifischen Arten der verschiedenen Warengruppen berücksichtigt. "Kleidung" basiert zum Beispiel auf einem einheitlichen "Modell", das durch Farben und Größen individuell modifiziert wird. "Schuhe" besitzen unterschiedliche Größen, "Accessoires" gehören zu bestimmten Kleidungsstücken, "Gepäck" ist saisonal unabhängig - im Gegensatz zu den anderen Warengruppen. Schließlich wird in einer Klasse "Kombination" die Zusammenfassung von Einzelartikeln modelliert. Um die Marketing-Informationen über inhaltliche Zusammenstellungen wie Farbthemen, Outfits und Kollektionen zu erhalten, wird ein weiterer Klassenbaum mit der Basisklasse "Artikel-Collection" entworfen.

Besonders deutlich wird die veränderte Modellierung, wenn wir in die Klasse "Kombination", schauen. In der Basisklasse "Artikel" werden allgemeingültige Attribute wie die Artikelnummer verwaltet. Außerdem besitzt die Klasse die Eigenschaft, die unterschiedlichen Preise für Einkauf, Verkauf und Herstellung zu berechnen. Da diese Berechnung zum Teil nur aufgrund von Informationen in den abgeleiteten Klassen stattfinden kann, wird die Methode zur Errechnung als virtuell gekennzeichnet. Dieser Mechanismus, der in der Objekttechnologie Polymorphie genannt wird, gehört zu den neuen mächtigen Werkzeugen der Abstraktion, die wir später benutzen werden. In der abgeleiteten Klasse "Kombination" befindet sich ein Container, der wieder um Verweise auf Artikel aufnehmen kann. Außerdem besitzt die Klasse real implementierte Methoden für die Errechnung der Preise. Der Einkaufspreis und der Verkaufspreis sollen in diesem Fall aus der Summe der Einzelpreise abzüglich zehn Prozent berechnet werden, der Verkaufspreis muß außerdem mit Hilfe einer Preisstaffel-Tabelle auf einen handelsüblichen Preis (zum Beispiel 298 Mark) korrigiert werden. Die Herstellungskosten setzen sich natürlich aus der Stimme der Einzelteile zusammen. Auch der verwendete Container basiert auf dem Mechanismus der Polymorphie. Er kann jede Art von Artikelobjekten aufnehmen (zum Beispiel Hose, Jacke, Gürtel, Schuhe) und liefert diese als vollständige Objekte der richtigen Klasse dem Anwender (in diesem Fall der Klasse "Kombination") zurück. Selbst rekursive Strukturen, wie beispielsweise eine Kombination, die wiederum aus einer Kombination besteht, stellen mit dieser Modellierung kein Problem dar, da "Kombination" ebenfalls die Basisklasse "Artikel" besitzt.

Eine Erweiterung des Gesamtmodells, etwa um eine neue Artikelart oder eine weitere Diversifizierung - aus Kleidung wird DOB (Damenoberbekleidung) und Kinderkleidung abgeleitet -, ist problemlos und ohne Änderung der bestehenden Programme und Klassen möglich.

Besteht nun dieses Klassendesign, muß es früher oder später in einem Datenbanksystem verwaltet werden. Spätestens hier wird offensichtlich, daß konventionelle Datenbanksysteme diese Aufgabe nicht zufriedenstellend lösen können. Allein ein satzorientiertes Design für das komplexe Klassenmodell zu entwerfen ist eine gigantische Aufgabe; dieses dann innerhalb des Anwenderprogrammes bei jeder Schreib- und Leseoperation nachzuvollziehen, stellt einen massiven Programmieraufwand dar, der zwangsläufig zu Fehlern führt. Aus diesem Grund das objektorientierte Design zu reduzieren, würde bedeuten, die Vorteile dieser Methode schlicht zunichte zu machen. Gefragt sind hier objektorientierte Datenbanksysteme (OODBS), denn sie lösen diese Aufgabe einfach und effizient. Sie bieten die Funktionalität eines konventionellen Datenbanksystems, verbunden mit der vollständigen Unterstützung des objektorientierten Klassenmodells. In unserem Beispiel bedeutet dies, daß ein Objekt der Klasse "Kombination", zum Beispiel bestehend aus Hose, Gürtel, Jacke und Schuhen, mit einer Schreib beziehungsweise Leseoperation bearbeitet werden kann. Es ist also nicht relevant, ob und wie oft eine Klasse spezialisiert (abgeleitet) wird und wie komplex diese Klasse intern aufgebaut ist. Außerdem besitzen OODBS neben den konventionellen Selektionen Navigationsmöglichkeiten, womit Verweise von einem Objekt, zum Beispiel der "Kombination", zu seinen Unterobjekten (Hose etc,) direkt verfolgt werden können und keine erneute Selektion anhand einer Artikelnummer erfordern.

In dieser Art arbeiten auch die angesprochenen Container für Artikel-Collections wie Outfits, Farbthemen und Kollektionen. Jedes Objekt innerhalb eines OODBS erhält eine eigene und eindeutige Identität (Object Identifier). Diese interne ID wird von dem System als De-Referenzierungs-Mechanismus zwischen Arbeitsspeicher und Sekundärspeicher verwendet und muß so nicht jedesmal von Anwenderprogramm durchgeführt werden.

Soviel zu diesem Beispiel; selbstverständlich ist das reale Design der Applikation wesentlich komplexen. Es wurde jedoch aus Gründen der Verständlichkeit hier deutlich vereinfacht, zeigt aber trotzdem die Vorteile eines OODBS: Zum einen wird die Programmentwicklung drastisch vereinfacht; die Entwicklungszeiten reduzieren sich bei komplexen Datenmodellen um bis zu 80 Prozent. Zum anderen verbessert sich Laufzeitverhalten wesentlich, da das Datenbanksystem Relationen zwischen Objekten selbstständig herstellt und diese nicht Schritt für Schritt im Anwendungsprogramm zusammengesetzt werden müssen. Hinzu kommen alle Vorteile der objektorientierten Programmierung wie Wiederverwendbarkeit, bessere Pflege und Erweiterbarkeit.

Die nächsten Jahre werden zeigen, ob auch die deutsche Software-Industrie dein Trend, zur objektechnologie und den OODBS rechtzeitig für sich entdeckt und damit Produktivität und Qualität der hiesigen Softwareproduktion wesentlich steigern kann.

Die Herausforderung, einen wirklichen Quantensprung in der Softwaretechnik zu vollziehen, steht jedenfalls im Raum.