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.

Relationale Datenbanken entlasten Benutzer und Programmierer:


03.12.1982 - 

Mehr Augenmerk aufs Interface

So wichtig eine Datenbank für die schnelle und umfassende Information in einem Unternehmen ist, so vielfältig sind aber auch die Probleme, mit denen der Datenbankadministrator in seiner täglichen Arbeit zu kämpfen hat. Nicht nur Strukturen bereiten Kopfzerbrechen, auch Fragen wie Bindung an den Hersteller oder Bereitstellung spezialisierten Personals zur Datenbankpflege wollen gelöst sein. Datenbankberater Johann R. Rinner von der Münchner CAM GmbH diskutiert in seinem Beitrag Problemkreise und zeigt anhand eines im CAM-Vertrieb befindlichen Systems konzeptionelle Lösungsmöglichkeiten auf.

Die Problematik bei den Betreibern universeller Datenbanksysteme mit umfangreichen Datenbeständen ist weitgehend dieselbe. Hierbei spielt die Branche, der der Betrieb angehört, nur eine untergeordnete Rolle. Deutlich ist oft ein gewisses Unbehagen gegenüber dem (eingesetzten) Datenbanksystem herauszuhören. Dieses Gefühl beruht meist auf einer vorhandenen Unsicherheit, bedingt durch die Komplexität und Unübersichtlichkeit des Datenverwaltungssystems. Dies kann natürlich zu einer Art "Black-box-Denken" führen, mit der Konsequenz, auftretende Probleme zurückzustellen oder beiseitezuschieben. Noch weitaus mehr Verunsicherung ist im allgemeinen bei Unternehmen vorzufinden, die sich in der Auswahlphase für ein DB/DC-System befinden. Die Angst vor dem "Seiltanz ohne Netz" oder dem "Weg ohne Umkehr" liegt begründet in der zu erwartenden Herstellerabhängigkeit sowie der Frage nach der Anpassungsfähigkeit des Systems an zukünftige Anforderungen.

Ursachenanalyse vorrangig

Weitere oft genannte Schwachstellen allgemeiner Art liegen in der aufwendigen Datenmanipulation begründet. Aus der Sicht des Managements treten Probleme der Datenbankauswahl und der Bereitstellung spezialisierten Personals auf. Anders gelagert sind wiederum die Beschwerden der Organisatoren, Programmierer und Datenbankadministratoren. Die Liste reicht hier von Schwierigkeiten mit den Datenbankstrukturen bis hin zu Designproblemen wegen unvollständiger Informationen über zukünftige Anforderungen an die Datenbanken.

Natürlich sind diese Schwachstellen allgemein bekannt und haben für die verschiedenen Unternehmen unterschiedliche Gewichtung und Bedeutung.

Der erste Schritt zur Behebung von Schwachstellen muß die Ursachenanalyse sein. Die Klassifizierung der erläuterten Probleme läßt folgende grundlegende Ursachen erkennen:

- (bewußte) Produktinkompatibilität verschiedener Hersteller und

- komplexe, unübersichtliche Daten und Systemstrukturen (Datenmodelle).

Nun existieren hierzu seit langem bekannte Lösungsideen, sowohl theoretischer als auch praktischer Natur, jedoch mangelt es bisher an einer Synthese der Lösungsvorschläge auf fundierter theoretischer Basis einerseits und einer die praktischen Bedürfnisse abdeckenden Implementierung andererseits.

Geeignete Antworten konzeptioneller Art auf die genannten Ursachen sind:

Vereinfachte Datensuche

Die schichtenartige Architektur des Datenbanksystems, eine neutrale, einfache Schnittstelle vom Benutzer (Anwendungsprogramm) zum Datenbanksystem und die Verwendung eines einfachen, flexiblen Datenmodells auf Benutzerebene (logischer Ebene) des relationalen Datenmodells.

Eine Lösungskonzeption soll im Folgenden diskutiert werden. Die relationale Sicht und Verarbeitung der Daten von der Benutzerwarte her gesehen, impliziert Programme ohne die die DB-Navigation betreffenden Spezifikationen sowie ohne Abbild eines DB- Strukturausschnittes.

Kenntnisse der DB-Strukturen werden vom Benutzer (Anwendungsprogrammierer) nicht mehr gefordert.

Weiterhin "sieht" der Benutzer (das Anwendungsprogramm) nur noch relevante Daten. Das Handling zusätzlicher, nicht benötigter Datenbereiche entfällt. Der Relationen- und Beschreibungspool dient als Informationsgrundlage für den Datenbankadministrator und spiegelt die aktuellen Benutzeranforderungen an die Datenbanken wider.

Die physische Beschreibung formuliert den vollständigen Ist-DB-Zustand. Hierbei lautet die wesentliche Forderung, daß sowohl existierende Datenbanken oder Dateiensysteme als auch hierarchische und Netzwerkstrukturen dargestellt werden können. Zentrale Bedeutung besitzen die Umsetzungs-(Transformations-)Schichten, wodurch Änderungen von Datenbankstrukturen absorbiert werden, die somit keinesfalls in das Anwendungsprogramm durchschlagen. Es ist sogar möglich, das Datenbankmanagementsystem auszutauschen, ohne ein einziges Anwendungsprogramm anpassen zu müssen.

Implementierung nicht trivial

Der Übergang zur Praxis, zur Implementierung, ist jedoch keineswegs trivial. Bei genauerer Betrachtung des vorliegenden Konzepts stößt man schnell auf Problemzonen wie die folgenden:

a) Die Relationenmanipulation ist auf Mengenoperationen aufgebaut. Die kann zu Performanceproblemen führen.

b) Die physische Datenstruktur ist nicht relational, sondern hierarchisch oder vernetzt.

c) Wie kann das Interface beim Austausch des Datenbanksystems mit geringem Aufwand angepaßt werden?

d) Die Relationen können Attribute (Felder) aus verschiedenen Segmenttypen anfordern. Wie sind die Transformationsregeln Relation - physische DB-Beschreibung in den Griff zu bekommen und welche Restriktionen sind nötig?

e) Wie soll die einfache, neutrale Schnittstelle Benutzer (Anwendungsprogramm) - Interface aussehen?

f) Wie werden die Anwendungsprogramme auch vom eingesetzten DC-System unabhängig?

Tupel für Tupel bereitstellen

Um die nötige Akzeptanz für das Interface sowohl beim (DB)-Programmierer als auch beim Anwender in der Fachabteilung zu finden und um den Übergang für den Programmierer kontinuierlich zu gestalten, ist es naheliegend, dem Programm Tupel für Tupel seiner Relation auf Anforderung zur Verfügung zu stellen sowie der Fachabteilung eine einfache Online-Abfragemöglichkeit auf derselben Grundlage anzubieten. Dies wirft keine speziellen Performanceprobleme auf und eröffnet dennoch so gravierende Vorteile des Relationenmodells wie Stabilität, Ausgewogenheit und Übersichtlichkeit. In einem zweiten Schritt kann dann eine mächtigere Querysprache realisiert werden.

Der größte Aufwand für die Entwicklung des Interface liegt natürlich in der Erstellung der Routinen für die Interpretation der Relationenbeschreibungen, physischen DB-Beschreibungen sowie der Kommunikation mit dem Datenbanksystem. Modularer Aufbau der Routinen wie auch Performancegesichtspunkte stellen hierbei die Prämissen dar, jedoch sollen die wichtigsten erforderlichen Aktionen skizziert werden:

- die der Relation zugeordnete physische DB-Beschreibung muß interpretiert werden,

- der geeignete Datenbankzugriffspfad ist aufzusuchen,

- aus den verschiedenen DB-Segmenten sind die benötigten Datenfelder zu extrahieren,

- die Datenfelder sind zu konvertieren, um die vom Benutzer gewünschte Form zu erhalten,

- die Dateninhalte sind in die Relationen einzusetzen.

Neutrale Schnittstellen

Letztlich müssen Fehlerdiagnosen durchgeführt werden und Daten sowie eventuelle Fehlermeldungen beziehungsweise Informationen an den Benutzer übergeben werden.

Die einfache, neutrale Schnittstelle Benutzer (Anwendungsprogramm) - Interface ist durch die zugrunde liegende Konstellation bereits vorgezeichnet. Die im Aufruf enthaltenen Spezifikationen beschränken sich auf den Namen der Relation, die Identifikation des Benutzers, Verarbeitungswünsche wie Lesen, Einfügen, Löschen, den Datenbereich und den Fehler- und Informationsbereich. Die zusätzliche Option, den Zielort der Relation (zum Beispiel Datenbank, Drucker, Bildschirm) zu bestimmen, und etwa dem Zielort Bildschirm ein individuelles, außerhalb des Anwendungsprogrammes liegendes Modul zuzuordnen, erlaubt es dem Anwendungsprogramm, sowohl für DB- wie auch für DC-Aufrufe eine einheitliche Notation ohne DB/DC-spezifischen Code zu verwenden.

Online-Erfassung bewährt

Des weiteren ist es unabdingbar, die erforderlichen Definitionen und Beschreibungen für Relationen und DB-Strukturen möglichst komfortabel und einfach zu gestalten. Eine Menü-gesteuerte Online-Erfassung hat sich optimal bewährt.

Bei der Entwicklung von GDI (General Database Interface) wurden verschiedene praxisrelevante Zusätze berücksichtigt. So können beispielsweise Benutzertabellen ebenso wie Relationen über Bildschirm erfaßt und gewartet werden, wobei sich eine etwaige Änderung von Tabelleninhalten sofort auf darauf zugreifende Anwendungen auswirkt. Weiterhin ist es möglich, sowohl Relationen als auch physische DB-Beschreibungen ohne Anwendungsprogramm im Dialog zu testen. Ebenso kann ohne Anwendungsprogramm mit dem Datenbanksystem kommuniziert werden, wobei, falls gewünscht, die Manipulation der Tupel der Relationen möglich ist. Der Datenschutz wird unterstützt durch Benutzeridentifikation sowie Restriktion der Verarbeitungsmöglichkeiten einer Relation.

Die Bindung an das verwendete DBS reduziert sich. Ein Wechsel des Systems wird erleichtert, da die Umstellung der Anwendungsprogramme entfällt.

Strukturänderungen der Datenbank erfordern keine Änderung in den Anwendungsprogrammen. Der Anwendungsprogrammierer benötigt (fast) keine Kenntnisse über das eingesetzte Datenbanksystem beziehungsweise die Datenbankstrukturen.

Die Performance der einzelnen Anwendungen und insbesondere des Gesamtsystems hängt nicht mehr von der "Güte" des Anwendungsprogrammierers ab, sondern von den Qualitäten des Datenbankadministrators, welcher die physische DB-Beschreibung zentral erstellt und verwaltet.

Die daraus abzuleitenden Kosteneinsparungen in den Bereichen Softwareentwicklung und -wartung sowie Ausbildungs- und Personalkosten können manches angespannte DV-Budget entlasten.