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.

21.08.1992 - 

RELATIONALE DATENBANKEN

Kaum eingesetztz und beinahe schon veraltet

Während die Fachwelt bereits über objektorientierte Datenbankmodelle diskutiert, sind die von Edgar Codd definierten Möglichkeiten relationaler Datenbanksysteme kaum ausgereizt. Bislang ist kein einziges DBMS Produkt kommerziell verfügbar, das die Coddtschen Vorgaben vollständig erfüllen würde. Es steht also zu befürchten, daß die relationale Datenbanktechnik bereits überholt ist, bevor sie ihre spezifischen Vorteile überhaupt ausspielen kann.

Die Idee an und für sich

Arme IBM: Kaum hat sie eine stabile DB2-Ausführung auf die Beinegestellt, sind die Mitbewerber schon wieder eine Nasenlänge voraus. Vielleicht ist Big Blue aber auch nur klüger als die Konkurrenz: Während sich Oracle und Co. abmühen, die Moglichkeiten der relationalen Datenbanktechnik auszureizen, verabschiedet sich der Marktführer klammheimlich von der Idee, DB2 zur Grundlage eines unternehmensweiten Informationsmodells zu erklären. Die größte DB2-Anwendung aller Zeiten, der Repository Manager/ MVS, soll durch verteilte Datenverzeichnisse auf objektorientierter Basis ersetzt werden - wie und wann auch immer.

Bislang sind objektorientierte Datenbank-Management-Systeme zwar ein beliebtes Thema für Congresse und Serminare, aber kaum für die tägliche Anwenderpraxis: Die Großunternehmen haben ihre Daten uberwiegend in IMS, Adabas oder IDMS gespeichert - von VSAM ganz zu schweigen. Für neue Applikationen kommt hier und da schon mal DB2 zum Einsatz, und dieganz Progressiven setzen auf Oracle oder gar Sybase.

Wir haben es wieder und wieder gehört: Objektorientierung erfordert einen "Shift of Paradigm": Der Anwender nicht ehrfürchtig, denkt nach und fragt sich schließlich: Wo bleibt der Schutz meiner Investitionen, und woher nehme ich die Leute, die diesen Paradigmenwechsel nicht nur vollzogen haben, sondern auch praktisch umsetzen können?

Das Konzept einer objektorientierten Informationsverarbeitung wird sich irgendwann durchsetzen, weil es eine Antwort auf reale Anforderungen der Benutzer gibt. Aber es wird die DV-Welt stärker verändern, als der gängige Sprachgebrauch vermuten läßt Im Grunde widerspricht der Begriff des objektorientierten Datenbank-Management-Systems sich selbst, da die Obiektorientierung doch gerade die Trennung von Daten und Funktionen aufheben soll. Ein Paradigmenwechsel bedeutet eben nicht nur: RDBMS 'raus, OODBMS 'rein. Zur Disposition steht die Idee des Datenbanksystems an und für sich. qua

Zerlegt in Einzelteile

Relationale Datenbank-Management-Systeme bilden die reale Welt ab, indem sie sie zunächst einmal zerstören: Jedes Objekt wird in seine Einzelteile zerlegt und erst zur Laufzeit wiederhergestellt. Diese Art der Informatzonsspeicherung hat den Vorteil, komplizierte Abfragen auf große Datentmengen zu ermöglichen. Die Kehrseite der Medaille zeigt einen hohen Bedarf an Ressourcen.

Quelle: IBM

*Michael Bauer ist Gescheftsführer der Informatik Trainng GmbH, Radolfzell.

Mehr als 20 Jahre alt ist die Theorie von Codd, und seit über einem Jahrzehnt gibt es operative relationale Datenbanksysteme. Doch ist deren Einsatzintensität immer noch relativ gering. Aktuelle Untersuchungen, beispielsweise die Studie "Informations-Management" von Plenum Institut, belegen, daß erst 24,7 Prozent der Daten in relationalen Datenbanken gespeichelt sind.

lnsbesondere die Großunternehmen zahlen fast alle seit geraumer Zeit Lizenzgebühren für ein relationales DBMS - zumeist für das IBM-Produkt DB2 -, doch die DV-Produktion basiert nach wie vor auf den alten Datenbanksystemen. Das sieht auch die IBM selbst. So stellt Michael Peltzer, Mitarbeiter der Hamburger IBM Unternehmensberatung, in der August-Ausgabe der CW-Schwesterpublikation "edv-Aspekte" fest, daß "DB2 bislang vor allem ein Marketing-Erfolg" sei.

Die praktische Nutzung der relationalen DBMS-Produkte beschränkt sich in vielen Unternehmen noch immer auf Informationssysteme. Einen intensiven Einsatz von DB2 für operative Anwendungen findet man erst bei einem kleinen Teil schätzungsweise bei fünf Prozent der Anwender.

Daß der Migrationsprozeß so langsam vorangeht, beruht auf zwei Gründen. Zum einen bringt es keinen Nutzen, Sondern nur Kosten und Ärger, wenn man ein bestehendes Anwendungssystem lediglich von einem DBMS auf ein anderes umstellt. Für das Unternehmen und für die Benutzer hat sich dadurch nichts verbessert.

Nutzen erschließt sich erst durch Datenmodell

Folglich ist es nur im Rahmen der Neukonzeption eines Anwendungssystems sinnvoll, zugleich das neue DBMS einzuführen. Bis aber alle existierenden Anwendungen ausgetauscht worden sind, vergeht mindestens ein Jahrzehnt.

Der zweite Hinderungsgrund für die Migration liegt in der Qualität der Daten, die in den historisch gewachsenen Dateien und Datenbanksystemen vorhanden sind. Der Nutzen eines neuen DBMS - gleichgültig, ob relational oder objektorientiert - erschließt sich erst bei einem sauberen Datenmodell richtig. Und das zu schaffen, kostet Zeit und Arbeit.

Trotz dieser Schwierigkeiten haben in der oben erwähnten Studie viele Unternehmen angegeben, in den kommenden drei bis fünf Jahren den Anteil der in relationalen DB-Systemen gespeicherten Daten auf 53,5 Prozent steigern zu wollen. Wenn diese Entwicklung so weiter geht, dürften bis zur Jahrtausendwende alle Datenbestände uberführt sein. Doch dann ist das Relationenmodell wahrscheinlich bereits überholt.

Während die Fachwelt bereits über weitergehende Datenbankmodelle diskutiert, stellen wir fest, daß es heute noch immer kein kommerzielles DBMS gibt, das alle Anforderungen von Codd erfüllt. Dabei beziehen sich diese Anforderungen nur auf die Oberfläche eines DBMS und nicht auf seine Technik. Das Modell beschreibt, wie sich die Daten in einer Datenbank dem Benutzer - gleichgültig, ob Programmierer oder Endanwender - präsentieren und mit welchen Operationen er sie bearbeiten kann.

Mit seinen Regeln hat Codd die Datenorganisation und -manipulation auf eine mathematisch präzise Grundlage gestellt - eine auf jeden Fall richtungsweisende Arbeit. Insgesamt gesehen, lassen sich die Anforderungen des Relationenmodells drei Bereichen zuordnen: der Datenorganisation, der Datenmanipulation und der Datenintegrität. In dieser Reihenfolge nimmt die Schwierigkeit der Realisierung zu.

Welchen Nutzen kann man von Relationenmodell erwarten.Im wesentlichen handelt es sich umfolgende Vorteile:

- Die Sicht der Benuzter auf die Daten vird abstrakter, das heißt es sind weniger Kenntnisse über die phisische Datenorganisation erforderlich.

- Es sind mächtigere Operationen gegen die Daten möglich; mit einem DB-Befehl kann eine Vielzahl von Einzeloperationen ausgelöst verden.

- Ein hohes Maß an Datenunabhängigkeit wird erzielt: Die Anwender sind nicht mehr von

Änderungen an der physischen Datenspeicherung oder an der logischen Datenstruktur betroffen.

- Ziel war ebenfalls eine einheitliche Datenbanksprache. Das hat in der Praxis leider nicht ganz geklappt

Eigenschaften wie Performance, Sicherheit, Verfügbarkeit und Handhabbarkeit sind übrigens nicht mit dem Relationenmodell verknüpft. Sie hängen vielmehr von der technischen Realisierung des jeweiligen RDBMS ab und schwanken von Produkt zu Produkt teilweise beträchtlich .

In dem Maße, in dem die Anforderungen des Relationenmodells erfüllt werden, steigt der Nutzen für den Anwender. Doch gerade sehr nützliche Dinge sind häufig nicht implementiert. Dabei fallt auf, daß gerade die Datenbanksysteme der IBM, die ganz auf das Relationenmodell setzen - O-Ton IBM: "DB2 ist die theoriekonforme Implementierung des Relationenmodells" -, noch die meisten Lükken aufweisen. Andere Produkte, speziell aus dem Bereichmittlerer Rechnersysteme, beweisen, daß die Coddschen Forderungen durchaus erfüllbar sind.

Ohne einen Anspruch auf Vollständigkeit zu erheben, will ich hier einige wesentliche Eigenschaften relationaler Datenbanken nennen, die zwar sehr nützlich, aber in den vorhandenen Produkten nur teilweise vorhanden sind:

- Die von Codd geforderte Operation "Outer Join" ist beispielsweise in Oracle und Sybase realisiert; in DB2 fehlt sie hingegen.

- Update auf Join-views ist mit den aus DDB4 weiterentwickelten Produkten SQL-DB und Supra möglich; DB2 muß hier ebenfalls passen.

- Eine automatische Prüfung auf gültige Werte der Daten ist zum Beipiel in IDMS-R und SQI.-DB, aber wiederum nicht in DB2 implementiert.

- Last, but not least weist Sybase an Daten gekoppelte Prüfregeln (Trigger) auf; während DB2 hier einmal mehr außen verbleibt.

Die beiden letztgenannten funktionen gehöre yu der von Codd geforderten User-defined Integrity. Nur mit Hilfe dieser Funktionalität läßt sich in eineml RDBMS eine deutliche Erleichterung bei der Anwendungsentwicklung erzielen. Auf diese Weise wird nämlich viel von dem Coding, das sonst in verschiedenen Programmen wiederholt benötigt wird, zentral beim DBMS hinterlegt und damit automatisch die Wartung vereinfacht .

Weiterentwicklung technischer Funktionen

Selbslverständlich gibt es auch eine Menge technischer Funktionen die in relationalen Dtenbanksystemen weiterentwickelt werden müssen. Dazu gehören unter andern.

- die Verbesserung des Optimizers, der für den Programmierer die intelligente Auflösung der SQL-Statements übernimmt,

- dic Unterstützung großer Datenfelder (Binary Large Objects), die für Textc und Grafik nötig sind sowie

- die Steigerung der Performance durch Buffer-Management, Multiprozessor-Unterstützung und ausgefeilte Speicherungstechniken. Wie schnell hier die Weiterentwicklung voranschreitet und welche Produkte einen Leistungs- und Qualitätsvorsprung haben werden, hängt sichierlich auch von der Marktsitution ab.

Im Mainframe-Bereich sind die Weichen gestellt

Was den Bereich der Großrechnersysteme angeht, so ist die Zeit der Ausvwahlprozesse für die DBMS-Produkte voruber. Der Großteil der MVS-Anwender hat sich "aus strategischen Gründen" - was auch immer das bedeuten mag - für DB2 entschieden. Daneben gibt es noch eine beachtliche Gruppe von Adabas-Anwendern sowie die installierte Basis von IDMS und Datacom, zwei DB-Systemen, die neuerdings auch rclational werden. Lediglich auf dem VSE-Sektor und bei den BS2000-Systemen finden sich heute Unter nehmen, die die DBMS-Entscheidung noch zu treffen haben.

Neugeschäft und damit verbundenen Wettbewerb finden wir im Bereich der Abteilungsrechner sowie der Datenbank-Server. Um die VMS- und Unix-Anwender konkurrieren Oracle, Ingres, Informix, Rdb und neuerdings auch Adabas sowie SQL-DB. Im Server-Bereich treten zusätzlich Sybase, SQL-Base, Progress, OS2/Database Manager und viele andere als Mitbewerber auf.

Dementsprechend intensiv werden diese Produkte weiter entwickelt. Insbesondere für die Datenbank-Server sind Trigger und Stored Procedures (Umfangreiche Datenbankprozeduren, die innerhalb des DBMS ablaufen) notwendig, um den Kommunikationsatlfwand und die Antwortzeiten in einer Client-Server-Umgebung zu verbessern. Diese Erweitelungen bewegen sich bereits in objektorientierte Richtung.

Vor einigen Jahren liefen die Anwender bei der DBMS-Auswahl mit einer Liste der Coddschen Regeln herum - nach dem Motto: "Wenn relational, dann gut." Inzwischen hat sich diese dogmatische Einstellung geändert. Nachdem in der Fachwelt die dem Moelellinnewohnenden Schwächen erkannt und diskutiert wurden, haben die Anwender auch eine mehr pragmatische Sichtweise gewonnen.

Trotz der sicherlich richtungsweisenden Konzepte von Codd ist der relationale Ansatz sicher nicht der alleinseligmachende. Das Modell enthält eine ganze Reihe von Schwachstellen. Zum einen gehen die Bezierungen zwischen Entitäten. die bei der Datenanalyse ermittelt werden, im Relationenmodell wieder verloren ("semantische Lücke). Zum anderen ist das bei der Normalisierung erforderliche Zerschlagen der Daten in lauter kleine Stücke für die Praxis keineswegs hilfreich. Drittens erlauben relationale Datenbanksysteme keine rekursiven Operationen, wie sie bei Stücklisten oder CASE-Repositories benötigt werden und viertens läßt sich in ihnen zu wenig wissen über die Regeln und Funktionen speichern die mit den Daten verbunden sind.

Hier setzt das Konzept der objektorientierten Datenbank an. Diese Systeme bieten zwei wesentliche Erweiterungen: Sie bilden auch Objekte mit komplex strukturierten Daten ab und erlauben so eine vereinfachte Sicht der Welt. Außerdem besitzen sie ein umfangreiches Wissen über die Daten das in form von objekt funktionen, (Methoden) hinterlegt ist.

Durch den Anstoß einer solchen Objektfunktion laufen Prüf- und Verarbeitungsregeln die zusammen mit den Daten definiert werden automatisch ab. Das führt dazu daß Operationen nur einmal codiert werden müssen -unabhängig davon, in wie vielen Geschäftsprozessen diese Funktionalität benötigt wird.

Gesteigert wird diese Wieder verwendung noch durch eine weitere Eigenschaft objektorientierter Datenbanksysteme nämlich durch die Vererbung. Da durch daß Definitionen und Objektfunktionen innerhalb von Objektklassen vererbt werden können reduziert sich der Aufwand nochmals; zu spezifizieren sind dann nur noch die abweichenden Eigenschaften.

Nach diesen Überlegungen drängt sich die Frage auf, ob ein Anwender der jetzt eine DBMS Auswahl zu treffen hat, nicht die Phase der relationalen Datenbanken überspringen und gleich ein objektorientiertes System einsetzen soll. Zu bedenken ist dabei jedoch tolgendes:

1. Die objektorientierten Datenbanksysteme befinden sich noch in den Kinderschuhen. Die wenigen technischen Realisierungen sind meist nur auf PCs und Unix-Rechnern einsetzbar und von daher für viele Anwendungsbereiche ungeeignet.

2 Die evolutionäre Weiterentwicklung der relationalen Datenbanksysteme kann zur Verlagerung von mehr Intelligenz ins DBMS führen. Einen Beleg dafür lietern zum Beispiel Ingres oder Adabas mit Active View Processor. Wenn sich die Systeme in diese Richtung entwikkeln, besteht für die Anwender die Möglichkeit künftig komf'ortablere Funktionen zu nutzen ohne die heute erstellten Anwendungen umstellen zu müssen.

3. Eine saubere Datenanalyse ist die sinnvolle Voraussetzung für die Migration auf ein relationales Datenbanksystem. Sie ist allerdings auch für jedes andere DB-Modell sinnvoll. Existiert erst einmal ein Datenmodell so ist die Migration yu einem anderen DBMS einfacher. Folglich sollten die Anwenderunternehmen sich zunächst auf diesen Prozeß konzentrieren.

4. Der Nutzen der Objektorientierung - bessere Verständlichkeit und ein hohes Maß an Wiederverwendbarkeit - ist durch den Einsatz einer objektorientierten Datenbank oder Sprache keinesfalls automatisch gewähr leistet. Entscheidend ist vielmehr, daß die Prinzipien der Objektorientierung im Analyse- und Designprozeß angewendet werden. Dieser Nutzen läßt sich also weitgehend auch mit konventionellen Softwareprodukten erzielen.

Mein Rat an die Anwender: Verwenden Sie zunächst erprobte und operativ einsetzbare Datenbanksysteme aber entwerfen Sie Ihre Anwendungen bereits heute mittels objektorientierter Anayse- und Designmethoden.