ING_DB

WEGA/contrib/ingres/dbs/tmp/ing_Vortrag

@@ -0,0 +1,311 @@
+Datenbank-Entwicklung und Anwendung unter UNIX in der DDR
+
+Sehr geehrte Damen und Herren !
+
+Auf der Einladung zur heutigen Veranstaltung finden Sie das
+Thema "Datenbank-Entwicklung und Anwendung unter UNIX in der
+DDR" und als Vortragende zwei Namen: Wenzlaff und Froehlich.
+Mein  Name ist Froehlich, ich komme vom ZKI (Langform:
+Zentralinstitut fuer Kybernetik und Informationsprozess der
+DDR-Akademie der  Wissenschaften), und ich bin bei dem gan-
+zen der Leidtragende, weil ich, nachdem ich aus einem Urlaub
+zurueckkam, mit der Aufgabe konfrontiert wurde, einen Vor-
+trag zu halten, der einzig auf meinen Kollegen Joerg Wenz-
+laff zugeschnitten ist.
+Nun gut, Herr Wenzlaff kann heute leider nicht unter uns
+sein, und ich werde, mit einigen Arabesken, das erzaehlen,
+was er zu berichten vorhatte.
+
+Bevor ich zum eigentlichen Thema komme, kann ich es mir
+nicht verkneifen, einen Ausflug in die Geschichte der
+Bechaeftigung mit UNIX in der DDR zu unternehmen, zumindest
+in dem Rahmen, wie mein Institut daran beteiligt ist.
+
+Auf der Suche nach einer Basis fuer ein zeitgemaesses Soft-
+ware Engineering Environment, bzw. nach einem reorganisa-
+tionsfreien Filesystem mit einer fast unbeschraenkten Zahl
+vor allem kleiner Files, haben Kollegen aus dem LfA (Leit-
+zentrum fuer Anwendungsforschung, der heutige Veranstalter)
+und dem ZKI mit der Untersuchung einer UNIX-Quelle begonnen,
+die in abenteuerlicher Form in unsere Haende geraten war.
+Das war Mitte 1981, als Zielrechner haben wir nur die damals
+noch ueberwiegend im Stapelbetrieb genutzten Robotron-
+Rechner 1040 und 1055 gesehen. Diese Anlagen sind den IBM-
+Machinen 360/50 bzw. 370/140 vergleichbar. Die UNIX-Quelle
+war ein Version 6 UNIX, so aus dem Jahre 1976/77, genauer
+gesagt, Kern-Quellen und Quellen zu C-Compiler, Assembler,
+Verbinder und eine fruehe Version des relationalen DB-Sys-
+tems INGRES aus Berkeley. Diese Quellen waren mit 'dd
+conv=ebcdic' in ein festes Format konvertiert worden, wobei
+leider auch alle Kleinbuchstaben in Grossbuchstaben
+und alle besseren Sonderzeichen in durch unsere Drucker
+nicht behandelbare Zeichen verwandelt wurden.
+Alle Informationen zu UNIX und C mussten wir aus dem 78er
+Bell Systems Technical Journal gewinnen, mehr Literatur war
+uns nicht zugaenglich, insbesonerde keine Literatur zu den
+pdp11, den Wirtsrechnern des Systems.
+Um es abzukuerzen, Ergebnis dieser ersten Untersuchungen
+war die PSU (Programmier-stuetzende Umgebung) des LfA fuer
+oben genannte Robotron Rechner, einsetzbar im Stapelbetrieb,
+unter TSO und CMS, ein heute nur noch leicht eingeschraenk-
+tes Mehnutzer-UNIX. Die erste Version der PSU lief schon
+im Sommer 1982. Die Arbeiten zur PSU wurden im wesentlichen
+vom LfA getragen, einige Hochschulen, insbesondere die TU
+KMStadt haben zeitweilig wertvolle Leistungen beigetragen,
+das ZKI hat nur in der allerersten Phase mitgewirkt.
+Wir konnten naemlich ab 1982 stundenweise auf einem Rechner,
+der der pdp11/34 ziemlich nahe kam, erste Erfahrungen mit
+einem Version 6 UNIX machen, das in binary Form in unsere
+Haende geraten war. Unsere Bemuehungen zielten auf einen
+selbststaendig vorzunehmenden Umstieg auf UNIX Version 7 ab,
+d.h., wir wollten zuerst einen V7-C-Compiler schaffen und
+dann schrittweise den V6-Kern aufbohren. Diese Arbeiten
+fanden einen natuerlichen Abschluss, als uns eine vollstaen-
+dige V7-Quelle in die Haende geriet, das war im Fruehjahr
+1983. Diese Quelle wurde Ausgangspunkt fuer UNIX Aktivitae-
+ten bei Robotron, dort stellte man fuer einen pdp11/34
+aehnlichen Rechner eigener Produktion in der Folge das
+V7 kompatible System MUTOS (Multi User Time-sharing
+Operating System) her, spaeter auch fuer IBM/XT vergleich-
+bare PC's. Robotron arbeitete, auch was die Dokumentationen
+anbelangt, eng mit der TH Ilmenau zusammen.
+Ich moechte hier gleich einschieben, dass der Kontakt
+zwischen allen mit UNIX befassten Gruppen in der DDR immer
+sehr eng und freundschaftlich war, unabhaengig ob sie in
+Hochschulen, der Akademie oder der Industrie (Robotron
+und EAW-Berlin) angesiedelt waren.
+Zu diesem Zeitpunkt, 1983, begannen auch im EAW Arbeiten zu
+einem auf dem Zilog Prozessor Z8001 basierenden Mikro-
+rechner, fuer den zuerst ein V7, spaeter System III kompa-
+tibles Betriebssystem, genannt WEGA, entwickelt wurde.
+Diesem Rechner, mit seinem UNIX System, ist es zu danken,
+dass es in der DDR nicht nur UNIX-Entwickler und Adaptierer,
+sondern auch eine ernstzunehmende Anwendergruppe gibt.
+Wobei, wenn ich mir so den bisherigen Verlauf unserer Histo-
+rie ansehe, sicher die Mehrzahl lieber IBM-PC's genommen
+haette, wenn sie sie haetten nur kaufen koennen.
+Ich moechte die Uebernahme von  Amdahl's UTS durch die
+TU Karl-Marx-Stadt, unter dem Namen VMX seit einigen Jahren
+auf einigen Anlagen aehnlich IBM 370/..., hier wenigstens
+kurz erwaehnen, ebenso die Aktivitaeten meines Institutes
+zu einer nebenlaeufigen Entwicklung zum P8000 vom EAW,
+gemeinsam mit dem EAW betrieben (von dort die Hardware, von
+uns ein V7 UNIX, genannt MUTOS 8000). Letzteres ist nur
+dadurch interessant, das unsere Zielhardware ueber 256 KByte
+RAM und als externem Speicher ueber drei 8"-Floppylaufwerke
+mit insgesamt weniger als 750 kByte verfuegte. Und noch
+etwas, was charakteristisch fuer die Arbeitsbedingungen
+aller unserer Gruppen war und eigentlich noch ist: Fuer
+den vollstaendigen Transport (Kern, C-System, Assembler
+u.s.w.) stand uns dreimal woechentlich fuer vier Stunden als
+Crosssystem die schon erwaehnte pdp11/34 aehnliche Anlage
+mit, wenn alle vier Wechselplatten-Laufwerke zufaellig mal
+in Ordnung waren, 10 MByte externem Speicher und vier Termi-
+nals zur Verfuegung.
+Genug der Horrormeldungen, ich koennte noch viel hinzufue-
+gen. Am uebelsten waren die Bedingungen fuer lange Zeit wohl
+im LfA.
+Nun aber zum eigentlichen Thema:
+Wie Sie sich vorstellen koennen, waren die, sagen wir mal
+UNIX-Kenner, mit Transporten, Adaptionen, Compilerbau und
+aehnlichem beschaeftigt. Wo sollte aber die Anwender-Soft-
+ware entstehen, die vor allem die WEGA-Nutzer forderten?
+Das EAW ist auf dieser Strecke nicht untaetig gewesen, es
+blieb aber das Problem, dass unsere Kunden unbedingt Word-
+star, DBase und aehnliches wollten, weil sie in der Mehr-
+zahl aus der CPM-Welt kamen. Und gleichzeitig gab es immer
+wieder den Wunsch, ein Paket, wenn es denn schon unter UNIX
+sein musste, dann wenigstens auf all den vefuegbaren UNIX-
+Systemen gleichermassen einsetzen zu koennen.
+Was Datenbanken anbelangt, so gibt es hier bei uns inzwi-
+schen eine Reihe von Sytemen, alle an Vorbilder angelehnt,
+aber nur ein System, das obigem Kriterium wirklich genuegt:
+Es laeuft tatsachlich bei ungefaehr 200 Anwendern, und zwar
+auf tatsaechlich allen uns bekannten UNIX-Systemen und
+Rechnern in der DDR und, oh Schande, sogar unter MS/DOS -
+die Zahl der MS/DOS Anwender kenne ich aber nicht.
+Das System nennt sich ING_DB oder DABA16 oder INDES, abhaen-
+gig davon, von wem man es bezieht, ihm liegt aber ein, im
+ZKI von Herrn Wenzlaff gewarteter Qellenstand, zu Grunde.
+
+Herr Wenzlaff kam von der Staatsbibliothek unter den Linden
+ins ZKI, nachdem die dort mit der Entwicklung eines
+Datenbanksystems fuer Bibliothekszwecke beschaeftigte
+Arbeitsgruppe auseinandergelaufen war. Seine letzte Arbeit
+in der Stabi war die Wiederingangsetzung der Ingres-Version,
+von der ich oben schon kurz gesprochen hatte.
+Seine erste Aufgabe im ZKI war, dieses oder ein aehnliches
+System fuer den spassigen Rechner von oben, an dem inzwi-
+schen eine furchtbar laute Festplatte hing, bereit zu stel-
+len. Er hat aber seine Ziel von Anfang an sehr viel weiter
+abgesteckt und dann auch systematisch verfolgt. Der Anteil
+userer Gruppe an diesen  Arbeiten beschraenkt sich auf
+gelegentliche Diskussionen und eine gewisse Mehrarbeit von
+unserer Seite, weil er, als Arbeitskraft, nach dem ersten
+Jahr stets fuer andere als Datenbankvorhaben eingeplant war.
+
+Nun werde ich im wesentlichen den  Aufzeichnungen von Herrn
+Wenzlaff folgen:
+
+Mitte 1986 begann die Entwicklung von ING_DB als einhetli-
+chem Datenbanksystem fuer UNIX-Systeme auf unterschiedlichen
+Rechnerarchitekturen.
+Der Schwerpunkt der Arbeiten lag nicht auf dem Entwurf eines
+neuen Datenbanksystems sondern vielmehr auf der zu
+erreichenden Portabilitaet.
+Als Ausgangspunkt bot sich die Uebernahme der INGES-Konzepte
+an.
+Fuer die Datenbanksysteme INFORMIX, UNIFY oder ORACLE gab
+es in der DDR z.T. sogar Quellen, die aber leider nicht of-
+fen zugaenglich waren.
+Das Datenbanksystem INGRES wird heute von INGRES Inc.,
+(ehemals RTI = Relational Technology Inc.) entwickelt und
+vertrieben, es beruht auf einem Forschungsprojekt der
+University of California Berkeley / USA, das 1973 von den
+Professoren Stonebreaker und Wong initiiert wurde.
+1976 trat Professor Rowe dem Projekt bei.
+Das Konzept und die Implementierungen wurden stets sehr
+offen und genau publiziert.
+Das System besteht in seinem Kern aus einer Abfragesprache
+QUEL (Querry Language), die auch in Programmiersprachen
+eingebettet werden kann. (Embedded QUEL = EQUEL) und einer
+Reihe von Hilfsprogrammen fuer den System- bzw. Datenbank-
+administrator.
+Als Entwicklungsrechner wurde anfaenglich eine pdp11/40,
+spaeter eine pdp11/45 und schliesslich eine VAX11 verwendet.
+Die pdp11/40 hat fuer heutige Programmierer eine interessan-
+te Eigenschaft, sie unterstuetzt nur Programme deren
+Programmcode und -daten plus Stack nicht mehr als 64 KByte
+gross ist.
+Ein Datenbanksystem musste also, neben der 3-Schichtenarchi-
+tektur, funktional dekomponiert werden, um auf solchen
+Rechnern implementiert werden zu koennen.
+UNIX ist zwar ein multi-user und multi-task System, die Ver-
+staendigung zwischen einzelnen Prozessen ist jedoch bei den
+aelteren UNIX-Systemen schwach entwickelt. Die einzige bei
+V7 nutzbare Kommunikationsmoeglichkeit sind die pipes. Muss
+man sie nutzen, sind klar definierte Schnittstellen zwischen
+den Funktionen erforderlich.
+Das Datenbanksystem, genauer die Anfregesprache QUEL, be-
+steht aus mindestens zwei Prozessen, dem  Terminal- und dem
+Datenbankprozess.
+Diese Zweiteilung ist notwendig, da der Terminalprozess im
+Verzeichnis des Nutzers und mit dessen Zugriffsberechti-
+gungen arbeitet, waehrend der Datenbankprozess im Verzeich-
+nis der Datenbank mit der Berechtigung des Datenbanksystems
+arbeitet.
+Der "Datenbankprozess" zerfaellt in die Funktionen:
+  - Anfrageuebersetzung
+  - Anfragemodifizierung
+  - Anfrageoptimierung
+  - Anfragebearbeitung (Anfrageinterpreter)
+  - Dienstprogramme
+Jede Funktion kann in einen seperaten Prozess gelegt oder
+mit einem anderen kombiniert werden, so dass der Datenbank-
+prozess ein bis fuenf Prozesse und das Gesamtsystem
+zwischen zwei und sechs Prozessen benoetigt.
+Temporaer werden weitere Prozesse erzeugt, die aber hier
+nicht weiter behandelt werden sollen.
+Es ist verstaendlich, dass aus der Sicht des Betriebssystems
+die Abarbeitung einer Anfrage eine erhebliche Ressourcen-
+belastung darstellt und demzufolge auch eine gewisse Zeit
+dauert.
+Die eingebettete Version der Anfragesprache aendert an
+diesen Verhaeltnissen wenig, da nur der Terminalprozess
+durch das Datenbankprogramm ersetzt wird und alle Anfragen
+an den eben geschilderten Datenbankprozess weitergereicht
+werden.
+Soviel zu dem INGRES, wie es aus Berkeley ueberkommen ist.
+Nun zu den eigenen Aktivitaeten:
+1)
+Das Datenbanksystem ist so entwickelt worden, das es in Ab-
+haengigkeit von der im Betriebssystem zulaessigen Programm-
+groesse generiert werden kann.
+2)
+Alle Dienstprogramme, deren Leistungsumfang im Vergleich zum
+Orginal erheblich erweitert wurde, laufen in 64 KByte, bzw.
+sind Folgen von solchen Programmen.
+3)
+Wie schon erwaehnt laeuft das nun als ING_DB bezeichnete
+Produkt auf allen in der DDR bekannten Rechnerarchitekturen
+unter allen moeglichen UNIX Versionen. Eine Aufzaehlung
+moechte ich mir hier ersparen, aber WEGA und PSU sind dabei.
+4)
+Als erweiterte Funktionalitaet, die aber noch nicht wesent-
+lich ueber das vom UniversitaetsINGRES gebotene hinausgeht,
+wird geboten:
+  - Reorganisation als eigenstaendige Funktion
+  - Die Groesse einer Relation wird nur durch das Betriebs-
+    system beschraenkt
+  - Eine um den Faktor vier schnellere Sortierfunktion
+  - Die Seitengroesse (ein Tupel muss in eine Seite passen)
+    kann Datenbank-spezifisch festgelegt werden
+  - Die max. Domaenenzahl wurde erweitert
+  - Der Komplex Zugriffsschutz, Integritaeten, komplexe
+    Sichten (alles unter dem  Stichwort Anfragemodifizierung
+    zusammengefasst) wurde voellig ueberarbeitet. Er ist nun
+    in sich stimmig und, wenn auch noch nicht perfekt, so,
+    dass die Anwender keine Klagen erheben.
+  - Einige ueble Luecken bei paralleler Nutzung des Systems
+    wurden beseitigt.
+5)
+Ganz neu hinzugekommen sind:
+  - Ein Reportsystem, das auch Datenbank-unabhaengig nutzbar
+    ist.
+  - Ein Transaktionsbegriff wurde intern durchgaengig ein-
+    gebracht. Das fuehrte zu einem Transaktionsmanager, der
+    jedoch (noch) nicht in die Anfragesprache hochgereicht
+    wurde. D.h. dort gilt: eine Anfrage entspricht einer
+    Transaktion.
+6)
+Nun zur wesentlichen Erweiterung, um derentwillen der ganze
+Vortrag eigentlich gehalten wird:
+Eine Datenbanksprache, AMX genannt ist hinzugekommen. Sie
+zerfaellt in Datenbank-spezifische Teile und reinen C-Code,
+sie kennt den Transaktionsbegriff und gestattet rekursives
+Arbeiten, d.h. z.B. Stuecklistenprobleme sind mit ihr behan-
+delbar.
+Zu dieser Sprache gibt es einen Compiler, realisiert als
+C-Precompiler, der Programme dieser Sprache in C-Programme
+uebersetzt, die nach entsprechenden Compile- und Link-
+laeufen als ein Prozess abgearbeitet werden koennen.
+D.h. die Metadatenarbeit wird zur Compile-time erledigt,
+die DB-Anfragen werden nicht mehr interpretativ, sondern
+direkt in ein C-Programm transformiert, abgearbeitet.
+Im Prinzip fuehrt dieser Ansatz zu einem C-Programm, wie
+es ein C-ISAM Anwender fuer sein Problem schreiben wuerde.
+Die Abarbeitungszeiten sind vergleichbar, der Aufwand des
+AMX-Programmierers fuer die Datenbankseite des Problems
+duerften erheblich geringer sein.
+Die Abarbeitung von AMX-Programmen ist natuerlich an die
+Datenbankstrukturen gebunden, wie sie zur Uebersetzungszeit
+vorgelegen haben.
+
+Was fehlt bei ING_DB ?
+ - Die bunte Oberflaeche (von Wedekind mal als Gruenzeug
+   bezeichnet), aber ernsthaft: Maskengeneratoren, Querry
+   by Example und eine SQL-Schnittstelle werden gewuenscht.
+ - Eine Ausweitung auf wirklich verteilte Datenbanksysteme.
+
+Aber als Erlaeuterung der bisherigen Strategie:
+ - Wir hatten harte Projekte, die meist auch mit Datenpro-
+   blematik zu tun haben, aber eben nur unter anderem, im
+   Blick und wollten den Programmierern die Muehen der
+   Basiszugriffsmethoden ersparen.
+ - Die desolate Hardwaresituation in der DDR hat bisher eine
+   eine Entscheidung der Art, "von nun an nur noch fuer
+   32-Bit Architekturen mit virtuellem Speicher" von
+   vornherein verboten.
+ - Falls es genuegend Interessenten gaebe, wuerden wir die
+   bisherigen Beschraenkungen fallen lassen und erheblich
+   ausbauen, z.B. in Richtung einer X-Window Anbindung.
+   Und das dann auch mit mehr Kraeften als nur Herrn
+   Wenzlaff, dessen beachtliche Leistung ich hier
+   auch noch einmal wuerdigen moechte, denn er hat nicht
+   nur das erledigt, wovon ich bisher gesprochen habe,
+   er hatte auch die Auslieferung, das ging bis zum
+   Schnueren der Paeckchen mit den  Disketten, und die
+   Anwenderbetreuung am Halse.
+
+Ich danke Ihnen fuer Ihre Geduld und stehe fuer Ihre Fragen
+zur Verfuegung.