Die Nachfrage nach einem Standard-Datenmodell steigt

Wichtig für Integration von Standard- und Individualsoftware
von Heinz Axel Pürner, Unternehmensberatung Pürner in Dortmund

aus COMPUTERWOCHE Nr. 42 vom 19.10.1990

In der Anwendungsentwicklung und beim Einsatz von Standardsoftware spielt ein unternehmensweites Datenmodell eine immer zentralere Rolle. Heinz Axel Pürner diskutiert die Vor- und Nachteile eines vorgefertigten konzeptionellen Datenmodells - eines Standard-Datenmodells also.

Mit dem Bedürfnis vieler Unternehmen nach besserer Informationsversorgung sind auch die Daten als wertvolle Ressourcen anerkannt worden. Sie sind nicht mehr nur die Betriebsmittel der funktionalen Systeme. Viele Unternehmen sind heute dabei, ihre "Welt" in einem konzeptionellen Datenmodell abzubilden. Erst auf dieser Basis ist die Entwicklung integrierter bereichsübergreifende DV-Systeme sinnvoll und erfolgversprechend.

Andere Unternehmen dagegen setzen vorwiegend Standard-Anwendungssoftware ein und wollen damit die Entwicklung eines Datenmodells überflüssig machen. Das Angebot an Standard-Datenmodellen, die ein Unternehmen erwerben und als Basis für die eigene Anwendungsentwicklung einsetzen kann, ist noch recht neu.

Weil den Anwendern in den letzten Jahren neue DV-Technologien mit Sprachen der 4. Generation, relationalen Datenbanken und einer Vielzahl weiterer Werkzeuge angeboten wurden, habe ich 1987 folgenden Vorschlag gemacht [3]: Anstelle von bereits fest codierten Anwendungen sollten Konzepte und speziell Datenmodelle übernommen werden, die dann auf der konzeptionellen Ebene adaptiert und mit Werkzeugen der 4. Generation implementiert werden.

Da heute auch von anderer Seite Standard-Datenmodelleangeboten werden, erscheint es sinnvoll, die Rolle des Datenmodells in der Anwendungsentwicklung und beim Einsatz von Standardsoftware einmal kritisch zu diskutieren sowie einige Anmerkungen zur qualitativen und preislichen Bewertung zu machen.

Standardsoftware beruht auf der Idee, daß eine einmal geschaffene Lösung auch von anderen Anwendern in dieser Form übernommen werden kann. Das klassische Beispiel dafür ist eine Finanzbuchhaltung, die nun wirklich nicht von jedem DV-Anwender neu implementiert werden muß. Bei vielen anderen Standardlösungen stellt sich jedoch das Problem der Anpassung an die individuellen Gegebenheiten. Diese verursachen dann als Modifikationen üblicher Standardpakete häufig Aufwand und Ärger.

In aller Regel trifft nämlich Standardsoftware die Bedürfnisse des Anwenders nicht genau. Bietet sie ausnahmsweise mehr, so muß sich der Anwender mit zu großen Datensatz-Definitionen und einem Programm-Overhead herumärgern. Bieten die Standards zu wenig oder in Teilbereichen nicht das Gewünschte, so müssen Datensätze erweitert, Programme ergänzt, ersetzt oder hinzugefügt werden.

Da häufig kein Source-Code ausgeliefert wird, sind Anpassungen entweder beim Hersteller in Auftrag zu geben, was die Kostenvorteile von Standardsoftware gegenüber Eigenentwicklungen erheblich reduzieren kann oder es müssen Ergänzungen über Datenschnittstellen angeflickt werden, was meistens zu problematischen Abläufen führt. Viele Standardpakete sind schon einige Jahre auf dem Markt und damit in ihrer Konzeption oft schon veraltet. Andere Produkte sind wiederum zu starr ausgelegt, als daß sie abweichenden Anwenderbedürfnissen gerecht werden können.

Da die meisten Standardpakete von heute noch konventionell, das heißt in Cobol, RPG oder Assembler, erstellt sind, ist auch die Unterstützung zur Generierung einer individuellen Konfiguration sehr begrenzt. Dies führt spätestens beim nächsten Releasewechsel zu Problemen, schlimmstenfalls sogar zur vollständigen Wiederholung des erstmaligen Anpas- sungsaufwands. Scheuen jedoch Management und DV-Abteilung den Anpassungsaufwand, so können Akzeptanzprobleme die Einführung und den Routine-Einsatz gefährden oder verhindern, weil der Anwender seine Probleme nicht befriedigend gelöst sieht.

Die Eigenentwicklung einer Anwendung verspricht eine maßgeschneiderte Problemlösung. Häufig ist jedoch die Aufgabenstellung so komplex, daß große, unüberschaubare Projekte daraus entstehen. Falsche Vorgehensweisen und Fehler im Fachkonzept führen zu Fehlentwicklungen, die, im schlimmsten Fall ihre Aufgabenstellung schlechter erfüllen als eine Software "von der Stange". Es ist durchaus nicht selten, daß die vollständige Lösung nach vielen Entwicklungsjahren so spät eingeführt wird, daß der Lösungsansatz mittlerweile überholt, das heißt veraltet ist.

Um für die Eigenentwicklung einer Problemlösung Ideen zu sammeln, wird sich die DV-Abteilung auch bei anderen Unternehmen über deren Vorgehensweise informieren. Warum dann nicht gleich eine vollständige Lösungsidee in Form eines konzeptionellen Modells übernehmen und überarbeiten? Die dritte Möglichkeit neben Standardsoftware oder Eigenentwicklung besteht also darin, ein vorgefertigtes konzeptionelles Datenmodell oder Modell-Informationsschema zu übernehmen, an die individuellen Bedürfnisse anzupassen und mit der Software-Technologie der 4. 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.

Realisierungsphase wird deutlich kürzer

Die Anpassungen werden auf der Ebene des Fachkonzepts, nicht an fertigen Dateien und Programmen vorgenommen. Schließlich läßt sich eine maßgeschneiderte Lösung realisieren. Nach der Überarbeitung des konzeptionellen Modells werden die Tabellen des relationalen Datenbankmanagement-Systems (RDBMS) definiert und die Benutzersichten (Views) festgelegt.

Durch den Einsatz moderner Entwicklungssysteme mit relationaler Datenbank, Data Dictionary (beziehungsweise ein Information Resource Dictionary System (IRDS) oder - im IBM-Jargon - ein Repository), Sprachen der 4. Generation und weiterer Werkzeuge wird die Realisierungsphase auf ein Bruchteil konventioneller Eigenentwicklung verkürzt. Die modernsten Werkzeuge sind durchaus in der Lage, die Beschreibungen und Modelle der konzeptionellen Ebene weiter zu verarbeiten und daraus Datenbank-Definitionen und Anwendungscode zu generieren.

Nicht außer acht gelassen werden darf der Nutzen, der durch die Informationsanalyse und Datenmodellierung zusätzlich außerhalb der Systementwicklung entsteht: Durch die Informationsanalyse und den Aufbau eines Datenelemente-Katalogs wird die Informations- und Begriffswelt des Unternehmens zusammengeführt und vereinheitlicht. Dadurch vermindern sich Mißverständnisse und Reibungen innerhalb des Unternehmens. Erst die Vereinheitlichung schafft auch die Voraussetzung für die Entwicklung integrierter Informationssysteme.

Noch scheuen sich viele Anwender, ein unternehmensweites Datenmodell zu entwickeln, obwohl dieses eine notwendige Voraussetzung für den Einsatz bereichsübergreifender DV-Lösungen ist. Nachrichten vom Scheitern einiger Versuche, zum Teil aufgrund falscher Methodenwahl, sorgen für zusätzliche Hemmungen.

Auch 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 Standardpakets entspricht oder dieses übertrifft. Die Übernahme eines fremden Datenmodells ist jenem Modell überlegen, das nur von wenigen Spezialisten entwickelt wurde.

Neutrale Instanz muß Kompromisse finden

Mit dem Berater und Software-Ingenieur, der das Modell zur Verfügung stellt, werden diese Strukturen ein weiteres Mal diskutiert und angepaßt. Dabei fließen natürlich auch die Erfahrungen des Beraters aus vorangegangenen Projekten ein. Bei der Einführung einer einheitlichen und verbindlichen Begriffswelt durch das Datenmodell in das Unternehmen ist es sicher von Vorteil, wenn bei Meinungsverschiedenheiten zwischen den Fachbereichen eine neutrale Instanz zur Verfügung steht, von der der Kompromiß übernommen werden kann: das Modell-Informationsschema. Das Know-how, das bei der Anpassung des Datenmodells an die individuellen Gegebenheiten eines Anwenders gewonnen wird, wird auch in das Standard-Datenmodell integriert, so daß dieses mit dem Einsatz- Zyklus eine höhere Reife gewinnt. Im Interesse des Kunden muß natürlich sichergestellt sein, daß nun nicht sein individuelles Datenmodell weiter vermerktet wird.

Wie aber ist ein solches Modell-Informationsschema preislich zu bewerten? Mit etwa 70 Mark, dem Betrag also, den der Anwender für A. W. Scheers Buch "Wirtschaftsinformatik" [1] ausgeben muß? Der Professor beschreibt einen Industriebetrieb in einem Modell mit etwa 160 Entities und Gerunds sowie etwa 110 Beziehungen.

Oder mit mehreren 100 000 Mark? Soviel kostet ja in etwa auch die Ausrüstung eines Unternehmens mit Standardsoftware! Schließlich ist die Qualität des Konzeptes entscheidend für die Güte der eingesetzten Lösung. Doch man sollte nicht vergessen, daß trotz des vorgefertigten Datenmodells der Benutzer noch viel Arbeit investieren muß: Das Modell ist zu analysieren und mit der existierenden Organisation zu vergleichen. Im Unternehmen fallen außerdem organisatorische Aufräumarbeiten, Standardisierungen sowie die Beseitigung von Homo- und Synonymen an. Und schließlich muß ja auch noch implementiert werden.

Ausschlaggebend für die preisliche Bewertung des Modell-Informationsschemas ist unter anderem, wie unabhängig das Schema von einer Werkzeug-Umgebung (DDS, Generatoren) ist. Dabei ist entscheidend, ob es sich leicht in eine, bereits vorhandene Tool-Landschaft integrieren läßt oder ob mit ihm auch ein kompletter zugehöriger Werkzeugsatz, vom IRDS (Information Resource Dictionary System) bis zur Sprache der 4. Generation, eingekauft werden muß.

Weiterhin kommt es darauf an, ob das Schema zusammen mit Beratungsleistungen erworben wird oder ob beides getrennt zu berechnen ist. Daß diese Beratungsleistungen notwendig sind, steht wohl außer Zweifel, sonst hätten ja heute, dank der theoretischen Unterstützung von Scheer, bereits alle Industrieunternehmen ein unternehmensweites Datenmodell - für gerade 70 Mark.

Wie umfangreich sollte ein solches Standard-Datenmodell sein? Ist seine Größe - zum Beispiel die Anzahl der Entitäten - eine Qualitätsaussage beziehungsweise ein Maßstab für den Preis? Je nach eingesetzter Variante des Entity-Relationship-Ansatzes (ER-Ansatz) erhöht sich die Anzahl der Entities und der Beziehungen zugunsten einer inhaltlichen Vereinfachung der Beziehungen. Daher sind "Kennzahlen" wie die Anzahl der Entities nur beschränkt aussagefähig. Andere Methoden als der ER-Ansatz kommen zu ganz anderen "Kennzahlen" - so zum Beispiel die Nijssen Information Analysis Method (NIAM) - obwohl diese Methoden inhaltlich dasselbe darstellen.

Sicher ist mit einem reinen Überblicksmodells, das ein ganzes Unternehmen in zehn Entitäten darstellt, niemandem geholfen. Insbesondere unternehmensindividuelle Eigenschaften sind hier überhaupt nicht darstellbar. Eine kleine bis mittlere Anwendung kann in einem Datenmodell von 20 bis 40 Entities abgebildet werden. Es gibt sogar Empfehlungen, "komplexe" Modelle mit mehr als 20 Objekttypen zur Bearbeitung in Teilmodelle aufzuspalten (Münzenberger in [2]).

Was bieten dann Standard-Modelle mit mehr als 400 Entities? Und wer kann diese noch überblicken? Diese 400 Entities mit ihren Attributen müssen in dem Unternehmen, das dieses Modell übernimmt, detailliert bearbeitet und mit den eigenen Gegebenheiten verglichen werden. Die Qualität eines Datenmodells hängt aber nicht nur von der Detaillierung (Anzahl Entities) ab, sondern auch von der sorgfältigen Definition der Attribute sowie von der Definition sinnvoller Wertemengen (Domänen) und der vollständigen Darstellung aller Integritätsbedingungen (Semantic constraints).

Ein Datenmodell, das nur aus Grafik und einer Liste von Entities mit Attributen besteht, ist zu wenig. Entitäten und Beziehungen müssen exakt beschrieben, ihre Attribute eindeutig definiert sein. Kurztexte zur Erläuterung reichen nicht aus. Die Entwurfsüberlegungen müssen nachvollziehbar bleiben und im Modell erkennbar sein. Integritätsbedingungen, die ja für eine jederzeit einwandfreie Übereinstimmung von Modell und Realität sorgen sollen, sind wesentlicher Bestandteil eines guten Datenmodells. Bei der Frage nach der Methode zur Darstellung des konzeptionellen Modells stellt man fest, daß sich bisher die Familie des Entity-Relationship-Ansatzes von Chen durchgesetzt hat. Aber auch andere Methoden, wie NIAM, sind möglich und bieten in einigen Punkten durchaus Vorteile gegenüber dem ER-Modell.

Weniger geeignet sind dagegen reine Relationenmodelle in dritter, vierter oder fünfter Normalform - sie enthalten zu wenig Semantik. Elementarrelationen sind als Basiskonstrukt einfach zu wenig, um komplexe Sachverhalte eindeutig und nachvollziehbar auszudrücken.

Kann nun der Anwender, der sich zur Einführung von Standardsoftware entschließt, darauf verzichten, ein Datenmodell zu entwickeln? Wohl nur unter dem kurzfristigen Aspekt, daß keine Individualsoftware entwickelt wird. Doch über die reine Sicht althergebrachter Anwendungsentwicklung hinaus kann es sich kein Informationsmanager mehr leisten, nicht zu wissen, welche Informationen in seinem Unternehmen verarbeitet und benötigt werden. Der größte Nutzen durch die Datenmodellierung wird ja schließlich außerhalb der DV erreicht: nämlich dadurch, daß die Informations- und Begriffswelt des Unternehmens zusammengeführt und vereinheitlicht wird.

Das Datenmodell dient außerdem als Integrationsrahmen für Standardsoftware und Eigenentwicklung. Erst damit läßt sich wirklich beurteilen, inwieweit eigene Bedürfnisse durch das Standardpaket abgedeckt werden können, beziehungsweise, wie leistungsfähig eine Standardsoftware eigentlich ist. Auch können die Lücken im Informationssystem, die durch Eigenentwicklungen zu füllen sind, erkannt werden. Daher sollten Standardpakete in ihrer Dokumentation in Zukunft das fachliche Datenmodell und das Funktionsmodell enthalten.

In den nächsten Jahren werden sich immer mehr Unternehmen der unterschiedlichsten Branchen mit der Erstellung eines Datenmodells befassen müssen, um ihren Informationsbedarf analysieren und decken zu können. Daher wird auch die Nachfrage nach Standard-Datenmodellen steigen, zumal die Entwicklung eines individuellen Modells auf dieser Basis optimal und schnell erfolgen kann. Mit dem Angebot eines Standard-Datenmodells darf aber nicht die Erwartung vermittelt werden, es handele sich um eine Patentlösung, die ohne hinzusehen und ohne weitere Bearbeitung eingesetzt werden könne. Das Standardmodell gibt den Rahmen vor, zeigt Lösungsmöglichkeiten auf und kann im Falle sich streitender Fachabteilungen zum Standard gemacht werden.

Es bleibt die Arbeit, in der eigenen Organisation das Informationschaos aufzuräumen und zwischen verschiedenen sich auseinandersetzenden Bereichen Kompromisse zu finden. Diese Arbeit kann sehr mühsam und zeitraubend sein. Erleichtert wird jedoch der Start des Modellierungsprozesses: Man braucht nicht mehr das erste Musterprojekt auszusuchen oder das erste Globalmodell zu erstellen, in dem sich doch keiner wiederfinden will.

Literaturhinweise

[1] A. W. Scheer: Wirtschaftsinformatik, Springer Verlag, Berlin, Heidelberg, New York 1988.

[2] G. Müller-Ettrich (Hrsg.): Effektives Datendesign, Verlag R. Müller, Köln 1989.

[3] H. A. Pürner: Datenstruktur wird kundenspezifisch angepaßt, CW Nr. 33 1987, IDG-Verlag, München 1987.

[4] H. A. Pürner: Moderne Methoden der Datenmodellierung - ein Vergleich bereits etablierter und neuerer Verfahren, in K. P. Fähnrich (Hrsg.): Software-Engineering und Software-Werkzeuge, Proceedings Online 89, Verlag Online GmbH, Velbert 1989.