Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

27.05.1983 - 

Codasyl- und Relationenmodell im Wettstreit:

Navigieren in DBs bleibt zentrale Tätigkeit

Als ein Werkzeug für Fachleute klassifiziert Dr. Stephan Braun von der Hochschule der Bundeswehr, Neubiberg, die Datenmanipulationssprachen, wie sie vorzugsweise bei Codasyl-Datenbanken auftreten. Sie setzten vor allem eine genaue Kenntnis der Datenstrukturen voraus. Für Laien hingegen eignen sich Kommunikationssprachen, die bei relationalen Datenbanken häufig verwendet werden. Diese Sprachen sind nützlich für kurze DB-Anfragen und setzen keine weitreichenden Detailkenntnisse voraus. Braun erklärt in seinem folgenden Beitrag die Unterschiede.

Datenbanken sind eine zunehmend wichtiger werdende Form der Datenhaltung innerhalb von Informationssystemen. Sie entstanden aus dem Wunsch, die technischen Beschränkungen reiner Dateiensysteme zu überwinden, insbesondere in flexibler Weise zu Datensätzen verschiedener Satzarten zugreifen zu können. Eine Datenbank im technischen Sinne ist demnach eine Sammlung von Datensätzen verschiedener Satzarten mit der Möglichkeit

(1) zu Datensätzen einer Satzart außer über den Schlüssel auch über andere Datenfelder zugreifen zu können;

(2) Kopplungen zwischen Datensätzen verschiedener Satzarten oder auch innerhalb derselben Satzart einfach realisieren zu können.

Im Verlauf der Entwicklung (seit zirka 1965) entstanden verschiedene "Datenbanksysteme"; ein Datenbanksystem ist dabei ein (großes) Programmsystem zur Verwaltung einer Datenbank. Datenstrukturen und Zugriffsoperationen der ersten Datenbanksysteme wurden ad hoc entworfen und zeigten daher eine erhebliche Vielfalt; insbesondere waren sie stark von der physischen Speicherung der Datensätze abhängig.

Der Wunsch nach Vereinheitlichung führte zur Entwicklung von "Datenbankmodellen"; ein Datenbankmodell ist dabei eine Sammlung von Regeln über den Aufbau eines Datenbanksystems. Derzeit existieren zwei solche Datenbankmodelle, das Codasyl-Modell der "Conference on Data Systems Languages" und das mit dem Namen E. F. Codd verbundene Relationenmodell.

Die in der Praxis verwendeten Datenbanksysteme richten sich im wesentlichen nach diesen Modellen, wobei sowohl Codasyl-Systeme (zum Beispiel UDS von Siemens) wie auch relationale Systeme (System R von IBM oder Adabas/Natural der Software AG) wie auch Mischformen (beispielsweise EDMS von Control Data) vorkommen.

Eine wichtige Ausnahme bildet das historisch ältere, weitverbreitete System IMS von IBM. Es ist als Eigenentwicklung der Firma keinem der beiden heute gängigen Datenbankmodelle zuzuordnen; gelegentlich wird IMS einem "hierarchischen" Datenbankmodell zugeordnet.

Netzartige Strukturen erleichtern Implementierung

Das Codasyl-Modell arbeitet mit Datensätzen - verschiedener Satzarten und baut daraus Datenstrukturen mit Hilfe des zentralen Konstrukts der "Kette" (set occurrence) auf. Eine Kette besteht aus einem "Ankersatz" (owner), an den ein oder mehrere "Gliedsätze" (member) angehängt sind. Diese Gliedsätze können einerseits wiederum Anker für andere Ketten sein, andererseits zu mehreren Ketten gehören, wobei gefordert wird

(a) Ankersatzart und Gliedsatzart müssen verschieden sein (meist noch, daß sie Gliedsätze alle von derselben Art sind, wobei diese Forderung im Codasyl-Standard von 1978 fallengelassen wurde.

(b) Falls ein Datensatz zu mehreren Ketten gehört, müssen diese Ketten von verschiedenem Typ sein, wobei ein Kettentyp durch (im wesentlichen) Ankersatztyp, Gliedsatztyp und Kettentypname definiert ist.

Es entstehen damit netzartige Datenstrukturen, wobei die beiden Forderungen einerseits für eine gewisse Übersichtlichkeit sorgen und andererseits die Implementierung erleichtern.

Das Relationenmodell arbeitet mit Daten in Form von Tabellen. Eine einzelne Tabelle heißt "Relation" eine Zeile der Tabelle heißt "Tupel" und die Überschrift einer Spalte der Tabelle heißt Attribut. Diese Sprechweisen stammen aus der Mathematik; das Tupel entspricht dem Datensatz, das Attribut dem Datenfeld des Datensatzes, die Relation der Datei. Jede Relation hat ein "Schlüsselattribut, durch dessen Wert ein Tupel eindeutig bestimmt ist. Kopplungen zwischen Tupeln (derselben oder verschiedener Relationen) werden durch "Kopplungsrelationen" ausgedrückt; ein Tupel einer Kopplungsrelation enthält die Schlüsselwerte der gekoppelten Tupel sowie gegebenenfalls noch weitere Informationen.

Eine Datenbanksprache ist eine Programmiersprache zum Bearbeiten einer Datenbank. Datenbanksprachen entstanden aus dem Bedürfnis, Zugriffe zu den relativ komplexen Datenstrukturen einer Datenbank bequem formulieren zu können; die in Sprachen wie Cobol oder PL/I vorhandenen Befehle zum Dateizugriff reichen dafür nicht aus. Es gibt zwei Arten von Datenbanksprachen

a) Datenmanipulationssprachen (Data Manipulation Languages, DML);

(b) Kommunikationssprachen (Query Languages, QL).

DML sind die historisch ältere Form. Eine DML besteht aus einem Bündel von rund zwölf bis 15 Anweisungen zum Datenbankzugriff. Diese Anweisungen bilden keine eigene Programmiersprache, sondern werden ausschließlich innerhalb eines Programms einer höheren Programmiersprache, der sogenannten Wirtssprache (host language), verwendet. Wirtssprache ist meist Cobol ("Cobol-DML ), doch kommen auch andere Wirtssprachen wie PL/I vor. Das Format einer DML-Anweisung ist dem der Wirtssprache angepaßt; für Cobol spezielle Befehlswörter sowie Cobol-gemäße Syntax, für PL/I-Prozeduraufrufe. DML-Anweisungen erledigen ausschließlich Datenbankzugriffe. Sie

- holen Datensätze aus der Datenbank

- speichern neue Datensätze ein,

- modifizieren oder löschen vorhandene Datensätze.

Sämtliche sonstige Verarbeitung dieser Datensätze, insbesondere auch das Aufbauen neu einzuspeichernder Datensätze, ist die Aufgabe der Wirtssprache. Dementsprechend transportieren DML-Anweisungen einen Datensatz auch nur zwischen der (in der Regel auf Hintergrundspeicher gelagerten) Datenbank und einem speziellen Hauptspeicher-Arbeitsbereich "User Work Area" (UWA)- die UWA dient somit als Datenschnittstelle zwischen DML-Anweisungen einerseits und den Anweisungen der Wirtssprache andererseits. DML sind "prozedurale" Sprachen: Für den Zugriff zu Datensätzen der Datenbank muß der Suchvorgang (der Zugriffspfad) genau angegeben werden.

Manipulationssprache navigiert in Datenbank

Kommunikationssprachen sind im Gegensatz zu DML selbständige Programmiersprachen. Sie erledigen sowohl den Datenbankzugriff wie die Verarbeitung der Daten, letzteres allerdings nur in eingeschränktem Maße. Die verschiedenen Kommunikationssprachen unterscheiden sich darin, wieviel an Verarbeitung sie gestatten, wobei als Mindestausstattung das Berechnen von Maximum, Minimum und Durchschnitt numerischer Werte sowie das Zählen von Datensätzen angetroffen wird. Kommunikationssprachen sind in wesentlichen Teilen "nichtprozedural": Es ist nur anzugeben, welche Eigenschaften die gesuchten Datensätze haben sollen; der Suchvorgang selbst wird vom Datenbanksystem erledigt.

Zentrale Tätigkeit einer Datenmanipulationssprache (DML) ist das "Navigieren in der (Codasyl-)Datenbank. Unter DML ist im folgenden die DML gemäß den "Codasyl-Vorschriften, die Codasyl-DML", gemeint. Vom Typ her ist auch die Datenbanksprache DL/I des Datenbanksystems IMS eine DML gemäß der obigen Begriffsbestimmung, enthält aber sehr viele nur ihr eigene Besonderheiten. Die Operationen der Codasyl-DML sind zugeschnitten auf die Datenstrukturen des Codasyl-Modells. Navigieren bedeutet der Zugriff zu verschiedenen Datensätzen mittels zweier Operationen

(a) der Zugriff längs einer Kette, das heißt vom Ankersatz zum ersten Gliedsatz und weiter von Gliedsatz zum jeweils nächsten Gliedsatz, bis hin zum Kettenende,

(b) der Zugriff von einem Gliedsatz zu einem seiner Ankersätze.

Die erste Operation wird sprachlich formuliert als

(1) FIND NEXT datensatzart WITHIN kettentyp, die zweite als

(2) FIND OWNER WITHIN kettentyp.

Durch mehrfaches Anwenden dieser beiden Operationen kann man auf jeden Datensatz der Datenbank zugreifen (ausgenommen Datensätze außerhalb der Kettenstruktur, für die spezielle Zugriffsmöglichkeiten existieren, in der Regel über Hash-Verfahren). Insbesondere lassen sich somit auch Kopplungen zwischen Datensätzen formulieren. Die Formulierungen (1) und (2) enthalten nur Angaben über Satzart und Kettentyp.

Zugriff über Hash-Verfahren

Zum Ausführen der Anweisungen ist zusätzlich Information über den speziellen Datensatz und die spezielle Kette nötig, in der er liegt. Dies wird indirekt über die Aktualitätsinformation (currency information) erreicht: Der während des Navigierens jeweils zuletzt angesprochene Datensatz heißt "aktueller Satz des Programmlaufs" (current of rununit) und die Kette eines bestimmten Kettentyps, in der er liegt (es gibt nur eine), heißt "aktuelle Kette" (current set occurrence).

Anweisung (1) liefert dann den nächsten Datensatz hinter dem current of rununit in der aktuellen Kette des angegebenen Typs, Anweisung (2) den Anker des current of rununit in der aktuellen Kette des angegebenen Typs. Neben diesen Anweisungen gestattet die Codasyl-DML

- das Auffinden eines Datensatzes innerhalb einer Kette über seinen Schlüsselwert oder auch ein anderes Datenfeld:

(:3) FIND datensatzart WITHIN kettentyp USING datenfeld

- das Auffinden über Schlüsselwert mittels Hash-Verfahren, unabhängig von der Kettenstruktur:

(4) FIND ANY datensatzart;

- das Neueinspeichern eines Datensatzes in die Datenbank:

(5) STORE datensatzart

- das Ändern beziehungsweise Löschen eines Datensatzes:

(6) MODIFY datensatzart,

(7) ERASE datensatzart,

wobei bei allen diesen Anweisungen unter Umständen umfangreiche Vorbereitungen notwendig sind (zu formulieren in der Wirtssprache).

Kommunikationssprache SQL

Als Beispiel einer Kommunikationssprache wird im folgenden die Sprache SQL ("Structured Query : Language") des relationalen Datenbanksystems System R gewählt. Gegeben sei eine Relation EMP (Angestellter) mit Attributen

EMPNO Angestellten-Nummer

NAME Name des Angestellten

DNO Abteilungsnummer des Angestellten

JOB Tätigkeit des Angestellten

SAL Gehalt

MGR Angestellten-Nummer des Vorgesetzten

Die Anfrage

(8) "Liefere Name sowie Gehalt aller Programmierer in Abteilung 50" lautet in SQL

(9) SELECT name, sal

FROM emp

WHERE job = 'prog' AND dno = 50

Anweisung (9) zeigt die drei typischen Bestandteile - einer QL-Anweisung

- die durchsuchte Relation (hinter FROM)

- die Auswahlbedingung für die Tupel (hinter WHERE; zusammengesetzte Bedingungen wie hier sind die Regel)

- die Attribute, deren Werte für die gefundenen Tupel zu liefern sind (hinter SELECT; "Zielattribute").

Kopplungen zwischen Tupeln werden formuliert durch Angabe mehrere Relationen hinter FROM: sei neben der Relation EMP eine weitere Relation DEPT (Abteilung) gegeben mit Attributen

DNO Abteilungs-Nummer

DNAME Abteilungs-Name

LOC Ort

Die Anfrage

(10) "Liefere die Namen der Programmierer in München" lautet in SQL

(11) SELECT name

FROM emp, dept

WHERE emp. job = 'prog' AND dept. loc = 'muenchen` AND

emp. dno = dept. dno

wobei die letzte Teilbedingung der Auswahlbedingung die Kopplung ausdrückt. Auch Kopplungen zwischen Tupeln derselben Relation sind möglich, wie das beliebte Beispiel

(12) "Für alle Angestellten, die mehr verdienen als ihr Vorgesetzter, liefere den Namen des Angestellten und den seines Vorgesetzten"

(13) SELECT X.name, Y.name

FROM emp X, emp Y

WHERE X.mgr = Y.empno AND X.sal > Y.sal

zeigt.

SQL gestattet weiterhin unter anderem

- Datenbankänderungen UPDATE, INSERT, DELETE,

- Datenbankdefinition CREATE TABLE, EXPAND TABLE, DROP TABLE, DEFINE VIEW, DROP VIEW,

- Definition von Zugriffspfaden innerhalb einer Relation CREATE IMAGE zwischen zwei Relationen CREATE LINK,

- Transaktionen,

- Datenschutz mit Benutzerberechtigungsprüfung,

- Integritätsbedingungen.