Pürner Unternehmensberatung

Datenstruktur wird kundenspezifisch angepaßt

Modell-lnformationsschema versus Standardsoftware
von Heinz Axel Pürner, Unternehmensberatung Pürner in Dortmund

aus COMPUTERWOCHE Nr. 33 vom 14.08.1987

Computerwoche Standardsoftware beruht auf der Idee, daß eine einmal geschaffene Lösung von vielen anderen Anwendern in dieser Form übernommen werden kann. Bei vielen dieser Lösungen stellt sich jedoch das Problem der branchen- oder firmenspezifischen Anpassungen. die als Modifikationen üblicher Standardpakete häufig Aufwand und Arger verursachen.

Der Einsatz von Standardsoftware ist zwar kostengünstiger als die Eigenentwicklung, jedoch mit einigen Problemen behaftet: Meist trifft Standardsoftware die Bedürfnisse des Anwenders nicht genau. Bietet sie ausnahmsweise mehr, so muß sich der User mit zu großen Datensatzdefinitionen und Programm-Overhead herumärgern.

Anpassungen erfolgen auf der Fachkonzept-Ebene

Bietet sie zu wenig oder in Teilbereichen nichts, was den Wünschen des Anwenders entspricht, so müssen Datensätze erweitert, Programme ergänzt, ersetzt oder hinzugefügt werden. Da die meisten Standardpakete von heute noch konventionell, das heißt in Cobol, RPG oder Assembler, programmiert werden, ist auch die Unterstützung zur Generierung einer individuellen Konfiguration sehr begrenzt. Dies führt spätestens beim nächsten Release-Wechsel zu Problemen, schlimmstenfalls sogar zur vollständigen Wiederholung des Erstaufwandes. Scheuen jedoch Management und DV-Abteilung den Anpassungsaufwand, so daß der Endbezieher seine Probleme nicht befriedigend gelöst sieht, können Akzeptanzprobleme die Einführung und den Routine-Einsatz gefährden oder verhindern.

Eine Alternative ist es, ein vorgefertigtes konzeptionelles Datenmodell - ein Informationsschema nach dem Objekt-Beziehungsansatz - zu übernehmen, an die individuellen Bedürfnisse anzupassen und mit Werkzeugen der vierten Generation in DV-Technik umzusetzen.

Ein solches Informationsschema entsteht im Rahmen der Entwicklung einiger Fachkonzepte nach der Methode der Informationsanalyse. Durch die Übernahme des Modells braucht man nicht mehr "auf der grünen Wiese" zu beginnen. Das Modell führt Analytiker und Fachabteilung durch die Problematik, zeigt neue Aspekte und Lösungsansätze auf und verkürzt so die Designphase gegenüber einer vollständigen Neuentwicklung. Die Anpassungen werden auf der Ebene des Fachkonzepts statt an fertigen Dateien und Programmen vorgenommen. Realisiert wird schließlich eine maßgeschneiderte Lösung.

Durch den Einsatz moderner Entwicklungssysteme mit relationaler Datenbank, Sprachen der vierten Generation und weiteren Werkzeugen läßt sich die Realisierungsphase auf ein Bruchteil konventioneller Eigenentwicklung verkürzen.

Als Beispiel für die Vorgehensweise kann die Einführung eines Data Dictionary in Ergänzung eines relationalen Datenbank-Management-Systems dienen. Gerade die relationalen DBMS-Produkte verfügen nur über einen Dateikatalog zur eigenen Steuerung; in den meisten Fällen reicht dieser Katalog dem Anwender nicht aus, da er nicht über die Bandbreite eines klassischen Data Dictionary verfügt. Es fehlen beispielsweise eine Reihe von Objekten, Projektmodelle sowie Informationen über den Einsatz von Mitarbeitern.

Obwohl eine Ergänzung des Datenkatalogs durch weitere Tabellen und deren Verknüpfung mit den Systemtabellen gerade bei einem relationalen Datenbank-Management-System keine Schwierigkeiten bereiten sollte, scheuen viele Anwender zu Recht den Aufwand, ein Data Dictionary "auf der grünen Wiese" nur für sich zu entwickeln. Hier hilft ein Modell-Informationsschema weiter: Ein solches Datenmodell enthält Strukturen, die bereits vorher entwickelt, durchdacht, diskutiert und adaptiert wurden. Man erhält einen konzeptionellen Lösungsvorschlag, der dem Niveau eines Standardpaketes entspricht oder es übertrifft.

Mit dem Berater und Software-Ingenieur, der das Modell zur Verfügung stellt, werden diese Strukturen ein weiters Mal diskutiert und angepaßt; dabei fließen natürlich auch die Erfahrungen des Beraters aus vorangegangenen Projekten ein. In dem so weiterentwickelten Informationsschema, das nun eine maßgeschneiderte Lösung darstellt, werden die Strukturen, die der Datenkatalog des Systems abdeckt, kenntlichgemacht, so wird deutlich, welche Entitäten und Beziehungen in Tabellen umgesetzt werden müssen. Dann lassen sich die Benutzersichten auf System- und eigenen Tabellen definieren.

Modell-Informationsschema
Die Objekt-Beziehungen eines Data Dictionar
im Rahmen des Modell-Informationsschemas

Das abgebildete Objekt-Beziehungsdiagramm zeigt einen solchen, zum Dictionary erweiterten Datenkatalog. Dabei werden in dieser vereinfachten Darstellung die Entitäten oder Objekte als Rechtecke und die Beziehungen als Kreise - statt der üblichen Rauten - dargestellt. Zu dem Datenmodell gehört selbstverständlich auch die Festlegung von Attributen, das heißt Feldern, zu den Objekten.

Die prinzipiellen Strukturen eines Datenkataloges sind in der Grafik Gelb hervorgehoben: Die Objekte "Datei', "Extent" und "Partition" enthalten Informationen über die physische Speicherung; die Objekte "Entität" und "Feld" beschreiben die gespeicherten Daten auf der logischen Ebene. Dabei spaltet sich das Objekt "Entität" noch intern in die Unterobjekte "Tabelle" und "Benutzersicht" mit einer N:M-Beziehung untereinander auf. Benutzer (Objekt "Mitarbeiter") können Rechte zur Datenmanipulation (Objekt "Recht") besitzen (Beziehung EL) oder auch vergeben, was durch die Beziehung VG dargestellt wird. Die Zugriffsrechte können sich auf Tabellen oder Sichten (Objekt "Entität') oder auf Felder (Objekt "Feld") beziehen. Für jeden Anwender werden sitzungsbezogene Abrechnungs- und Arbeitsprotokolle geführt, wie es durch das Objekt "Sitzung" mit seiner 1:N-Beziehung zu "Mitarbeiter" ausgedrückt wird. Der übrige Teil des Diagramms zeigt nun ein einfaches Modell-lnformationsschema eines Data Dictionary: Es enthält anwendungs- und projektbezogene Objekte ebenso wie DV-technische Informationen.

Projekte, die die Realisierung, Änderung oder Wartung von Anwendungen zum Gegenstand haben, gliedern sich in Phasen, zu denen wiederum Meilensteine gehören. Mitarbeiter können in einem Projekt feste Funktionen wie Projektleiter oder Sekretär ausüben, abgebildet in der Beziehung "Funktion", und in Projektphasen verschiedene Aufträge (Beziehung "Auftrag") ausführen. Die Mitarbeiter sind Kostenstellen zugeordnet; die Beziehung "Hierarchie" drückt die Personalverantwortung im Rahmen der Unternehmenshierarchie aus.

DV-Systeme bestehen aus Programmen und Jobs. Programme, die Aufgabenstellungen der Anwendungen lösen werden von Mitarbeitern verantwortlich erstellt beziehungsweise betreut. Sie bestehen nach diesem Ansatz aus Modulen, die sich gegenseitig aufrufen, auf Entitäten zugreifen, Listen erstellen und Masken benutzen können. Die Masken und Listen wiederum enthalten die Felder der Tabellen und Sichten.

Irrelevante Beziehungen sind nicht berücksichtigt

Dieses Modell-lnformationsschema wird nun mit den Anwendern diskutiert und deren Wünschen angepaßt. Diese Anpassungen an die individuellen Bedürfnisse können einfache Umbenennenden von Objekten und Feldern sein, zum Beispiel "Kostenstelle" in "Abteilung" Erweiterung oder Verringerung der Objekte und Beziehungen um Attribute (Felder) oder Veränderungen der Objekt-Beziehungs-Struktur. Es wird beispielsweise vorgeschlagen, Masken zu Bildschirmen (neues Objekt) für die sie freigegeben werden, in Beziehung zu setzen und diese wiederum über eine neue Beziehung "Standort" zur Abteilung oder Kostenstelle, wo sie aufgestellt sind .

Bei der Anpassung entfallen auch Beziehungen, die in der realen Welt des Anwenders nicht von Bedeutung sind, wie vielleicht die Zuordnung Liste - Mitarbeiter (Beziehung "Verteiler"). Nach der Überarbeitung des konzeptionellen Modells werden die Tabellen des relationalen Datenbank-Managementsystems (RDBMS) definiert und die Benutzersichten (Views) festgelegt.

Schwerpunkte bei der Einführung verschieben sich

Mit Hilfe der Werkzeuge, die heute fast jeder Hersteller um sein RDBMS gruppiert hat, werden Erfassungsprogramme und Auswertungen mit geringem Aufwand realisiert. Es soll allerdings nicht verheimlicht werden, daß in diesem Beispiel ein Problem noch im automatischen Erfassen oder Generieren von Informationen liegt. Dies gilt vor allem, wenn die Werkzeuge, für die das geschehen soll, deutlich außerhalb der "Welt" des RDBMS liegen, zum Beispiel für Maskensysteme von TP-Monitoren.

Eine analoge Vorgehensweise ist auch in anderen Anwendungsbereichen möglich, zum Beispiel in der Fertigung, Materialwirtschaft oder im Einkauf. Schließlich könnte die Standardsoftware von morgen aus einem Fachkonzept, einem Werkzeugkasten mit Datenbank und aus einer Musterimplementierung mit Standarddialogen und -berichten als Grundlage für die individuelle Lösung bestehen. Bei der Einführung dieser Standardpakete steht dann das Fachkonzept, seine Übernahme oder Modifikation, und nicht mehr das Problem bei der Programmanpassung im Vordergrund.

linie
Homepage | Informationstechnologie | Aktuelles | Datenbanken | DB2 | Publikationen
Links | Kontakt | Impressum | International Pages