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.