Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Datenbanken und Zugriffssprachen


27.05.1983 - 

Mit Superdeskriptoren allen möglichen Zugriffen vorbeugen:Zunächst die eigene Begriffswelt ordnen

Datenbanken schaffen keine Ordnung, provoziert Alexander von Stülpnagel, Chef der Münchner Geschäftsstelle der MSP GmbH, sondern sie setzen im Gegenteil eine voraus. Unter Wert sieht er Datenbanken eingesetzt, wenn deren Datenbasen nur eine genaue Abbildung konventioneller Datenstrukturen ist. Im folgenden Artikel versucht Stülpnagel Denkanstöße zu geben, erst einmal die META-Daten zu strukturieren.

Fast jedes Unternehmen, das kommerzielle, betriebliche Abläufe mittels Datenverarbeitung online unterstützt, nutzt dazu die Funktionen eines Datenbanksystems. Unter Datenbanksystem sind dabei nicht nur die "klassischen" Datenbankmanagementsysteme von IMS bis UDS zu verstehen, sondern generell alle Softwaresysteme, die den Anwendungssystemen Funktionen für

- parallele Verarbeitung (Online und Batch)

- Wiederanlauf /Logging

- verschiedene Zugriffs- und Einstiegsarten

- Datenstrukturierungsmöglichkeiten

bieten. Gleichzeitig soll dabei möglichst Redundanz vermieden werden und die Inhalte jederzeit konsistent sein. Insbesondere durch die Forderung nach stärkerer Online-Unterstützung trat die Notwendigkeit auf neben dem sequentiellen Zugriff verschiedene schnellere - also direkte

- Zugriffe auf ein und denselben Datenbestand zu realisieren beziehungsweise neue Daten zu integrieren.

Dabei durften die bestehenden Anwendungen von solchen "Eingriffen"

in den Datenbestand nichts merken andernfalls wären solche Änderungen/Erweiterungen von vornherein nicht wirtschaftlich vertretbar gewesen.

Das war einfacher gesagt als getan, resultieren doch die meisten Datenbasen solcher Datenbanksysteme aus 1:1-Abbildungen von existierenden konventionellen Dateistrukturen. Trotz des heeren Anspruchs, der dem Management oft unter dem Zauberwort "Datenbanken schaffen Managementinformationssysteme" verkauft wurde, blieb man bei der alten Satzarttechnik mit hierarchischem Aufbau in Form von root-only Segmenten. Datenbanken wurden als

automatische Sekundär Indexverwaltungssysteme, bezogen auf operationelle Daten, unter Wert eingesetzt.

Wer aber den Schritt zur Gewinnung von dispositiven Informationen gehen wollte, erkannte die Notwendigkeit, solche "Datenbanken" in verschiedenen Applikationen - zumindest aus der Sicht der Anwender - zu einem Ganzen zu vereinen. Dazu war eine entsprechende Strukturierung der Datenmenge unumgänglich. So besann man sich auf die entsprechenden Funktionen des Datenbanksystems.

Man lernte also, wie ein hierarchisch strukturiertes System über "logical paired virtually relationship" zu einem Netzwerk zu vergewaltigen ist; oder welche Vorteile eine verkettete Anordnung in der Owner/Member-Zuordnung eines Codasyl-Systems für die gleichzeitige direkte und sequentielle Verarbeitung hat; oder welchen Sinn sogenannte Superdeskriptoren haben und wie man sie nutzen kann, um allen möglichen Zugriffen vorzubeugen.

Doch wer glaubte, mit diesen Voraussetzungen seine Daten ordentlich strukturieren zu können, wurde bald eines Besseren belehrt. Da stellte sich nämlich heraus, daß das Feld Umsatz in der einen Datenbasis konsolidierter Umsatz bedeutete, während in der anderen Datenbasis ebenfalls ein Feld Umsatz existierte, das nichtkonsolidierte Umsatzzahlen enthielt. Oder, was manchmal noch schlimmer war, daß Felder, die die gleichen Inhalte hatten, unterschiedlich benannt wurden.

Dies alles herauszufinden, dauerte oft länger als für die gewünschte Integration veranschlagt war und führte zu langen Auseinandersetzungen, welche Bezeichnung denn nun die richtige sei beziehungsweise welche Inhalte unter dieser Bezeichnung nun tatsächlich gespeichert werden sollten.

Geeignete Hilfsmittel die Ordnung in diese Begriffsvielfalt bringen, sind bekanntlich Data Dictionaries, mit denen verbindliche Definitionen, beispielsweise von Datenfeldern, festgelegt werden können. Aber auch diese Systeme können die Vergangenheit - sprich die "Unordnung" nur teilweise bewältigen. Ein Data Dictionary ist deshalb eine Investition für morgen, um die Investition von gestern - das Datenbanksystem - mit seinen ganzen Möglichkeiten für die dispositive und integrierte Informationsgewinnung zu nutzen.

Erst wenn ein solches Ordnungssystem geschaffen ist, die Meta-Daten also geordnet sind, können die tatsächlich physisch gespeicherten Anwenderdaten aktuell und integer zur Verfügung gestellt werden. Daran werden auch die heißersehnten relationalen Datenbanksysteme genausowenig ändern, wie die Programmiersprachen der 4. Generation mit ihren relationalen Abfragekonstruktionen.

Die Ordnung der Meta-Daten beantwortet jedoch noch nicht die Frage, nach welchen Gesichtspunkten die umfassende Datenbasis selbst zu strukturieren ist, um den teilweise gegenläufigen Forderungen nach

- Schneller Verarbeitung einerseits

- optimaler Speicherung andererseits

- Änderungsflexibilität und

- Zugriffsschutz

Rechnung zu tragen. In vielen Fällen sind heute die Restriktionen der derzeit eingesetzten Datenbanksysteme wie auch die Menge der derzeit realisierten Anwendungen Maßstab für die Findung des geeigneten Kompromisses. Nur wenige Unternehmen haben erkannt, daß eine Ordnung auf höherer Stufe eine längerfristige Basis bietet und damit strategisch gesehen ein sicherer Maßstab ist.

Eine solche höhere Stufe bilden sogenannte Datenmodelle für das Unternehmen, die die Zusammenhänge über alle die Dinge, die für das Unternehmen von Interesse sind, über die also möglicherweise etwas gespeichert werden könnte, aufzeigen. Aus diesem Modell können nicht nur zukünftige Planungen abgeleitet werden, sondern an ihnen lassen sich auch die für bestimmte Anwendungen notwendigen Datenbankstrukturen messen. Denn dieses Modell beinhaltet die immanenten Gegebenheiten und ist deshalb zwangsläufig genauso stabil, wie das Unternehmen selbst.

Wie die Fachabteilung mit diesen Daten arbeitet, wird dann wiederum die datenbankspezifische Struktur, das heißt die Kompromißbildung im obigen Sinne beeinflussen. Jedoch kann davon ausgegangen werden, daß die Strukturen als solche weniger geändert und damit Erweiterungen leichter durchgeführt werden können, als im bisherigen Vorgehen.

Wer also die Investitionen für ein Datenbanksystem optimal nutzen will, indem er Unternehmensweite Datenbasen aufbaut, deren Nutzen für die Sachbearbeiter wie für das Management heute unumstritten ist, muß zunächst seine Begriffswelt in Ordnung bringen, um anschließend seine Datenstruktur an dem Unternehmen und nicht an dem bestehenden Datenbanksystem zu orientieren. Erst wenn diese - man könnte sagen Meta-Welt - in Ordnung gebracht ist, können die Daten selbst die relevanten Informationen liefern und damit (hoffentlich) die gewünschte Ordnung im Unternehmen herstellen.