Auch renomntierte Datenbanksysteme werden immer häufiger für das Betriebssystem Unix "scharfgemacht". Bereits jetzt sind mehr als ein Dutzend DB-Systeme unter diesem Operating-System und seinen Derivaten lauffähig. Damit ergibt sich für den User die Qual der Wahl, denn nicht alle Datenbankprogramme eignen sich optimal für Unix-Anwendungen - Unterschiede in der Datenstruktur und im Ablaufverhalten bestimmen das Marktbild und somit auch die optimale Kaufentscheidung. Im Rahmen eines internen Projektes überprüfte das Team der PCS Peripherie Computer Systeme GmbH, München, verschiedene Angebote. Die Verantwortliche für Datenbanksysteme in der PCS-Entwicklungsabteitung, Erika Mühlmann, gibt in ihrem Beitrag einen Überblick über DB-Konzepte und analysiert die Eigenschaften von drei Unix-fähigen DB-Systemen.

Seit rund 20 Jahren beschäftigen sich die Informatiker mit der Theorie der Datenbanken, und auch praktische Erfahrungen mit kommerziellen Datenbanksystemen liegen seit mehr als 10 Jahren vor.

Über die Basiskonzepte der Theorie der Datenbanken herrscht weitgehend Konsens, und auch die praktische Ausprägung dieser Konzepte läßt Übereinstimmung erkennen. Am deutlichsten zeigt sich dies in der Tatsache, daß sich internationale Standardisierungs- und Normungsgremien mit Datenbanken und Teilaspekten dieser Thematik befassen. (Ansi, Iso, Codasyl;(1), (2))

Historisch haben sich die ersten Datenbanksysteme aus mehr oder weniger ausgeklügelten Dateiverwaltungssystemen mit sequentiellem und indexsequentiellem Zugriff (ISAM) entwickelt. Hieraus sind hierarchische Datenbanksysteme entstanden.

In einem hierarchischen DB-System bilden die Datensammlungen auf der logischen Ebene Knoten und Unterbäume eines oder mehrerer Bäume (deshalb hierarchisch). Die strenge hierarchische Anordnung in Bäumen (einfach zusammenhängende Grafen, im Gegensatz zum allgemeinen "Netzwerk" ) bedingt, daß Knoten, die unabhängig von ihren Beziehungen zu anderen Knoten bearbeitet werden sollen, redundant gespeichert werden müssen. Hierdurch entstehen Probleme für die Konsistenz des Systems.

Die Effizienz eines solchen Systems ist stark abhängig von der

richtigen Datendefinition (Datendesign). Schon zum Zeitpunkt des Datenbankentwurfs müssen möglichst alle Datenapplikationen bekannt sein, um im Hinblick hierauf ein günstiges Datendesign zu wählen. Die Flexibilität eines solchen Systems - bei Einhaltung der ursprünglichen Effizienzkriterien - ist im allgemeinen gering.

Viele der klassischen Datenbanksysteme entsprechen dem hierarchischen Datenmodell so zum Beispiel IMS (3)

Im Gegensatz zum hierarchischen Modell bilden die Daten in einer Netzwerk-Datenbank Knoten eines Netzwerks; Beziehungen zwischen Daten werden über gerichtete Kanten im Netz dargestellt. Die Richtung der Kanten unterliegt hierbei keinerlei Einschränkungen. Anfragen erfordern ein Navigieren durch die Datenbank und damit Kenntnis der Pfade und insebesondere der Einstiegspunkte. Anfragen komplexerer Art oder Anfragen mit nicht unmittelbar ersichtlichen Einstiegspunkt verursachen ein unter Umständen langwieriges

"Abklappern" der Pfade. Auch hier hängt die Effizienz der speziellen Datenbank und gegebenenfalls Kenntnis der zukünftigen Applikationswünsche ab.

Das am meisten verbreitete Netzwerk-Datenmodell ist das Codasyl-Modell (4), dem zum Beispiel das Siemens-System UDS (5) folgt.

Relationale Datenbanken basieren auf dem Relationenmodell für Daten. Grundlage des Relationenmodells ist der mathematische Begriff der mengentheoretischen Relation (6). Neben dem unproblematischen, theoretischen Hintergrund besitzt das Relationenmodell gegenüber den beiden oben beschriebenen Datenmodellen den Vorteil, daß Beziehungen zwischen "entities" ebenfalls als "entities" darstellbar sind. (Unter "entity" versteht man salopp formuliert jedes konkrete oder abstrakte wohlunterscheidbare Ding). Das führt zu einem einfachen, auch für den Benutzer leicht verständlichen Datenmodell. Für Operationen auf der Datenbank ist eine Kenntnis von Einstiegspunkten oder Pfaden erforderlich, da Datenmanipulationen auf alle Relationen in uniformer Weise anwendbar sind. Im Gegensatz zu den beiden anderen Datenmodellen erfolgt die Verarbeitung nicht satzweise, sondern Mengen-/Relationen-orientiert. Das hat zur Folge, daß die Struktur der Datenbank geändert werden kann, ohne daß Programme oder Anfragen geändert werden müßten.

Dieses Modell wird heute wegen seiner straffen mathematischen Basis und der Allgemeinheit des Ansatzes im Allgemeinen favorisiert. Allerdings ist der relationale Ansatz eben wegen seiner Allgemeinheit unter Umständen weit von den Problemen der konkreten Welt entfernt, und bei der heute gängigen Rechnerstruktur sind gewisse Ineffizienzen nicht auszuschließen.

Beispiele für "relationale Datenbanksysteme" sind Ingres, Pascal-R, QBE oder System R (7, 8, 9, 10). Derartige Systeme sind in jüngster Zeit in zunehmendem Maße auch für Rechner der mittleren Leistungsklasse verfügbar, zum Beispiel Unify, Logix, Lidas, Oracle, Progress, Informix und viele mehr. (11, 12, Kap.2)

Die Entwicklung ist, speziell auf theoretischem Gebiet, mit den relationalen Datenbanken keineswegs zum Stillstand gekommen: Als Übergang von einer reinen lexikonartigen Wissensanhäufung (unkorrelierten Fakten) zu einem semantisch strukturierten Wissen ist das Konzeptionelle Schema zu betrachten. Während sich die verschiedenen oben vorgestellten Datenmodelle mit der Darstellung und Organisation von Informationsinhalten befassen, liefert das Konzeptionelle Schema Möglichkeiten, globale Gesetzmäßigkeiten dieser Informationsinhalte zu

beschreiben. Es berücksichtigt sowohl die Art und mögliche Ausprägung von "entities" wie auch Regeln welche Aktionen für welche "entities classes" zulässig sind. Mit dem Konzeptionellen Schema können sowohl statische wie auch - je nach verwendetem Ansatz - dynamische Aspekte beschrieben werden.

Das Konzeptionelle Schema läßt sich bequem schichten- oder schalenmäßig organisieren, wobei die Grundschicht zum Beispiel aus den Basisregeln der Logik und Arithmetik bestehen könnte; weitere Ebenen würden dann stufenweise eine immer detaillierte Beschreibung des betrachteten Weltausschnitts liefern. Im allgemeinen stellen formale Methoden das geeignete Ausdrucksmittel zur Definition eines Konzeptionellen Schemas dar.

Als weiteren Schritt von einten reinen Faktensammlung zu Wissen mit semantischer Tiefenstruktur sind Wissensbasierte Systeme anzusehen. Wissensdarstellung, Wissenserwerb und "logisches" Schlußfolgern, oft zusammengefaßt unter dem Begriff des "knowledge engineering", bilden die zentralen Themen der Künstlichen Intelligenz und finden im Bereich der Expertensysteme besonders intensive Anwendung. Obwohl die ersten Expertensysteme schon vor gut zehn Jahren beschrieben wurden, scheint sich die Grundidee erst in letzter Zeit mit entsprechender Breitenwirkung durchzusetzen. Besonders die "5th Generation Computer Conferenced" (1982) der Japaner mit ihren durchaus aggressiven Zukunftsprognosen hat der informationsverarbeitenden Wissenschaft und Industrie der westlichen Hemisphäre erst die Notwendigkeit des Einsatzes von Künstlicher Intelligenz zum Erhalt der technischen Wettbewerbsfähigkeit in hochinnovativen Bereichen vor Augen geführt.

Speziell im universitären Bereich in den USA ist Unix (19, 20, 21, 22, 23) seit mehr als zehn Jahren die Lingua Franca auf dem Gebiet der Betriebssysteme. Seit der Verfügbarkeit von Unix auf 32-Bit-Rechnern und der Konsolidierung des Systems in Unix Version (1980) ist verstärkt ein Übergang auch nach Europa und ein Eindringen in den kommerziellen Bereich zu verzeichnen. Mit dem Übergang von Unix an AT&T und der Unix-Version System V Release 2 (Anfang 1984) ist eine boomartige Verbreitung von Unix-Systemen und Lookalikes zu erwarten.

Tabelle 1 gibt eine knappe Übersicht über mehr als ein Dutzend Datenbanksysteme wie auch Außenseiter - möglicherweise Eintagsfliegen - und erhebt keinerlei Anspruch auf Vollständigkeit. Die Kandidaten erscheinen in alphabetischer Reihenfolge.

Interessant erscheint für diese Kurzübersicht

- das zugrunde liegende Datenmodell (mit Ausnahme von MDBS III sind alle relational),

- das Vorhandensein einer möglicherweise standardisierten Datenbankanfragesprache (Query language) wie SQL,

- die Möglichkeit, über die Datenbank zu kommunizieren; in diesem Bereich sind Menüs, Masken and Spezialeditoren und dergleichen zu finden,

- die Möglichkeit, das Ergebnis von Datenbankanfragen in wohlformatierten Reports darzustellen

- Programmiersprachenanschlüsse

- der Bereich der Anlagen, auf denen das Produkt abläufig ist (die Aussagen der Hersteller und dabei zum Teil recht pauschal wie any/some Unix system(s))

- der Preis, (soweit eruierbar).

Anfang 1982 stellte die PCS GmbH ihren ersten Muniz-Rechner vor. Das Systemhieß damals QU68000 - ein zusammenfassendes Akronym für die wixhtigsten Grundprinzipien des Systems:

- Q-Bus der Firma Digital Equipment

- Unix, das Betriebsystem der Bell Laboratories

- MC 68000, der 16/32-Bit-Prozessor von Motorola.

Das System ist in den vergangenen zwei Jahren laufend erweitert und verbessert worden.

Munix, das Unix auf dem QU 68000 ist die einzige Original AT&T-Unix-Portierung auf dem europäischen Kontinent. Mit der Freigabe von Munix V.2 im Herbst 1984 steht, bis auf Geringfügigkeiten, der volle Leistungsumfang vom AT&T System V Release 2 zur Verfügung. Als Prozessor wird heute der MC 68010 verwedet.

1983 wurde in den USA Cadmus Inc. gegründet. Cadmus Inc. ist für die Hardware Lizenznehmer von PCS, wobei PCS an dem US-Unternehmen beteiligt ist.

Beide Firmen bieten für die Cadmus 9000 Serie das Datenbanksystem Unify Version 3.1 an. Während die Cadmus Inc. darüber hinaus noch Progress anbietet, hat PCS einen Vertrag mit Oracle abgeschlossen, um dieses Datenbanksystem bis Ende 1984/Anfang 1985 auf das System Cadmus 9000 portieren zu lassen.

Diese drei Datenbanksysteme sollen im folgenden einhergehender behandelt werden.

Alle drei Systeme besitzen eine hohe Attraktivität, sind in ihrer Benutzeroberfläche und Zielrichtung aber so verschieden, daß sie sich nur in begrenzten Bereichen Konkurrenz machen.

Als Beurteilung für eine Wertung der einzelnen Systeme liegen zugrunde:

- die benötigten Ressourcen in Form von Platten- und Speicherbedarf sowie CPU-Zeit

- der Funktionsumfang

- die Benutzerfreundlichkeit aus der Sicht des Endbenutzers sowie des

Datenbankherstellers (Administrators)

- die Robustheit der Systeme gegenüber Hardwareausfällen und Fehlbedienung

- die favoriesierten Anwendungsbereiche

Progress ist ein umfangmäßig kleines, aber dennoch komplettes Datenbanksystem. Auf der Platte werden im Minimum zirka 500 KB, im Hauptspeicher zirka 250 KB belegt. Ein "leeres" Data Dictionary, der Anfang jeder Applikation, belegt und 12 KB.

Da die,Tests nur an einem Demonstrationsystem durchgeführt wurden, das die Definiton und den Eintrag von Daten nich zuließ, können

keine Aussagen zur Performance gemacht werden.

Der ganze Bereich der Datenbankaktionen, also Administration, Datemanipulation, Queries und Reportformatierung wird mit einer einheitlichen Schnittstelle - der Sprache Progress - abgehandelt. Anschlüsse an weitere Programmiersprachen, etwa zur Erstellung von Benutzerfunktionen für die nicht abgedeckten Bereiche stehen nicht zur Verfügung. Das schränkt die allgemeine Brauchbarkeit des Systems in einigen Punkten ein.

Progress ist eine relativ einfache, halb prozedurale halb nonprozedurale Sprache, die leicht zu erlernen ist. Es ist aber für den Bereich der Queries eine reinrassige nonprozedurale Sprache wie etwa SQL die adäquate Parallele zum relationalen Datenmodell, so daß hier ein gewisser Konsistenzsprung zu verzeichnen ist.

Komponenten zur Menü-, Programm- oder Benutzerverwaltung, also weite Bereiche der Datenbankadministration, müssen explizit programmiert werden. Applikationen, die eine straffe Benutzerfunktion notwendig erscheinen lassen, erfordern hier im Gegensatz etwa zu Unify, doch einigen zusätzlichen Progammieraufwand.

Dem Endbenutzer bleibt dieses natürlich verborgen. Ihm wird Progress wohl am meisten durch die Präsentation des Ergebnisses von Queries am Bildschirm imponieren. Besonders bei geschachtelten Queries bietet Progress von den drei Datenbanksystemen die beste Darstellung, die auch einem unerfahrenen Benutzer die Verknüpfung der Datensätze untereinander sehr deutlich macht. Der starke Einsatz von Funktionstasten macht das System allerdings etwas gewöhnungsbedürftig.

Mit den vorhandenen "Lock"- und Transaktionsmechanismen ist es möglich, robuste und sichere Benutzerprogramme zu erstellen. Explizite Mechanismen zum Transaction-Logging stehen nicht zur Verfügung, jedoch macht der Einsatz von Beforeimages das System weitgehend robust gegenüber Systemausfällen.

Im Prinzip deckt Progress den ganzen Bereich der Datenbankapplikationen ab, in wieweit es allerdings für große Anvendungen mit der entsprechenden Last geeignet ist kann aufgrund fehlender Performancemessungen und mangelnder Herstellerangaben hier nicht entschieden werden.

Oracle zahlt zu den relationalen Datenbanksystemen. Ursprünglich auf den großen Mainframes beheimatet, ist das System heute auch auf Mikros wie zum Beispiel dem IBM-PC ohne Funktionsreduzierung zu finden. Diese breite Verfügbarkeit von Oracle spricht zwar für einen hohen implementierungstechnischen Standard, bürdet jedoch dem Mirko-Anwender zwar lange, aber noch erträgliche Antwortzeiten auf.

In verstärktem Maße wird derzeit Oracle nun auch auf Unix-Systeme portiert. Da die Portierung auf die Serie 9000 noch nicht abgeschlossen ist, können keine Aussagen zur Performance und Resourcebelegung getroffen werden, jedoch ist heute schon ersichtlich, daß der Platten- und Speicherbedarf deutlich höher als bei Progress oder Unify liegen dürfte. Bei deutlich höherem Komfort und Ausfallsicherheit des Systems ist das weiter nicht verwunderlich. Da über Oracle ausreichend Literatur zu finden ist, es gibt sogar eine eigene Benutzerorganiation, soll dieses System hier nicht weiter behandelt werden.

Unify benötigt auf den Cadmus Systemen mindestens zirka 3 MB Plattenspeicher und zirka 250 KB Hauptspeicher, zusätzlich zu dem vom Betriebssystem belegten. Das Unify System ist in eine ganze Reihe separat ablauffähiger Programme aufgeteilt die entweder völlig separat oder als Hierarchie von Prozessoren gestartet werden. Abhängig hiervon und von den Aktivitäten der einzelnen Benutzer, kann durch weiteren Speicherausbau die Performance erheblich gesteigert werden, da dann ein Swapping beziehungsweise Paging entfällt.

Verschiedene Applikationen können, müssen aber nicht in getrennten Anwendungsdatenbanken stehen. Hier fallen nochmals mindestens 100 KB für das jeweilige Data Dictionary an.

Messungen an synthetischen, das heißt, etwas wirklichkeitsfremden Beispielen haben ergeben, daß bei Unify Zugriffe auf die Datenbank relativ unabhängig von der Länge des betrachteten Satzes sind. Im konstruierten Fall dauert das Messenladen von 1000 Sätzen, die nur aus einem vierstelligen Key bestanden, aus einer ASCII-Datei 172 CPU-Sekunden (CPUs); dasselbe für Sätze, die noch zusätzlich einen 256 Byte String enthielten; 178 CPUs. Unter Verwendung von SQL dauerte das Selektieren von 1000 Sätzen im ersten Fall 33, im zweiten 53 CPUs, das Löschen jeweils zirka 290 CPUs. Ein natural join, der aus 1000 000 Sätzen 1000 auswählte, dauerte 240 CPUs.

Funktionsmäßig deckt Unify das gesamte Spektrum der zur Datenbankadministration und der zur Nutzung durch den Endbenutzer erforderlichen Komponenten ab. Unify kennt als Objekte, die der Pflege durch den Administrator unterliegen, Schemas (Datendefinition), Masken, Menüs, Programme, Benutzerkennungen und -gruppen sowie Maßnahmen zum Tunen und Sichern der Datenbank. Der Endbenutzer wird normalerweise nur noch mit Menüs, Masken, Queries, Reportscripts und applikationsspezifischen Programmen in Berührung kommen, wobei zur Benutzung der Datenbank nicht einnal die Kenntnis der Anfragesprache SQL oder des Reportgenerators RPT erforderlich ist.

Ein anderes Kapitel ist die Benutzeroberfläche von Unify aus der Sicht des Datenbankadministrators. Alle Unify Komponenten zur Datenbankadministration sind stark bildschirmorientiert, was eine langwierige Eingabe nach sich zieht. Der erfahrene Unix-Anwender greift natürlich sofort zum Mittel der Automation durch "shell-scripts". Da alle Komponenten zur Administration einem Muster folgen, ist der Aufwand nicht allzu hoch.

Unify bietet die Möglichkeit, Standardkomponenten wie zum Beispiel das Programm "Enter" zur Maskenverarbeitung, über einen einfachen Mechanismus an spezielle Applikationswünsche anzupassen. Im Prinzip eine geniale Sache, die viel Programmieraufwand erspart. Für spezielle Applikationprogramme steht ein C-oder auch Cobol-Anschluß zur Verfügung. Die C-Library zum Beispiel besteht aus zirka 100 Funktionen.

Von einigen Problemen, die das System für den Administrator bereit hält, bemerkt der Endbenutzer erfreulicherweise nichts. Eine straffe Führung über Menüs und Masken machen das System nahezu narrensicher. Bedauerlich ist lediglich, daß die Prompts für die Menüs nicht frei wählbar sind (zum Beispiel in der Landessprache), sondern offensichtlich irgendwo fest im Unify-Quellcode "verdrahtet" sind. Queries und Reports sind ebenfalls über Masken parametriesierbar, so daß ein Endbenutzer sich nicht notwendigerweise mit SQL und RPT auseinandersetzen muß. Man kann sich auch vorstellen, daß ein Benutzer, dem die Grundlagen der Mengentheorie nicht vertraut sind, Schwierigkeiten hat eine komplizierte Query in SQL semantisch korrekt zu formulieren.

Gegenüber Fehlbedienungen und gleichzeitigen Zugriffen auf die Datenbank über die Standardbedienschnittstellen ist Unify äußerst robust. Da die von PCS gelieferte Unify-Version kein Transaction-Logging und keine Utility zum Nachfahren einer Logdatei enthält, kann das gleiche bei Hardwareausfällen oder Systemabstürzen nicht zugesichert werden. An dieser Stelle sei allerdings vermerkt, daß Unify bei PCS seit einem Jahr auf den Entwicklungsrechnern in Einsatz ist. Auf diesem Rechner wird auch die jeweils neueste Betriebssystemsversion entwickelt und getestet, so daß Systemabstürze an der Tagesordnung sind. Die Datenbank wurde dabei kein einziges Mal in Mitleidenschaft gezogen, lediglich die letzte Aktion war manchmal nicht durchgeführt. Inkonsistenzen traten keine auf. Da Unify aus vielen Einzelprogrammen besteht, die relativ unabhängig voneinander sind, ist es möglich, einen Endbenutzer oder Endkunden einer Applikation mit einem Minimal-Unify zu beliefern. Das bietet den Vorteil, daß zum einen wenig Platten- und gegebenenfalls auch Hauptspeicher benötigt wird, zum anderen sind kritische Komponenten - zum Beispiel Schemamaintenance zur Datendefinition - nicht im Repertoir des Endbenutzers, so daß auch hier nichts "passieren" kann. Unify ist zum einen ein ideales Werkzeug zum Rapid-prototyping, zum anderen bestens geeignet, Datenbankapplikationen ohne das große Geschüz der ganzen Datenbankorganisation zu installieren.

Wie wird die Entwicklung auf dem Gebiet der Datenbank weitergehen? Läßt man die semantische Seite in Form der eingangs aufgezeigten Gebiete Konzeptionelles Schema und wissensbasierte Systeme außer Betracht, werden sicher Fragen der Benutzeroberfläche und Benutzerfreundlichkeit im Vordergrund stehen.

Die Zeit ist praktisch überreif, Datenbanksysteme um grafische Ein/ Ausgabe-Systeme zu erweitern. Grafikpakete zum Anschluß an Datenbanksysteme sind zwar schon auf dem Markt, doch handelt es sich hier um separate Lösungen, die dann der Datenbank aufgepfropft werden, zum anderen befassen sich diese Systeme lediglich mit der Ausgabeseite. Die semantische Dichtheit grafischer Darstellungen auch bei der Eingabe wird bis jetzt nur im akademischen Vorfeld genutzt (24). Hier hat das Gebiet der Datenbanken sicher noch reichlich Entwicklungsmöglichkeiten.

Ein weiterer wichtiger Aspekt ist die Benutzerfreundlichkeit. Der Endbenutzer einer Datenbank ist heute noch weitgehend auf einen Spezialisten, normalerweise den Administrator, angewiesen, wenn es um so kritische Bereiche wie die Datendefinition geht. Über die zu verwendenden Attribute wie zum Beispiel Personal nummern, Namen oder Adressen und ihren syntaktischen Aufbau herrscht beim Endbenutzer Klarheit; normalerweise werden sie von ihm ja vorgegeben. Probleme hat der Laie lediglich bei der Datenaggregation. Hier ist das Terrain, zum Beispiel mit den Coddschen Normalformen theoretisch bereitssgut fundiert, ein Vorschlag zur Datenaggregation gut automatisch erstellbar (14). Auf diesem Gebiet wird bei PCS bereits an einem Frontend zu Datenbanksystemen gearbeitet.