Wissen > 1. Klassische Datenbanken > Erfolgsgeschichte klassischer Datenbanken > Warum DBTG nicht gewinnen konnte
Eine der ersten Abfragesprachen im Bereich der klassischen Datenbanken war DBTG. Sie wurde im April 1971 vom Codasyl Programming Language Committee [1] veröffentlicht. Sie war eine allgemeine Abfragesprache für das Netzwerkmodell.
Prinzipiell bestand das DBTG Modell aus sechs Elementen:
Wertbereich
ein Wertbereich ist eine Zusammenfassung aller möglichen bzw. zugelassenen Werte
Feld (engl. Data Item)
ein Feld kann in zwei unterschiedlichen Formen existieren:
atomar
arithmetisch
String
data base key (DBK)
implementor defined
aggregiert
zur Abbildung von Datenbankstrukturen, Feld mit Unterstruktur
vektor (1:n)
allgemeine Wiederholungsgruppe (0:*)
Recordtyp
ohne Primärschlüsselkonzept; Objektidentität unabhängig von Werten
Set-Typ
binäre Beziehung zwischen zwei Records
storage Area (später auch realm genannt)
benannte Speichereinheit
Database (Schema)
Bachmann Diagramm (1:n)
Wir wollen nun anhand eines kleinen Beispiels DBTG näher betrachten. Eine kleine Firma besteht aus zwei Abteilungen (Departments), dem jeweils die einzelnen Mitarbeiter (Employees) zugeordnet sind.
Zur Abbildung dieser Information verwendet man sowohl Records als auch Sets: ein Department ist ein Record, welcher z.B. ein aggregiertes Feld beinhaltet, denn eine Abteilung kann schliesslich mehrere Mitarbeiter beinhalten; ein Mitarbeiter ist ein Recordtyp und speichert die Informationen über einen einzelnen Mitarbeiter. Die Beziehung zwischen dem Departmen und den Angestellten heisst "DEPTEMP" und ist ein Set.
In Abbildung 1 ist das Beispiel graphisch veranschaulicht.
Auf den ersten Blick kann man vier unterschiedliche Objekte erkennen:
 |
 |
 |
 |
| Pfeil
verbindet einzelne Recordtypen zu einer Liste bzw. zu einem Kreis |
Record-Typ DEPT
repräsentiert ein "Department"; prinzipiell wie eine Tabelle |
Record-Typ EMP
repräsentiert einen "Employee"; prinzipiell wie eine Tabelle |
Set-Typ DEPTEMP
Relation "Department" <=> "Employee"; Abbildung der Beziehung, dass die "Employees" dem "Department" zugeordnet sind, bzw. in der Liste "danach" stehen |
Die Definitionsweise einer Netzwerkdatenbank mit DBTG zeigt nicht nur die Unterschiede zum heute verwendeten SQL, sondern deutet gleichzeitig auch die typischen Probleme von CODASYL DBTG auf: die Daten werden allgemein nicht zusammen mit deren Typ-Definition gespeichert, sondern die Form der Datenbank und deren Layout muss in der jeweiligen Applikation integriert werden; ein typisches Beispiel für ein solches System ist auch das DBF-Dateiformat. Dies macht nicht nur eine Veränderung im Datenbanklayout erheblich komplizierter als in heutigen Datenbanken, sondern es macht es auch relativ unmöglich, mehrere unterschiedliche Applikationen gleichzeitig mit dem selben Datenstamm arbeiten zu lassen; eine Datensicherheit hinsichtlich Zugriffskontrolle fehlt ebenso wie eine Form von Recovery Control.
Ein weiteres Manko von DBTG ist seine komplizierte Syntax, welche im folgenden Beispiel veranschaulicht werden soll; es wird hierbei ein Schema "Bibliothek" angelegt, welches einen Record "Buch" und "Autoren" beinhaltet:
Schema name is Bibliothek Record name is Buchduplicates are not allowed for InvNrInvNr type is character 6Titel type is character 30VerlagName type is character 20VerlagOrt type is character 20Jahr type is numeric integerRecord name is Autorenautor type is character 30Um Relationen zwischen zwei Records abzubilden kann man sich zum Beispiel der folgenden Definitionsweise von "Verbindungen" (Set-Typen) bedienen:
Set name is BuchAutorenowner is Buchnumber is Autorenorder is firstinsertion is automaticretention is mandatoryDie Definition besagt prinzipiell, dass ein "Buch", mehreren Autoren zugewiesen werden kann, bzw. dass ein Buch eine Liste von Autoren beinhaltet - die Definition desselbigen ist im Grunde genommen Interpretationssache.
Die starre Definitionsweise des DBTG verursachte allerdings ein gravierendes Flexibilitätsproblem: bei Änderungen in der Datenbank mussten sämtliche Abfragen neu formuliert werden, die in irgendeiner Weise mit den veränderten Strukturen verbunden sind. Dies ist mit ein Grund, weshalb DBTG auf Dauer nicht bestehen konnte - Ted Codd's relationaler Ansatz war deutlich simpler und dennoch mindestens gleich performant.
Doch nicht alleine die Definition der Datenbankschemata war unnötig kompliziert; das System erschwerte auch alltägliche Suchabfragen und Datenänderungen. Was dem SQL-Programmierer heute sein SELECT ist, waren damals die Befehle "FETCH", "FIND", "GET", "ACCEPT", "SET"; was heute "UPDATE" und "INSERT" ist, war damals "STORE", "ERASE", "MODIFY", "CONNECT", "DISCONNECT", "INSERT" und "REMOVE". Es existierte damals allerdings bereits ein "READY" und "FINISH" Befehl für Transaktionsmodi und Daten-Locking via die Befehle "KEEP" und "FREE".
Um einen Eintrag in der Datenbank ändern zu können, musste er allerdings erst umständlich in der gesamten Struktur gesucht werden:
GETMove S4 to SNo IN SFind S RecordGet Svergleichbar in SQL geschrieben, bedeutet dieses Kommando:
SELECT * FROM S WHERE SNo=S4 Das Kommando
MODIFYFind S occurence for S4Get S; StatusAdd 10 to Status IN SModify S; Statusbedeutet übersetzt in SQL:
UPDATE S SET Status=Status+10 WHERE SNo=S4
All diese Probleme und Komplikationen fügten sich nahtlos in die Schwierigkeiten mit anderen bereits vergangenen Abfragesprachen ein und führten letztlich dazu, dass SQL seinen Siegeszug begann.