Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

22.11.1991 - 

Streitpunkt Unternehmensdaten-Modellierung

Datenmodellierung: Theorie und Praxis gehen auseinander

Während sich die meisten Unternehmen über die Notwendigkeit einer Datenmodellierung einig sind, werden die Unternehmensdaten-Modellierung und die unternehmensweite Datenmodellierung oft mit Skepsis betrachtet. Betriebe, die übergreifende Modellierungsaktivitäten ablehnen, halten nach der Erfahrung von Manfred Gerisch in der Regel auch eine strategische Informationsplanung für überflüssig.

In der COMPUTERWOCHE Nr. 30 vom 26. Juli 1991 war zu lesen, daß laut einer unlängst durchgeführten Untersuchung 96 Prozent der deutschen Großanwender mit Datenmodellierung vertraut seien. Was immer der Begriff vertraut in diesem Zusammenhang bedeuten mag - der Schluß, daß sich die Datenmodellierung als integraler Bestandteil der DV-Projektierung in der Praxis umfassend durchgesetzt habe, ist sicher verfrüht.

Unstrittig ist, daß bereits viele Unternehmen erste Erfahrungen bei der Datenmodellierung gesammelt haben. Einige Hindernisse, die auf dem Weg zum Datenmodell zu überwinden sind, sowie eine Reihe charakteristischer Probleme, mit denen sich der Verfasser bei Datenmodellierungs-Aktivitäten in mehreren Unternehmen auseinanderzusetzen hatte, sollen im folgenden diskutiert werden.

Ausgangspunkt ist klare Zielvorstellung

Ausgangspunkt jeglicher Aktivitäten in der Datenmodellierung muß eine klare Zielvorstellung sein, was damit eigentlich erreicht werden soll. Davon hängt ab, welche Art von Datenmodell zu entwickeln ist und welche Folgeaktivitäten auf diesem Modell aufsetzen müssen.

Für die Datenmodellierung gibt es zwei Einsatzgebiete, die unterschiedliche Modelle zum Ergebnis haben: die strategische Informationsplanung (SIP) und die DV-Projektierung. Bei der SIP geht es um die Analyse der wesentlichen Informationskomplexe und Geschäftsprozesse eines Unternehmens und deren Beziehungen untereinander, wobei DV- und Datenbankaspekte keine Rolle spielen.

Ein Teilergebnis der strategischen Informationsplanung ist

das Unternehmensdaten-Modell. Es soll

- die wichtigsten Informationszusammenhänge im Unternehmen transparent abbilden,

- die Begriffswelt des Unternehmens einheitlich und verständlich definieren und

- Schwachstellen in der Organisation des Unternehmens sichtbar machen.

Das Unternehmensdaten-Modell dient als Verständigungsmittel zwischen den Fachabteilungen des Unternehmens und als Rahmen für die Datenmodellierungs-Aktivitäten der DV-Abteilung.

Bei der DV-Projektierung ist die Datenmodellierung die erste Aktivität innerhalb eines Prozesses, der als "integriertes Datenmanagement" bezeichnet werden kann. Dieser Prozeß umfaßt die Tätigkeiten

- Datenmodellierung,

- Datenbankentwurf,

- Datenbankdefinition mit Data Definition Language (DDL),

- Datenbankimplementierung,

- Bereitstellen von Datenstrukturen für Programme.

"Integriert" bedeutet in diesem Kontext, daß

- die Ergebnisse jeden Schrittes in den Folgeschritten weiterverarbeitet werden,

- Teilergebnisse maschinell aus den Ergebnissen vorangegangener Schritte

abgeleitet werden,

- eine integrierte Datenhaltung als Gesamtergebnis des Prozesses erzielt

wird

Innerhalb des DV-Phasenkonzeptes ist die Datenmodellierung eine Aktivität der Analysephase. Als Ergebnisse entstehen einerseits Projektdaten-Modelle, zum anderen ein übergreifendes Datenmodell, das als globales oder auch als unternehmensweites Datenmodell bezeichnet wird. Beide Typen sind die Basis für den Entwurf aller eingesetzten Datenbanken.

Das Projektdaten-Modell ist das Ergebnis der Datenmodellierung, bezogen auf das einzelne DV-Projekt. Es gibt die Teilsicht der an der Projektierung beteiligten Fachabteilungen auf die Gesamtheit der Unternehmensdaten wieder und ist die Basis für die Ableitung des externen Schemas für das jeweilige Datenbanksystem. Somit ist das Projektdaten-Modell nicht nur Verständigungsmittel zwischen Projektteam und Fachabteilung, sondern dient insbesondere zur Kommunikation der DV-Projektanten mit der Datenadministration (DA).

Kernpunkt einer integrierten Datenhaltung ist, die Datenbanken neutral gegenüber Einzelanwendungen und deren lokaler Sicht auf die Daten zu konzipieren. Anders ausgedruckt: Datenbanken sollen bereichsübergreifend und redundanzfrei sein. Das zu gewährleisten ist Aufgabe des konzeptionellen Schemas von Datenbanksystemen. Dessen Vorläufer auf der Datenmodell-Seite ist das unternehmensweite Datenmodell, das Ergebnis der Datenmodellierung bezogen auf die Gesamtheit aller DV-Projekte im Unternehmen, das iterativ durch die Integration von Projektdaten-Modellen entsteht.

Dieser oft als Konsolidierung bezeichnete Prozeß ist die Aufgabe der Datenadministration. Das unternehmensweite Datenmodell ist sowohl die Basis für die Erarbeitung des konzeptionellen Schemas durch die Datenbankadministration (DBA) als auch Vorgabe für die DV-Projektanten, die weitere Projektdaten-Modelle erarbeiten.

Beide Einsatzgebiete stehen nicht beziehungslos nebeneinander. Im Idealfall geht die strategische Informationsplanung der DV-Projektierung voraus und definiert unter anderem die erforderlichen DN-Projekte sowie deren Bearbeitungsprioritäten.

Die ersten Projektdaten-Modelle, die im Rahmen der aufgesetzten Projekte entstehen, orientieren sich am Unternehmensdaten-Modell als Vorgabe und Richtlinie. Mit Wachsender Anzahl realisierter Projekte geht diese Rolle immer mehr auf das unternehmensweite Datenmodell über. Dennoch sollte das Unternehmensdaten-Modell auch weiterhin separat verfügbar und aktuell gehalten werden.

So weit zur Theorie - doch wie sieht die Praxis aus? DV-Projektierung setzt heute nicht mehr auf der grünen Wiese auf. Viele Projekte sind bereits realisiert. Von daher wird eine strategische

Informationsplanung, obgleich in jedem Falle sinnvoll, oft vom Management nicht für erforderlich gehalten. In einem solchen Umfeld ist es dann schwer, die Notwendigkeit eines Unternehmensdaten-Modells deutlich zu machen.

Generell scheint die Akzeptanz für übergreifende Modellierungsaktivitäten geringer zu sein als für Projektdaten- Modellierung. Folgende Argumente sind häufig zu hören:

- Wir brauchen unsere Daten nicht mit denen anderer Bereiche abzustimmen, da es zwischen ihnen keine Gemeinsamkeiten gibt.

- Der Aufwand für das Vereinheitlichen von Begriffen ist uns zu hoch und hält uns in der Projektarbeit auf.

- Organisatorische Schwächen im Unternehmens fest zustellen lohnt nicht, da wir sie ohnehin nicht beseitigen können.

- Die Kosten übergreifender Aktivitäten werden durch den erzielten Nutzen nicht aufgewogen.

Die Argumentation verrät, einen erstaunlichen Mangel an Problembewußtsein, zeigt aber auch folgendes Dilemma: Niemand kann nachweisen, wieviele Doppelarbeiten, unnötige Sonderzweige in Programmen, Programmierfehler, Mängel in aggregierten, Daten etc. auf die unzureichende Abstimmung der Informationsbeziehungen zwischen verschiedenen Projekten zurückzuführen sind. Ebenso läßt sich nicht nachweisen, ob diese Mangel auf Mißverständnisse begrifflicher Natur, auf organisatorische Ungereimtheiten im Unternehmens, auf Mängel in Schlüsselsystematiken oder auch auf die Unkenntnis der DV-Projektanten von unternehmensinternen Informationszusammenhängen zurückzuführen sind und welche Kosten das verursacht.

Wer sich täglich als Daten- oder Datenbankadministrator mit dem Datenchaos in der DV-Projektierung auseinanderzusetzen hat erfolgt über eine ungefähre Vorstellung diesen Dingen. Aber wie kann er seine Eindrücke am besten demjenigen vermitteln, der das Budget für die übergreifenden Datenaktivitäten bewilligen muß?

Je höher die Datenadministration in der Hierarchie des Unternehmens angesiedelt ist, um so leichter werden ihre Argumente berücksichtigt. Auch sind die Chancen besser, bei der Datenanalyse erkannte Schwächen in der Unternehmensorganisation zu beheben. Eine Datenadministration auf der untersten Ebene der DV-Abteilung bleibt dagegen in ihrer Wirksamkeit beschränkt.

Zurück zum Unternehmensdaten-Modell. Manche sind der Meinung, man könne ein solches Modell von außen importieren (beispielsweise das Modell nach Scheer). Grundsätzlich kann jedes verallgemeinerte Datenmodell nützliche Hinweise für die Entwicklung eines eigenen Unternehmensdaten-Modells liefern, aber es kann nicht dessen Stelle einnehmen. Das hängt mit der Untermenge von Informationsbeziehungen (Subject Area) zusammen, die im Unternehmensdaten-Modell behandelt werden sollte.

Leider wird in Schullungen und Veröffentlichungen zu sehr darauf abgehoben, das Unternehmensdaten-Modell sei ein Top-Level-Modell, das später in der DV-Projektierung verfeinert werden müsse. Es bringt aber wenig, im Unternehmensdaten-Modell Trivialsachverhalte in m:n-Beziehungen der Form 'Ein Kunde kauft mehrere Produkte - ein Produkt wird an mehrere Kunden verkauft' abzubilden.

Gefragt ist vielmehr das, was alle DV-Projekte an übergreifendem einheitlichen Wissen brauchen, also insbesondere alle Aspekte der Unternehmensstruktur und -organisation. Diese Sachverhalte sind aber unternehmensspezifisch und können von einem neutralen Modell nicht abgedeckt werden.

Zwar kann man gegebenenfalls das Unternehmensdaten-Modell zur Disposition stellen, nämlich wenn das unternehmensweite Modell dessen Rolle mit übernimmt, doch das unternehmensweite Datenmodell ist als Basis des konzeptionellen Schemas von Datenbanksystemen unersetzlich. Die Notwendigkeit einer integrierten Datenhaltung sollte eigentlich heute keiner Erklärungen mehr bedürfen. Um dieses Ziel zu erreichen, sind Projektdaten-Modelle notwendig, aber diese allein reichen nicht aus. Mit ihnen läßt sich Datenchaos nicht beseitigen - es wird lediglich um ein Datenbeschreibungs-Chaos angereichert.

Unternehmensweite Datenmodellierung darf nicht als zeitlich begrenzter Vorgang begriffen werden. Die entsprechenden Modelle leben, da sie durch die laufenden DV-Projekte ständig erweitert und modifiziert werden.

Die Frage "Wann seid Ihr denn endlich einmal fertig mit dem unternehmensweiten Datenmodell?" kann der Datenadministrator folglich nicht definitiv beantworten.

Als Methode der Datenmodellierung gewinnt das Entity-Relationship-Modell (ERM) immer mehr an Boden gegenüber dem Relationenmodell, weil es insbesondere bei den Beziehungen semantisch aussagefähiger ist. In methodischer Hinsicht ist das ERM leicht verständlich und einfach nachvollziehbar. Das kann aber nicht, verhindern, daß beim praktischen Einsatz der Methode in der Projektdaten-Modellierung bestimmte charakteristische Fehler begangen werden.

Einige Fehler resultieren aus dem unzureichendem Verständnis des Zusammenhangs von Beziehungen und Schlüsseln. So werden oft Fremdschlüssel als beschreibende Attribute von Entitäten aufgeführt, anstatt sie in entsprechende Beziehungen umzusetzen. Das bedeutet, ERM und Relationenmodell miteinander zu vermischen.

Manchem DV-Projektanten ist der Unterschied zwischen Primär- und Fremdschlüsseln nicht ausreichend geläufig. Teilidentifizierende Attribute in Primärschlüsseln erweisen sich oft bei näherem Hinsehen als redundant und entsprechen in Wirklichkeit einer Beziehung der Kardinalität 1 auf eine andere Entität oder gehören unter die beschreibenden Attribute.

Das Entity-Relationship-Modell hat auch noch Lücken in methodischer Hinsicht. Die drei klassischen Beziehungstypen des ERM nach Chen (1:1, 1:n, m:n) reichen in der Praxis nicht aus.

Wesentlich für das richtige Modellverständnis sind auch die impliziten Beziehungen, die keine zusätzlichen Fremdschlüsseleinträge erfordern, sondern über teilidentifizierende Attribute innerhalb der Primärschlüssel bereits abgebildet sind. Dazu gehören:

- die hierarchische Beziehung (Characteristic Relationship) zwischen einer Entität und einer von ihr abhängigen Entität (Dependent Entity, attributive Entität);

- die Superentity-Subentity- Beziehung (Classification Relationship, Spezialisierung, Unternehmengenbeziehung) zwischen einer Entität und Untermengen dieser Entität;

- die Assoziativbeziehung (Association Relationship) zwischen einer assoziativen Entität (Beziehungsobjekt) und einer an ihrer Konstruktion beteiligten, aber von ihr sonst unabhängigen Entität;

- die Generalisierungsbeziehung (Generalization Relationship) zwischen einer Entität, in der mehrere Entitäten mit unterschiedlichen Schlüsseln unter einem Oberbegriff zusammmengefaßt sind (Generalisierung), und

einer der beteiligten Entitäten.

Für diese Beziehungstypen gibt es kein allgemeingültiges Verständnis, keine verbindlichen Bezeichnungen und keine einheitliche Symbolik in den Entity-Relationship-Diagrammen. Sie werden in den Tools zur Datenmodellierung nicht oder nur teilweise realisiert und dementsprechend in Methodiken und Schulungen zu wenig behandelt. Hier wäre eine Normierung äußerst wünschenswert.

Wie kann die Qualität von Projektdaten-Modellen verbessert werden? Zunächst sollte man sich klarmachen, daß Datenmodellierung ein spezifisches methodisches Wissen, eine längere Praxiserfahrung sowie eine umfassende Kenntnis innerbetrieblicher Informationzusammenhänge erfordert. Die Kurse, auf denen das methodische Grundwissen erworben wird, sind leider bei einigen Anbietern zu oberflächlich und nicht genügend praxisorientiert.

Ungünstig ist auch eine Projektorganisation, bei der ein ständig wechselnder Personenkreis für eine begrenzte Zeit während der Analysephase Datenmodelle erarbeitet, weil sich ein tiefergehendes Know-how auf diese Weise nicht bilden kann. Leider ist diese Organisationsform in der Praxis der Normalfall. Besser wäre, Datenmodellierungs-Kapazität im Bereich der Datenadministration zu konzentrieren und diese auch zur Erarbeitung von Projektdaten-Modellen einzusetzen.

Geschieht dies nicht, ist eine Qualitätskontrolle der Projektdaten-Modelle durch die Datenadministration sowohl während der Erarbeitung als auch nach Abschluß der Analysephase unerläßlich. Das darf sich nicht nur auf Vollständigkeit und Einhaltung formaler Richtlinien beschränken, sondern muß die inhaltliche Seite mit einschließen. Leider wird immer wieder von Projektteams unter Termindruck die Klärung offener fachinhaltlicher Probleme vernachlässigt, die das Datenmodell beeinflussen, besonders dann, wenn Abstimmungen mit anderen Projekten und Fachabteilungen erforderlich sind.

Konsolidierung und Integration

Eine der wichtigsten Datenmodellierungs-Aktivitäten ist die Konsolidierung und Integration der Projektdaten-Modelle ins unternehmensweite Datenmodell. Wie dabei vorzugehen ist, wird aber in den gängigen CASE-Methodiken kaum behandelt. Dabei handelt es sich hier um eine der zeitraubendsten Arbeiten, die die Datenadministration auszuführen hat, vor allem dann, wenn die Datenmodellierung der Projekte relativ isoliert voneinander abläuft. Auf keinen Fall ist das eine Tätigkeit, die ein Tool per Knopfdruck zufriedenstellend erledigen kann.

Ein Werkzeug kann zwar Diskrepanzen und Widersprüche zwischen verschiedenen Datenmodellen feststellen, nicht aber die erforderlichen Entscheidungen treffen, wie diese Widersprüche aufzulösen sind. Wie sollte es beispielsweise darüber befinden, ob die, jeweils aus einem anderen Projekt stammenden Entitäten Vertreter, Provisionsempfänger und Vertretung das gleiche meinen? Wie sollte das Tool beurteilen. ob die Schlüsselnummer einer schaft dreistellig ist, wie das eine Projekt glaubt oder fünfstellig, wie ein anderes behauptet? Hier ist der menschliche Sachverstand gefragt, der über richtig oder falsch befinden muß. Hinderlich bei Konsolidierungsprozessen ist, wenn, für Entitäten in den Projektdaten-Modellen zu allgemeine Bezeichner, gewählt werden. Die Entität Auftrag des einen Projektes mit der, Kundenauftrag gemeint ist, kollidiert bei der Konsolidierung natürlich mit der Entität Auftrag eines anderen Projektes, die eigentlich Produktionsauftrag heißen müßte.

Grundsätzlich sollten Entitätsnamen so differenziert wie möglich sein, allerdings ohne daß dabei ihre Verständlichkeit verloren geht. Entitätsnamen in DV-Chinesisch, die nur aus Abkürzungen bestehen, erhöhen nicht gerade das Modellverständnis.

Wer hat schon eine Vorstellung, was beispielsweise mit PROD-UKZ-GUETE-LORT-VERP-CH gemeint sein konnte?

Problematisch für die Konsolidierung von Projektdaten-Modellen ist auch, wenn beispielsweise

- zwei Projekte zur gleichen Entität verschiedene Primärschlüssel verwenden,

- die in Datenbanken realisierten Teile des unternehmensweiten Datenmodells ignoriert werden,

- die Projekte bereits vorhandene Entitäten unter anderem Namen erneut anbieten,

- logische Ungereimtheiten und physische Aspekte der Datenaltlasten in das Datenmodell übernommen werden sollen. Datenmodellierung ist eine Tätigkeit, die nicht allein mit Bleistift und Papier bewältigt werden kann, sondern den Einsatz geeigneter CASE-Tools voraussetzt. Jedes Datenmodell besteht aus den Entity-Relationship-Diagrammen, die Entitäten und Beziehungen in, Überblick zeigen sowie aus detaillierten Beschreibungen der Entitäten, Beziehungen, Attribute und Datentypen.

So unverzichtbar Diagramme als Darstellungsmittel bei der Datenanalyse sind, so liegt doch der Schwerpunkt der Modelldokumentation bei den Beschreibungen. Die Meta-Objekttypen des Datenmodells stehen in Beziehung zu den Meta-Objekttypen des Fuktionenmodells (zum Beispiel Prozeß, Funktion) und werden in der Entwurfsphase zu Meta-Objekttypen des Datenbankentwurfs (zum Beispiel Relation, File, Datenbank) weiterverarbeitet.

Folglich sind Tools mit Dictionary-/Repository-Charakter, die alle für die DV-Projektierung erforderlichen Meta-Objekttypen und deren Beziehungen untereinander abbilden können, das Rückgrat jeglicher

Datenmodellierung. Hinsichtlich, ihrer Metastruktur können solche Tools offen (zum Beispiel Data Manager, Rochade) oder geschlossen (zum Beispiel ADW, Predict Case) sein. Offen heißt, daß eigene Meta-Objekttypen vom Anwender definiert werden können, während geschlossene Metastrukturen nur die Tool-Hersteller vorgesehenen Objekttypen unterstützen.

Welche dieser Varianten ist für die Datenmodellierung günstiger? Geht man vom heutigen Entwicklugsstand der Tools aus, so bevorzugen besonders Neueinsteiger in die Datenanalyse die geschlossenen Tools, da diese den Anwender besser methodisch führen. Je mehr Erfahrungen aber vorliegen, um so schmerzlicher werden die in den Tools noch vorhandenen Mängel und Lücken spürbar und um so stärker wird der Wunsch nach einer offenen Metastruktur.

Möglicherweise entwickelt sich in absehbarer Zeit im Rahmen von AD/Cycle mit dem IBM-Repository eine standardisierte Metastruktur für Dictionaries/Repositories, auf der alle Tool-Hersteller aufbauen können. Dennoch ist ein Trend zu offenen Metastrukturen nicht auszuschließen. Die offenkundige Differenz zwischen Anspruch und Wirklichkeit von CASE läßt eine gewisse Vorsicht ratsam erscheinen, was den Grad der fachlichen Durchdringung des Themas Metastruktur für den, gesamten Softwarentwicklungs- und -wartungsprozeß angeht.

Was ist gegenwärtig an Tools mit geschlossener Metastruktur zu bemängeln? Einige Beispiele zu ADW und Predict Case sollen stellvertretend auch für andere Tools genannt werden. ADW ist das wahrscheinlich ausgereifteste Tool in bezug auf Entity-Relationship-Modellierung. Dennoch kennt es keine impliziten Beziehungen, hat aber einige Möglichkeiten, Teilaspekte über Entitäten auszudrücken (attributive Entität, assoziative Entität, Konstruktion der Primärschlüssel assoziativer Entitäten über Beziehungsbezüge). In den Diagrammen wird allerdings nicht sichtbar, welche Entität der attributiven Entität übergeordnet ist oder aus welchen Entitäten die assoziative Entität konstruiert wird.

Viele haben ein zusätzliches Data Dictionary

Die Hauptschwäche von ADW scheint darin zu liegen, daß es nicht Data-Dictionary-Charakter hat, was unter anderem im Fehlen einer Abfragesprache oder in der Workstation-Trennung zum Ausdruck kommt. Das veranlaßt viele Anwender, neben ADW noch ein zusätzliches Data Dicitionary einzusetzen.

Bei Predict Case ist von den impliziten Beziehungen nur die Spezialisierung unterstützt. Dabei sind aber einige Ungereimtheiten in Kauf zu nehmen. Teilobjekte dürfen keine eigenen Schlüsselbezeichner haben. Somit lassen sich für die Identifier der Teilobjekte gültige Subdomänen nicht abbilden, und das Rollenverhalten ist aus den später in Predict-Files eingetragenen Fremdschlüsseln nicht mehr ersichtlich. Auch darf ein Informationsobjekt nicht Teilobjekt mehrerer Spezialisierungen sein.

Schwerfällig sind die angebotenen Kopiermechanismen sowie die Möglichkeiten, mit Projektsichten auf ein gemeinsames Datenmodell zu arbeiten (Kontext), vergleicht man sie beispielsweise mit der Subject Area in ADW oder dem Statuskonzept des Data Manager. Hinderlich ist dabei auch die im Sinne der Normalisierung sicher gut gemeinte Einschränkung, daß ein Datenelement, nicht mehreren Informationsobjekten zugeordnet werden kann.

Wieso aber ein Tool, das primär auf Adabas/Natural mit der Möglichkeit von Periodengruppen und multiplen Feldern ausgerichtet ist, keine Multiattribute zuläßt, oder warum zusammengesetzte Attribute in Datentypen statt wiederum in Attribute zerlegt werden, ist eigentlich nicht nachvollziehbar.

Die Hauptschwäche von Predict Case aus Sicht der Datenverwaltung ist, daß ab dem Datenbankentwurf auf als Predict als Dictionary übergegangen werden muß. Damit reißen die Beziehungen zwischen Datenmodell und Datenbankentwurf ab, was negative Folgen für die Konsistenz der Datenbeschreibungen haben kann.

Übersichtlichkeit laßt zu wünschen übrig

Ein letztes Wort zu Entity-Relationship-Diagrammen. Um die Übereinstimmung von Dictionary-Beschreibungen und Diagrammen zu sichern, ermöglichen viele Tools eine gemeinsame Bearbeitung (zum Beispiel ADW) oder mindestens die Ableitung von Diagrammen aus dem Dictionary-Inhalt. So wünschenswert die automatische Konsistenzsicherung ist - was bisher in dieser Weise an Diagrammen geliefert wird, ist für praktische Belange kaum brauchbar.

Ob ADW, Manager View, oder Predict Case Workstation, sie alle liefern Ergebnisse, die an Übersichtlichkeit zu wünschen übrig lassen, insbesondere wenn die Anzahl der Entitäten und Beziehungen gewisse Werte überschreitet. Hier sind dringend weitere Möglichkeiten der Diagrammaufbereitung (Umsetzen von Koordinaten. Vergrößern und Verkleinern von Symbolen, Aufteilen von Diagrammen, Einbeziehen selbstdefinierter Symbole) erforderlich.

Solange das nicht ausreichend unterstützt wird, sind zusätzliche Entity-Relationship-Diagramme, die mit allgemeinen Grafik-Tools (zum Beispiel GEM, Freelance) hergestellt werden, in der Praxis unverzichtbar. Zusammengefaßt läßt sich feststellen: Die Datenmodellierung ist aus der DV-Projektierung nicht mehr wegzudenken. Wenn sie jedoch maximale Effekte erzielen soll, wird noch einiges sowohl von den CASE-Entwicklern als auch von den Anwendern getan werden müssen.