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.

27.04.1979 - 

Heilige Kühe irren vor sich hin

Eine Kritik der Datenmodelle mit einem Diskussionsvorschlag zur Verbesserung der Datenunabhängigkeit bei formatierten Datenbanksystemen\. Teil II

Man unterscheidet zwischen der

a) Datenstrukturunabhängigkeit und

b) Datenformatunabhängigkeit (Bild 1)

Die Datenstrukturunabhängigkeit

Zum sicheren plazieren und Wiederauffinden einer Information in einem

formatierten DBS muß der "Eingangsmechanismus"

ENTITY-Name... ATTRIBUT-Name... ATTRIBUT-WERT

eingehalten werden (Wedekind - Datenbanksystem I).

Die Begriffe wie Dateiname, Satzart, Segment, Feldgruppe, multiples Feld,

SET-Name, Subschema-Name, Relationenname beweisen die Notwendigkeit,

eine bestimmte Forderung an die Daten oder den Zweck, für den sie verarbeitet werden sollen, von anderen zu trennen und eindeutig zuzuordnen. Es genügt nicht, nur zu wissen, WAS ein Wert darstellt, sondern auch WARUM oder WO ein Item (Attributname mit

Attributwert) sich befindet (Bild 2).

Der Wert 47 11 kann beispielsweise sowohl die Kontonummer eines beliebigen Kunden darstellen, als auch die Kontonummer eines Mitarbeiters, als auch das Gehalt dieses Mitarbeiters. Welche dieser drei Möglichkeiten jeweils die richtige ist, wird durch den "Zweck" bestimmt (beispielsweise Kundenbuchhaltung oder Gehaltsabrechnung), der somit den ENTITY definiert.

Für das Verfahren "automatisierter Datenaustausch", mit dem alle Überweisungen in Form von Magnetbändern an die Bank gesandt werden, sind aber die Konten 4711 sowohl des Kunden als auch des Mitarbeiters gleichrangig, wobei hier die Kontonummer zusammen

mit der Bankleitzahl für die Eindeutigkeit der Überweisung notwendig ist. Die Informationen "Personalnummer" oder "Kundennummer" sind für den Datenaustausch nicht relevant.

Vielmehr müssen aus der Personal- und Kundendatei die Namen der Personen der Bank mitgeteilt werden, damit sie die Richtigkeit der Überweisung prüfen kann.

Der Begriff ENTITY ist eine abstrakte Bezeichnung für die Eindeutigkeit einer

Information, die aufgrund bestimmter Anforderungen stets bestimmten Zwecken zugeordnet sind, (siehe auch Wedekind, Datenbanksysteme I, Seite 19, 25, 134).

Die Feststellung der ENTITIES und die Festlegung des logischen Zugriffspfades gehört zu den schwierigsten und wichtigsten Tätigkeiten eines Organisators. Daß manche DB-Projekte an der ENTITY-Analyse scheitern, ist sicherlich richtig.

Es wäre aber töricht zu glauben, daß. man einen hundertprozentig richtigen und vollständigen Datenstrukturentwurf immer vor dem Anfangen der Implementierungsphase definieren kann. Auch wenn es gelingen wurde, muß man damit rechnen, daß das Zeitverhalten des DBS erst am Ende der Testphase, wenn alle Programme laufen und Produktivdaten in der DB vorhanden sind, gemessen werden kann. Es kann dann vorkommen, daß alle die vorher wohldurchdachten Datenstrukturen umstrukturiert und die Programmen entsprechend modifiziert werden müssen.

Ein ENTITY kann entweder durch das Zusammenführen aller Schlüsselattribute zu einem Schlüsselkandidat (Ordnungsbegriff, der aus einem oder mehreren Feldern besteht) oder aus der logischen Beziehung (ENTITY-SET-Name) zwischen den Daten ohne Kenntnis der Schlüssel festgelegt werden (Bild 3a, 3b). An dieser Stelle ist das Schlagwort "Religionskrieg zwischen den Hierarchisten und Relationisten" zu erwähnen, das manchmal falsch verstanden wird. Den Unterschied zwischen der hierarchischen Datenorganisation mittels eines SET-Namens in einem SUBSCHEMA und dem Codd'schen Normalisierungsprozeß muß man zunächst losgelöst von einem DBVS aus der logischen Sicht des Anwenders an die Daten betrachten (Bild 4). Die Festlegung der ENTITIES darf auf der Stufe III, der Eigenschaften der zweiten Stufe (DBS/DBVS), nicht gestört werden. Ein Relationen-Datenbanksystem setzt zuerst den Normalisierungsprozeß auf der dritten Stufe voraus, ein ENTITY-SET-Name-Konzept (CODASY-Vorschlag) nicht. Die technische Voraussetzung für eine Relationen-Datenbank, wie Vollinvertierung der Attributwerte in Sekundärdateien und die Fähigkeit des Systems, die Relationen-Operation RESTRIKTION, JOIN, PROJEKTION durchzufahren haben mit dem Problem des Datenstrukturentwurfes zunächst nichts gemeinsames.

Weil an die Daten und deren Verknüpfungs- und Auswertungsmöglichkeiten verschiedene Anforderungen gestellt werden (Bild 5), ist es fast unmöglich, zu einem bestimmten Zeitpunkt alle ENTITIES in einem Datenstrukturentwurf richtig und endgültig festzulegen. Auch wenn ein hervorragendes Verhältnis zwischen dem Auftraggeber (der Fachabteilung) und der EDV-Abteilung existiert, bleibt das Problem bestehen, weil die Tatsachen, die in der Fachabteilung als "nicht erwähnenswert" dem Datenorganisator vorenthalten bleiben, für den Datenstrukturentwurf von entscheidender Bedeutung sein können. Mit zu nehmender Anzahl von Mißverständnissen und Ignoranz wird es dann schwieriger, alle funktionalen Abhängigkeiten zwischen Daten zu erkennen und den Datenstrukturentwurf durchzufahren. Auch wenn man eine gewissenhafte Durchführung der ENTITY-Festlegung unterstellt, muß damit gerechnet werden, daß zu einem späteren Zeitpunkt, aus welchen Gründen auch immer, eine Restrukturierung der Daten notwendig wird.

Bei Datenbanksystemen, bei denen das Kriterium der Datenstrukturunabhängigkeit nicht beachtet wird, verursachen solche Änderungen einen umfangreichen und sehr schwer vertretbaren Aufwand, weil in der Regel auch die nicht-betroffenen Daten und Programme an die neue Struktur angepaßt werden müssen.