FRIEDRICHSDORF (je) - Sechsmal pro Jahr will Frederick H. Schuchardt , Marktkenner und Softwareexperte" sowie Geschäftsführer der Data Research International (DRI) GmbH in Friedrichdorf, von neutralem Standpunkt aus über DB/DC-Entwicklungen und -Probleme berichten. Sein Sprachrohr dabei ist der "database newsletter", dessen Erstausgabe letzt vorliegt, und als dessen Chefredakteur Schuchardt fungiert. Der database newsletter - er ist zu einem Jahres-Abonnementpreis von 240 Mark zu beziehen -enthält in Ausgabe Nr. 1 beispielsweise unter "Trends & Prognosen" einen Bericht über die Arbeit des amerikanischen Normenausschusses ANSI/SPARC, den wir mit freundlicher Genehmigung der DRI hier wiedergeben:
Der amerikanische Normenausschuß ANSI/SPARC verfügt über eine Reihe von Kommissionen und Arbeitsgruppen, die Empfehlungen für den Ausschuß erarbeiten. Im Herbst 1979 traf sich die Data Base Systems Study Group (DBS-SG) in New York. Ihr gehören Vertreter aus Industrie, Regierung, Wissenschaft und solche von Beratungsgesellschaften an. Die Anwenderseite ist derzeit noch unterrepräsentiert. Eine der vordringlichsten Aufgaben, mit der sich die Arbeitsgruppe wird befassen müssen, ist die Festlegung einer Datenbank-Systemarchitektur.
Theoretiker neigen zur Black Box
Einige Mitglieder, insbesondere die eher theoretisch ausgerichteten, meinen, die gesamte Architektur sollte eine "Black Box" sein, deren Funktionalität erst an den Punkten der Nutzung beschrieben wird. Pragmatiker hingegen möchten die Einzelheiten der Architektur spezifiziert haben. Wenn alternative Architekturen existieren, wollen sie die Einzelheiten jeder untersuchten Alternative, der verworfenen wie der ausgewählten, beschrieben haben. Da es schwierig ist, sich "Standards" ohne Architektur vorzustellen werden sich, wahrscheinlich die Pragmatiker durchsetzen.
In den 60er Jahren noch glaubten Datenbanktheoretiker, daß eine aus zwei Schemata (Schema, Subschema) bestehende Architektur ausreichend sein würde. Inzwischen aber gibt es Befürworter einer 3-Schemata-Architektur (internes Schema, Begriffsschema, externes Schema), die noch durch den Vorgänger der DBS-Arbeitsgemeinschaft entwickelt wurde. Vielleicht werden verteilte Systeme oder Produkte, die auf neuer Hardware basieren, noch mehr Schemata erfordern. Die zukünftigen Aufgaben eines Information-Management innerhalb eines Unternehmens sind noch nicht deutlich zu übersehen. Dies sind die Dinge, die die Architekturdebatte beeinflussen werden. In dieser Debatte wird die Rolle von Data Dictionary Systems (DDS) ebenfalls zu erörtern sein. Es wird mehr oder weniger allgemein akzeptiert, daß eine Standardisierung von Datenbanken letztlich auch eine Standardisierung von DDS bedeutet.
Aber wie ist es mit DDS ohne Database Managementsystem (DBMS)? Und mit DDS und verteilten. Systemen ohne DBMS? Wie steht es mit allen dreien zusammen? Wenn alle Definitionen von verteilten Systemen und Datenbanken im DDS enthalten sind, ist dann nicht die Benutzerschnittstelle mit dem DDS letztlich die kritischste? Offensichtlich sind dies sehr schwierige Fragen, und zwar unmittelbar am Kernpunkt der Architekturdiskussion.
Hier wollen sich relationale Verfechter Gehör verschaffen. Sie haben eingeräumt, daß das Codasyl-Datenmodell unausweichlich der Kernpunkt der Beratungen des Komitees sein wird, und führen nun Gründe für mehrfache Begriffsschemata mit abbildbarer Äquivalenz an. Mit anderen Worten, externe Schemata (das 3-Schema-Äquivalent von Subschemata) sollten in ein beliebiges Datenmodell eingebettet werden, das dem Datenadministrator für die gegebene Anwendung geeignet erscheint. Die Folgerung ist, daß ein Codasyl-ähnliches Datenmodell (und DBMS) in der Lage sein muß, relationale Anwendungen und umgekehrt zu unterstützen.
Derzeit wird mit viel Aufwand die Durchführbarkeit von Äquivalenzabbildungen (mapping equivalence) untersucht. Diese Arbeit wird jedoch durch die Tatsache gehemmt, daß keiner wirklich zu wissen scheint, wie ein Begriffsschema (Conceptual Schema) aussieht. Einige sagen, ein Codasyl-ähnliches Datenmodell sei auf der Begriffsschemastufe; andere sagen nein.
Die Ergebnisse dieser Untersuchungen sind folgenreich. Falls sich Äquivalenzabbildungen als undurchführbar erweisen I werden die relationalen Verfechter einen I Frontalangriff auf Codasyl als den Brennpunkt für Standards inszenieren. Anderenfalls ist ein beträchtlicher Fortschritt im "State-of-the-Art" der Datenabbildung zu erwarten.
Relationale Standards vor oder nach der Praxiserprobung?
Das Problem der Einbeziehung relationaler Betrachtungen wird nicht einfach verschwinden. Einige glauben die Zeit zur Einführung eines relationalen Standards sei günstig, solange noch keine kommerziellen Angebote existieren. Andere bestreiten dies mit der Begründung daß bisher noch keine praktischen Erfahrungen gesammelt werden konnten In jedem Falle wird eine Datenbankarchitektur, die - jetzt oder später - keine relationalen Verbindungen berücksichtigen kann, höchstwahrscheinlich von der Industrie abgelehnt.
Obwohl die DBS-SG so zusammengesetzt wurde, daß sie für die Industrie von Interesse blieb, paßt die relationale Untergruppe nicht recht in das Konzept. Die "Blitzableiter" -Untergruppen, wie der Vorsitzende Berg sie kennzeichnet, sollten die "Speerspitze" der Benutzer und Hersteller sein, haben aber bisher kaum ein Echo gefunden.
Schließlich gibt es auch eine Diskussion darüber, wie weit die Arbeitsgemeinschaft bei der Analyse der administrativen Konsequenzen der von ihr vorgeschlagenen Architekturen gehen sollte. Der Konsensus scheint darin zu bestehen, daß das Komitee nicht versuchen sollte, sich selbst zu Management-Beratern zu machen. Da jedoch die neuen Datenmanagement-Architekturen die Organisationsstruktur des Information-Management beeinflussen werden, ist zu erwarten, daß sich eine andere Institution oder Gruppe dieses Themas annehmen muß.