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.

29.06.1990 - 

Die Datenbank-Entwicklung geht weiter, und

Das Relationenmodell ist nicht mehr Stand der Technik

Der Zahn der Zeit verschont auch nicht die relationalen Datenbanken. Wer sich für ein derartiges Produkt entscheidet, sollte schon heute daran denken, daß die Nachfolgeprodukte bereits in den Startlöchern hocken. Treffen die Prognosen von Peter Pagé (siehe auch vorstehende Diskussion auf Seite 31) zu, dann geht das Relationenmodell in naher Zukunft in einem Technologie-Konglomerat auf, das er als "objektorientiertes Entity-Relationship-Modell" beschreibt.

Peter Pagé ist als Vorstandsmitglied der Software AG verantwortlich für Entwicklung, Marketing und Vertrieb in Europa.

Die folgende Darstellung behandelt die Entwicklung der Datenbank-Verwaltungssysteme (DBMS) und ihrer zugrundeliegenden Datenmodellierungs-Methoden. Aufbauend auf Erfahrung und Analyse der praktischen Anforderungen an DBMS wird versucht, eine rationale Evolution der Methoden und implementierten Systeme aufzuzeigen, um dann über den Status quo hinaus in die Zukunft zu schauen.

Ende der 60er Jahre kamen die ersten DBMS

Nachdem in ersten DV-Anwendungen die Datenverwaltung in die Programme eingebettet war und für jede Anwendung individuell konzipiert wurde, entstanden Ende der 60er Jahre die ersten Standard-Datenbank-Verwaltungssysteme (DBMS). Basierend auf verschiedenen Ansätzen bildeten sich unterschiedliche Typen heraus:

- Hierarchisch orientierte Systeme (zum Beispiel IBMs IMS), die mit physischen "Pointern" hierarchische Strukturen in Daten abbilden konnten. Diese Systeme basieren auf den Anforderungen von Anwendungen zur Stücklisten-Verarbeitung. Ausgehend von den technischen Möglichkeiten der hierarchischen Datenstrukturierung wurden die Daten aller Anwendungssysteme hierarchisch strukturiert, auch wenn dies nicht unbedingt dem Problem entsprach.

- Netzwerkartig strukturierte Systeme (zum Beispiel Cullinets IDMS), die mit physischen Pointern Netzwerkstrukturen in Daten abbilden konnten und damit flexibler als streng hierarchische Systeme waren. Netzwerksysteme basieren auf dem Codasyl-Normungsvorschlag für einheitliche Datendefinitions- und -manipulationssprachen.

Inflexibel bei Strukturveränderungen

Sowohl hierarchische als auch netzwerkorientierte Datenbanksysteme erwiesen sich bei Strukturänderungen als sehr inflexibel und schränkten zudem die Möglichkeiten der Informationsgewinnung stark ein. Daher wurden "Sekundärindizes" zum direkten Zugriff auf Daten und "logische Sichten" eingefügt, die auch eine bessere Entkoppelung der Datendarstellung im Programm von deren physischer Implementierung ermöglichte.

- Datenbanksysteme mit "invertierten Listen", wie zum Beispiel Adabas, stellen einen pragmatischen Kompromiß dar, mit dem bei Stapel- und Transaktionsverarbeitung dieselbe Leistung wie von hierarchischen Systeme erbracht wird. Gleichzeitig wird durch "Deskriptoren", die durch sogenannte "invertierte Listen" repräsentiert werden, eine schnelle und flexible Informationsgewinnung möglich. Strukturierungsmöglichkeiten für die gespeicherten Daten sind dabei durch mehrwertige Attribute und "Wiederholgruppen" für Attribute nur begrenzt gegeben.

In der Folge haben sich die Systeme mit invertierten Listen in zwei Richtungen weiterentwickelt: einerseits Datenselektion auch über "Nichtdeskriptoren", andererseits beliebige Attribute und Erweiterung der Datenstrukturierung auf der Basis des Entity-Relationship-Modells.

- Seit den 80er Jahre gibt es relationale Datenbanksysteme wie DB2 und Oracle. Sie basieren auf der bereits 1970 vor E.F. Codd formulierten relationalen Theorie, die über "Normalisierungsregeln" Daten ausschließlich in Tabellenform abbildet und über"Mengenoperationen" die Selektion von Daten über Wertinhalte von Attributen ermöglicht.

Konzipiert wurden relationale Systeme primär als "Endbenutzersysteme" zur Informationsgewinnung. Als besondere Funktion ermöglichen RDBMS "Joins" von Tabellen über Wertinhalte von Attributen. Da diese Systeme ein abstraktes mathematisches Modell implementieren, sind wesentliche Funktionen mit heute verfügbarer Hardware in der Praxis noch nicht anwendbar.

Als wichtiges Ergebnis der Implementierung der relationalen Theorie und deren Darstellung als einziges Datenmodell der Zukunft gilt heute SQL, das sich als Standard für Datenmanipulations-Sprachen etabliert. SQL erlaubt jedoch bis heute nicht die Verarbeitung von Daten aus anderen etablierten Datenverwaltungs-Systemen wie IMS beziehungsweise VSAM.

Das Datenchaos droht bei der "Normalisierung"

Die dogmatische Anwendung der "Normalisierungsregeln" zur Aufteilung der Daten auf Tabellen führt häufig zu einer Inflation "atomarer" Datenstückchen, die erst im Anwendungsprogramm durch Programmierungslogik wieder zusammengeführt werden können. Während die hierarchische Strukturierung von Daten eine "Erstarrung" der Strukturen zur Folge hatte, besteht bei einer strengen "Normalisierung" der Daten das Risiko eines völligen Verlustes von Strukturierung mit der Konsequenz des Datenchaos.

Noch etwa bis letztes Jahr konnten etablierte Daten-Verwaltungssysteme die wesentlichen Anforderungen in der kommerziellen Datenverarbeitung erfüllen. Sie ergänzten sich in ihren Funktionen und deckten gemeinsam ein breites Anforderungsspektrum von strukturierten Daten bis zu Endbenutzer-Informationssystemen ab. Auch bei Einführung der relationalen Datenbanksysteme wurden diese noch als Ergänzung zu den bestehenden Systemen positioniert.

Die Anforderungen sind stetig gewachsen

Trotz ausbleibender Erfolge in der Implementierung von umfangreichen und durchsatzorientierten Anwendungssystemen verschob sich die Positionierung mehr und mehr zur Ausschließlichkeit relationaler Systeme, ja sogar zu einer dogmatischen Starrheit, die keine anderen Ansätze der Datenmodellierung für die Zukunft in Betracht zog.

Zunehmend ergeben sich jedoch Anforderungen an Datenverwaltungssysteme, die mit konventionellen und relationalen Systemen nicht abgedeckt werden können.

So verlangt die Büroautomation nach der Möglichkeit, Dokumente zu verwalten, die sowohl aus Texten, formatierten Daten als auch aus Bildinformation bestehen. Hier kann die Funktion der Auffindung von Dokumenten durch eine Kombination der darin enthaltenen Wörter mit relationaler Technik weder konzeptionell noch praktisch abgebildet werden. Systeme mit "invertierten Listen", die das Konzept mehrwertiger Attribute (Wort in Text) zulassen, liefern dafür eher praktische Lösungen.

Neben dem Wunsch nach speziellen Lösungen tritt die Forderung nach strukturierterer Datenverwaltung immer mehr in den Vordergrund. Basierend auf dem Entity-Relationship-Ansatz von Professor Chen, der seit 1976 zunehmend die konzeptionelle Basis bei der Analyse und Strukturierung von Anwendungssystemen mit Computer-Aided-Software-Engineering (CASE)-Werkzeugen darstellt, wird auch für das Daten-Verwaltungssystem die Möglichkeit der Verwaltung von Strukturinformationen gefordert.

Mit Entire von der Software AG und dem Repository von IBM, die beide eine Datenstrukturierung nach dem Entity-Relationship-Modell erlauben, werden erste Antworten in Form verfügbarer Produkte gegeben. Dazu führt IBM mit dem NF2-Modell (Non First Normal Form) eine weitere Variante für strukturierte Datenverwaltung in die Diskussion ein.

Oft wird fälschlicherweise der Eindruck erweckt, als sei Entity-Relationship eine Weiterentwicklung des Relationenmodells. Das ist falsch. Beide Modelle beruhen auf völlig unterschiedlichen Theorien. Es ist nicht möglich, die eine aus der anderen abzuleiten. Normalisierte tabellarische Daten mit dynamisch aufgebauten Beziehungen (Relationen) stehen gegen strukturierte (von Objekten der realen Welt abgeleiteten) Entitäten mit explizit implementierten Beziehungen (Relationships).

Zusammenfassend kann der derzeitige Stand der Entwicklung so dargestellt werden, daß sich durch die übermäßige Herausstellung des relationalen Datenmodells die nationale Beschäftigung mit anderen Systemen, die für die Lösung anstehender Probleme benötigt werden, erschwert.

Schon jetzt gewinnen neben dem Entity-Relationship-Modell - durch das die Prinzipien der Datenstrukturierung implementierter Beziehungen, der Klassifizierung und Vererbung von Eigenschaften eingeführt wurden - die Prinzipien objektorientierter Programmierung und objektorientierter Datenmodellierung an Bedeutung.

Ähnlich wichtig sind die Techniken der vierten Generation. Sie erlauben es, Funktionen zu spezifizieren und unmittelbar (ohne Generierung von Low-Level-Programmen) auszulösen. Damit ist die Möglichkeit gegeben, beliebige Aktionen als Eigenschaften von Objekten zu formulieren und in beliebiger Konfiguration je nach Referenz durch den Benutzer zu aktivieren. Diese Ansätze führen zu einem Konzept von "aktiven" Eigenschaften (Attributen) und ermöglichen die Kommunikation zwischen Objekten auf der Basis von definierten Nachrichten, die innerhalb der Objekte definierte Aktionen (Methoden) anregen.

Ein Abbild der realen Welt

Auch in relationalen Systemen werden zunehmend aktive Komponenten in der Form von "lntegritätsregeln" eingeführt und damit auch hier der Forderung nach Verwaltung von "aktiven" Eigenschaften als Teil der Datenverwaltung Rechnung getragen. Da jedoch das Konzept eines komplexen Directories zur Steuerung und Verwaltung der Regeln fehlt, stehen die "lntegritätsregeln" heute als externe Programme noch außerhalb der Datenverwaltung. Nur sehr eingeschränkte und feste Regeln werden als "Standardfunktionen" unterstützt.

In der Verbindung dieser Konzepte wird sich die Datenverwaltung in der Zukunft dahin entwickeln, daß sie ein Abbild des Datengehaltes der realen Welt erstellen und damit ein "natürliches" Verständnis für die Datenverarbeitung bei einem großen Kreis von Menschen aus allen Fachabteilungen ermöglichen kann.

Das Ergebnis wird ein Modell sein, in dem die meisten der genannten Techniken zu einem Produkt zusammenfließen, daß sich am ehesten als "objektorientiertes Entity-Relationship-Datenbanksystem" bezeichnen läßt.