Noch bevor sich die Datenbanktechnik allgemein etablieren konnte, kamen auf sie neue Anforderungen zu, mit denen die heutigen DB-Systeme überfordert sind. Die Einbeziehung der Non-Standard-Anwendungen wird die Datenbanktechnik von Grund auf verändern und die betriebliche Datenverarbeitung der Integration einen Schritt näher bringen. Der Beitrag beschreibt einige Ansätze zur Lösung alter und neuer Probleme. (Teil 2)
Großcomputer-Datenbanksysteme sind gewöhnlich umfassend ausgestattet. Ihre Geschwindigkeit hält sich jedoch in Grenzen und ist allenfalls in Verbindung mit administrativen Programmen befriedigend. Dabei darf aber nicht vergessen werden, daß eine Menge von Funktionen, besonders die der Integritätswahrung, heute noch von den Anwendungsprogrammen wahrgenommen werden, obwohl sie eigentlich Sache des Datenbanksystems sind.
Erhaltung der Integrität ist umfangreiche Aufgabe
Unter Integrität oder Konsistenz versteht man die Richtigkeit der Daten einer Datenbank. Welch eine umfangreiche Aufgabe die Erhaltung der Integrität darstellt, wird an folgenden Aspekten deutlich: Bei Daten, die Tatbestände der Realität darstellen sollen, ist die Übereinstimmung von Daten und Wirklichkeit ein wichtiges Anliegen. Allein mit den Informationen aus der Datenbank ist das Problem nicht zu lösen. Der Nachweis der Richtigkeit läßt sich nur erbringen, wenn man die Daten mit der Realität vergleicht.
Die Frage, ob Daten richtig oder falsch sind, beschränkt sich nicht auf ihre Übereinstimmung mit der Realwelt. Bei vielen Anwendungen werden Tatbestände durch automatisierte Entscheidungen geschaffen oder ihre Zulässigkeit soll mit Hilfe des DBS geprüft werden.
Hier geht es darum, daß bestimmte Normen eingehalten werden. In der betrieblichen Datenverarbeitung ergeben sich solche Normen unter anderem aus dem Zielsystem des Unternehmens. Eine konkrete Norm daraus könnte beispielsweise besagen, daß ein Mitarbeiter nicht mehr als sein Vorgesetzter verdienen dürfe.
Soll die Richtigkeit eines Datums in bezug auf solche normativen Aussagen überprüft werden, dann genügt es nicht, nur ein Datum zu betrachten. Meist läßt sich erst in Zusammenhang mit anderen Daten sagen, ob ein Datum berechtigt ist (im Beispiel das Gehalt des Vorgesetzten).
Datenbanksysteme tragen auch heute schon zur Integrität durch die Möglichkeit bei, aufzunehmende Daten auf ihre Harmonie mit dem definierten Schema zu prüfen. Für jedes Attribut einer Datenbankdatei wird bei der Datenbankdefinition ein Datentyp angegeben. Bei jeder Eingabe kann das DBMS prüfen, ob diese dem festgelegten Typ entspricht. Je mehr unterschiedliche Datentypen ein Datenbanksystem kennt, um so enger kann der Wert eines Attributs eingegrenzt werden und um so besser wirkt dieser Schutz.
Transaktionen verletzen nicht Integritätsbedingung
Ein weiteres Beispiel für die Schutzwirkung der Schemata ist die Eindeutigkeit des Primärschlüssels für einen Objekttyp. Wenn bereits ein Lieferant mit der Nummer 755 gespeichert ist, wird ein weiterer Lieferant mit derselben Nummer nicht vom DBMS akzeptiert.
Die Hauptlast bei der Wahrung der Integrität tragen heute aber die Anwenderprogramme. Nimmt man von einer Transaktion an, daß sie die Datenbank von einem richtigen Zustand in einen weiteren richtigen Zustand überführt, dann liegt die Annahme zugrunde, daß die Transaktion selbst keine Integritätsbedingung verletzt. Man spricht vom Wohlverhalten der Programme.
Nun läuft diese Strategie eigentlich dem Prinzip der programmneutralen Datenhaltung zuwider. Dies äußert sich in einem Mehrfachaufwand bei der Programmierung, weil jedes Anwenderprogramm Routinen enthalten muß, die die Wahrung der Integrität erzwingen. Auch ist die Datenbank den Programmierern auf Gedeih und Verderb ausgeliefert.
Der Idealzustand ist die Überprüfung durch das Datenbanksystem. Dies um so mehr, als in Zukunft der Anteil der starren, kurzen Transaktionen zugunsten freierer, nicht nach festem Schema ablaufender Arbeit (wie bei CAD) zurückgehen wird.
Erste Ansätze zu einer Integritätsüberwachung durch das DBMS gibt es schon. So ist zum Beispiel in SQL die Möglichkeit vorgesehen, bei der Datenbankdefinition Festlegungen der folgenden Art zu treffen:
ASSERT A ON UPDATE OF PERSONAL (GEHALT) NEW GEHALT = OLD GEHALT.
(Gehälter dürfen nicht gekürzt werden.)
Ein großes Problem der Integritätswahrung durch das DBMS ist der Geschwindigkeitsverlust. Man wird auch bei wesentlich schnellerer Hardware nur einen geringen Teil der formulierbaren Integritätsbedingungen überprüfen können.
Von verteilten Datenbanken spricht man, wenn die Datenbasis auf mehrere Datenbanken verteilt ist, die auf verschiedenen Rechnern laufen. Die Anwender können innerhalb eines Programms mit mehr als einer Datenbank in Verbindung treten, unabhängig davon, an welchem Rechner sie selbst arbeiten.
Verteilte Datenbanken werden in der betrieblichen DV künftig eine große Rolle spielen. Bild 10 zeigt ein System der verteilten Verarbeitung im Industriebetrieb. Die Abteilungen haben eigene Rechner (vorwiegend Mikrocomputer), auf denen der Großteil der DV-Aufgaben gelöst wird. Diese Rechner sind miteinander vernetzt.
Um Datenübertragungen zu vermeiden, speichert man auch die Daten, die eine Abteilung alleine oder vorwiegend alleine benutzt, auf einer Datenbank des Abteilungsrechners. Werden Daten aus dem Fundus einer anderen Abteilung gebraucht, dann werden sie aus der dortigen Datenbank abgerufen und übertragen.
Fortgeschrittenste DDP-Form ist der logische Verbund
Es gibt auch heute schon verteilte Datenbanksysteme. Ein Handicap ist allerdings, daß im Anwendungsprogramm stets angegeben werden muß, aus welcher der angeschlossenen Datenbanken ein bestimmtes Datum abzurufen ist.
Die fortgeschrittenste Form der verteilten Verarbeitung ist der logische Verbund. Darin merkt der Anwender nicht, daß er es mit mehr als einer Datenbank zu tun hat. Die angeschlossenen Datenbanken lösen die Frage, auf welcher Datenbank ein Datum zu finden ist, selbständig.
Bevor dieser Endzustand erreicht ist, sind nicht nur eine Reihe von technischen Fragen zu lösen. Es müssen im Betrieb die Datenstrukturen der Abteilungen so abgestimmt werden, daß sie ein harmonisches Ganzes ergeben.
Non-Standard-Anwendungen bedürfen DB-Unterstützung
Unter dem Begriff Non-Standard-Anwendungen faßt man neuerdings eine Reihe von Aufgaben zusammen, die dringend einer Datenbankunterstützung bedürfen, aber mit den herkömmlichen Datenbanksystemen nicht gut gelöst werden können. Die wichtigsten dieser Aufgaben sind CIM (Computer Integrated Manufacturing), Büroanwendungen und die Datenhaltung für Expertensysteme. Welche Anforderungen auf die Datenbanktechnik zukommen, soll am Beispiel des CIM erläutert werden.
Unter CIM versteht man die Integration der bisher in der betriebswirtschaftlichen DV angesiedelten Produktionsplanung und -steuerung (PPS) und der technischen Bereiche CAD und CAM. Könnten sie auf eine gemeinsame Datenbasis zugreifen, dann ergäben sich große Vorteile. Bislang existiert kein von beiden Bereichen gemeinsam benutzbares DBS.
Bei den Standard-Anwendungen hat man es mit einfach strukturierten Objekten zu tun, von denen es jeweils viele Ausprägungen gibt (Beispiel: die Objekte Meier, Müller, Kunze, ... vom Typ Kunde). Dagegen sind die Objekte der technischen Anwendungen komplex aufgebaut. Bei vielen Objekten gibt es mehrere Aspekte der Betrachtung, beispielsweise kann man ein Konstruktionsobjekt unter den Gesichtspunkten der Funktion, der Geometrie, der Fertigung und so weiter betrachten.
Es wurde versucht, komplexe Objekte mit Hilfe des Relationen- und des Netzwerkmodells zu erfassen. Dies ist vom Prinzip her möglich. Beispielsweise ist die Stücklistenstruktur, wie sie in Fertigungssteuerungssystemen vorkommt, eine Darstellung eines komplexen Objekts. Bild 11 zeigt die Realisierung im Relationenmodell. Zwei "flache" Relationen (Teil und Teilestruktur) enthalten die Information über die Zusammensetzung aller Teile. Nun ist die Zusammensetzung eines Teils im CAD sicher ein wichtiger Aspekt, aber doch nur einer unter mehreren. Wollte man alle diese Aspekte mit flachen Relationen abbilden, dann ergäbe sich ein Geflecht aus vielen Relationen und Beziehungen. Das Wissen, welche Beziehungen zu verfolgen sind, um die Aspekte eines Objekts wiederzugewinnen, läge nicht in der Datenbank, sondern müßte im Anwenderprogramm vorhanden sein.
Ein weiterer Nachteil dieser Lösung ist, daß sie langsam ist. Um ein Objekt zu laden oder zu speichern, müssen sehr viele Zugriffe durchgeführt werden.
Komplexe Objekte aus flachen Relationen
Eine andere Lösung auf der Basis herkömmlicher Datenbanksysteme ist die folgende: Das Anwenderprogramm wird von der Bürde, das komplexe Objekt zusammenzusetzen, befreit. Man legt statt dessen im Datenbanksystem über die Ebene der flachen Relationen eine weitere Betrachtungsebene, in der komplexe Objekte vorkommen. Mit dieser Ebene kommuniziert der Anwender. Wird von einem Programm ein komplexes Objekt angefordert, dann setzt das DBMS dieses Objekt aus den flachen Relationen zusammen und stellt es zur Verfügung.
Gegenüber dem vorherigen Ansatz ist damit viel an Unabhängigkeit der Anwendungen gewonnen. Es bleibt das Schnelligkeitsproblem, denn die Arbeit des Zusammensetzens wird zwar auf das Datenbanksystem verlagert, ist aber nach wie vor zu tun.
Während man bei den Standard-Anwendungen alte Versionen der Datensätze einer Ablage (Papier oder Band) anvertrauen kann, kommt es im CAD häufig vor, daß man auf alte Versionen zurückgreifen will, um eine Neukonstruktion darauf aufzubauen. Das Datenbanksystem braucht daher eine Versionenverwaltung.
Bei manchen Non-Standard-Anwendungen verliert auch das jetzige Transaktionskonzept seinen Sinn. Bei den Standard-Anwendungen bemüht man sich, die Transaktionen möglichst kurz zu halten, damit die Anwender einander nicht blockieren. Bei einem Konstruktionsgebilde im CAD dagegen kann über eine längere Entwicklungszeit hinweg die Datenintegrität nicht gegeben sein. Dies betrifft besonders die Integrität in bezug auf normative Aussagen, wie zum Beispiel Konstruktionsvorschriften.
Komplexe Objekte, Versionenverwaltung und ein neues Transaktionskonzept sind nur ein Teil der Anforderungen, die auf die Datenbanktechnik zukommen. Erschwerend wirkt, daß die Non-Standard-Bereiche CIM, Expertensysteme und Bürotechnik recht unterschiedliche Probleme aufwerfen.
Es gibt bereits einige Datenmodelle, die es gestatten, komplexe Objekte darzustellen. Zum Teil sind sie Erweiterungen der herkömmlichen Datenmodelle, vorwiegend des Relationenmodells.
Verblüffend einfach ist der NF2-Ansatz (Non-First-Normal-Form). Eine von Codd formulierte und als erste Normalform bezeichnete Anforderung an Relationen besagt, daß sie weder Wiederholungsgruppen noch zusammengesetzte Attribute enthalten dürfen. Anders ausgedrückt: Relationen haben flach zu sein.
Im NF2-Ansatz geht man von dieser Forderung ab und erlaubt als Attribute auch Relationen. In Bild 12 ist eine solche NF2-Relation abgebildet. Die Objekte der Non-Standard-Anwendungen sind jedoch wesentlich komplexer, als in diesem einfachen Beispiel dargestellt.
Da, wie bereits erwähnt, ein DBS mit einer Zusatzschicht für die Non-Standard-Anwendungen zu langsam wäre, muß eine neue, besser geeignete Datenbankarchitektur gefunden werden. Grundsätzlich könnte man ein solches System universell, das heißt für alle Anwendungen geeignet oder aber spezialisiert und separat für jede Anwendungsart entwerfen. Weil die Anforderungen der Non-Standard-Anwendungen sehr unterschiedlich sind, würde ein universelles System sehr aufwendig und langsam sein. Auf der anderen Seite könnte mit völlig getrennten Systemen auch die gewünschte Integration nicht erreicht werden.
Bild 13 zeigt die sogenannte Kernarchitektur, die sowohl Schnelligkeit als auch Integrationsfähigkeit verspricht. Ein Speicherserver (der Datenbankkern) übernimmt die Verwaltung aller Daten. Der Speicherserver benutzt ein geeignetes Datenmodell für die Darstellung komplexer Objekte, also beispielsweise das NF2-Modell. Er stellt, gemessen an herkömmlichen DBS, ein vollständiges DBS mit allen drei Ebenen dar.
Weitere Schicht für unterschiedliche Anforderungen
Damit den unterschiedlichen Anforderungen der Anwendungen Genüge getan werden kann, legt mal als weitere Schicht noch eine spezialisierte Benutzerschnittstelle darüber. Diese Schnittstelle nimmt Befehle für Operationen entgegen, die für die Objekte der Anwendungsart spezifisch sind. Beispielsweise könnte die bildorientierte Schnittstelle Kopien von Bildausschnitten herstellen und Bilder zusammenfügen. Die Benutzerschnittstelle setzt die spezifischen Operationen in Befehle für Operationen auf komplexe Objekte um, die sie an den Speicherserver richtet. Der Speicherserver führt dann die Arbeiten bis hinunter zur physischen Ebene durch.
Um dem Speicherserver die notwendige Schnelligkeit zu geben, denkt man daran, neue Zugriffsformen und Speicherungstechniken einzuführen. Ein schneller Zugriff auf ein komplexes Objekt wäre besonders dann möglich, wenn alle dazugehörigen Daten auch körperlich nahe beieinander auf den Datenträgern lägen.
Wieder Probleme mit den Redundanzen
Allerdings besteht hier ein Konflikt zwischen dem Streben nach Schnelligkeit und dem Ziel, Redundanz zu vermeiden. Wenn nämlich ein Teilobjekt mehrmals verwendet wird, müßten seine Daten bei jedem komplexen Objekt, in das es eingeht, gespeichert werden. Es treten damit wieder Probleme mit Redundanten auf, wie sie aus der konventionellen Datenhaltung bekannt sind und die durch das Baukastenprinzip der Coddschen dritten Normalform bereits beseitigt waren.
Eine Lösung, die ausreichende Schnelligkeit verspricht und trotzdem die Mehrfachverwendung erlaubt, könnte das Minidirectory-Konzept sein (Bild 14). Die Information, wo ein komplexes Objekt gespeichert ist, enthalten die sogenannten Minidirectories (MD). Dies sind Datensätze mit Zeigern auf andere Datensätze.
Das Root-MD verweist auf die Teile von Projekt 10 auf der obersten Ebene. Die atomaren Attribute der obersten Stufe (Projekt # und Projektleiter) sind zu einem Nutzdatensatz zusammengefaßt, auf den ein Datenzeiger (D) des Root-MD verweist. Für die Attribute, die selbst Relationen darstellen (hier nur Mitarbeiter), existieren im Root-MD entsprechende C-Zeiger (Childpointers) auf weitere MDs auf der nächstniedrigeren Ebene. In diesen MDs sind dann Zeiger auf die Nutzdatensätze enthalten. Wie viele Ebenen von MDs notwendig sind, ist vom Aufbau des komplexen Objekts abhängig.
Die Mehrfachverwendung von Daten wird verwirklicht, indem die zugehörigen MDs in mehrere Vater-MDs eingehängt werden können. Auch im MD-Konzept sollen zusammenhängende Daten zusammen gespeichert werden. Allerdings beschränkt man sich hier auf Cluster mit atomaren Attributwerten, die nach Möglichkeit auf einer Speicherseite abgelegt werden sollen.
Der Entwurf eines Produkts mit einem CAD-System kann Wochen und sogar Monate dauern. Solange der Entwurf nicht fertiggestellt ist, sind seine Daten auch nicht konsistent. Andererseits sind häufige konkurrierende Zugriffe auf ein Objekt im CAD nicht zu erwarten Man wird deshalb durch eine längere Sperre eines Objekts nicht den ganzen Betrieb mit der Datenbank lahmlegen.
Eine Besonderheit bei CAD ist, daß ein Objekt häufig durch eine Entwicklungsgruppe bearbeitet wird. Zwischen den Mitgliedern der Gruppe muß ein Datenaustausch nach festgefügten Regeln möglich sein. Bild 15 zeigt das Prinzip eines gruppenbezogenen Transaktionskonzepts. Es werden zwei Transaktionsarten unterschieden: Gruppentransaktionen, die für eine Entwicklergruppe durchgeführt werden und Benutzertransaktionen, die Mitglieder der Gruppe abwickeln.
Zu Beginn einer Entwicklung werden die von der Gruppe benötigten Grunddaten aus der Datenbasis geholt und in einen Benutzerpool kopiert (Checkout). Dies ist der Beginn einer Gruppentransaktion, die bis zum Ende der Entwicklung andauert. Die Originale können weiterhin gelesen, aber nicht verändert werden. Aus dem Datenpool der Gruppe können nun Daten von einzelnen Mitgliedern mit Benutzertransaktionen bearbeitet werden. Die betreffenden Objekte werden in den privaten Speicher des Erwerbers kopiert und - analog zur Gruppentransaktion - wird das Exemplar im Pool gegen Änderungen geschützt, darf aber gelesen werden. Mit dem Zurückschreiben in den Gruppenpool endet die Benutzertransaktion.
Die Gruppenmitglieder haben auch die Möglichkeit, einander ihre Arbeitsergebnisse zur Verfügung zu stellen. Die Verantwortung für die Richtigkeit solcher Übernahmetransaktionen liegt bei der Gruppe.
Entwicklungsergebnisse können im Pool zusammengeführt und dort in ihrer Gesamtheit auf Richtigkeit überprüft werden. Der in sich konsistente Gesamtentwurf kann dann in die Datenbasis zurückgeschrieben werden. Damit endet die Gruppentransaktion .
Von Zeit zu Zeit aktuellen Stand sichern
Natürlich können solche langen Transaktionen bei einem Fehler nicht zurückgesetzt werden, wie das normalerweise mit den kurzen Transaktionen der Standard-Anwendungen geschieht. Es wäre ja dann die ganze Entwicklungsarbeit verloren. Man muß sich also behelfen, indem man von Zeit zu Zeit den aktuellen Stand sichert und im Fehlerfall auf dem letzten Sicherungspunkt aufsetzt.
Durch die Non-Standard-Anwendungen wird die Forderung nach der Integritätswahrung durch das DBS dringender. Dem Benutzer muß hier ein erheblich größerer Spielraum bei der Änderung der Daten eingeräumt werden als bei den Standard-Anwendungen, wo eine straffe Führung durch das Anwenderprogramm möglich ist. Auf Wohlverhalten kann nicht gebaut werden. Als wesentliche Aspekte des Integritätsproblems wurden die Prüfung von Daten auf ihre Übereinstimmung mit der Realität und hinsichtlich der Harmonie mit normativen Aussagen genannt. Für beide Situationen ist der vollständige Integritätsnachweis nicht zu erbringen; man ist auf Indizien angewiesen.
Ungewöhnliche Daten wehrt das System ab
Ein vielversprechender Ansatz besteht darin, daß man Ausnahmesituationen definiert. Nimmt ein Datum oder eine Datenkonstellation einen ungewöhnlichen Wert an, dann kann das System die Eingabe abwehren oder, in schwächeren Fällen, beim Benutzer nachfragen, ob die Eingabe so gewollt ist.
Weil solche Ausnahmesituationen sich auch auf das Verhältnis zu bereits gespeicherten Daten beziehen können, lassen sich auch Indizien bezüglich der Übereinstimmung der Eingabe mit der Wirklichkeit gewinnen. Geht man davon aus, daß die gespeicherten Daten der Realität entsprechen, dann deuten Widersprüche zu neu eingegebenen Daten darauf hin, daß diese von der Realität abweichen.
Die Ausnahmesituationen können mit Hilfe einer Metadatenbank verwaltet werden. Eine solche Datenbank enthält Aussagen über die gespeicherten Nutzdaten, die vom DBMS bei der Integritätsprüfung herangezogen werden.
Man versucht schon länger, Datenbanken schneller zu machen, indem man sie auf speziell dazu ausgestatteten Rechnern, sogenannten Datenbankmaschinen, einrichtet. Die ersten Lösungen waren Backend-Konzepte (Bild 16). Auf der dem Benutzer abgewandten Seite des Verarbeitungsrechners wurde ein weiterer Rechner installiert, der die Datenbankoperationen ausführte und damit den Verarbeitungsrechner entlastete. Die Schnelligkeitsgewinne mit solchen Konfigurationen waren allerdings nicht ermutigend.
In der letzten Zeit wird ein flexiblerer Ansatz verfolgt, der auch besser zu verteilten Systemen paßt (Bild 17). Die Datenbank befindet sich auf einem Datenbank-Server, der mit anderen Rechnern vernetzt ist. Der Datenbank-Server kann Datenbankoperationen für alle Rechner des Netzes abwickeln. Auch der verteilten Datenhaltung steht nichts entgegen, denn es lassen sich auch mehrere DB-Server installieren.
Ein Vorteil gegenüber dem Backend-Konzept ist auch, daß eine Datenbank unschwer von Mainframes und Mikros parallel genutzt werden kann.
Der DB-Server kann ein Universalrechner sein oder aber eine Datenbankmaschine. Während es am Markt bereits Lösungen mit Universalrechnern gibt, stehen die DB-Maschinen noch in der Entwicklung. Es werden verschiedene Konzepte diskutiert. Gemeinsam ist ihnen, daß die Schnelligkeit durch paralleles Arbeiten mit mehreren oder gar vielen Prozessoren gewonnen werden soll.