Benutzer:Dbisianer/Advanced Information Management Prototype (AIM-P))

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Der Advanced Information Management Prototype (AIM-P) war ein experimentelles Datenbankmanagementsystem (DBMS), das im Bereich "Advanced Information Managment (AIM)" [1] des Wissenschaftlichen Zentrums der IBM in Heidelberg (WZH) von 1982 bis 1989 entwickelt und in experimentellen Anwendungen eingesetzt und erprobt wurde. Ziel dieses Forschungs- und Entwicklungsprojektes war zu untersuchen, wie die Technogie der relationalen DBMS so weiterentwickelt werden kann, dass sie sowohl (weiterhin) für die konventionellen Anwendungen als auch für sog. "Nicht-Standard-Datenbankanwendungen" [2], wie z.B. Computer Integrated Manufacturing (CIM), Robotik, Geoinformationssysteme, Dokumenten-Verwaltung (Dokumenten-Retrieval) und die zeitversionierte Speicherung von Daten (temporale Datenhaltung) adäquat einsetzbar wird.[3][4] Obwohl AIM-P ein vollständig von IBM finanziertes Forschungs- und Entwicklungsprojekt war, war es als rein wissenschaftliches Projekt angelegt (d.h. keinerlei Geheimhaltung, keinerlei Patentierungsbestrebungen). Dies spiegelt sich auch in der hohen Anzahl von Gastwissenschaftlern wider, die in diesem Projekt mitgewirkt haben (siehe Abschnitt AIM-P-Team) sowie in den ca. 70 wissenschaftlichen Publikationen von Projektmitgliedern, die während ihrer Mitwirkung in diesem Projekt [1] oder im Nachgang, wie z.B. [5][6][7][8][9][10][11][12][13], entstanden sind.

Vorgeschichte[Bearbeiten | Quelltext bearbeiten]

Ende der 1970er Jahre - also noch bevor die ersten kommerziellen relationalen DBMS auf den Markt gekommen sind - experimentierten Wissenschaftler am IBM Research Laboratory in San Jose (dem späteren IBM Almaden Research Center) und am Wissenschaftlichen Zentrum der IBM in Heidelberg mit den Einsatz von System R in Anwendungen, in denen komplex strukturierte Datenobjekte zu verwalten waren. In San Jose waren dies ingenieur-wissenschaftliche [14], während es in Heidelberg Dokumentenretrieval-Anwendungen [1] 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, wie im Kapitel Schwächen des 1NF-Relationenmodells veranschaulicht.

Während man im San Jose Resarch Lab der IBM (dem späteren Almaden Research Lab) den auf flache Relationen ausgerichteten DBMS-Kern nicht anrührte und es mit einem „On-Top“-Ansatz versuchte [14], tauchte man am WZH tief in die relationale Theorie und die zugrundeliegende Relationenalgebra ein. Anfang der 1980er Jahre zeigten die beiden WZH-Mitarbeiter Jaeschke und Schek [15], dass das Axiom der 1. Normalform, dass die Attributwerte von Relationen stets atomar sein müssen, nicht wirklich essentiell für das Relationale Datemodell und seine Relationenalgebra ist, sondern dass sich diese so verallgemeinern lassen, dass (wie bei mathematischen Relationen) auch geschachtelte Relationen unterstützt werden können. Da dieses erweiterte relationale Datenmodell die Forderung der ersten Normalform (1NF) aufgibt, nannten sie es Non First Normal Form Relations (abgekürzt NF2-Relations) [15]. – Das NF2-Relationenmodell - in Verbindung mit dem Sprachvorschlag von Schek und Pistor zur Erweiterung der Datenbank-Anfragesprache SQL [16] - inspirierte weltweit zahlreiche Forschungsaktivitäten (wie z.B. in Australien [17], Finnland [18][19], Frankreich [20] [21], Italien [22], Japan [23], Kanada [24], Niederlande [10][11] und den USA [25][26][27]) und wurde später auch in kommerzielle relationale DBMS integriert (wie z.B. 1997 in Oracle Version 8 [28]).

Nachdem diese Schwächen der in Entwicklung befindenden relationalen DBMS erkannt wurden, richtete man am WZH gegen Ende der 1970er Jahre 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 NF2-Ansatz hinausgehende) - Lösungskonzepte zu entwickeln [1]. Zu Anfang wurden eine ganze Reihe von "Nicht-Standard-Datenbankanwendungen" (wie oben skizziert) untersucht, um ihre Anforderungen an die benötigten Datenstrukturen und Datentypen, die Art der Anfragen, die typische Interaktion (etwa im CAD-Bereich) zwischen Anwender bzw. Anwendungsprogrammen und Datenbank-Server und daraus resultierende Anforderungen an die System-Architektur zu ermitteln. Die hierbei gewonnen Erkenntnisse ließen erkennen, dass das NF2-Relationenmodell wohl nicht alle Anforderungen abdecken wird, sondern dass sehr wahrscheinlich ein noch mächtigeres Datenmodell benötigt wird; und man außerdemn auch von der zu dieser Zeit rein serverbasierten Bearbeitung von Datenbankobjekten in relationalen DBMS würde abrücken müssen.

Ende 1982 wurde dann am WZH entschieden einen DBMS-Prototyp zu bauen, in dessen 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 erprobt werden können. Der Prototyp erhielt den Namen "Advanced Information Management Prototype (AIM-P)" [29], sein Datenmodell - da dessen Ausgangspunkt die NF2-Relationen waren - die Bezeichnung "Erweiterte NF2-Relationen"[30] bzw. kurz "eNF2-Relationen" und seine Anfragesprache den Namen "Heidelberg Database Language (HDBL)" [29].

Schwächen des 1NF-Relationenmodells[Bearbeiten | Quelltext bearbeiten]

Das 1NF-Relationenmodell hat viele Stärken, wie z.B. die intern verwendete Relationen-Algebra, die hierdurch mögliche systemseitige Anfrageoptimierung, eine mächtige und dennoch relativ einfach zu erlernende Anfragesprache (SQL), der theoretisch fundierte Datenbankentwurf und anderes mehr. Bei der Verwaltung von typischen Datenobjekten technisch-wissenschaftlicher Anwendungen zeigt der 1NF-Ansatz jedoch große Schwächen. Betrachten wir als (stark vereinfachtes) Beispiel die Speicherung der Daten von Robotern, wie in Abb. 1 illustriert. Hierzu würde man in einem relationalen DBMS etwa die in Abb. 2 dargestellten Basis-Relationen verwenden.

Abb. 1: Modellierung eines Roboters (vereinfacht)
Abb. 2: Speicherung der Roboter-Daten als 1NF-Relationen

Eine typische Anfrage, die man via Anwendungsprogramm stellen würde, wäre alle Informationen zu einem bestimmten Roboter zu erhalten. Dies würde z.B. die in Abb. 3 dargestellte SQL-Anweisung leisten und dem Anwendungsprogramm als Resultatmenge, wie in Abb. 4 skizziert, zur Abholung bereitstellen.

Abb. 3: SQL-Anfrage: "Gib alle Daten zu Roboter 'Rob1' aus"
Abb. 4: Resultat-Tabelle für Anfrage in Abb. 3

Durch die 1NF-Ergebnisdastellung erhält man eine Tabelle, in der sich die vom Anwender gewünschte Information über viele Spalten und Zeilen verstreut und so eigentlich für ihn nicht direkt brauchbar ist und erst per Anwendungsprogamm in eine vernünftig darstellbare Form gebracht werden muss. Bei einer realen Roboter-Anwendung kommt man zudem auf eine viele größere Anzahl von Basis-Relationen, die in Folge zu einer sehr großen Resultattabelle mit vielen hundert Spalten (was die relationalen DBMS des Jahrgangangs 1983 überfordert hätte) und tausenden von Zeilen kommen, was sich zudem auch in einer langen Antwortzeit niederschlagen würde. Die "Lösung" sah deshalb MItte der 1980er Jahre - und das hat sich bis heute (2023) eigentlich nicht wesentlich geändert - dann wie in Abb. 5 skizziert aus. Das Anwendungsprogramm führt hier mehrfach iterierend viele einzelne SQL-Anfragen auf der relationalen Datenbank aus, wobei der "Output" einer Anfrage in der Regel den "Input" für die Folgeanfrage liefert. Bei dieser Vorgehensweise werden die benötigten Daten quasi "stückweise" aus der Datenbank geholt. Das SQL-DBMS wird hierdurch in seiner Nutzung quasi zum Dateisystem degradiert.

Abb. 5 Iterierende SQL-Anfragen gegen die Roboter-Tabellen

Die Art der Interaktion zwischen Anwendungsprogramm und Datenbanksystem - wie in Abb. 5 skizziert - ähnelt bei solchen Anwendungen stark derjenigen aus der vor-relationalen Zeit [31][32][33]. – 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 ein semantisches Datenmodell (wie z.B. ER- oder UML-Diagramme) dieses Datenobjektes als Hilfsmittel, um die SQL-Anfrage überhaupt so formulieren zu können, dass sie auch tatsächlilch das gewünschte Ergebnis liefert.

NF2-Relationenmodell[Bearbeiten | Quelltext bearbeiten]

Das NF2-Relationenmodell

  • ist eine Verallgemeinerung des 1NF-Relationenmodells, d.h. jede korrekt konstruierte 1NF-Relation ist somit auch eine korrekt konstruierte NF2-Relation
  • ermöglicht eine natürlichere und intuitiv besser verständliche Darstellung hierarchisch strukturierter Datenojekte (siehe Abb. 6)
  • ermöglicht die kompakte Übertragung solcher Anfrageeergebnisse zum Anwendungsprogramm [34] und reduziert dort ggf. den Aufbereitungsaufwand
  • basiert auf einer (erweiterten) Relationenalgebra und ermöglich hierdurch auch (weiterhin) eine systemseitige Anfrageoptimierung
  • verfügt über entsprechend angepasste Normalformen für den Datenbankentwurf [35]
Abb. 6: Roboter-Tabelle als NF2-Relation

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

  1. Speicherung als NF2-Datenobjekt mit darauf zugeschnittenen internen Datenstrukturen [30][36]
  2. Speicherung als 1NF-Relationen (wie in Abb. 2) und definiert darauf eine Abb. 6 entsprechende Sicht

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

eNF2-Relationenmodell[Bearbeiten | Quelltext bearbeiten]

Das NF2-Relationenmodell stellt zwar für technisch-wissenschaftliche Anwendungen bereits einen Schritt in die richtige Richtung dar, ist aber hinsichtlich der Vielfalt der Datenstrukturen, die dort benötigt werden, bei weitem noch nicht ausreichend. NF2-Relationen sind nämlich, wie die 1NF-Relationen, immer noch (ungeordnete) Mengen von Tupeln; und zwar sowohl auf Top- und auch auf der Ebene von relationswertigen Attributen. D.h. selbst wenn die Roboterdaten auch intern in speziellen NF2-unterstützenden Datenstrukturen gespeichert sind [30][36], muss man diese beim Auslesen (wie von SQL gewohnt) sortieren, damit sie in der gewünschten Reihenfolge vom DBMS geliefert werden. Im obigen Beispiel muss man daher nach RobID, ArmID, AxisNo, Row und EffID sortieren, um tatsächlich auch die in Abb. 6 dargestellte Reihenfolge der Einträge zu erhalten. Dies ist nicht nur bei der Anwendungsentwicklung etwas lästig, sondern würde auch bei umfangreichen Daten, wie z.B. langen Messreihen oder Polygonzügen, wie sie etwa in Geoinformationssystemen oder bei der Modellierung der Bahnkurven, die ein Roboterarm ausführt, zu einem erheblichen Aufwand und längeren Antwortzeiten führen.

Dies führte im AIM-P-Projekt daher bereits früh zu der Entscheidung, das NF2-Relationenmodell um "geordnete Mengen", d.h. um Listen von Tupeln zu erweitern.[30] Die Einschränkung auf Listen von Tupeln ist jedoch - insbesondere bei der Speicherung von Matrizen - hinderlich, da dann der zeilenorientiere Zugriff über ihre Listenposition und der spaltenorientierte über den Spaltennamen erfolgen müsste und damit die Formulierung von Anfragen verkompliziert. Matrizen als Liste von Listen von Zahlen zu interpretieren, ist daher eine sehr viel natürlichere Darstellung (und dies gilt insbesondere für höherdimensionale oder Matrizen mit sehr vielen Spalten). Aus diesem Grund wurden deshalb das Dies führte zu einer Erweiterung des NF2-Relationenmodell mit Listen von Listen.

In Abb. 7 ist eine derartig erweiterte NF2-Relation illustriert, in welcher die Achsen als einfache Listen und Matrixen innerhalb der Achsen als geschachtelte Listen dargestellt werden und somit über ihre Listenpositionen angesprochen werden können. Die in Abb. 6 vorhandenen Attribute AxisNo und Row können deshalb nun entfallen.

Abb. 7: Roboter-Daten als erweiterte NF2-Relation mit Listen und Listen von Listen

Am Ende aller Untersuchungen und Überlegungen stand dann ein Datenbank-Datenmodell, an dem alle atomaren und konstruierten Typen sowohl als Top-Level-Datenbankobjekte als auch als Unterobjekte von diesen auftreten können, wie in Abb. 8 illustriert. D.h. in einem DBMS, welche das eNF2-Datenmodell unterstützt, sind auch einfach oder komplex-strukturierteTupel sowie atomare Werte legale Datenbankobjekte. Damit bietet das eNF2-Datenmodell den Anwendungsentwicklern im Wesentlichen dieselben atomaren und konstruierten Datentypen und kann - eine geeignete eNF2-Anfragesprache und Anwendungsprogrammschnittstelle vorausgesetzt - das Anfrageergebnis in einer passgenauen Strukturierung an das Anwendungsprogramm übergeben. Näheres hierzu in den Abschnitten Heidelberg Database Language (HDBL) und Anwendungsprogrammschnittstelle (API).

Abb. 8: Vom 1NF via NF2 zum eNF2-Datenmodell

Da der Ausgangspunkt dieser Erweiterungen und Verallgemeinerungen das NF2-Datenmodell war, erhielt dieses erweiterte Datenmodell den Namen "Erweiterte NF2-Relationen" bzw. abgekürzt eNF2-Relationen[29][30], unter dem es auch Eingang in Lehrbücher (siehe z.B. [37][38][39]), Vorlesungen (siehe z.B. [40][41][42][43]) und andere wissenschaftliche Projekte (siehe z.B. [44][45]) gefunden hat. - Diese (nochmalige) Verallgemeinerung des NF2-Datenmodells war auch durch die Datenbanksprache HDBL bzw. ihres relationenalgebra-ähnlichen Unterbaus motiviert[46].

Heidelberg Database Language (HDBL)[Bearbeiten | Quelltext bearbeiten]

To Do ...

Wie bereits eingangs erwähnt, war es ein wesentliches Ziel des AIM-P-Projekts, der Anwendungsentwicklung die für technisch-wissenschaftliche und andere anspruchsvolle Anwendungen als unabdingbar identifizierte Datenstrukturen des eNF2-Datenmodells mittels einer SQL-ähnlichen Datenbanksprache (mit einer relationenalgebra-ähnlichen Zwischensprache als "Unterbau" und Basis für eine systemseitige Anfrageoptimierung) in adäquater Weise bereit zu stellen.

Die hierfür entwickelte Datenbanksprache HDBL wurde - wie auch das eNF2-Datenmodell - in einem iterativen Analyse-, Entwurfs- und Entwicklungsprozess erarbeitet und in diversen Veröffentlichungen im Detail beschrieben [16][47][48]. - Nachstehend deshalb nur einige ausgewählte Beispiele, um die Gemeinsamkeiten und Unterschiede zu SQL etwas zu veranschaulichen.

Im Folgenden werden zunächst nur interaktive Anfragen betrachtet, wo der Anwender direkt die Online-Schnittstelle des DBMS benutzt wird, um die Anfrage via Tastatur einzugeben und deren Resultat auf dem Bildschirm angezeigt zu bekommen. Auf die Einbettung solcher Anfragen in ein Anwendungsprogramm und den Transfer der Ergebnisse von DBMS zu diesem gehen wir im Abschnitt Anwendungsprogrammschnittstelle (API) ein. Für die folgenden HDBL-Beispiele wird unterstellt, dass sowohl die "flachen" 1NF-Relationen für das Roboter-Beispiel in Abb. 7, die "RobotNF2"-Relation aus Abb. 10 sowie die "Robot_eNF2"-Relation aus Abb. 11 in der Datenbank gespeichert sind. Der Einheit halber wird im Folgenden angenommen, dass diese ggf. auch in einer derart strukturierten Form vom DBMS am Bildschirm ausgegeben werden.

Fremde Referenzen auf HDBL [49][50][51][52][53]

R2D2-Projekt[Bearbeiten | Quelltext bearbeiten]

Referenzen[54]

Benutzerdefinierte Datentypen und Operationen[Bearbeiten | Quelltext bearbeiten]

Anwendungsprogrammschnittstelle (API)[Bearbeiten | Quelltext bearbeiten]

Implementierungsaspekte[Bearbeiten | Quelltext bearbeiten]

Unterstützung von Zeitversionen[Bearbeiten | Quelltext bearbeiten]

Referenzen [55]

Kooperative Objektbearbeitung im Workstation-Server-Kontext[Bearbeiten | Quelltext bearbeiten]

Referenzen [56]

Unterstützung komplexer Indexe[Bearbeiten | Quelltext bearbeiten]

Weitere Aspekte ??[Bearbeiten | Quelltext bearbeiten]

HDBL und der SQL-Standard ??[Bearbeiten | Quelltext bearbeiten]

Date-Darwen-Beiträge [57][58]

Wikipedia.org zur SQL-Kritik bzgl. Erweiterungen SQL-Kritik

Der Datenbank-Hersteller Oracle griff dieses Konzept auf und führte 1997 mit Version 8 seines Datenbanksystems das Konstrukt "Nested Table Columns" mit darauf abgestimmten proprietären SQL-Erweiterungen ein.[28]

AIM-P-Team[Bearbeiten | Quelltext bearbeiten]

An der Realisierung von AIM-P waren das „Kern-Team“ sowie viele Gastwissenschaftler vor Ort sowie die über Kooperationsprojekte mit Universitäten involvierten Wissenschaftler beteiligt. Die folgenden Angaben wurden [1] entnommen.

WZH-Mitarbeiter[Bearbeiten | Quelltext bearbeiten]

  • Peter Dadam, 1982–1989, ab 1985 Leiter der Abteilung AIM, dann Professor an der Universität Ulm
  • Rolf Erbe, ca. ab 1980
  • Jürgen Günauer, ab 1982
  • Klaus Küspert, 1986–1994, zuvor als Gastwissenschaftler, ab 1989 Leiter der Abteilung AIM, dann Professor an der Universität Jena
  • Volker Linnemann, 1986–1990, dann Professor an der Universität Lübeck
  • Vincent Lum, 1982–1985, auf Assignment von IBM Almaden Research, Leiter der Abteilung AIM
  • Peter Pistor, ab 1977
  • Emilio Roman, 1988–1990, auf Assignment vom IBM Santa Teresa Entwicklungslabor, USA
  • Hans-Jörg Schek, ab 1977–1982, erster Leiter der Abteilung AIM, dann Professor an der TH Darmstadt
  • Nobert Südkamp, ab 1986
  • Georg Walch, ca. ab 1980

Gastwissenschafter[Bearbeiten | Quelltext bearbeiten]

  • Fleming Andersen, TCC Kopenhagen, Dänemark, 12/1984–01/1987
  • Henk Blanken, Universität Twente, Niederlande, 06/1985–07/1986
  • Bo Hansen, Universität Lyngby, Dänemark, 04/1982–06/1982
  • Michael Hansen, Universität Lyngy, Dänemark, 04/1982–06/1982
  • Ulrich Herrmann, Doktorand, FernUniversität Hagen, 09/1986–10/1989
  • Ulrich Kessler, Universität Hamburg, 02/1980–01/1981
  • Klaus Küspert, Universität Kaiserslautern, 01/1985–03/1986, danach als WZH-Mitarbeiter
  • Gunter Saake, TU Braunschweig, 04/1988–04/1989
  • Maria Rita Scalas, Universität Bologna, Italien, 02/1986–01/1987
  • H.-J. Schneider, TU Berlin, 09/1983–03/1984 und 10/1986–03/1987
  • Jukka Teuhola, Universität Turku, Finnland, 01/1986–12/1986
  • Roland Traunmüller, Universität Linz, Österreich, 10/1980–09/1981
  • Hartmut Wedekind, Universität Erlangen/Nürnberg, 04/1983–09/1983
  • Lutz Wegner, FH Fulda, 07/1986–09/1986
  • Hans-Dieter Werner, Universität Dortmund, 02/1983–07/1984
  • John Woodfill, University of California at Berkeley, USA, 03/1983–07/1984

Forschungskooperationen[Bearbeiten | Quelltext bearbeiten]

  • TH Darmstadt (Workstation-Server-Kooperation): Hans-Jörg Schek, Uwe Depisch, Volker Obermeit
  • FernUniversität Hagen (Engineering Design Versions / Textindex): Gunter Schlageter, Wolfgang Wilkes, Ulrich Prädel
  • Universität Karlsruhe (R2D2): Peter Lockemann, Rüdiger Dillmann, Alfons Kemper, Mechthild Wallrath, Martin Dürr, Martin Huck

Referenzen[Bearbeiten | Quelltext bearbeiten]

  1. a b c d e Albrecht Blaser: The Heidelberg Science Center: User Oriented Informatics and Computers in Science. Röhm GmbH, Druckerei und Verlag, Sindelfingen, 2001, ISBN 3-920799-23-2 (uni-jena.de).
  2. T. Härder, A. Reuter: Architektur von Datenbanksystemen für Non-Standard-Anwendungen. In: Datenbank-Systeme für Büro, Technik und Wissenschaft. Band 94. Springer Berlin Heidelberg, Berlin, Heidelberg 1985, ISBN 978-3-540-15196-8, S. 253–286, doi:10.1007/978-3-642-70284-6_21 (springer.com [abgerufen am 25. Februar 2023]).
  3. 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. Band 94. Springer Berlin Heidelberg, Berlin, Heidelberg 1985, ISBN 978-3-540-15196-8, S. 362–381, doi:10.1007/978-3-642-70284-6_26 (springer.com [abgerufen am 13. Februar 2023]).
  4. 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, Massachusetts 1984, ISBN 978-0-89791-128-3, S. 115, doi:10.1145/602259.602276 (acm.org [abgerufen am 1. März 2023]).
  5. H.-J. Schek, M.H. Scholl: The relational model with relation-valued attributes. In: Information Systems. Band 11, Nr. 2, Januar 1986, S. 137–147, doi:10.1016/0306-4379(86)90003-7 (elsevier.com [abgerufen am 18. Februar 2023]).
  6. H. B. Paul, H. J. Schek, M. H. Scholl: Architecture and implementation of the Darmstadt database kernel system. ACM Press, 1987, ISBN 978-0-89791-236-5, S. 196–207, doi:10.1145/38713.38737 (acm.org [abgerufen am 29. Juli 2023]).
  7. R. Lorie, H. -J. Schek: On dynamically defined complex objects and SQL. In: Advances in Object-Oriented Database Systems. Band 334. Springer Berlin Heidelberg, Berlin, Heidelberg 1988, ISBN 978-3-540-50345-3, S. 323–328, doi:10.1007/3-540-50345-5_30 (springer.com [abgerufen am 18. Februar 2023]).
  8. Lutz Wegner: ESCHER — interaktive, graphische Darstellung komplexer Objekte auf der Basis des erweiterten NF2-Datenmodells. In: Graphik im Bürobereich. Band 192. Springer Berlin Heidelberg, Berlin, Heidelberg 1988, ISBN 978-3-540-50543-3, S. 127–141, doi:10.1007/978-3-642-74276-7_11 (springer.com [abgerufen am 1. März 2023]).
  9. Lutz M. Wegner: Let the fingers do the walking: Object manipulation in an NF2 database editor. In: New Results and New Trends in Computer Science. Band 555. Springer-Verlag, Berlin/Heidelberg 1991, ISBN 978-3-540-54869-0, S. 337–358, doi:10.1007/bfb0038201 (springer.com [abgerufen am 8. März 2023]).
  10. a b 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 (springer.com [abgerufen am 1. März 2023]).
  11. a b 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 (elsevier.com [abgerufen am 1. März 2023]).
  12. Cristina De Castro, Fabio Grandi, Maria Rita Scalas: On Schema Versioning in Temporal Databases. In: Recent Advances in Temporal Databases. Springer London, London 1995, ISBN 978-3-540-19945-8, S. 272–291, doi:10.1007/978-1-4471-3033-8_15 (springer.com [abgerufen am 1. März 2023]).
  13. Volker Linnemann: Grammatiken und Syntaxbäume in Datenbanken. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Springer Berlin Heidelberg, Berlin, Heidelberg 1993, ISBN 978-3-540-56487-4, S. 403–412, doi:10.1007/978-3-642-86096-6_28 (springer.com [abgerufen am 8. März 2023]).
  14. a b 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 [abgerufen am 18. Februar 2023]).
  15. a b 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, California 1982, ISBN 978-0-89791-070-5, S. 124, doi:10.1145/588111.588133 (acm.org [abgerufen am 18. Februar 2023]).
  16. a b 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]).
  17. 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]).
  18. Kalervo Järvelin, Timo Niemi: An NF 2 relational interface for document retrieval, restructuring and aggregation. ACM Press, 1995, ISBN 978-0-89791-714-8, S. 102–110, doi:10.1145/215206.215343 (acm.org [abgerufen am 30. Juli 2023]).
  19. 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 (sciencedirect.com [abgerufen am 30. Juli 2023]).
  20. 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 (acm.org [abgerufen am 31. Juli 2023]).
  21. 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 (ieee.org [abgerufen am 30. Juli 2023]).
  22. 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]).
  23. 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]).
  24. 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 (sciencedirect.com [abgerufen am 30. Juli 2023]).
  25. 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 (sciencedirect.com [abgerufen am 30. Juli 2023]).
  26. 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 (acm.org [abgerufen am 5. August 2023]).
  27. 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 (springer.com [abgerufen am 31. Juli 2023]).
  28. a b Diana Lorentz: Oracle 8 - SQL Reference, Release 8.0. Hrsg.: Oracle Corporation. 1997, S. 4–126 ff. (oracle.com [PDF]).
  29. a b c 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 (springer.com [abgerufen am 3. August 2023]).
  30. a b c d e 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 (acm.org [abgerufen am 25. Februar 2023]).
  31. Peter Dadam: Vorlesung Datenbanksysteme: Konzepte und Modelle, Universität Ulm, WS 2013/14. Kapitel 4: Netzwerk-Datenmodell, 2013 (researchgate.net).
  32. Peter Dadam: Vorlesung Datenbanksysteme: Konzepte und Modelle, Universität Ulm, Wintersemester 2013/14. Kapitel 3: Hierarchisches Datenmodell, 2013 (researchgate.net).
  33. P. Dadam: Extending database technology towards object orientation: for whom, why, and for what? In: [1991] Proceedings, Advanced Computer Technology, Reliable Systems and Applications. IEEE Comput. Soc. Press, Bologna, Italy 1991, ISBN 978-0-8186-2141-3, S. 398–405, doi:10.1109/CMPEUR.1991.257418 (ieee.org [abgerufen am 8. März 2023]).
  34. 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 (sciencedirect.com [abgerufen am 5. August 2023]).
  35. 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 (acm.org [abgerufen am 29. Juli 2023]).
  36. a b 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. Band 94. Springer Berlin Heidelberg, Berlin, Heidelberg 1985, ISBN 978-3-540-15196-8, S. 441–459, doi:10.1007/978-3-642-70284-6_30 (springer.com [abgerufen am 28. Februar 2023]).
  37. Gunter Saake, Ingo Schmitt, Can Türker: Objektdatenbanken - Konzepte, Sprachen, Architekturen. International Thomson Publishing, 2003, ISBN 3-8266-0258-7 (uni-magdeburg.de [PDF]).
  38. Gunter Saake, Kai-Uwe Sattler, Andreas Heuer: Datenbanken - Konzepte und Sprachen. Ergänzendes pdf-Kapitel. 6. Auflage. mitp, Frechen 2018, ISBN 978-3-95845-776-8 (mitp.de [PDF]).
  39. Joachim Fischer: Datenmanagement: Datenbanken und betriebliche Datenmodellierung. De Gruyter, 1992, ISBN 978-3-486-78418-3, doi:10.1515/9783486784183 (degruyter.com [abgerufen am 1. März 2023]).
  40. Klemens Böhm: Datenbankeinsatz: Relationale Algebra. 2004, abgerufen am 28. Februar 2023.
  41. Peter Dadam: Datenbanksysteme - Konzepte und Modelle - Relationales Datenmodell III: NF2 -und eNF2 -Relationenmodell. 2013 (researchgate.net).
  42. Uwe H. Suhl: Datenmodellierung und Datenbanksysteme, Vorlesung, Lehrstuhl für Wirtschaftsinformat, FU Berlin. 2005 (fu-berlin.de [PDF]).
  43. Kai-Uwe Sattler, Gunter Saake: Vorlesung Datenbanksysteme, Wintersemester 2019/2020, TU Ilmenau. 2019 (tu-ilmenau.de [PDF]).
  44. Sven Theleman: Semantische Anreicherung eines Datenmodells für komplexe Objekte. Dissertation, Fachbereich Mathematik/Informatik der Universität Gesamthochschule Kassel. 1996 (uni-kassel.de [PDF]).
  45. Mechthild Wallrath: Entwicklung ingenieurwissenschaftlicher Datenbankanwendungen. FZI-Fachberichte. Springer, 1994, ISBN 978-3-540-55720-3.
  46. 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]).
  47. 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]).
  48. 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 (elsevier.com [abgerufen am 7. März 2023]).
  49. Henry F. Korth, Mark A. Roth: Query languages 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. 190–204, doi:10.1007/3-540-51171-7_27 (springer.com [abgerufen am 8. März 2023]).
  50. Klaus Benecke: Geschachtelte Relationen. In: Strukturierte Tabellen. Deutscher Universitätsverlag, Wiesbaden 1998, ISBN 978-3-8244-2099-5, S. 39–47, doi:10.1007/978-3-663-09008-3_2 (springer.com [abgerufen am 8. März 2023]).
  51. Uwe Hohenstein: Eine SQL-ähnliche Anfragesprache für das EER-Modell. In: Formale Semantik eines erweiterten Entity-Relationship-Modells. Vieweg+Teubner Verlag, Wiesbaden 1993, ISBN 978-3-8154-2052-2, S. 161–178, doi:10.1007/978-3-663-12118-3_8 (springer.com [abgerufen am 8. März 2023]).
  52. E. Andonoff, M. Canillac, C. Mendiboure, G. Zurfluh: Hypertext Interface for an Object-oriented Database. In: Intelligent Text and Image Handling. Vol. 2. Le Centre de Hautes Etudes Internationales d'Informatique Documentaire, Paris, France 1991, S. 843–862 (acm.org).
  53. De Lima, Jose Valdeni, Henri Galy: The Integration of Structured Documents into DBMS. In: Proceedings of the International Conference on Electronic Publishing, Document Manipulation & Typography, Gaithersburg, Maryland, USA. Cambrigde University Press, Cambridge, U.K. 1990, ISBN 0-521-40246-8, S. 153–168.
  54. Alfons Kemper, Peter C. Lockemann, Mechtild Wallrath: An object-oriented system for engineering applications. In: Proceedings of the 1987 ACM SIGMOD international conference on Management of data - SIGMOD '87. ACM Press, San Francisco, California, United States 1987, ISBN 978-0-89791-236-5, S. 299–310, doi:10.1145/38713.38747 (acm.org [abgerufen am 8. März 2023]).
  55. 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 (elsevier.com [abgerufen am 8. März 2023]).
  56. J. Günauer, W. Manus: Austausch komplexer Datenbank-Objekte in einer heterogenen Workstation-Server-Umgebung. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Band 270. Springer Berlin Heidelberg, Berlin, Heidelberg 1991, ISBN 978-3-540-53861-5, S. 140–160, doi:10.1007/978-3-642-76530-8_8 (springer.com [abgerufen am 8. März 2023]).
  57. C.J. Date, Hugh Darwen: Foundation for Future Database Systems: The Third Manifesto. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, United States 2000, ISBN 978-0-201-70928-5.
  58. C.J. Date, Hugh Darwen: Databases, Types, and the Relational Model - The Third Manifesto. 3. Edition Auflage. 2014 (warwick.ac.uk [PDF]).