Jeder Ersteinsatz einer Datenbank - egal ob bei bereits bestehenden Anwendungen oder neu zu konzipierenden Lösungen - _bedeutet sowohl für die EDV-Abteilung als auch für die Anwender einen Bruch mit der Tradition. Das eingesetzte Datenbanksystem will beherrscht sein, "beherrscht" aber eben auch den Organisationsablauf innerhalb des Betriebes. Wohlgemerkt: Eine DB, die nach sachbezogenen Kriterien ausgewählt wurde, erleichtert dem Benutzer erheblich das Handling seiner Daten. Doch sollte das "Korsett", das ein DB-System darstellt, nicht unterschätzt werden.

Es gilt für die EDV-Abteilung, Abschied zu nehmen von liebgewordenen Individualdateiverwaltungen. Die Fachabteilungen ihrerseits müssen durch die Struktur des ausgewählten DB-Systems mehr mit in die organisatorische Verantwortung genommen werden.

Ein unverzichtbares Entscheidungsmerkmal beim DB-Einsatz sollte das Vorhandensein einer Query Language (QL) sein. Der Handlingskomfort der QL muß die Anwenderabteilung in die Lage versetzen, einfache DB-Auswertungen (auch Listen) ad hoc durchzuführen. Die Benutzung der QL darf die Schutzmechanismen (concurrent-update Satz/ Feldschutz) nicht verletzen. Für den mündigen Anwender ist eine QL, die formatierte Dialog-Ein-/Ausgabe unterstützt, von wesentlicher Bedeutung.

Banale Forderung

Trotz der Diskussionen um den umstrittenen Wert der kompatiblen Schnittstellen (KDBS, KDCS) sollte bei der Auswahl der DB darauf geachtet werden, daß diese Schnittstellen unterstützt werden. Damit ist zumindest ein hohes Maß an standardisierter Vorgehensweise bei der Programmierung möglich, um einen eventuellen Transport der Anwendersoftware auf ein alternatives DB-System zu unterstützen.

Das DB-System muß über ein eigenes Recovery-System verfügen und im Zusammenhang mit dem eingesetzten DC-System eine automatische Transaktionssicherung erlauben, damit aufwendige Benutzerprogramme in diesem Bereich entfallen. Diese so banal klingende Forderung ist bei genauer Betrachtung verschiedener DB-Systeme nicht immer selbstverständlich.

Über den Vorteil, daß durch den Einsatz eines DB-Systems eine einheitliche Speicherung- und Zugriffsform erreicht wird, besteht sicherlich Einigkeit, jedoch darf dieser entscheidende Vorteil nicht durch Performance- und/oder Handlings-Nachteile eingeschränkt werden.

Die Performance eines DB-Systems muß unter folgenden Aspekten untersucht werden:

- Physikalische Speicherung

Lassen sich Sekundärschlüsse per Option resident halten? Lassen sich Daten und Verwaltungsbereiche auf verschiedenen Datenträgern einrichten? Wie groß ist der prozentuale Anteil der notwendigen Verwaltungsdateien am Gesamtspeicherbedarf?

- Zugriffswege

Wie wird vom DB-System über Primär- und Sekundärschlüssel zugegriffen? Sind die Suchstrategien unter Berücksichtigung der physikalischen Zugriffe optimierbar?

- Datenkomprimierung

Werden die Dateien vorn DB-System komprimiert? Durch Komprimierung kann bis zu 60 Prozent des Volumens eingespart werden.

- Reorganisationsaufwand

Inwieweit wird die notwendige Reorganisation der DB vom System überwacht, gemeldet beziehungsweise durchgeführt?

- Datenbanksplitting

Ist das DB-System Multi-DB-fähig? Ist ein DB-Splitting wirklich notwendig und/oder sinnvoll?

- Benchmark-Test

Ist der DB-Hersteller bereit, einen BMT durchzuführen? Welcher Aufwand ist hierbei notwendig?

Überdimensioniertes System kostet Performance

Es sollte kein DB-System eingesetzt werden, dessen Möglichkeiten weit über die überschaubaren heutigen und zukünftigen Anforderungen hinausgeht. Das ausgewählte System sollte jedoch für die mittelfristigen Anforderungen ausbaubar sein und die Schnittstellen bieten, die bei Bedarf den Transport der Anwenderprogramme in ein anderes DB-System ermöglichen.

Überdimensioniert eingekaufte DB-Systeme kosten Performance, die oft nur durch überflüssige Hardwareaufrüstungen wettgemacht werden Können.

Die Beschaffenheit der DB-Utilities sollte eine wesentliche Entlastung der Anwendungsprogrammierung von Banalaufgaben ermöglichen. Dabei ist wichtig, daß die Einbettung der Tools und des DB-Systems in die Systemumwelt durchgängig ist.

Ein besonderes Augenmerk bei der Auswahl des DB-Systems sollte dem Datenschutz gelten. Abgesehen davon, daß ein DB-System die gesetzlich vorgeschriebenen Forderungen des Datenschutzes erfüllen sollte, muß der Anwender darauf achten, daß Schutz auf drei Ebenen besteht:

- DB

- Satz

- Feld (gebunden an Berechtigungsschlüssel)

Das zeitliche Raster für den Einsatz der DB-Anwendungen sollte unter Berücksichtigung der Lieferzeiten, Personalkapazitäten oder Schulungsmöglichkeiten möglichst konkret erstellt werden. Hier zeigt sich zum ersten Mal, ob das geplante Vorhaben mit eigener Kapazität erreichbar und sinnvoll realisierbar ist. Nicht zu unterschätzen ist der Zeit- und Kostenaufwand, der notwendig ist, die eigenen Mitarbeiter DB-spezifisch auszubilden und ein Projekt "auf der grünen Wiese" zu beginnen.

Leichtfertige Argumentation

Eine besondere Bedeutung kommt der Auswahl und Ausbildung des DB-Administrators zu. Dessen Kompetenzen müssen rechtzeitig gegenüber der EDV- und den Fachabteilungen bekanntgegeben und klargestellt werden.

Durch den Einsatz einer DB erfolgt eine Strukturierung der Datenbestände. Warum sollte man hier nun haltmachen? Spätestens zu diesem Zeitpunkt kann auch die Entscheidung zugunsten der Strukturierung der Anwenderprogramme erfolgen. Der gezielte Einsatz von am Markt erhältlichen Software-Tools reduziert den Gesamtaufwand.

Ein häufiger, grundsätzlicher Fehler besteht darin, daß der Aufwand für die Design-Phase bei DB-Projekten unterschätzt wird. Dies wird leider auch allzuoft durch die leichtfertige Vertriebsargumentation (easy-in-use) der Hersteller forciert und erweist sich dann für den Anwender als "hard-to-handle". Design-Fehler wirken sich meist in festgefahrenen Strukturen, schlechten Responsezeiten und damit verbundener negativer Akzeptanz durch die Benutzer aus.

In Anlehnung an die logischen Strukturen des Gesamtkonzeptes muß unbedingt überprüft werden, ob ein Splitting auf mehrere DB möglich ist und durch den DB-Händler unterstützt wird, um Bottle-neck-Effekte zu vermeiden. Das gleiche gilt für die Struktur des DC-Händlers.

Ein wesentlicher Vorteil des Einsatzes eines DB-Systems liegt in der klaren, für alle Beteiligten verbindlichen Struktur der Datenbestände. Die Erfahrung zeigt, daß eine Langzeitentwicklung nur dann erreicht wird, wenn die Verantwortlichkeit für die Pflege der DB durch den Einsatz eines DB-Administrators koordiniert wird. Das Feeling dieser Person sowohl für die DV-technischen Belange als auch für die Anwenderbelange ist entscheidend für den langfristigen Erfolg eines DB-Einsatzes

In eingehenden Diskussionen mit den Fachabteilungen während der Design-Phase sollte die Wahrscheinlichkeit und Gewichtung der häufigsten Zugriffswege definiert und hierbei auf eine realistische Nutzung der verfügbaren Suchstrategien geachtet werden. Exotische Zugriffe, die aus einer momentanen Anforderung beim Design berücksichtigt werden, können die Performance des Gesamtsystems negativ beeinflussen.

Vor dem Hintergrund der vorhandenen und geplanten Hardwarekonfiguration sollte die Location der DB-Files unter Sicherheits- und Zugriffsverteilungsaspekten genau geplant werden. Dabei ist die Ausnutzung von Hardwarefeatures wie Mehrkanalzugriff unbedingt zu berücksichtigen und oft sehr effektiv.

Nur zentrales Modul anpassen

Eine wesentliche Voraussetzung für die Arbeit in dem Projekt ist die Schaffung eines definierten Umfeldes. Dazu gehören sowohl klare Absprachen über die Programmstrukturen und Schnittstellen als auch die Benutzung einheitlicher Testprozeduren, soweit kein Tool eingesetzt wird. Eine Festlegung der Dateinamen-Nomenklatur, insbesondere unter Berücksichtigung der Sicherungsversionen, ist erforderlich. Bezüglich der Funktionsaufrufe in den Anwenderprogrammen sollte vermieden werden, sich der Herstellerschnittstellen zu bedienen, sondern es sollte ein eigenes, zusätzliches Zugriffsmodul (in das eventuelle kompatible Schnittstellen der Hersteller eingebettet sind) geschaffen werden. Der Vorteil liegt auf der Hand: Bei Austausch des DB-Systems muß nur das zentrale Schnittstellenmodul angepaßt werden. Änderungen in den Anwenderprogrammen entfallen.

Aus Gründen des Datenschutzes und der Datensicherung ist die Einhaltung einer Test-DB unverzichtbar. Der wahlweise Zugriff auf die Echt-/Test-Daten muß ohne Änderungen in den Anwenderprogrammen möglich sein. Bietet das DB-System diese Möglichkeit nicht, hat es sich bewährt, eine geeignete Oberfläche selbst zu schaffen.

Die Testphase erfordert neben der Design-Phase sicherlich die intensivste Zusammenarbeit zwischen EDV- und Anwenderabteilung. Die Zusammenstellung der überprüfbaren Testdaten sollte schwerpunktmäßig durch die Anwenderabteilungen erfolgen. Dem muß eine rechtzeitige Schulung der Anwender vorausgehen. Die Schwierigkeiten so banaler Dinge wie Gerätebedienungen sind dabei nicht zu unterschätzen. Dabei ist es wenig hilfreich, wenn highsophisticated EDV-Gurus ihren Wissensvorteil ohne Fingerspitzengefühl deutlich machen.

Zur Erhöhung der Akzeptanz in den Fachabteilungen sollten diesen rechtzeitig Testmodelle zur Verfügung gestellt werden. Ein Benutzerhandbuch einschließlich einer Fehlerdokumentation sollte spätestens zu diesem Zeitpunkt vorliegen um den Anwendern die Möglichkeit zu geben, sich bereits jetzt mit dem System vertraut zu machen. EDV-Chinesisch ist in diesen Unterlagen fehl am Platz. Zusätzlich muß die EDV-Abteilung den Fachabteilungen einen Ansprechpartner zur Koordination zur Verfügung stellen.

*Raymond Treß ist Geschäftsführer der Wiskom GmbH, Hannover