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.

24.04.1987 - 

Entwurf von Datenbanken im Unternehmen (Teil 2):

Logisches DB-Schema braucht Langfrist-Geltung

In der betrieblichen Datenverarbeitung ist die Datenbank als umfassender Informationspool ein zentrales Medium der Integration. Um einen verläßlichen Ausgangspunkt für Softwareprojekte zu bieten, muß ihr Aufbau auf lange Sicht stabil bleiben. Der logische DB-Entwurf ist deshalb in der Rahmenplanung anzusiedeln und sollte alle von der DV zu unterstützenden Funktionen berücksichtigen.

Die Realität eines Unternehmens ist komplex und kann nur in Etappen erfaßt und rekonstruiert werden. Man geht am besten nach Funktionsbereichen vor. Eine Person, der Datenadministrator, sollte für das gesamte Modell verantwortlich sein und den Entwurf zusammen mit Fachleuten der einzelnen Bereiche durchführen. Es empfiehlt sich, mit einem bedeutenden Bereich zu beginnen und die übrigen sukzessive einzugliedern, bis ein Modell des gesamten Unternehmens vorhanden ist.

Beim Datendesign geht es darum, den relevanten Ausschnitt der Wirklichkeit mit den Mitteln der verwendeten semantischen Methode zu beschreiben, das heißt geeignete Objekttypen zu finden und die Beziehungsarten zwischen ihnen zu bestimmen. Die Konstrukteure müssen dazu wissen, welcher Teil der Wirklichkeit relevant ist und diese Wirklichkeit begreifen. Weil mit der Einführung der DV oder auch nur eines neuen Verfahrens häufig auch organisatorische Änderungen verbunden sind, müssen die Konstrukteure gegebenenfalls einen Ist- und einen Soll-Zustand rekonstruieren.

Es gibt verschiedene Möglichkeiten, die relevante Wirklichkeit zu erfassen. Ein Fachmann, der den gesamten darzustellenden Bereich "im Kopf hat", könnte das Modell auch ohne Umwege konstruieren. Normalerweise ist es jedoch besser, wenn die Konstrukteure sich anfangs explizit über die Funktionen Klarheit verschaffen, die von der DV wahrzunehmen sind. Dies kann durch eine Aufgabenanalyse und/oder eine verbale Beschreibung der Funktionen geschehen. Aufwendig, aber sicher dem Gesamtergebnis dienlich, ist die Beschreibung mit Hilfe einer zweiten Modellsprache aus einem anderen Blickwinkel.

Funktionen sind nicht mit Modulen gleichzusetzen. Die Hauptmodule eines Programmsystems üben zwar bestimmte Funktionen aus, es gibt jedoch gewöhnlich verschiedene Möglichkeiten, die einzelnen Funktionen den Modulen zuzuordnen. Im Stadium des logischen Datenbankentwurfs braucht man noch kein detailliertes Wissen über die Module eines Aufgabenbereichs. Lediglich die Gruppierung der Aufgaben zu Aufgabenbereichen, die dann jeweils in einem Projekt realisiert werden, sollte schon bekannt sein.

Als fachliches oder konzeptuelles Schema soll das in Objekt- und Beziehungstypen ausgedrückte Modell bezeichnet werden, das noch nicht auf eine bestimmte Datenbankart zugeschnitten ist. Aus diesem Schema wird dann später das auf eine relationale oder Netzwerkdatenbank zugeschnittene logische Schema abgeleitet (siehe Abbildung 4).

Der Entwurf des fachlichen Schemas sollte ebenfalls in mehreren Schritten erfolgen:

Festlegen der Objekttypen und ihrer Identifikationsschlüssel

Ein Objekttyp ist eine Klasse von Objekten. Zum Objekttyp "Kunde" sind die Datensätze aller Objekte dieses Typs zu zählen, also beispielsweise die der Kunden Meier und Müller.

Die Objekttypen werden direkt aus der betrieblichen Realität abgeleitet. Im Einkauf hat man es mit Typen wie "Lieferant", "Teil", "Bestellung", "Angebot" zu tun; in der Fertigung ebenfalls mit dem Typ "Teil", darüber hinaus aber noch mit vielen anderen wie "Arbeitsplatz", "Arbeitsplan" oder "Werkzeug".

Für jeden Typ benötigt man einen Identifikationsschlüssel - ein Merkmal oder eine Merkmalskombination zur Identifikation und Unterscheidung der Objekte eines Typs. Für einen Typ kann es mehrere Möglichkeiten (Schlüsselkandidaten) geben. Sind sie alle unpraktikabel, so behilft man sich mit einem "künstlichen Schlüssel, meist einer Nummer. Beispielsweise wird für den Typ "Mitarbeiter" eine Personalnummer anstelle der Kombination Name, Vorname, Geburtsdatum verwendet.

Wenn sich die Objekte eines Typs mit den Objekten eines anderen Typs überschneiden, gibt es Redundanz. Ein Beispiel: die Objekttypen "Kunde und "Lieferant". Falls die Überschneidungen zahlreich und die relevanten Attribute dieselben sind, kann daraus ein einziger Typ "Geschäftspartner" gebildet werden.

Bestimmung der Beziehungstypen

Beziehungen müssen qualitativ und quantitativ erfaßt werden. Es können auch mehrere Beziehungsarten zwischen denselben Objekttypen bestehen. Beispielsweise kann es zwischen "Einkäufer" und "Produktgruppe" die Beziehungsarten "Zuständigkeit" und "Stellvertretung" geben.

In quantitativer Hinsicht unterscheidet man gewöhnlich 1:1-, 1:m- und m:n-Beziehungen, je nachdem, wie viele Objekte eines Typs einem Objekt eines anderen Typs zugeordnet werden können und umgekehrt.

Die Beziehungsart "Zuständigkeit" könnte eine 1:m-Beziehung sein: Ein Einkäufer ist für mehrere Produktgruppen zuständig, eine Produktgruppe liegt in der Zuständigkeit genau eines Einkäufers.

Was ein Objekt- und was ein Beziehungstyp ist, wird in der Theorie nicht klar definiert. Bei den heute gebräuchlichen relationalen und Netzwerkdatenbanken ist dies auch nicht nötig. Die im fachlichen Schema getroffenen Unterschiede verschwinden völlig (Relationenmodell) oder teilweise (Netzwerkmodell).

Der Konstrukteur hat hier also Wahlmöglichkeiten. Durch die anfängliche Bestimmung von Objekttypen sind allerdings schon Vorentscheidungen getroffen. Bei m:n-Beziehungen hat man gewöhnlich die Wahl, ob man sie als solche belassen soll, oder ob man sie durch Einführen zusätzlicher Objekttypen in 1:m-Beziehungen zerlegen soll. Zusammenstellung der Nicht-Schlüssel-Attribute

Auch eine Beziehung kann, wie ein Objekt, Merkmale aufweisen. Beispielsweise kann die Beziehung "Ehe" zwischen den Objekttypen "Mann" und "Frau" Merkmale wie Heiratsdatum und -ort besitzen.

In der Rahmenplanung wird es nicht möglich sein, bereits alle Attribute für jeden Objekt- und Beziehungstyp festzulegen. Gewöhnlich ergeben sich in den Projekten später noch Erweiterungen. Es sollte aber von vornherein Vollständigkeit angestrebt werden, damit alle Attribute, die mehrere Bereiche betreffen (Schnittstellenattribute), berücksichtigt werden. Auch Datenformate und Wertebereiche müssen schon in der Rahmenplanung festgelegt werden.

Welche Attribute sich einem Objekttyp zuordnen lassen, ist für die formal-analytische Designmethode mit Hilfe der Begriffe der funktionalen Abhängigkeit und der Normalformen geklärt worden. Da das Ziel des Designs bei beiden Methoden dasselbe ist, nämlich ein weitgehend redundanzfreies Schema, kann das bei der analytischen Methode verwendete Gütekriterium der dritten Normalform auch beim semantisch-konstruktiven Entwurf Hilfestellung leisten.

Im Sinne des semantisch-konstruktiven Vorgehens gilt folgende Formulierung:

- In einen Objekttyp sollen nur Merkmale aufgenommen werden, die Eigenschaften der durch den Identifikationsschlüssel bestimmten Objekte darstellen, und zwar der ganzen Objekte. Dies gilt ebenso für Beziehungstypen.

- Gegliederte Merkmale (zum Beispiel "Adresse") und Wiederholungsmerkmale ("Kind") sind nicht zugelassen,

- Objekte sind "leere" Objekte in dem Sinne, daß sie keine aus mehreren Merkmalen bestehenden Unterobjekte enthalten dürfen. Ein Beispiel: Im Objekttyp "Abteilung" sollen nicht die Merkmale der Abteilungsmitarbeiter wie Alter und Verdienst gespeichert werden.

Befinden sich gegliederte Merkmale in einem Objekttyp, so löst man sie gewöhnlich in ihre Komponenten auf. Das Merkmal Adresse wird zu Straße, Postleitzahl, Ort. Wiederholungsmerkmale können durch Aufspaltung in mehrere verschieden benannte Merkmale beseitigt werden. "Kind" wird dann zu "Kind 1 ", "Kind 2", . . . Eine andere Möglichkeit ist, einen eigenen Objekttyp für das Wiederholungsmerkmal zu schaffen und eine Beziehung zwischen den beiden Objekttypen zu definieren.

Ebenso verfährt man auch im Fall des "Objekts im Objekt". Die Merkmale der Abteilungsmitarbeiter lassen sich aus dem Typ "Abteilung" auslagern, indem ein Typ "Mitarbeiter" geschaffen wird.

Es zeigt sich, daß die kritische Betrachtung der Attribute zu Änderungen in der Liste der Objekttypen führen kann. Datenbankentwurf ist ein iterativer Vorgang.

Die Komplexität, die das Unternehmensmodell auszeichnet, ist leichter zu bewältigen, wenn man mit dem Entwurf eines Funktionsbereichs beginnt und die übrigen schrittweise einbindet. Damit die Bereichsentwürfe nicht allzusehr auseinanderlaufen, sollte jedes Entwurfsteam unter der Leitung oder Beratung des Datenadministrators arbeiten.

Die wichtigsten Tätigkeiten bei der Eingliederung eines Bereichs sind:

- Identifizierung gemeinsam benutzter Objekttypen und Finden geeigneter Namen;

- Zusammenfassen in einzelnen Bereichen benötigter Attribute;

- Abstimmen der Datenformate und Wertebereiche gemeinsam benutzter Attribute.

Sieht man von den antiquierten hierarchischen Systemen ab, so gibt es heute zwei viel benutzte Arten von Datenbanksystemen: relationale und Netzwerkdatenbanken. Sie unterscheiden sich durch die Modelle voneinander, in die die relevante Realität zu ihrer Speicherung gepreßt wird. Da keines der beiden dem Objekt-Beziehungs-Modell ganz entspricht, muß der fachliche Entwurf nochmals umgesetzt werden.

Weshalb soll man den Umweg über ein fachliches datenbankunabhängiges Schema mit eigener Beschreibungssprache gehen, wenn das Konstruierte dann wieder in ein anderes, datenbankspezifisches Modell umgewandelt werden muß?

Ein guter Grund ist, daß dieses fachliche Schema datenbankunabhängig ist. Die Konstrukteure benötigen nur die Kenntnis der recht einfachen Beschreibungssprache (Objekttypen, Beziehungstypen, Merkmale, Schlüssel) und können sich von DV-technischen Einzelheiten freihalten. Auch läßt sich dieser fachliche Entwurf konstruieren, selbst wenn noch keine Entscheidung für einen bestimmten Datenbanktyp gefallen ist.

Der Umweg ist vertretbar, weil die Umsetzung des fachlichen in das logische Schema keine aufwendige Prozedur ist. Sie geschieht nach wenigen formalen Regeln; die Mitarbeit der Fachabteilung ist dazu nicht mehr erforderlich. Abbildung 5 ist eine grobe Darstellung dieser Umsetzungsregeln.

Umsetzung in das Relationenmodell

Die Umsetzung wird anhand einer Mini-Datenbank (siehe Abbildung 6) erläutert. Sie enthält zwei Objekttypen, "Teilegruppe" und "Teil", und zwei Beziehungstypen. Die erste davon, eine m:1 -Beziehung, hält die Zugehörigkeit von Teilen zu einer Teilegruppe fest. Die zweite ist eine m:n-Beziehung, die angibt, aus welchen Unterteilen ein Teil zusammengesetzt ist beziehungsweise in welche Oberteile ein Teil eingeht (Stücklisten- oder Teileverwendungsinformation). Diese Beziehung hat auch ein Attribut, nämlich die Menge eines Unterteils, die für ein Oberteil benötigt wird.

Regel 1:

Jeder Objekttyp wird in eine Relation verwandelt. Dadurch ergeben sich die Relationen "Teilegruppe" und "Teil".

Regel 2:

Zur Realisierung von 1:m-Beziehungen nimmt man den Schlüssel der 1-Seite in die Relation der m-Seite auf. Das Attribut Teilegr # wird Bestandteil der Relation "Teil".

Regel 3:

Für m:n-Beziehungen und alle Beziehungen mit Attributen werden eigene Relationen gebildet. Der Schlüssel einer solchen Beziehungsrelation ist eine Kombination aus den Schlüsseln der beteiligten Relationen. Da es sich im Beispiel um eine rekursive Beziehung handelt, an der nur der Objekttyp "Teil" beteiligt ist, geht dessen Schlüssel zweimal ein: als Oberteil # und als Unterteil #.

Man beachte folgende Variante: Anstelle der m:n-Beziehung wird ein Objekttyp "Teilestruktur" gebildet, der mit "Teil" über zwei 1:m-Beziehungen (Oberteilzuordnung und Unterteilzuordnung) verbunden ist. Bei einem Verfahren nach der obengenannten Umsetzungsregel für 1:m-Beziehungen ergeben sich keinerlei Veränderungen im Relationenschema. Der Unterschied zwischen den Objekt- und den Beziehungstypen des fachlichen Entwurfs wird im Relationenmodell nicht ausgedruckt.

Umsetzung in das Netzwerkmodell

Im Netzwerkmodell wird die Realität durch Satzarten und Sets abgebildet. Sets drücken Beziehungen zwischen Satzarten aus. DV-technisch werden sie durch Zeiger und Zeigerketten zwischen Sätzen verwirklicht. Sowohl Satzarten als auch Sets können Datenfelder enthalten.

Der Entwurf einer Netzwerkdatenbank läßt sich gut mit Hilfe eines "Bachmann-Diagramms" veranschaulichen. Es ist mit dem Objekt-Beziehungs-Diagramm verwandt: Satzarten sind durch Kästchen, Sets durch Pfeile gekennzeichnet (siehe Abbildung 7).

Regel 1:

Objekttypen werden zu Satzarten. (Jeder Satz entspricht einem Objekt.)

Regel 2:

Eine 1:m-Beziehung wird durch einen Set verwirklicht. Die Zeiger weisen von den Sätzen der 1-Seite zu den zugehörigen Sätzen der m-Seite. Im Bild ist dies durch Pfeile dargestellt.

Regel 3:

m:n-Beziehungen können nicht direkt verwirklicht werden. Man führt eine Verbindungssatzart ein und zerlegt damit die Beziehung in zwei 1:m-Beziehungen. Die restliche Umsetzung geschieht nach Regel 2. Im Beispiel wird die Verbindungssatzart "Teilestruktur" eingeführt.

Man kann den ersten Teil der Umsetzung nach Regel 3 auf den fachlichen Entwurf verlagern, indem man jede m:n-Beziehung durch Definition zusätzlicher Objekttypen in 1:m-Beziehungen zerlegt.

Die wichtigste Person beim Entwurf ist der Datenadministrator. Die Unternehmen neigen dazu, diese Position zu DV-technisch zu sehen. Wissen und Kreativität sind besonders während des fachlichen Entwurfs gefordert. DV-technische Kriterien können durch konstruktive Beschränkungen wie die der dritten Normalform beziehungsweise Boyce-Codd-Normalform hinreichend berücksichtigt werden.

In größeren Unternehmen kann die Arbeit der Datenadministration auch vorteilhaft einem Team übertragen werden. Einem mehr fachlich ausgerichteten "Unternehmensadministrator" kann ein "Datenbankadministrator" zur Seite gestellt werden, der als Fachmann für internes Schema und Datenkommunikation auch die Programmierer berät. Das Zusammenwachsen von betriebswirtschaftlicher und technischer Datenverarbeitung im Rahmen von CIM wird die Arbeit der Datenadministration noch um vieles schwieriger machen. Einzelne Personen haben nur selten das betriebswirtschaftliche und technische Wissen, das für die Betreuung einer Datenbank für beide Bereiche notwendig ist.

Auch ein Unternehmensadministrator wird selten so vielseitig sein, daß er das Modell ohne die Mithilfe der Fachabteilungen entwerfen könnte. Er benötigt aus jedem Funktionsbereich Partner mit analytischem Denkvermögen, die die Realität in allen wichtigen Details erfassen und wiedergeben können.

Literaturverzeichnis

Chen, P. P., The Entity-Relationship Model

- Toward a Unified View of Data. ACM TODS, Vol. 1, 1976, S. 9-36

Codd, E. F., A relational model for large shared data banks. CACM 13, 1970, S. 377-387

Date, C. J., An Introduction to Database Systems, 4. Aufl., Addison-Wesley Publishing Company, Reading (Mass.) u. a. 1986

Fischer, A., Wo greifen grafisch orientierte Verfahren? Erfahrungen mit SADT und DSA, in: Morgenbrod, H., u. Remmele, W. (Hrsg.), Entwurf großer Software-Systeme, Stuttgart 1985

Ortner, E., Semantische Modellierung - Datenbankentwurf auf der Ebene der Benutzer, Informatik-Spektrum (1985) 8: 20-28

Rauh, Q., Heutige DB-Systeme sind oft durch Benutzerwünsche überfordert, COMPUTERWOCHE v. 18.4. u. 25.4.86

Scheer, A.-W., EDV-orientierte Betriebswirtschaftslehre, Berlin/Heidelberg/New York/Tokyo 1984

Ullman, J. D., Principles of Database Systems, 2. Aufl., Computer Science Press, Rockeville, Maryland, 1982

Wedekind, H., Datenbanksysteme 1, 2., völlig neu bearbeitete Auflage, Mannheim/Wien/Zürich 1981

Zehnder, C. A., Informationssysteme und Datenbanken, 3. Auflage, Stuttgart 1985

In der ersten Folge seiner zweiteiligen Artikelreihe behandelte Otto Rauh den Datenbankentwurf im System der DV-Planung sowie zu diesem Zweck verwendbare Methoden. Thema des zweiten Teils ist die Konstruktion eines Unternehmensmodells.