Wir gehen davon aus, daß die Entscheidung für ein DB/DC-System bereits gefallen ist. Die Gründe dafür sollen nicht mehr untersucht werden. Zu den am häufigsten genannten Argumenten gehören:

-Entscheidung des Managements

-Einziges Mittel zur Lösung einer bestimmten Aufgabe

-Größere Flexibilität und leichtere Handhabung des Systems

-Erhöhung der Produktivität der Programmierer

Bis zur Übernahme des Systems in die Produktion werden im Idealfall folgende Stufen durchlaufen:

1. Festlegen der Randbedingungen bzgl. Kosten, Hardware, Software, Personal, Zeit

2. Entscheidung über Einsatzgebiete, Ermittlung des Benutzerbedarfs

3. Grobauswahl aus allen bekannten Systemen

4. Engere Wahl

4.1. Aufstellen von Kriterienlisten

4.2. Theoretische Vergleiche

4.3. Benchmarktest, Modellbildung Simulation

4.4. Bewertung

5. Benutzerschulung

6. Aufbau einer DB/DC-Gruppe

7. Testbetrieb

8. Schrittweise Umstellung

Aus Platzgründen soll hier nur auf die ersten vier Punkte näher eingegangen werden. Es wird vorausgesetzt, daß die übrigen Punkte und die damit verbundene Problematik bei der Auswahl mit berücksichtigt werden.

Ermittlung des Benutzerbedarfs

Zu l/2: Hier wird häufig der Fehler gemacht, daß der mindestens benötigte Aufwand weit unterschätzt wird. Bei komplexen Systemen muß mit einer Anlaufphase von zwölf Monaten gerechnet werden, bis die Firma das System "im Griff" hat. Je nach Art des Systems und der Anwendung kann es erforderlich werden, bis zu zehn Personen ausschließlich mit Betrieb und Wartung des Systems zu betrauen. Unbefriedigend ist bei den meisten bekannten Auswahlverfahren noch die Erhebung der Anforderungen der Endbenutzer. Diese zu erfassen erfordert außerordentliches Geschick, insbesondere ist es fast unmöglich, die Auswirkungen eines laufenden Systems auf die Benutzer abzuschätzen; deren Verhalten ändert sich fast immer nach der Systemeinführung.

Weltweit über 200 Systeme

Zu 3: Die Vorauswahl der Systeme ist ein kaum zu bewältigendes Problem. Kaum jemand kennt alle in Frage kommenden Systeme mit Namen (es gib weltweit über 200 auf dem Markt!) noch weniger ist über Eigenschaften und Leistungen bekannt. Hier sind von unabhängigen Institutionen angefertigte Kurzvergleiche, aus denen die wichtigsten Systemeigenschaften zu entnehmen sind, eine große Hilfe.

Die Praxis hat gezeigt, daß für viele in Komplexität und Anforderungsspektrum überschaubare Anwendungen ein eigenes maßgeschneidertes System preisgünstiger als ein gemietetes, generalisiertes System der großen Hersteller ist. Es sollte überprüft werden, ob die Abhängigkeit von den Entwicklern (eigenes Team oder Software-Haus) eines maßgeschneiderten Systems größer ist, als die vom Hersteller eines generalisierten Systems.

Selbst für die bekanntesten DB/DC-Systeme gibt es keine Garantien, daß sie an die nächste Hard-/Softwaregeneration angepaßt werden. Einige Anwender haben schon kostspielige Erfahrungen machen müssen.

Die Kriterienliste

Zu 4.1.: Der Kriterienkatalog ist das Kernstück der Auswahl.

Er könnte zum Beispiel folgende Grobgliederung haben:

1. Leistungen und Eigenschaften l.1 Aufbau einer Datenbasis

1.2 DBMS-Benutzung

1.3 Datensicherheit

1.4 Performance

1.5 Vorzüge beziehungsweise Schwachstellen des

DBMS

1.6 Dokumentation

2. System(umgebung )/Aufwand

2.1 System

2.2 Zusätzliche Programme

2.3 Hardware zu 2.1/2.2

2.4 Beziehungen System Systemumgebung

2.5 Systemeinsatz

2.6 Herstellerunterstützung

2.7 Integration in den Betriebsablauf

Die einzelnen Punkte werden weiter untergliedert. (Ein Beispiel für einen Punkt der feinsten Gliederungsstufe wäre zum Beispiel:

1.1.9 Auswahl einer bestimmten Gliederung/Speicherung

Einflußgrößen für diese Auswahl (Welche Einheiten werden vom DBMS getrennt manipuliert?

Welche Einheiten sind adressierter? Ggf. Hinweise auf Sortierkriterien, Zugriff, Mehrdeutigkeit, Verknüpfung, Überlauf, online Verfügbarkeit [wahlweise auch von DB-Teilen], Reorganisation, Datenredundanz, Überlagerung mehrerer Zugriffsmethoden . . .) Dieser Katalog sollte in Zusammenarbeit mit DB/DC-Kennern erstellt werden, gegebenenfalls ist es sogar günstiger, getrennte Listen für die beiden Teilsysteme zu erstellen.

Erfahrungsaustausch

Zu 4.2: Nach den vorliegenden Erfahrungen reichen für eine fundierte Entscheidung Publikationen über theoretische Vergleiche nicht mehr aus. Sie erreichen kaum den nötigen Detallierungsgrad. Die eigentlichen Probleme sind erst beim praktischen Einsatz eines DB/DC-Systems zu erfassen, Einschränkungen und Flaschenhälse beim Betrieb des Systems kommen nur hier zu Tage.

Es wird dringend empfohlen über Arbeitskreise der Systembenutzer, Seminare, Besuche in anderen Firmen etc. zu versuchen, Zugang zu den Erfahrungen anderer zu erreichen. Die so gewonnenen Aussagen sind jedoch in zweierlei Hinsicht problematisch. Zum einen haben die meisten Anwender nur mit einem System Erfahrungen und deswegen keine Vergleichsmöglichkeiten zu anderen Systemen; zum anderen ist es sehr schwer zu entscheiden, welche Erfahrungen (positive oder negative) auf den eigenen Betrieb übertrabar sind.

Zu 4.3: Benchmarktests sind teuer und in ihrer Aussagekraft begrenzt. Damit gewonnene Ergebnisse zu analysieren und auf weitere Anwendungen zu übertragen erfordert genaue Kenntnisse der Systeminterne. Als Ergänzung oder gar Ersatz empfiehlt sich die Modellbildung. Die Simulation scheint eher für die Anpassung eines Systems an den lautenden Betrieb geeignet.

Bewertung durch Punktvergabe

Zu 4.4: Die einzelnen Kriterien erhalten , Gewichte. Aufgrund der Ergebnisse aus 4 2/4.3 wird entschieden, wie weit die Systeme die Kriterien erfüllen, dementsprechend werden Punkte vergeben Punkte und Gewichte werden miteinander multipliziert, man bildet die Summe und hat eine Meßzahl für die Güte jedes untersuchten Systems. Den meisten Anwendern sind die Konsequenzen aus der Wahl einer bestimmten Methode der Punktvergabe nicht bekannt. Erhält zum Beispiel das System, das die Anforderungen am besten erfüllt immer zehn Punkte, verliert man u einen Maßstab für den Grad der Erfüllung aller Anforderungen. Fast immer a kommen in den Kriterienlisten die Nachteile der erwogenen Lösungen zu kurz. Diese sollten in gesonderten Untersuchungen herausgearbeitet werden.

Dipl.-Math. Konrad Supper ist bei der Gesellschaft für Mathematik und Datenverarbeitung (GMD) am Institut für Informationssysteme zuständig für das Projekt "Existierende Datenbanksoftware".