Die Entwicklung von Datenbanksystemen führte schrittweise von der programmbezogenen Dateiverwaltung zu Programmsystemen, die den Anwender allmählich von den Aufgaben der Kontrolle und Verwaltung großer Datenmengen befreite. Die Ergebnisse der ersten Schritte waren nicht-universell einsetzbare Datenverwaltungssysteme, ausgerichtet auf eine Spezialaufgabe wie Stücklistenverarbeitung oder Information-Retrieval. Heute existieren auf dem DB-Markt Systeme verschiedener Hersteller, die in ihren Strukturen, ihrer Terminologie und vor allem in den Benutzersprachen erhebliche Unterschiede aufweisen.

Zur Behebung dieses Zustandes wurden von verschiedensten Gremien (DIN, AFNOR, ANSI, SPARC, ISO) allgemeine DB-Standards empfohlen und Normierungsvorschläge unterbreitet. Exemplarisch hierfür werden im folgenden zwei Normierungsvorschläge vorgestellt. Der eine (DBTG-Konzept von CODASYL) war der erste ernsthafte Vorschlag zur Standardisierung von DB-Systemen überhaupt und ist vielfach realisiert worden, der andere (Koexistenzmodell von ANSI/SPARC) kam bisher über theoretische Überlegungen nicht hinaus, wird aber von vielen DB-Experten als wegweisende Basis zukünftiger DB-Entwicklungen gesehen.

CODASYL-Konzept

Die DB-Vielfalt Ende der 60er Jahre erschwerte im großen Maße die von vielen Anwendern geforderte Kompatibilität und Portabilität von Anwenderprogrammen, die häufig mit als unabdingbare Voraussetzung für die Zukunftssicherheit der auf einer Datenbank basierenden Programmsysteme angesehen werden. So entstanden bereits vor etwa 15 Jahren Benutzervereinigungen, die sich die Normierung von DB-Systemen zum Ziel gesetzt haben. Als bedeutendste erwies sich zunächst CODASYL (Conference on Data System Languages). Seit 1965 befaßt sich dieses Gremium auch mit der Aufgabe der Datei- und Datenbankbehandlung. 1969, 1971, 1973, 1976 und 1978 wurden die Ergebnisse der entsprechenden Arbeitsgruppen veröffentlicht. Sie beschreiben ein Datenbankkonzept, das von Bericht zu Bericht ständig konkretisiert wurde. Dieses Konzept ist weitgehend in sich geschlossen, abgerundet und durch intensive Diskussion auch außerhalb der CODASYL-Arbeitskreise ständig verbessert worden.

Das CODASYL-Modell steht allen Herstellern und Anwendern zur Verfügung. Seine externen Schnittstellen sind exakt beschrieben, die interne Realisierung bleibt jedem Produzenten selbst überlassen. CODASYL-Datenbanksysteme werden angeboten unter anderem von Honeywell (IDS), Univac (DMS/1100), DEC (DBMS-20), Cullinane Corp. (IDMS), Fujitsu (AIM) und Siemens (UDS).

Koexistenzmodell

(ANSI/SPARC)

Wegen der Vielfalt der Anwendungsmöglichkeiten, den unterschiedlichen Zielsetzungen und den differierenden Ebenen der Problemlösungen setzte in der wissenschaftlichen Auseinandersetzung eine heftige Diskussion um das geeignetste künftige Datenmodell ein. Zur Beantwortung der Frage, wie standardisierte DB-Systeme der Zukunft aussehen werden, muß vor allem die Konzeption des amerikanischen Normenausschusses ANSI/SPARC (ANSI/X3/SPARC, Study Group on Data Base Management Systems, 1975) erwähnt werden (ANSI = American National Standards Institute, SPARC = Standard Planning and Requirement Commitee).

Die Struktur dieses DB-Systems ist durch einen dreischichtigen Aufbau gekennzeichnet (Abbildung). Im Zentrum der Architektur steht das Basisschema bei dessen Entwurf zu den Anwendungsprogrammen hin auf Datenneutralität und mit Blickrichtung auf die physische Datenbank auf Datenunabhängigkeit zu achten ist. Es soll eine vollständig redundanzfreie und neutrale Darstellung der logischen Datenstrukturen gewährleisten. Aus ihm können durch Abbildungen benutzerindividuelle externe Schemata abgeleitet werden. Bei vollständiger Datenneutralität ist es möglich, durch unterschiedliche Benutzerschichten das Basisschema zu betrachten. Eine Sicht ist dabei keine physische Kopie, sondern ein abstrakt existierendes Datenmodell, das nach ANSI/SPARC mit Hilfe einer Datenmanipulationssprache aus der Basis erzeugt wird. Auf der anderen Seite soll eine Reihe von Abbildungen verschiedene interne Schemata zur Beschreibung der physischen Strukturen erzeugen. Sie enthalten mit ihren Katalogen die Details über die Zugriffspfade und die physische Abspeicherung.

Im ANSI-/SPARC-Ausschuß konnte man sich bisher nur auf die globale Architektur eines DB-Systems einigen.

Ein Datenmodell, mit dem das Basisschema zu realisieren ist, war wegen der unterschiedlichen Interessenlagen nicht Gegenstand von Einigungsbemühungen. Aus dem Normenvorschlag kann man allerdings schließen, daß dem Modell die Zukunft gehört, das den Forderungen nach Neutralität und Unabhängigkeit am besten gerecht wird.

Obwohl die Nützlichkeit von Standards von vielen Anwendern, insbesondere aus dem Nicht-CODASYL-Bereich, oft abgestritten wird, sind doch erhebliche Vorteile bei objektiver Betrachtung festzustellen. So konnte die durch CODASYL initiierte Systematik in der Beschreibung und Handhabung der Daten das DB-Gebiet wesentlich transparenter machen. DB-Standards, abgestimmt mit-DC-Normen, werden, besonders auch für den Anwender sichtbar, künftig noch größere Bedeutung erlangen, je häufiger DB-Systeme als integrierte Bestandteile in Verarbeitungsnetzen vorgesehen sind. Standards vermindern in diesen Fällen das Pflege- und Wartungsproblem, der Datenaustausch zwischen verschiedenen Installationen kann wesentlich erleichtert werden (höhere Leitungsprotokolle für Host- und DB-Rechner; normierte Schnittstellen bei DB-Prozessoren). Die entstehenden Vorteile kommen dann nicht nur den Anwendern zugute, sondern immer auch Systemanalytikern und DB-Verwaltern, die das DB-Design wesentlich leichter und effizienter erstellen beziehungsweise die DB-Anwendungen problemloser.

Literatur: T. Härder, Implementierung von Datenbanksystemen, Hanser Verlag 1978;

H. Wedekind, Relationale Datenbanksysteme, Informatik-Spektrum 1,5-16 (1978); H. Clemm, E. Wildgrube, Datenbank-Management-Systeme als Rationalisierungsmittel, Siemens data report 14 (1979); K. Hollederer, K. L. Hebler, Universelles Datenbanksystem UDS, Sonderdruck aus data report 11 (1976). Wolfgang Suske ist Produktplaner für Datenbanken bei der Siemens AG, München.

*Wolfgang Suske ist Produktplaner für Datenbanken bei der Siemens AG, München