Neue Ansätze in der Datenmodellierung:

Die Attribute sollten hierarchisch vererbt werden

22.07.1988

Lutz Ahrens und Jürgen Hoffmann sind Mitarbeiter der Pylon Unternehmensberatung GmbH in Hamburg.

Insbesondere unter Kostengesichtspunkten konnte die Datenverarbeitung oft genug die notwendige Anpassung an die organisatorische Umgebung im Unternehmen mit herkömmlichen Techniken nicht leisten. Der Einsatz relationaler Datenbanksysteme und darauf abgestimmte Verfahren bestimmen in Zukunft die Informationsverarbeitung.

Die Realität EDV-technisch zu erfassen und abzubilden, ist Voraussetzung für die Dauerhaftigkeit eines daraus entwickelten Datenbestandes, seiner Struktur und den darauf operierenden Anwendungen. Die Erfahrungen der Vergangenheit mit ihren undurchsichtigen Daten- und Programmkomplexen haben mittlerweile zu den Erkenntnissen geführt, daß die Daten der Unternehmung ebenso zu behandeln sind, wie Produktionsfaktoren.

Insbesondere in einer Phase des Übergangs auf eine neue (relationale) Technologie bietet sich die Chance, die bestehenden historisch gewachsenen "Datenfriedhöfe" zu reorganisieren, und diese neuen Strukturen, im Sinne eines Produktionsfaktors, durch ein Datenmanagement verwalten zu lassen. Der Übergang von der hierarchischen in die relationale Welt bedingt den Einsatz entsprechender Methoden und Verfahren, um diese neue Welt zu planen und zu realisieren.

Die bisher angewandten Methoden der Ist-Aufnahme sind daher durch rein datentheoretische Ansätze ergänzt worden. Das Ergebnis dieser Ansätze sind kanonische Datenstrukturen. Eine kanonische Datenstruktur ist ein software- und hardwareunabhängiger, anwendungsneutraler und stabiler Bezugspunkt. Aus diesem lassen sich sowohl die logischen als auch die physischen Datenstrukturen ableiten, auf denen alle Anwendungen operieren.

Vor dem Hintergrund, daß Daten einer Unternehmung Produktionsfaktoren sind, ist auch klar, daß hier nicht ein Datenmodell einer Anwendung gemeint ist, sondern ein unternehmensweites Datenmodell für alle Anwendungen. Der einzige bisher überzeugende Ansatz zur Erstellung dieser unternehmensweiten Datenmodelle basiert auf dem Entity-Relationship Modell (ERM).

Geeignete Werkzeuge sind nicht vorhanden

Methoden, die auf diesem Ansatz basieren, zeichnen sich durch eine sehr wirtschaftliche, sichere und bei sorgfältiger Anwendung auch vollständige Erfassung der betrieblichen Umwelt aus. Es fehlen bisher aber geeignete Werkzeuge, die den Prozeß der Datenmodellierung bis hin zum relationalen Datenbankmodell unterstützen.

Nach unserer Ansicht wird der Stellenwert eines Datenmodells von vielen Anwendern zu niedrig angesetzt. Wir vertreten die Ansicht, daß Datenmodelle, seien es nun unternehmensweite oder nur projektinterne, nicht nur Modell- beziehungsweise Dokumentationscharakter haben. Das Datenmodell stellt immer ein Abbild der betrieblichen und organisatorischen Realitäten eines Unternehmens dar. Zu diesen Realitäten gehört auch die Speicherung und Verwaltung von Unternehmensdaten in einer elektronischen Datenverarbeitungsanlage.

In diesem Sinne muß das Datenmodell dem realisierten Datenbankmodell entsprechen. Voraussetzung hierfür ist, daß aus dem Datenmodell maschinell, also verifizierbar, das Datenbankmodell erstellt und realisiert wird. Wir gehen mit unseren Forderungen soweit, daß wir Änderungen am generierten Datenbankentwurf bezüglich der Relationen nicht zulassen. Mit anderen Worten: Das maschinell aus dem Datenmodell erzeugte Datenbankmodell mit seinen logischen und physischen Strukturen wird nachträglich nicht manuell geändert.

Das heißt nicht, daß das Datenbankmodell der dritten Normalform in 3NF vorliegen muß. In Abhängigkeit vom Zielsystem kann eine Verletzung dieser Bedingungen erwünscht beziehungsweise notwendig sein. Aber: Jede Argumentation, die aus Performance-Gründen einen Unterschied zwischen den logischen und physischen Datenstrukturen begründet, ist unzulässig.

Zu den beliebtesten Änderungen der logischen Strukturen zählt das Splitten einer Relation in mehrere kleine, das Zusammenlegen von mehreren Relationen in eine Tabelle und das Erzeugen von Redundanzen. Sollte dies aus Gründen der System-Performance tatsächlich unumgänglich sein, so stellt sich für uns die Frage, ob das eingesetzte Datenbanksystem den gestellten Anforderungen genügt. Wenn die Datenbankadministration - als verantwortliche Stelle - den Datenbankentwurf verbessern muß, so ist diese Änderung nicht an den physischen Strukturen durchzufahren, sondern immer im Datenmodell!

Es stellt sich jetzt die Frage, mit welchen Hilfsmitteln die Konsistenz von Datenmodell und Datenbankmodell sichergestellt werden kann. Die Speicherung von Datenmodellen allein in einem Data-Dictionary-System (DDS) kann schon aus Sicherheits- und Revisionsaspekten nicht genügen. Das Datenmodell als strategischer Mittelpunkt der DV-Aktivitäten in einem Unternehmen muß wie eine Programm-Source behandelt werden, das heißt, es unterliegt einer gesicherten und revisionsfähigen Source-Code-Verwaltung. Diese Verwaltungsmöglichkeiten bieten weder DDS noch Workbenches auf PC-Systemen.

Der Umkehrschluß, Datenmodelle nicht in einem Dictionary zu speichern, trifft nicht zu. Erst durch die Speicherung des Datenmodells in einem DDS werden diese Informationen für Anwender, Entwickler und Revisoren transparent. Wir plädieren dafür, aus dem Source des Datenmodells die Informationen maschinell in das Dictionary zu laden. Nur so kann sichergestellt werden, daß alle Einträge im Dictionary konsistent und nach einem einheitlichen Schema aufgebaut sind.

Es gilt also, einen Weg zu finden, folgende Ziele zu erreichen:

1. maschinelle Überführung des Datenmodells in ein Datenbankmodell, wobei zumindest folgende Nebenbedingungen erfüllt sein müssen:

a. Auflösung aller komplexen Beziehungen in zwei einfache 1:N-Beziehungen.

b. Automatische Generierung von Fremdschlüsseln in den Relationen.

c. Verwalten von Intersection-Data an Beziehungen.

d. Hierarchische Vererbung von Attributen.

e. Erzeugen der Syntax zum Laden der physischen Tabellen für das gewählte Ziel DBMS.

f. Prüfung des Modells auf Verletzungen der dritten Normalform.

g. Keine Abweichung der logischen von den physischen Strukturen. Änderungen an der Physik erfolgen im Modell.

2. Einbringen des Datenmodells in eine Source-Code-Verwaltung, um seine Revisionsfähigkeit sicherzustellen.

3. Speicherung möglichst aller Informationen des Datenmodells in einem DDS, um diese Informationen im Entwicklungsprozeß transparent zu machen.

a. Speicherung der Dictionary-Inhalte in einheitlicher Form.

b. Prüfungsmöglichkeiten hinsichtlich der im Unternehmen geltenden Standards, insbesondere der Namenskonventionen.

c. Ausschluß von manuellen Eingaben und Manipulationen direkt im DDS.

4. Erstellen einer standardisierten Dokumentation für Entwickler und Fachabteilung.

5. Unterstützung der Datenadministration und der Datenbankadministration durch die Möglichkeit, unterschiedliche Modelle zu vergleichen.

6. Einsatz grafischer Back-ends. Eine grafische Eingabeform erscheint uns wegen der Komplexität unternehmensweiter Datenmodelle nicht sinnvoll.

An unserer Forderung nach der hierarchischen Vererbung von Attributen wollen wir darstellen, wie ein solches Werkzeug den Prozeß der Datenmodellierung unterstützen kann.

Da das relationale Modell nur Schlüsselredundanzen zuläßt, muß der Entwickler bei der Namensvergabe unterstützt werden.

Insbesondere unter Berücksichtigung der Novellierung des Bundesdatenschutzgesetzes müssen Informationen, wie "Wer hat wann zuletzt die Tabelle/Relation geändert" nachgeholten werden. Hierzu werden die Attribute AENDERUNGSDATUM und USERID benötigt. Diese Datenelemente werden sicher nicht nur als Attribute einem Objekt zugeordnet. Die Speicherung dieser Informationen stellt noch keine Verletzung des relationalen Modells dar.

Es handelt sich hier nicht um Redundanzen oder Synonyme, denn in einem Fall geht es zum Beispiel um das Änderungsdatum des Objektes PERSON und im anderen Fall um das Änderungsdatum des Objektes STUECKLISTE. Die Vergabe eines Attributes BESTAND an die beiden Objekte erzeugt dagegen eindeutig eine Redundanz.

Bei dem Einsatz von Design-Tools ist der Anwender gezwungen, für die Attribute AENDERUNGSDATUM und USERID unterschiedliche Namen zu vergeben (zum Beispiel USERID_1 und USERID_2), um dem Relationen-Modell gerecht zu werden. Hier sollte das eingesetzte Design-Tool durch die Möglichkeit der hierarchischen Vererbung von Attributen eine Hilfestellung bieten.

Außerdem muß es möglich sein, für alle Datenelemente nicht nur den physischen Typ (beispielsweise CHARACTER (1)) sondern auch die möglichen Ausprägungen oder Wertebereiche (Domains) anzugeben.

Um insbesondere eine maschinelle Analyse von Datenmodellen durchzuführen und aus diesen Modellen automatisch ein Datenbankmodell für unterschiedliche Zielsysteme zu erzeugen, bietet es sich an, eine formale Spezifikationssprache einzusetzen. Diese Sprache beschreibt alle Elemente eines Datenmodells, also Objekte, Beziehungen, Attribute und Domains und läßt sich gleichzeitig wie Programm-Code maschinell verarbeiten.

Die Vorteile einer solchen Sprache und der entsprechenden Übersetzer und Generatoren liegen beispielsweise in einer einfachen Benutzeroberfläche, in der maschinellen Speicherung der gesamten Informationen des Datenmodells mit einheitlicher Form in einem DDS sowie in der Konsistenz von Datenmodell, DDS und Datenbankmodell.

Im Rahmen großer Reorganisationsprojekte hat sich gezeigt, daß der Einsatz einer solchen formalen Spezifikationssprache bei der Datenmodellierung zu den gewünschten Ergebnissen führt. Insbesondere ließen sich die geplanten Aufwände erheblich nach unten korrigieren und die Qualität der Dokumentation im Data-Dictionary automatisch sicherstellen. Es wurde aber auch deutlich, daß eine Unterstützung der Projekte durch eine sachverständige und methodisch geschulte Datenadministration unbedingt notwendig ist.