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.
Datenbanksysteme sind das Ergebnis einer kontinuierlichen Entwicklung der Datenhaltung. Das heute als antiquiert angesehene hierarchische Datenbanksystem entstand aus konventionellen Dateisystemen mit hierarchischer Gliederung und Wiederholungsgruppen. Bild 1 zeigt Ausschnitte aus den Cobol-Dateibeschreibungen zweier Programme, die mit hierarchisch gegliederten Dateien arbeiten. In der herkömmlichen Dateiverwaltung speichert jedes Programm seine Daten separat. Für das gezeigte Beispiel ergibt sich daraus eine hohe Redundanz, weil es sich weitgehend um dieselben Daten, nämlich die Personaldaten handelt.
Mit der Redundanz sind höhere Speicherkosten verbunden. Doch dies ist nicht das Hauptproblem. Da keine ständige Abstimmung zwischen den Programmen stattfinden kann, können Daten gleichen Namens unterschiedliche Werte bekommen. Man spricht von Dateninkonsistenz. Selbst wenn die Daten periodisch abgeglichen werden, fallen in den Zeiten zwischen den Abgleichsläufen Entscheidungen auf der Basis ungleicher Daten.
Wenn zwei Programme im Betriebsablauf aufeinanderfolgen, und eines auf den Ergebnissen des anderen aufbaut, dann müssen bei konventioneller Datenhaltung diese Ergebnisse erst in den Umkreis des zweiten Programms übertragen werden, bevor dieses starten kann. In einem Unternehmen mit einer Vielzahl solcherart verbundener Programme ist der Übertragungsaufwand immens. Es bietet sich deshalb an, die Daten nur einmal zu speichern und sie mehrfach zu verwenden. Dies ist das Datenbankprinzip.
Mangelnde Performance wird zum RDBMS-Handicap
Die Datenbankentwicklung ging zunächst zwei Wege, um diesen Grundsatz zu verwirklichen. Beim ersten Ansatz, der in dem heute noch weitverbreiteten Datenbanksystem IMS der IBM mündete, behielt man die hierarchische Gliederung grundsätzlich bei. Die Mehrfachverwendung der Daten wurde dadurch ermöglicht, daß anstelle von Nutzdaten Zeiger gespeichert werden können, die auf Datensätze verweisen. Bild 2 zeigt, wie im hierarchischen Datenbanksystem die Daten vom Typ Mitarbeiter aus der Abteilungshierarchie gleichzeitig für die Typen Projektleiter, Projektmitarbeiter und Abteilungsleiter verwendet werden können, wenn man deren Nutzdaten durch Zeiger ersetzt.
Der zweite Ansatz wurde von der Codasyl Data Base Task Group (DBTG) entwickelt. Sie löste sich von der Hierarchie, in ihrem Konzept kann jeder Typ beliebig vielen anderen untergeordnet sein. Weil sich dabei ein Netz von Typen ergibt, spricht man vom Netzwerkmodell. Bild 3 zeigt das gleiche Beispiel in der Netzwerkstruktur. Der Typ Personal ist den Typen Projekt und Abteilung untergeordnet (Pfeilrichtung), wobei jeweils zwei Unterordnungsbeziehungen bestehen. Physisch werden diese Beziehungen durch Zeiger und Zeigerketten verwirklicht. Nach Bild 4 sind die Angestellten Müller, Meier und Kunze Mitglieder des Projekts Alpha, Müller ist außerdem Leiter der Abteilung Zentraleinkauf. Die Unterordnungsbeziehung wird im Codasyl-Sprachgebrauch als Set bezeichnet, die konkrete Ausprägung - Quelle: Computer, Tomus Verlag, München, 1986 - (das Projekt Alpha und seine Mitarbeiter) heißt Set-Occurrence.
Die ersten Arbeiten der DBTG über das Netzwerkmodell erschienen Ende der sechziger Jahre. Bereits 1970 veröffentlichte Ted Codd seine erste Arbeit zum Relationenmodell. Obwohl bestechend einfach im Aufbau und in der Handhabung, hat es sich im Großcomputerbereich gegen die Netzwerkdatenbanken nicht so recht durchsetzen können. Der am häufigsten genannte Grund ist die zu geringe Geschwindigkeit. Dem stehen jedoch andere Mängel bei den Netzwerkdatenbanken gegenüber.
In einer relationalen Datenbank werden die Daten in Relationen (Tabellen) abgelegt. Die relationalen Datenbanksysteme verlangen, daß diese Tabellen "flach" sein müssen, das heißt, die Attribute dürfen weder gegliedert sein noch Wiederholungsgruppen darstellen. Ein Attribut Adresse innerhalb der Relation Mitarbeiter wäre also unzulässig, nicht aber wären es die drei Attribute Straße, Postleitzahl und Wohnort. Verfügt ein Mitarbeiter über mehrere Telefonanschlüsse, dann genügt ein Attribut Telefonnummer nicht, sondern es müssen mit Tel1, Tel2, ..., Teln die Plätze für n Telefone als Attribute definiert werden.
In jeder Relation werden ein oder mehrere Attribute als Schlüssel festgelegt. Der Wert des Schlüssels muß einen bestimmten Satz (eine Zeile der Tabelle) eindeutig identifizieren, darf also nur einmal vorkommen. Will man Beziehungen zwischen Relationen benutzen, dann tut man dies auch mit Hilfe der Schlüssel. Da in der Relation Abteilung das Attribut Abt-Leiter die Personalnummer des Leiters aufnimmt, kann man für eine bestimmte Abteilung leicht aus der Relation Personal die Daten ihres Leiters holen (Bild 5).
Relationale Datenbanken erlauben nicht nur die herkömmlichen satzweisen Zugriffe, sondern auch Operationen auf ganzen Tabellen. Man kann klassische Mengenoperationen (Vereinigung, Durchschnitt, Differenz) und Relationsoperationen (Verbund, Selektion, Projektion) unterscheiden. Die erste Gruppe ist auf Relationen mit gleichartigen Attributen beschränkt. Hat man beispielsweise zwei solche Relationen Lieferant und Kunde, dann ergibt die Vereinigung eine Tabelle mit allen Geschäftspartnern. Der Durchschnitt ist eine Relation mit allen Lieferanten, die zugleich Kunden sind, und die Differenz ist die Menge aller Geschäftspartner, die zwar Lieferanten, aber nicht Kunden sind.
Die zweite Gruppe kann anhand von Bild 5 erklärt werden. Beim Verbund werden zwei oder mehr Tabellen bezüglich gemeinsamer Attribute verknüpft, so daß daraus eine einzige, breitere Tabelle entsteht. Die Relationen Abteilung und Personal können unter anderem bezüglich der Merkmale Abt-Leiter # und Personal #, die einander entsprechen, verknüpft werden. Es entsteht daraus eine Tabelle, die sowohl die personenbezogenen Daten der Abteilungsleiter enthält als auch die Daten der Abteilungen, die sie leiten.
Von Selektion spricht man, wenn aus einer Tabelle alle Sätze herausgesucht werden, die einer bestimmten Bedingung genügen. Die Bedingung Abteilung = RE ist im abgebildeten Ausschnitt der Personaltabelle für zwei Sätze erfüllt. Bei der Projektion werden aus einer Relation eine oder mehrere Spalten (Attribute) entfernt. Dadurch kann es passieren daß Sätze, die sich vorher voneinander unterschieden, nunmehr identisch sind.
Streicht man beispielsweise in der Personaltabelle alle Attribute außer der Abteilung, dann gibt es zwei Sätze mit dem Wert RE, die sich durch nichts voneinander unterscheiden. Die meisten Datenbanksysteme lassen hier dem Benutzer die Wahl, ob er die Sätze mehrfach oder nur einmal haben will.
Diese sechs Grundoperationen und meist noch weitere Hilfsoperationen wie Sortieren, Drucken und so weiter sind in viele verschiedene Datenbanksprachen eingegangen. Unter diesen ist die Sprache SQL (Structured Query Language) so etwas wie ein Standard geworden. SQL erlaubt eine fast umgangssprachliche Formulierung eines Problems.
Die Anweisung
SELECT PERSONAL #, NAME
FROM PERSONAL
WHERE ABTEILUNG = VT
führt zur Ausgabe der Personalnummern und Namen aller Mitarbeiter die in der Abteilung VT arbeiten.
Da in Anweisungen wie der obigen kein Lösungsweg angegeben werden muß, sondern lediglich eine Angabe über das gewünschte Ergebnis gemacht wird, spricht man von einer deskriptiven Sprache (im Gegensatz zu einer prozeduralen Sprache).
Nicht immer sind die Fragen so einfach zu formulieren. Ist beispielsweise nur die Langbezeichnung der Abteilung bekannt, dann kommt man mit folgender Anweisung zum Ziel:
SELECT PERSONAL #, NAME
FROM PERSONAL
WHERE PERSONAL # IN
SELECT PERSONAL #
FROM ABTEILUNG
WHERE NAME = VERTRIEB
Diese geschachtelte Anweisung enthält ein prozedurales Element. Die durch die innere Select-Klausel beschriebene Menge ist Ausgangsbasis für die äußere. Hinsichtlich der Schachtelungstiefe gibt es keine Begrenzungen außer der Übersicht und der Geduld des Anwenders.
Datenbanksysteme haben, unabhängig vom zugrundeliegenden Datenmodell, einige, gemeinsame Merkmale, die sie von anderen Datenverwaltungstechniken abheben. Während in der konventionellen Datenhaltung jedes Programm über seine eigenen Dateien verfügt, die genau Jene Daten enthalten, mit denen das Programm arbeitet, gibt es in der Datenbanktechnik nur eine einzige Datenbasis, aus der alle Programme versorgt werden.
Daraus erwächst ein besonderes Sicherheits- und Koordinationsbedürfnis. Da man nicht mehr sagen kann, daß dieses oder jenes Datum einem bestimmten Programm "gehört", werden die Daten in die Obhut einer anwendungsneutralen Stelle, der Datenbankadministration gegeben, die dafür sorgt, daß die einzelnen Programme Zugang zu den benötigten Daten bekommen und daß sie diese auch in der richtigen Form vorfinden.
Diese "Schlüsselgewalt" der Datenbankadministration kann nur gewährleistet werden, wenn alle Programme mit Hilfe derselben Datenverwaltungsroutinen auf die Datenbasis zugreifen. Diese Datenverwaltungsroutinen werden vom DBS bereitgestellt und sind Teil von dessen DBMS (Database-Management-System, Bild 6).
Mit der Abkehr von der programmeigenen Datenhaltung ist auch verbunden, daß für die Daten nunmehr eine logische Struktur gefunden werden muß, die es erlaubt, allen Anwendungen genau die Daten zur Verfügung zu stellen, die es braucht. Eine zusätzliche Bedingung ist, daß die darin untergebrachten Daten möglichst wenig Redundanz aufweisen sollen.
Man löst dieses Problem heute mit objektbezogenen Datenstrukturen. Die Objekte sind reale oder abstrakte Dinge, die direkt der abzubildenden Wirklichkeit entlehnt sind. Da man nicht die ganze Wirklichkeit erfassen kann und will, speichert man von jedem Objekt nur die im Zusammenhang mit den Programmen relevanten Eigenschaften. Bei einem Objekt vom Typ Kunde gehört dazu gewöhnlich der Name, nicht aber die Farbe seines Schnurrbarts oder seine Schuhgröße (es sei denn, es handelt sich um die Kunden eines Schuhgeschäfts).
Bild 7 zeigt eine solche objektbezogene Struktur für ein einfaches Vertriebssystem. Damit die Objekte später zu den Datengebilden zusammengesetzt werden können, die die einzelnen Programme brauchen "Sichten" auf die Daten), müssen auch die Beziehungen zwischen den Objekten in der Datenbank festgehalten werden. Sie sind in Bild 7 durch Linien zwischen den Objekttypen-Kästchen dargestellt. Die eingezeichnete Beziehung zwischen den Objekten des Typs Auftrag und jenen des Typs Kunde gestattet beispielsweise, alle Aufträge eines bestimmten Kunden zu finden. Im Bild sind beispielhaft die Objekttypen eingekreist, die zur Sicht eines Programms gehören, das eine Liste aller Aufträge mit Angabe des Kundennamens und der Artikelbezeichnung ausdruckt.
Die Objekttypen der Datenbasis können zwar weitgehend nach dem Allgemeinverständnis bestimmt werden, es gibt jedoch auch formale Regeln, die es gestatten, die gefundenen Objekttypen dahingehend zu testen, ob sie den Erfordernissen der Datenbankhaltung entsprechen. Diese Regeln wurden von Codd zuerst im Rahmen seines Relationenmodells entwickelt, sie sind jedoch mittlerweile zur Grundlage einer modellunabhängigen Datenstrukturlehre geworden ("Normalformen").
Die objektbezogene Datenstruktur ist in die Datenbanksysteme nicht "eingebaut". Man kann durchaus auch auf einem Datenbanksystem eine herkömmliche, programmorientierte Datenstruktur halten, und dies wird leider noch häufig getan. Es können dann zwar die komfortablen Dienstprogramme eines solchen Systems genutzt werden, der eigentliche Zweck der Datenbanktechnik wird aber nicht erreicht.
Datenbanksysteme betrachten die Daten auf mehreren Ebenen (Bild 8). Die unterste ist die der physischen Speicherung. Die Festlegungen über die Speicherungsformen und Zugriffswege für diese Ebene werden unter dem Begriff internes Schema zusammengefaßt. Das Wort "intern" weist darauf hin, daß "außen", also im Kreis der Benutzer, überhaupt nicht bekannt sein muß, wie und wo die Daten gespeichert sind.
Die darüberliegende Ebene wird logisches Schema genannt. Der Aufbau dieser Ebene ist gemeint, wenn von einem bestimmten Datenmodell die Rede ist. Das interne Schema allein bezeichnet nur eine Ansammlung von Daten ohne jede Bedeutung. Erst das logische Schema gibt diesen Daten Sinn. Es enthält die Information, welche Typen von Objekten gespeichert sind und welche Beziehungen zwischen ihnen bestehen.
Die oberste Ebene stellt die Verbindung vom Datenbanksystem zu den Anwendern her. Jedem Anwender ist ein "externes Schema" (eine Datensicht) zugeordnet, das angibt, welche Zusammenstellung von Daten er aus dem logischen Schema benötigt. Die Verbindung zwischen den Ebenen wird durch das DBMS hergestellt. Die Anwenderprogramme werden damit nicht belastet.
Die Dreiebenen-Architektur ermöglicht es, den Anwender von der Art und Weise der Datenspeicherung abzuschneiden. Ist das externe Schema eines Programms einmal festgelegt, dann berühren interne Änderungen den Anwender nicht, so lange dieses Schema stabil bleibt.
Volle Wirkung nur im Mehrbenutzerbetrieb
Datenbanksysteme werden heute zwar, besonders auf Mikrocomputern, auch im Einbenutzerbetrieb eingesetzt, ihren vollen Nutzen können sie aber nur im Mehrbenutzerbetrieb entfalten. Hier entstehen Probleme dadurch, daß mehrere Anwendungen gleichzeitig auf dieselben Daten zugreifen wollen. Das DBMS sorgt dafür, daß Daten, mit denen ein Programm gerade arbeitet, für andere gesperrt werden.
Dadurch können wiederum Situationen geschaffen werden, in denen es nicht möglich ist, alle gestarteten Aktionen der Anwenderprogramme zu Ende zu führen. Diesem Problem wird mit dem Konzept der Transaktionen begegnet.
Wird von einer Buchung nur der Eintrag auf der Sollseite, nicht aber der auf der Habenseite ausgeführt, dann sind die Daten in Unordnung. Man nennt solche Handlungseinheiten, die mit einem korrekten Zustand beginnen und mit einem korrekten Zustand enden, Datenbank-Transaktionen. Transaktionen müssen stets vollständig ausgeführt werden, oder überhaupt nicht. Kann aus irgendwelchen Gründen (zum Beispiel Deadlock) eine Transaktion nicht vollständig ausgeführt werden, dann werden die bereits ausgeführten Teile rückgängig gemacht (Roll back). Beginn und Ende von Transaktionen werden dem DBS vom Anwendungsprogramm durch entsprechende Befehle mitgeteilt.
Die Transaktion eines Programms ist von großer Bedeutung für die anderen Programme, die gerade mit der Datenbank arbeiten, weil die Daten, mit denen diese Transaktion arbeitet, für die anderen Programme gesperrt werden müssen. Wäre das nicht der Fall, dann könnten andere Programme die bereits bearbeiteten Daten vor dem Ende der ersten Transaktion weiterverarbeiten.
Muß nun die erste Transaktion rückgängig gemacht werden, weil sie nicht abgeschlossen werden kann, dann müßten auch alle anderen Transaktionen zurückgesetzt werden, die mit den von der ersten Transaktion veränderten Daten gearbeitet hatten. Der Roll back würde sich also fortpflanzen.
Wegen dieser Sperrnotwendigkeit versucht man, Transaktionen möglichst kurz zu halten, was bei den heutigen Standard-Anwendungen auch meist gelingt.
Datenbanksysteme werden heute vor allem auf den Gebieten der administrativen und dispositiven DV, der Informationssysteme im engeren Sinne und des Information Retrieval eingesetzt. Während administrative Systeme die Rationalisierung der Massendatenverarbeitung bezwecken (Beispiel: Lohnrechnung), sollen dispositive Systeme Entscheidungen vorbereiten oder selbst fällen (Beispiel: Fertigungsablaufplanung). In der Praxis ist diese Trennung allerdings nicht eingehalten, und das wäre auch nicht sinnvoll.
Datenbanksysteme sind heute der Integrationsmotor der betrieblichen Datenverarbeitung. Wenn alle Programme auf die gemeinsame Datenbasis zugreifen können, sind keine Datentransfers und Brückenprogramme mehr nötig, um den Output des einen Programms zum Input eines anderen zu machen. Die Datenbank fungiert als umfassende Schnittstelle (Bild 9).
Allerdings täuscht das Bild einen Grad an Integration vor, der noch nicht vorhanden ist. Es herrscht heute noch eine strenge Trennung zwischen "betriebswirtschaftlicher" und "technischer" Datenverarbeitung. Dies macht sich besonders in den Bereichen Produktentwicklung und Fertigung bemerkbar. Innerhalb der betriebswirtschaftlichen DV werden Bedarfsrechnung, Losgrößenrechnung, Terminierung und Auftragsfreigabe abgewickelt, daneben existieren jedoch "technische" Systeme mit eigenen Daten für CAD (computergestütztes Konstruieren) und CAM (computerunterstützte Fertigung). Bislang sind noch nicht einmal diese technischen Systeme miteinander vereint, geschweige denn die technischen und betriebswirtschaftlichen Programme.
Systeme zur Administration und Disposition sind heute noch eine Domäne der Netzwerkdatenbanken (UDS, IDMS, IDS) und eines hierarchischen Systems (IMS). Aber die relationalen Systeme sind stark im Kommen.
Bei den Informationssystemen war die Bereitschaft, relationale Datenbanken (SESAM, SQL/DS, IDMS/R, Oracle) oder verwandte Systeme (Adabas) einzusetzen, von Anfang an größer. Solche Systeme haben die Aufgabe, die notwendigen Informationen für die Entscheidungen des Managements bereitzustellen. Weil dieser Informationsbedarf meist kurzfristig und immer wieder in anderer Form, auftritt, sind die flexibleren relationalen Datenbanken mit ihren deskriptiven Abfragesprachen besser geeignet.
Während in den Informationssystemen der betrieblichen DV die Datenbasis laufend verändert wird, geht es beim Information Retrieval darum, aus einer relativ konstant bleibenden Datenbasis stets andere Informationsbedürfnisse zu stillen.
Häufig sind Literaturdatenbanken. Die Datenbasis wird periodisch um die Neuerscheinungen ergänzt, Abfragen sind jederzeit möglich. Information-Retrievar-Systeme werden manchmal auf ein relationales Datenbanksystem "aufgesetzt", in den meisten Fällen werden sie aber mit speziellen DBMS ausgestattet (Beispiel: Golem von Siemens).
Je komfortabler und sicherer ein Datenbanksystem ist, um so umfangreicher und komplexer ist auch sein DBMS. Dies mindert die Geschwindigkeit. Dialogverarbeitung und besonders Echtzeitverarbeitung, wie sie bei der Prozeßsteuerung gefragt ist, verlangen aber schnelle Reaktionen. Kommt langsame Hardware hinzu, dann wird schnell die Grenze überschritten, ab der der Geschwindigkeitsverlust nicht mehr tragbar ist.
Damit dies vermieden wird, sind besonders Datenbanksysteme für Mikrocomputer oft stark abgemagert. Die wenigsten enthalten ein Transaktionskonzept. Der Anwender muß in seinen Programmen selbst dafür sorgen , daß keine Teiltransaktionen ausgeführt werden.