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.

11.05.1979

Datenbanken - Änderung der Darstellungsmerkmale ohne Anpassung des Datenbestandes möglich:Durch Anarchie in die Unabhängigkeit

Aus seiner Kritik an den bestehenden Datenmodellen (veröffentlicht in CW- Nr.15, 17 und 18: "Heilige Kühe irren vor sich hin") leitet Ladislav Motl einen Diskussionsvorschlag" zur Verbesserung der Datenunabhängigkeit bei formatierten Datenbanksystemen" ab. Mit der Motl- Lösung wird dem Benutzer eines Datenbankverwaltungssystems (DBVS) zunächst "Format- Anarchie" angeboten: "Das DBVS muß . . . jeden Wunsch bezüglich der dynamischen Veränderung der Darstellungsmerkmale befriedigen können."

In der Praxis kommt es aus den unterschiedlichsten Gründen sehr häufig vor, daß bei einem bereits produktiv eingesetzten Programmkomplex die Darstellungsmerkmale einer Datenmenge geändert werden müssen. Am häufigsten werden Länge und Anzahl der Kommastellen geändert, weniger oft der Darstellungscharakter (numerisch, nichtnumerisch, Gleitpunkt, dezimal, binär).

In der Regel müssen dann alle Programme, die dieses Feld ansprechen, in den Ein-/Ausgabebereichen an die veränderten Feldlängen angepaßt werden und die Daten selbst in den Dateien restrukturiert werden. Dies kann aber bei mehreren Programmen, die gleiche Daten ansprechen, nur zu einem fest definierten Zeitpunkt geschehen, weil es

sonst zu Datenverlust oder Datenverstümmelung sowohl bei der Änderung als auch bei der Wiedergewinnung kommen kann. Es wird die Strategie des kleinsten Widerstandes und der größten Sicherheit gewählt. Alle betreffenden Programme und Dateien werden mit Testnamen versehen, verdoppelt und so lange getestet, bis die Integrität der neuen Programme und Daten gewährleistet ist. Die Empfindlichkeit der Programme gegenüber solchen Veränderungen ist sehr groß, weil der Schwierigkeitsgrad einer Bereichsänderung immer unterschätzt wird. Man neigt dazu, zu sagen, "das mach' ich mit der linken Hand", weil dies keiner "schöpferischen", sondern einer leicht stereotypen Tätigkeit gleicht, die unproblematisch durchgeführt werden kann. Die Wahrscheinlichkeit, daß in irgendeinem Modul ein Bereich vergessen wird, ist sehr hoch. Man muß bedenken, daß nicht nur die E/A- Bereiche, sondern meistens auch Zwischenbereiche und Arbeitsbereiche modifiziert werden müssen und daß ein Modul, das von mehreren Programmen aufgerufen wird, nur dann verändert und neu gebunden werden darf, wenn auch diese Programme (manchmal von "fremden" Programmiergruppen erstellt) an die neuen Feldlängen angepaßt werden.

Diese Probleme werden organisatorisch durch die Führung von Programm- Modul- Verzeichnissen abgedeckt, wobei streng darauf geachtet werden muß, daß jeder Programmierer auch diese Information der Dokumentationsstelle rechtzeitig mitteilt. Nur unverbesserliche Optimisten werden hier aber behaupten können, daß ab einer bestimmten Größe der EDV- Abteilung (mit Tausenden von Programmen) dieses Problem reibungslos in den Griff zu bekommen ist.

In den konventionellen Datenverarbeitungssystemen verursachen die das Formatierungsmerkmal betreffenden Änderungswünsche einen unvertretbar hohen Pflegeaufwand.

Auch in den Datenbanksystemen, die keine dynamische Veränderung der Darstellungsmerkmale erlauben, müssen umfangreiche organisatorische

Maßnahmen zur Programmänderung eingeleitet werden, weil die Verfügbarkeit der Programme und die Datenintegrität gewährleistet bleiben müssen. Leider müssen dann - bei allen dem Verfasser bekannten Datenbanksystemen - auch die Daten in den Datenbanken mit Dienstprogrammen reformatiert werden.

Wie später gezeigt wird, kann man jeden Änderungswunsch bezüglich des Darstellungsmerkmals einer Datenmenge ohne eine Anpassung des Datenbestandes erfüllen.

Eine exakte Datenunabhängigkeit eines

Datenbanksystems ist dann gegeben wenn bei einer Änderung eines oder mehrerer Darstellungsmerkmale

þkeine Dienstprogramme zur Datenformatanpassung ablaufen müssen,

þdie Programmänderungen zeitunabhängig durchgeführt werden können, das heißt zwei Programme können zum gleichen Zeitpunkt eine Datenspalte mit verschiedenen Darstellungsmerkmalen verarbeiten.

Die erste Voraussetzung, dieser Forderung gerecht zu werden, ist die Möglichkeit einer dynamischen Änderung der Darstellungsmerkmale zum Ablaufzeitpunkt.

Die zweite Voraussetzung dafür ist die Möglichkeit der statischen Zuordnung von verschiedenen Darstellungsmerkmalen zu einer Datenspalte zum Zeitpunkt der Formatierung der Dateien mit der DDL.

Die mit diesen Forderungen verbundenen Probleme werden im weiteren näher analysiert:

Die Lösung der dynamischen Veränderbarkeit der Darstellungsmerkmale zum Ablaufzeitpunkt.

Für die Speicherung und Wiedergewinnung von formatierten Daten genügen pro Attributname folgende drei Formatierungsmerkmale:

þLängenmerkmal

þAnzahl Kommastellen

þnumerischer oder nichtnumerischer Darstellungscharakter.

Beim Schreiben der Werte in die Datenbank wird die tatsächlich vorhandene Länge dieses Attributwertes mit abgespeichert. Beim Lesen aus der Datenbank wird entweder das zum Ablaufzeitpunkt gewünschte oder, falls nicht vorhanden, das mit der DDL definierte Längenmerkmal verwendet.

Bei der Abspeicherung der Daten in die Datenbank wird die mit der DDL deklarierte oder zum Ablaufzeitpunkt angegebene Länge nur zur Ermittlung der Distanzen in den Ein-/Ausgabebereichen benutzt. Die Daten werden komprimiert in der implizit vorhandenen Attributwertlänge abgespeichert.

Bei der Wiedergewinnung der Daten ist die Lösung des Problems des Widerspruchs zwischen tatsächlich vorhandener und geforderter Länge in Bild 6 erläutert.

Anzahl Kommastellen

Beim Schreiben der Werte in die Datenbank wird die tatsächlich vorhandene Anzahl Kommastellen mit abgespeichert (Gleitpunktzahl). Dadurch ist es bei der Wiedergewinnung immer möglich, die geforderte Anzahl der Kommastellen zu akzeptieren. Beim Lesen oder Schreiben in die oder aus der Datenbank wird entweder die zum Ablaufzeitpunkt angegebene Anzahl Kommastellen, oder, falls nicht vorhanden, die mit DDL definierte Anzahl Kommastellen verwendet (maximale Anzahl Kommastellen = 15).

Wenn weniger Kommastellen in dem Attributwert vorhanden sind als gefordert, werden sie rechtsbündig mit Nullen erweitert, im umgekehrten Fall rechts abgeschnitten

(Bild 7).

Bei nichtnumerischen Werten ist die Anzahl der Kommastellen nicht relevant und wird nicht berücksichtigt. Es muß auch keine Fehlermeldung ausgegeben werden, falls bei einem nichtnumerischen Attributnamen die Anzahl der Kommastellen angegeben wird.

Darstellungscharakter

Bei formatierten DB- Systemen ist es erforderlich, zwischen numerischen und nichtnumerischen Informationen zu unterscheiden.

Dem Verfasser dieses Berichtes ist die allgemeine Problematik mit "signifikanten Nullen" bekannt, er ist aber der Ansicht, daß es sich hierbei um einen EDV- technischen Aspekt handelt. Die Aussage "Null als Aspektwert JA/NEIN" ist aus semantischer Sicht ein Unsinn.

In den Fällen, wo mit numerischen Werten arithmetische Operationen durchzuführen sind, ist es vorteilhaft, bei nichtsignifikanten Werten in der Datenbank dem Anwender beim Lesen eines Satzes Nullen zu liefern, weil er die zu diesen Attributen notwendigen "Abfragen auf BLANK" in seinem Programm nicht durchführen muß.

Bei identifizierenden Attributwerten, die nur aus numerischen Werten bestehen, wie zum Beispiel Personalnummer oder Kundennummer, ist es durchaus möglich, den Anfang der Nummernfolge bei einem > 0 festzulegen. Außerdem werden oft Nullen zum Zwecke der logischen Aussage JA/NEIN benützt. In diesem Falle soll ein 1- byte langes nichtnumerisches Attribut deklariert werden. Die Nichtexistenz einer Null unter einem numerischen Attribut ist keine "Information".

Nichtnumerische Darstellung

Unter einem als nichtnumerisch deklarierten Attribut können alle Bitkombinationen abgespeichert werden. Bei der Speicherung solcher Werte, deren Länge sich aus dem Eingabebereich nicht ermitteln läßt, ist der Anfang und Ende mit Gänsefüßchen (") gekennzeichnet. Andernfalls ist eine Blank (X'40) ein Trennungskriterium.

Wenn ein Attributwert nur aus Blanks besteht, wird er nicht abgespeichert. Bei der Wiedergewinnung sollen Antwortbereiche der nicht signifikanten Attribute mit Blanks ausgefüllt werden. Nichtnumerische Datenmengen können auch fragmentarischen Abfragen unterzogen werden.

Numerische Darstellung

Unter einem als numerisch deklarierten Attributnamen können nur sedezimale Ziffern in ABCDIC-Code angespeichert werden. Die Zonenteile der Nummer werden geprüft (TM X'FO). Das letzte Byte darf den Zonenteil X'C, A, E'- Positiv oder X'D, B' - Negativ haben.

Bei einem Dialog mit dem System kann eine Nummer die Sonderzeichen "+", " - ", ", " beinhalten.

Zum Beispiel + 133,45 oder - 67,89.

Falls ein numerischer Attributwert nur aus "0" besteht, wird er nicht berücksichtigt.

Wenn in einem Datenbestand für numerisch deklarierte Felder kein Wert vorhanden ist, werden sie mit dezimalen Nullen ausgefüllt. Im Gegenteil zur nichtnumerischen Darstellungsform ist die fragmentarische Suche in einem numerischen Datenbestand nicht gestattet und auch nicht sinnvoll.

Löschzeichen

Unabhängig von der Darstellungsform sollen zum Beispiel binäre (X'00') Nullen als Löschzeichen dienen.

Bei Neuaufnahme eines Attributwertes in die Datenbank wird dieser Wert nicht berücksichtigt.

Beim Updaten eines Satzes wird der alte Attributwert gelöscht.

Speicherung numerisch - nichtnumerisch

Bei der Speicherung der Daten wird nicht wie bei der Wiedergewinnung aus der Information selbst ermittelt, ob es sich um einen numerischen oder nichtnumerischen Wert handelt, sondern es wird immer der bei dem Attributnamen angegebene Darstellungscharakter verwendet (mit der DDL deklariert oder dynamisch beim Attribut angegeben).

Erklärung:

Wenn ein numerischer Wert zur Identifizierung einer Information verwendet wird, muß die Möglichkeit bestehen, diesen numerischen Wert, der aber durch die Identifizierung einen nichtnumerischen Charakter bekommen hat, auf seine Teile abzufragen. Deshalb muß bei solch numerischer Identifikation diesem Attribut ein nichtnumerischer Darstellungscharakter zugeordnet werden. Nur bei tatsächlich numerischen Attributen ist es sinnvoll, einen numerischen Darstellungscharakter dieser Datenspalte zuzuordnen. Alle Attributwerte werden dann auf einen numerischen Inhalt geprüft und bei Auftreten eines Widerspruchs wird eine Fehlermeldung im Quittungsbereich des Benutzers ausgegeben.

Wiedergewinnung numerisch - nichtnumerisch

Für die Wiedergewinnung soll die Deklaration eines Darstellungscharakters ohne Bedeutung sein. Es wird der implizit in dem Datenbestand vorhandene

Darstellungscharakter benutzt. Eine als numerisch abgespeicherte Information wird auch numerisch (rechtsbündig), eine nichtnumerische (linksbündig) in den Eingabebereich abgeliefert.

Eine Ausnahmesituation, bei der der explizit angegebene Darstellungscharakter bei der Wiedergewinnung benutzt wird, entsteht dann, wenn nichtsignifikante Werte zur Verfügung gestellt werden sollen.

In diesem Falle werden:

- bei nichtnumerisch deklarierten Attributen Blanks,

- bei numerisch deklarierten Attributen Nullen in den Eingabebereich des Benutzers abgeliefert.

Für ein Datenbanksystem darf es aber kein Hindernis sein, in der gleichen Datenspalte numerische und nichtnumerische Werte zu speichern.

Der Aufwand für die Verwaltung der Daten und für die Änderung von Programmen wird dadurch reduziert, daß die zu allen Feldern vorhandenen Attribute vom DBVS

"wertunabhängig" verwaltet werden.

Die Darstellungsmerkmale können sowohl zum Zeitpunkt der Datenverwaltung mit der DML als auch zum Zeitpunkt der Verwaltung der Attribute mit der DDL vom DBVS interpretiert werden. In der Organisationsdatei des Systems befinden sich aber nur die mit der DDL deklarierten Attribute. Sie können mit der DML (write, rewrite, read) nur temporär im Arbeitsspeicher verändert werden. Eine Veränderung der Attribute in der Organisationsdatei ist aber zu jedem beliebigen Zeitpunkt mit der DDL möglich, weiI nicht die explizit angegebenen, sondern die direkt bei einem Wert in der DB vorhandenen Darstellungsmerkmale für das DBVS maßgebend sind.

Um den Grad der Datenformatunabhängigkeit zu maximieren, wird dem Benutzer vom DBVS zunächst eine "Format- Anarchie" angeboten. Durch die Anwendung von Schutzmechanismen auf der Feldebene kann er dann diese "Anarchie" mäßigen. Das DBVS muß aber jeden Wunsch bezüglich der dynamischen Veränderung der Darstellungsmerkmale befriedigen können.

Wird fortgesetzt