Mit dem Einsatz eines Datenbank-Management-Systems treten in aller Regel Probleme auf, an die vorher niemand dachte. Probleme, die die Performance, das durch erweiterte Datenbestände eventuell notwendige Re-Design oder die verlängerten Laufzeiten von Batch-Programmen betreffen. Das DV-Management sieht sich aber nicht nur mit technischen Problemen konfrontiert, die letztlich alle lösbar sind. Schwerer sind psychologische Probleme zu bewältigen, die nach der DBMS-Einführung auftreten. Oft wird die DV-Crew in zwei "Kasten" aufgeteilt. eine, die durch neue Entwicklungen Lorbeeren einheimst; eine andere, die "im Verborgenen" Alt-Systeme pflegt. Unzufriedenheit im Team ist hier die Folge. Hier eine einvernehmliche Lösung zu finden, stellt das Management vor eine fast unlösbare Aufgabe. Denn auch Job-Rotation hilft kaum weiter, da sich Spezialwissen nicht beliebig teilen läßt. ih

Kurt Blank, Spartenleiter Systementwicklung INC Aktiengesellschaft für Betriebswirtschaft und DV, Köln

Jedes Unternehmen steht vor der Frage, welches Datenbanksystem das geeignetste ist.

Oft werden aufgrund von Herstellergarantien unüberlegt überdimensionierte Datenbanksysteme "ausgewählt" und installiert. Das Ergebnis ist, daß man ein zu komplexes Datenbanksystem als eigentlich nötig hat und daher mehr Aufwand betreibt als erforderlich.

Im einzelnen bedeutet dies: Es werden nicht alle Funktionen genutzt, sondern nur Teile, man braucht mehr Mitarbeiter (zum Beispiel für Design und Pflege der Datenbanken); die Datendefinitionssprache (DDS) ist sehr umfangreich; die Installation und Pflege der Datenbanken ist aufwendig; die Datenmanipulationssprache (DMS) ist komplex, umfangreich und schwierig; hoher Schulungsaufwand ist nötig, um das ganze System kennenzulernen; hoher Wissensaufwand ist insgesamt erforderlich. Dieser Mehraufwand kann vermieden werden.

Eine einmalige Erstellung eines Anforderungskataloges aller - Informationsbestände und Informationssysteme - auch der zukünftigen - würde ein Anforderungsprofil an ein Datenbanksystem ergeben, wie zum Beispiel Datenmengen, Datenstrukturen, Update, Sicherheit.

Beim Design wird oft der Fehler gemacht, daß die logische Datenstruktur eines Datenbestandes als physische Datenbank realisiert wird.

Im Detail:

- Zu starke Segmentierung ergibt einen Overhead an Calls und Speicher.

- Das Mengenprofil des Datenbestandes, des Datenbanksatzes (zum Beispiel 5 bis 20 KB) bringt einen erhöhten Suchvorgang im DB-Satz und einen umfangreichen IO-Bedarf.

- Das Updateprofil des Datenbestandes wird zu wenig einkalkuliert, so daß daraus häufige Reorganisationen oder schlechte Performance resultieren.

Maxime beim Design von physischen Datenbanken sollte sein:

- Keine unnötigen Systemoverheads an Speicher und Systemroutinen.

- Handhabbare Datenbestände vom Umfang her.

- Jede gewünschte Information mit einem IO zu erhalten.

- Ein updateneutrales Design zu garantieren.

Der Teufel steckt im Detail.

Datenbestände beziehungsweise Datenbanken erweitern sich oft in nicht vorhergesehener Weise. Dies würde oftmals ein Redesign oder sogar eine Neukonzeption von Datenbanken notwendig machen. In den meisten Fällen ist es nicht möglich, da der Änderungsaufwand der betroffenen Programme zu hoch ist. Damit haben wir ein weiteres Problem.

Bei fast allen Datenbankanwendern ist das spezielle Design einer Datenbank in den Anwendungsprogrammen enthalten. Das bedeutet, es werden Abhängigkeiten zwischen spezieller Datenhaltung und Anwendungslogik hergestellt. Diese Verbindung halte ich aus mehreren Gründen nicht für gut.

Sie führt:

- zu einer Inflexibilität der Datenhaltung aufgrund von Programmänderungen.

- Zu einem großen Schulungsaufwand (Kosten) der Programmierer (Belastung), damit auch zu einer größeren Abhängigkeit von installierten DB-Systemen.

- Zu einer Redundanz an Programmierung der Datenbankzugriffe.

Die Trennung der Datenhaltung von der Anwendungssoftware ist sinnvoll und erforderlich.

Diese Unabhängigkeit wird erreicht - durch Datenbankinterfaces. Sie stellen eine neutrale Schnittstelle zwischen Datenhaltung und Anwendungsprogrammen dar. Durch DB-Interfaces werden die oben genannten Nachteile umgangen. Auch bestehende Anwendungssoftware kann über ein zentrales Zwischeninterface unabhängig gemacht werden.

Wolf-Dieter Böhrendt, Unternehmensberater und Seminarreferent im Bereich DB/DC bei lntegrata GmbH, Tübingen

Es ist schon oft festgestellt worden, daß Datenbanken ihre Bedeutung in den meisten Anwendungen im Online-Betrieb zeigen. Integrierte DB/DC-Systeme, Logging, automatischer, Restart, konkurrierendes Update ohne Probleme, alles realisiert über das Transaktions-Konzept, das ist vielen EDV-Leuten heute (zumindest in der Theorie) geläufig.

In der Praxis können dabei Probleme auftreten, an die man vorher wirklich nicht denken konnte. Wie ist das beispielsweise mit der Stapelverarbeitung einer Datenbank?

Daß in vielen Fällen die Laufzeit eines Batch-Programmes durch den Einsatz der Datenbank erheblich verlängert wird, ist schon fast eine Binsenwahrheit. Wenn die Online-Anschaltzeiten unter dem ständigen Druck der Terminal-Benutzer länger als acht oder zehn Stunden täglich werden, oder sogar 2-Schicht-Betrieb im Werk entsprechende Online-Verfügbarkeit der Datenbank voraussetzt, bleibt immer weniger Zeit für die abendlichen Batch-Läufe. Nicht jeder RZ-Leiter will und kann tatsächlich 3-Schicht-Betrieb realisieren!

Dann muß die Anlage entsprechend dimensioniert und Batch-Verarbeitung parallel zum Online-Betrieb gefahren werden.

Daß dies nicht unproblematisch ist, hat sich inzwischen bei vielen Anwendern herumgesprochen. Bei manchen DB/DC-Systemen wird, vom Parallel-Betrieb Batch/Online zumindest abgeraten bei anderen werden doch erhebliche Klimmzüge auch in der System-Software gemacht, zum Beispiel IMS mit den sogenannten BMPs (Batch Message Programs).

In jedem Fall muß organisatorisch Vorsorge getroffen werden für Fehlerfälle, die auch die beste DB/DC-Software nicht vollautomatisch beheben kann. Hierzu ein einfaches Beispiel: Ein Batch-Job hat aufgrund eines Programm- oder Bedienungsfehlers die Datenbank fehlerhaft verändert (zum Beispiel falsches Kalenderdatum oder Buchungen plus statt minus), ohne eine Fehlernachricht zu erzeugen. Am nächsten Tag wird von den Terminalbedienern auf diesem fehlerhaften Stand aufgesetzt und die Datenbank weiter verändert, bis der Fehler festgestellt wird. In einer solchen Situation muß genau überlegt werden, was passiert sein kann; durch Vergleichsläufe alt/neu oder Auswertungen der Logdatei kann man rekonstruieren, was passiert ist. Auch auf solche Probleme sollte der DB/DC-Anwender gefaßt sein.

Wolf-Dieter Wrack, Unternehmensberater, Rehling-Unterach

Ist die Entscheidung für ein DBMS gefallen, treten in aller Regel zuvor unbekannte Probleme auf, die sich in technische und psychologische einteilen lassen.

Die geringsten sind noch jene, die die Performance und die daraus resultierenden Antwortzeiten betreffen: Eine größere, mächtigere Maschine behebt diesen Mangel. Schwerer wiegen schon jene, die sich durch eine überzogene Erwartungshaltung ergeben und großen Einfluß auf die Eingliederung in den bestehenden RZ-Betrieb haben. Stichworte: Verfügbarkeit und Sicherheit mit allen Unterpunkten, wie einfachem Handling, schnellen Recovery, Kenntnis der Anwendungszusammenhänge. Hierfür muß oft ein nicht unerheblicher Aufwand in Form einer zweiten RZ-Schicht getrieben werden um die normalen Batch-Arbeiten durchführen zu können.

Darüber hinaus sind erweiterte Sicherungsverfahren für die Daten erforderlich, die bei einer konventionellen Bestandsführung nicht nötig waren. Im Altverfahren stellten der Eingabe-File in Verbindung mit den Änderungen zugleich die Sicherung dar. Beim Inplace-Update müssen zusätzliche Maßnahmen ergriffen werden, die, bei entsprechender Datenmenge, zeitlich recht aufwendig sein können und darüber hinaus ein Problem-Bewußtsein der RZ-Mannschaft voraussetzen.

Alle diese Dinge jedoch sind letztlich plan- und lösbar.

Schwieriger wird es mit den psychologischen Problemen, die im Zusammenhang mit der Einführung eines DBMS entstehen können: Die Belegschaft wird in zwei Gruppen geteilt. Jene, die mit dem DBMS Neuentwicklungen betreiben und Lorbeeren einheimsen, und jene, die "im Verborgenen" die Altsysteme pflegen. Da in aller Regel aber die besten Mitarbeiter für Neuentwicklungen herangezogen werden, liegt hierin schon eine implizite Bevorzugung und Beförderung. In nicht wenigen Fällen wird hierdurch das Gehaltskarusell in Bewegung gesetzt und zum Wissensdefizit kommt der finanzielle Graben.

Ob Jobrotation hier hilft, ist zu bezweifeln, da die Kostenfrage in aller Regel verhindert, Spezialwissen an alle zu verteilen und allgemeine Besitzstands-Ängste dem entgegen stehen.