Als Voraussetzung für den wirtschaftlichen Einsatz eines Datenbanksystems gilt die Koordination des organisatorischen und DV-technischen Umfelds von zentraler Stelle aus. Dabei sollten die komplexen DB-Aufgaben von einer "Spezial"-Abteilung, zumindest jedoch von einem Datenbank Administrator wahrgenommen werden. In den meisten Unternehmen ist eine derartige Institution noch nicht vorhanden. DB-Aufgaben werden meist ohne entsprechende Kompetenzen nur "nebenbei" wahrgenommen. Wer sich allerdings den Luxus eines DB-Systems leistet, sollte sich auch eine starke DB-Mannschaft leisten. Andernfalls könnte der Schritt in die Datenbank-Zukunft zu einem weiteren traurigen Kapitel im Buch der Softwarekrisen werden. ih

Claus Weichselbaumer Unternehmensberater, München

Ein problemloser, zufriedenstellender und wirtschaftlicher Einsatz eines Datenbanksystems kann erfahrungsgemäß nur dann erreicht werden, wenn das DB-System (einschließlich Datenbasis) und sein organisatorisches und dv-technisches Umfeld von Anfang an von zentraler Stelle aus organisiert und koordiniert werden. Da die Aufgaben, die dieser Stelle obliegen, vielseitig, umfangreich und komplex sind, werden sie meist von einer Abteilung, Dienststelle oder Gruppe wahrgenommen. Ein einzelner Datenbank-Administrator

wäre durch die Fülle der Aufgaben hoffnungslos überfordert. Der Leiter dieser Stelle (man kann in ihm den eigentlichen DB-Administator sehen), trägt die zentrale Verantwortung für das DB-System. Er muß mit entsprechenden Kompetenzen ausgerüstet sein, da er die schwierige Aufgabe hat, die fast immer divergierenden Anforderungen von Software-Entwicklern und anderen DB-Benutzern zu Koordinieren und im Sinne der Gesamtwirtschaftlichkeit von Software-Entwicklung und -Betreuung und Datenbankeinsatz zu optimieren.

Zu den Aufgaben der DB-Administration zählen außerdem:

- das DB-Design (Basis: Informationsanalyse und Mengengerüst)

- die Unterstützung des DB-Einsatzes im RZ

- die Berücksichtigung von Fragen des Datenschutzes

- die Beratung und Ausbildung der Software-Entwickler

- das Design und die Implementierung von Zugriffsmoduln

- das Erstellen zusätzlicher DB-Dienst-und-Korrekturprogramme und

- die laufende DB-Dokumentation.

Die Verantwortung für einen reibungslosen Betrieb des Datenbanksystems, für die Durchführung der Datensicherung und den ordnungsgemäßen Wiederanlauf nach abnormaler Systembeendigung liegt im Rechenzentrum, wobei entsprechende Regelung und Vorgabe der DB-Administration beachtet werden müssen.

Wer sich den Luxus eines DB-Systems leistet, muß auch bereit sein, den Aufwand für eine starke und leistungsfähige Mannschaft zur DB-Administration zu tragen, wenn der Schritt in die DB-Zukunft nicht zu einem weiteren traurigen Kapitel im Buch der Software Krisen werden soll.

Die Entscheidung, ein Datenbanksystem einzusetzen, fällt als Konzession an die Zukunft. Sie wird meist im Zusammenhang mit einem umfangreichen Software-Projekt getroffen, das im Rahmen einer Ablöse-Strategie von Alt-Verfahren gleichzeitig zum Ziel hat, die systemtechnische Basis für die Zukunft der Datenverarbeitung einer Unternehmung zu bilden.

So gesehen erfolgt der Einsatz von Datenbanksystemen wohl eher unter Integrationsaspekten als für Einzelsysteme auch wenn expliziert formulierte Ablöse-Strategien und langfristige DV-Konzepte noch eine Seltenheit sind. Begonnen wird der Einsatz von DB-Systemen meist mit einem Einzelsystem. Wenn dabei aber keine mittelfristige und langfristige DB-Planung durchgeführt wird, besteht die Gefahr, daß der Traum von wirtschaftlicher DV-Integration zum teuren DB-Alptraum wird.

Der Einsatz eines Data Dictionary, ob manuell geführt oder dv-technisch unterstützt, ist nicht nur sinnvoll, sondern unumgänglich. Für jede Datenbank-Area, jeden Set, jede Satzart und jedes einzelne Datenfeld muß jederzeit der vollständige Verwendungsnachweis geführt werden können.

Es muß feststellbar sein wer für einzelne Felder die Verantwortung trägt (zum Beispiel welche Fachabteilung), welche Programme welche Datenfelder pflegen (im Sinne der Aktualisierung von Konstanten, wie z.B. bei Preisen, Artikelbezeichnungen), welche Programme Datenfelder modifizieren (zum Beispiel Buchung von Bestellungen) und welche

Programme nur lesend auf Datenfelder zugreifen. Auf Satzart-Ebene muß feststellbar sein, welche Programme neue Sätze in die Datenbank einspeichern.

Dieses Wissen ist unabdingbare Voraussetzung für die Betreuung, für die Fehlersuche bei Datenverfälschung (ein Programm, das Sätze zugreift ist wohl nie Verursacher), für Redesign-Maßnahmen und für Optimierungsentscheidungen. Neben der Datenbeschreibung und dem Verwendungsnachweis von Daten, sollten in einem Data Dictionary auch Angaben zum Mengengerüst (Anzahl Owner-Sätze, Anzahl Member-Sätze je Owner etc.) enthalten sein.

Ob der Einsatz von Datenbanksystemen wirtschaftlich ist, läßt sich mit letzter Konsequenz nicht behaupten. Zu vielseitig sind die Faktoren, die die Wirtschaftlichkeit des DB-Einsatzes beeinflussen. Ein hieb- und stichfester Nachweis daß sie es sind, wird, wie im DV-Geschäft üblich, weder von Managern gefordert, noch von Software-Entwicklern und DB-Administratoren erbracht. Andererseits wurden die Argumente, die von den Entwicklern von DB-Sytemen ins Feld geführt werden, und die bei konsequenter Berücksichtigung einen wirtschaftlichen Gewinn versprechen, bis heute nicht widerlegt.

Wolf-Dietrich Wrack Selbständiger Unternehmensberater, Augsburg

Hat sich ein Unternehmen für den Einsatz eines DBMS entschieden, sind für die Zukunft nicht nur Weichen gestellt, sondern es wurde auch in nicht geringem Umfange investiert. Die Weichenstellung der künftigen Konzeption ergibt sich zwangsläufig aus der integrierten Datenhaltung eines DBMS. Dieses System einzig zur Abwicklung singulärer oder mehrerer Minisysteme einzusetzen, hieße doch, mit Kanonen auf Spatzen zu schießen. Nicht zuletzt die vergleichsweise hohen Kosten sprechen dagegen. Nützlich und kostendeckend wird ein DBMS in aller Regel nur dann arbeiten wenn es in der Firmen-EDV eine zentrale Rolle spielt oder in Zukunft erhalten soll. Was die Investitionen für ein DBMS anbetrifft, sollte sich jeder darüber klar werden, daß es mit der monatlichen Miete für das Produkt nicht getan ist.

Den flotten Sprüchen der Hersteller ist stets mit gesundem Mißtrauen zu begegnen: Es gibt noch immer nicht die reorganisationsfreie DB, das sicherungsarme DBMS, das einfach zu handhabende DBMS das DBMS, das nur noch Hilfskräfte erfordert. Als absolute Aussagen sind diese Dinge schlicht falsch, allenfalls besitzen sie eine Berechtigung in Relation zu andern existierenden DB-System. Die Wirklichkeit sieht immer noch so aus daß das Operating, die AV, die Programmierer-, die Anwendungsentwicklung, die Systemgruppe und nicht zuletzt das Management mehr oder minder stark geschult werden muß, um sich in der veränderten Umgebung sicher bewegen zu können. Dabei hat sich in der Vergangenheit immer wieder gezeigt: Steht das Management voll hinter der Entscheidung für ein DBMS, so ist der Erfolg oft trotz mangelndem personellem Equipment gesichert. Andererseits fehlt die Unterstützung, können meistens auch gute Leute nur den Mißerfolg garantieren.

Zu einer positiven Haltung des Managements gehört zum Erfolg, aber auch das solide handwerkliche Können der anderen angesprochenen Gruppen. Ist das Unternehmen klein, die Anwendung gering in Umfang und Bedeutung reicht eine Schulung beim Hersteller oder einem anderen professionellen Schulungsunternehmen aus, sofern das Wissen alsbald in der Praxis angewandt wird. Wenn allerdings der Schritt zur Groß-EDV getan ist, reichen Schulungsmaßnahmen alleine nicht aus dann braucht man, um in der Terminologie zu bleiben, einen permanenten Referenten im Haus: Den Datenbank-Administrator. Der DBA soll, nur um einige der bekannten Qualifikationen zu wiederholen, die vielfältigen DB-Aktivitäten eines Unternehmens koordinieren, Standards entwickeln und bereitstellen und allgemeinen User-Support geben. Leider ist der DBA in den Unternehmen oftmals gar nicht vorhanden, oder er versieht die Aufgaben "nebenbei" oder, am schlimmsten, bekommt den Titel zugewiesen, aber weder Aufgaben noch die notwendigen Kompetenzen.

Es gilt abschreckende Beispiele in unserer Wirtschaft, wo die Bedeutung eines DBA nicht erkannt wurde, und es heute identischer Software praktisch jeweils ein DBMS für Fertigung, für Material, für Buchhaltung und eines für Lohn gibt. Hier sind die Dinge ohne DBA derart auseinander gewachsen, daß eine Reduktion auf gemeinsame Standards nicht möglich ist. Zusätzlich zu den personellen Investitionen müssen sinnvollerweise sachliche treten. Denkbar ist, daß beispielsweise die Online- und Batch-up-dates zu einem vernünftigen Recovery-System zusammengefügt werden. Weiterhin ist über den Einsatz eines Dictionary-Systems nachzudenken. Auch hier gilt das zum DBA Gesagte analog: Einmal Versäumtes ist nur unter schwierigsten Bedingungen nachzuholen, und deshalb unterbleibt es meistens. Ist aber ein Dictionary nicht vollständig oder inkonsistent, verliert es Wirkung und Berechtigung und die erheblichen Kosten hierfür sind umsonst ausgegeben. Diese Dinge sollten beim Einsatz eines DBMS grundsätzlich untersucht werden, wobei es unverzeihlich erscheint, die Infrastruktur in Form von DBA, Dictionary und anderen- Tools zu vernachlässigen. Oftmals ist ein um das Vielfache größerer Aufwand nötig, um Fehlentwicklungen zurückzudrehen.

Michael Rostaher Leiter EDV-Entwicklung, Merkur-Versicherung, Graz, und Dieter Rohlfing

Berater "Datenbankgestützte Informationssysteme", mbp, Dortmund

Es setzt sich zunehmend die Erkenntnis durch, daß Informationen ein genauso wichtiger Faktor in einem Unternehmen sind wie zum Beispiel Kapital und Produktionsmittel. So mehren sich auch die Stimmen, die für diese Ressource eine eigene Position fordern: den Informationsmanager. Der Datenbank-Administrator als reiner Verwalter der Daten ist zu wenig. Der Informationsmanager muß die Position - und den Einfluß haben, um eine vernünftige, dem Unternehmen adäquate Informationspolitik durchsetzen zu können. Information ist das Blut in einem Unternehmen und damit von lebenswichtiger Bedeutung.

Das Informationsmanagement muß von einem leistungsfähigen Informationssystem unterstützt werden. Was dem Körper seine Adern und Venen sind, stellt für ein Unternehmen sein Kommunikationsnetz dar. Für die Speisung und Verwaltung des Inhaltes ( = Daten, die Informationen repräsentieren) in diesem Netz sind ein oder mehrere Datenbankverwaltungssysteme mit ihren angeschlossenen Datenpools zuständig.

Die Forcierung eines integrierten, das ganze Unternehmen umfassenden Informationssystems wird weitergehen. Der Einsatz eines Datenbanksystems zur Unterstützung beziehungsweise Realisierung eines Einzelsystems wird daher in der Zukunft wohl die Ausnahme bleiben.

Die Vielfalt und Verschiedenartigkeit der in einem integrierten Informationssystem vorkommenden Daten legt es nahe, die Informationen über die Information (der Informatiker spricht von Meta-lnformationen) mit ähnlichen Hilfsmitteln zu verwalten, wie die eigentlichen Daten. Genau das tun Data-Dictionary-Systeme. Im Grunde genommen sind sie nichts anderes als Datenbanksysteme, die alle Angaben über Felder, Dateien, Sätze, Beziehungen zwischen diesen sowie Konvertierungs- und Abbildungsvorschriften enthalten.

Die Frage, sie lange sich solch ein Informationssystem nutzen läßt, hängt vorwiegend von der Architektur und dem Konzept ab, das dem ganzen zugrunde liegt. Eine sorgfältige Anforderungsanalyse und ein darauf aufbauender, methodischer Lösungsansatz sind die Garanten der Rentabilität. Wer in dieser Phase spart zahlt später mehrfach darauf.

Gute Lösungen zeichnen sich durch ein hohes Maß an Flexibilität, Transparenz und Einfachheit aus. Ein Lösungsansatz sollte nach Möglichkeit nicht auf bestimmte Eigenarten irgendwelcher Produkte basieren. Besser ist es, seine Lösung in mehreren Ebenen zu organisieren: Die oberste stellt die anwendungsorientierte, logische Lösung dar, die unterste deren technische Realisierung. Je nach Komplexität des Informationssystems wird man eventuell noch einige Ebenen dazwischenschalten.

Ein derart konzipiertes System wird durchaus eine Dekade bestehen können.