*Horst-Joachim Hoffmann ist freier Journalist in München.
MÜNCHEN - "Wir ertrinken In Information, aber hungern nach Wissen", so John Naisbitt in seinem Bestseller "Megatrends". Ob hierarchisch, relational, verteilt oder assoziativ - die Crux des modernen Datenmanagements liegt immer weniger in der technischen Realisierbarkeit, sondern zunehmend im Vorfeld der Konzeption.
Zynisch könnte man behaupten, daß sich die Rolle der Datenbank im Laufe der DV-Geschichte nicht geändert hat, daß aber genau daraus die Probleme heutiger Anwendungen resultieren. "Zu Beginn der Datenverarbeitung wurden Daten parallel zu den Programmen ohne Rücksicht auf ihre Struktur behandelt," erläutert Josef Aichele, Leiter der Zentralabteilung Datenbanken bei der GEI GmbH, Aachen. Doch schon relativ schnell kam die Forderung auf, Daten und Programme getrennt zu sehen und zu bearbeiten.
Die Probleme, die bei der Verquickung von Software und Daten auftraten, machten vor allem einen kommerziellen Einsatz von datengestützten Anwendungen schwierig. So mußten beispielsweise die Werträume innerhalb eines Programms fest definiert werden. Schon bei der Auftragsabwicklung, die mit zu einem der ersten Anwendungsbereiche für DB-Anwendungen zählt, war dies ein Unterfangen, das nicht nur das Nutzungspotential der Informationen erheblich beschnitt. Inhaltliche Änderungen führten im Normalfall auch zu technischen Problemen - zum Beispiel zu Maskenüberläufen - und ließen vor allem bei Fehleingaben leicht ein ganzes System zusammenbrechen.
Einige Mannjahre Änderungsaufwand
Unter Cobol wurde dann die "Data Definition Section" eingeführt, die Datendefinitionen an den Anfang eines Programmes stellte. Dieser Schritt war eine Folge der Erkenntnis, daß Daten unabhängig von der weiteren Verarbeitung und deshalb separat abzulegen seien. Dennoch wurde den Daten eine feste Bedeutung gegeben, die bis zum physischen Verdrahten unabhängig von ihrer sonstigen Bedeutung führte. Für diese hierarchischen Systeme, die als Spezialfall eines Netzes gelten können, steht nach Aussage von DB-Experten als eines der großen Beispiele das IBM-Produkt IMS.
Diese Systeme litten und leiden immer noch vor allem unter dem großen Aufwand, den Änderungen hervorrufen. "Die Einführung einer neuen Produktlinie des Unternehmens beispielsweise kann leicht einige Mannjahre Änderungsaufwand hervorrufen", erläutert der DB-Experte Aichele, "da alle Anwendungen neu bearbeitet werden müssen."
Der Nachteil der totalen Inflexibilität wurde indes wegen des Vorteils eines sehr guten Laufzeitverhaltens DV-technisch gerne in Kauf genommen. Dennoch darf nicht vergessen werden, daß die Starrheit des Datenbanksystems auf die gesamte Unternehmensstruktur durchschlägt. Nicht zuletzt aus Gründen der Performance haben diese hierarchischen Systeme jedoch auch heute noch in speziellen Bereichen Existenzberechtigung, so bei Buchungen im Flug- oder Reiseverkehr.
Der Unterschied zwischen hierarchischen Datenbanken und den zeitlich nachfolgenden Codasyl-Datenbanken, zu denen Systeme wie UDS oder IDMS zählen, liegt in der strengen, statischen Pfadstruktur. Durch logische Datenbanken, die über das hierarchische Grundmuster gelegt wurden, ist die Inflexibilität gelockert worden, um Netzstrukturen abbilden zu können.
Geschwindigkeit auf Kosten der Dynamik
Die Speicherung von Daten in Unabhängigkeit von anderen Merkmalen - die Grundlage relationaler Datenbanksysteme - wird als einer der großen Schritte hin zur Flexibilität der heutigen DV betrachtet. Die Relationen zwischen den Tabellen, in denen die Daten abgespeichert sind, werden über Schlüssel - also nicht mehr physisch - aufgebaut. Der große Vorteil dieses Verfahrens liegt darin, daß Daten unter dem Aspekt ihrer Veränderbarkeit nur noch einmal umdefiniert werden müssen, und alle verarbeitenden Programme unberührt von dieser Aktion bleiben.
Fragen der Performance scheinen gelöst. "Das Laufzeitverhalten ist bei langen Tabellen in geringer Anzahl durchaus o.k.", meint Alexander von Stülpnagel von der MSP GmbH aus München. Das Joinen, also das Zusammenfügen eines neuen Bildes aus mehreren Tabellen dauert allerdings noch seine Zeit. Hier ist der Zugriff durch eine optimierte physische Verdrahtung schneller. "Der Preis für die Dynamik und Verarbeitungsfreiheit liegt also in der Geschwindigkeit," befindet der Münchner.
Der Trend, so ist von Spezialisten zu hören, geht dahin, unter relationalen Datenbanken häufig geforderte Verknüpfungen in ihrer Konzeption so zu gestalten, daß die Zugriffszeiten optimiert werden können.
Der nächste Schritt in der Entwicklungskette sind verteilte Datenbanken als Sonderfall der relationalen Datenbanken. Diese Systeme legen Daten nach Anwendungsgebieten auf dezentralen Einheiten ab.
Probleme gibt es hier bei der Transaktionsverarbeitung, da von mehreren Stellen aus auf die Daten zugegriffen werden kann. Eine der Hauptforderungen bei Datenbankanwendungen aber ist, nur vollständige Transaktionen abzulegen. Auch die Verwaltung der Daten an den unterschiedlichen Zugriffsorten macht noch Schwierigkeiten.
Aus Transaktionsgründen muß zum Beispiel bei Änderungen eine Bestätigung aller berechtigten Stellen über den ordnungsgemäßen Abschluß eingeholt werden. Die Aufteilung der Daten reicht heutzutage bis in Tupel-Größe, um die Lesegeschwindigkeit zu erhöhen. Das Zurückschreiben ist allerdings problematisch, weil der Comitt quadratisch mit der Zahl der Zugriffsberechtigungen wächst. Die mögliche Folgeerscheinung, ein rapider Ab ,fall der Performance, kann sich als eine echte Falle erweisen.
Vollkommen gelöst wäre das Problem der Performance bei relationalen DBs mit Assoziativ-Datenbankrechnern. Sie greifen nicht zu einem Zeitpunkt in genau eine Tabellenspalte, sondern parallel in verschiedene Tabellen mit der geforderten Relation. Serienreife Produkte in dieser Technik sind zur Zeit allerdings noch nicht bekannt.
Letztlich aber steht die Frage nach der geeigneten Datenbank in engem Zusammenhang mit der Modellierung der Datenstruktur und der Definition der Datenrelationen. Daher sollten Datenstrukturen so angeordnet werden, erläutert der Münchner MSP-Manager, daß sie vorerst vom Datenbanksystem völlig unabhängig sind.
Der Trend geht zu relationalen Systemen
Zum Abbilden der realen Welt unabhängig von der Technik eignet sich ein konzeptionelles Modell; für die Repräsentation eignet sich das Relationenmodell. Da ein konzeptionelles Relationenmodell leichter in ein relationales Datenbanksystem wenn auch nicht immer 1: 1 - zu überführen ist, als zum Beispiel in IMS, läuft der allgemeine Trend verstärkt hin zu Systemen Ó la DB2. Für die Umwandlung der konzeptionellen Definitionen bieten die Hersteller bereits technische Hilfsmittel an.
Ein großes Problem (insbesondere der verteilten Datenbanken) ist immer noch die Netz- und Rechnerverträglichkeit, meint der Münchner Datenbankspezialist. Während im kommerziellen Bereich IBM dominiert, sind im technisch-wissenschaftlichen Sektor meistens Nicht-IBM-Systeme zu finden. In einem heterogenen System wären für den ordnungsgemäßen Lauf verteilter Datenbanken zudem so etwas wie Gateways zur Kommunikation der Directories untereinander notwendig. Standards seien hier aber noch nicht in Sicht, erläutern Marktkenner.
Ein weiteres Problem sind die Datenbeschreibungen: Zwischen der inhaltlichen Beschreibung eines Datums aus kommerzieller und jener aus technisch-wissenschaftlicher Sicht klaffen häufig Welten, lehrt die Erfahrung. Hilfe böte hier ein Information Ressource Dictionary oder (in IBM-Terminologie) Repository, das die Abgrenzungen festhält und der begrifflichen Klarheit dient.
Um die gestiegenen Anforderungen an die Datenhaltung in einem Unternehmen erfüllen zu können, stellt sich die Frage, wie und vor allem, ob man auf ein neues DB-System umsteigen soll. Praktiker und Anwender sind der Meinung, daß für geraume Zeit hierarchische und relationale Datenbanken nebeneinander bestehen werden (siehe CW 23/88, Seite 7). Gleichzeitig sind sie auch der Überzeugung, daß hierarchische DBs langfristig nicht mehr zu halten seien.
Für die Übergangsphase ist es empfehlenswert, in die Entwicklung eines Datenkonzeptes im Rahmen einer unternehmerischen Gesamtsicht zu investieren, und sich auf eine Neuentwicklung der entsprechenden Anwendungen einzustellen.