MÜNCHEN - Eine Revolution bedeutete vor einigen Jahren die Einführung der "Data Description Tables" (DDT) für Dateien und später für Datenbänke. Sinn dieser DDT war es, Datensätze und Datenfelder unabhängig von Programmen zu definieren. Mehrere Programme konnten unter Zuhilfenahme der DDT auf die gleiche Datei zugreifen, ohne daß Datenformate, Feldlängen und Satzlängen jeweils einzeln hätten spezifiziert werden müssen.
Große Datenbänke haben die Eigenschaft, daß sie Aufbau und Inhalt im Laufe der Zeit wesentlich verändern. Die Erweiterung eines Nummernschlüssels erzwingt sehr häufig, daß die Länge eines Feldes geändert werden muß. Oder eine neue Anwendung erfordert, daß neue Datenfelder zum Datensatz hinzugefügt werden müssen. Das hätte normalerweise zur Folge, daß die Anwenderprogramme, die mit der Datenbank arbeiten, dementsprechend geändert werden müßten. Insofern geht in den letzten Jahren die Tendenz dahin, Datenbanken und Dateibeschreibungstafeln (im englischen auch: Data Base Definition - DBD) so zu konzipieren, daß eine Änderung ohne weiteres möglich ist - ohne daß die Anwenderprogramme angepaßt werden müßten.
Unabhängigkeit als Qualitätsmerkmal
Die Anwenderprogramme müssen Gebrauch machen von externen Definitionen und erst im Go Step mit diesen arbeiten. Die Schnittstelle zur Datenbank an sich liegt dann nicht beim Ein/ Ausgabemodul sondern bei der DDT.
Die Erweiterung eines Schlüssels macht die Verlangerung des betreffenden Datenfeldes notwendig.
Über die Programmänderung hinaus erzwingen solche Änderungen Wartungsläufe, bei denen die Datenbank ausgeladen und mit der Berücksichtigung der neuen Feldlänge wieder eingeladen wird.
Der Grad der Unabhängigkeit der Anwenderprogramme von Änderungen in der Datenbank kann als Gradmesser für die Qualität eines Datenbankkonzepts gelten.
Zwei Methoden
Diese Datenunabhängigkeit ist dadurch zu erreichen, daß Anwenderprogramme jeweils nur zu den Datenfeldern zugreifen, die sie benötigen. Um das zu erreichen, haben sich zwei Methoden herauskristallisiert:
- Feldzugriff: Das Anwenderprogramm bezeichnet die Felder, die es für seine Operationen braucht. Beispiel: Aus der Mitarbeiterdatei eines Betriebes seien aie Felder Name, Vorname, Ortsname, Straßenname, Hausnummer, Kinderzahl, Einkommen auszulisten. Das Anwenderprogramm wird an das Ein/Ausgabesystem der Datenbank melden: Hole Datei Mitarbeiter, Name, Vorname, Ortsname, Straßenname, Hausnummer, Kinderzahl, Einkommen. Das Ein/Ausgabesystem würde dann diese Felder aus allen Datensätzen der Datei liefern.
- Segmentzugriff heißt die zweite Methode (in der Codasyl-Terminologie "Subschemamethode"). Hier werden mehrere Felder zu Segmenten zusammengefaßt. Ein Segment ist dann die kleinste von einem Anwenderprogramm adressierbare Einheit. Es ist möglich, für jedes Anwenderprogramm, ein eigenes Segment zu spezifizieren. In bezug auf den oben dargestellten Datensatzaufbau sei ein Segment als "Anschrift" definiert. Der Aufruf "Hole Mitarbeiterdatei, Anschrift" würde die unter dem Segment mit dem Namen "Anschrift" definierten Datenfelder Name, Vorname, Ortsname, Straßenname, Hausnummer aus allen Datensätzen der Datei anliefern.
Bei beiden Methoden müssen möglicherweise der ganze Satz oder sogar mehrere Sätze, nämlich der physische Block in den Puffer eingelesen werden. Die verschiedenen Datenbanksysteme benutzen eine von diesen zwei Methoden, jedes aber in unterschiedlicher Art und Weise. Eine Übersicht über die Eigenschaften der verschiedenen Datenbanksysteme zeigt die Tabelle.
Zugriffsschutz bei Segmentmethode
Der Segmentzugriff erleichtert die Einrichtung eines Zugangskontrollsystems wesentlich. Für jedes Anwenderprogramm wird ein eigenes Segment definiert und nur Benutzer des zugehörigen Anwenderprogramms haben Zugriff zu den so spezifizierten Daten. Systeme mit programmexterner Segment- oder Feldbeschreibung entziehen sich zudem der Manipulation durch den Anwenderprogrammierer. Die Systeme, die mit Feldzugriff arbeiten, müssen zwecks Zugangskontrolle eigene Referenztafeln aufbauen. In System 2000 ist programmexterne Definition nicht möglich. Insofern müssen for den Zugriffsschutz völlig andere Methoden gewählt werden. Weder System 2000 noch eine Codasyl-Datenbank erlauben eine Zugriffshierarchie wie IMS. Die Konversion und das Hinzufügen von Feldern ohne daß reorganisiert werden muß, ist charakteristisch für Sesam und Adabas.
Pointer über Pointer
Über die Fähigkeit, zu einzelnen Feldern direkt zuzugreifen (Feldunabhängigkeit) verfügt nur IMS nicht. Dort muß stets der ganze Satz geholt werden.
Ein weiterer Aspekt ist die Unabhängigkeit der Anwenderprogramme von den Verknüpfungsstrukturen einer Datenbank. Die Codasylsysteme, IMS und Total, erlauben einen hohen Grad von Strukturierung durch die Verwendung von Pointern. Pointersysteme bedeuten aber eine Limitierung bezüglich des Zugriffes in willkürlichen Kombinationen. Wenn bei Adabas und Sesam Strukturierung erwünscht ist, so ist diese durch Pointer anf der logischen Ebene realisierbar. Diese Pointer werden dann als Daten behandelt und spielen in bezug auf die Datenunabhängigkeit keine Rolle.
Für welche Vorteile man sich entscheidet und welche Nachteile man in Kauf nimmt, entscheidet letzten Endes die eingehende Systemanalyse im Anwendungsfall.