Integration bedeutet einerseits, daß alle Daten einheitlich modelliert und beschrieben werden müssen, um typübergreifende Operationen und flexible Auswertungen auf den Daten durchführen zu können. Da es sich zunächst um eine gemeinschaftliche Sicht der Daten handeln soll, ist dabei auch Anwendungsneutralität von großer Wichtigkeit. Andererseits dürfen einzelne Benutzer nur auf die Teile der Datenbasis zugreifen, die zur Lösung ihrer Aufgaben erforderlich sind. Dabei sollen individuelle Sichten der benötigten Daten eine angemessene Unterstützung für anwendungsspezifische Problemlösungen liefern, ohne wiederum Abhängigkeiten zwischen Daten und Programmen einzuführen. Weiterhin können Leistungsanforderungen, durch die Mehrfachbenutzung der integrierten Daten bedingt, den Einsatz verschiedenartiger Speicherungsstrukturen für bestimmte Teile der Datenbasis (Repräsentationssicht) diktieren, so daß systemkontrollierte Redundanz für ausgewählte Anwendungen durch die physische Organisation der DB bereitzustellen ist. Auch hier dürfen Speicherungsredundanz und andere leistungsbezogene Maßnahmen die geforderte Datenunabhängigkeit nicht abschwächen. Durch eine geeignete Systemarchitektur und vorgegebene Zugriffsschnittstellen sollen die DB-Nutzer von den Leistungsaspekten des DBS abgeschirmt werden. Auf keinen Fall sind Beeinflussungen der logischen Organisation der integrierten Daten und der Benutzersichten oder gar Funktionsveränderungen zulässig.
In einer mehrjährigen Studie hat die "ANSI/X3/SPARC Study Group on Database Management Systems" (ANSI steht für American National Standards Institute) die Frage nach einer allgemeinen Beschreibungsarchitektur für DB-Funktionen, -Schnittstellen und -Nutzungen untersucht, wobei Datenintegration bei gleichzeitiger Datenunabhängigkeit herausragendes Entwurfsziel war. Ein Überblick zum ANSI/SPARC-Architekturvorschlag findet sich in [TSIC78], wo durch Graphiken und Schnittstellenbeschreibungen dessen Reichweite verdeutlicht wird. Durch die Festlegung von 40 Schnittstellen (unterschiedlicher Wichtigkeit und Komplexität) will der Architekturvorschlag einen Beschreibungsrahmen für alle Probleme und Aufgaben der Modellierung, Realisierung, Verwaltung und Nutzung von DB-Daten definieren. Aus dieser "Schnittstellenarchitektur" wählen wir nur solche Schnittstellen aus, die für unsere Diskussion der DBS-Realisierung wichtig sind. In Abb. 1.1 ist ein Ausschnitt der Schnittstellenarchitektur skizziert, der oft als ANSI/SPARC-Grobarchitektur bezeichnet wird.
Schnittstellen bieten Beschreibungsebenen und damit gewisse Sichten auf die Daten. Zentral ist danach die integrative oder gemeinschaftliche Datensicht, die auch als Konzeptionelle Ebene bezeichnet wird. Benutzerspezifische Sichten werden auf der Externen Ebene festgelegt, während die Interne Ebene bestimmte Aspekte der physischen DB-Organisation beschreibt. Weitere Schnittstellen, welche die Spezifikation der Abbildung und Zuordnung der Daten auf Externspeicher erlauben, werden bei dieser Großcharakterisierung gewöhnlich weggelassen, sind im ANSI/SPARC-Vorschlag jedoch vorgesehen. Zu jeder Beschreibungsebene (Schnittstelle) gehört eine Sprache zur Spezifikation konkreter Objekte; das Ergebnis einer solchen Beschreibung wird, wie im DB-Bereich üblich, als Schema (und nicht als Modell) bezeichnet.
Bei der Entwicklung eines Anwendungssystems liefert eine Informationsbedarfsanalyse in der betrachteten Miniwelt die Informationen über Sachverhalte, Beziehungen und Vorgänge, die im DBS durch Daten repräsentiert werden sollen. Der DB-Entwurf zielt zunächst auf eine gemeinschaftliche Sicht der integrierten Daten ab. Die Aufbereitung dieser Daten führt dann zur Definition des Konzeptionellen Schemas. Die Festlegung der physischen DB-Struktur erfolgt im Internen Schema. Sie ist zu ergänzen durch Angaben der Speicher- und Gerätezuordnung, für deren Spezifikation spezielle Sprachen[3] oder fallweise Dienstprogramme eines konkreten DBS eingesetzt werden.
Aus der gemeinschaftlichen Sicht werden i. allg. eine Reihe verschiedener individuellen Sichten abgeleitet, um Anwendungsprogrammen für ihre Problemlösung angemessene Datenstrukturen bieten zu können. Solche speziellen Benutzersichten sind jeweils durch ein separates Externes Schema zu spezifizieren. Mit der benutzerspezifischen Sichtenbildung werden zugleich wichtige Aufgaben, die einfache Nutzung und Zugriffsschutz der Daten betreffen, erfüllt. Durch eine explizite Abbildung (durch Projektion, Selektion und Verbund) ausgehend vom konzeptionellen Schema lassen sich externe Schemata an die Erfordernisse der Anwendung anpassen. Da außerdem nur die im externen Schema spezifizierten Daten für den Benutzer (Programm) sichtbar sind, wird eine Reduktion der Komplexität und eine vereinfachte Verarbeitung erreicht. Zugleich sind alle nicht in der Sicht definierten Datenobjekte dem Benutzer verborgen. Da diese nicht adressiert werden können, ergibt sich automatisch eine starke Isolation dieser Daten, die dem Zugriffsschutz dient. Schließlich wird eine explizite Abbildung der Datentypen (Datentypkonversion) auf die Datentypen der Wirtssprache vorgenommen. Dies ist eine Voraussetzung dafür, daß das DBS zusammen mit Anwendungsprogrammen, die in verschiedenen Programmiersprachen geschrieben sind, eingesetzt werden kann.
Solche mehrsprachenfähige DBS entsprechen einer wichtigen Anforderung aus der Praxis, da in einem Unternehmen nicht davon auszugehen ist, daß über einen langen Zeitraum nur eine einzige Programmiersprache eingesetzt wird. Die explizite Abbildung der Daten durch das externe Schema und ihre räumlich getrennte Verarbeitung im Arbeitsbereich des Benutzers erzielen auch eine Isolationswirkung bei Programmfehlern (oder beabsichtigten Manipulationen) in der Anwendung, die eine Zerstörung oder Korruption der DB-Daten verhindert.
Alle Schemata müssen vollständig definiert sein, bevor mit ihnen und einem generischen Datenbankverwaltungssystem (DBVS) ein konkretes DBS erzeugt werden kann. Im Mittelpunkt unserer Betrachtungen steht nachfolgend der Aufbau und die Realisierung solcher generischer DBVS, für die wir zunächst geeignete Schichtenarchitekturen einführen. Im Gegensatz zur ANSI/SPARC-Architektur, die im wesentlichen Schnittstellen beschreibt, dienen die nachfolgend eingeführten Schichtenmodelle zur Beschreibung und Erklärung der Realisierung von DBVS.