Als schwierig hat sich bisher eine Kostenbetrachtung bei der Auswahl von Datenbanken erwiesen. Dies deshalb, weil Faktoren wie beispielsweise eine schnelle Informationswiedergewinnung, das Informationsmanagement oder stabile Datenstrukturen nur schwer qualifizierbar sind. Dennoch kann man nach Ansicht von Josef Kraus* auch in diesem Fall bestimmte Kostenfaktoren isolieren, wenn auch nicht betriebswirtschaftlich kostenmäßig allgemein erfassen.

Nicht nur Erstkosten sind bei DB-Entscheidungen zu betrachten, sondern vor allem die Folgekosten, zum Beispiel bei Umstellung, Design- und Definitionsphase. Systeme wie IMS oder DL/1 sind da sehr kostenintensiv, weil wenig flexibel bezüglich ihrer Anpassung an die Anwenderanforderungen. Nach Aussagen von Fachleuten ist hier eine Design-Planung mit zirka zwei bis drei Mannjahren (MJ) durchaus realistisch. Dabei sind die Kosten für Personal mit rund 150 000 bis 220 000 Mark zu veranschlagen, Gemein- und andere betriebliche Fixkosten nicht eingerechnet.

Relationale Systeme dagegen sind durch die Möglichkeiten von "anwendungsneutralem" DB-Design und ihre normalisierten Datenstrukturen insensitiv gegen Anwendungsbereichserweiterungen und Änderungen. Die DB-Design-Phase ist selbst bei großen Datenbanken sehr kurz und entsprechend kostensparend.

Systeme komplexer Architektur, beziehungsweise traditionelle DBMS, verlangen über die gesamte Einsatzdauer nach mindestens einer Data Base Administration (DBA).

Ein relationales DBMS hingegen mit eingesetztem aktiven und integrierten Data-Dictionary verlangt vom Benutzer, abgesehen von der Einführungsphase, eine halbe DBA, das heißt DB-Administration kann auch ein Teil der Systemprogrammierung werden, obwohl die Institutionalisierung einer Gruppe "Datenadministration" ratsam ist.

Die Programmierung auf nicht relationalen Systemen ist kompliziert und zeitaufwendig bezüglich Programmimplementierung und Programmier-Ausbildung. DL/1- oder IMS-Programmierer brauchen erfahrungsgemäß etwa ein Jahr, um selbständig arbeiten zu können. Relationen sind einfache überschaubare Tabellen, die, von einem DBMS verwaltet, dem Programmierer als Anwender der Informationen keine Verarbeitungs- und Erfassungsprobleme entstehen lassen. Der Programmierer kennt keine Navigation und keine komplizierten unterschiedlichen Datenstrukturen .

RDBMS-basierte Programme behalten Investitionswert

Einmal auf der Basis relationaler DBMS geschriebene Programme behalten ihren einmal getätigten Investitionswert, da neue Anwendungen die Möglichkeit haben, ihre Daten auf der DB so zu sehen, wie sie sie benötigen, andere Anwendungen bei Erweiterungen und Änderungen jedoch nicht berührt werden. Folge: Kein Änderungsaufwand bei Datei- und Datenstrukturänderungen sowie Anwendungserweiterungen.

Bei andersgearteten Systemen unterliegen ständig 30 bis 80 Prozent der Programme und Datenstrukturen dem "Wartungsdienst". Die Kosteneinsparung, die hieraus abzuleiten wäre, ist zunächst von vielen Faktoren abhängig:

- Menge der Programme,

- Größe der Datenbank (Sätze/Segmente),

- Anzahl der Programmierer,

- Menge der zu wartenden Programme zum Zeitpunkt x,

- Intervallgröße zwischen den Zeitpunkten x1 und xn,

- Schwierigkeitsgrad der Änderung je nach individueller Schwierigkeitsgradeinteilung.

Der Faktor "DB-Größe" tritt nur als Operand auf, wenn die DB einer Änderung unterliegt, die auch die Programme berührt. Bei relationalen DBMS ist dieser Faktor zu vernachlässigen, da konstant.

Bei Systemen, die die Datenstruktur der DB in die Programme verlagern müssen, verbirgt sich hinter einer Datenstrukturänderung immer auch die Manipulation von Programmen, die diese Struktur benutzen.

Die indirekten Kosten sind so zu verstehen, daß man verschiedene Aspekte eines DBMS untersucht und herausfindet, welche Auswirkungen das Fehlen bestimmter Facilities, die Residenz in den Systemressourcen, nicht vorhandene Transparenzprogramme und Zukunftstrends auf das DV- beziehungsweise Betriebskostengefüge hat oder haben kann. So fallen auch "Emergency"-Situationen (...) diesen Teil der Kostenbetrachtungen.

Datenschutz gewinnt zunehmend an Bedeutung

Dazu gehört auch die Frage, was einem Unternehmen die Datensicherheit und der konsistente Zustand eines DB-Systems wert ist. Das hängt sicherlich vom Unternehmen und auch dem Umfang des DB-Einsatzes innerhalb des Unternehmens ab. Fest steht, daß in der Zukunft mit der steigenden Automatisierung und Vernetzung von Industrie- und öffentlichen Bereichen miteinander auch der Datenschutz an Bedeutung erheblich gewinnen wird. Ein im DBMS enthaltenes entsprechendes Feature sollte dafür Sorge tragen, daß alle denkbaren möglichen Maßnahmen zum Schutz der Information realisiert werden können:

- Password-Schutz,

- Schutz der Daten nach Benutzerprofilen,

- Schutz von Informationen auf elementarer Ebene,

- Zeitfenster,

- Schutz der Daten abhängig von ihrer Aussage (Wert),

- Schutz der Daten in ihrer beziehungsbedingten Aussage. Hiermit ist gemeint, daß häufig einzelne Daten für sich harmlos und wenig aussagekräftig sind. Bringt man sie jedoch untereinander oder mit anderen Daten entsprechend in Beziehung und zieht aus der neuen Informationsmenge seine Erkenntnisse, so können diese durchaus umfassend und wertvoll sein.

Traditionelle Systeme weisen Support-Lücken auf

Auch hier sind bei den meisten traditionellen Systemen erhebliche Lücken beziehungsweise ein vollständiges Fehlen solcher Möglichkeiten festzustellen.

Was Datenintegrität schließlich wert sein kann, kann nur jemand ermessen, der jemals den Aufwand an Zeit erfahren hat, der notwendig ist, um Datenbestände, etwa nach Programmabstürzen oder Systemzusammenbrüchen, wieder zu "verifizieren" (VSAM).

Abgesehen vom kostenintensiven Zeit- und Personalaufwand erhebt sich hier die Frage zum einen nach Recovery und Restart-Verfahren, die solche Situationen zu 100 Prozent automatisch bewältigen können, und zum anderen nach einem zentralen Kontrollorgan des DB-Environments, das gleichzeitig Dokumentationsinstrument, Designtool und DBA-Unterstützung sein kann, nämlich nach einem zentralen, aktiven Data-Dictionary.

Schwer in Zahlen zu bewerten ist auch der Wert eines Data-Dictionary. Es ist heute in allen DV-Environments als wertvoll und unumgänglich akzeptiert. Dennoch: Auch andere DB-Umgebungen verlangen nach einer Dokumentation ihrer Produktions- und Testrealitäten. Dokumentation erzeugt Personalunabhängigkeit, vermeidet gehäuftes Wissen bei einer Person und damit Abhängigkeit des Unternehmens von seiner personellen Besetzung.

DDS müssen auf Automatik hin untersucht werden

Dokumentation bedeutet aber gleichzeitig auch Aufwand. Deshalb ist es unerläßlich, DDs auf ihre Automatik hin zu untersuchen: Ist das DD in der Lage, einmal gegebene Informationen entsprechend in Aktionen umzusetzen (zum Beispiel die DB aufzubauen)? Spart man dabei die Nachdokumentation?

Können die Fragen positiv beantwortet werden, dann sind die Migrationsängste von der traditionellen Datenorganisationsumgebung auf eine zukunftsweisende Systemumgebung der vierten Generation überflüssig .

Wenn im Unternehmen die Überzeugung akzeptiert ist, daß eine zentrale Kontrolle aller Unternehmensdaten unerläßlich ist, so sollte auch der Einsatz eines Data-Dictionary eine beschlossene Sache sein. Denn mit dem Data-Dictionary erzielt man den Effekt qualitativ als auch quantitativ gleichbleibend guter Dokumentation.

Wenn außerdem für ein DD die Prämissen "Definition" = "Dokumentation" und "Aktivität = Dokumentation" gelten, so bringt das DD-System ohne spürbaren Zusatzaufwand den Vorteil einer wohldefinierten, überschaubaren und zentral kontrollierten DV-Umgebung. Dies dürfte jeder Kosten/Nutzen-Rechnung standhalten.

Systemressourcen als Kostenfaktor einbeziehen

Haben die vorhergehenden Ausführungen zu dem Schluß geführt, daß DBMS-Modelle relationaler Art für DV-Abteilungen langfristig als besonders kostengünstig anzusehen sind, so müssen zusätzlich die vom DBMS benötigten Systemressourcen in diese Kostenbetrachtungen miteinbezogen werden.

In diesem Zusammenhang muß ein DBMS oder auch ein Query-System dann als nur unzureichend kosteneffizient angesehen werden, wenn es

- die CPU zu sehr belastet (realer Speicherbedarf und interne Belastung);

- die Kanäle zu den externen Speichern übermäßig in Anspruch nimmt;

- die Möglichkeiten des TP-Monitors in der OL-Umgebung zu sehr beeinträchtigt .

In allen drei Fällen kann man von Kosten für Neuanschaffungen für SW und/oder HW ausgehen.

Inwieweit die Aktualität von Daten in diesem Zusammenhang als betriebswirtschaftlicher Faktor zu bewerten ist, hängt in hohem Maß von ihrer Verwendung ab. Global kann jedoch gesagt werden, daß Daten mit zunehmender Dauer ihrer "Zur-Verfügung-Stellung" ("retrieval time") an Wert verlieren.

In Management-Informations-Systemen (MIS) hat der Aktualitätsgrad von Daten, die als Entscheidungshilfen herangezogen werden, einen besonders hohen Stellenwert. In Zeiten zunehmenden Konkurrenzdrucks wird die Aktualität der Daten nicht mehr nur wünschenswert, sondern unter Umständen zu einem entscheidenden Faktor als Grundlage für unternehmerische Entscheidungen. Die Frage: Welche Verluste entstehen einem Unternehmen, wenn benötigte Daten nur mit Zeitverzögerung oder nicht aktuell zur Verfügung stehen, kann nur dann befriedigend beantwortet werden, wenn auch das Umfeld und die entsprechende Situation analysierbar ist.

Wesentliches Kennzeichen und markanter Vorteil relationaler Systeme sind die Möglichkeiten, mittels Abfragesprachen (relational query systems) "ad hoc" alle gespeicherten Informationen in beliebiger Konsistenz wiederzugewinnen und auszuwerten. Der Effekt: Klein- und Kleinstanwendungen, Abfragen und Einzelinformations-Wiedergewinnung werden von der DV-Abteilung in die entsprechende Fachabteilung verlegt oder ohne großen Programmier- und Testaufwand für die FA sofort realisiert.

Somit ist die Arbeitsersparnis für die FA und die DV-Abteilung zur Bereitstellung aktueller Daten auch kostenmäßig erfaßbar. Eine Vergleichsrechnung "vor und nach Einsatz" relationaler Systeme kann die individuelle Unternehmensrentabilität für solche Systeme nachweisen.

Normalisierung bewirkt stabile Datenstrukturen

Die Existenz stabiler Datenstrukturen durch Normalisierung der Daten wurde bereits angesprochen - nicht jedoch in allen ihren Auswirkungen:

- Insensitives Verhalten gegen Programmänderung;

- insensitives Verhalten gegen Anwendungserweiterungen beziehungsweise Neuanwendungen;

- Minimierung von Datenredundanz und Schonung der Systemressourcen (extern und intern);

- Effizientes internes Handling auf der physikalischen Ebene;

- Benutzergerechte externe Handhabung.

Diese Punkte lassen Problemkreise heutiger DV-Umgebungen auf Null schrumpfen:

- Neue Projekte bedürfen keiner Neustrukturierung der Daten.

- "Nach-log" und Nachfahr-Problematiken im Bereich auch bewußt redundant gehaltener Datenmengen sparen Zeit sowie Personal- und DV-Kapazitäten.

- Techniken, die grundsätzlich von DBMS-Systemen zur Verfügung gestellt werden können, da es nur einen Datenpool in einer Datenorganisationsform gibt - nämlich in dem eingesetzten DBMS - würden in traditionellen Umgebungen deshalb nicht möglich sein, da diese verschiedenartigste konzeptionslose Voraussetzungen für die Datenverarbeitung vorsehen müssen.

- Die Verlagerung bestimmter fachbereichsorientierter Problembereiche in die Fachabteilung selbst spart zeitintensive Auseinandersetzung der FA mit den analytischen Anforderungen der DV-Abteilung und versetzt sie in die Lage, ihre Probleme und Lösungen selbst zu formulieren.

Billige Systeme kosten oft mehr als teure

Die Frage nach Trends und künftigen Konzeptionen ist gerade bei einer Investition wie einem DBMS angebracht. Das DBMS und seine Umgebung ist eine der strategischen Entscheidungen, die in einem Unternehmen der Gegenwart anstehen.

Hier sollen 4GL-Systeme den Benutzer in die Lage versetzen, die Probleme und ihre Lösungen mehr zu "formulieren" denn zu "programmieren". Durch die Verfügbarkeit aller notwendigen "facilities" für den Zyklus einer Anwendungsentwicklung und zugehöriger Komponenten in einer einzigen Systemumgebung werden folgenden Ziele erreicht:

- Bedeutend schnellere Entwicklung von AW-Systemen,

- Automatische Dokumentation aller Aktivitäten,

- Verbesserte Wartbarkeit und erhöhte Verfügbarkeit von 4GL-AW-Systemen,

- Unabhängigkeit vom Betriebssystem und Problemorientierung des Anwendungsentwicklers,

- Reduzierung notwendiger Systemkenntnisse,

- Verfügbarkeit dieser Umgebung auch für den Benutzer.

Der Anwendungsentwickler soll sich um die Sache, das Problem und dessen Lösung, also um das "Was" kümmern können und nicht mehr wie heute noch vielfach, 50 bis 70 Prozent seiner Erfahrung für das "Wie" einer Anwendungsentwicklung verschwenden müssen.

Verteilte DBs fallen hierunter, in Zukunft jedoch noch viel mehr die Einbettung von Personalcomputern in das DB-Environment und dessen Möglichkeiten.

DB-Systeme, die von ihrer Konzeption her Zukunftsperspektiven wie Mehrrechnerverbund, Anschluß von PCs und verteilte Datenbanken nicht vorsehen, ignorieren die DV-Weiterentwicklung sowie die Entwicklungstrends und können das Unternehmen viel Zeit, Geld und Aufwand kosten, wenn es sich in diese Richtungen entwickeln will.

Bei der Integration neuer Technologien trifft insbesondere die PC-Frage zu: "Wildwuchs oder kontrollierte Benutzung und damit Entlastung des DV-Environments". Der PC kann nur sinnvoll eingesetzt werden, wenn die bestehenden Unternehmensinformationen entsprechend transparent und dokumentiert sind. Es sei denn, man möchte im Unternehmen wieder individuelle DV-Insellösungen schaffen.

Die Sicherheit des DB-Anbieters und dessen Support-Stärke sind ebenfalls Kriterien, die den Anwender eines DB-Systems neben den technischen Vorteilen "seines" Systems am meisten interessieren sollten. Datenbanken im "Ausverkauf" zu erwerben, kann ein Unternehmen bei fehlendem Support und finanzieller Potenz des Anbieters an den Rand einer Katastrophe bringen, wenn die DB im Unternehmen als organisatorischer und rationalisierender Faktor integriert wurde.

All dies ist aber nur schwer kostenbetrachtend zu beurteilen. Eine Aussage eines Referenten im Rahmen eines DB-Seminars sollte zu verstehen geben, wie wichtig aber dieser Aspekt ist: "Billige Datenbanksysteme können im Endeffekt teurer sein als teuer eingekaufte."

Schnelle Entscheidungen erhöhen DB-Risiko

Datenbankentscheidungen, die in kürzeren Zeitabschnitten als einem halben Jahr getroffen werden, können durchaus als unternehmerisches Risiko betrachtet werden.

Die Entscheidung für eine Software-Umgebung der vierten Generation mit relationalem DBMS, Endbenutzerabfragesprache, aktivem zentralen Data-Dictionary, Anwendungsentwicklungssystem der vierten Generation, Option der sinnvollen PC-Integration sowie der Möglichkeit verteilter Datenbanken in einem stabilen Netz muß für ein Unternehmen als wichtigste strategische Entscheidung mindestens für die nächsten zehn Jahre gesehen werden.

*Josef Kraus ist Marketingleiter Central Europe der ADR Applied Data Research (Deutschland) GmbH, Neuss.