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.

12.05.1978 - 

Stand der Entwicklung von Datenbanken:

Den "point of no return" möglichst weit nach hinten legen

Die Unzulänglichkeiten in konventionellen Datenverarbeitungssystemen führten in den 60er Jahren zu dem Gedanken, Dateien zu zentralisieren und den Zugriff zu ihnen über ein Datenverwaltungssystem vorzunehmen. Es wurde der Begriff Datenbanksystem als begriffliche Zusammenfassung von Datenbank und Datenverwaltungssystem eingeführt. Eine Datenbank enthält zentral gespeicherte Daten, ein Datenverwaltungssystem alle Prozeduren zu ihrer Handhabung. Das Datenverwaltungssystem ist ein spezielles Betriebssystem, das unter dem allgemeinen Betriebssystem der Anlage läuft.

Folgende Funktionen sollten von diesem "Sonderbetriebssystem" wahrgenommen werden: Auswahl von Zugriffspfaden, Übersetzung der Anweisungen in einer Datenmanipulationssprache, Zugriffsoptimierung, Sperren und Entsperren von Datenobjekten, Behandlung von Verklemmungen, Überwachung der Integritäts- und Autorisierungsbedingungen.

Ein Datenbanksystem hebt sich von einem konventionellen System mit individuellen Dateien durch sechs Entwicklungsziele ab:

Trennung von Datenmanipulationssprache (DML) und Trägersprache (host language).

Eine Datenmanipulationssprache für das Auffinden und für den Änderungsdienst der Daten in einer Datenbank kann in eine universelle Programmiersprache (Trägersprache, host language) eingebaut werden, oder aber sie kann als selbständige Sprache (self-contained language) gehalten sein. Im zweiten Fall spricht man auch von einer Query-Sprache.

Zentrale Integritätskontrolle (system enforced integrity)

Es ist unbestritten, daß in kommerziellen Programmen der konventionellen Art ein enorm hoher Teil der Programmcodes ausschließlich für die Zwecke der Fehlersuche entworfen werden muß. Es werden in den Codes Sortierfolgen geprüft, mit Prüfziffern wird die Gültigkeit einer Nummer festgestellt oder der Inhalt der Felder eines Satzes in einem Plausibilitätstest verglichen, um die Richtigkeit der Wertbeziehungen zu testen. Jackson nennt kommerzielle Programme scherzhaft "data vetting programs" (to vet = tierärztliches Untersuchen, veterinarian = Tierarzt), um darzutun, daß die Komplexität der Programme durch Fehleraufdeckung und Fehlerbehandlung so groß geworden ist, daß ein tiermedizinisches Studium eigentlich vonnöten ist. Die Garantie der Datenqualität oder Datenintegrität bestimmt die Struktur der Programme und nicht das gestellte Problem. Integritätsverletzungen sind einer der Kerne des Softwaredilemmas.

Wie bei anderen Waren hat in Datenbanksystemen nicht der Benutzer oder Verbraucher für die Korrektheit der Daten zu sorgen, sondern das Datenverwaltungssystem beziehungsweise der Produzent. Es gibt drei Möglichkeiten, Integritäts - oder Qualitätsbedingungen in das Datenverwaltungssystem einzubringen:

-Durch Systemproduzenten, die im Bedarfsfalle aufgerufen werden.

Der Codasyl-Vorschlag sieht diese Variante vor.

-Durch ein Datenmodell

Im Codasyl-Vorschlag wird für bestimmte Integritätsbedingungen, die sich auf mehrere Dateien beziehen, ebenfalls dieser Weg beschritten. Das hierarchische Datenkonstrukt "SET" impliziert diese Integritätsbedingung insofern, als eine Ausprägung des Member-Satzes (Kindsatz) immer

einer Ausprägung des Owner-Satzes (Vatersatz) zugeordnet sein muß. "Vaterlose Kinder" bedeuten eine Verletzung der Datenintegrität. Auf die SET-Struktur wird im folgenden noch genauer im Rahmen der hierarchischen Datenmodelle eingegangen werden.

-Durch die Formulierung in einer nicht-prozeduralen Sprache.

In vollständigen relationalen Systemen wird eine Integritätsbedingung

wie eine mathematische Gleichung formuliert und in ein Subsystem eingebracht. Das relationale Datenmodell und die Integritätsbedingungen bleiben im Gegensatz zum hierarchischen Modell strikt voneinander getrennt.

Integrierte Auswertung der Dateien für den Bedarf in einem Informationssystem

Die integrierte Auswertung von Dateien bedeutet, daß eine Datei nicht nur nach dem Primärschlüssel oder einem anderen Sortierbegriff verarbeitet werden kann. Die Verarbeitung im Hinblick auf alle Felder und Feldkombinationen muß über mehrere Dateien hinweg gewährleistet sein. Der Informationsbedarf und nicht die Abspeicherung sollte die Auswertbarkeit bestimmen.

Zeitgerechter Änderungsdienst

Durch die Zentralisierung der Dateien wird eine Einmalspeicherung angestrebt. Wenn die Daten nicht in mehreren Dateien aufgeführt werden, so wird der Änderungsdienst wesentlich erleichtert. Das Verstreuen gleicher Daten über mehrere Dateien hat in konventionellen Systemen häufig zu unlösbaren Aufgaben geführt.

Erweiterung der Benutzerklassen "Programmierer" und Betriebspersonal um die Klassen der parametrischen Benutzer (angelerntes Schalterpersonal) und die Klasse der anspruchsvollen Laien (Ingenieure,

Mediziner, Kaufleute etc.)

In konventionellen Systemen gibt es im wesentlichen nur zwei Benutzerklassen, das System - und Betriebspersonal sowie die Anwendungsprogrammierer. Durch Datenbanksysteme soll

ermöglicht werden, daß anspruchsvolle Laien, die mit der Datenverarbeitung nur wenig Kontakt haben, aber Fachleute auf ihrem Gebiet sind, Anfragen (queries) formulieren und eingeben können. Ferner soll etwa das Schalterpersonal in den Banken, auf den Flughäfen und in Auskunftsbüros mit Information direkt aus der Datenbank zu versorgen sein. Die Feature Analysis der Codasyl-Gruppe nennt diese Benutzer zutreffend "parametric user". Es wird keine Formalisierung in einer Datenmanipulationssprache verlangt, sondern es müssen nur offene Parameter für ansonsten fertige Programme zur Verfügung gestellt werden. Eine Anlernzeit von wenigen Wochen genügt in der Regel, um die Funktionen eines parametrischen Benutzers wahrnehmen zu können.

Gewährleistung eines hohen Maßes an Datenunabhängigkeit

Datenunabhängigkeit ist die Isolierung der Daten von den Programmen. Je höher der Grad an Datenunabhängigkeit ist, desto geringer ist der Aufwand für Programmänderungen im Falle einer Änderung der Daten. Es gibt mehrere Arten von Datenunabhängigkeit.

Besonders hervorzuheben sind die Speicherungsunabhängigkeit (physische Unabhängigkeit) und die Zugriffspfad-Unabhängigkeit (logische Unabhängigkeit). Eine physische Datenunabhängigkeit, die auch schon in konventionellen Systemen gewährleistet wird, bewirkt, daß eine Veränderung der tatsächlichen Abspeicherung auf den Geräten keinen Einfluß auf die Programme hat. Zugriffspfad-Unabhängigkeit, die als eine höhere Form der Datenunabhängigkeit anzusehen ist, bedeutet, daß der Benutzer keine Kenntnisse darüber benötigt, wie der Aufsuchprozeß beim Wiederauffinden, beim Modifizieren, beim Einfügen oder beim Löschen im einzelnen vonstatten geht. Zugriffspfad-Unabhängigkeit ist nur dann möglich, wenn der Benutzer in einer Datenmanipulationssprache Mengen von Sätzen spezifizieren kann, ohne eine Satz-für-Satz-Prüfung vornehmen zu müssen. Fragen des Typs "Finde alle Sätze, welche...", die also auf Grund bestimmter inhaltlicher Kriterien Datensätze qualifizieren, können pfadunabhängig in einer Datenmanipulationssprache formuliert werden. Die Zugriffspfade-Unabhängigkeit öffnet dem anspruchsvollen Laien den Weg zum System. Das Denken in Zugriffspfaden und den damit verbundenen Kontrollogiken bleibt dem Programmierer vorbehalten.

Die Entwicklungsziele müssen als Primärziele aufgefaßt werden. Der Leser könnte die Position "Schutz vor unberechtigtem Zugriff" vermissen, über die im Rahmen des Datenschutzes in der politischen Welt heftig debattiert wird. Aus der nüchternen Entwicklungspraxis heraus kann als ein Nachteil der zentralisierten Dateien angesehen werden, daß die Abwehr des unberechtigten Zugriffs zu einem besonderen Problem geworden ist. Forderungen des Datenschutzes, wie die Forderungen des Umwelt - und Denkmalschutzes, können nicht zu Entwicklungszielen erklärt werden; sie sind als Nebenbedingungen den Systemen aufzuerlegen. Es hat keinen Sinn, den Datenschutz eines Systems zu maximieren, was Vertreter der Jurisprudenz-Datenverarbeitung gerne möchten. In einem solchen Falle würden wir uns fast ausschließlich mit dem unberechtigten Zugriff beschäftigen. Zu produktiven Zugriffen käme es dann nicht mehr. Der Unterschied zwischen Entwicklungsziel und Entwicklungsnebenbedingung sollte nicht aufgehoben werden.