Die Diskussion um das optimale Datenbanksystem bewegt sich nach Ansicht von Sepp Kraus heute auf einem Level, der mit dem, was vernünftig realisierbar ist, nichts mehr gemein hat. Der Autor stellt dar, welche Faktoren wichtig sind, damit ein Datenbanksystem optimale betriebswirtschaftliche Nutzenpotentiale bietet.

Auf das Phänomen Datenbank passen viele Beschreibungen: Objekt strategischer Unternehmensentscheidungen, Verwalter und Träger des neuen Produktionsfaktors Information, Hilfsmittel zur Verdunkelung fehlender organisatorischer Infrastruktur, fehlender Produktivität in der Software-Entwicklung und fehlender Konzeption im Informationsverarbeitungs-Bereich, Hindernis beim Umgang mit neuen Technologien und geliebtes Spielzeug von DV-Freaks - aber auch: ernstgenommene technologische Möglichkeit für einen Schritt ins Informationszeitalter.

Codasyl-Datenbanken sind noch nicht tot

Es ist nicht einfach, ein Produkt zu beschreiben, das wie kein anderes in der Geschichte der Informationsverarbeitung neue Wege und Chancen eröffnet hat und komplexe informationsbezogene Unternehmensziele durchführbar werden ließ. Etwa 25 Jahre lang wurde das Datenbankmanagement-System (DBMS) als integriertes und sicheres Daten- und Dateiverwaltungssystem verstanden.

Im Einsatz waren vorwiegend Systeme mit hierarchischer beziehungsweise mit Codasyl-Struktur. Diese Systeme können heute noch dem Anspruch eines sicheren Daten- und Dateiverwaltungssystems genügen und insbesondere in operativen Anwendungsbereichen immer wieder ihre (Performance-)Qualitäten beweisen.

Eine neue Generation von Datenbanksystemen erwuchs in den 80er Jahren mit der Idee der Relationentheorie: Relationale Datenbankmanagement-Systeme (RDBMS) prägen seither ein neues Bild der Informationsverarbeitung. Noch ist diese Technologie kaum den Kinderschuhen entwachsen, schon bemühen sich Wissenschaftler um eine neue Orientierung in der Strukturierung und Verarbeitung von Daten. "Objektorientiert" lautet das Stichwort - dabei haben die meisten Unternehmen bisher nicht einmal ihre einfache Informationsstruktur im (relationalen) Griff.

Wie aber muß eine zeitgemäße Informationsverarbeitungs-Umgebung aussehen? Welche Fähigkeiten muß ein Datenbanksystem aufweisen, um den heutigen Anforderungen standhalten zu können? Die Zukunft der wirtschaftlichen Entwicklungen ist eng mit der Zukunft der Informationsverarbeitung (IV) verbunden. Die Megatrends kann man schon seit einigen Jahren erkennen:

- Indikatoren wie steigende Leistung bei gleicher Technik, neue Hardware-Entwicklungen ( "Connection machine", Vektorrechner, assoziative Speicher) deuten darauf hin, daß der technische Fortschritt weitergeht;

- weltweite Produktionsteilung durch weiteres Zusammenwachsen der Märkte;

- steigende Vernetzung der IV-Ressourcen auf allen Ebenen (LAN, WAN);

- mehr Rechnerleistung, Parallelverarbeitung, Dezidierung der Systemaufgaben, Implementierung von Systemdiensten in Hardware beziehungsweise Firmware (zum Beispiel SQL-Prozessor, DB-Optimizer), Mehrprozessorsysteme als ausfallsichere Systeme, intelligente Netze;

- massiver Zeit- und Kostendruck in allen (nicht-kartellisierten) Märkten. Damit sinkt die verfügbare Reaktionszeit für Entscheidungen ebenso wie die erlaubte Zeit für Entwicklung und Markteinführung neuer Produkte;

- Flexibilisierung von Produkten und Dienstleistungen: Die Hinwendung von der produktions- zur absatzorientierten Unternehmensorganisation ist bereits erkennbar;

- zunehmende Durchdringung aller Bereiche mit Informatik: Die Zukunft wird geprägt sein vom Bedarf an wachsenden Mengen verfügbaren Wissens von hoher Qualität. Daher wird es darauf ankommen, relevante Informationen zum rechten Zeitpunkt in der richtigen Konsistenz zu erhalten.

Alle genannten Trends führen zu genau definierbaren Anforderungen an heutige und zukünftige Informationsverarbeitungs-Umgebungen einschließlich den zugehörigen Datenbanksystemen.

Mit den Zielen eines Unternehmens werden die Forderungen an das eingesetzte Datenbanksystem und seine Umgebung formuliert. Es gehört heute Mut dazu, technische Neuentwicklungen und Konzepte abzulehnen. Ein klares IV-Konzept und eine transparente unternehmensorientierte Informationsverarbeitungs-Strategie geben die nötige Sicherheit, um im allgemeinen Technologierausch die strategisch richtigen und nutzenorientierten Entscheidungen zu treffen.

Oft werden von Herstellern Erwartungen geweckt, die sich beim praktischen Einsatz nicht bestätigen. Was bleibt sind Zeitverluste, Kosten und die Enttäuschung der Beteiligten. Als Beispiele könnten Bereiche genannt werden wie

- Expertensysteme,

- CASE-Produkte (ohne organisatorische Infrastrukturen),

- Management-Informationssysteme (ohne genügende Datenbasis),

- Data-Dictionary-Systeme (ohne Integration in das Datenverwaltungssystem),

- Datenbanksysteme (ohne Integrationsfähigkeiten in die DV-Historie des Unternehmens) etc.

Projekte dieser Art hatten in der Vergangenheit eines gemeinsam: Der Ablauf von der Euphorie- über die Spielphase bis hin zur produktiven Einsatzkonzeption - und dann die mehr oder weniger große Frustration. Die offensichtliche Fehleinschätzung dieser Produkte rührt möglicherweise daher, daß der Vergleich technischer Funktionen verschiedener Systeme noch längst keine Nutzenaspekte für einen betriebswirtschaftliche Einsatz transparent macht.

Es ist an der Zeit, daß die Informationsverarbeitung ihre Dienstleistungen dem Kunden erschließbar macht. Kostenfaktoren und Nutzenindikatoren müssen einander gegenübergestellt werden. Das hauptsächliche Problem dabei liegt darin daß jedes Unternehmen für sich die unternehmensindividuellen Nutzenpotentiale selbst eruieren und die daraus resultierenden Ziele definieren muß.

Einige Beispiele für mögliche Ziele seien hier skizziert:

- rechtzeitige und bedarfsgerechte Entwicklung von unterstützenden IV-Applikationen (Anwendungsstau);

- organisatorische und anwendungsbezogene Änderbarkeit zu jedem Zeitpunkt oder zumindest in vertretbaren Zeiträumen (Wartungsaufwand und Flexibilität);

- Applikationen, die den Anforderungen der Benutzer entsprechen (Qualität);

- Möglichkeit der präzisen Formulierung von Anforderungen durch die (späteren) Benutzer (Spezifikationsergonomie);

- kalkulierbare Kosten und Zeiten für Entwicklung und Wartung (Akzeptanz);

- Verfügbarkeit getätigter Investitionen weiterhin (Investitionssicherheit).

Nur ein Teil dessen, was bisher schiefgelaufen ist, kann dem IV-Baustein "Datenbankmanagement-System" angelastet werden.

Eine funktionsfähige (integrierte) IV-Umgebung besteht aus mehreren gleichwertigen Komponenten, die in ihrer Funktion zusammenwirken müssen, damit synergetische Effekte eintreten.

Die Frage nach den Nutzenpotentialen der IV und damit nach den Anforderungen an eine DBMS-Umgebung kann, wie schon erwähnt, nicht generell beantwortet werden. Der Einzelfall ist entscheidend. Nutzenpotentiale lassen sich nur konsequent erschließen, wenn die Planung der Information als Ressource im Unternehmen auch eine Informationstechnologie-Strategie beinhaltet. Dazu gehören

1. Anwendungsentwicklungs-Strategien:

- Methoden und Standards des Software-Engineering, zum Beispiel CASE-Unterstützung;

- organisatorische Vorgaben (Information Center, Qualitätssicherung, Datenmanagement, Projektvorgehen etc.);

- Techniküberlegungen (Datenbanksysteme, Entwicklungs- und Werkzeugumgebungen, Data-Dictionaries etc.).

2. Datenbank- und Datenadministrations-Strategien:

- Homogenisierung und Integration der Umgebung (Redundanzfreiheit, Auswahl des DBMS-Anbieters nach Herstellerkonzeption, nicht nach "technischen Präferenzen");

- Organisation der Datenverwaltung (zentrale oder dezentrale Datenhaltung, Datenschutzautomatismen, Verdichtungsautomatismen etc.);

- Einbezug angrenzender Informationsquellen (zum Beispiel BDE, externe Datenbanken);

- Überwachung der technischen Umgebung.

3. Strategien für verteilte Verarbeitung:

- Design unternehmensspezifischer Netzwerke;

- Kontrolle der Telekommunikationsanforderungen (LANs, PC-Anbindung, "Electronic mail", Daten, Bilder, Sprache etc.);

- Sicherstellen der Netzverträglichkeit;

- Auswahl der Software-Architektur (Betriebssystem, DBMS, Standardapplikationen etc.).

4. Bürokommunikations-Strategie:

- Textverarbeitung;

- Interfaces (Teletex, Btx, ISDN etc.).

Der IV-Markt läßt nicht zu, daß eine Basis für Informationsverarbeitung in einem Unternehmen geschaffen wird, die nicht flexibel genug ist, Trends der Zukunft aufzunehmen Zudem soll der Aufwand für die IV übersehbar bleiben. Das ist er sicher nicht so ohne weiteres, wenn sich der Anwender eine übermäßig heterogene DV-Landschaft (ohne Konzept?) zugelegt hat.

Darum die Frage: Was bedeutet es, unter Nutzenaspekten eine möglichst homogene IV- oder Datenbankumgebung einzusetzen?

Zunächst ist die Informationsbereitstellung in allen IV-Ebenen unproblematischer. Überall existieren gleiche Informationsstrukturen und eine gleiche Bedienungsoberfläche. Die Konsistenz der Unternehmensinformationen, egal in welcher Ebene diese entstehen, ist gewährleistet.

Die Bewältigung der DV-Vergangenheit

Der Administrationsaufwand ist geringer als in heterogenen Umgebungen. Das beginnt bei der Minimierung des Schulungsaufwandes, und der Einführungskosten und endet beim "Know-how", das im Unternehmen ohne Umstände transferiert werden kann sowie der Transparenz des Informationsmodells über alle Unternehmensebenen . Eine homogene IV-Umgebung trägt dazu bei, ein einheitliches, eindeutiges, flexibles und redundanzfreies Unternehmens-Datenmodell zu erstellen. Die Plege der gesamten Datenstruktur ist nur einmal notwendig. Zeitaufwendige Koordinationsaufwände fallen weg. Datenschutz-Maßnahmen werden durchführbar.

Die Bewältigung der DV-Vergangenheit wird greifbar, wobei das Problem der Softwarehistorie immer noch ungelöst scheint, da Migration und Neuentwicklung getätigte Investitionen gar nicht oder nur teilweise und in meist fraglicher Weise schützen. Das Problem der Hardwarehistorie ist dagegen lösbar, zumindest in den Angeboten einiger weniger Anbieter von Datenbanksystemen.

Die genannten Nutzenaspekte können nur durch Systeme erlangt werden, die konkreten Anforderungen genügen. Dazu zählt die hohe Integrationsfähigkeit auf allen IV-Ebenen vom PC bis zum Host: Die DB-Systeme müssen die auf den unterschiedlichen Betriebssystemen und Hardwareplattformen existierenden Trägersysteme unterstützen und eine überdurchschnittliche Netzwerkfähigkeit aufweisen. Zudem sollten sie die Fähigkeit haben, die verwalteten Informationen zu verteilen. Wichtig ist ferner die Dokumentation der Unternehmensdaten in einem aktiven Dictionary. Die Möglichkeit, die Unternehmensrealität für alle informationsverarbeitenden Stellen im Unternehmen transparent und dokumentiert bereitzuhalten, ist um so wichtiger, je mehr organisatorische Positionen an der Unternehmens-IV teilnehmen sollen.

Wegen der häufig komplexen Vorgänge im Unternehmen sind hier außerdem alle an Vorgänge oder Daten geknüpften Regeln wie zum Beispiel "Integrity rules" oder sonstige "Business rules" zu dokumentieren. Datensicherheits-Maßnahmen können außerdem über ein Data Dictionary transparent und sicher sowie flexibel anpaßbar gesteuert und durchgeführt werden.

Eine weitere Anforderung an ein DB-System ist die Verfügbarkeit geeigneter Werkzeuge für alle an der IV im Unternehmen Beteiligten. Gemeint ist damit die Existenz von Endbenutzer-Werkzeugen, von produktivitätsorientierten Entwicklungswerkzeugen und nicht zuletzt die Möglichkeit, Arbeitsplatzrechner und Abteilungsnetze in gleicher Weise mit in die Verarbeitung mit einzubeziehen.

Dies soll nur ein Beispiel für die Notwendigkeit der Nutzendefinition für die Unternehmens-IV und die daraus resultierenden Forderungen an eine Datenbankumgebung sein. Die Frage nach dem Nutzen eines DBMS sollte damit beantwortet sein.

Das Datenbanksystem selbst trägt dem Benutzer von sich aus einen relativ geringen Nutzen ein. Erst der Gebrauch eines solchen Produkts im Sinne von definierten (und definierbaren) Zielen erschließt positive qualitative oder quantitative Nutzenfaktoren.

Der Nutzer muß seine Aufgaben lösen können

Daher ist letztlich nicht die Frage relevant, ob relational oder nicht-relational, ob objektorientiert oder in anderer Weise futuristisch aufpoliert. Vielmehr geht es darum, wie eine Umgebung aussehen muß, damit ein Nutzer heute alle seine Aufgabe zu lösen in der Lage ist, ohne die Perspektive für die Zukunft zu verlieren.

Tatsache ist, daß die relationale Datenbanktechnik heute noch immer die Spitze der Technologie darstellt. Erst seit kurzem beweisen relationale Datenbanksysteme ihre Einsatzfähigkeit und ihren Nutzen in der Praxis. Die Relationentheorie bildet außerdem mit ihren Aussagen die Basis für zukünftige Entwicklungen und damit eine wichtige Orientierungshilfe für alle Entscheider in der IV. Alle anderen Ideen, auch der Gedanke "Objektorientierung", werden sich erst noch als praxisgerecht beweisen müssen.

Das reine Vorhandensein einer Komponente sagt noch nichts über deren Qualität aus. Die Forderungen sollten also weiter gehen und die Untersuchung der Einzelkomponenten mit einschließen.

Ein Werkzeug für die Datenbankadministration mit automatischen Dokumentationsfunktionen gibt natürlich Sicherheit im Produktionsumfeld und in Revisionsverfahren, stellt aber gleichzeitig die Forderung nach einem zentralen Data-Dictionary. Und hier scheiden sich die Geister.

Es besteht immer noch das ungelöste Problem, den Wert eines solchen Produkts in Zahlen auszudrücken. Nur ein paar Gedanken hierzu: Dokumentation erzeugt Unabhängigkeit von Personal, externem "Know-how" sowie von Wissen, das an anderer Stelle "angehäuft" wurde. Aufwendige infrastrukturelle Verfahren zur Information von Beteiligten bei allen möglichen Aktionen des Datenbankadministrators entfallen.

Dokumentation aber bedeutet in jedem Fall Aufwand. Deshalb ist es unerläßlich, Data Dictionaries auf ihre Automatismen hin zu untersuchen. Folgende Fragen sind zu stellen:

- Ist das Data Dictionary mit dem Datenbanksystem integriert?

- Sind die Inhalte von Data Dictionary und DBMS konsistent?

- Ist das Data Dictionary mit der Entwicklungsumgebung integriert?

- Gehen Analyse-Ergebnisse direkt ins Data Dictionary?

- Erlaubt das Data Dictionary die Verwaltung von Datenschutzmechanismen?

- Besitzt es eine Schnittstelle zur Systemautorisierung?

- Spart man sich damit redundante Data-Dictionary-Informationen?

- Entspricht die Metastruktur des Data Dictionarys der Unternehmensrealität?

- Können gegebenenfalls Erweiterungen vorgenommen werden?

- Existiert eine Versionsverwaltung der Data-Dictionary-Objekte?

In der Data-Dictionary-Umgebung können so wichtige Objekte beschrieben sein wie Programme und ihre Referenzen zu anderen DBMS Objekten, zum Beispiel zu "Views", zu Bild schirmformaten, zu Regeln, zu Autorisierungen und anderen notwendigen Informationen Selbst die Dokumentation historischer Datenstrukturen sollte in einem qualitativ hochstehenden Data Dictionary keine Probleme bereiten.

Sepp Kraus ist Ceschäftsführer der ISCO Information Systems Consulting GmbH in Zorneding bei München.