Loading AI tools
Aus Wikipedia, der freien Enzyklopädie
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.
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.
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.
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:
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.
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.
Zur Beschreibung einer Satzart gehören ein eindeutiger Datensatzname, die Beschreibung der Attribute aller Datenfelder und die Angabe des sog. „Location Mode“.
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.
Zusätzliche Optionen können sein:
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.
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.
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.
Die User working Area enthält also:
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.
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.
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.
Das Lesen eines Datensatzes erfolgt in zwei Schritten:
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.:
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.
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.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.