In thematisch zusammenhängenden Beiträgen beschäftigt sich Michael Bauer mit Fragen das Ob und Wie einer Datenbank-Implementierung, der Auswahl eines geeigneten TP-Monitors und der Ausbildungserfordernisse je nach Benutzerebene. Außerdem stehen Themen wie Data Dictionary, Dritte Normalform, neue Hochsprachen und Datensicherheit im Mittelpunkt seiner Erörterungen.

* Michael Bauer, Leiter des Bereichs DV-Beratung bei der GES-Gesellschaft für elektronische Systemforschung mbH in Allensbach, ist seit vielen Jahren mit der Anwendungspraxis von Datenbank- und Online-Systemen vertraut. Er ist Autor zahlreicher Fachbeiträge zur DB/DC-Thematik.

Kapitel V, Teil 3:

Grundsätze für den Datenbankeinsatz

Strategische Planung

Phasenorientiertes Vorgehen

Der langfristige Prozeß der Implementierung eines Datenbanksystems läßt sich in einzelne überschaubare Abschnitte gliedern. In Abbildung 1 sind die acht Stufen dieses Prozesses veranschaulicht. Diese Reihenfolge sollte eingehalten werden, denn jede Phase baut sich sinnvollerweise auf den Ergebnissen der vorhergehenden auf. So ist es zum Beispiel wenig sinnvoll - aber leider oft Realität! -, daß ein DBMS ausgewählt wird, bevor man Oberhaupt weiß, was man damit realisieren und erreichen will; das heißt, bevor die Phase der Anwendungserschließung und -organisation stattgefunden hat.

Zeitfaktor berücksichtigen

Durch den Aufbau einer Datenbank verlagert sich der Arbeitsaufwand verstärkt in die Organisationsphase. Dies gilt besonders beim ersten Projekt; die später folgenden dagegen profitieren von diesen organisatorischen Vorleistungen. Bei der Planung des ersten DB-Projektes muß dieser Zeitfaktor berücksichtigt werden. Ein DB-Einsatz für ein Projekt, das eigentlich "gestern" schon hätte fertig sein sollen, ist ein hohes Risiko. Deshalb: Planen Sie die DV-Maßnahmen langfristig voraus, so daß Sie einen DB-Einsatz vorbereiten können, bevor das erste Projekt an der Tür steht!

Gesamtheitliche Datenorganisation

In einer Datenbank konzentrieren sich die Daten, die von verschiedenen Anwendungen benötigt werden. So werden in einem Industrieunternehmen die artikelbezogenen Daten nicht nur für die Fertigung und Materialwirtschaft, sondern auch für das Bestellwesen und die Auftragsbearbeitung gebraucht. Entsprechend sind die Bedürfnisse aller dieser Anwendungen beim DB-Design zu berücksichtigen. Die Datenorganisation sollte also anwendungsübergreifend durchgeführt werden.

Allerdings ist es kaum möglich, für ein Unternehmen eine umfassende Datenorganisation zu entwerfen, um schließlich darauf aufbauend die Anwendungen zu erstellen. Das wäre Sisyphosarbeit. Deswegen: Legen Sie großen Wert auf die Flexibilität (Anpassungsfähigkeit an Erweiterungen und Änderungen) des auszuwählenden DBMS. Relationale Datenbanksysteme bieten in dieser Hinsicht die größte Leistungsfähigkeit.

Migrationsfähigkeit

Das Teuerste einer DB-Implementierung ist die Umstellung bestehender Anwendung, nur weil die bisher verwendeten Dateien in eine Datenbank umgewandelt worden sind. Teuer deshalb, weil dieser Aufwand keinen Nutzen bringt. Zur Planung gehört es deshalb, auf eine sorgfältige Abgrenzung des Aufgabenkreises eines DB-Projektes zu achten und saubere Schnittstellen zu schaffen. In vielen Fällen ist es sinnvoller, die Daten zwischen den bestehenden Dateien und der Datenbank zu überspielen als unbeteiligte Anwendungen umzustellen.

Stabile Datenstrukturen schaffen

Eine Datenbank sollte so konzipiert sein, daß sie eine längerfristige Stabilität besitzt. Dies kann man durch ein datenorientiertes Design erreichen, das heißt, man entwirft erst die Zusammensetzung der Daten und die Beziehungen zwischen ihnen unabhängig vom einzusetzenden DBMS. Man spricht hierbei von einem "konzeptionellen Modell'.

Das konzeptionelle Modell spiegelt die Daten und informativen Beziehungen des jeweiligen Unternehmens wieder. Dadurch kann man erwarten, daß neue Forderungen die Datenorganisation prinzipiell nicht mehr umstoßen.

Erst danach wird das konzeptionelle Modell in ein "physisches Modell" überführt, das sich an den Möglichkeiten und Grenzen eines realen DBMS orientieren muß. Hierbei müssen Zugriffstechniken, Strukturierungsmöglichkeiten, Speicheroptimierung und andere berücksichtigt werden, Dieser Anpassungsaufwand ist abhängig vom eingesetzten DBMS. Bei einem relationalen DBMS kann das Modell 1 : 1 abgebildet, bei hierarchisch oder netzwerkorientierten Systemen muß es angepaßt werden. Die modernen Entwurfstechniken für konzeptionelle Modelle verwenden zwar Begriffe wie "Entity" oder "Dritte Normalform" - aber keine Sorge vor akademischer Komplizierung! Im Grunde genommen handelt es sich hierbei um recht einsichtige Vorgänge.

Humane Codes einführen

Datenbanken werden zunehmend in interaktiven Anwendungen eingesetzt. Bei der Neugestaltung der Datenbasis sollte man dies berücksichtigen, indem man die Verschlüsselung der Daten überprüft und gegebenenfalls neu konzipiert.

Die bisher verwendeten Schlüssel orientierten sich üblicherweise an den Verarbeitungsmöglichkeiten konventioneller Dateien und Batch-Programme. Entsprechend wurden meist numerische Codes verwendet. Diese erfordern aber einen fortlaufenden Umsetzprozeß, was dem Endbenutzer am Terminal - speziell beim Einsatz von Abfragesprachen - nicht zugemutet werden sollte. Sprechende, meist alphanumerische Schlüssel aber sind einfacher zu handhaben und weniger fehlerbehaftet. So ist es zum Beispiel günstiger, statt des synthetischen Länderschlüssels "04" für die Niederlande den Ländercode "NL" zu verwenden. Datenbanksysteme bieten uns die Möglichkeiten, solche "humanen Codes" problemloser einzuführen.

Data Dictionary von Anfang an

Die Entkoppelung der Datenorganisation von der Anwendungsentwicklung und die Zentralisierung der Verwaltung, die eine Datenbank mit sich bringt erfordert auch eine Übersicht und Kontrolle der Gesamtheit der Daten. Mit der Implementierung eines DBMS bietet sich auch die Chance, ein zentrales Datenverzeichnis zu schaffen, das alle Anwendungen versorgt.

So hatte beispielsweise ein Unternehmen festgestellt, daß es in über 1000 Programmen und 620 Dateien nur 700 verschiedene Datenelemente gab, die aber in jeder Anwendung anders bezeichnet und, beschrieben wurden. Wird fortgesetzt