Netzwerkdatenbankmodell

Das Netzwerkdatenbankmodell wurde von der Data Base Task Group (DBTG) des Programming Language Committee (später COBOL Committee) der Conference on Data Systems Language (CODASYL) vorgeschlagen, der Organisation, die auch für die Definition der Programmiersprache COBOL verantwortlich war. Es ist auch unter den Namen „CODASYL Datenbankmodell“ oder „DBTG Datenbankmodell“ bekannt und entsprechend stark von Cobol beeinflusst. Der fertige DBTG-Bericht wurde 1971, etwa zur gleichen Zeit wie die ersten Veröffentlichungen über das relationale Datenbankmodell, vorgestellt. Er enthielt Vorschläge für drei verschiedene Datenbanksprachen: Eine Schema Data Description Language (Schema-Datenbeschreibungssprache), eine Subschema Data Description Language (Subschema-Datenbeschreibungssprache) und eine Data Manipulation Language (Datenmanipulationssprache).

Das Netzwerk-Modell fordert keine strenge Hierarchie und kann deswegen auch m:n-Beziehungen abbilden, d. h. ein Datensatz kann mehrere Vorgänger haben. Auch können mehrere Datensätze an oberster Stelle stehen. Es existieren meist unterschiedliche Suchwege, um zu einem bestimmten Datensatz zu kommen. Man kann es als eine Verallgemeinerung des hierarchischen Datenbankmodells sehen.

Datenbankaufbau

Netzwerkdatenbankmodell

Datenbanksätze

Eine Netzwerkdatenbank besteht aus Datensätzen (Record), welche aus verschiedenen Feldern (Data Item) bestehen. Ein Feld hat einen Namen und einen Wert. Jeder Satz beschreibt eine Person, ein Objekt oder ein Ereignis (event).

Ein Netzwerk-Datenbankmanagementsystem (DBMS) bearbeitet Datensätze. Ein Satz, oder genauer die Ausprägung eines Satzes (record occurrence) kann als Ganzes in die Datenbank gespeichert (STORE), verändert (MODIFY) und wieder gelöscht (DELETE) werden.

Ein CODASYL-Datensatz hat in der Regel eine innere Struktur. Felder können zu Gruppenfeldern zusammengefasst werden und Gruppenfelder können nicht nur aus Einzelfeldern, sondern wiederum aus Gruppenfeldern bestehen.

Ein CODASYL-Satz kann sogenannte „Tabellen“ enthalten, das sind mehrere Werte, die unter einem Namen verwaltet werden. Die Einzelwerte oder Elemente der Tabelle werden durch Subscripte adressiert, z. B. Kunde.Mayer.Monatsumsatz[0]. Es sind auch doppelte Feldnamen erlaubt, sofern sie in unterschiedlichen Sätzen sind. Sie müssen dann qualifiziert angesprochen werden, z. B. Kunde.Name und Lieferant.Name.

Sätze einer Satzart (record type), die einen eindeutigen Namen haben muss, haben die gleiche interne Struktur. Eine Satzart ist also eine allgemeine Beschreibung vieler Datensätze, sprich Ausprägungen einer Satzart (record occurrence). Im Datenbankschema werden alle Satzarten definiert.

Datenbankschlüssel

Sätze innerhalb einer Datenbank können in allen Feldern gleiche Werte haben. Dagegen ist der Datenbankschlüssel (Data Base Key = DBK) ein interner eindeutiger Schlüssel, der beim erstmaligen Speichern des Satzes in der Datenbank vergeben wird.

Dataset

Beziehungen zwischen Sätzen werden durch eine spezielle, Datenset (oder einfach Set) genannte, Konstruktion bestimmt. Im einfachsten Fall besteht jedes Set aus zwei verschiedenen Satzarten. Ein Daten-Set besteht aus genau einem Mitglied der ersten Satzart, dem Owner des Daten-Set. Jedes Set kann keinen (leeres Set-Auftreten), einen, oder mehrere Sätze der zweiten Satzart haben, die Member des Daten-Set. Diese haben eine definierte Sortierfolge. Die eindeutig benannte Set-Art (set type) beschreibt alle Mitglieder der gleichen Beziehung.

Die beiden Strukturtypen, die also das Netzwerkdatenbankmodell beschreiben, sind:

• die Satzart (record type); mehrere Sätze einer Satzart nennt man record occurrence
• Set-Art (set type); mehrere Ausprägungen einer Set-Art nennt man set occurrence

Alle Satzarten und alle Set-Arten müssen im Datenbankschema beschrieben sein.

Das Schema einer Datenbank wird grafisch als Bachman-Diagramm dargestellt, in dem jede Satzart als Rechteck (mit Satzart und Attributnamen) und jede Set-Art als Pfeil vom Owner zum Member dargestellt ist.

Datenmanipulation

Eine Datenmanipulationssprache besteht aus Updatefunktionen- und aus Abfragefunktionen. Zu den Update-Funktionen gehört das Speichern neuer Sätze der Satzart, das Ändern existierender Sätze, das Löschen existierender Sätze, das Einfügen existierender Sätze einer Satzart als Member eines Data Set und das Entfernen einer Satzart aus einem Data Set.

Ein Anwendungsprogramm benötigt gewöhnlich nur Teile einer Datenbank oder eines Datenbankschemas. Deshalb definiert man Subschemas für Programme oder Programmgruppen, die diese Teile der Datenbank manipulieren möchten.

Datenbeschreibungssprache

Die „Record“-Klausel

Zur Beschreibung einer Satzart gehören ein eindeutiger Datensatzname, die Beschreibung der Attribute aller Datenfelder und die Angabe des sog. „Location Mode“.

• RECORD NAME IS <record name>
• DATA ITEM-Subklausel: Sie definiert Einzelfelder, Gruppenfelder und „Tabellen“
• LOCATION MODE-Subklausel: Sie definiert die Regel, nach der den Datensätzen (record occurrences) Datenbankschlüssel (DBK) zugewiesen werden sollen, nämlich SYSTEM, CALC USING [data item, ...], VIA <set name> SET oder DIRECT. SYSTEM heißt, es ist dem System freigestellt, die schnellste sich gerade anbietende Methode zu wählen. CALC ist eine Abkürzung für calculation; gemeint ist, dass der DBK aus den aneinandergereihten Werten der in der USING-Klausel genannten Einzelfelder berechnet werden soll. Mit VIA... soll erreicht werden, dass der Member-Satz möglichst in der Nähe des Owners gespeichert wird. DIRECT bedeutet, dass der Anwendungsprogrammierer den Data Base Key selbst berechnen soll.

Die „Set“-Klausel

Zur Definition eines Data Set gehören vor allem ein eindeutiger Name des Set-Typs, der Name der Owner-Satzart, der Name der Membersatzart und die gewünschte Sortierfolge.

• SET NAME IS [set name]
• OWNER IS [record name]
• MEMBER IS [record name]
• ORDER IS {FIRST / LAST / NEXT / PRIOR / SORTED BY ...}.

Zusätzliche Optionen können sein:

• SET IS PRIOR PROCESSABLE. Der Set soll auch Pointer zum vorherigen Membersatz enthalten.
• SET IS LINKED TO OWNER. Jedes Member soll zusätzlich einen direkten Pointer zum Owner erhalten.
• INSERTION IS {AUTOMATIC / MANUAL}. Bei AUTOMATIC soll jeder der Datenbank zugefügte Satz dieser Satzart automatisch Mitglied des Set werden. MANUAL besagt, dass die Sätze nicht automatisch, sondern nur bei Bedarf vom Programm mit dem INSERT-Befehl eingefügt werden sollen.
• RETENTION IS {MANDATORY / OPTIONAL}. OPTIONAL bedeutet, dass die Mitgliedschaft im Set auch ohne Löschen des Satzes (MANDATORY) vom Anwendungsprogramm aus erfolgen kann.

Die Set-Definition ist wie man sieht eigentlich streng hierarchisch, ein Owner kann viele Member haben. Wie steht es da mit der m:n-Beziehung aus, die das Netzwerk erst ausmacht? Am Beispiel einer Stücklistenstruktur weiß man, dass ein Teil (Gruppe) aus vielen verschiedenen Teilen (Gruppen) bestehen kann. Die Stückliste ist alleine betrachtet eine Baumstruktur. Teile können aber auch in vielen Gruppen verwendet werden, für die man einen Teileverwendungsnachweis haben möchte. Eine zweite Baumstruktur dafür wäre von erheblicher Redundanz. Man verwendet deshalb Struktur- oder Kettsätze, die sich einerseits in der Stücklistenkette und andererseits in der Verwendungskette des Owners Teilestamms befinden. Damit ist die m:n-Beziehung realisiert.

Datenmanipulationssprache

Die Anwendungsumgebung (UWA)

UWA steht für User Working Area (Anwendungsumgebung). Jedem gleichzeitig laufenden Programm wird eine UWA bereitgestellt. Sie enthält Currency-Indikatoren genannte Pointer als Referenzen auf Datensätze der Datenbank (record occurrences). Sie enthält auch Muster oder Formatvorlagen (templates) der unterschiedlichen Datensatztypen. Des Weiteren eine Fehlerstatus (Error status) genannte Variable die das Ergebnis des letzten DML-Befehls aufzeigt.

Currency Indikatoren (aktuelle Zeiger)

Das Konzept der Datenmanipulation in einer CODASYL-Datenbank beruht auf Currency Indikatoren (currency indicators) und Navigation. Currency Indikatoren sind Variablen deren Wert Datenbankschlüssel (Data Base Keys) im internen Format sind.

• Es gibt nur einen Datensatz (record occurrence) der Datenbank, der aktuell der RUN-UNIT für Verarbeitung zur Verfügung steht, er heißt current of run-unit. „run-unit“ ist in CODASYL-Terminologie ein Anwendungsprogramm. Wenn ein Datensatz der Datenbank ausgewählt (mit FIND) oder gespeichert wurde (mit STORE), wurde er der derzeitige Datensatz des Programms (current record of run-unit).
• Die Abfolge der Datensätze, welche aktuelle (derzeitige) Datensätze eines Programms waren, heißt Navigation (navigation).
• Der Datensatz, egal welche Satzart (record type), auf den zuletzt zugegriffen wurde, ist der derzeitige des Programms („current of run-unit“).
• Der Satz einer bestimmten Satzart, auf den zuletzt zugegriffen wurde, ist der derzeitige der Satzart. Beispiel: der letzte der Satzart KUNDE ist der derzeitige der Satzart KUNDE.
• Entsprechend gibt es auch eine derzeitige Set-Art („current of set type“). Für jede Set-Art (bestehend aus Owner-Satzart und Member-Satzart) ist der Satz, auf den zuletzt zugegriffen wurde, der derzeitige des Set, gleichgültig ob es ein Owner oder ein Member war.

Die User working Area enthält also:

• einen derzeitigen Indikator für die Run-Unit
• einen derzeitigen Indikator für jede Satzart
• einen derzeitigen Indikator für jede Set-Art, der entweder auf den Owner oder auf den Member verweist, je nachdem, auf wen zuletzt zugegriffen wurde.

Currency Indikatoren werden bei jeder Ausführung einer DML-Operation verändert. Beim Zugriff auf einen bestimmten Datensatz wird er current record of run-unit, current record of its record type und current record of all sets, in denen er entweder als Owner oder als Member vorkommt.

Record Templates (Vorlagen für Satzformate)

Vorlagen sind „leere“ Bereiche im Format der jeweiligen Satzart. Sie können über Satzname.Feldname (oder nur Feldname, wenn er eindeutig ist) vom Anwendungsprogramm angesprochen werden.

Ein GET Befehl liest den Datensatz in die entsprechende Vorlage und kann dort vom Programm verarbeitet werden. Die Speicherung erfolgt auch, nachdem sie vom Programm beschickt wurde, über die Vorlage. Ein STORE-Befehl kopiert die Vorlage in die Datenbank.

Error Status (Fehlerstatus)

Nach der Ausführung eines DML-Befehls enthält die Variable Error_Status in der UWA den Wert 0, wenn die Operation erfolgreich war und einen Wert ungleich 0, wenn ein Fehler aufgetreten ist. Werte ungleich 0 sind nicht immer Fehler, z. B. ist es kein Fehler, sondern nur ein Hinweis, wenn beim Durchlesen eines Sets das Ende des Sets erreicht wurde.

Datensätze lesen

Das Lesen eines Datensatzes erfolgt in zwei Schritten:

1. Durch einen FIND-Befehl wird der gewünschte Satz current of run-unit. Der FIND ändert nur den Currency-Indikator, nicht das Template in der UWA.
2. Mit einem speziellen GET-Befehl wird der Satz in den Arbeitsbereich UWA übertragen. Der GET-Befehl überträgt immer den current of run-unit in den entsprechenden Template-Bereich. Das Format des Befehls ist: GET [record name].

Der FIND-Befehl hat verschiedene Varianten, die alle die allgemeine Aufgabe haben, einen bestimmten Datensatz (record occurrence) zum current record der Run-Unit, der Satzart und aller Sets, in denen er vorkommt, zu machen. Varianten des FIND-Befehls sind z. B.:

• Finden eines Datensatzes mit dem Datenbankschlüssel,
• Finden eines Satzes mit dem Wert seines CALC-Schlüssels,
• Nacheinander finden aller Sätze eines Sets
• Finden aller Sätze eines Sets, die in einem bestimmten Feld einen bestimmten Wert haben.
• Finden des Owners eines Sets.

Datensätze hinzufügen und verändern

Hierfür gibt es verschiedene Befehle: Speichern (STORE) eines neuen Datensatzes, Einfügen (INSERT) eines Datensatzes in einen Set, Entfernen (REMOVE) eines Datensatzes aus einem Set, Löschen (DELETE) des derzeitigen Satzes (current record) und Verändern (MODIFY) des derzeitigen Satzes. Alle Befehle haben viele verschiedene Optionen, deren Einsatz stark von der jeweiligen Datenbankstruktur (Schema) abhängt und im Einzelfall sehr komplex werden kann.

Um dem Anwendungsprogrammierer in der Praxis das Leben zu erleichtern haben sich deshalb zwischen (z. B. COBOL-) Programm und Datenbank geschaltete I/O-Module bewährt.

Das Netzwerkdatenbankmodell heute

Nach der Vorstellung beider Datenbankmodelle (Relational vs. Netzwerk) Anfang der 1970er Jahre gab es schon zwanzig Jahre lang hocheffiziente Netzwerkdatenbanksysteme auf mittleren und großen Mainframes für höchste Transaktionsraten, bis relationale Datenbanksysteme bezüglich der Performance einigermaßen gleichziehen konnten. Nicht ohne Grund ist das hierarchische Datenbanksystem von IBM von Ende der 1960er noch heute bei vielen IBM-Kunden im Einsatz. Auch Abfragesprachen für Ad-hoc-Anfragen standen auf Netzwerksystemen zur Verfügung, beispielsweise QLP/1100 von Sperry Rand. Heute wird das Netzwerkdatenbankmodell hauptsächlich auf Großrechnern eingesetzt.

Bekannte Vertreter des Netzwerkdatenbankmodells sind UDS (Universal Datenbank System) von Siemens, DMS (Database Management System) von Sperry Univac. Mischformen zwischen Relationalen Datenbanken und Netzwerkdatenbanken wurden entwickelt – z. B. von Sperry Univac (RDBMS Relational Database Management System) und Siemens (UDS/SQL), mit der Absicht, die Vorteile beider Modelle zu verbinden.

Seit den 1990er Jahren wird das Netzwerkdatenbankmodell vom relationalen Datenbankmodell mehr und mehr verdrängt. Mit der Idee des semantischen Webs gewinnt das Netzwerkdatenbankmodell wieder mehr an Bedeutung. Mittlerweile existieren eine Reihe von Graphdatenbanken, die man als moderne Nachfolger der Netzwerkdatenbanken bezeichnen könnte. Ein wesentlicher Unterschied ist allerdings die Möglichkeit der dynamischen Schemaänderung.

Siehe auch

→ Hauptartikel: Datenbankmodell

• Datenbank
• Charles Bachman

Weblinks

• The User as Navigator