Gründe für das Scheitern von DB-Projekten - Teil 2: Software-Auswahl

Die Datenbank muß das Unternehmen exakt repräsentieren

11.08.1978

Vielfach sind in der Vergangenheit Entscheidungen für eine Datenbank getroffen worden, bevor die fundamentalsten Fragen geklärt wurden. Einige dieser Fragen sollten sein: Warum eine Datenbank? Welche Art von Datenbank? Welcher Grad der Verteilung ist erforderlich? Welche Rolle spielt die Datenfernübertragung? Sind diese Fundamentalfragen nicht vollständig beantwortet, so gleicht die Entscheidung zum Einsatz einer Datenbank im Unternehmen der Entscheidung, einen Wagen zu kaufen und anschließend zu diskutieren, ob nun per Auto, Zug, Schiff oder Flugzeug gereist werden soll.

Viele Anwender von Datenbanken stellen nach einer gewissen Zeit fest, daß das benutzte DBMS für das Unternehmen und all seine Anforderungen nicht geeignet ist. Dies ist die Folge davon, daß die Auswahl der Software ohne genaues Verständnis der technischen Erfordernisse einer Datenbank vorgenommen wurde. Das Übergehen von einem DBMS zu einem anderen DBMS ist nicht weniger teuer als der Übergang von den ursprünglichen konventionellen Dateien auf ein DBMS. Zur Zeit befinden sich viele Unternehmen in der Situation, ihr installiertes DBMS auszutauschen. Sie sind dazu jedoch, wegen der damit verbundenen Kosten sowie der unumgänglichen Unterbrechung des Arbeitsablaufes, nicht in der Lage.

Zukünftige Entwicklungen berücksichtigen

Sehr häufig werden zukünftige Entwicklungen in der Technologie und in der Unternehmenspolitik im Hinblick auf die Benutzung von Datenfernverarbeitungssystemen, Datenkommunikation, Datenverarbeitung und Data Dictionary mißachtet. Die Entscheidungen über ein DBMS beziehen sich zentral auf alle zukünftigen Entwicklungen und können nicht isoliert von anderen Entwicklungen betrachtet werden.

Die Auswahl eines DBMS ist des weiteren sinnlos, wenn der notwendige Überblick über die Datenresourcen eines Unternehmens nicht besteht. Um die von der Software verlangten Datenstrukturierungsfähigkeiten zu definieren, sollten formale Methoden wie Daten-(ENTITY-)Analyse benutzt werden. Wenn die Datenbank nicht eine exakte Repräsentation des Unternehmens darstellt, was unter Umständen durch Struktureinschränkungen des DBMS verursacht wird, wäre es unverantwortlich, sie einzuführen, und unnötigerweise schwer, sie zu benutzen.

Datenbank-Vorteile nicht genutzt

Vielfach basiert das ausgewählte DBMS auf Batch-Updating und sequentieller Verarbeitung, da den Analytikern diese Art des Systems bekannt ist, obwohl zukünftige Anwendungen, um die richtigen Vorteile einer Datenbank zu erzielen, transaktionsorientiert sein sollten, mit der Möglichkeit des Online-Updating.

Viele Anwender von Datenbanken mußten notgedrungen eine Vielzahl von Basis-Software selbst entwickeln. Dies ist die Folge davon, daß die ausgewählte Software nicht die wesentlichen Fähigkeiten besaß, um die Leistungsfähigkeit einer Datenbank auszunutzen. Ein unerfahrener Analytiker, der mit der Auswahl eines DBMS beauftragt ist, kann nur schwer erkennen, daß zum Beispiel Unterstützungs-Utilities (Laden einer Datenbank, Reorganisation, Rekonstruktion, Performance-Monitoring, Recovery, Änderung der Sicherheitskontrolle) nicht Bestandteil des von ihm ausgewählten DBMS sind.

Es wird von allen Systemen behauptet, daß sie leicht zu benutzen sind, daß sie sehr leistungsfähig laufen, volle Daten-Unabhängigkeit gewährleisten und eine automatische Recovery ermöglichen. Tatsächlich ist dies jedoch in den einzelnen DBMS sehr unterschiedlich.

Viele Unternehmen ernennen ihren Datenbank-Administrator erst nach der Auswahl des DBMS. Es ist verständlich, daß in diesem Fall der Datenbank-Administrator nicht für ein nichtadäquates System verantwortlich gemacht werden kann.

Um etwas über Datenbanken zu lernen, wird vielfach die Probeinstallation eines DBMS durchgeführt. Einige Monate später wird dann festgestellt, daß diese Investition lediglich in Schulung, Entwurf und Programmierung erfolgte. Entsprechend erfolgt auch die Verpflichtung der für das DBMS verantwortlichen Systemprogrammierer, ohne ernsthafte Untersuchungen alternativen DBMS durchgeführt zu haben.

*Hans-Werner Steffen ist Marketing-Manager der CACI Inc. International, Hamburg