Advanced Information Management Prototype

Dieser Artikel wurde zur Löschung vorgeschlagen.

Falls du Autor des Artikels bist, lies dir bitte durch, was ein Löschantrag bedeutet, und entferne diesen Hinweis nicht.

Zur Löschdiskussion
Begründung: Enzyklopädische Relevanz unbestritten, aber kein enzyklopädischer Artikel. QS ist nicht möglich. Der Artikelersteller wollte ein technisches Handbuch verfassen. Unverständlich, unrettbar. -- WMS.Nemo (Diskussion) 19:38, 23. Feb. 2026 (CET)

Dieser Artikel wurde am 21. Februar 2026 auf den Seiten der Qualitätssicherung eingetragen. Bitte hilf mit, ihn zu verbessern, und beteilige dich bitte an der Diskussion! Folgendes muss noch verbessert werden: möchte da jemand einen Artikel draus machen? Relevanz vorausgesetzt 𝔉𝔩𝔬𝔰𝔰𝔢𝔫𝔱𝔯𝔞𝔢𝔤𝔢𝔯 🐟🐟🐟 16:50, 21. Feb. 2026 (CET)

Der Advanced Information Management Prototype (AIM-P) war ein experimentelles Datenbankmanagementsystem (DBMS), das am Wissenschaftlichen Zentrum Heidelberg (WZH) der IBM von 1982 bis 1989 entwickelt und erprobt wurde ^[1][2]. Der Entwurf, die Entwicklung sowie der anschließende Einsatz von AIM-P in technisch-wissenschaftlichen Anwendungsprojekten diente als „Proof of Concept“ für wesentliche Teile des am WZH entwickelten Datenmodells der „Erweiterten NF²-Relationen" (eNF²-Relationen), der darauf abgestimmten SQL-ähnlichen Anfragesprache HDBL, den benutzerdefinierten Datentypen und Funktionen, der Programmierschnittstelle zur Anwendungsentwicklung (API), der Unterstützung temporaler Daten sowie dem neuartigen Ansatz für das kooperative Zusammenwirken von (CAx-)Workstations mit Datenbankservern („Workstation-Server-Kooperation“). Die Bezeichnung „Prototype“ diente der Klarstellung, dass es sich nicht um ein kommerzielles Produkt von IBM handelt, sondern um eine experimentelle Implementierung eines DBMS zur Erprobung dieser technologischen Konzepte. Die entstandenen Publikationen zeigen allerdings, dass die erarbeiteten Konzepte im Prinzip „produkttauglich“ sein sollten, wie z. B. internen Datenstrukturen für die eNF²-Relationen zum effizienten Zugriff sowohl auf ein eNF²-Objekt als Ganzes als auch auf dessen Teile ^[3][4][5] und die tief im Systemkern verankerte Unterstützung der Zeitversionen ^[6][7].

Am Entwurf und der Implementierung von AIM-P arbeiteten neben den WZH-Wissenschaftlern viele Gastwissenschaftler aus Deutschland, Europa und den USA sowie in Form von institutionellen Forschungskooperationen mit den Universitäten Darmstadt, der Fernuniversität in Hagen sowie der Universität Karlsruhe (dem heutigen KIT) mit. Dies spiegelt sich auch in den über 80 wissenschaftlichen Publikationen von Projektmitgliedern wider, die während ihrer Mitarbeit beim Entwurf, der Implementierung, der Entwicklung weiterer Konzepte und der Evaluation des AIM-P-System entstanden sind. Das AIM-P-Forschungs- und Entwicklungsprojekt (insbesondere der NF²-/eNF²-Ansatz) inspirierte weltweit zahlreiche Forschungsaktivitäten (wie z. B. in Australien ^[8], Finnland ^[9][10], Frankreich ^[11][12], Italien ^[13], Indien ^[14], Japan ^[15], Kanada ^[16], Niederlande ^[17][18] und den USA ^{[19][20][21][22]}). Teile des NF²-/eNF²-Ansatzes wurden später auch in kommerzielle relationale DBMS integriert (wie z. B. 1997 in Oracle Version 8 ^[23] und 1999 in Informix Dynamic Server.2000 ^[24]) und gingen z.T. auch in den SQL-Standard ab SQL:2003 ^[25] ein, allerdings in einer im Vergleich zum AIM-P-Ansatz stark eingeschränkten Form.

Ende der 1970er Jahre – also noch bevor die ersten kommerziellen relationalen DBMS auf den Markt kamen – experimentierten Wissenschaftler am IBM Research Laboratory in San Jose (dem späteren IBM Almaden Research Center) und am Wissenschaftlichen Zentrum Heidelberg der IBM mit den Einsatz von System R in Anwendungen, in denen komplex strukturierte Datenobjekte zu verwalten waren. In San Jose waren dies ingenieurwissenschaftliche ^[26], während es in Heidelberg Dokumentenretrieval-Anwendungen ^[1][27] waren. Beide Gruppen kamen unabhängig von einander zu dem Ergebnis, dass auf dem Relationmodell von E.F. Codd basierende Datenbanksysteme mit ihren (wegen der 1. Normalform) „flachen“ Relationen (im Folgenden „1NF-Relationen“ genannt) für Anwendungen dieser Art nicht geeignet sein werden.

Während man im San Jose Resarch Lab der IBM (dem späteren IBM Almaden Research Center) 1NF-Relationen ausgerichteten DBMS-Kern nicht anrührte und es mit einem „On-Top“-Ansatz versuchte ^[26] (im Folgenden XSQL genannt), erweiterte man am WZH die theoretische Grundlage des relationalen Datenmodells und die zugrundeliegende Relationenalgebra, so dass diese auch Relationen mit relationswertigen Attributen („geschachtelte Relationen“), unterstützen konnte. Da dieses erweiterte relationale Datenmodell die Forderung der ersten Normalform (1NF) aufgibt, nannte man es Non First Normal Form Relations (abgekürzt NF²-Relationen) ^[28] und skizzierte auch einen Sprachvorschlag zur Erweiterung der Datenbank-Anfragesprache SQL.^[27]

Nachdem diese Schwächen der in Entwicklung befindenden relationalen DBMS erkannt wurden, richtete man Ende der 1970er Jahre am WZH den Forschungsbereich „Advanced Information Management“ (AIM) ein, um dort die Anforderungen an zukünftige Datenbanksysteme in neuen Anwendungsbereichen systematisch zu untersuchen und hierfür ggf. geeignete (und bei Bedarf auch über den NF²-Ansatz hinausgehende) Lösungskonzepte zu entwickeln ^[1][2]. Zu Anfang wurden eine ganze Reihe von „Nicht-Standard“-Datenbankanwendungen, wie z. B. Computer Integrated Manufacturing (CIM), Computer Aided Design (CAD), Robotik, Geoinformationssysteme, Dokumenten-Verwaltung (Dokumenten-Retrieval), untersucht, um ihre Anforderungen an die benötigten Datenstrukturen und Datentypen, die Art der Anfragen und die daraus resultierenden Anforderungen an das Datenbanksystem zu ermitteln ^[29].

Die hierbei gewonnen Erkenntnisse ließen erkennen, dass auch das NF²-Relationenmodell nicht alle Anforderungen abdecken kann, sondern dass ein noch mächtigeres Datenmodell, eine dazu passende Anfragesprache sowie die Unterstützung benutzerdefinierter Datentypen und Operationen benötigt werden. Außerdem sollten geeignete Konzepte für das Zusammenwirken von CAx-Workstations mit Datenbankservern („Workstation-Server-Kooperation“) sowie die Unterstützung zeitversionierter Daten (im Sinne einer temporalen Datenbank) erarbeitet werden ^[29].

Ende 1982 wurde dann am WZH entschieden einen DBMS-Prototyp zu bauen, in dessen sowie Entwurf und Implementierung alle wesentlichen Erkenntnisse einfließen sollten, die sich im Verlauf des Projektes ergeben, so dass diese nach Fertigstellung dieses DBMS in realitätsnahen Anwendungsszenarien als Proof of Concept erprobt werden können. Dieser Prototyp erhielt den Namen „Advanced Information Management Prototype (AIM-P) ^[1][30] und seine Anfragesprache das Akronym bzw. den Namen HDBL („Heidelberg Database Language“) ^[29]. Seine Architektur mit den wichtigsten Komponenten ist in Abb. 1 dargestellt.

Der Catalog Manager ist – wie bei den relationalen Datenbanksystemen auch – dafür zuständig, die in der Datenbank als reine Bytestrings variabler Länge gespeicherten Datensätze inhaltlich interpretieren zu können. Während es im 1NF-Fall in vielen Fällen genügt, für jede Relation zur Beschreibung der Struktur ihrer Tupel lediglich eine Liste der Attributtypen und ggf. deren Länge in Bytes zu speichern, kommen im eNF²-Fall noch zusätzliche „Struktur-Datensätze“ wie im Abschnitt Speicherstrukturen für das NF²-/eNF²-Relationenmodell beschrieben hinzu, deren inhaltliche Struktur ebenfalls im Datenbank-Katalog gespeichert werden muss. Dem Query Processor liefert der Catalog Manager eine logische Sicht auf das eNF²-Datenmodell, das in etwa der bildlichen Darstellung als geschachtelte Tabellen (wie weiter unten abgebildet) entspricht. Dem Complex Object Manager sowie dem Subtuple Manager werden hingegen die zugehörigen (internen) Struktur-Informationen zu allen Datensätzen geliefert auf die sie zugreifen müssen.

Der Query Processor nimmt die in HDBL formulierten Anfrage- und Änderungsoperationen entgegen und transformiert diesen in einen Operatorbaum in dem, ggf. (auch tief) geschachelt, die mit Aufrufparametern versehenen Operatoren der HDBL-Algebra für Selektion, Projektion usw. eingebettet sind. (Wenn nur 1NF-Relationen involviert sind, sieht dieser Operatorbaum sehr ähnlich aus wie der vom Anfrageoptimierer eines relationalen DBMS erzeugte.) Diesen Operatorbaum reicht der Query Processor an den Complex Object Manager weiter.

Der Complex Object Manager erfüllt drei verschiedene Aufgaben, die in den verschiedenen Phasen der Anfragebearbeitung anfallen:

1. Die Operatoren der HDBL-Relationenalgebra durch die konkreten Such- und Zugriffsoperatoren auf den benötigten Datensätzen der intern verwendeten Speicherstrukturen zu ersetzen und diese auszuführen.
2. Das Ergebnis der Anfrage (das „Resultat-Objekt“) in einer internen Datenstruktur entsprechend der gewünschten Ausgabestruktur zu materialisieren und in einem temporären Segment der AIM-P-Datenbank als Übergabebereich zu speichern.
3. Den Inhalt des Resultat-Objekts in der von der Anwendung (Online-Interface oder Anwendungsprogramm-Schnittstelle (API)) mittels seiner Subkomponente Result Walk ^[31] in der gewünschten Form (attribut-weise, tupel-weise oder „en bloc“ (objekt-weise)) an diese zu übergeben ^[32]. Für den Zugriff auf die Datensätze zum Lesen, Einfügen, Löschen oder Ändern wendet sich der Complex Object Manager an den Subtuple Manager.

Der Subtuple Manager benötigt beim Aufruf die Informationen, ob der Datensatz in seiner aktuellen oder einer früheren Version („ASOF“) zurückgeliefert werden soll sowie – wenn es sich um den Start einer neuen Transaktion handelt – in welchem Transaktionsmodus („read-only“ oder „update“) diese ausgeführt werden soll. Der Subtuple Manager kümmert sich auch um die zeitversionierte Speicherung der Datensätze, das transaktionsorientierte Logging und Recovery sowie das Setzen und Freigeben von Sperren. Hierauf wird im Abschnitt System-interne Aspekte näher eingegangen.

Der Buffer Manager verwaltet einen zentralen Übergabebereich, Systempuffer genannt, im Hauptspeicher, in dem die vom Subtuple Manager zum Lesen und Schreiben angeforderten aktuellen oder „historischen“ Datensätze abgelegt werden. Beim lesenden Zugriff reicht der Subtuple Manager i.W. anschließend einfach die Adresse des Datensatzes im Systempuffer via Complex Object Manager an den Query Processor oder die Anwendung weiter. Beim schreibenden Zugriff führt der Subtuple Manager die angeforderten Änderungen im Datensatz im Systempuffer selbst durch und kümmert sich auch um die Sicherung dieser Änderungen auf dem Hintergrundspeicher. Weitere Details dazu werden in den Abschnitten Transaction-Oriented Workspace (TWS) und Unterstützung temporaler Daten beschrieben.

Der Segment Manager interagiert mit dem Dateisystem des Betriebssystems, um Dateien für das Datenbanksystem anzulegen (zu „allokieren“) oder diese wieder freizugeben. In den meisten Fällen wird ein Segment auf Basis einer einzelnen Datei realisiert. Bei Bedarf können diese Segmenten aber auch aus mehreren Dateien zusammengesetzt werden, die „nach oben“ wie ein einziger großer Speicherbereich in Erscheinung treten.

Eine ausführlichere Beschreibung dieser Systemarchitektur und das Zusammenspiel der verschiedenen Komponenten findet sich in _^[32].

Für die „vor-relationalen“ DBMS, die auf dem hierarchischen Datenbankmodell oder dem Netzwerk-Datenbankmodell basieren ist typisch, dass man sich das gewünschte Anfrageergebnis in der Regel mit Folgen von einzelnen DatenbankAnfragen quasi stückweise zusammensuchen muss. (Ausführliche Anfragebeispiele zu diesen DBMS finden sich z. B. in _^[33] und _^[34].) Im Gegensatz dazu ermöglichen relationale DBMS, solche DatenbankAnfragen mit einem einzigen Anfrageausdruck zu erledigen. Ermöglicht wird dies durch die diesem Datenmodell zugrundeliegende Relationenalgebra bzw. die darauf aufbauende Anfragesprache SQL. Die Relationenalgebra setzt voraus, dass alle Daten als Relationen in 1. Normalform – im Folgenden kurz „1NF-Relationen“ genannt – gespeichert werden.

Bei relativ einfach strukturierten Daten, wie sie z. B. im kaufmännischen Bereich vorkommen, funktionieren deren Abbildung auf 1NF-Relationen sowie DatenbankAnfragen gegen diese in der Regel recht gut. Ganz anders sieht es hingegen bei großen und komplex-strukturierten Datenobjekten aus, wie sie z. B. bei CAD-Konstruktionsdaten von Motoren, Turbinen, PKW, Flugzeugen und Gebäuden auftreten. Als stark vereinfachtes Beispiel ^[35] dient im Folgenden die Speicherung der Daten von Robotern, wie in Abb. 2 illustriert (den Gelenken sind in dieser Abbildung sog. DH-Matrizen zugeordnet, die zu Berechnungen im Zusammenhang mit Bewegungen der Roboterarme benötigt werden). Für die Abbildung all dieser Daten würde man in einem relationalen DBMS etwa die in Abb. 3 dargestellten 1NF-Relationen verwenden.

Eine typische DatenbankAnfrage wäre alle Informationen zu einem bestimmten Roboter zu erhalten. Dies würde z. B. die in Abb. 4 dargestellte SQL-Anweisung leisten und als Resultatmenge die in Abb. 5 skizzierte Ergebnistabelle zurück liefern.

Durch die 1NF-Ergebnisdarstellung (und nur diese gibt es in relationalen DBMS) erhält man eine Tabelle, in der die vom Anwender gewünschte Information über viele Spalten und Zeilen verstreut und so eigentlich für ihn nicht direkt brauchbar ist. Um mit diesen Ergebnisdaten etwas anfangen zu können, müssen diese deshalb per Anwendungsprogramm erst in eine strukturierte, lesbare Form gebracht werden. Bei realen Daten für Roboter-Anwendungen, bei den CAD-Daten für einen Serien-PKW mit all seinen Varianten, bei einem Flugzeug usw. können dies hunderte und auch tausende von 1NF-Relationen sein. Anfragen dieser Art würden dann in vielen Fällen zu extrem großen Resultattabellen mit vielen hundert oder gar tausend Spalten führen (was die relationalen DBMS des Jahrgangs 1983 überhaupt nicht unterstützt hätten). Abgesehen davon würde es auch zu tausenden von Zeilen führen, was sich wiederum in sehr langen Antwortzeiten niederschlagen würde. Die „Lösung“ sah deshalb Mitte der 1980er Jahre – und das hat sich bis heute (2026) eigentlich nicht wesentlich geändert – dann wie in Abb. 6 skizziert aus. Das Anwendungsprogramm oder eine Zwischenschicht zwischen diesem und der Datenbank führt, mehrfach iterierend, viele einzelne SQL-Anfragen auf der relationalen Datenbank aus, wobei der „Output“ einer Anfrage in der Regel den „Input“ für die nachfolgende Anfrage liefert. Bei dieser Vorgehensweise werden die benötigten Daten quasi „stückweise“ aus der Datenbank geholt. Diese Art der Interaktion zwischen Anwendungsprogramm und Datenbanksystem ähnelt damit stark derjenigen bei den DBMS aus der vor-relationalen Zeit, die auf dem hierarchischen oder Netzwerk-Datenbankmodell basierten.

Das 1NF-Datenmodell hat darüber hinaus auch noch eine weitere Schwäche: Es bietet – insbesondere im Kontext komplex strukturierter Datenobjekte – dem Anwendungsentwickler keine intuitive Vorstellung, wie das komplexe Datenobjekt strukturiert ist. Da dieses aufgrund der Normalisierung auf viele Relationen verteilt gespeichert werden muss, benötigt dieser deshalb in den meisten Fällen jeweils ein geeignetes semantisches Datenmodell (wie z. B. ER- oder UML-Diagramme) als Hilfsmittel, um die SQL-Anfrage überhaupt so formulieren zu können, dass sie das gewünschte Ergebnis liefert.

Wie im Abschnitt „Vorgeschichte“ erwähnt, waren das am WZH entwickelte NF²-Relationenmodell ^[28] in Verbindung mit Sprachvorschlägen für eine dazu passende SQL-ähnliche Anfragesprache ^[27][36], bereits ein wichtiger Schritt zur besseren Unterstützung komplex strukturierter Datenobjekte. Die Roboterdaten könnten in diesem Relationenmodell z. B. wie in Abb. 7 illustriert strukturiert werden.

Das NF²-Relationenmodell

• ist eine Verallgemeinerung des 1NF-Relationenmodells, d.h. jede korrekt konstruierte 1NF-Relation ist auch eine korrekt konstruierte NF²-Relation ^[28][37]
• ermöglicht eine natürlichere und intuitiv besser verständliche Darstellung hierarchisch strukturierter Objekte (Abb. 7) ^[9][38]
• ermöglicht die kompakte Übertragung solcher Anfrageeergebnisse zum Anwendungsprogramm oder zur Workstation ^[39][40][41] und reduziert dort ggf. den Aufbereitungsaufwand
• basiert auf einer (erweiterten) Relationenalgebra und ermöglich hierdurch auch (weiterhin) eine systemseitige Anfrageoptimierung ^{[37][42][43][44]}
• verfügt über entsprechend angepasste Normalformen für den Datenbankentwurf ^[45][46]

Wenn ein NF²-DBMS Sichten unterstützt, dann ergeben sich hinsichtlich der in Abb. 7 dargestellten NF²-Tabelle im Prinzip zwei Möglichkeiten der internen Speicherung:

1. Speicherung als strukturiertes NF²-Datenobjekt (d.h. als Tupel einer NF²-Relation) mit darauf zugeschnittenen internen Datenstrukturen ^[5][4]
2. Speicherung als 1NF-Relationen (wie in Abb. 3) und man definiert darauf eine der Abb. 7 entsprechende Sicht

Da die 1NF-Relationen in diesem Beispiel verlustfrei in die NF²-Darstellung und umgekehrt transformiert werden können, könnte man bei Realisierungsvariante 1 umgekehrt auch die 1NF-Relationen als Sichten auf die gespeicherte NF²-Relation realisieren und über beide Wege dann auch Änderungsoperationen (Updates) unterstützen.^[37]

Das NF²-Relationenmodell stellt für technisch-wissenschaftliche Anwendungen zwar bereits einen wichtigen Schritt in die richtige Richtung dar, ist aber hinsichtlich der Vielfalt der Datenstrukturen, die in solchen Anwendungen benötigt werden ^{[47][48][49][50]}, bei weitem noch nicht ausreichend. Die Entwicklung vom NF² zum endgültigen "erweiterten NF²-Relationenmodell (kurz: eNF²-Relationenmodell) war ein iterativer Prozess verbunden mit sukzessiven Erweiterungen des NF²-Ansatzes um weitere Konstrukte wie Liste von atomaren Werten, Liste von Tupeln, Listen von Listen usw. (Eine ausführliche Begründung dieser Erweiterungen mit Anwendungsbeispielen findet sich in _^[35].) Das finale eNF²-Relationenmodell war auch stark von den bei dem Entwurf der dazu passenden DatenbankAnfragesprache gewonnenen Einsichten geprägt und lässt atomare Werte sowie die Konstruktoren Tupel, Liste und (Multi-)Set, die alleine stehen oder in beliebiger Weise miteinander kombiniert werden können, wie in Abb. 8 illustriert, sowohl als Top-Level-Objekt als auch innerhalb eines strukturierten Objektes zu. Jedes so erzeugte Objekt ist ein strukturell legales Objekt des eNF²-Relationenmodells. Es kann als Ergebnisobjekt in Anfragen und in Zwischenergebnissen von geschachtelten Anfrageausdrücken auftreten und auch in einer eNF²-Datenbank gespeichert werden ^[29]. - Die für das eNF²-Relationenmodell entwickelte Relationenalgebra ^[29][30] (die leider nie in Gänze publiziert wurde), ermöglicht ebenfalls eine systemseitige Anfrageoptimierung, ist naturgemäß jedoch komplexer als bei 1NF-Relationen.^[30][51]

Bei Verwendung des eNF²-Relationenmodells kann man z. B. auf das in Abb. 7 noch vorkommende „Sortier-Attribut“ 'AxisNo' verzichten und die DH-Matrix als Liste von Listen von atomaren Werten darstellen wie in Abb. 9 illustriert (und wenn man 'Arms' als Liste speichern würde, wäre auch das Attribut 'ArmID' überflüssig.)

Die bahnbrechende Neuerung bei der Entwicklung des relationalen Datenmodells durch E.F. Codd ^[52] war die konsequente Speicherung aller Daten als Relationen mit 1NF-Tupeln als Datensätze und die darauf aufbauende Definition der Relationenalgebra mit Operatoren wie Selection, Projection, Join usw. Diese Operatoren haben allesamt die Eigenschaft, dass sie, angewandt auf eine 1NF-Relation, als Ergebnis stets wieder eine 1NF-Relation zurückgeben. Durch diese Orthogonalitäts-Eigenschaft kann man auch sehr komplexe, geschachtelte Anfrageausdrücke mit diesen Operatoren formulieren. Außerdem kann man – in Analogie zur mathematischen Algebra – Äquivalenztransformationen definieren, die es ermöglichen einen Anfrageausdruck in einen anderen Anfrageausdruck umzuformen, der – angewandt auf dieselben Ausgangsrelationen – zum selben Ergebnis führt. (Die Reihenfolge der Tupel sowie der Attribute der Ergebnisrelationen werden hierbei as irrelevant betrachtet.) Diese Äquivalenztransformationen ermöglichen die Implementierung von Anfrageoptimierern in relationalen DBMS.

Alle diese Eigenschaften gelten auch für das von Jaescke und Schek entwickelte NF²-Relationenmodell mit der zugehörigen NF²-Algebra ^[28]. Hierzu wurden die Operatoren der 1NF-Algebra – soweit erforderlich – geeignet redefiniert und zusätzlich die Operatoren 'nest' („schachteln“) und 'unnest' („entschachteln“) eingeführt, um 1NF-Relationen in NF²-Relationen und umgekehrt zu transformieren. Das 1NF-Relationenmodell ist hierdurch ein Spezialfall des NF²-Relationenmodells und damit ist jede 1NF-Relation auch eine NF²-Relation. D.h. die Orthogonalitäts-Eigenschaft ist auch hier gegeben.

Die in den relationalen Datenbanksystemen verwendete Anfragesprache SQL wird intern zwar auf die Operationen der 1NF-Relationenalgebra nebst einigen weiteren, wie z. B. Sortierung, Gruppierung und Join-Varianten, abgebildet, hat jedoch nicht mehr die vollständige Orthogonalitäts-Eigenschaft des 1NF-Relationenmodells. Der Sortieroperator (ORDER BY) erzeugt z. B. eine (sortierte) Liste von Tupeln, die nicht mehr dem Relationenmodell entspricht (das nur Mengen kennt) und darf daher nicht innerhalb von geschachtelten SQL-Ausdrücken auftreten. Noch weitergehend ist der Gruppierungsoperator GROUP BY von SQL, der intern eine Relation mit Untermengen (d.h. Mengen von Mengen von Tupeln) und damit eigentlich eine geschachtelte Relation à la NF² erzeugt. Aus diesem Grund darf er stets nur in Verbindung mit Aggregations-Operatoren wie COUNT, SUM, AVG usw. verwendet werden, die jede Teilmenge jeweils auf ein einziges Tupel reduzieren, welches jeweils die aggregierten Attributwerte enthält und die Ergebnisrelation damit dann wieder 1NF-konform ist.

Das an sich sehr viel komplexere eNF²-Datenmodell hat diese Art von Problemen nicht, da all die zuvor beschriebenen nicht-1NF-konformen Zwischen- und Endzustände legale Strukturen des eNF²-Relationenmodells darstellen. Allerdings ist natürlich die Anzahl der Operatoren der eNF²-Relationenalgebra, z. B. zur Typumwandlung (Menge ↔ Liste, flach ↔ geschachtelt), Zugriff aus Listenelemente (einzeln oder von-bis-Intervalle) sowie für Änderungsoperationen ganz erheblich größer. Mehr Details hierzu finden sich in den Publikationen _^[53], _^[54], _^[55] und _^[56].

Bei der in Abb. 4 dargestellten SQL-Anfrage hat man bereits gesehen, dass auch SQL-Anfragen recht komplex werden können. Wenn neben vielen Basistabellen auch noch weitere Operationen wie z. B. Group-By-Having, Vereinigung, Durchschnitt und Differenz erforderlich werden, kann die semantisch korrekte Formulierung der DatenbankAnfrage auch für einen erfahrenen SQL-Anwender herausfordernd sein.

Bei einem sehr viel mächtigeren Datenmodell wie den eNF²-Relationen, wo neben den 1NF-Relationen im Prinzip jede Kombination von Mengen, Listen, Tupeln und atomaren Werten sowie als Basisobjekte, als Zwischenergebnisse und als Ergebnistyp auftreten können, braucht man eine Anfragesprache mit klaren, leicht verständlichen Regeln sowie mit einen (möglichst vollständigen) Verzicht auf Ausnahmen und Sonderfälle, um trotz aller inhärenten Komplexität noch beherrschbar zu sein. Die für AIM-P und das eNF²-Datenmodell entwickelte DatenbankAnfrage- und -manipulationssprache HDBL (ein Akronym für „Heidelberg Database Language“ ) wurde unter Beachtung dieser Vorgaben entworfen und in wesentlichen Teilen prototypisch in AIM-P implementiert ^[29][53][54]. Das SELECT-FROM-WHERE-Konstrukt (kurz: SFW-Konstrukt) wurde z. B. einerseits beibehalten und sogar auf Listen von Tupeln erweitert, andererseits aber auch in dem Sinne „entschlackt“, dass nicht mehr jede Art von Anfrage-Operatoren der zugrundeliegenden eNF²-Relationenalgebra (wie z. B. GROUP-BY-HAVING bei SQL) in das SFW-Konstrukt integriert wird. Das SFW-Konstrukt wird damit ein „normaler“ Operator, der im Wesentlichen „nur noch“ für die syntaktische Repräsentation der Basis-Operatoren Selektion und Projektion von Mengen von Tupeln und Listen von Tupeln zuständig ist. Das SFW-Konstrukt kann z. B. auch für die Sortierung von Mengen und Listen von Tupeln verwendet werden, man kann aber – wie im Q3 gezeigt – die Sortierung auch durch die Anwendung des Sortier-Operators auf die (Zwischen-)Resultatmenge der SFW-Operation erhalten. Daneben gibt es noch weitere Operatoren wie z. B. für die Entfernung von Duplikaten, für die Gruppierung, für Typ-Umwandlungen und vieles andere mehr. - Im Folgenden werden exemplarisch einige Anwendungsbeispiele von HDBL mit dem SELECT-FROM-WHERE-Konstrukt gezeigt, die im Wesentlichen aus _^[35] entnommen wurden. Viele weitere Beispiele, insbesondere auch zu INSERT, UPDATE und DELETE, finden sich ebenfalls dort.

Wie bereits oben erwähnt verwendet HDBL ebenfalls das SFW-Konstrukt zur Formulierung von Selektionen und Projektionen, allerdings sowohl auf Mengen als auch auf Listen von Tupeln. In beiden Fällen können bei HDBL die Attribute der Tupel sowohl atomar als auch beliebig komplex strukturiert sein. Das SFW-Konstrukt kann in HDBL darüber hinaus auch dazu verwendet werden, um „flache“ in geschachtelte Relationen zu („Nestung“) und umkehrt („Entnestung“) zu überführen.

Beispiele:

Beispiel Q1: Anfrage auf 1NF-Relationen mit Join

Aufgabe: „Gib zu allen Robotern deren ID und Beschreibung sowie die passenden Endeffektoren mit deren und Funktion sortiert nach Roboter-ID als 'flache' Relation aus“.

Die eckigen Klammern in der SELECT-Zeile drücken explizit aus, dass das Ergebnis tupelstrukturiert sein soll. Durch die Sortierung ist der Resultattyp dieser Anfrage eine Liste von Tupeln.

Anmerkung: Die Formulierung des Joins im obigen HDBL-Beispiel entspricht der Join-Syntax gemäß SQL:1986-Standard, an dem man sich beim Entwurf von HDBL orientiert hat. Die expliziten Join-Operatoren wurden erst später mit SQL:1992 eingeführt und waren zum Zeitpunkt der Entwicklung von HDBL daher noch nicht bekannt. Die neue Join-Syntax hat die „alte“ aber nicht abgelöst, sondern stellt nur eine alternative syntaktische Formulierung einer Join-Operation dar (und könnte auch problemlols in HDBL integriert werden).

Beispiel Q2: Alternative Strukturen für das Anfrageergebnis

Aufgabe: „Gib die IDs aller Roboter aus“.

Da in der Anfrage keine Sortierung spezifiziert wurde, würde bei der ersten Anfrage-Variante eine Menge von Tupeln mit dem Attribut RobID zurückgeliefert, also z. B. { ['Rob2'], ['Rob1'], ['Rob3'] } und bei der 2. Variante eine Menge von atomaren Werten, also z. B. { 'Rob2', 'Rob1', 'Rob3' }.

Beispiel Q3: Anfrage-Alternativen für die sortierte Ausgabe der RobIDs

Die in diesem Fall einfachste Alternative ist, die Anfragen in HDBL-Beispiel 2 (Abb. 11) um die ORDER-BY-Klausel erweitern, womit man dann < ['Rob1'], ['Rob2'], ['Rob3'] > bzw. < 'Rob1', 'Rob2', 'Rob3' > als Ergebnis erhält. Eine andere Alternative ist die explizite Anwendung des ORDER-BY-Operators wie in Abb. 12 illustriert.

Beispiel Q4: Einfache Selektions-Anfragen mit Resultatstruktur wie gespeichert

Aufgabe 1: „Gib alle Roboter mit ihren Daten aus“
Aufgabe 2: „Gib Daten von Roboter 'Rob1' aus“
Aufgabe 3: „Gib alle Roboter aus, die den Endeffektor 'SR200' anschließen können"

Beispiel Q5: Ausgabe einer Relation ohne Strukturänderung, aber mit Selektion auf mengenwertigem Attribut

Aufgabe: „Gib alle Roboter aus mit allen Daten aus, ausgenommen bei den Endeffektoren, da interessieren nur die Schraubenzieher ('Screw Driver')“

Beispiel Q6: Ausgabe einer Relation mit Ausblendung von Teilen auf tieferen Ebenen

Aufgabe: „Gib die RobotNF2-Relation aus und blende dabei die Spalten Col1..Col4 des Attributs DH_Matrix aus“

Beispiel Q7: Überführung von 1NF-Relationen in eine inhaltlich äquivalente, geschachtelte NF²-Relation

Aufgabe: „Gib auf Basis der 1NF-Relationen aus Abb. 3 eine geschachtelte NF²-Ergebnis-Relation à la RobotsNF2 aus Abb. 7 aus“

Viele weitere Beispiele, wie z.B. Erstellung einer geschachtelten eNF²-Relation entsprechend der Abb. 9 mittels HDBL-Anfrage sowie Änderungsoperation aller Art finden sich in _^[35].

Zu erwähnen ist noch, dass wirklich alle mittels HDBL erzeugbaren Resultat-Objekte stets auch legale Datenbankobjekte in HDBL sind und daher z. B. auch mittels INSERT-Operation als Top-Level oder auch als Sub-Objekt eines eines anderen Objekts in die Datenbank eingefügt werden können. Die diesbezüglichen Einschränkungen wie bei SQL-Anfragen gibt es, wie oben bereits erwähnt, bei HDBL nicht.

Ganz am Anfang des AIM-P-Projekts wurde auch untersucht, ob man die anfänglich betrachteten „reinen“ NF²-Relationen + ggf. geringfügige Erweiterungen wie z.B. „lange Felder“ (in _^[26] „long fields“ genannt) nicht einfach ebenfalls „on top“ der 1NF-Relationen realisieren sollte, etwa im Stil des im Abschnitt Vorgeschichte erwähnten XSQL-Ansatzes des San Jose Research Labs von IBM ^[26]. Bei einem solchen Ansatz werden die Relationen einfach um zusätzliche Attribute wie z.B. IDENTIFIER, REF und COMP_OF ergänzt, um mit diesen die Querbezüge zwischen den Tupeln des komplexen Objekts mittels Primär- und Fremdschlüsselbeziehungen zu realisieren. Anfragen gegen diese NF²-Sicht werden intern dann in Folgen von „navigierenden“ SQL-Anfragen (oder in Operationen der Relationen-Algebra) übersetzt, mit denen das komplexe Objekt quasi Stück für Stück in eine passende Datenstruktur des Anwendungsprogramms im Hauptspeicher übertragen wird, ganz im Stile der in Abb. 6 illustrierten Lösung. Natürlich stellt dies keine allzu performante Lösung des Problems für einen Einsatz im großen Stil dar. Nachdem sich zudem relativ rasch herausstellte, dass man auch Listen beliebiger Art im Datenmodell unterstützen muss, erübrigten sich weitere Überlegungen in dieser Richtung.

Eine Motivation für die explizite Unterstützung komplexer Objekte in einem Datenbanksystem ist, dass man diese bei Bedarf als Ganzes rasch auslesen kann. Auf der Speicherungsebene bedeutet dies, dass es vorteilhaft ist, alle Teile eines solchen Objekts benachbart auf der Festplatte zu speichern. Man kann aber auch Daten, die man sehr häufig zusammen benötigt und die man im 1NF-Fall mittels Join-Operation in einer Anfrage verknüpfen würde, ebenfalls in einer passenden NF²-Struktur, quasi als „vorberechnete Joins“ ^[43] speichern. In einem solchen Fall sollen hierdurch natürlich keine wesentlichen Nachteile entstehen, wenn man auf diese (evtl. sogar tief geschachtelten) Daten auch separat zugreifen möchte. Im AIM-P-Projekt hat man verschiedene Realisierungsvarianten evaluiert und sich dann für die folgende Vorgehensweise entschieden ^[4][5]: Die Datensätze für die Strukturinformation der eNF²-Objekte – in AIM-P als „Mini-Directories“ (MD) bezeichnet – werden getrennt von den Nutzdaten gespeichert. Mittels physisch benachbarter Speicherung der MD-Datensätze eines eNF²-Objektes konnte man dessen Strukturinformation sehr effizient lesen, dort dann das gewünschte (Sub-)Objekt identifizieren und mit den – ebenfalls in den MD-Datensätzen enthaltenen Adressinformationen auf die (Nutz-)Daten dieses (Sub-)Objekts zuzugreifen. Ausführliche Beschreibungen hierzu finden sich in _^[4],_^[5] und _^[35].

Concurrency Control sowie Logging und Recovery sind systemseitige Maßnahmen zur Synchronisation konkurrierend ausgeführten Transaktionen sowie zur Gewährleistung der Konsistenz der Datenbank in Normalbetrieb sowie auch im Falle von ungeplanten Transaktionsabbrüchen. Die grundlegenden Prinzipien wie Sperrverfahren (mit Zweiphasen-Sperrprotokoll und verschiedenen Sperrmodi), wurden bereits Ende der 1970er und Anfang der 1980er Jahre im Rahmen des Projektes IBM System R ^[57][58] publiziert, so dass man bei der Entwicklung von AIM-P darauf aufsetzen und für die eigenen Anforderungen anpassen und weiterentwickeln konnte. Hierzu gehörten u. a.

• Sperrverfahren für komplex-strukturierte Objekte ^[59][60]
• Sperr- und Update-Verfahren für Text-Indexe ^[61]

Ansonsten galt auch für AIM-P, dass alle Transaktionen alle Objekte auf die sie zugreifen möchten, zuvor mit geeigneten Sperren belegen müssen, die erst nach dem Commit der Transaktion wieder freigegeben werden. Lediglich für langlaufende Transaktionen, wie sie z. B. im Kontext von CAD-Anwendungen auftreten ^[26][62], wurde eine Erweiterung in Form der "Langzeit-Sperren" eingeführt. Die Sperren dieses Typs wurden während der Laufzeit der zugehörigen Transaktion persistent gespeichert, um diese nach einem Neustart des Datenbanksystems und vor Aufnahme des normalen Transaktionsbetriebs wieder aktivieren zu können.

Das Logging, d.h. die Protokollierung von Änderungen der von Transaktionen gemachten Änderungen in der Datenbank zwecks Rückgängigmachung („Undo-Eintrag“) oder Wiederholen („Redo-Eintrag“) von diesen, das von den Datenbanksystemen der 1980er Jahre im Wesentlichen nur für das Recovery verwendet wurde, wurde in Form des im nächsten Abschnitt beschriebenen „Transaction-oriented Workspace“ so umgestaltet, dass es auch für viele andere Zwecke nutzbringend verwendet werden konnte.

Beim Start einer Update-Transaktion wird ihr vom Subtuple-Manager ein Transaction-oriented Workspace (TWS) zugeordnet. Ein solcher TWS besteht aus einem dieser Transaktion exklusiv zugeordneter Bereich im Systempuffer sowie einem ebenfalls exklusiv zugeordneten Datenbank-Segment auf den Festplatten des Datenbanksystems ^[3][63]. Der TWS nimmt alle geänderten Datensätze dieser Transaktion auf, egal ob Benutzerdaten oder Mini-Directories. Im TWS-Index wird verzeichnet, welche Datensätze sich bereits im TWS befinden. Alle Udate-Operationen laufen ebenfalls über den Subtuple-Manager und spezifieren jeweils exakt, welche Teile des Datensatzes zu ändern sind. Diese Informationen werden in einer Undo-Liste ebenfalls im TWS gespeichert. Diese Liste ist sehr ähnlich zu den Undo-Logs der konventionellen Datenbanksysteme, nur dass die Einträge in diesem Fall zunächst nur im TWS verbleiben.

Vor dem Commit einer Update-Transaktion gelangen keinerlei Änderungen von ihr in die Datenbank. Die vom geplanten Update potenziell betroffenen Datensätze werden – in Anlehnung an System R ^[57][58] – lediglich mit einer IX-Sperre belegt, die signalisiert, dass die Umwandlung in eine exklusive X-Sperre beabsichtigt ist. Die IX-Sperre ist kompatibel mit Lesesperren (S-Sperren), so dass während dieser Zeit Nur-Lese-Transaktionen mit ihren S-Sperren weiterhin auf diese Datensätze zugreifen können.

Wird eine Update-Transaktion vor Erreichen ihres Commit-Zeitpunkts von Seiten des Benutzers, der Anwendung oder anderer Umstände abgebrochen, dann besteht die „Recovery“-Maßnahme für diese darin, die von ihr gesetzten Sperren frei zu geben und den TWS (Systempuffer-Bereich + Datenbanksegment) zu löschen und für die weitere Verwendung wieder frei zu geben.

Erreicht eine Update-Transaktion ihren Commit-Zeitpunkt, werden folgende Aktionen durchgeführt:

• Pre-Commit-Phase: Alle geänderten Datensätze sowie deren Undio-Listen werden – soweit noch erforderlich – vom TWS-Systempuffer in dessen Datenbank-Segment geschrieben („forced write“) (damit sind alle Änderungen „in Sicherheit gebracht“)
• Commit-Phase:
  • Die vorher bereits gesetzten IX-Sperren (Sperrverfahren) werden für die zu ändernden Datensätze in X-Sperren konvertiert
  • Die Datensätze werden vom TWS-Systempuffer in den regulären Systempuffer verschoben und von dort in die Datenbank geschrieben
  • Der TWS-Systempuffer-Bereich dieser Update-Transaktion wird gelöscht frei gegeben
  • Die Einträge in den Undo-Listen werden bei Bedarf etwas zusammengefasst und mit den Commit-Zeitstempel versehen in den History-Pool geschrieben (siehe folgender Abschnitt)
  • Die für diese Transaktion gesetzten Sperren werden aufgehoben
  • Sobald sichergestellt ist, dass alle geänderten und neuen Datensätze in die Datenbank und den History-Pool geschrieben wurden, kann das TWS-Datenbank-Segment gelöscht und freigegeben werden

Der TWS wird auch für lange Transaktionen genutzt, wie sie z. B. in technisch-wissenschaftlichen Entwicklungsprojekten auftreten und sich über viele Stunden, u.U. auch mehrere Tage erstrecken können. Hier ist relativ typisch, dass das zu bearbeitende komplexe Objekt (z. B. ein mittels CAD konstruiertes Fahrzeug) per "Check-out" aus der Datenbank „ausgeliehen“, auf die Workstation geladen und dort bearbeitet und dann mittels "Check-in" wieder in der Datenbank gespeichert wird.^[26][62] – Neben den oben bereits erwähnten persistenten Langzeit-Sperren, können lange Transaktion auch Zwischenzustände des ihres TWS auf der Workstation auf das Datenbank-Segment ihre TWS-Pendants auf dem Datenbankserver propagieren und damit Sicherungspunkte für diese Transaktion erzeugen, auf die sie bei Bedarf zurückgehen und die Bearbeitung von dort aus fortsetzen kann. (Ein solches Konzept wurde später unter der Bezeichnis „Save Points“ auch in den SQL-Standard übernommen.)

Sowohl das Anfang der 1980er Jahre wiederauflebende Interesse in der wissenschaftlichen Welt an der Unterstützung zeitversionierter Daten in Datenbanksystemen ^[64][65] als auch die eigenen Anforderungsanalysen zu Beginn des AIM-P-Projekts haben zum Entschluss geführt, die Unterstützung temporaler Daten von Anfang an beim Systementwurf mit zu berücksichtigen.^[3][6] Besondere Anliegen hierbei waren, diese Unterstützung so zu realisieren, dass hierdurch

1. der Zugriff auf die aktuellen Daten nicht verlangsamt wird
2. die Speicherung der Historie in kompakter Form erfolgen kann

Diese beiden Ziele wurden durch eine Separierung der aktuellen von den historischen Daten erreicht; und zwar auf Ebene der Speicherung von Datensätzen aller Art. Es gibt zum einen die aktuellen Datensätze und einen Versions-Pool mit den historischen Daten, im AIM-P „History-Pool“ genannt. Für jeden aktuellen Datensatz, der mindestens einmal durch eine Update-Operation verändert wurde, gibt es im Index des History-Pools einen Eintrag mit seinem Datensatz-Identifier, der den Kopf einer rückwärtsverketteten Liste von zeitgestempelten History-Datensätzen repräsentiert, welche die in einer Transaktion durchgeführten Änderungen am Datensatz in kompakter Form (als „Delta“) speichern. Das Wiederherstellen des historischen Zustandes eines Datensatzes wie folgt: Man beginnt mit dem aktuellen Datensatz oder – falls dieser gelöscht wurde – mit seinem letzten vollständigen Eintrag im History-Pool und macht die durchgeführten Änderungen so lange mit den Delta-Datensätzen rückgängig, bis man den gewünschten Zeitpunkt erreicht hat. Diese History-Datensätze haben eine große Ähnlichkeit zu den sog. „Undo-Log-Records“ ^[66], welche in den Datenbanksystemen zum Zurücksetzen von Änderung beim Abbruch von Transaktionen verwendet werden. Im Gegensatz den Undo-Datensätzen können diese Listen zum einen beliebig lang werden und weisen zum andern zwischendurch immer wieder eingestreute Vollversionen des Datensatzes auf, um die Rekonstruktion nicht immer ganz von vorne beginnen zu müssen.^[6][7]

Abb. 17 illustriert die Speicherung von zeitversionierten Daten in AIM-P. Der erste aktuelle Datensatz hat noch keine Updates erfahren, deshalb gibt es für ihn noch keinen Eintrag im Index des History-Pools. Der zweite aktuelle Datensatz wurde mit drei Update-Transaktionen verändert und hat deshalb 3 Delta-Einträge im History-Pool. Der dritte aktuelle Datensatz zeigt den Umgang mit langen Delta-Ketten. Hier kommt anstelle des ersten Delta-Eintrags ein spezieller Delta-Index, der direkt auf zwischendurch angelegte Vollversionen verweist. Alle diese Einträge sind mit den Zeitstempeln der jeweiligen Update-Transaktion versehen, so dass man ggf. erst bei der passenden Vollversion mit der Rekonstruktion des historischen Datensatzes beginnt.

Auf HDBL-Ebene wurde der Zugriff auf eine historische Version der Datensätze durch den Zusatz „ASOF <datumsangabe>“ im der FROM-Klausel realisiert. Diese Zeitangabe wurde vom Query Processor via Complex Object Manager an den Subtuple Manager durchgereicht, der den gewünschten Datensatz zum gewüschten Zeitpunkt (falls vorhanden) wie einen ganz normalen Datensatz im Systempuffer bereitstellte.

Bereits zu Beginn des AIM-P-Projektes war abzusehen, dass die CAD-Anwendungen, die in den Unternehmen bis dahin – wie z.B. CATIA – sehr häufig auf Großrechnern (den sog. Mainframes) installiert und betrieben wurden, im Laufe der Zeit mehr und mehr auf Workstations verlagert werden. Der Grund hierfür ist relativ klar: In CAD-Anwendungen müssen häufig sehr rechenintensive Operationen durchgeführt werden und – außer dem Laden des CAD-Objekts – sollten während der Arbeit an den CAD-Modellen möglichst wenige Datei- oder Datenbankzugrifffe durchführt werden müssen, um den Anwendern ein zügiges Arbeiten zu ermöglichen. Werden solche Anwendungen auf Mainframes im typischen Timesharing-Betrieb ausgeführt, dann stellt dies hohe Anforderungen an deren Prozessorleistung und Hauptspeicherausstattung, was sich dann in entsprechend hohen Kosten für diese Systeme niederschlägt. Allerdings war auch absehbar, dass man die CAD-Anwendungen nicht einfach vom Mainframe auf viele Workstations verteilen und die sichere Speicherung der z.T. sehr aufwendigen und kostspieligen CAD-Modelle und sonstigen wertvollen Daten, die Koordination des Zugriffs auf gemeinsam benötigte Daten sowie deren Konsistenthaltung alleine den einzelnen Anwendern überlassen kann. Es war daher ebenfalls absehbar (und ist dann auch genau so gekommen), dass man die Speicherung der Metadaten, Querverweise und ergänzenden Dokumenten zum CAD-Modell in einem relationalen Datenbanksystem vornehmen und das CAD-Modell selbst als „black box“ in einem „langen Feld“ (in SQL:1999 BLOB ("binary large object) genannt ^[25]) oder als Datei im Dateisystem des Servers im proprietären Datenformat des Herstellers der CAD-Software speichern würde. Diese Art der Speicherung ist zwar aus Performanzgründen vorteilhaft, hat aber zur Folge, dass selbst bei geringfügigen Änderungen am CAD-Modell diese „black box“ zur Bearbeitiung auf die Workstation geladen und anschließend auf den Server zurück übertragen werden muss.

Ende 1985 war AIM-P in einer lauffähigen Version mit Transaction-Oriented Workspace, Unterstützung von Zeitversionen ^[6][7][5], einer Benutzerschnittstelle sowie einer Anwendungsprogramm-Schnittstelle (API) ^[39] verfügbar. Man konnte daher das nächste wichtige Ziel, die Evaluierung und ggf. Weiterentwicklung der erabeiteten Konzepte sowie die Erarbeitung von besseren Lösungen für das Zusammenspiel der Workstations mit AIM-P als Server-Datenbank in Angriff nehmen ^[5][67].

Mit dem Institut für Prozessrechentechnik und Robotik (IPR) und dem Lehrstuhl für Systeme der Informationsverwaltung der Universität Karlsruhe (heute: KIT Karlsruhe) wurden hierfür die passenden Partner gefunden und 1986 mit diesen das Kopperationsprojekt R²D² – „A Relational Robotics Database System with Extensible Data Types“ gestartet. - Da passte es sehr gut, dass die IBM Deutschland und die Universität Karlsruhe im Jahr 1984 das Kooperations-Projekt HECTOR – „Heterogeneous Computers Together“ ^[68] gestartet hatten und das R²D²-Projekt 1986 dort eingebracht und finanziert werden konnte.

Das Institut für Prozessrechentechnik und Robotik brachte seine langjährige F&E-Erfahrung im Bereich Computer Integrated Manufactuing (CIM) ein. Ziel der dortigen Forschungsarbeiten war u.a. Fertigungszellen mit miteinander kooperativ zusammenarbeitenden Robotern und Transportmittel jeder Art zur Durchführung der gewünschten Aufgabe digital am Computer zu modellieren, programmieren und deren Aktionen und Interaktionen zu simulieren.^[69][70] Hierzu reicht es dann nicht mehr aus die Roboter, Transportmittel, Werkzeugmaschinen etc. nur als CAD-Objekte zu modellieren, sondern man muss auch deren kinematische Eigenschaften kennen und die hierzu erforderlichen Daten für die diversen Berechnungen im 3D-Raum, wie z.B. Bahnkurven der Roboter-Arme und Kollisionserkennung zur Verfügung haben ^[47]. - Es bietet sich natürlich an, diese Daten in einer dafür gemeinsamen Datenbasis so zu speichern, dass alle CAx-Anwendungen darauf aufsetzen können. Dieses auf Basis von AIM-P mit seinem eNF²-Datenmodell zu erproben, war natürlich auch für das Institut sehr interessant; und zwar insbesondere auch deshalb, da sie durch das von Ihnen am Institut entwickelte Roboter-Simulations-System ROSI ^[71] bereits über entsprechende Implementierungserfahrungen verfügten.

Der Lehrstuhl für Systeme der Informationsverwaltung fungierte quasi als Mittler zwischen dem AIM-P-Team und den CIM-Experten. Sie arbeiteten sich in die datentechnischen und algorithmischen Problemstellungen im CIM-Bereich ein ^[50] und brachten dieses und ihr Datenbank- und Programmiersprachen-Knowhow für die Definition der hierfür passenden benutzerdefinierten Datentypen und Funktionen sowie das Zusammenspiel zwischen Workstation und Datenbankserver ein ^{[72][73][74][75]}.

Für viele Phasen der Entstehung eines neuen Produkts und dessen Herstellung gab es bereits Mitte der 1980er Jahre schon mächtige Werkzeuge für die graphische Konstruktion mittels CAD, für die Planung des Herstellprozesses mittels CAM und die Produktionsplanung und Steuerung mittels PPS. Allerdings waren dies im Wesentlichen „stand-alone“-Anwendungen mit ihren eigenen Datenbasen. Mangels (zu dieser Zeit) geeigneten Datenformaten für den Export und Import von bzw. in andere Systeme mussten diese oft jeweils händisch eingepflegt oder nachbearbeitet werden (siehe z.B. CAD – Exportieren in ein anderes Dateiformat). - Für CIM-Anwendungen ist typisch, dass ein und dieselben Daten von verschiedenen Anwendungen benötigt werden. Wenn diese Anwendungen jedoch erfordern, dass diese Daten jeweils in ihrer eigenen Datenbasis vorhanden sind, dann kommen diese natürlich mehrfach in verschiedenen Datenbasen vor. Eine solche, redundante Speicherung birgt die große Gefahr von Inkonsistenzen mit sich, z.B. infolge unterschiedlicher Aktualitätsniveaus oder fehlerhafter Datenübernahmen aus anderen Datenbasen. Mit einer von allen Anwendungen gemeinsam genutzten Datenbank (wie in Abb. 18 illustriert) könnte man diese Probleme vermieden. Das eNF²-Datenmodell und dessen Umsetzung im AIM-P-System war genau hierauf ausgerichtet: Die Speicherung und den Zugriff (auch) auf komplex-strukturierte Datenobjekte war so realisiert, dass sowohl Anwendungen, die ein solches Objekt als Ganzes als auch solche, die nur Teile davon benötigen dies performant tun können. Mit anwendungsbezognenen, maßgeschneiderten Sichten können zudem Daten „aus den Tiefen“ solcher Objekte den Anwendungen bei Bedarf auch als 1NF-Relationen angeboten werden.

Das R²D²-Projekt startete mit Analysen verschiedener CIM-Anwendungen um zu lernen, welche Arten von Daten diese jeweils benötigen, welche Auswertungen damit gemacht, welche Algorithmen hierfür verwendet werden und wie sich diese Anforderungen in AIM-P strukturell und operationell umsetzen lassen ^{[47][50][77][78][79][80]}. Die Erkenntnisse aus diesen Analysen sowie den bereits zuvor gemachten Erfahrungen flossen in die Realisierung der Benutzerdefinierte Datentypen und Funktionen und der Workstation–AIM-P-Server–Kooperation ein.

Die 1984 von Michael Stonebraker et al.^[81] publizierte Idee, die relationalen Datenbanksysteme mit benutzerdefinierten Typen und Funktionen zu erweitern, inspirierte auch das AIM-P-Entwicklungsteam ^[5]. Im dem von Stonebraker vorgestellten Ansatz wird ein atomarer Datentyp als Basis für einen Abstrakten Datentyp mit benutzerdefinierten Funktionen benutzt. Da dieser Ansatz letztlich in den SQL-Standard SQL:1999 aufgenommen wurde und auch in diesem Beitrag noch eine Rolle spielen wird, soll kurz beschrieben werden, wie er funktioniert.

Es geht bei diesen abstrakten Datentypen darum, eine „nicht-atomare“ Datenstruktur, so in ein atomares Attribut einer 1NF-Relation hineinzupacken und mit darauf zugeschnittnen Funktionen zu versehen, dass mit diesem Attribut auf der SQL-Ebene (fast) wie mit einem normalen Attribut umgegangen werden kann. Angenommen, wir möchten das 2D-Objekt „Linie“ als Datentyp einführen, und es auf der Speicherungsebene durch seine zwei Endpunkte (x1,y1) und (x2,y2) repräsentieren. Als Funktion wollen wir u.a. „get_lineGetLength() returns real“ definieren, die uns – angewandt auf dieses „abstrakte“ Attribut die Länge der Linie als atomaren Wert zurückliefert. Für die x- und y-Komponenten könnten wir jeweils einen Integer-Datentyp mit 16 Bits nehmen und diese 4 Werte als aufeinanderfolgende Bits in einen Long-Integer-Datentyp mit 64 Bits speichern. Die Funktion get_lineGetLength müsste nach einander jeweils 16-Bit-Folgen aus diesem Long-Integer extrahieren und diese als Integer-Wert für x1, die nächsten als Integer-Wert für y1 usw. extrahieren und könnte dann mit diesen Werten die gewünschte Länge berechen und als Funktionswert zurückgeben. Möchte man jedoch komplexere Dinge darstellen, dann benötigt man mehr Bits für die interne Repräsentation und dies führt dann in der Folge auch aufwendigeren Implementierungen für die gewünschten Funktionen. Bleiben wir der Einfachheit halber bei unserem Beispiel und schauen uns eine andere interne Abbildung unserer Linie an; und zwar als Zeichenkette. Eine solche Zeichenkette könnte auf der Speicherungsebene z.B. wie folgt aussehen: „(13,29) (25,48)“. In diesem Fall müsste unsere get_lineGetLength-Funktion diese Zeichenkette zerlegen (parsen), die Teilstrings „13“, „7“, „25“ und „48“ extrahieren und in numerische Werte für die gewünschte Berechnung umwandeln.

Für komplexere Objekte verwendet man heute als Basisdatentypen lange Binärstrings vom CLOB (Character Large Object) oder BLOB (Binaray Large Object) für Binärdaten. Die Serialisierung von komplexen Datenstrukturen in eine lineare Speicherdarstellung sowie die Implementierung von Funktionen und Prozeduren, die auf diesen Strukturen arbeiten, macht man heute in einer passenden höheren Programmiersprache wie z.B. Java. Wenn dann z.B. auf Seiten des Anwendungsprogramms dieselbe Programmiersprache verwendet wird, kann man das komplexe Objekt auch direkt als Ganzes an das Anwendungsprogramm übergeben bzw. vom diesem übernommen werden. Beispiele hierzu finden sich in vielen Datenbanklehrbüchern, wie z.B. _^[25] sowie in _^[82] und _^[83].

HDBL wurde im Rahmen des R²D²-Projekts so erweitert, dass alle im eNF²-Datenmodell zulässigen atomaren und konstruierten Datentypen auch für einen benutzerdefinierten Datentyp verwendet werden können. D.h. alle diese Datentypen können sowohl für die Deklaration der internen Struktur als auch für die Aufrufparameter und den Rückgabewert der benutzerdefinierten Funktionen verwendet werden. Als Anwendungsbeispiel erweitern wir unser obiges Beispiel von einer einfachen Linie zu einem (beliebig langen) Polygonzug. Die Typdeklarationen und der Funktionsaufruf zur Bestimmung der Länge könnten dann in HDBL im Prinzip wie in Abb. 19 skizziert aussehen (die eckigen Klammern in dieser Abbildung sind Konstruktoren für Tupel und die spitzen Klammern für Liste).

Wenn man nichts anderes festlegt, dann sind die mittels TYPE-Anweisung deklarierten Strukturen „offen“, d.h. auf alle deren Strukturelemente kann in HDBL-Anweisungen so zugegriffen werden, also ob diese direkt „inline“ bei der CREATE-Anweisung für das Objekt festgelegt worden wären. Will man dies nicht haben, z.B. weil gewisse Elemente von Attributen auf der SQL-Ebene nicht detailliert dargestellt werden sollen oder man z.B. anstatt der numerischen eine graphische Darstellung des CAD-Objekts haben möchte oder wenn Updates nur mittels objektbezogener Prozeduren erfolgen sollen, so kann man in HDBL Typen „kapseln“ (ähnlich dem Konzept der „versteckten Typen“ in Modula-2). Dies geschieht, in dem man die DECLARE-TYPE -Anweisung mit dem Schlüsselwort ENC versieht. Wenn man z.B. die TYPE-Deklaration für Polygon mit ENC versieht, dann würde HDBL den Inhalt dieses Attributs nicht ausgeben und würde auch keine gewöhnliche HDBL-UPDATE-Anweisung auf einem Objekt dieses Typs unterstützen. Einen inhaltlichen Zugriff auf Objekte dieses Typs haben dann nur Funktionen oder Prozeduren, die dieses Objekt per Aufrufparameter diesen Typs übergeben bekommen.- In AIM-P wurde dies z.B. benutzt, um bei Demos anstatt der „numerischen“ Darstellung von Roboterm eine graphische Darstellung von ihnen auszugeben. (Im Online-Interface von AIM-P war eine solche Ausgabemöglichkeit vorgesehen.) Um auch die „numerische“ Darstellung auf Wunsch anzeigen zu können, wurde eine zweite Funktion deklariert, die als Return-Wert das Objekt „as is“ zurückgegeben hat.

Wie bei SQL mussten auch in HDBL bzw. AIM-P die benutzerdefinierten Funktionen mit Hilfe einer Programmiersprache implementiert werden. Im Fall von HDBL war dies die sehr mächtige Pascal-Version von IBM für VM/CMS, in der auch AIM-P selbst implementiert wurde. Jeder in HDBL deklarierbare benutzerdefinierte Datentyp – und sei er auch noch so komplex strukturiert – benötigt eine Abbildung in eine in gewisser Weise „äquivalente“ Datenstruktur der Programmiersprache, in Fall von AIM-P also Pascal. Da es für viele HDBL-Konstrukte im Prinzip mehrere „äquivalente“ Programiersprachen-Datenstrukturen gibt, erzeugte der Datentyp-Code-Generator ggf. mehrere alternative Datenstrukturen – in R²D² „User customized PASCAL structures“ genannt ^[84] – aus denen die Anwender die für ihren Anwendungszweck passende wählen konnte. Diese (ggf. alternativen) Programmiersprachen-Datenstrukturen wurden und im Datenbank-Katalog ergänzend zur eNF²-Struktur und den sonstigen Angaben gespeichert ^[84]. Für die Implementierung der benutzerdefinierten Funktion konnte man diese damit direkt (z.B. per „copy & paste“) in den Quellcode übernehmen. Da die Generierung systemseitig vorgenommen wurde, funktionierte auch die umgekehrte Richtung, d.h. beim Übertragen der Daten vom Anwendungsprogramm in die AIM-P-Datenbank. - Eine relativ detailliert und lesenswerte Beschreibung der system-internen Realisierung und Diskussion anderer Ansätze findet sich in _^[84].

Beim SQL-Ansatz läuft es bei Änderungsoperationen am komplexen Objekt in der Regel darauf hinaus, dass dieses komplett in die passende Datenstruktur im Anwendungsprogramm geladen, dort dann verändert und dann wieder in Datenbank zurückgeschrieben werden muss. Beim HDBL-Ansatz ist die Struktur des komplexen Objekts der Anfragebearbeitungskomponente des DBMS bekannt. D.h. man kann den Pfad zu dem zu ändernden Teil des Objektes in der Update-Anweisung angeben und dieses dann „minimal-invasiv“ ändern. Hat man z.B. modular aufgebaute Roboter-Typen, bei denen Arme hinzugefügt oder entfernt werden können, dann würde es sich anbieten, für den Arm einen eigenen Datentyp zu deklarieren und diesen bei der Deklaration der Roboter-Tabelle zu verwenden. In diesen Fall kann man dann unter Verwendung dieses Typs eine Variable vom Typ 'Arm' im Anwendungsprogramm mit allen seinen Werten befüllen und dann mittels INSERT-Anweisung quasi en bloc dem betroffenen Roboter zuzuweisen.

Im eingangs erwähnten XSQL-Forschungsprojekt am IBM Research Laboratory in San Jose entwarf man auch Konzepte für das „Ausleihen“ von „complex objects“ zu deren Bearbeitung („check-out“), für deren „Rückgabe“ nach vollzogener Bearbeitung („check-in“) sowie die Unterstützung „langer Transaktionen“ ^[26]. Diese Konzepte lieferten auch wertvolle Anregungen für den Entwurf und die Realisierung der Systemarchitektur von AIM-P, wo man anstrebte systemseitig möglichst viele Dinge so zu realisieren, dass sie anschließend mehreren Zwecken dienen können. Der oben beschriebene Transaction-Oriented Workspace (TWS) wurde so konzipiert, dass er nicht nur für die Unterstützung der Zeitversionen, sondern auch für lange Transaktionen, das Sichern von Zwischenzuständen dieser Transaktionen sowie zum persistenten Speichern der von ihnen gesetzten Sperren genutzt werden konnte. Die Zeitversionen in Verbindung mit dem TWS machten es wiederum möglich, dass Nur-Lese-Transaktionen ohne zusätzlichen Mehraufwand gut unterstützt werden konnten.

Dass ein eNF²-basiertes Datenbanksystem sehr gut geeignet ist CIM-Daten adäquat strukturiert zu speichern, war eigentlich bereits beim Start des R²D²-Projekts erwartet worden und wurde während der anfangs durchgeführten Anforderungsanalysen auch bestätigt.^[38][77] Insbesondere durch CAD und Robotik kamen jedoch auch neue Aspekte bzw. Anforderungen hinzu. So nimmt man bei der CAD-Konstruktion gerne ein topologisch ähnliches Modell als Ausgangsbasis und passt dieses an die neuen Anforderungen an ^[85][86][87]. Wenn man dann irgendwann einmal hunderte oder tausende von CAD-Objekten in der Datenbank gespeichert hat und die Meta-Daten für die konkrete Suche zu unspezifisch sind, dann könnte es sinnvoll sein hierfür objekttyp-spezifische Suchfunktionen mittels benutzerdefinierter Datentypen und Funktionen zu implementieren, die dann als Prädikate in HDBL-Anfragen zur Verfügung stehen. Ähnliches gilt, wenn man für die Planung einer neuen Fertigungszelle die Datenbank nach Robotern durchsuchen möchte, die gewisse Bewegungen bzw. Bahnkurven ausführen können. Wenn für die Auswertung solcher Prädikate jeweils nur ein kleiner Teil des Gesamtobjekts benötigt wird und die benutzerdefinierten Datentypen dazu passend gewählt werden, dann würde AIM-P – im Gegensatz zu den relationalen DBMS mit ihrem SQL-ADT-Ansatz (siehe SQL – HDBL – Vergleich oben) – bei der Anfragebearbeitung nicht die ganzen Objekte, sondern nur deren datentyp- bzw. prädikat-bezogene Teile laden und auswerten. - Die oben beschriebene Erweiterung von HDBL um benutzerdefinierte Datentypen und Funktionen diente genau diesen Zweck.

Die mit CAD-Programmen arbeitenden Konstrukteure von Werkzeugen und Maschinen erwarten von diesem Programm (wie z.B. CATIA) eine graphische Oberfläche mit 2D/3D-Darstellungsmöglichkeit in der ihnen u.a. ein Katalog mit Basisobjekten, wie z.B. Quader, Zylinder, Kugel, Kegel usw. angeboten wird, aus dem sie das benötigte Basisobjekt auswählen und daraufhin eine Liste der möglicher Aktionen, wie z.B. Positionierung im 2D/3D-Raum, Rotation, Translation, Skalierung usw für dieses angeboten bekommen. Mit Hilfe dieser Basisobjekte oder bereits konstruierter Objekte können sie neue Objekte konstruieren und oder vorhandene weiterentwickeln. Vieles geschieht rein graphisch interaktiv, gelegentlich müssen aber auch Vektoren oder Matrizen editiert werden, um gewisse Eigenschaften oder Verhaltensweisen von Objekten exakt festzulegen. Ähnlich verhält es sich bei der Programmierung von Robotern, wo mit den als CAD-Modell vorliegenden Robotern interaktiv-graphisch die für die gewünschte Aufgabe erforderlichen Armbewegungen ausgeführt und entsprechender Programmcode für den Roboter erzeugt wird.^[70][88][89]

Datenbankseitig bietet es sich an für alle möglichen Basis-Objekttypen, wie z.B. Quader, Zylinder, Kegel, Kugeln usw., anwendungsbezogene Datentypen und Funktionen für die jeweilige Domäne zu definieren. Dies können z.B. Funktionen für die Manipulation dieser Objekte (wie z.B. deren Position im 3D-Raum, Größenänderung, Rotation usw.) oder Filter für Suchoperationen sein. Für Robotik-Anwendungen könnte man z.B. den häufig verwendeten Datentyp DH-Matrix mittels „User customized PASCAL structures“ als Array[0..3,0..3] : REAL und darauf definierte Funktionen wie z.B. die „Multiplikation zweier DH-Matrixen“ realisieren.

1. Realisierung einer zentralen CIM-Datenbank mit AIM-P als Datenbankserver, in der u.a. auch CAD-Modelle in strukturierter Form (d.h. nicht als „black box“) mit darauf abgestimmten anwendungsspezifischen Datentypen und Funktionen gespeichert werden können
2. Laden von ausgewählten CAD-Modellen vom AIM-P-Server auf die Workstation in einer Form, die dort eine hochperformante Bearbeitung dieser Modelle ermöglicht
3. Unterstützung von „langen Transaktionen“ mit „Check-out“- und „Check-in“-Funktion und Langzeit-Sperren auf dem Datenbankserver
4. Speicherung von Zwischenergebnissen und zeitversionierte Speicherung der geänderten CAD-Modelle beim „check-in“ auf dem Datenbankserver

Der im R²D²-Projekt entwickelte „Object Cache“ ist eine Art von In-Memory-Datenbank auf der Workstation, die eine exakte Kopie eines eNF²-Datenobjekts vom AIM-P-Datenbankserver (mit exakt denselben Mini-Directory-Datenstrukturen wie dort), zusammen mit darauf zugeschnittenen Zugriffsfunktionen sowie den anwendungsbezogenen (benutzerdefinierten) Datentypen und Funktionen aufnehmen und für die Implementierung einer CAD-Software verwendet werden kann. Als Studienobjekt einer solchen Software stand dem R²D²-Projekt das am Institut für Prozessrechentechnik und Robotik entwickelte Robot Simulation System ROSI zur Verfügung.^[48][90]

Das Resultat einer gewöhnlichen HDBL-Anfrage ist ein Resultat-eNF²-Objekt, das in einem temporären Datenbank-Segment gespeichert wird. Für dieses Resultat-Objekt werden dieselbe Art von internen Datenstrukturen wie in der AIKM-P-Datenbank verwendet und man benötigt deshalb auch einen (in diesem Fall temporären) Eintrag im Datenbank-Katalog, damit das Resultat-Objekt überhaupt in sinnvoller Form an die Anwendung übergeben werden kann (Abschnitt Catalog Manager für Details hierzu). Dies gilt auch dann wenn ein ganzes eNF²-Objekt „as is“ als HDBL-Anfrageergebnis ausgegeben werden soll. In diesem Fall sind der erzeugte temporäre und der korrespondiere Original-Katalog sowie die Datenstrukturen und deren Inhalte des Orignal-eNF²-Datenobjekts und des als Kopie erzeugten Resultats-Objekts i.W. fast identisch. Sie unterscheiden sich nur in den in beiden Katalogzügen (Satzadresse der „Wurzel“ des eNF²-Objekts) sowie in den in den beiden Mini-Directories hinterlegten Satzadressen. Beim Original-Objekt beziehen sich diese auf die AIM-P-Datenbank, während sie sich beim Result-Objekt auf das temporäre Datenbank-Segment beziehen.^[31][32]

Der „Trick“ war nun, beim „Check-out“ eines solchen Objects für dieses zwar im Prinzip in gewohnter Weise ein Resultat-Objekt anzulegen, sich aber zusätzlich zu jedem Datensatz auch seine Original-Satzadressen in AIM-P-Datenbank zu merken und diese Information in einer Art von „Adress-Umsetzungstabelle“ zu speichern. Das Resultat-Objekt zusammen mit seinem Katalogeintrag samt den für diesen Objekttyp hinterlegten benutzerdefinierten Datentypen und Funktionen, dieser Adress-Umsetzungstabelle und evtl. noch benötigten Basisobjekten wurden an die Workstation übertragen und in deren Hauptspeicher-Datenbank übernommen. Abb. 20 illustriert das Zusammenspiel der verschiedenen Komponenten.

Mit dieser Vorgehensweise wurden die Anforderungen 1 und 2 aus der obigen Liste der Herausforderungen und die Anforderung 3 durch den Transaction-Oriented Workspace (TWS) des AIM-P-Datenbankservers erfüllt. Zur Erfüllung der Anforderung 4 war es notwendig, jedwede Änderung an den im Object Cache liegenden Objekten hinsichtlich der Art der Änderung (Einfügen, Löschen, Update), wo und auf welcher Objekt-Ebene sie stattfand und den Zustand vor und nach der Änderung in geeigneter Form im Object Cache festzuhalten. Hierzu wurde auf Basis der Subkomponente Result Walk des Complex Object Managers ein spezielles Konzept für geeignete Markierungen („multi-level flagging“ in _^[31] genannt) entwickelt, das den hierfür zu treibenden Aufwand relativ klein hält. (Eine relativ ausführliche Beschreibung hierzu findet sich in _^[31]). Mit Hilfe dieser Maßnahmen war es möglich, sowohl bei den gewünschten Zwischenspeicherungen als auch bei der Rückübertragung („Check-in“) die Änderungen gezielt in kompakter Form als Undo- und Redo-Einträge zu übertragen, die dann auf dem AIM-P-Server dann auch gleich für die Erzeugung der Datensätze für die zeitversionierte Speicherung genutzt werden konnten.

Dass das NF²/ eNF²-Datenmodell eine adäquate Basis für viele Anwendungsbereiche und gegenüber dem 1NF-Relationenmodell eine ganz erhebliche Verbesserung darstellt war, wie bereits am Anfang dieses Beitrags erwähnt, auch schon weltweit in vielen Projekten erkannt und belegt worden. Durch das R²D²-Projekt konnte dieses Datenmodell und HDBL mit den realen Implementierungen der vollumfänglich darauf basierenden benutzerdefinierten Datentypen und Funktionen jedoch nochmals auf eine wesentlich höhere Ebene gehoben und als „Gesamtpaket“ evaluiert werden.^{[80][92][93][94][95][96][97]}

Während diese Ergebnisse aufgrund der konzeptionellen Vorüberlegungen vielleicht in gewisser Weise fast noch „erwartbar“ waren, war zu Beginn des R²D²-Projekts überhaupt noch nicht absehbar wie gut es gelingen würde, die zwei sich eigentlich widersprechenden Ansätze CIM-Datenbank als zentraler Speicher für alle Arten von -Anwendungenmit und der damit verbundenen Forderung nach einer möglichst feingranularen Speicherung der Daten mit den Anforderungen einer hochperformanten CAD-Modellierung auf der Workstation in Verbindung mit der üblichen „en bloc“-Speicherung des CAD-Modells unter einen Hut zu bringen. - Mit dem Object Cache in Verbindung mit der dazu passenden Speicherung der eNF^2-Objekte auf dem AIM-P-Datenbankserver konnte eindrucksvoll gezeigt werden, dass dies tatsächlich gelingen kann – vorausgesetzt, das Datenbanksystem und dessen Datenmodell sind für hierfür geeignet und ausgelegt.^{[91][98][99][100]}

Wie Internet-Recherchen mit Stichworten wie „NF2-Relationen“, „geschachtelte Relationen“, „nested relations“ etc. zeigen, war diese Thematik – wie in den einleitenden Abschnitten oben ausgeführt – ab Ende der 1980er / Anfang der 1990er Jahre sowohl im wissenschaftlichen Bereich als auch im kommerziellen Bereich weit verbreitet, siehe hierzu z.B. die Schlagzeilen der Computerwoche vom 26. Mai 1989 „NF2-Datenmodell ermöglicht flexiblere Datenstrukturierung“ ^[35.1] und von Computer Weekly vom 16. März 1989 „IBM Returns to the DB2 drawing board“ ^[35.1]. Dem entsprechend befasste sich natürlich auch das ISO-ANSI-Standardisierungsgremium ^[101] – dem u. a. auch ein Mitarbeiter des ehemaligen AIM-P-Teams angehörte – bei der Diskussion des nächsten SQL-Standards (damals als SQL3 bezeichnet ) mit diesem Thema. Von den zum Teil sehr heftigen und kontroversen Diskussionen im Verlauf des Standardisierungsprodrang drang leider nur wenig in Form von zitierfähigen Veröffentlichungen nach außen.

Eine der wenigen Quellen stammt von Jim Melton, dem Editor aller SQL-Standard seit SQL 92, der in seinem Buch „Advanced SQL:1999 – Understanding Object-Relational and Other Advanced Features“ ^[82]. Er berichtet hier auf Seite 527, dass die Integration von Objekt-Technologie in SQL sich sowohl in technischer als auch in politischer Hinsicht als sehr viel schwieriger herausstellte, als irgendjemand erwartet hatte und dass infolge dessen der auf SQL 92 folgende Standard nicht nach drei, sondern erst nach 7 Jahren fertiggestellt wurde und noch sehr wenig mit eNF²-Bezug enthielt. Dies kam dann erst 4 Jahre später mit SQL:2003, weshalb wir uns im Folgenden – sofern nicht anders gesagt wird – auf diesen SQL-Standard beziehen. - Einen Einblick in die Natur dieser Diskussionen gewährt auch R. Camps, der seine Publikation ^[102] zu diesem Thema mit „Domains, Relations and Religious Wars“ betitelte.

Ein Standard dient ja eigentlich dazu wesentliche Eigenschaften eines Produkts zu definieren, welche die Hersteller einhalten müssen, wenn sie „standard-konform" sein möchten bzw. müssen. Jim Melton berichtet dazu im oben erwähnten Buch ^[82] auf Seite 18, dass Oracle und IBM unterschiedliche Teile der Objektfunktionen von SQL:1999 implementiert haben. Oracle hat seiner Beobachtung nach den Schwerpunkt auf die Verwendung benutzerdefinierter Datentypen als Zeilen typisierter Tabellen gelegt, während IBM eher dazu neigt, benutzerdefinierte Typen als Zeilen von Spaltentypen in gewöhnlichen Tabellen zu verwenden. – Sybase wiederum konzentriert sich auf die Verwendung von Java als Grundlage seiner objektrelationalen Strategie.

Im Folgenden werden Attribute, die mittels benutzerdefiniertem Datentyp in Verbindung mit darauf definierten Funktionen realisiert wurden, kurz als ADT-Attribute bezeichnen.

Egal, wie man es dreht und wendet, das Ergebnis einer SQL-Anfrage muss entweder eine 1NF-Relation mit atomaren Werten sein oder man muss diese – in eine systemgenerierte Datenstruktur „verpackt“ – mittels Anwendungsprogrammschnittstelle (API) an eine Anwendung übergeben. Ansonsten kann ein ADT-Attribut nur durch den Aufruf einer für diesen ADT definierten Funktion, die einen atomaren Wert zurückliefert, in der Liste der Attributliste der 1NF-Resultat-Relation vertreten sein. - Selbst im Fall des Datenbanksystems Oracle, von geschachtelte Relationen angelegt werden können, können diese Subtabellen in der Ergebnis-Relation nicht einfach mit ausgegeben werden, sondern müssen hierfür „entschachtelt“ werden.

Nachfolgend ein paar Beispiele zur Veranschaulichung. Hierfür nehmen wir hierfür an, dass die in Abb. 7 dargestellte RobotNF2-Relation in einer SQL:2003-Datenbank als Robots1NF-Relation wie in Abb. 21 dargestellt angelegt worden ist. Die Attribute RobID und Rob_Descr sind wieder vom Typ, 'Arms' und 'Endeffectors' hingegen als abstrakte Datentypen namens ArmsADT und EndeffectorsADT angelegt worden.

In den nachfolgenden Beispielen beziehen sich die HDBL-Anfragen auf die RobotsNF2- und die SQL-Anfragen auf die Robots1NF-Relation.

Beispiel SQL-ADT-1: Realisierung einer Existenzbedingung in HDBL und in SQL

Aufgabe: „Gib von allen Robotern, die den Endeffektor SR200 anschließen können, die Atttribute RobID und Rob_Descr aus“

In HDBL kann man die Anfrage direkt mittels Standard-EXISTS-Prädikat auf dem Attribut EndEffectors ausdrücken. In SQL hingegen muss hierfür zuvor eine benutzerdefinierte Funktion, wie z.B. EndEff_Exists(vergleichswert), für diesen ADT deklariert und implementiert werden, die den Vergleichswert als Eingabeparameter übergeben bekommt und z.B. TRUE oder FALSE als Vergleichsergebnis zurückliefert. Abb. 22 zeigt diese beiden Anfragen im Vergleich. dargestellt.

Beispiel SQL-ADT-2: Ausgabe berechnen und Ausgeben der Kardinalität eines mengenwertigen Attributs

Aufgabe: „Gib von allen Robotern neben RobID und Rob_Descr auch noch die Anzahl ihrer Arme aus.“

In HDBL kann man hierfür die Standard-Funktion CARD verwenden ^[53], welche die Kardinalität einer Menge bestimmt. In SQL muss man hierfür wieder zuvor eine geeignete benutzerdefinierte Funktion, wie z.B. anzArms() für diesen ADT deklariert und implementiert werden, die den gewünschten numerischen Wert zurückliefert. Abb. 23 zeigt wieder beide Anfragevarianten im Vergleich.

Beispiel SQL-ADT-3: Ausgabe eines mengenwertigen Attributs in der Ergebnis-Relation

Aufgabe: „Gib von allen Robotern neben RobID und Rob_Descr auch ihre Endeffektoren als Ergebnistabelle aus.“

Nehmen wir zur Vereinfachung der Aufgabe für SQL an, dass dort (was in SQL:1999 nicht ging – und evtl. bis heute noch nicht geht) im EndeffectorsADT-Attribut die Endeffectors als Multiset von Tupeln mit den Attributen Eff_ID und Function realisiert wurde.

In HDBL ist diese Aufgabe trival lösbar: Wir müssen hierfür in der SELECT-Zeile lediglich das Attribut 'Endeffectors' mit aufführen. In SQL muss die Multiset-Tabelle in eine 1NF-Struktur „entschachtelt“ werden, wofür es in der NF²-Relationenalgebra und in SQL:2003 den UNNEST-Operator ^[28][25] gibt. Dieser Operator bewirkt einen JOIN der 1NF-Relation mit den Elementen ihrer eingeschachtelten Tabelle dergestalt, dass – falls das Multiset z.B. 3 Einträge hat, aus einem 1NF-Tupel anschließend 3 1NF-Tupel geworden sind, die sich nur durch die Attributwerte der Multiset-Tabelle unterscheiden.

Abb. 24 zeigt wieder für beide Anfrage-Varianten wie diese im Prinzip aussehen könnten und Abb. 25 die Ergebnis-Relation der SQL-Anfrage.

Und wenn die Aufgabe gelautet hätte, die gesamte Robot1NF-Relation in lesbarer Form auszugeben, dann müsste dieses „Entschachteln“ über alle Ebenen hinweg von „unten“ nach „oben“ durchführt werden und man würde, falls innerhalb des ADT dieselben Attributnamen wie in RobotNF2 in Abb. 7 verwendet wurden, dann wieder bei der in Abb. 5 dargestellten Tabelle landen.

Wenn man bedenkt, das die CAD-Objekte in der Realität extrem komplex und groß sein können (man denke da nur an einen Pkw, ein Flugzeug oder eine ganze Fertigungsstraße im Bereich CIM), dann sieht am bereits anhand dieser sehr einfachen Beispiele, dass die objekt-relationalen Erweiterungen von SQL auf Basis von 1NF-Relationen für die Unterstützung von wirklich komplexen Objekten – wie im Abschnitt Konventionelle relationale DBMS und das „Complex Object“-Problem) beschrieben, eigentlich untauglich sind,

Jim Melton hat am 5. Juni 2009 im online anhörbaren Software Engineering Radio Podcast hierzu (transkripiert mit speech-to-text.cloud) dazu das Folgende gesagt ^[103]:

„Well, I believe that the object-oriented SQL stuff was not a very big success. No vendor that I know of has implemented all of it. Oracle has implemented part of it, Sybase implemented part of it, IBM implemented part of it, and the parts all overlap. But the overlapping subset, the intersection of all of those subsets, is not big enough, I think, to build meaningful applications. Consequently, we didn’t get the uptake in the customer usage that we had hoped for. And it was extremely expensive to develop, so we learned a lot of lessons while we were doing that, and we are not ever again going to do anything that substantial, I hope. After SQL 1999 was published, we began working on a version that eventually was published as SQL 2003. SQL 2003 was, I think you could properly call it, a maintenance version of the standard. It fixed a tremendous number of bugs, and it added only a small number of new features. We just recently published, in fact, this year, in fact, SQL 2008, which was more than just a maintenance version. We added a number of new features, but nothing nearly as notable as object-oriented SQL. And we are currently working on the subsequent version of the standard, which we hope will be called SQL 2011, but it's possible it could slip into 2012. The truth is that a lot of people consider SQL to be done, that right now what we're doing is adding features that are more of interest to specific vendors or customers.“

Ins Deutsche übersetzt: "Nun, ich glaube, dass das Thema „objektorientiertes SQL“ kein allzu großer Erfolg war. Kein mir bekannter Anbieter hat das Ganze vollständig umgesetzt. Oracle hat einen Teil davon umgesetzt, Sybase hat einen Teil davon umgesetzt, IBM hat einen Teil davon umgesetzt und diese Teile überschneiden sich alle. Aber die sich überschneidende Teilmenge, die Schnittmenge all dieser Teilmengen, ist meiner Meinung nach nicht groß genug, um sinnvolle Anwendungen zu entwickeln. Folglich haben wir bei den Kunden nicht die Akzeptanz erreicht, die wir uns erhofft hatten. Und die Entwicklung war extrem teuer, also haben wir dabei viel gelernt, und ich hoffe, dass wir nie wieder etwas so Umfangreiches in Angriff nehmen werden. Nachdem SQL 1999 veröffentlicht worden war, begannen wir mit der Arbeit an einer Version, die schließlich als SQL 2003 veröffentlicht wurde. SQL 2003 war, wie man es wohl treffend bezeichnen könnte, eine Wartungsversion des Standards. Sie behob eine enorme Anzahl von Fehlern und fügte nur eine kleine Anzahl neuer Funktionen hinzu. Tatsächlich haben wir erst kürzlich, nämlich in diesem Jahr, SQL 2008 veröffentlicht, das mehr als nur eine Wartungsversion war. Wir haben eine Reihe neuer Funktionen hinzugefügt, aber nichts, was auch nur annähernd so bemerkenswert wäre wie objektorientiertes SQL. Und wir arbeiten derzeit an der nächsten Version des Standards, die hoffentlich SQL 2011 heißen wird, aber es ist möglich, dass sie sich bis 2012 verzögert. Die Wahrheit ist, dass viele Leute SQL als abgeschlossen betrachten und dass wir derzeit Funktionen hinzufügen, die eher für bestimmte Anbieter oder Kunden von Interesse sind."

Die Schilderung von Jim Melton deckt sich auch mit dem, was zu diesem Thema 1996 in der Computerwoche mit dem Beitrag „Die Konzepte von Informix, Oracle, Sybase, Software AG, CA und IBM: Objektrelationale Technik bereitet Herstellern Sorgen“ ^[104] geschrieben wurde, der auf das sehr uneinheitliche Vorgehen der Hersteller eingeht.

Das AIM-P- in Verbindung mit dem R²D²-Projekt hatte eine fachlich fundierte Blaupause für die Weiterentwicklung der relationalen Datenbank-Technologie geliefert. Mit seinem mächtigen eNF²-Datenmodell, der Anfragesprache HDBL, den sehr universell einsetzbaren benutzerdefinierten Datentypen und Funktionen, den tief ins System integrierten Zeitversionen und mit seiner Workstation-Datenbankserver–Kooperation lieferte es interessante Anregungen und Perspektiven für die Weiterentwicklung der relationalen Datenbanksysteme. Leider hat man sich im SQL-Standardisierungsgremium für einen anderen Weg entschieden. Nach den oben zitierten Aussagen von Jim Melton ist auch nicht zu erwarten, dass sich dies nochmals ändern wird. Die Zeit für große technologische Sprünge in der Entwicklung der relationalen Datenbanksysteme scheint endgültig vorbei zu sein. Dazu passt auch, dass das NIST, das National Institute of Standards der USA, sich aus der SQL-Standardisierung im Jahr 1996 zurückgezogen hat und diese Aufgabe jetzt alleine den Herstellern überlässt.

Dies schmälert natürlich nicht die wissenschaftlichen Erfolge des AIM-P-Projekts, zeigt aber, dass die Forschung im technologischen Bereich letztlich nur Angebote an die Hersteller einer solchen Technologie machen kann. Ob diese Angebote dann angenommen werden oder nicht, hängt von vielen Faktoren ab, auf welche die Forscher und Forschungsgruppen in vielen Fällen keinen Einfluss haben. Oftmals weiß natürlich auch die große Mehrheit der Anwender nicht, dass es bessere Alternativen gäbe und können diese daher gegenüber den Herstellern auch nicht einfordern.

1. ↑ ^{a b c d} Albrecht Blaser: The Heidelberg Science Center: User Oriented Informatics and Computers in Science. Röhm, Sindelfingen 2001, ISBN 3-920799-23-2 (uni-jena.de). 
2. ↑ ^{a b} P. Dadam, V. Linnemann: Advanced Information Management (AIM): Advanced database technology for integrated applications. In: IBM Systems Journal. Band 28, Nr. 4, 1989, ISSN 0018-8670, S. 661–681, doi:10.1147/sj.284.0661. 
3. ↑ ^{a b c} V. Lum, P. Dadam, R. Erbe, J. Guenauer, P. Pistor, G. Welch, H. Werner, J. Woodfill: Design of an Integrated DBMS to Support Advanced Applications. In: Datenbank-Systeme für Büro, Technik und Wissenschaft. Springer, Berlin/Heidelberg 1985, ISBN 978-3-642-70284-6, S. 362–381, doi:10.1007/978-3-642-70284-6_26. 
4. ↑ ^{a b c d} Uwe Deppisch, Jürgen Günauer, Georg Walch: Speicherungsstrukturen und Adressierungstechniken Für Komplexe Objekte des NF2-Relationenmodells. In: Datenbank-Systeme für Büro, Technik und Wissenschaft. Springer, Berlin/Heidelberg 1985, ISBN 978-3-642-70284-6, S. 441–459, doi:10.1007/978-3-642-70284-6_30. 
5. ↑ ^{a b c d e f g} P. Dadam, K. Kuespert, F. Andersen, H. Blanken, R. Erbe: A DBMS prototype to support extended NF2 relations: an integrated view on flat tables and hierarchies. In: ACM SIGMOD Record. Band 15, Nr. 2, 15. Juni 1986, ISSN 0163-5808, S. 356–367, doi:10.1145/16856.16889. 
6. ↑ ^{a b c d} V Lum, P Dadam, R Erbe, J Guenauer, P Pistor, G Walch, H Werner, J Woodfill: Designing DBMS support for the temporal dimension. In: Proceedings of the 1984 ACM SIGMOD international conference on Management of data – SIGMOD '84. ACM Press, Boston 1984, ISBN 978-0-89791-128-3, S. 115, doi:10.1145/602259.602276. 
7. ↑ ^{a b c} Peter Dadam, Vincent Y. Lum, H.-D. Werner: Integration of Time Versions into a Relational Database System. In: VLDB '84: Proceedings of the 10th International Conference on Very Large Data Bases, Singapore. August 1984, S. 509–522 (vldb.org [PDF]). 
8. ↑ Justin Zobel, James A. Thom, Rom Sacks-Davis: Efficiency of Nested Relational Document Database Systems. In: VLDB '91, Proceedings of the 17th International Conference on Very Large Data Bases. September 1991, S. 91–102 (vldb.org [PDF]). 
9. ↑ ^{a b} Kalervo Järvelin, Timo Niemi: An NF2 relational interface for document retrieval, restructuring and aggregation. In: Proceedings of the 18th annual international ACM SIGIR conference on Research and development in information retrieval (= SIGIR '95). Association for Computing Machinery, New York 1995, ISBN 978-0-89791-714-8, S. 102–110, doi:10.1145/215206.215343. 
10. ↑ Timo Niemi, Kalervo Järvelin: A straightforward NF2 relational interface with applications in information retrieval. In: Information Processing & Management. Band 31, Nr. 2, 1. März 1995, ISSN 0306-4573, S. 215–231, doi:10.1016/0306-4573(95)80036-S. 
11. ↑ Serge Abiteboul, Nicole Bidoit: Non first normal form relations to represent hierarchically organized data. ACM Press, 1984, ISBN 978-0-89791-128-3, S. 191, doi:10.1145/588011.588038. 
12. ↑ R. Sacks-Davis, A. Kent, K. Ramamohanarao, J. Thom, J. Zobel: Atlas: a nested relational database system for text applications. In: IEEE Transactions on Knowledge and Data Engineering. Band 7, Nr. 3, Juni 1995, S. 454–470, doi:10.1109/69.390250. 
13. ↑ Filippo Cacace, Stefano Ceri, Stefano Crespi-Reghizzi, Georg Gottlob, Gianfranco Lamperti, Luigi Lavazza, Letizia Tanca, Roberto V. Zicari: ALGRES: An Extended Relational Database System for the Specification and Prototyping of Complex Applications. In: CAiSE '89: Proceedings of the First Nordic Conference on Advanced Systems Engineering, Stockholm. CEUR Workshop Proceedings, Nr. 961, Mai 1989 (ceur-ws.org [PDF]). 
14. ↑ Anand Deshpande, Dirk Gucht: A storage structure for Nested Relational Databases. In: Nested Relations and Complex Objects in Databases. Band 361. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 978-3-540-51171-7, S. 69–83, doi:10.1007/3-540-51171-7_21 (researchgate.net [abgerufen am 19. März 2026]). 
15. ↑ Moto Kawamura, Toru Kawamura,: Parallel Database Management System: Kappa. In: FGCS '94: Proc. Fifth Generation Computing Systems, Icot, Japan. Dezember 1994, S. 100–105 (psu.edu [PDF]). 
16. ↑ B. C. Desai, P. Goyal, F. Sadri: Non-first normal form universal relations: An application to information retrieval systems. In: Information Systems. Band 12, Nr. 1, 1. Januar 1987, ISSN 0306-4379, S. 49–55, doi:10.1016/0306-4379(87)90017-2. 
17. ↑ Hennie J. Steenhagen, Peter M. G. Apers, Henk M. Blanken: Optimization of nested queries in a complex object model. In: Advances in Database Technology — EDBT '94. Band 779. Springer Berlin Heidelberg, Berlin/Heidelberg 1994, ISBN 978-3-540-57818-5, S. 337–350, doi:10.1007/3-540-57818-8_62. 
18. ↑ Henk Blanken: Implementing version support for complex objects. In: Data & Knowledge Engineering. Band 6, Nr. 1, Januar 1991, S. 1–25, doi:10.1016/0169-023X(91)90013-N. 
19. ↑ Mark A. Roth, Henry F. Korth, Don S. Batory: SQL/NF: A query language for ¬1NF relational databases. In: Information Systems. Band 12, Nr. 1, 1. Januar 1987, ISSN 0306-4379, S. 99–114, doi:10.1016/0306-4379(87)90021-4. 
20. ↑ Mark A. Roth, Herry F. Korth, Abraham Silberschatz: Extended algebra and calculus for nested relational databases. In: ACM Transactions on Database Systems. Band 13, Nr. 4, Oktober 1988, ISSN 0362-5915, S. 389–417, doi:10.1145/49346.49347. 
21. ↑ Henry F. Korth, Mark A. Roth: Query languages for Nested Relational Databases. In: Nested Relations and Complex Objects in Databases (= Lecture Notes in Computer Science). Springer, Berlin/Heidelberg 1989, ISBN 978-3-540-46175-3, S. 190–204, doi:10.1007/3-540-51171-7_27. 
22. ↑ B. Rathakrishnan, J.L. Kim: An extended recursive algebra for nested relations and its optimization. IEEE Comput. Soc. Press, 1993, ISBN 978-0-8186-4440-5, S. 145–151, doi:10.1109/CMPSAC.1993.404228 (ieee.org [abgerufen am 19. März 2026]). 
23. ↑ Diana Lorentz: Oracle 8 – SQL Reference, Release 8.0. Hrsg.: Oracle Corporation. 1997 (oracle.com [PDF]). 
24. ↑ Informix Guide to SQL – Tutorial. Dezember 1999 (uni-kl.de [PDF]). 
25. ↑ ^{a b c d} Can Türker: SQL:1999 & SQL:2003 – Objektrelationales SQL, SQLJ & SQL/XML. 1. Auflage. dpunkt.verlag, Heidelberg 2003, ISBN 3-89864-219-4, 2: Objektrelationale Datendefinition in Standard-SQL, S. 92 ff. 
26. ↑ ^{a b c d e f g} Roger L. Haskin, Raymond A. Lorie: On extending the functions of a relational database system. In: Proceedings of the 1982 ACM SIGMOD international conference on Management of data – SIGMOD '82. ACM Press, Orlando, Florida 1982, ISBN 978-0-89791-073-6, S. 207, doi:10.1145/582353.582390 (acm.org). 
27. ↑ ^{a b c} H.-J. Schek, P. Pistor: Data Structures for an Integrated Data Base Management and Information Retrieval System. In: Proceedings 8th International Conference on Very Large Data Bases. Mexico City September 1982, S. 197–261 (vldb.org [PDF]). 
28. ↑ ^{a b c d e} G. Jaeschke, H. J. Schek: Remarks on the algebra of non first normal form relations. In: Proceedings of the 1st ACM SIGACT-SIGMOD symposium on Principles of database systems – PODS '82. ACM Press, Los Angeles 1982, ISBN 978-0-89791-070-5, S. 124, doi:10.1145/588111.588133 (acm.org [abgerufen am 18. Februar 2023]). 
29. ↑ ^{a b c d e f} Peter Pistor, Peter Dadam: The advanced information management prototype. In: Nested Relations and Complex Objects in Databases (= Lecture Notes in Computer Science). Springer, Berlin/Heidelberg 1989, ISBN 978-3-540-46175-3, S. 1–26, doi:10.1007/3-540-51171-7_18. 
30. ↑ ^{a b c} P. Dadam: Advanced Information Management (AIM): Research in Extended Nested Relations. In: Data Engineering, Quarterly Bulletin of the IEEE Computer Society Technical Committee. Nr. 11-3, 1988, S. 4–14 (computer.org [PDF]). 
31. ↑ ^{a b c d} K. Küspert, P. Dadam, J. Günauer: Cooperative Object Buffer Management in the Advanced Information Management Prototype. In: Proceedings 13th VLDB Conference, Brighton. 1987, S. 483–492 (vldb.org [PDF]). 
32. ↑ ^{a b c} P. Dadam, K. Küspert, N. Südkamp, R. Erbe, V. Linnemann, P. Pistor, G. Walch: Managing Complex Objects in R2D2. In: Hector – Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer, Berlin, Heidelberg 1988, ISBN 978-3-642-73574-5, S. 304–331, doi:10.1007/978-3-642-73574-5_19 (researchgate.net [abgerufen am 26. März 2026]). 
33. ↑ Peter Dadam: Datenbanksysteme: Konzepte und Modelle, Vorlesung Universität Ulm, WS 2013/2014. 2013, 3: Hierarchisches Datenmodell (researchgate.net). 
34. ↑ Peter Dadam: Datenbanksysteme: Konzepte und Modelle, Vorlesung Universität Ulm, WS 2013/14. 2013, 4: Netzwerk-Datenmodell (researchgate.net). 
35. ↑ ^{a b c d e} Peter Dadam: Datenbanksysteme – Konzepte und Modelle, Vorlesung Universität Ulm, WS 2013/14. 2013, 7: Relationales Datenmodell III: NF2 -und eNF2 -Relationenmodell (researchgate.net). 
    1. ↑ ^{a b} Seite 142
36. ↑ P. Pistor, B. Hansen, M. Hansen: Eine Sequelartige Sprachschnittstelle für Das NF2-Modell. In: Sprachen für Datenbanken. Band 72. Springer, Berlin/Heidelberg 1983, ISBN 978-3-540-12733-8, S. 134–147, doi:10.1007/978-3-642-69297-0_9. 
37. ↑ ^{a b c} H.-J. Schek: Towards a Basic Relational NF2 Algebra Processor. In: Foundations of Data Organization. Springer US, Boston 1987, ISBN 978-1-4612-9048-3, S. 549–562, doi:10.1007/978-1-4613-1881-1_46. 
38. ↑ ^{a b} Martin Dürr, Martin Huck, Alfons Kemper, Mechtild Wallrath: Using an NF2 Data Base System for Modeling of CIM Data. In: Non-Standard Datenbanken für Anwendungen der Graphischen Datenverarbeitung. Band 171. Springer, Berlin/Heidelberg 1988, ISBN 978-3-540-19175-9, S. 105–136, doi:10.1007/978-3-642-73608-7_7. 
39. ↑ ^{a b} R. Erbe, N. Südkamp: An Application Program Interface for a Complex Object Database. In: Proceedings of the Third International Conference on Data and Knowledge Bases. Morgan Kaufmann, 1988, ISBN 978-1-4832-1313-2, S. 211–226, doi:10.1016/b978-1-4832-1313-2.50023-8. 
40. ↑ J. Günauer, W. Manus: Austausch komplexer Datenbank-Objekte in einer heterogenen Workstation-Server-Umgebung. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Springer, Berlin/Heidelberg 1991, ISBN 978-3-642-76530-8, S. 140–160, doi:10.1007/978-3-642-76530-8_8. 
41. ↑ K. Küspert, J. Günauer: Workstation-Server-Datenbanksysteme für Ingenieuranwendungen: Anforderungen, Probleme, Lösungsmöglichkeiten. In: GI — 19. Jahrestagung I. Band 222. Springer, Berlin/Heidelberg 1989, ISBN 978-3-540-51821-1, S. 274–286, doi:10.1007/978-3-642-75177-6_22. 
42. ↑ Jürgen Hölsch, Michael Grossniklaus, Marc H. Scholl: Optimization of Nested Queries using the NF2 Algebra. In: Proceedings of the 2016 International Conference on Management of Data (= SIGMOD '16). Association for Computing Machinery, New York 2016, ISBN 978-1-4503-3531-7, S. 1765–1780, doi:10.1145/2882903.2915241. 
43. ↑ ^{a b} Marc H. Scholl: Theoretical foundation of algebraic optimization utilizing unnormalized relations. In: ICDT '86. Springer, Berlin/Heidelberg 1986, ISBN 978-3-540-47346-6, S. 380–396, doi:10.1007/3-540-17187-8_48. 
44. ↑ Volker Linnemann: Funktional rekursive Abfragen auf der Basis von geschachtelten Tabellen. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Springer, Berlin/Heidelberg 1989, ISBN 978-3-642-74571-3, S. 408–427, doi:10.1007/978-3-642-74571-3_37. 
45. ↑ Z. Meral Ozsoyoglu, Li-Yan Yuan: A new normal form for nested relations. In: ACM Transactions on Database Systems. Band 12, Nr. 1, März 1987, ISSN 0362-5915, S. 111–136, doi:10.1145/12047.13676. 
46. ↑ Mark A. Roth, Henry F. Korth: The design of ¬ 1NF relational databases into nested normal form. In: SIGMOD Rec. Band 16, Nr. 3, 1. Dezember 1987, ISSN 0163-5808, S. 143–159, doi:10.1145/38714.38733. 
47. ↑ ^{a b c} Rüdiger Dillmann: Types of Robols and Their Integration into Computer-Integrated Manufacturing Systems. In: Robot Technology and Applications. 1. Auflage. CRC Press, 2020, ISBN 978-1-00-306634-7, S. 1–62, doi:10.1201/9781003066347-1. 
48. ↑ ^{a b} R. Dillmann, M. Huck: R2D2: An Integration Tool for CIM. In: Hector Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer, Berlin/Heidelberg 1988, ISBN 978-3-642-73574-5, S. 355–372, doi:10.1007/978-3-642-73574-5_21. 
49. ↑ L. Gründig, P. Pistor: Land-Informations-Systeme und ihre Anforderungen an Datenbank-Schnittstellen. In: Informatik-Fachberichte, Sprachen für Datenbanken, 13. GI-Jahrestagung. Band 72. Springer-Verlag, Berlin / Heidelberg / New York / Tokyo 1983, ISBN 978-3-540-12733-8, S. 61–76. 
50. ↑ ^{a b c} Alfons Kemper, Mechtild Wallrath: An analysis of geometric modeling in database systems. In: ACM Comput. Surv. Band 19, Nr. 1, 1. März 1987, ISSN 0360-0300, S. 47–91, doi:10.1145/28865.28866 (acm.org [abgerufen am 26. März 2026]). 
51. ↑ Norbert Südkamp, Volker Linnemann: Elimination of View and Redundant Variables in a SQL-like Database Language for Extended NF2 Structures. In: Proceedings of the 16th International Conference on Very Large Data Bases (= VLDB '90). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA 1990, ISBN 978-1-55860-149-9, S. 302–313, doi:10.5555/645916.671994 (vldb.org [PDF; abgerufen am 26. Oktober 2024]). 
52. ↑ E. F. Codd: A relational model of data for large shared data banks. In: Commun. ACM. Band 13, Nr. 6, 1. Juni 1970, ISSN 0001-0782, S. 377–387, doi:10.1145/362384.362685. 
53. ↑ ^{a b c} P. Pistor, R. Traunmueller: A database language for sets, lists and tables. In: Information Systems. Band 11, Nr. 4, Januar 1986, S. 323–336, doi:10.1016/0306-4379(86)90012-8. 
54. ↑ ^{a b} P. Pistor, F. Andersen: Designing A Generalized NF2 Model with an SQL-Type Language Interface. In: VLDB '86, Proceedings of the 12th International Conference on Very Large Data Bases, Kyoto, Japan. August 1986, S. 278–285 (vldb.org [PDF]). 
55. ↑ G. Saake, V. Linnemann, P. Pistor, L. Wegner: Sorting, grouping and duplicate elimination in the advanced information management prototype. In: Proceedings of the 15th international conference on Very large data bases (= VLDB '89). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA 1989, ISBN 978-1-55860-101-7, S. 307–316, doi:10.5555/88830.88881 (vldb.org [PDF; abgerufen am 27. Oktober 2024]). 
56. ↑ K. Küspert, G. Saake, L. Wegner: Duplicate detection and deletion in the extended NF2 data model. In: 3rd International Conference, FODO 1989 on Foundations of Data Organization and Algorithms. Springer-Verlag, Berlin/Heidelberg 1989, ISBN 978-0-387-51295-2, S. 83–100, doi:10.5555/68413.68419 (researchgate.net [abgerufen am 27. Oktober 2024]). 
57. ↑ ^{a b} M. M. Astrahan, M. W. Blasgen, D. D. Chamberlin, K. P. Eswaran, J. N. Gray, P. P. Griffiths, W. F. King, R. A. Lorie, P. R. McJones, J. W. Mehl, G. R. Putzolu, I. L. Traiger, B. W. Wade, V. Watson: System R: relational approach to database management. In: ACM Trans. Database Syst. Band 1, Nr. 2, 1. Juni 1976, ISSN 0362-5915, S. 97–137, doi:10.1145/320455.320457 (acm.org [abgerufen am 1. März 2026]). 
58. ↑ ^{a b} Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Putzolu, Irving Traiger: The Recovery Manager of the System R Database Manager. In: ACM Comput. Surv. Band 13, Nr. 2, 1. Juni 1981, ISSN 0360-0300, S. 223–242, doi:10.1145/356842.356847 (acm.org [abgerufen am 1. März 2026]). 
59. ↑ U. Herrmann, P. Dadam, K. Küspert, E. A. Roman, G. Schlageter: A lock technique for disjoint and non-disjoint complex objects. In: Advances in Database Technology — EDBT '90. Springer, Berlin, Heidelberg 1990, ISBN 978-3-540-46948-3, S. 219–237, doi:10.1007/BFb0022173 (springer.com [abgerufen am 2. März 2026]). 
60. ↑ Ulrich Herrmann: Mehrbenutzerkontrolle in Nicht-Standard-Datenbanksystemen. In: Informatik-Fachberichte. Springer-Verlag, 1991, ISSN 0343-3005, doi:10.1007/978-3-642-76360-1 (springer.com [abgerufen am 2. März 2026]). 
61. ↑ Peter Dadam, Vincent Y. Lum, U. Prädel, Gunter Schlageter: Selective Deferred Index Maintenance & Concurrency Control in Integrated Information Systems. In: Proc. VLDB 85, International Confernce on Very Large Databases, Stockholm. 1985, S. 142–150 (vldb.org [PDF]). 
62. ↑ ^{a b} P. Klahold, G. Schlageter, R. Unland, W. Wilkes: Ein Transaktionskonzept zur Unterstützung komplexer Anwendungen in integrierten Systemen. In: Datenbank-Systeme für Büro, Technik und Wissenschaft. Springer, Berlin, Heidelberg 1985, ISBN 978-3-642-70284-6, S. 309–335, doi:10.1007/978-3-642-70284-6_23 (fernuni-hagen.de [PDF; abgerufen am 6. März 2026]). 
63. ↑ K. Küspert, U. Herrmann, R. Erbe, P. Dadam: The recovery manager of the advanced information management prototype. In: Reliability Engineering & System Safety. Band 28, Nr. 2, 1. Januar 1990, ISSN 0951-8320, S. 187–203, doi:10.1016/0951-8320(90)90063-S (sciencedirect.com [abgerufen am 4. März 2026]). 
64. ↑ James Clifford, David S. Warren: Formal semantics for time in databases. In: ACM Trans. Database Syst. Band 8, Nr. 2, 1. Juni 1983, ISSN 0362-5915, S. 214–254, doi:10.1145/319983.319986. 
65. ↑ T. L. Anderson: Modeling Time at the Conceptual Level. In: Proc.Second Int'l Conf. Databases: Improving Usability and Responsiveness, Jerusalem, Israel. Academic Press, 1982, S. 273–297. 
66. ↑ Peter Dadam: Vorlesung Database Internals, Universität Ulm, Sommersemester 2014. Kapitel 4: Implementierung von Fehlertoleranz, 2014, S. 32 ff. (researchgate.net). 
67. ↑ U. Deppisch, J. Günauer, K. Küspert, V. Obermeit, G. Walch: Überlegungen zur Datenbank-Kooperation zwischen Server und Workstations. In: Informatik-Anwendungen — Trends und Perspektiven. Springer, Berlin, Heidelberg 1986, ISBN 978-3-642-71388-0, S. 565–580, doi:10.1007/978-3-642-71388-0_44 (springer.com [abgerufen am 6. April 2026]). 
68. ↑ G. Krüger, G. Müller (Hrsg.): Hector – Heterogeneous Computers Together, A Joint Project of IBM and the University of Karlsruhe – Conference proceedings. Volume II: Basic Projects, About this book. Springer, Berlin, Heidelberg 1988, ISBN 978-3-540-19137-7. 
69. ↑ K. Hoermann, U. Rembold: A Robot Action Planner For Automatic Parts Assembly. IEEE, 1988, S. 311–317, doi:10.1109/IROS.1988.593308 (ieee.org [abgerufen am 1. April 2026]). 
70. ↑ ^{a b} Ulrich Rembold: Robot Technology and Applications. 1. Auflage. CRC Press, 2020, ISBN 978-1-00-306634-7, doi:10.1201/9781003066347 (taylorfrancis.com [abgerufen am 26. März 2026]). 
71. ↑ R. Dillmann, M. Huck: A software system for the simulation of robot based manufacturing processes. In: Robotics (= Special Issue: R&D in the F.R.G.). Band 2, Nr. 1, 1. März 1986, ISSN 0167-8493, S. 3–18, doi:10.1016/0167-8493(86)90018-5 (sciencedirect.com [abgerufen am 15. April 2026]). 
72. ↑ Klaus R. Dittrich, Willi Gotthard ,Peter Lockemann: Complex Entities for Engineering Applications. In: Proceedings of the Fifth International Conference on Entity-Relationship Approach, Dijon, France. 1986, S. 421–440. 
73. ↑ Klaus R. Dittrich, Willi Gotthard, Peter C. Lockemann: Damokles — A database system for software engineering environments. In: Advanced Programming Environments. Band 244. Springer Berlin Heidelberg, Berlin, Heidelberg 1986, ISBN 978-3-540-17189-8, S. 353–371, doi:10.1007/3-540-17189-4_107 (springer.com [abgerufen am 1. April 2026]). 
74. ↑ Klaus R. Dittrich, Angelika M. Kotz, Jutta A. Mölle, Peter C. Lockemann: Datenbankunterstützung für den ingenieurwissenschaftlichen Entwurf: Eine Übersicht über den Stand der Entwicklung. In: Informatik Spektrum. Band 8, Nr. 3, Juni 1985, ISSN 0170-6012, S. 113–125, doi:10.1007/BF00425952 (springer.com [abgerufen am 1. April 2026]). 
75. ↑ José Encarnação, Peter Lockemann (Hrsg.): Engineering Databases: Connecting Islands of Automation Through Databases. Springer-Verlag, 1990, ISBN 978-3-642-64859-5, doi:10.1007/978-3-642-61508-5 (springer.com [abgerufen am 1. April 2026]). 
76. ↑ Peter Dadam, Rüdiger Dillmann, Alfons Kemper, Peter Lockemann: Objektorientierte Datenhaltung für die Roboterprogrammierung. In: Informatik, Forschung und Entwicklung. Band 2, Nr. 4. Springer, Berlin, Heidelberg 1987, S. 151–170 (researchgate.net). 
77. ↑ ^{a b} Martin Dürr, Martin Huck, Alfons Kemper, Mechtild Wallrath: Using an NF2 Data Base System for Modeling of CIM Data. In: Non-Standard Datenbanken für Anwendungen der Graphischen Datenverarbeitung. Springer, Berlin, Heidelberg 1988, ISBN 978-3-642-73608-7, S. 105–136, doi:10.1007/978-3-642-73608-7_7 (springer.com [abgerufen am 26. März 2026]). 
78. ↑ Alfons Kemper, Peter C. Lockemann, Mechtild Wallrath: An object-oriented system for engineering applications. In: SIGMOD Rec. Band 16, Nr. 3, 1. Dezember 1987, ISSN 0163-5808, S. 299–310, doi:10.1145/38714.38747 (acm.org [abgerufen am 26. März 2026]). 
79. ↑ Peter Dadam, Rüdiger Dillmann, Alfons Kemper, Peter Lockemann: Objektorientierte Datenhaltung für die Roboterprogrammierung. In: Informatik, Forschung und Entwicklung. Band 2, Nr. 4. Springer, Berlin, Heidelberg 1987, S. 151–170 (researchgate.net). 
80. ↑ ^{a b} P. Dadam, R. Dillmann, A. Kemper, P. C. Lockemann: Object-Oriented Databases for Robot Programming. In: Hector Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer, Berlin, Heidelberg 1988, ISBN 978-3-642-73574-5, S. 289–303, doi:10.1007/978-3-642-73574-5_18 (researchgate.net [abgerufen am 6. April 2026]). 
81. ↑ James Ong, Dennis Fogg, Michael Stonebraker: Implementation of data abstraction in the relational database system INGRES. In: SIGMOD Rec. Band 14, Nr. 1, 1. September 1983, ISSN 0163-5808, S. 1–14, doi:10.1145/984540.984541 (acm.org [abgerufen am 16. März 2026]). 
82. ↑ ^{a b c} Jim Melton: Advanced SQL:1999 – Understanding Object-Relational and Other Advanced Features. Morgan Kaufmann Publshers, an imprint of Elsevier Science, San Francisco, USA 2003, ISBN 1-55860-677-7. 
83. ↑ Peter Dadam: Datenbanksysteme: Konzepte und Modelle. Vorlesung Universität Ulm, WS 2013/2014. 2013, Kapitel 12: Relationales Datenmodell IV: Objektrelationale SQL-Erweiterungen (researchgate.net). 
84. ↑ ^{a b c} Volker Linnemann, Klaus Küspert, Peter Dadam, Peter Pistor, R. Erbe, Alfons Kemper, Norbert Südkamp, Georg Walch, Mechtild Wallrath: Design and Implementation of an Extensible Database Management System Supporting User Defined Data Types and Functions. In: VLDB '88: Proc.14th International Conference on Very Large Data Bases. 1988, S. 294 – 305 (vldb.org [PDF]). 
85. ↑ Chao Zhang, Guanghui Zhou: A view-based 3D CAD model reuse framework enabling product lifecycle reuse. In: Advances in Engineering Software. Band 127, 1. Januar 2019, ISSN 0965-9978, S. 82–89, doi:10.1016/j.advengsoft.2018.09.001 (sciencedirect.com [abgerufen am 13. April 2026]). 
86. ↑ Jing Bai, Shuming Gao, Weihua Tang, Yusheng Liu, Song Guo: Design reuse oriented partial retrieval of CAD models. In: Computer-Aided Design. Band 42, Nr. 12, 1. Dezember 2010, ISSN 0010-4485, S. 1069–1084, doi:10.1016/j.cad.2010.07.002 (sciencedirect.com [abgerufen am 13. April 2026]). 
87. ↑ J. Altmeyer, S. Ohnsorge, B. Schiirmann: Reuse Of Design Objects In Cad Frameworks. IEEE, 1994, ISBN 978-0-8186-6417-5, S. 754–761, doi:10.1109/ICCAD.1994.629908 (researchgate.net [PDF; abgerufen am 13. April 2026]). 
88. ↑ Ulrike Thomas: Automatisierte Programmierung von Robotern für Montageaufgaben (Fortschritte in der Robotik). Hrsg.: Friedrich M. Wahl, Institut für Robotik und Prozessinformatik, TU Braunschweig. Shaker, 2008, ISBN 978-3-8322-7101-5. 
89. ↑ C. Brecher, J. Roßmann, C. Schlette, W. Herfs, H. Ruf, M. Göbel: Intuitive Roboterprogrammierung in der automatisierten Montage *. In: wt Werkstattstechnik online. Band 100, Nr. 9, 2010, ISSN 1436-4980, S. 681–686, doi:10.37544/1436-4980-2010-9-681 (researchgate.net [abgerufen am 8. April 2026]). 
90. ↑ R. Dillmann, M. Huck: A Relational Data Base Supporting CAD-Oriented Robot Programming. In: CAD Based Programming for Sensory Robots. Springer, Berlin, Heidelberg 1988, ISBN 978-3-642-83625-1, S. 41–65, doi:10.1007/978-3-642-83625-1_3 (springer.com [abgerufen am 3. April 2026]). 
91. ↑ ^{a b} Alfons Kemper, Mechtild Wallrath, Martin Dürr: Object Orientation in R2D2. In: Hector – Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer, Berlin, Heidelberg 1988, ISBN 978-3-642-73574-5, S. 332–354, doi:10.1007/978-3-642-73574-5_20 (springer.com [abgerufen am 1. April 2026]). 
92. ↑ M. Dürr, M. Huck, A. Kemper, P. Mohrholz, M. Wallrath: Using conventional and nested relational database systems for modelling CIM data. In: Computer-Aided Design. Band 21, Nr. 6, 1. Juli 1989, ISSN 0010-4485, S. 379–392, doi:10.1016/0010-4485(89)90005-5 (sciencedirect.com [abgerufen am 26. März 2026]). 
93. ↑ Alfons Kemper, Mechtild Wallrath: Konzepte zur Integration Abstrakter Datentypen in R2D2. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Springer, Berlin, Heidelberg 1987, ISBN 978-3-642-72617-0, S. 344–359, doi:10.1007/978-3-642-72617-0_32 (springer.com [abgerufen am 26. März 2026]). 
94. ↑ M. Dürr, M. Huck, A. Kemper, P. Mohrholz, M. Wallrath: Using conventional and nested relational database systems for modelling CIM data. In: Computer-Aided Design. Band 21, Nr. 6, 1. Juli 1989, ISSN 0010-4485, S. 379–392, doi:10.1016/0010-4485(89)90005-5 (sciencedirect.com [abgerufen am 3. April 2026]). 
95. ↑ Martin Dürr, Martin Huck, Alfons Kemper, Mechtild Wallrath: Using an NF2 Data Base System for Modeling of CIM Data. In: Non-Standard Datenbanken für Anwendungen der Graphischen Datenverarbeitung. Springer, Berlin, Heidelberg 1988, ISBN 978-3-642-73608-7, S. 105–136, doi:10.1007/978-3-642-73608-7_7 (springer.com [abgerufen am 3. April 2026]). 
96. ↑ Mechtild Wallrath: Modellierung technischer Anwendungen in R2D2. In: Entwicklung ingenieurwissenschaftlicher Datenbankanwendungen: Ein objektorientiertes Datenmodell. Springer, Berlin, Heidelberg 1994, ISBN 978-3-642-77665-6, S. 63–148, doi:10.1007/978-3-642-77665-6_4. Fehler in Vorlage:Literatur – *** Parameterproblem: Dateiformat/Größe/Abruf nur bei externem Link
97. ↑ Mechtild Wallrath: Softwareentwurf in R2D2. In: Entwicklung ingenieurwissenschaftlicher Datenbankanwendungen: Ein objektorientiertes Datenmodell. Springer, Berlin, Heidelberg 1994, ISBN 978-3-642-77665-6, S. 161–195, doi:10.1007/978-3-642-77665-6_6. Fehler in Vorlage:Literatur – *** Parameterproblem: Dateiformat/Größe/Abruf nur bei externem Link
98. ↑ R. Dillmann, M. Huck: R2D2: An Integration Tool for CIM. In: Hector Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer, Berlin, Heidelberg 1988, ISBN 978-3-642-73574-5, S. 355–372, doi:10.1007/978-3-642-73574-5_21 (springer.com [abgerufen am 1. April 2026]). 
99. ↑ Alfons Kemper, Mechtild Wallrath: A uniform concept for storing and manipulating engineering objects. In: Advances in Object-Oriented Database Systems. Springer, Berlin, Heidelberg 1988, ISBN 978-3-540-45981-1, S. 292–297, doi:10.1007/3-540-50345-5_27 (springer.com [abgerufen am 26. März 2026]). 
100. ↑ Transaction Control Mechanism for the Object Cache Interface of R2D2. In: Proceedings of the Third International Conference on Data and Knowledge Bases. Morgan Kaufmann, 1. Januar 1988, S. 81–89, doi:10.1016/B978-1-4832-1313-2.50013-5 (sciencedirect.com [abgerufen am 3. April 2026]). 
101. ↑ Andrew Eisenberg, Jim Melton: SQL: 1999, formerly known as SQL3. In: SIGMOD Rec. Band 28, Nr. 1, 1. März 1999, ISSN 0163-5808, S. 131–138, doi:10.1145/309844.310075 (acm.org [abgerufen am 7. März 2026]). 
102. ↑ R. Camps: Domains, relations and religious wars. In: SIGMOD Rec. Band 25, Nr. 3, 1. September 1996, ISSN 0163-5808, S. 3–9, doi:10.1145/234889.234890 (acm.org [abgerufen am 18. März 2026]). 
103. ↑ Jim Melton: Interview mit Jim Melton. Hrsg.: Software Engineering Radio Podcast. 5. Juni 2009, S. Minuten 18:20 – 19:13 (se-radio.net). 
104. ↑ Die Konzepte von Informix, Oracle, Sybase, Software AG, CA und IBM: Objektrelationale Technik bereitet Herstellern Sorgen. 21. Juni 1996, abgerufen am 24. März 2026.