Wissen > 1. Klassische Datenbanken > Historische Entwicklung
Die Entwicklung der Datenbank - im klassischen Sinne - begann eigentlich in den 50er Jahren mit der Erfindung der Festplatte. Seit jeher versuchte man, eine Form von Informationssystem bzw. Datenadministrations-System zu entwickeln. Man begann in den 60er Jahren mit hierarchischen Datenbankkonzepten erste Systeme zu implementieren und IBM war mit seinem IMS (Informations Management System) auch relativ erfolgreich damit (IMS ist selbst heute noch im Produktkatalog von IBM).
Das gröbste Problem damals war, eine Abfragesprache für die Datenmengen zu finden; damals existierten noch keine graphischen Userinterfaces und so war das Primärziel darauf angelegt, die Verwendung von Datenbanken einer völlig neuen Gruppe von Konsumenten - nämlich auch Nichtprogrammierern - zugängig zu machen. Dieses Ziel änderte sich schlagartig mit der Einführung von GUIs in das Vereinfachen von Datenabfragen für die Integration in Programme.
In den Anfängen verwendete man auf der Prädikatenlogik basierende Sprachen und hatte relativ grosse Schwierigkeiten selbst einfache Abfragen zu formulieren; erst als 1970 Ted Codd[1] ein mathematisch sehr fundiertes Dokument veröffentlichte, welches sich mit dem Problem der "Query Language" beschäftigte, wurde das Gebiet von Grund auf revolutioniert: Abfragen, welche zuvor mit der damals im Einsatz befindlichen Sprache CODASYL DBTG noch mehrere A4-Seiten lang gewesen wären, konnten so mit Hilfe relationaler Abfragen als Einzeiler angeschrieben werden.
Zwei Jahre später wurde M. Stonebraker damit beauftragt ein Geographisches Informationssystem (Geo-Query Database) zu implementieren; die Ziele des Projekts verschoben sich allerdings rasch zur Entwicklung einer relationalen Datenbank. Das Resultat dieses Projekts ist heute als INGRES System bekannt und ist einer der Spin-Offs von Firmen wie Ingres, Britton-Lee und Sybase.
Bei der Entwicklung von System R, der ersten relationalen Datenbank von IBM, trafen sehr divergente Kulturen aufeinander: bei der Konzeption und Entwicklung trafen sich Leute wie Vera Watson, Ray Boyce, Morton Astrahan, Pat Selinger, C. Mohan und Dines Bjorner - Leute, wie sie unterschiedlicher fast nicht sein konnten; dennoch schweisste dies das Team zusammen und brachte eine Menge von Dingen hervor, die selbst heute noch de facto Standards in der Industrie darstellen.
Anfangs dachte man, mit Hilfe des fertigen Produkts ein Text-zu-Text Übersetzersystem entwickeln zu können. Deshalb holte man Vera Watson in das Entwicklungsteam: sie war in China geboren, stammte von zwei russischen Elternteilen ab und konnte flüssig russisch sprechen und dem Entwicklungsteam Informationen über ihre Muttersprache vermitteln. Sie arbeitete allerdings auch an graphischen Projekten mit. Sie besass grosses Interesse am Extrembergsteigen und nutzte diverse Möglichkeiten aus, dementsprechende Tourengänge zu unternehmen einer dieser Ausflüge wurde ihr zum Verhängnis und kostete sie das Leben. Angeblich soll sie in eine Gletscherspalte gefallen sein.
C. Mohan[2] ist gebürtiger Inder und arbeitete an der Recovery Routine sowie am presumed abort commit Protokoll.
Pat Selinger[3] arbeitete an SQL precompilation, Query processing uvm.; sie ist heute für die Integration der DB2 Universal Database verantwortlich.
Morton Astrahan war einer der stillen im Team; er mied laute Diskussionen und Streitgespräche, wie sie oft an der Tagesordnung waren, und zog sich lieber in seine Hütte (namens "Serendipity") in den Bergen zurück um dort über die auftretenden Probleme in aller Ruhe nachzudenken; für gewöhnlich kehrte er nach kurzer Zeit mit einer Lösung zurück - sein Trick funktionierte also. Morton war grundsätzlich jemand, der sich nie aufregte und daher sehr kalmierend auf das Team wirkte; er litt unter der Parkinson Krankheit und voranschreitender Arthritis und obwohl er laut seinen Teamkollegen bestimmt oftmals teuflische Schmerzen empfand, liess er es niemals in seinem Arbeitsstil durchscheinen. Er verliess 1981 IBM's Team und starb kurze Zeit darauf.
Stichwort:Obwohl heute relationale Datenbanksysteme (RDBMs) mehr oder weniger als das Mass der Dinge und der Gipfel der Entwicklung klassischer Datenbanken betrachtet werden, ist die Einstellung eigentlich nicht nachhaltig korrekt. Die neuen Systeme, die sich seit den letzten Jahre abzeichnen, wie etwa XML-Datensysteme, sind keine relationalen Datenbankkonzepte sondern entsprechen dem hierarchischen Datenbankmodell; es wird nur oftmals durch Einstatz von SQL als Abfragesprache nicht (an)erkannt sondern einfach als relational abgetan. Dies kennzeichnet gleichzeitig das für die Entwicklungsgeschichte der klassischen Datenbanken urtypische Kurzzeitgedächtnis für technologische Errungenschaften und deren zeitlichen Verlauf: während es schon vor sieben Jahren schwierig war einen exakten Zeitverlauf der Entstehungsgeschichte von SQL aufzutreiben, kommen heute auch wieder ältere und bewährte Technologien zum Einsatz - welche zwar niemals als "alt" und "unbrauchbar" eingestuft wurden, nur in der Praxis einfach nicht mehr verwendet und deshalb "vergessen" wurden.
Wohin der Trend in der Zukunft sich auch wenden mag: es wird nach wie vor nicht sinnvoll sein für jede Form von Applikation eine eigene Datenbank zu entwickeln - gerade deshalb werden relationale Datenbanken vermutlich auch weiterhin einen Grossteil des industriellen Marktanteils ausmachen - nicht zuletzt, da andere Konzepte, wie etwa hierarchische Datenbankmodelle (z.B. IBMs IMS) eben nur auf Mainframe Plattform existieren und in absehbarer Zukunft sicher nicht auf andere Hardwarebasis portiert werden.
Einen wichtigen Aspekt im Fortschritt relationaler Datenbank wird besonders die weitere Entwicklung und Normierung der Abfragesprache SQL ausmachen: schon jetzt versuchen die implementierenden Firmen sich gegenseitig durch diverse proprietäre Befehle und Optionen gegenseitig zu übertreffen, bewirken aber auf diese Weise gleichzeitig eine Bildung unterschiedlicher SQL-Dialekte [5].
Betrachtet man allerdings den Verlauf der Geschichte, der zur heute so weit verbreiteten Abfragesprache SQL führte, ist es nicht weiter verwunderlich, dass sich SQL aufgrund seiner einfachen Struktur gegenüber anderen Produkten wie SEQUEL, SEQUEL/2 und DBTG [6] durchsetzen konnte.