Fachhochschule vereinfacht IBMs ER-Modell:

Entity Relationship-Modell nach Chen weist Lücken auf

15.05.1992

Schwierigkeiten bei der Datenbankmodellierung fiir DB2 und wie an der Fachhochschule Heidelberg (FHD) damit umgegangen wird, schildern Alfred Moos, Karl Friedrich Rauland und Barbara Schneider*. Die Autoren kritisieren unter anderem fehlende Eigenschaften der referentiellen Integrität sowie die von der IBM bevorzugte Definition der Beziehungsgrade nach Peter Chen, die zu Mißinterpretationen führen könne.

In einem AD/Cycle-Studienprojekt, das die Fachhochschule Heidelberg derzeit gemeinsam mit der IBM Deutschland GmbH durchführt, wird untersucht, wie eine zukunftsorientierte und praxisgerechte Datenbankausbildung im Fachbereich Wirtschaftsinformatik aussehen könnte Die entstehenden Probleme und die möglichen Vorgehensweisen sind Gegenstand der folgenden Ausführungen.

Bei uns werden die praxisnahen Studieninhalte der Kerninformatik vorwiegend an IBM-Systemen vermittelt. Hierzu stehen ein IBM-Großrechner der Serie 9121, Modell 190, unter MVS/ESA sowie mehr als 100 PS/2 Systeme zur Verfügung. Die PS/2-Rechner sind durch zwei Token-Ring-Netzwerke aneinander gekoppelt. Diese Netze stehen über eine Kommunikationsbrücke in Verbindung mit dem Großrechner. Dadurch ist es möglich, daß jedes PS/2 System einerseits als Arbeitsplatz-Rechner und andererseits als Terminal des Großrechners agieren kann Die Kleinrechner werden derzeit zur Hälfte unter DOS und zur anderen Hälfte unter OS/2 betrieben.

Der Einstieg in die Welt der Daten geschieht mit Hilfe des Entity-Relationship-Modells (ERM), wobei dessen verschiedenen Spielarten explizit wie auch implizit eingeführt werden. Die aus dem LRM abgeleitete computerspezifische Datenbetrachtung führt über die Datenstrukturen nach Michael Jackson zu den Algorithmen für die Verarbeitung dieser Daten. Neben der Anleitung der Programm und Prozeßlogik aus dem Entitäten-Beziehungsmodell wird hieraus auch die Datei- oder Datenbankorganisation erstellt, in Abhängigkeit davon, auf welchem Ausbildungsstand die Studenten sich aktuell befinden.

Im Fach Datenbanken steht derzeit das relationale Datenbankmodell im Mittelpunkt der Ausbildung. Der praxisorientierte Teil hierzu wird den Studenten mit DB2 und dem zugehörigen SQL-Dialekt (Structured Query Language) nahegebracht. Zusätzlich schließen die Studenten mit dem Database Manager (DBM) unter OS/2 und dessen SQL-Dialekt Bekanntschaft.

Neben DB2 wird auch noch DL/1 gelehrt. Die praxisgerechte Ausbildung im Fach Datenbanken erfolgt nicht nur im relationalen Datenbankmodell, sondern auch in dem noch weit verbreiteten hierarchischen Datenbanksystem DL/1 (Data Language/1). Die dabei zu bewältigenden Schwierigkeiten in der Anwendung reichen von der Programmierung einer Rechnungsschreibung mit einfachen Datenstrukturen bis hin zur Programmierung einer Struktur und Mengenübersichts-Stückliste mit rekursiven Datenstrukturen. Die Gastsprache DL/1 ist hierbei in der Wirtssprache PL/1 eingebettet.

Wegen seiner großen Verbreitung in der DV-Praxis und der umfassenden Implementierung von Kriterien für relationale Datenballken, wie sie vom Schöpfer des relationalen Datenbankmodells, Edgar Codd, aufgestellt wurden, ist DB2 ein geeigneter Kandidat für die Datenbankausbildung von Wirtschaftsinformatikern. Probleme, die beim praktischen Einsatz von DB2 an einer Fachhochschule auftreten, ergeben sich zunächst aus einem großen Betriebsmittelverbrauch, und hier speziell aus der Belegung von Plattenspeicherplatz für Hilfsdateien, wenn die Einbettung von DB2 in TSO/ISPF/PDF genutzt wird.

IBM bemißt den Speicherplatz reichlich

Dieses Randproblem läßt sich jedoch lösen, wenn man die von der IBM allzu reichlich bemessene Speicherplatz-Zuordnung für die Hilfsdateien auf ein haltbares Maß reduziert. Hierzu sind zwei Maßnahmen erforderlich. Zum einen muß in den zuständigen ISPF-Prozeduren die Speicherplatz-Zuordnung für die Hilfsdateien auf ein Minimum zurückgesetzt werden. Dazu wurden in der Fachhochschule Heidelberg pro Hilfsdatei eine Primärmenge und eine Sekundärmenge von jeweils einer Plattenspur implementiert

Zum anderen hat seitens der Studenten eine strenge maschinelle Überprüfung des jeweils belegten Speicherplatzes zu erfolgen. Hierzu wurde bei uns eine Software geschaffen, die das benutzte Speicherkontingent überwacht und bei einer Kontingentsüberschreitung nur noch die Freigabe von nicht genutztem Speicherplatz sowie das Löschen von nicht mehr benötigten Dateien und die Übertragung von Dateien auf private Disketten ermöglicht.

Ein Schönheitsfehler von DB2 liegt derzeit noch darin, daß die Entitätsintegrität nicht automatisch überwacht wird, sondern daß auf einem Primärschlüssel hierzu explizit ein eindeutiger Index definiert werden muß.

Diese "wesentliche Kleinigkeit" ist im Database Manager (DBM) von OS/2 bereits imple mentiert. Dies zeigt auch, daß die Entwicklungslabors der IBM für die beiden Datenbanksysteme nicht auf gleichem Arbeitsstand sind: Die Arbeitsgruppe um den OS/2 DBM scheint - vermutlich wegen des geringeren Bedarfs an Kompatibilitätsrücksichtnahme - die Nase vorn zu haben.

Der Zugriff auf eine Tabellenzeile erfolgt in DB2 entweder sequentiell oder über einen Index. Für den schnellen wahlfreien Zugriff auf eine Tabellenzeile über den Primärschlüssel bei großen Tabellen wäre ein zusatzlicher Hash-gestützter Zugriffspfad für den Hochgeschwindigkeitszugriff wünschenswert. Solche Vorrichtungen sind zum Beispiel in der Datenbank Organisationsform HDAM von DL/1 oder auch beim DB2 Konkurrenten Supra 1 von der Firma Cincom vorhanden. Dieser Zusatz kann natürlich entfallen, wenn bei zukünftigen Computersystemen aufgrund des wesentlich größeren Zentralspeichers die Indexe nicht mehr auf Platte, sondern im Zentralspeicher gehalten werden können.

Weitere Verbesserungen in DB2 sind auch noch auf dem Gebiet der Erhaltung der Beziehungsintegrität (referentielle Integrität) möglich. Das Abweisen einer datenbankverändernden Operation durch DB2 ist sowohl beim integritätsgefährdenden Löschen oder Verändern als auch beim Einfügen implementiert. Auch das Null-Setzen von Fremdschlüsseln durch DB2, um die Beziehungsintegrität aufrecht zu erhalten, kann beim Verändern und Löschen vorgegeben werden. Implementiert ist auch das sich fortsetzende Löschen von abhängigen Zeilen, wenn die Zeile gelöscht wird, von der die anderen existentiell abhängen.

Das automatische Einfügen einer erforderlichen Rumpfzeile durch das Datenbanksystem bei der lediglich der Primärschlüssel bekannt ist, die restlichen Nichtschlüsseldaten jedoch zunächst unbekannt bleiben oder per Annahme vom System vorgegeben werden, ist in DB2 im Gegensatz zu Supra 1 nicht implementiert. Ein solches Einfügen einer Rumpfzeile, von der die einzufügende Zeile existentiell abhängt, wäre eine wünschenswerte Einrichtung in DB2, weil sich so die Beziehungsintegrität bei Einfügungsproblemen leichter realisieren ließe. Dabei könnte zum Beispiel das automatische Einfügen einer noch nicht vorhandenen Kundenzeile in die Kundentabelle zu einem Zeitpunkt, wo die erste Rechnungszeile an diesen Kunden gerade erfaßt wird, ausgesprochen nützlich sein .

Der Ausgangspunkt zur Erarbeitung eines Datenbankmodells sollte nach dem heutigen Stand der Kenntnis ein Entity-Relationship-Modell (ERM) sein, in dem die Entitäten und Beziehungstypen sowie die Komplexitätsgrade der Beziehungen ausgewiesen sind. Diese drei wesentlichen Informationen sind in einem Entitäten-Beziehungsdiagramm übersichtlich darzustellen, damit sie leicht verständlich sind. Nach Einbeziehung der Attribute kann hieraus automatisch ein relationales

Datenbankmodell abgeleitet werden, das als struktureller Überbau für eine zu implementierende DB2-Datenbank dient.

Der früher übliche und oft mühsame Weg zur Erarbeitung eines relationalen Datenbankmodells über die drei Normalisierungsschritte - der Weg vom Chaos zur "organischen Einfachheit"-verliert mit dem Einsatz eines Entitäten-Beziehungsmodells seinen Schrecken. Er dient nur noch als Methode der Qualitätssicherung der aus den Entitäten- und gegebenenfalls aus den Beziehungstypen sich ergebende Relationen. Diese befinden sich hierbei sehr oft bereits in der dritten Normalform. Um diesen erforderlichen Zustand abzusichern, sind jedoch auf jede sich ergebende Relation die drei Normalisierungsüberlegungen anzuwenden.

Die Methode des Entitäten-Beziehungsmodells ist heute weder in ihrem Umfang noch in ihrer Ergebnisdarstellung einheitlich. Zusätzlich zu den ursprünglichen Uberlegungen von Peter Chen ist für uns die Berücksichtigung aller möglichen Entitäten einer Entitätenmenge als Grundlage bei der Definition eines Beziehungsgrades wichtig, und nicht nur die Berücksichtigung solcher Entitäten, die gerade aktuell sind. Unter einem Beziehungsgrad verstehen wir die Anzahl (Kardinalität) an Beziehungsausprägungen einer bestimmten Art, die von einer betrachtenden Entität prinzipiell ausgehen könne.

Mit der Einbeziehung auch der nicht unmittelbar von einer Beziehungsausprägung betroffenen Entitäten in die Uberlegungen gelangt man zu einer einfacheren Betrachtung des Gesamtgeschehens. Hierbei ist es besonders wichtig zu erkennen, ob eine Entität eine oder mehrere Beziehungen einer bestimmten Art eingehen muß oder diese lediglich eingehen kann. So zeichnen sich die Mußbeziehungen dadurch aus, daß die minimale Anzahl an ausgeprägten Beziehungen einer bestimmten Art größer als Null - üblicherweise Eins - ist. Die Gruppe der Kann-Beziehung wird dadurch charakterisiert daß die minimale Ausprägung der Beziehungen die Anzahl Null hat.

IBM unterstützt die Definitionen nach Chen

Von der IBM wird derzeit die ursprüngliche Definition von Chen bei der Angabe der Beziehungsgrade favorisiert, der die zweiseitig gerichteten Beziehungsgrade 1:1, 1:M, M:1 und M:M unterschieden hat und hierbei nur die Entitäten betrachtet, die aktuell Beziehungen einer bestimmten Art eingegangen sind, nicht auch die restlichen Entitäten. Dies fallt vornehmlich in den Handbüchern und in den Schulungsunterlagen über das Repository auf, das in einer sehr großen DB2-Datenbank implementiert ist.

Mit dieser Definition der Beziehungsgrade ist jedoch der Muß-Fall für das Eingehen von Beziehungen nicht abgedeckt, wobei dieser möglicherweise dem uneingeweihten Betrachter aufgrund des Vorkommens der Anzahl 1 suggeriert wird. Das kann zu Mißinterpretationen des ERMs führen. Um auch das zentral wichtige Muß in den Entitäten-Beziehungsmodellen sinnvoll ausdrücken zu können, wird die Muß-Eigenschaft von Beziehungen durch zwei zusätzliche Aussagen (M für mandatory, das heißt zwingend, und c für controlling) in die Formulierung einer ERMs eingebracht, was die Übersichtlichkeit und leichte Verständlichkeit nicht fördert und gewöhnungsbesdürftig ist.

Eine präzise und unmißverständliche Angabe der Beziehungsgrade und damit der wesentlichen Eigenschaft von Beziehungen sehen wir heute in der Minimal- und Maximalschreibweise (min:max). Darin ist nicht nur die Anzahlmäßigkeit von Beziehungen, sondern gleichzeitig auch die Muß- und Kann-Aussage beinhaltet.

Neueres Prinzip der (min:max) - Angabe

Der Muß-Fall wird hierbei dureh zwei (min:max)-Angaben abgedeckt. Die Angabe (1:1) bedeutet: Jede Entität der betrachteten Entitätsmenge muß minimal eine und maximal eine, also genau eine Beziehung der vorliegenden Art eingehen. Und (1:M) bedeutet: Jede Entität der betrachteten Entitätsmenge muß minimal eine und darf maximal beliebig viele Beziehungen der betrachteten Art eingehen.

Auch der Kann-Fall wird durch zwei (min:max)-Angaben beschrieben. Die Angabe (0:1) bedeutet analog: Jede Entität der betrachteten Entitätsmenge kann minimal null und

maximal eine, also höchstens eine, Beziehung der vorliegenden Art eingehen. Und (0:M) bedeutet: Jede Entität der betrachteten Entitätsmenge kann minmal null und maximal beliebig viele Beziehungen der betrachteten Art eingehen.

Werden die somit möglichen Beziehungsgrade zwischen zwei Entitätsmengen, zum Beispiel den Mengen A und B, in einer Tabelle gegenübergestellt, so ist die Eingeschränktheit der Ausdrucksmöglichkeiten bei der Schreibweise der im DB2-Umfeld derzeit verwendeten Notationsformen für Beziehungsgrade erkennbar.

Die in unserer Tabelle (siehe Abbildung) mit IBM bezeichneten - Kombinations-möglichkeiten von Beziehungsgraden decken die von Chen und der IBM verwendeten Anzahlangaben (1:1), (1:M), (M:1) und (M:M) ab. Die restlichen Kombinationsmöglichkeiten müssen durch zusätzliche Angaben definiert werden, um zur selben Aussage zu gelangen, die bei Verwendung der (min:max)-Notationsform automatisch gegeben ist. Daß die einfache und mächtige (min:max)-Notationsform empfehlenswert ist, wurde auch von James Martin.

*Professor Alfred Moos ist Leiter des AD/Cycle-Studienprojektes an der Fachhochschule Heidelberg, das von Dipl.-Informatiker Karl Friedrich Rauland und Dipl.-Informatikerin Barbara Schneider hauptamtlich bearbeitet wird.