Oft mangelt es an einer disziplinellen Methodologie, die zu einem gut dokumentierten Datenbank-Design fährt. Kritische Entwurfsentscheidungen sind nicht fein genug durchdacht und neigen dazu, unlogisch zu sein. Eine daraus resultierende Datenbank ist schwierig zu erweitern oder zu verbessern, da die Auswirkungen einer Änderung im Design nicht vorhersehbar sind.
Vielfach wird eine anwendungsorientierte Datenbank entwickelt, die für die erste oder zweite Anwendung gut läuft, jedoch zukünftigen Anforderungen nicht gerecht wird. Dies ist das Ergebnis der Vernachlässigung einer von der Funktionsanalyse unabhängigen ENTITY-Analyse.
Durch diese Analyse soll die Unabhängigkeit der Daten von verschiedenen möglichen Wegen ihrer Verarbeitung erkannt werden.
Es werden häufig Datenbanken eingesetzt, die sich als unflexibel erweisen, weil sie nicht auf Veränderungen ihrer Umwelt reagieren. Den Fachabteilungen wird in diesen Fällen meist gesagt, daß gewisse Anwendungen nicht möglich sind, da die Datenbank keine Unterstützung geben kann. Der reale Grund liegt jedoch darin, daß beim DB-Design auf eine strenge ENTITY-Analyse verzichtet wurde.
Viele eingesetzte Datenbanken lassen sich nicht umstrukturieren oder tunen, ohne daß die meisten Programme, die auf sie zugreifen, umgewandelt und neu codiert werden müssen. Dies ist das Ergebnis eines DBMS, das die Unabhängigkeit der Programme nicht in ausreichendem Maße sicherstellt. Soweit die Datenbank geändert werden kann, wird dieses Problem nicht auftreten.
In vielen Fällen wird das Design vervollständigt, ohne einen Simulator zu benutzen oder Performance-Vorhersagen zu machen. Das führt dazu, daß nach dem Laden der gesamten Datenbank und" der Verarbeitung des gesamten Transaktionsumfanges das System möglicherweise als zu langsam empfunden wird. Zu diesem späten Zeitpunkt kann der Durchsatz nur dadurch erhöht werden, daß die Datenbank entladen, neu entworfen und die Anwendungsprogramme neu codiert werden.
Wenn in vielen Unternehmen Daten und Dateien wiederholt definiert werden müssen, dann deshalb, weil die Bedeutung des Data-Dictionary beim Datenbank-Design und bei der Systementwicklung falsch eingeschätzt wird.
Unerfahrene Designer implementieren eine Datenbank, die zur Reorganisation eine Elapsed-Time von mehreren Tagen erfordert. Da dies nicht praktikabel war, wurde die Leistung so weit verschlechtert, bis die Datenbank zusammenbrach. Das Ergebnis ist ein der Recovery, der Reorganisation oder anderer ähnlicher Sachverhalte nicht adäquater DB-Entwurf.
Werden ISAM-Dateien einfach 1:1 ersetzt, dann wird das DBMS hauptsächlich als reine Zugriffsmethode benutzt. In diesem Falle werden zwar die zusätzlichen Kosten für Software und Verarbeitung wirksam, nicht jedoch die echten Vorteile eines Datenbank-Managementsystems.
Unerfahrene Anwender begeben sich leicht in die Situation, bestehende konventionelle Dateien direkt in eine Datenbank umzuwandeln. Die damit verbundene fehlende Veränderung der Datenstrukturen führt zu einer Datenbank, die die Fehler und Unvereinbarkeiten der bestehenden Systeme enthält und kein Unternehmensmodell darstellt. Der erwartete Erfolg kann folglich nicht eintreten.
*Hans-Werner Steffen ist Marketing-Manager des
Softwarehauses CACI International, Hamburg