Zum Inhalt springen

Advanced Information Management Prototype

Links hinzufügen
aus Wikipedia, der freien Enzyklopädie
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 | Artikel eintragen
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 Zentrums der IBM in Heidelberg (WZH) 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 NF2-Relationen" (eNF2-Relationen), der darauf abgestimmten SQL-ähnlichen Abfragesprache 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 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 eNF2-Relationen zum effizienten Zugriff sowohl auf ein eNF2-Objekt als Ganzes als auch auf dessen Teile[3][4][5] und die tief im Systemkern verankerte Unterstützung der Zeitversionen[6][7][8].

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 ca. 70 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 NF2-/eNF2-Ansatz) inspirierte weltweit zahlreiche Forschungsaktivitäten (wie z. B. in Australien[9], Finnland[10][11], Frankreich[12][13], Italien[14], Japan[15], Kanada[16], Niederlande[17][18] und den USA[19][20][21]). Teile des NF2-/eNF2-Ansatzes wurden später auch in kommerzielle relationale DBMS integriert (wie z. B. 1997 in Oracle Version 8[22] und 1999 in Informix Dynamic Server.2000[23]) und gingen z.T. auch in den SQL-Standard ab SQL:2003[24] ein, allerdings in einer im Vergleich zum AIM-P-Ansatz stark eingeschränkten Form.

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 ingenieurwissenschaftliche[25], während es in Heidelberg Dokumentenretrieval-Anwendungen[1][26] 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 Reab]) 1NF-Relationen ausgerichteten DBMS-Kern nicht anrührte und es mit einem „On-Top“-Ansatz versuchte[25], 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 NF2-Relationen)[27] und skizzierte auch einen Sprachvorschlag zur Erweiterung der Datenbank-Abfragesprache SQL[26].

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 NF2-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 Abfragen und die daraus resultierenden Anforderungen an das DBMS zu ermitteln[28].

Die hierbei gewonnen Erkenntnisse ließen erkennen, dass auch das NF2-Relationenmodell nicht alle Anforderungen abdecken kann, sondern dass ein noch mächtigeres Datenmodell, eine dazu passende Abfragesprache 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[28].

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 als Proof of Concept erprobt werden können. Dieser Prototyp erhielt den Namen „Advanced Information Management Prototype (AIM-P)“[1][29]. Seine Architektur mit den wichtigsten Komponenten ist in Abb. 1 dargestellt.

Abb. 1: Architektur des AIM-P-Datenbankservers

Konventionelle relationale DBMS und das „Complex Object“-Problem

[Bearbeiten | Quelltext bearbeiten]

Für die „vor-relationalen“ DBMS, die auf dem hierarchischen Datenbankmodell oder dem Netzwerk-Datenbankmodell basieren ist typisch, dass man sich das gewünschte Abfrageergebnis in der Regel mit Folgen von einzelnen Datenbankabfragen quasi stückweise zusammensuchen muss. (Ausführliche Abfragebeispiele zu diesen DBMS finden sich z. B. in[30] und[31].) Im Gegensatz dazu ermöglichen relationale DBMS, solche Datenbankabfragen mit einem einzigen Abfrageausdruck zu erledigen. Ermöglicht wird dies durch die diesem Datenmodell zugrundeliegende Relationenalgebra bzw. die darauf aufbauende Abfragesprache SQL. Die Relationenalgebra setzt voraus, dass alle Daten als 1NF-Relationen gespeichert werden.

Bei relativ einfach strukturierten Daten, wie sie z. B. im kaufmännischen Bereich vorkommen, funktionieren deren Abbildung auf 1NF-Relationen sowie Datenbankabfragen 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. Betrachten wir als (stark vereinfachtes) Beispiel[32] die Speicherung der Daten von Robotern, wie in Abb. 2 illustriert (den Gelenken sind sog. DH-Matrizen zugeordnet, die zur Berechnung von Bewegungsabläufen 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.

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

Eine typische Datenbankabfrage 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.

Abb. 4: SQL-Abfrage: „Gib alle Daten zu Roboter 'Rob1' aus“
Abb. 5: Resultat-Tabelle für Abfrage in Abb. 4

Durch die 1NF-Ergebnisdarstellung (und nur diese gibt es in relationalen DBMS) 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. 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. Abfragen 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-Abfragen auf der relationalen Datenbank aus, wobei der „Output“ einer Abfrage in der Regel den „Input“ für die nachfolgende Abfrage 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.

Abb. 6 Iterierende SQL-Abfragen gegen die Roboter-Tabellen

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-Abfrage überhaupt so formulieren zu können, dass sie das gewünschte Ergebnis liefert.

NF2- und eNF2-Relationenmodell

[Bearbeiten | Quelltext bearbeiten]

NF2-Relationenmodell

[Bearbeiten | Quelltext bearbeiten]

Wie im Abschnitt „Vorgeschichte“ erwähnt, waren das am WZH entwickelte NF2-Relationenmodell[27] in Verbindung mit Sprachvorschlägen für eine dazu passende SQL-ähnliche Abfragesprache[26][33], 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.

Abb. 7: Roboter-Tabelle als NF2-Relation

Das NF2-Relationenmodell

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

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

  1. Speicherung als strukturiertes NF2-Datenobjekt (d.h. als Tupel einer NF2-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 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 und über beide Wege dann auch Änderungsoperationen (Updates) unterstützen.[34]

eNF2-Relationenmodell

[Bearbeiten | Quelltext bearbeiten]

Das NF2-Relationenmodell stellt zwar für technisch-wissenschaftliche Anwendungen bereits einen wichtigen Schritt in die richtige Richtung dar, ist aber hinsichtlich der Vielfalt der Datenstrukturen, die in solchen Anwendungen benötigt werden[44][45][46], bei weitem noch nicht ausreichend. Die Entwicklung vom NF2 zum endgültigen "erweiterten NF2-Relationenmodell (kurz: eNF2-Relationenmodell) war ein iterativer Prozess verbunden mit sukzessiven Erweiterungen des NF2-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[32].) Das finale eNF2-Relationenmodell war auch stark von den bei dem Entwurf der dazu passenden Datenbankabfragesprache gewonnenen Einsichten geprägt (siehe Abschnitt Abfragesprache (HDBL)) und kennt nur noch 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. Jedes so erzeugte Objekt ist ein strukturell legales Objekt des eNF2-Relationenmodells. Es kann als Ergebnisobjekt in Abfragen und in Zwischenergebnissen von geschachtelten Abfrageausdrücken auftreten und auch in einer eNF2-Datenbank gespeichert werden[28]. - Die für das eNF2-Relationenmodell entwickelte Relationenalgebra[29][28] (die leider nie in Gänze publiziert wurde), ermöglicht ebenfalls eine systemseitige Abfrageoptimierung, ist naturgemäß jedoch komplexer als bei 1NF-Relationen.[47][29]

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

Bei Verwendung des eNF2-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.)

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

Speicherstrukturen für das NF2-/eNF2-Relationenmodell

[Bearbeiten | Quelltext bearbeiten]

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 Abfrage verknüpfen würde, ebenfalls in einer passenden NF2-Struktur, quasi als „vorberechnete Joins“[40] 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 eNF2-Objekte – in AIM-P als „Mini-Directories“ (MD) bezeichnet – werden getrennt von den Nutzdaten gespeichert. Mittels physisch benachbarter Speicherung („clusterung“) der MD-Datensätze eines eNF2-Objektes konnte man dessen Strukturinformation daher 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[32].

Abfragesprache (HDBL)

[Bearbeiten | Quelltext bearbeiten]

Vorbemerkungen

[Bearbeiten | Quelltext bearbeiten]

Die bahnbrechende Neuerung bei der Entwicklung des relationalen Datenmodells durch E.F. Codd[48] war die konsequente Speicherung aller Daten als Relationen mit 1NF-Tupeln als Datensätzen 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 Abfrageoptimierern in relationalen DBMS.

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

Die in den relationalen DBMS verwendete Datenbankabfragesprache 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 NF2 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 eNF2-Datenmodell hat diese Art von Problemen nicht, da all die zuvor beschriebenen nicht-1NF-konformen Zwischen- und Endzustände legale Strukturen des eNF2-Relationenmodells darstellen. Allerdings ist natürlich die Anzahl der Operatoren der eNF2-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[49],[50][51] und[52].

Herausforderungen und grundlegende Entwurfsentscheidungen

[Bearbeiten | Quelltext bearbeiten]

Bei der in Abb. 4 dargestellten SQL-Abfrage sieht man bereits, 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 Datenbankabfrage auch für einen erfahrenen SQL-Anwender herausfordernd sein.

Bei einem sehr viel mächtigeren Datenmodell wie den eNF2-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 eine Abfragesprache mit klaren, leicht verständlichen Regeln sowie mit einem (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 eNF2-Datenmodell entwickelte Datenbankabfrage und -Manipulationssprache HDBL (ein Akronym für „Heidelberg Database Language“[28]) wurde unter Beachtung dieser Vorgaben entworfen und in wesentlichen Teilen prototypisch in AIM-P implementiert[49][50]. 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 Abfrage-Operatoren der zugrundeliegenden eNF2-Relationenalgebra (wie z. B. GROUP-BY .. HAIVING 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 und Listen von Tupeln in HDBL zuständig ist. Das SFW-Konstrukt kann z. B. auch für die Sortierung verwendet von Mengen und Listen von Tupeln verwendet werden, man kann aber – wie im HDBL-Beispiel 3 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.

Es gibt auch klare Regeln welche Abfrageoperation welche Strukturtypen als Input erwartet und welchen sie als Output zurück gibt. Hierbei wird eine starke Typisierung („strong typing“) verfolgt. So kann z. B. der vorher erwähnte Sortier-Operator nur auf Listen von Objekten angewandt werden. Falls die Ausgangsdaten als Menge vorliegen, dann muss dem Sortieren eine Typwandlung Menge → Liste (mittels MLIST-Operator) vorgeschaltet werden. Wenn das SFW-Konstrukt mit der ORDER-BY-Klausel versehen ist, dann ist der Ergebnistyp immer vom Typ 'Liste', auch wenn 'Menge' der Input-Typ war.[51]

Im folgenden exemplarisch einige Anwendungsbeispiele von HDBL mit dem SELECT-FROM-WHERE-Konstrukt, die im Wesentlichen aus[32] entnommen wurden. Sehr viele weitere Beispiele, insbesondere auch zu INSERT, UPDATE und DELETE finden sich ebenfalls dort.

Abfragen mit dem SELECT-FROM-WHERE-Konstrukt

[Bearbeiten | Quelltext bearbeiten]

Wie bereits oben erwähnt verwendet HDBL das SFW-Konstrukt zur Formulierung von Selektionen und Projektionen auf 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:

Die folgenden Abfragebeispiele beziehen sich auf die in Abb. 3 dargestellten 1NF-Relationen

Beispiel Q1: Abfrage 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“.

Abb. 10: Abfrage für Bsp. Q1

Die eckigen Klammern in der SELECT-Zeile drücken explizit aus, dass das Ergebnis tupelstrukturiert sein soll. Durch die Sortierung ist der Resultattyp dieser Abfrage 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 Abfrageergebnis

Aufgabe: „Gib die IDs aller Roboter aus“.

Abb. 11: Alternative Abfragen für Bsp. Q2

Da wir in der Abfrage keine Sortierung spezifiziert haben, 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: Abfrage-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.

Abb. 12: Abfrage zu Bsp. Q3
Die folgenden Beispiele beziehen sich auf die in Abb. 7 dargestellte RobotsNF2-Relation

Beispiel Q4: Einfache Selektions-Abfragen mit Resultatstruktur wie gespeichert

Aufgabe: „Gib alle Roboter aus“ sowie „Gib alle Roboter aus, die den Endeffektor 'SR200' anschließen können“

Abb. 13: Abfragen mit und ohne Selektionsbedingungen zu Bsp. Q4


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')“

Abb. 14a: Gewünschte Ausgabe in Bsp. Q5
Abb. 14b: Abfrage zu Bsp. Q5

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

Abb. 15a: Gewünschte Ausgabe-Struktur in Bsp. Q6
Abb. 15b: Abfrage zu Bsp.-Q8

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

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

Abb. 16: Anfrage zu Bsp. Q7


Beispiel Q8: Erstellung einer geschachtelten eNF2-Relation mit listenwertigen Attributen auf verschiedenen Ebenen

Aufgabe: „Gib auf Basis der 1NF-Relationen aus Abb. 3 eine geschachtelte eNF2-Ergebnis-Relation à la Robots_eNF2 aus Abb. 9 aus“

Abb. 18: Abfrage zu Bsp. Q8

Zu erwähnen ist noch, dass alle diese Anfrageergebnisse auch legale Datenbankobjekte in HDBL sind und daher z. B. auch mittels INSERT-Operation in die Datenbank eingefügt werden können.

Unterstützung temporaler Daten

[Bearbeiten | Quelltext bearbeiten]

Sowohl das Anfang der 1980er Jahre wiederauflebende Interesse in der wissenschaftlichen Welt an der Unterstützung zeit-versionierter Daten in Datenbanksystemen (siehe z. B.[53][54]) 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.[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“,[55] 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 (siehe [6][7] für weitere Details).

Abb. 19: Speicherung temporaler Daten in AIM-P

Abb. 19 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-Eintrag ein spezielle Delta-Index, der anzeigt, der direkt auf zwischendurch angelegten Vollversionen verweist. Allle 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.

Workstation – DB-Server – Kooperation

[Bearbeiten | Quelltext bearbeiten]

Bereits Anfang der 1980er Jahre war absehbar, dass die bis dahin rein zentralrechner-basierten CAD-Anwendungen im Laufe der Jahre mehr auf sog. „CAD-Workstations“ verlagert werden.[38] Das zentrale Datenbanksystem wird mehr und mehr primär vor allem zur Zwischen- und endgültigen Speicherung der auf den CAD-Workstations erstellten Modelle benutzt.

Benutzerdefinierte Datentypen und Funktionen

[Bearbeiten | Quelltext bearbeiten]

Die 1986 von Michael Stonebraker[56] publizierte Idee, die relationalen DBMS mit benutzerdefinierten Typen und Funktionen zu erweitern, inspirierte auch das AIM-P-Entwicklungsteam.

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  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. ↑ 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 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 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 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. ↑ P. Dadam. R., K. Staab: Subtuple Manager – External Interface Description, Release 1.1. Hrsg.: IBM Heidelberg Scientific Center. 26. November 1984 (researchgate.net).
  9. ↑ 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]).
  10. ↑ 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.
  11. ↑ 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.
  12. ↑ 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.
  13. ↑ 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.
  14. ↑ 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]).
  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. ↑ Diana Lorentz: Oracle 8 – SQL Reference, Release 8.0. Hrsg.: Oracle Corporation. 1997 (oracle.com [PDF]).
  23. ↑ Informix Guide to SQL – Tutorial. Dezember 1999 (uni-kl.de [PDF]).
  24. ↑ 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.
  25. ↑ 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.
  26. ↑ 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]).
  27. ↑ a b c d 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]).
  28. ↑ a b c d e 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.
  29. ↑ 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]).
  30. ↑ Peter Dadam: Datenbanksysteme: Konzepte und Modelle, Vorlesung Universität Ulm, WS 2013/2014. 2013, 3: Hierarchisches Datenmodell.
  31. ↑ Peter Dadam: Datenbanksysteme: Konzepte und Modelle, Vorlesung Universität Ulm, WS 2013/14. 2013, 4: Netzwerk-Datenmodell (researchgate.net).
  32. ↑ a b c d Peter Dadam: Datenbanksysteme – Konzepte und Modelle, Vorlesung Universität Ulm, WS 2013/14. 2013, 7: Relationales Datenmodell III: NF2 -und eNF2 -Relationenmodell (researchgate.net).
  33. ↑ 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.
  34. ↑ 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.
  35. ↑ 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.
  36. ↑ 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.
  37. ↑ 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.
  38. ↑ a b 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.
  39. ↑ 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.
  40. ↑ 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.
  41. ↑ Volker Linnemann: Funktional rekursive Anfragen 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.
  42. ↑ 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.
  43. ↑ 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.
  44. ↑ 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.
  45. ↑ 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.
  46. ↑ 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.
  47. ↑ 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]).
  48. ↑ 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.
  49. ↑ a b 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.
  50. ↑ 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]).
  51. ↑ a b 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]).
  52. ↑ 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]).
  53. ↑ 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.
  54. ↑ 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.
  55. ↑ Peter Dadam: Updatestrategien und Protokollierung von Änderungsoperationen. In: Vorlesung Database Internals, Universität Ulm, Sommersemester 2014. 2014, S. 40–45.
  56. ↑ Michael Stonebraker: Inclusion of New Types in Relational Data Base Systems. In: Proc.Second International Conference on Data Engineering (ICDE), Los Angeles, Calif., USA. IEEE Computer Society, 1986, ISBN 0-8186-0655-X, S. 262–269, doi:10.1109/ICDE.1986.7266230.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Advanced_Information_Management_Prototype&oldid=264634554“