Noch haben längst nicht alle Anwender ihre hierarchischen oder Codasyl-Datenbanken gegen relationale Datenbanksysteme eingetauscht, da steht schon ein neues Modell der Datenmodellierung vor der Tür: Entity-Relationships. Peter Pagé, Dieter Mainz und Michael Bauer haben sich mit der Frage der Nützlichkeit dieser Innovation auseinandergesetzt.
Peter Pagé ist als Vorstandsmitglied der Software AG verantwortlich für Entwicklung, Marketing und Vertrieb in Europa. Dr. Dieter Mainz arbeitet als Berater für Systementwicklung bei der IBM in Köln. Als Moderator fungierte Michael Bauer, Geschäftsführer von Informatik Training, Radolfszell. Die hier wiedergegebene Podiumsdiskussion fand im Rahmen eines Datenbankkongresses statt, der von der Münchner Plenum Institut GmbH in Frankfurt veranstaltet wurde.
Bauer: Für die Anwender steht im Vordergrund, DV-Lösungen zu schaffen. Welche Rolle spielt es dabei, ob ihr eingesetztes Datenbanksystem nach dem Relationen- oder dem Entity-Relationship-Modell konzipiert ist? Was hilft diese neue Modelldiskussion?
Mainz: Modelle zu erstellen, bedeutet, Wirklichkeit abzubilden. Vor allem soll auf diese Weise der künftige Informationsbedarf eines Unternehmens fest gestellt werden. Modelle zeigen also wünschenswerte Zustände der kommenden fünf oder mehr Jahre an. Das Ziel ist eine funktionierende Strategie in Richtung auf ein integriertes Informationssystem. Insofern sind solche theoretischen Diskussionen gerade auch im Datenbankbereich für jeden von Bedeutung.
Was allerdings den Streit um das Relationen- oder Entity-Relationship-Modell betrifft, so wird hier eine nicht existente Alternative vorgegaukelt. Man braucht beide. Allerdings läßt sich das Entity-Relationship-Modell durchaus mit Hilfe von Relationen abbilden. Neben diesen Modellen spielen aber auch Data Dictionaries eine wichtige Rolle für die Zukunft der Datenhaltung.
Bauer: Heißt das, daß der Anwender sich nicht zwischen Entity-Relationship und Relationen zu entscheiden braucht?
Page: Es ist heute noch zu früh, sich auf ein bestimmtes Datenmodell festzulegen. Bei der Analyse der Datenmodelle erweist sich aber vor allem das Entity-Relationship-Modell als hilfreich. Die Implementierung scheitert daran, daß entsprechende Produkte fehlen. Das "perfekte" Datenbanksystem gibt es also nicht. Trotzdem muß man die Daten auch heute schon einheitlich beschreiben - zum Beispiel mit dem Entity-Relationship-Modell.
Bauer: Ist das relationale Modell, wie es von Codd aufgestellt wurde, jemals sauber und vollständig realisiert worden?
Mainz: Ihre Frage zielt auf die Ausbaufähigkeiten eines noch nicht angekündigten IBM-Produkts. Ich antworte also lieber allgemein. Wenn man Modelle miteinander vergleicht, darf man sie nicht an bestehenden Produkten messen.
Vielmehr geht es darum, daß sich formale Probleme optimal mit mathematischen Relationen beschreiben lassen, während Entity-Relationships sich für die Darstellung von Beziehungen zwischen Objekten eignen. Braucht man also zwei Sprachebenen?
Ich denke, das Entity-Relationship-Verfahren kann die Relationen immer dort ergänzen, wo deren mathematische Strenge der Wirklichkeit nicht mehr gerecht wird - vor allem in der Analysephase, wenn es darum geht, die Beziehung und Bedeutung von Attributen zu beschreiben.
Bauer: Ich fasse zusammen: Die Entscheidung für ein Datenmodell ist zunächst nicht von den verfügbaren Produkten abhängig. Wenn man aber seine Ergebnisse in einem Datenbanksystem ablegen will, dann existieren dort konkrete Regeln über die Organisation der Daten und ihre Speicherung. Damit wird auch die Logik der Programme produktspezifisch ausgelegt. Wenn die Unternehmen Datenbanksysteme nach dem Relationenmodell einsetzen, stellt sich die Frage, wie lange das Modell seine Geltung behalten wird.
Page: Das ist wie bei Codd. Bis dieses Modell vollständig implementiert ist, hat sich unser Denken verändert.
Mainz: Vielleicht ist es gar nicht sinnvoll, alle Regeln zu unterstützen.
Bauer: Gibt es vielleicht auch noch notwendige Regeln, an die Codd nicht gedacht hat?
Mainz: Man könnte und sollte den Objektbegriff mehr als bis her benützen - vor allem für die Benutzeroberflächen. Der Objektgedanke muß dabei aber auf die Interpretation von Unternehmensinformationen übertragen werden. Das Konzept der Objekte leitet sich von dein der Datenstrukturen ab. Der Weg führt von den Daten zu den Objekten. Die freie Kombinierbarkeit der Daten ist im Relationenmodell möglich, über die freie Kombinierbarkeit von Anwendungsfunktionen denken wir zur Zeit nach.
Pagé: Entitäten sollten untereinander kombiniert werden. Zwar leistet das Entity-Relationship-Modell prinzipiell dasselbe wie die Relationen, aber es vermeidet, daß unsinnige Bezüge hergestellt werden. Objekt plus Entity Relationship haben keine Einschränkungen der Verbindungen zur Folge.
Bauer: Wir nehmen nicht nur Strukturen sondern auch Datenregeln wahr. Ist das Relationenmodell in der Lage, dem methodischen Trend zu folgen und Regeln über Daten abzulegen? Mainz: Eine entscheidende Frage. Es gibt referentielle Integritätsregeln und andere Regeln über Daten. Sie festzuhalten ist nicht Aufgabe von SQL. In IBMs AD/Cycle-Konzept werden solche Aspekte durch das Repository aufgegriffen.
Bauer: Gibt es also künftig zwei Möglichkeiten für den Anwender, sich entweder ein ganz modernes Datenbanksystem anzuschaffen oder ein SQL-System mit entsprechenden Tools? Herr Pagé können Sie sich vorstellen, ein Adabas-Entire auf DB2 aufzusetzen?
Pagé: Unter den derzeitigen Bedingungen, nein. Für das Entity-Relationship-Modell ist SQL als Basis nicht leistungsfähig.
Bauer: Entscheidungen für Datenbanken gelten als strategisch, insbesondere wenn es um Produkte der IBM geht. Gibt es für Anwender damit eigentlich eine Alternative zu DB2.
Pagé: Das hängt ganz vom Bedarf ab. Die Entscheidung für DB2 geschieht doch nicht automatisch - oder darf man das heute nicht mehr sagen.
Frage aus dem Publikum: Was also sollen die Unternehmen machen?
Pagé: Sie sollten das Produkt kaufen, das die höchstmögliche Funktionalität aufweist.
Bauer: Können andere Anbieter hier den Anwendern helfen?
Pagé: Wir sind zur Zeit dabei, bei Natural die Sprache mit der Datenhaltung zu verheiraten.
Bauer: Ich halte es nicht für eine gute Lösung Datenbankfunktionen außerhalb der Datenbank in einem Tool zu halten.
Pagé: SQL als Standard soll bestehen bleiben. Erhaltenswert sind aber eigentlich nur die Befehlsbezeichnungen. Hier liegt die einzige Funktion dieser Abfragesprache.
Frage aus dem Publikum: Denkt IBM an eine so enge Verbindung zur Hardwaretechnologie, daß der Kunde um den Kauf von DB2 nicht herum kommt?
Mainz: Das SAA-Konzept ist die Leitlinie. DB2 fungiert hier als Kernstück. Damit geht die künftige Entwicklung ganz klar in Richtung DB2 und relationales Konzept. Wichtig ist uns dabei vor allem auch die Verbindung von PC und Host.
Pagé: Und Unix?
Mainz: Die Integration von Unix muß sicher genauer betrachtet werden.
Bauer: Um auf die Publikumsfrage zurückzukommen. Heißt die Schnittstelle zwischen Anwendung und Betriebssystem ausschließlich DB2 oder könnte, auch die Oracle-Datenbank nehmen?
Mainz: Der Sinn von Standards ist Entkoppelungen zu ermöglichen. SQL dient in diesem Sinn als Schnittstelle zwischen Datenbank und Anwendung. Bei der Schnittstelle zum Betriebssystem liegt die Sache allerdings anders.
Das Repository ist eine Anwendung von DB2 und hat das Ziel, alle Informationen über Informationssysteme zu erhalten. Das sind Metadaten von Daten, Funktionen und Relationen.
Pagé: Das Repository oder die Repositories werden sich zum Schlachtfeld der Zukunft entwickeln. Das Ziel heißt objektorientierte Datenhaltung unter einer solchen Metadatenbank.
Mainz: Ja. Das Repository entscheidet über die Entwicklung von Informationssystemen. Vor allem wird es mit einer Standardschnittstelle , ausgestattet sein.
Pagé: Die Basis von Relationen und Entity Relationships ist eine außerordentlich komplexe Struktur, in der sich ein Repository erst zurechtfinden muß.
Bauer: Wie beschreibt man dort Objekte, was passiert mit den Regeln?
Pagé: Das Repository kann - wenn es denn kommt - ein Topf für die Regeln werden. Cobol mit seinem Wust ist dafür sicher nicht die Programmiersprache der Wahl. Was wir brauchen, ist eine ausführbare Spezifikationssprache.
Mainz: Richtig. Die Datenregeln sollen im Repository nach einem verbindlichen Standard abgelegt werden. Um das zu ermöglichen, kooperieren wir mit, einer ganzen Reihe von Softwarepartnern. Ich zitiere Heinz Nixdorf: "Wem es gelingt, einen Standard zu setzen, der hat einen absoluten Vorteil". Da wir das nicht allein können, stützen wir uns beim Repository auf Partner.
Pagé: Das Datenbanksystem spielt dabei keine besondere Rolle...
Bauer: Je mehr Unabhängigkeit unsere Anwendungen von einem Datenbanksystem gewinnen, desto geringer wird dessen strategische Rolle. Der eigentliche Nutzen kommt von den Werkzeugen für die Anwendungsentwicklung - also Sprachen der vierten Generation oder Programmgeneratoren. Aber auch durch sie werden wir wieder von Herstellern abhängig - nur eben eine Stufe höher.
Hintergründe für die neue Modelldiskussion
Das Relationenmodell stellt einen richtungsweisenden Ansatz in der Datenbankentwicklung dar. Hier wurde zum ersten Mal ein methodisch abgesichertes Modell - im Gegensatz zu den heuristischen Lösungen der früheren Datenbank-Management-Systeme (DBMS) - entwickelt, das die Präsentation von Daten und ihre systematische Behandlung umfaßt. Hierauf basierend konnten in DBMS Sprachmittel und Funktionen implementiert werden, die ein wesentlich höheres Maß an Abstraktion, Mächtigkeit und Datenunabhängigkeit für die Benutzer von Datenbanken - Programmierer und selbständige Endbenutzer - ermöglichten. Dabei schälte sich eine der relationalen Abfragesprachen, nämlich SQL, als Standard heraus. Trotzdem darf man das Relationenmodell nicht einfach mit SQL gleichsetzen.
Als allgemeingültiger methodischer Ansatz ist das Relationenmodell von langfristiger Bedeutung. Aber es stellt noch nicht die ultima ratio dar. In der praktischen Nutzung zeigten sich auch Schwächen und Unzulänglichkeiten, die sich wiederum im Umgang mit SQL niederschlugen. Dies fällt insbesondere auf bei:
- Informationsgewinn durch Endbenutzer,
- Einsatz in "Non-standard-Anwendungen" wie CAD, Texte und Dokumente sowie bei
- Behandlung komplexen Objekte, etwa Stücklisten.
Insbesondere die Behandlung von Informationen, die zu einem Objekt gehören - sowohl Speicherung als auch Manipulation -, fällt im Relationenmodell schwer. Aufgrund der Normalisierung werden die Informationen zerstückelt gespeichert und erst mittels SQL-Anweisungen mühsam wieder zusammengesetzt, sofern es überhaupt geht.
An dieser Stelle setzen jetzt Datenmodelle an, die diese Probleme in den Griff bekommen wollen. Hierzu gehört das als Weiterentwicklung es Relationenmodells gedachte NF2-Modell des IBM-Forschungszentrums und das Entity-Relationship-Modell (ER-Modell) von Chen. Die Modelldiskussion ist damit wieder offen!
Die Anwender weisen den Weg
Es ist keineswegs sicher, ob die Zukunft objektorientierten Datenbanksystemen nach dem Entity-Relationship-Modell gehört, wie die nebenstehende Grafik suggeriert. Aber die Richtung stimmt.