NIAM: Weg vom intuitiven Top-Down,
zurück zum exakten Arbeiten

von Heinz Axel Pürner, Unternehmensberatung Pürner in Dortmund

aus DOAG news Nr. 9 Dezember 93/Januar 94

• Top-Down-Vorgehensweisen
• Beispiel ERA
• Beispiel SA
• Beispiel OOA
• NIAM - die Alternative
• Zusammenfassung
• Literaturverzeichnis
• Zum Autor
   

Die weit verbreiteten Top-Down-Verfahren zur Modellierung von Unternehmensdaten oder -funktionen basieren auf dem Prinzip der hierarchischen Zerlegung. Da für die hierarchische Zerlegung keine objektive Vorgehensweise vorgegeben werden kann, können Analytiker mit unterschiedlichem Erfahrungshintergrund durchaus zu unterschiedlichen, subjektiven, nur bedingt nachvollziehbaren Ergebnissen kommen. Die Berufserfahrung der Analytiker ist für die Art und die Qualität der Zerlegung und somit des Ergebnisses von wesentlicher Bedeutung! Wie die Erfahrungen mit dem Einsatz dieser Verfahren zeigt, sind durchaus Zweifel an der Top-down-Vorgehensweise angebracht.

Einen anderen, leicht erlernbaren Weg geht dagegen NIAM - Nijssen Information Analysis Method, um zu einem objektiveren Ergebnis zu kommen.

Im folgenden werden Schwächen von Top-down-Ansätzen und hierarchischer Zerlegung beleuchtet und das Vorgehen von NIAM erläutert.

Ein grundlegendes Problem bei der Analyse und dem Entwurf komplexer Informationssysteme liegt darin, daß zwischen dem Auftraggeber und zukünftigen Anwender eines solchen Systems und dem Informatiker als Entwickler eine große Lücke klafft. Der Anwender weiß, was er braucht oder haben möchte, kann es aber in der Regel nicht unmißverständlich, vollständig oder gar formalisiert ausdrücken. Der Informatiker weiß, wie er ein Informationssystem zu implementieren hat, versteht aber die Problemstellung des Anwenders nur unvollständig und kann daher keine korrekte Lösung dafür entwerfen.

Gängige Ansätze zur Systemanalyse und zum Entwurf versuchen nun, den Informatiker mit Vorgehensweisen, Vorschriften zur Formalisierung und Diagrammtechniken in die Lage zu versetzen, aus unverstandenen oder unpräzisen Vorgaben ein brauchbares Informationssystem zu entwerfen. Bei den meisten dieser sogenannten Methoden ist aber die Formalisierungsphase stark abhängig von der menschlichen Kreativität. Das subjektive Problemverständnis und die Berufserfahrung des Informatikers haben wesentlichen Einfluß auf die Qualität des Ergebnisses.

Von einer Methode wird jedoch verlangt, eine Vorgehensweise so zu bieten, daß verschiedene Fachleute bei gleichen Voraussetzungen auf systematischem Weg zu identischen Ergebnissen kommen. Diese Anforderung wird vielfach nicht erfüllt, ja soll manchmal auch nicht erfüllt werden [5, Seite 52]!

Viele Ansätze haben nur eine äußerst unpräzise Ausgangsbasis und versuchen "top down" von sehr allgemeinen Annahmen und Definitionen durch Detaillierung (Verfeinerung) zu einer größeren Präzision zu gelangen. Dabei wird in der Regel die hierarchische Zerlegung (hierarchical decomposition) der grob definierten Systemteile als Vorgehen zur Verfeinerung unterstellt.

Eine Anleitung, wie bei der Zerlegung methodisch vorzugehen sei, gibt es nicht. Daher ist es auch nicht möglich, Informatikstudenten die hierarchische Zerlegung zu lehren oder Berufsanfängern eine praxisgerechte Einweisung darin zu geben!

Auch die Werkzeuge, die solche Vorgehensweisen unterstützen, sind in erster Linie nur Mittel zur Dokumentation und zur Erzeugung von Grafiken, nicht aber zur Automatisierung von Abläufen.

Der weit verbreitete, geradezu schon klassische Ansatz zur Entwicklung von Informationssystemen geht davon aus, zunächst grobe Strukturen des Systems (Unternehmens, Bereichs) zu entwerfen. Es werden globale Architekturen dargestellt, die verfeinert, d.h. mit realen Details gefüllt werden müssen. Es wird abstrahiert, was heißen soll, daß mit Begriffen gearbeitet wird, die stellvertretend für sehr viele Einzelfälle in Erscheinung treten können [12, Seite 83] - ohne die Einzelfälle zu kennen und zuvor analysiert zu haben!

An Pyramiden wird die Top-down-Vorgehensweise dargestellt [4, 12]. Man beginnt zum Beispiel mit unternehmensweiten Globalmodellen, die 4-6 Entitäten enthalten wie "Organisation", "Partner", "Produkt", "Objekt". Wozu soll denn die Darstellung allgemeiner Trivialitäten wie "Kunde kauft mehrere Produkte; Produkte werden von mehreren Kunden gekauft" nützen? Können Sie wirklich Basis für eine weitere Verfeinerung eines solchen Globalmodells sein?

In den letzten Jahren sind Zweifel an der Praktikabilität einer reinen Top-down-Vorgehensweise aufgekommen. So hat sich mittlerweile die Erkenntnis durchgesetzt, daß ein unternehmensweites Datenmodell, d.h. ein alle Datenfelder eines Unternehmens enthaltendes Modell, nicht top-down vom Grobem zum Detail zu entwickeln ist. Das aktuelle Glaubensbekenntnis enthält jetzt die Forderung, zuerst ein grobes, aber ausreichend verfeinertes Unternehmensmodell zu entwickeln, in dem wenigstens die Besonderheiten des Unternehmens erkennbar sind, - als Rahmen und Vorgabe für die anschließend zu erarbeitenden detaillierten Projekt- oder Bereichsmodelle. Inwieweit kann aber der grobe Rahmen schon Besonderheiten berücksichtigen, die erst in einer Detailanalyse zu Tage treten? Wie kann sichergestellt werden, daß die Projektmodelle sich an die Vorgabe oder den Rahmen des zuvor erstellten Grobmodells halten?

Erfahrungen haben jedoch schon gezeigt [6], daß dieser theoretische Ansatz nicht immer in konkretem Bezug zu den operativen Informationssystemen steht und daher den eigenen Zielen nicht gerecht werden kann. Deshalb wird auch an Verfahren zur automatischen Integration von Teilmodellen und ihrer Verdichtung zu einer Datenarchitektur gearbeitet.

Der Entity-Relationship-Ansatz (ERA) mit seinen vielen Varianten ist heute das meist genutzte Verfahren zur Erstellung von Datenmodellen. Bereits 1976 veröffentlichte Chen die Ideen zum Entity-Relationship-Ansatz [1]. Er unterscheidet als Ausgangsbasis zu seinem Ansatz vier Ebenen logischer Sichten auf Daten:

1. Informationen über Entitäten und Beziehungen, die in unserer Vorstellung existieren.
2. Informationsstrukturen - Organisation von Informationen, in der Entities und Beziehungen durch Daten repräsentiert werden.
3. Zugriffspfadunabhängige Datenstrukturen - Datenstrukturen, die nicht durch Zugriffspfade, Suchvorgänge oder Indizes beeinflußt sind.
4. Datenstrukturen abhängig vom Zugriffspfad.

Er stuft seinen Ansatz als Modell für die ersten beiden Ebenen ein, das Relationenmodell als adäquad für die Ebenen 2 und 3 und implementierungsorientierte Datenbankkonzepte wie das Netzwerk-Modell (CODASYL) für die Ebene 4.

Das ER-Modell führt also von subjektiven Vorstellungen über Informationsstrukturen zu einer einheitlichen, objektiven Darstellung von Informationsobjekten und ihren Beziehungen, die durch ihre Attribute exakt beschrieben werden. Es adaptiert den Top-down-Ansatz unter Benutzung der semantischen Informationen zur Organisation der Daten in Entity- und Beziehungsrelationen.

Diagramme stellen die Strukturen übersichtlich dar und erleichtern die Kommunikation auch mit dem DV-Laien.

Zunächst werden Entitäten klassifiziert und in verschiedene Mengen (entity sets) eingeordnet. Diese Mengen müssen nicht notwendig disjunkt sein. Ebenso werden die Beziehungen zwischen den Entitäten betrachtet. Dabei wird die Funktion, die eine Entität in einer Beziehung inne hat, als Rolle bezeichnet. Es können Beziehungen zwischen Entitäten einer, zweier (binäre Beziehung) oder mehrerer Entitätsmengen vorkommen. Entitäten können zu jeweils genau einer oder mehreren Entitäten - einseitig oder wechselseitig - in Beziehung stehen (1:1-, 1:n oder n:m-Beziehung). Dies wird auch als Kardinalität der Beziehung bezeichnet.

Informationen über Entitäten und Beziehungen werden durch ihre Attributwerte ausgedrückt.

Attribute beschreiben und konkretisieren damit Entitäten und Beziehungen. Wer in der Informationsanalyse auf die Beschreibung durch Attribute verzichtet, bleibt aber auf der obersten Ebene der subjektiven Vorstellung über Informationsstrukturen stehen. Das wirft aber die Frage nach dem Nutzen solcher fast attributloser Datenmodelle - auch gern als Unternehmensmodelle bezeichnet - auf. Entsprechend ist dann auch die Verbreitung solcher Modelle: Nach einer Untersuchung von Gemünden und Schmitt [3] haben nur 6% der befragten Unternehmen ein Unternehmensdatenmodell, 40 % dagegen Projektmodelle - und immerhin 9% waren die aufwendige Aufgabe angegangen, ein unternehmensweites Modell zu entwickeln.

Das ER-Modell in der 1976 vorgestellte Fassung läßt den Entwicklern viel Entscheidungs- und Interpretationsfreiraum. Der Wunsch, diesen durch weitere Regeln einzuschränken und so zu einem höheren Maß an Objektivität zu gelangen, ist sicher eine der Ursachen dafür, daß sich aus dem ursprünglichen Verfahren eine Fülle von Varianten entwickelt hat.

Ein anderer wichtiger Grund für die Entwicklung von Varianten liegt darin, daß der Ansatz doch noch zu wenig Konzepte zur Aufnahme der Semantik bot. Daher wurden weitere Konstruktionselemente zu Entitäten und Beziehungen hinzugefügt oder diese durch Aufsplittung präziser definiert.

Allen Varianten ist gemeinsam, daß sie top-down vorgehen wollen, aber keine expliziten Regeln für die Verfeinerungsschritte definiert haben.

Für die Modellierung der Funktionen wird heute meist die Methode der Strukturierten Analyse (SA) benutzt.

Die wesentlichen Prinzipien der Strukturierten Analyse (Structured Analysis) sind die Beschreibung der Funktionen oder Prozesse durch Datenflußdiagramme (DFD) und die hierarchische Verfeinerung dieser Funktionen.

Datenflußdiagramme bestehen aus Prozessen, Datenspeichern und externen Funktionsträgern, die durch Datenflüsse miteinander verbunden sind. Auf der obersten Ebene wird das gesamte System als ein Prozeß mit seinen externen Schnittstellen (Datenflüsse von und zu externen Funktionsträgern) in einem "Context"-Diagramm dargestellt. Die klassische Vorgehensweise sieht vor, in den folgenden Ebenen das System hierarchisch zu zerlegen. Im Zuge der hierarchischen Zerlegung wird ein Prozeß mit seinen Datenflüssen wieder als DFD mit Teilprozessen und aufgegliederten Datenflüssen dargestellt. Auf der untersten Ebene existieren nur noch Elementarprozesse und Flüsse von Datenelementen.

Bekannte Autoren über SA und seine Varianten bestreiten nicht, daß Systemanalytiker bei der Zelegung eines Systems nach SA zu unterschiedlichen Ergebnissen kommen. Auch die Versuche, durch weitere Regeln zu objektiveren Ergebnissen zu kommen, werden selbst von ihren Autoren als wenig erfolgversprechend [5, Seite 52] angesehen.

Bei komplexen Systemen mit vielen Schnittstellen ist es nicht einfach, das Kontextdiagramm der ersten Ebene zu erstellen. Yourdon [13, S. 352] schlägt für solche Fälle vor, stattdessen mit der Entwicklung eines ER-Modells zu beginnen. Auch die direkte Zerlegung des Kontextdiagramms im Sinne des Top-down-Vorgehens funktioniert nach seinen Erfahrungen meistens nicht [13, S. 360], weil

• der Systemanalytiker zu lange auf die göttliche Eingebung wartet,
• das Analytiker-Team das System im Sinne einer gleichmäßigen Arbeitsteilung so zerlegt, daß jeder mit genau einem Prozeß weiterarbeiten kann,
• die Zerlegung sich an derzeitigen organisatorischen oder implementierungsspezifischen Gegebenheiten orientiert.

Stattdessen wird daher ein komplexes Modell mit typischerweise mehr als 40 Prozessen entwickelt, das dann einerseits zur besseren Präsentation der Analyseergebnisse zu DFDs auf höherer Ebene zusammengefaßt wird, andererseits die fundierte Ausgangsbasis für weitere Zerlegungen bildet. Das komplexe Modell wird anhand eine Liste elementarer, externer Ereignisse erstellt, wobei ein Prozeß ein Ereignis bearbeitet. Diese Ereignisliste wird bei der Erarbeitung des Kontextdiagramms erstellt.

Die einfache grafische Darstellung läßt dem Leser viele Interpretationsmöglichkeiten offen. Die Benennung der grafischen Elemente durch treffende Aussagen ist für das Verständnis der Diagramme von großer Bedeutung. Für die Konsistenzprüfung der Zerlegung können lediglich die ein- bzw. ausgehenden Datenflüsse des zerlegten Prozesses herangezogen werden. Ein Konzept für die Analyse der fließenden oder gespeicherten Daten existiert nicht. Kandidaten für die Objekte der Datenspeicher findet der Analytiker unter den "Hauptwörtern ..., die jeder verwendet, wenn er über die technologieneutralen Teile des Systems spricht" [5, S. 306].

Warum setzen wir dann nicht gleich einen linguistischen Ansatz zur Modellierung wie NIAM ein?

Auch ein objektorientierter Ansatz (OOA), wie Coad und Yourdon ihn vorgestellt haben [2], bringt keine Verbesserung in der hier diskutierten Problematik! Der unbestreitbare Vorteil von OOA liegt darin, daß das Neben- oder gar Gegeneinander von daten- und funktionsorientierter Entwurfsmethode durch Integration beider Prinzipien in ein Verfahren aufgehoben und daß Strukturbrüche vor allem im funktionalen Bereich beim Übergang von Fachkonzeption zu DV-Entwurf und Implementierung vermieden werden.

Nach Coad und Yourdon [2] haben datenorientierte Ansätze zu einem besseren Verständnis der analysierten Systeme geführt, funktionsorientierte zu einem schnelleren, aber oberflächlicheren Entwurf. Daher legen sie in ihren Ansatz - wie auch andere, z.B. Spitta [11] - den Schwerpunkt auf die Informations- und nicht auf die Funktionsanalyse. Sie können aber für die Bestimmung von Objekten und Klassen keine konkreten Regeln aufstellen. Ihre recht allgemeinen Ratschläge lassen die Modell-Entwicklung immer noch stark im intuitiven, subjektiven Bereich ablaufen, was letztlich kaum zu einer Verbesserung von Analyse und Entwurf führt.

Spitta [11] lehnt ein Top-down-Vorgehen entschieden ab und vertritt die These, objektorientierte Systeme ließen sich nur bottom-up entwerfen. Die funktionsorientierten Top-down-Verfahren sind seiner Erfahrung nach zu aufwendig.

Faßt man die Erfahrungen des Autors und die aus verschiedenen anderen Quellen zusammen, so erzielen datenorientierte Verfahren die besseren Ergebnisse als funktionsorientierte. Eine reine Top-down-Vorgehensweise hat sich als nicht praktikabel erwiesen. Ja man muß schon sagen, daß der Mythos vom Top-down-Entwurf letztlich in und an der Praxis gescheitert ist! Daher ist es höchste Zeit, auf den Boden der Realität zurückzukehren. Statt Philosophien, Mythen und Versprechungen braucht die Anwendungsentwicklung exakte Vorgehensweisen und praxisgerechte Regeln. Nur ein sauberes, auch im Detail standardisiertes Arbeiten führt zu einem brauchbaren Systementwurf.

Eine Methode, die zu solchem Arbeiten anleitet, ist NIAM.

NIAM ist ein linguistischer Ansatz: Nijssen und Falkenberg nutzen in ihrem Ansatz zur Informationsanalyse Erkenntnisse der Prädikatenlogik und des Objekt-Rollen-Modells der Linguistik [C.J. Filmore, 1968]. Nijssen und Halpin haben 1989 eine überarbeitete Version von NIAM vorgestellt [7]: Darin wurde vor allem die Terminologie an den heute vorherrschenden Sprachgebrauch angepaßt (facts, entities, labels) und die Vorgehensweise pragmatisch in neun Schritten dargestellt. Ausgangsbasis ist dabei die Beschreibung des zu analysierenden Systems - auch Universe of Discourse (UoD) genannt - in Elementarsätzen. Ein Elementarsatz enthält eine eindeutige Aussage über das System und kann nicht mehr ohne Informationsverlust zerlegt werden: Eine Aussage = eine Tatsache (fact).

NIAM entfernt die zuvor geschilderte Abhängigkeit von der menschlichen Subjektivität aus allen Phasen außer dem ersten Entwurfsschritt. Der Rest der Formalisierungsphase und die Abbildungsphase können durch Werkzeuge automatisiert werden.

Formale Grundlagen

Ein Elementarsatz enthält eine Aussage, in der ein oder mehrere Objekte (Entitäten) vorkommen. Formal darstellbar als

R(e1,...,en)

mit R als Prädikat und e als Entitäten (Objekte), wobei die Reihenfolge der Entitäten von Bedeutung ist (z.B. e1 = Subjekt des Satzes).

In der natürlichen Sprache werden die Entitäten üblicherweise kurz durch ihre Namen (Bezeichner) ersetzt, z.B. "Wirth entwarf Pascal". Diese Namen werden in NIAM auch als Label bezeichnet. Ist der Zusammenhang dabei nicht eindeutig, so wird die Art der Referenz mit erwähnt, z.B. "Die Person mit dem Hausnamen Wirth entwarf die Programmiersprache mit dem Namen Pascal".

Die Elementaraussage unseres Beispiels kann aber auch als "Pascal wurde von Wirth entworfen" ausgedrückt werden. Dabei hat sich allerdings das Prädikat von "entwarf" in "wurde entworfen von" geändert.

Es ist daher sinnvoll, zu Darstellung der elementaren Tatsache (Fakt) die Form des Paares von Entität und ihrer Rolle zu wählen:

F{(e1,r1),....,(en,rn)}

Für unser Beispiel gilt:

Entwurf{(Person mit dem Hausnamen 'Wirth', entwarf),
         (Programmiersprache namens 'Pascal', wurde entworfen von)}

Die Reihenfolge der Paare aus Entität und Rolle sind nun beliebig. Diese Form wird in NIAM verwendet. Mit Hilfe dieser Darstellung der Fakten wird nun in einem neun Schritte umfassenden Vorgehen das konzeptionelle Schema entwickelt.

Neun Schritte zum konzeptionellen Schema

1) Umsetzung vertrauter Aussagen über das System (UoD) in Fakten

Es werden bekannte oder vertraute Aussagen über das System in Elementarsätze mit jeweils einem Fakt zerlegt. Es werden Entitäten, ihre Referenzierung, die Labels und die Rollen analysiert und Beispiel-Tabellen aufgebaut, in der die einzelnen Aussagen aufgeführt werden (Populationstabellen):

2) Zeichnen des ersten Schema-Diagramms

NIAM wird grafisch unterstützt: Entitätstypen werden als Kreise dargestellt und mit "Entitätstyp (Label)" beschriftet, Fakten bzw. Elementarsätze durch eine Reihung von Rechtecken, für jede Rolle eines, und mit Faktname und Rollennamen beschriftet. Die Referenzierung von Entitätstypen wird nur ausnahmensweise explizit dargestellt. Labels werden dabei durch gestrichelte Kreise symbolisiert.

Es werden keine Entitätstypen gezeichnet, die nicht in einem Elementarsatz angesprochen wurden, die also nicht mit einem Fakttyp verbunden sind.

Das Diagramm ist eine den Menschen entgegenkommende, unzweideutige, aber meist unvollständige Darstellung des konzeptionellen Schema.

3) Entfernen überflüssiger Entitäten und allgemeiner Rollen

Entitätstypen sollten überschneidungsfrei definiert werden. Einfache Prüfungen helfen, redundante Entitätstypen oder Rollen zu erkennen:

• Wenn Entitäten zu mehreren Entitätstypen gehören können, so sind diese Entitätstypen zusammenzufassen.
• Wenn Entitäten verschiedenen Typs sinnvoll miteinander verglichen werden können, sind sie zusammenzufassen.
• Wenn alle Entitäten verschiedener Typen dieselbe Rolle haben, so sind sie zusammenzufassen und es ist gegebenenfalls ein Fakttyp zu ergänzen, um eine ursprüngliche Unterscheidung zu erhalten.

4) Bestimmung der Eindeutigkeitsbedingung für die Fakten

Die elementaren Aussagen müssen redundanzfrei sein, d.h. daß in ihrer Populationstabelle doppelte Zeilen nicht erlaubt sind. Und sie müssen die realen Häufigkeitsbeschränkungen wiedergeben. Dazu wird zu jedem Fakttyp eine Eindeutigkeitsbedingung definiert.

Die Eindeutigkeitsbedingung besagt, daß ein Entitätswert oder eine Kombination von Werten nur einmal in den Ausprägungen dieser Satzart vorkommen darf, wenn sie unter diese Bedingung fallen. Sie wird in der Grafik durch Unterstreichung der Rollennamen oder durch Pfeile bzw. Striche am Rollensymbol hervorgehoben.

Für Elementarsätze gilt, daß für eine Satzart mit N Rollen eine Eindeutigkeitsbedingung existieren muß, die mindestens N-1 Rollen umfaßt. Ist dies nicht erfüllt, kann die Satzart weiter zerlegt werden.

5) Prüfung auf Zerlegbarkeit

Aussagen werden solange zerlegt, wie dies ohne Informationsverlust möglich ist. Die Überprüfung funktionaler Abhängigkeiten zwischen den Rollen eines Fakttyps gibt Hinweise auf seine weitere Zerlegbarkeit.

Ein Fakttyp mit N Rollen muß mindestens eine N-1 Rollen umfassende Eindeutigkeitsbedingung (auch als Schlüssel bezeichnet) besitzen, sonst kann er weiter aufgesplittet werden.

6) Definition von Subtypen, "Muß/Kann"-Rollen, Wertevorräten und Häufigkeiten

Subtypen werden nur definiert, wenn mindestens eine spezifische Rolle für sie existiert. Die Zugehörigkeit zu einem Subtyp wird durch mindestens eine Rolle des Supertyp bestimmt.

Bleiben Werte einer Rolle unbestimmbar, so handelt es sich um eine optionale Rolle ("Kann"-Rolle). Pflichtrollen ("Muß"-Rollen) umfassen immer die gesamte Population des zugehörigen Entitätstyps und werden im Diagramm gekennzeichnet. Besitzt ein Entitätstyp nur eine Rolle, ist diese eine Pflicht-Rolle und die entsprechende Kennzeichnung entfällt.

Treten in mehrwertigen Aussagen auch optionale Rollen auf, führt das zu einer Fakt-Entity-Wandlung (Nesting).

Für Entitäten mit begrenztem Wertevorrat wird dieser angegeben.

Bei Rollen, die nicht unter die gekennzeichnete Eindeutigkeitsbedingung fallen, wird die Häufigkeit angegeben, mit der ein Rollenexemplar vorkommen kann.

7) Prüfung auf eindeutige Identifizierbarkeit

Die Art der Referenzierung wird darauf überprüft, ob eine eindeutige Identifizierung erzielt wird. Es kann durchaus sein, daß erst eine Kombination von Rollen für die eindeutige Identifikation sorgt.

Bei Synonymen wird ein Begriff zur Identifikation ausgewählt, die anderen als Fakte dargestellt.

8) Weitere Integritätsbeschränkungen

Die Integritätsbeschränkungen werden in den Diagrammen symbolisch dargestellt. NIAM kennt noch folgende Integritätsbedingungen:

• Untermengen: Ist eine Rolle-1 als Untermenge zu einer Rolle-2 definiert, so muß die Menge der Werte zu Rolle-1 Untermenge zur Menge der Werte von Rolle-2 sein. Die implizite Mengengleichheit von "Muß"-Rollen wird nicht dargestellt.
• Gleichheit: Ist eine Rolle-1 als gleich mit Rolle-2 definiert, so muß die Menge der Werte zu Rolle-1 gleich mit der Menge der Werte von Rolle-2 sein. Diese explizite Angabe ist nur für optionale Rollen sinnvoll.
• Ausschließlichkeit: Schließt Rolle-1 Rolle-2 aus, so dürfen Elemente der Menge zu Rolle-1 nicht auch in der Menge von Rolle-2 existieren und umgekehrt. Auch diese Beschränkung kann nur auf optionale Rollen angewendet werden.

Außerdem können Berechnungsvorschriften, Vergleichsbedingungen und Bedingungen für Zustandsübergänge angegeben werden. Für diese gibt es keine Darstellung im Diagramm.

9) Prüfung auf Konsistenz, Redundanzfreiheit und Vollständigkeit

Die Prüfung auf Konsistenz des konzeptionellen Schema erfolgt durch die Populationstabellen der ursprünglichen Beispiele. Es dürfen keine eingeführten Beschränkungen verletzt werden.

Die Redundanzfreiheit wird durch Überprüfung von Eindeutigkeitsbedingungen und der abgeleiteten Fakten sichergestellt.

Die Vollständigkeit wird durch die Erstellung einer Tabelle überprüft, in der Elementaraussagen und die zugehörigen Elemente des Schema einschließlich der Integritätsbedingungen einander gegenübergestellt werden.

Damit ist die Erstellung eines konzeptionellen Schemas abgeschlossen.

Transformation ins Relationenmodell

Das konzeptionelle Schema ist eine solide Ausgangsbasis für den Entwurf des DV-Systems:

Für den Übergang zum relationalen Datenmodell und für den Entwurf von Strukturen eines realen Datenbanksystems werden die Elementarsätze nach gleichen Eindeutigkeitsbedingungen zusammengefaßt: Die Rollen, die komplett einer Eindeutigkeitsbedingung unterliegen und zum selben Entitätstyp gehören, bilden mit den weiteren Rollen ihrer Elementarsätze einen Gruppensatz. Einfacher ausgedrückt: es werden alle Elementarsätze mit gleichen Schlüsseln zu Gruppensätzen zusammengefaßt. Entitätstypen, die aus Satzarten gewandelt wurden, werden bei der Gruppenbildung wieder aufgelöst und auf die ursprünglichen Entitätstypen zurückgeführt.

Subtypen sind im Zweifel ihrem Supertyp zuzuordnen.

Die so entstandenen Sätze werden von Nijssen als Relationen in optimaler Normalform (ONF) bezeichnet, da sie die 5. Normalform nicht verletzen und zugleich in ihrer Anzahl minimal sind. Ihre Primärschlüssel sind die Rollen, die zu den Eindeutigkeitsbedingungen gehören. Ein solches Relationenmodell bildet die ideale Ausgangsbasis für das weitere Datenbank-Design.

Auch für den objektorientierten Entwurf bietet das konzeptionelle Schema zusammen mit Informationsfluß-Diagrammen (IFD), die in NIAM die prozessoralen Aspekte wiedergeben, die notwendigen Informationen. Es ist die präzise Grundlage für die Definition von Klassen mit ihren Methoden. Durch die Subtypen im konzeptionellen Schema sind auch die ersten Klassenhierarchien bereits definiert.

Der wesentliche Vorteil von NIAM liegt darin, daß das Verfahren bereits in der frühen Phase der Informationsanalyse eine formale Vorgehensweise anbietet. Zunächst intuitive Entscheidungen, ob eine Tatsache, wie beim ER-Ansatz, durch ein Attribut, eine Beziehung, ein Gerund oder eine Entität darzustellen ist, entfallen! Auch das Problem, wie komplexe Sachverhalte dargestellt werden können, existiert nicht: Ihre textliche Beschreibung gibt die Darstellung vor. Die Vorgehensweise ist klar definiert und läßt nur wenig Raum für subjektive Entscheidungen oder Interpretationen des Systementwicklers.

NIAM ist leicht erlernbar, exakt und weitgehend objektiv. Es ist auch in der Lage, stark zeitabhängige Sachverhalte zu beschreiben [7]. Erfahrungen, die aus Anwenderabteilungen berichtet werden, beweisen zudem, daß auch Nicht-Informatiker mit dieser Methode gut zurecht kommen. NIAM bietet - unabhängig von allen Modeströmungen - gute Voraussetzungen, auf Dauer die Methode für die Systementwicklung zu sein.

(1) Chen, P.P.S.: The Entity-Relationship Model: Toward a Unified View of Data, in: ACM Transaction on Database Systems, Vol. 1 No. 1, 1976

(2) Coad, P., Yourdon, E.: Object-Oriented Analysis, 2nd edition, Verlag Prentice Hall, Englewood Cliffs, 1991

(3) Gemünden, H. G., Schmitt, M.: Datenmanagement in deutschen Großunternehmen - Theoretischer Ansatz und empirische Untersuchung, in: Information Management 4/91, IDG Verlag, München, 1991

(4) Martin, J.: Information Engineering, Book II: Planning and Analysis, Verlag Prentice Hall, Englewood Cliffs, 1990

(5) McMenamin, S.M., Palmer, J.F.: Strukturierte Systemanalyse, Verlag Prentice Hall, London, 1988

(6) Mistelbauer, H.: Datenstrukturanalyse in der Systementwicklung
in: Müller-Ettrich, G.: Effektives Datendesign, Verlag Rudolf Müller, Köln, 1989

(7) Nijssen, G.M., Halpin, T.: Conceptual Schema and Relational Database Design, Verlag Prentice Hall, Sydney, 1989

(8) Pürner, H.A.: Moderne Methoden der Datenmodellierung - ein Vergleich bereits etablierter und neuerer Verfahren, in:
Fähnrich, K.P.: Software-Engineering und Software-Werkzeuge, Kongreßband VI - Online 89, Online GmbH, Velbert, 1989

(9) Pürner, H.A.: NIAM - Eine Methode zur Informationsanalyse - Die Alternative zu Top-Down-Ansätzen, in:
Heilmann, W.: Informationsmanagement: Strategien und Logistik der Informationsverarbeitung, Kongreßband VII - Online 92, Online GmbH, Velbert, 1992

(10) Reusch P., Wintraecken, J.-J.: Systemanalyse und Systemspezifikation, BI-Wissenschaftsverlag, Mannheim, 1990

(11) Spitta, Th.: Objektorientierte Systemanalyse und Prototyping, in: Information Management 2/92, IDG Verlag, München, 1992

(12) Vetter, M.: Aufbau betrieblicher Informationssysteme mittels konzeptioneller Datenmodellierung, Verlag B.G. Teubner, Stuttgart, 1990

(13) Yourdon, E.: Modern Structured Analysis, Verlag Prentice Hall, Englewood Cliffs, 1989

Dipl.-Ing. Dipl.-Ök. H. A. Pürner, hat sich auf die Fachgebiete Information Engineering und Datenbank-Technologie spezialisiert. Er ist Inhaber der
Unternehmensberatung Pürner
- Ingenieurbüro für Informationstechnologie -