Benutzer:Dokumentarix/Advanced Information Management Prototype

Der „Advanced Information Management Prototype (AIM-P)“^[1]^[2]^[3]^[4]^[5] gehörte in den 1980er und 1990er Jahren zu den bekanntesten^[6]^[7]^[8]^[9] experimentellen „Next Generation“-Datenbanksystemen zur Unterstützung konventioneller und technisch-wissenschaftlicher Anwendungen. Das in diesem Kontext weiterentwickelte relationale Datenmodell wurde unter dem Namen NF² (Non First Normal Form Relations) weltweit bekannt und dessen Weiterentwicklung zum „Erweiterten NF²-Relationenmodell“ (eNF²) hat sogar die Entwicklung des SQL-Standards und die Weiterentwicklung der kommerziellen relationalen Datenbanksysteme beeinflusst.

Eine ausführliche Beschreibung der Entstehungsgeschichte dieser Datenmodelle, der formalen Grundlagen des NF2-Relationenmodells (erweiterte Relationenalgebra) sowie der Gründe für die Weiterentwicklung zum eNF²-Relationenmodell nebst Anfragebeispielen findet sich in den Wikipedia-Einträgen NF²-Relationen und Erweiterte NF²-Relationen.

Die Entwicklung von AIM-P fand am Wissenschaftlichen Zentrum der IBM in Heidelberg (WZH) im Forschungsbereich „Advanced Information Management“ (AIM) statt.

Dieser Beitrag befasst sich mit der

Entwicklungsgeschichte von AIM-P und den während dieser Zeit gewonnenen Erkenntnissen
Systemarchitektur von AIM-P
systeminternen Implementierung des eNF²-Datenmodells und der damit verbundenen Performanzaspekte
Realisierung der Programmierschnittstelle (API) für das eNF²-Relationenmodell
Nutzung des eNF²-Datenmodells für die Realisierung benutzerdefinierter Datentypen und Funktionen
Unterstützung von Zeitversionen
Nutzung von "fremden" Indexen
kooperativen Objektbearbeitung mittels Workstation und Datenbank-Server
Unterstützung "langer" Transaktionen und anderer Aspekte der Synchronisation konkurrierender Transaktionen (Concurrency Control)

Sofern noch keine oder geringe Vorkenntnisse zu NF²-Relationen und Erweiterten NF²-Relationen vorhanden sind, bietet es sich an zunächst diese beiden Beiträge lesen, bevor man hier weiterliest.

Vorgeschichte

Ende der 1970er Jahre experimentierten Wissenschaftler am IBM Research Laboratory in San Jose (dem späteren IBM Almaden Research Center) und am WZH mit den Einsatz von System R in Anwendungen, in denen komplex strukturierte Datenobjekte zu verwalten waren. In San Jose waren dies technisch-wissenschaftliche, während es in Heidelberg Dokumentenretrieval-Anwendungen war. Beide Gruppen kamen 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. Die folgenden Abbildungen zeigen die (stark vereinfachte) Modellierung eines Roboters (Abb. 1), die Speicherung seiner Daten in relationaler Form (Abb. 2), eine SQL-Anfrage, um alle Daten zu Roboter 'Rob1' auszugeben (Abb. 3) und die für einen Endanwender völlig unbrauchbare Form der Ergebnisdarstellung einer solchen Anfrage (Abb. 4).

**Abb. 2: Relationale Speicherung der Roboter-Daten**

**Abb. 4: Anfrageergebnis für Roboter 'Rob1'**

Während man in San Jose den auf flache Relationen ausgerichteten Datenbankkern nicht anrührte und es mit einem „On-Top“-Ansatz versuchte^[11]^[12], tauchte man am WZH tief in die relationale Theorie und die zugrundeliegende Relationenalgebra ein^[13] und entwickelte das NF²-Relationenmodell, bei dem die Werte der Attribute von Relationen nicht mehr zwingend atomar sein müssen, sondern auch selbst wieder Relationen sein können.^[14]

Nachdem diese Schwächen der in Entwicklung befindenden relationalen Datenbanksysteme erkannt wurden und Datenbanksysteme für die IBM ein strategisch sehr wichtiges Geschäftsfeld waren, 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 nach Möglichkeit geeignete Lösungskonzepte zu entwickeln.

AIM – die ersten Anfänge

Das WZH hatte sich bereits vor Einrichtung der AIM-Abteilung u. a. intensiv mit dem Thema Dokumentenretrieval und hier insbesondere mit Indexierungstechniken zur Unterstützung unscharfer Anfragen („partial-match queries“) befasst und zur Verbesserung der IBM-Produkte für die Verwaltung von Texten, wie z. B. STAIRS und dessen Nachfolgerprodukte, beigetragen.^[15]^[16] – Mit der damals gerade im Kommen befindlichen relationalen Datenbanktechnologie wuchs auch am WZH das Interesse, Datenbank- und Dokumentenretrieval-Technology derart zusammen zu bringen, dass damit „Integrierte Informatonssysteme“ realisiert werden können, welche die Fähigkeiten beider Systemwelten in integrierter Weise anbieten können. Neben der Frage der geeigneten Repräsentation von strukturierten Textdokumenten im Datenmodell, die schließlich zur Entwicklung NF²-Relationen führten, waren natürlich auch die Themen „Indexunterstützung“ für die Textsuche^[17] sowie die Integration geeigneter Suchfunktionen in die SQL-Sprache von Interesse.^[14]

Explorationsphase und frühe Entwurfs-Entscheidungen

Explorationsphase

Ende 1982 begann eine Explorationsphase, die sich mit Unterbrechungen über mehr als ein Jahr hinzog, während dieser die AIM-Gruppe sowohl mittels Literaturstudium, als auch durch Vor-Ort-Besuche sehr viele unterschiedliche Anwendungsgebiete daraufhin untersuchte, welche spezifischen Eigenschaften ein Datenbanksystem aus Anwendersicht (Endanwender oder Anwendungsentwickler) haben sollte, um die jeweilige Aufgabenstellung datenbankseitig möglichst optimal zu unterstützen. Das Credo hierbei: „Es wird kein Problem 'wegdefiniert'“. Insbesondere durch die Diskussion mit Anwendern kamen viele Anregungen und Hinweise auf andere Anwendungsgebiete hinzu, die man vorher gar nicht auf dem „Radar“ hatte. Nachstehend eine Auswahl der Anwendungsbereiche, mit denen man sich in dieser Phase näher befasst hat:

Dokumentenretrieval (war quasi „gesetzt“)
Büroanwendungen mit ihrem typischen Datenmix
Geo-Informationssysteme
Systeme zur Aufzeichnung und Auswertung der Daten von Erdbeobachtungssatelliten
Computer Integrated Manufacturing, mit den Teilbereichen
Kataster- und Standesämter (in beiden müssen alle Änderungen stets und jederzeit nachvollziehbar sein)

In einem Geo-Informationssystem kann man z. B. Grundstücke verwalten und würde hierfür Informationen wie etwa Eigentümer, Beschreibung, Fläche, Umfang, umschließender Streckenzug (Polygon), angrenzende Grundstücke u.v.a.m. speichern, um auch Anfragen der folgenden Art beantworten können: „Welche Grundstücke würde die geplante Hochspannungsleitung von A nach B überqueren?“

Iterativer Entwurfs- und Entwicklungsprozess

Im Prinzip startete man mit dem NF²-Relationenmodell + spezieller Unterstützung für Text-Attribute und fügte diesem in einem iterativen Prozess immer weitere Elemente hinzu, die man in den oben skizzierten Untersuchungen als wichtig erkannt hat. Im Bereich Betriebsdatenerfassungssysteme sind sehr häufig Messreihen von Sensoren, also lange Listen von Zahlen zu speichern. Geoinformationssysteme benötigen u. a. Polygonzüge zur Modellierung von Straßen, Stromleitungen, Gebietsgrenzen usw., d. h. (lange) Listen von Tupeln mit 3D-Koordinaten und anderen beschreibenden Informationen. Ähnliches gilt für Erdbeobachtungssatelliten, nur dass da noch viel mehr Daten dieser Art anfallen und zudem auch noch Foto-Sequenzen. CAD-Systeme benötigen (noch) komplexere Strukturen der obigen Art, zudem u. a. auch häufig Matrizen, d. h. (zum Teil mehrfach) geschachtelte Listen von Zahlen.

Kataster- und Standesämter sowie viele Anwendungen, in denen Entwürfe (Dokumente, Bauskizzen, Projektkalulationen, ...) erarbeitet werden und man gelegentlich auch den Zugriff auf frühere Versionen benötigt, erfordern eine (zeit-)versionierte Datenspeicherung. Die typische Unterstützung solcher Anwendungen sieht auf Datenbankebene so aus, neue und alte Daten quasi gleichberechtigt behandelt und durch die Speicherung des Erstellungszeitpunkts oder eines Gültigkeits-Zeitintervalls als Tupel-Attribbut auf logischer Ebene in eine zeitliche Reihenfolge gebracht werden. Dies führt potenziell zu einer starken Aufblähung des Datenbestands und in der weiteren Folge zu längeren Antwortzeiten bei Zugriffen auf die aktuellen Daten.

Entwurfsziele

Parallel zur Sammlung der Anforderungen an das Datenmodell von AIM-P begann man eine geeignete SQL-ähnliche Datenbanksprache nebst Ausführungslogik für das NF²-Relationenmodell zu entwerfen^[14]^[18] und diese sukzessive für die jeweils neu hinzukommenden Strukturelemente zu erweitern. Hierbei gab es wichtige Ziele, die gemeinsam verfolgt werden mussten:

Die Datenbanksprache muss die strukturelle Mächtigkeit des Datenmodells (inkl. der temporalen Aspekte) voll unterstützen können
Die Datenbanksprache soll aufgrund klarer und einfacher Regeln einfach zu erlernen und zu verstehen sein
Die strukturellen Möglichkeiten des Datenmodells müssen so gestaltet werden, dass die Ziele 1 und 2 für die Datenbanksprache auch tatsächlich erreicht werden können

AIM-P – Entwicklung des Basis-Systems (1983–1985)

Zielsetzung und Herausforderungen

Die generelle Zielsetzung war, kein Mockup zu entwerfen und zu implementieren, sondern fundierte Lösungskonzepte zu entwickeln, prototypisch zu implementieren und in möglichst realitätsnahen Anwendungen zu erproben, so dass man Erkenntnisse für die Realisierung eines mögliches Datenbank-Produkt dieser Art gewinnen kann.

Die konkrete Zielsetzung für AIM-P war, ein „All-round“-Datenbank-Management-System konzipieren und prototypisch zu implementieren, das nach Möglichkeit nicht nur für technisch-wissenschaftliche, sondern auch für konventionelle Datenbankanwendungen einsetzbar ist. Um dies zu erreichen, muss man u. a. zwei Einsatzszenarien eines solchen Datenbanksystems mit sehr unterschiedlichen Anforderungen unter einen Hut bekommen. Im technisch-wissenschaftlichen Bereich geht es meist darum, die im Vergleich zu konventionellen Anwendungen sehr großen Datenobjekte als Ganzes möglichst rasch von der Festplatte des Externspeichers in das Anwendungsprogramm, d. h. in den Hauptspeicher laden zu können. Ein solches Objekt könnte z. B. das komplex strukturierte Tupel des Roboters 'Rob1' in der in Abb. 5 dargestellten Robot_eNF2-Relation sein, das in der Realität natürlich sehr viel größer und komplexer strukturiert wäre. Die geschweiften Klammern („{...}“) kennzeichnen ein Attribut als „mengenwertig“ und die spitzen Klammern („<...>“) als „listenwertig“.

Das rasche Einlesen eines solchen Tupels gelingt am besten dann, wenn man dessen Daten dicht an dicht so auf der Festplatte platziert, dass auf diese mit möglichst wenigen Bewegungen der Schreib-/Leseköpfe der Festplatte zugriffen werden kann. Interessiert man sich aber nur dafür, welche Roboter den Endeffector 'GR1200' anschließen können, wäre es natürlich fatal, wenn man alle Roboter-Tupel jeweils komplett lesen müsste, um an ihre Endeffector-Daten zu gelangen. Ähnliche Problemstellungen ergeben sich auch für konventionelle Anwendungen, wenn man aus Performanzgründen häufig zusammen benötigte Daten aus der 1NF-Welt intern als „vorberechnete Joins“ kompakt als NF² oder eNF²-Relation speichert, diese aber via Sichten „nach außen“ wie 1NF-Relationen aussehen lässt.^[19] – Wie AIM-P mit diesem Zielkonflikt umgegangen ist, wird im Abschnitt 'Speicherstrukturen für eNF²-Objekte' beschrieben.

System-Architektur

Zeitlich überlappend zu den oben beschriebenen Explorationen begannen bereits ab etwa Mitte 1983 die Entwurfs- und initialen Implementierungsarbeiten für AIM-P, wie z. B. für den Subtuple-Manager, mit dem alle Arten von system-internen Datensätzen (in AIM-P „subtuple“ genannt) realisiert werden sollten und der unter anderem auch für die Realisierung der zeitversionierten Speicherung vorgesehen war.^[20] Der Entwurf sah vor, dass AIM-P über die folgende Funktionalitäten verfügen sollte: ^[2]^[3]^[18]

Unterstützung (der bereits bekannten Teile) des eNF²-Relationenmodells (dies waren NF² + Listen von Tupeln + „lange Felder“^[11])
Effizienter Zugriff sowohl auf eNF²-Objekte als Ganzes als auch deren Teile
Realisierung zeitversionierter Relationen
Indexbasierte Unterstützung der Textsuche
Interaktive Schnittstelle für Anfragen und Ergebnisdarstellung
SQL-artige Datenbanksprache

Abb. 6 illustriert die für AIM-P gewählte System-Architektur^[4]. Der Query Processor parst die HDBL-Anfrage- oder Änderungsoperation und holt sich hierzu via Catalog Manager die Stukturinformationen zu den hierbei angesprochen Datenbankobjekten. Er ist auch zuständig für die Anfrageoptimierung sowie Zugriffspfadauswahl sowie für die Ausführung dieser Anfrage- oder Änderungsoperation. Der Complex Object Manager realisiert für den Query Processor eine semantisch hohe abstrakte Sicht auf die Datenobjekte, die deren logische (Schachtelungs-)Struktur widerspiegelt, aber von den konkreten Realisierungsdetails der hierfür verwendeten Datenstrukturen abstrahiert. Der Subtuple Manager wiederum abstrahiert von den Details der Speicherung der (ggf. auch beliebig langen) Datensätze, unterstützt die Clusterung von Datensätzen, deren zeitversionierte Speicherung, die Wiederbereitstellung älterer Zustände und einige andere Dinge mehr.^[20] Der Segment Manager kümmert sich um die Bereichstellung von permanenten und temporären Speicherbereichen auf den Externspeichern während der Buffer Manager sich um das Lesen, Zwischenspeichern und Schreiben von Datenobjekten und Logeinträgen von bzw. auf den Externspeicher kümmert.

Der Index Manager ist so angelegt, dass er „fremde“ Indexe einbinden kann. D.h. in diesem Fall, einerseits den systemseitig realisierten B⁺-Baum zur Indexierung einzusetzen und der Anfragebearbeitung zur Verfügung zu stellen, andererseits aber auch den Textindex zu unterstützen. Für den in AIM-P eingesetzten Textindex^[17] – AIM-intern „Fragment-Key-Index“ genannt – ist typisch, dass die Indexanfrage eine Obermenge von Subtuple-IDs an Treffern liefert, so dass der Subtuple-Manager beim Zugriff auf diese Subtuples das betroffene Textfeld anhand der Suchbedingung der Anfrage prüfen und entscheiden muss, ob dieses Subtuple als Treffer via Complex Tuple Manager an die Anfragebearbeitung weitergegeben oder ignoriert wird. Ausführlichere Informationen Fragment-Key-Index finden sich im Abschnitt 'Implementierung des Text-Index'.

Datenbanksprache

Wie im Abschnitt Explorationsphase beschrieben, waren die Entwicklung der Datenstrukturen und einer darauf abgestimmten Datenbanksprache ein iterativer Prozess. Es kristallisierte sich hierbei immer klarer heraus, dass man Sonderregelungen wie bei den 'ORDER BY'- und 'GROUP BY'-Operatoren von SQL nach Möglichkeit vermeiden sollte.

SQL hat den Sortieroperator 'ORDER BY', mit dem man das Anfrage-Resultat sortieren kann. Da das relationale Datenmodell jedoch eine geordnete Menge von Tupeln bzw. eine Liste von Tupeln nicht kennt, darf dieser Operator nur ganz am Ende einer SQL-Anweisung stehen, d. h. nicht innerhalb geschachtelter SELECT-FROM-WHERE-Ausdrücke verwendet werden.
Der 'GROUP BY'-Operator erzeugt aus einer (einfachen) Menge von Tupeln eine Menge von Mengen von Tupeln, wobei die Tupel jeder Teilmenge in einem oder mehreren Attributen dieselben Werte aufweisen. Da das relationale Datenmodell aber keine Mengen von Mengen kennt, darf dieser Operator in SQL immer nur in Verbindung mit einer Aggregationsfunktion wie COUNT, SUM, AVG usw. verwendet werden, damit jede dieser Teilmengen wieder auf jeweils maximal ein Tupel reduziert wird.

Ausnahmen bzw. Sonderregelungen dieser Art erschweren tendenziell nicht nur das Erlernen einer Datenbanksprache, sondern macht auch deren Implementierung komplizierter. Im relativ einfachen „flachen“ Relationenmodell ist das noch nicht so problematisch, aber für das sich abzeichnende strukturell sehr vielmächtigere Datenmodell für AIM-P bekam dieser Aspekt im Laufe der Entwicklung ein immer größeres Gewicht.

Die Quintessenz dieser Überlegungen war, dass das Ergebnis jeder Anfrage wieder ein legales Objekt dieses Datenmodells sein muss. Nur dann kann ein solches „Resultat-Objekt“ bei Bedarf auch wieder in der Datenbank gespeichert werden und/oder auch ohne Probleme als Zwischenergebnis in geschachtelten Anfrageausdrücken auftreten. Das resultierende Datenmodell (und dessen Unterschiede im Vergleich zu 1NF und NF²) ist in Abb. 7 dargestellt und hat den Namen „erweitertes NF²-Relationenmodell“ bzw. abgekürzt eNF²-Relationenmodell erhalten. Hier sind – aus den oben erwähnten Gründen – nun alle diese Typen und auch alle Kombinationen davon legale Objekte des Datenmodells, selbst z. B. alleinstehende Tupel oder atomare Werte.

Die Datenbanksprache für dieses Datenmodell wurde dem entsprechend konzipiert^[18]^[21]^[22] und erhielt schließlich den Namen „Heidelberg Database Language“ (HDBL).^[23] Siehe die Wikipedia-Beiträge NF²-Relationen und eNF2-Relationen für ausführliche Beschreibungen nebst HDBL-Beispielen dieser Datenmodelle.

Implementierung des eNF²-Datenmodells

Interne Datenstrukturen

Bei kommerziellen Anwendungen wird man, auch wenn für Datenobjekte eines bestimmten Typs eNF²-Relationen zur Speicherung benutzt werden, aus Kompatibilitäts- oder anderen Gründen auf diese auch via alternativer 1NF-Sichten zugreifen wollen. Ein solcher Zugriff sollte hierbei nach Möglichkeit nicht oder zumindest nur geringfügig langsamer sein als bei einer „nativen“ Speicherung als 1NF-Relationen. Um dies zu gewährleisten, muss man erreichen, dass möglichst wenig „Beifang“ mit eingelesen werden muss, um die 1NF-Tupel aus dem eNF²-Objekt zu extrahieren. Dies gelingt am besten dann, wenn auf die einzelnen Teile des eNF²-Objekts (annähernd) direkt zugegriffen werden kann.

Für AIM-P hat man sich daher dafür entschieden, die Strukturinformation („Mini-Directories“ genannt) und die Nutzdaten getrennt voneinander zu speichern.^[24] Dies ermöglicht nur relativ wenige Daten lesen müssen, um im komplexen Objekt an eine bestimmte Stelle zu navigieren und erst dann – soweit noch erforderlich – mit den dort vorhandenen Verweisen auf die Nutzdaten zuzugreifen.^[1]^[23] Wenn die Mini-Directory-Subtuples physisch (mittels der Subtuple-Manager-Option „clustered insert“^[20]) benachbart gespeichert werden, kann ein solcher Zugriff in der Regel sehr effizient ausgeführt werden.

Das folgende Beispiel sowie Abb. 8 und Abb. 9 sind dem Vorlesungsskript von P. Dadam: „Datenbanksysteme: Konzepte und Modelle“^[25] entnommen; dort finden sich auch noch weitere Beispiele. Abb. 8 zeigt die intern von AIM-P verwendeten Datenstrukturen für die in Abb. 5 gezeigte Robot_eNF2-Relation.

Erläuterungen zu Abb. 8 in Verbindung mit Abb. 5:

Im Folgenden steht „MD“ für „Mini-Directory“, D-Pointer einen „Zeiger“ auf einen Daten-Record („Daten-Datensatz“) und C-Pointer als Zeiger auf einen Child-Datensatz („Kind-Record“)

Ein RobotNF2-Objekt weist auf Toplevel 2 atomare und 2 komplexe Attribute auf
Die Top-Level-MD (1) enthält daher einen D-Pointer (2) und zwei C-Pointer ((3), (4))
(2) Verweist auf einen Daten-Record (5), der alle atomaren Attributwerte der Topebene, d. h. für „RobID“ und „Rob_Descr“, speichert
Das Attribut „Arms“ enthält zwei Tupel mit einem atomaren und einem komplexen Attribut („ArmID“, „Axes“). Der C-Pointer (3) verweist daher auf einen MD-Record (6) mit 2 DC-Einträgen (je einen für A1 und A2)
Der C-Pointer für „Endeffectors“ verweist auf eine 7-elementige Menge von 1NF-Tupeln, die durch einen MD-Record (7) mit 7 D-Pointern strukturell repräsentiert wird
Der MD-Record (8) repräsentiert das Attribut „Axes“, das für Rob1 ® A1 drei Tupel mit 5 atomaren und einem komplexen Attribut aufweist und deshalb 3 DC-Paare enthält
Der D-Pointer (9) verweist auf einen MD-Record, der die atomaren Attributwerte der ersten Achse enthält, während der C-Pointer auf einen MD-Record (10) für die Zeilen des Attributs DH_Matrix verweist
Da jede Zeile der DH_Matrix nur atomare Werte enthält, enthält MD-Record (10) nur D-Pointer. Jeder dieser D-Pointer verweist auf einen Daten-Record (z. B. (11)), der die 4 atomaren Werte einer Matrixzeile enthält
Die Einträge im MD-Record (8), der < Axes> repräsentiert, werden als Liste von DC-Paaren interpretiert
Analog bei MD-Record (10): Auch hier werden die D-Pointer als Liste interpretiert
Die Einträge im Daten-Record (11) werden als Liste von atomaren Werten interpretiert

Die Überlegungen beim Entwurf der Syntax von HDBL, Ausnahmen und Sonderfälle möglichst zu vermeiden, wurden auch beim Entwurf der Speicherstrukturen beherzigt. Wie im vorstehenden Beispiel bereits gesehen, verwenden „Menge von ...“ und „Liste von ...“ denselben Typ von MD-Struktur, lediglich die Interpretation des Inhalts ändert sich. Dies gilt auch für die Top-Level-Objekte im Fall vom „Menge von ...“ und „Liste von ...“. Da man für „Liste von ...“ eine MD-Struktur mit den D-Zeigern der Listenobjekte benötigt, wird diese auch für „Menge von...“ verwendet. D.h. im Gegensatz zu den meisten relationalen Datenbanksystemen, die falls kein geeigneter Index existiert, das ganze Segment (heute „Tablespace“ genannt) durchsuchen müssen, um die zu einer Relation gehörenden Tupel zu finden, hat AIM-P immer einen direkten Zugriff aus diese, und zwar durch ihre Top-Level-MD. Im Fall einer 1NF-Relation würde diese nur eine Liste von D-Pointern enthalten. – Diese Eigenschaft ist auch sehr hilfreich bei der Realisierung von Zeitversionen, wie im Abschnitt 'Zeitversionen und deren Nebeneffekte' beschrieben.

Zugriff auf die internen Datenstrukturen

Natürlich sollte die Anfragebearbeitung von den im vorherigen Abschnitt beschriebenen Implementierungsdetails verschont bleiben. Diese Aufgabe erledigt der Complex Object Manager. Er bietet für jedes mengen- oder listenwertige Attribut einer Ebene einen Cursor für den sukzessiven Zugriff auf dessen Elemente an. Bis auf den Cursor auf oberster Ebene, sind alle anderen vom Cursor der darüberliegenden Ebene abhängig. Wird ein Cursor auf eine neue Position bewegt, dann bewegen sich alle von direkt und indirekt abhängigen ebenfalls; und zwar auf die Anfangsposition der mit ihnen assoziierten Menge oder Liste. Jeder Cursor hat Zugriff auf die atomaren Attribute seiner Ebene. Wenn die in Abb.5 dargestellte Robot_eNF2-Relation das Ergebnis einer Anfrage wäre, dann würde der Complex Object Manager hierfür (etwas vereinfacht) etwa die folgenden Cursor, wie in Abb. 9 mit ihren Abhängigkeiten und zugreifbaren Attribute dargestellt, bereitstellen.

Wenn sich alle Cursor noch in ihrer Anfangsposition befinden, dann haben die Cursor (bezogen auf Abb. 5) z. B. die folgenden Daten im Zugriff:

c_top → 'Rob1', 'Speedy 400 ...'
c_arms → 'A1'
c_axes → 20, 90, 40, 10
c_dh_matrix → {}
c_dh_matrix_elems → 1
c_endeffectors → {}
c_endeffectors_elems → 'GR700', 'Gripper ...'

Zeitversionen und deren Nebeneffekte

Deklaration und Nutzung von Zeitversionen in HDBL

Die Nutzung der Zeitversionierung ist optional. Wird sie gewünscht, dann wird dies bei der CREATE-Anweisung für ein Datenbankobjekt durch das zusätzliche Schlüsselwort 'VERSIONED' zum Ausdruck gebracht.

Abb. 10: Deklaration zeitversioniertes Objekt

Es war vorgesehen, zwei Arten von Anfragen gegen zeitversionierte Daten zu unterstützten; und zwar zeitpunkt-bezogene Anfragen („ASOF“) und zeitraum-bezogene Anfragen („walk through time“, „WTT“).^[3]^[23] Die Unterstützung von „ASOF“-bezogenen Anfragen in HDBL wurde relativ rasch in Angriff genommen, während für die Implementierung von „WTT“-Anfragen zwar Vorarbeiten geleistet wurden^[26], aber diese aber bis zum Ende des AIM-P-Projekts nicht mehr realisiert wurden.

Um auf eine ältere Objektversion Bezug zunehmen, wird in HDBL hinter dem Objektnamen die Klausel „ASOF zeitangabe“ hinzugefügt. Angenommen, Robot_eNF2 (siehe Abb. 12) wäre versioniert gespeichert und man möchte wissen, welche Roboter (Ausgabe RobID und Rob_Descr) es am 1. Dezember 2016 gab, da könnte man dies in HDBL wie folgt formulieren:

Abb. 11: HDBL-Anfrage mit ASOF (1)

Wenn man sich hingegen dafür interessiert, welche der aktuell vorhandenen Roboter am 1. Dezember 2016 noch nicht im Bestand waren, dann könnte man dies z. B. wie folgt formulieren:

Abb. 12: HDBL-Anfrage mit ASOF (2)

oder alternativ (hier unter der optionalen Verwendung von „ASOF NOW“ für die aktuelle Version):

Speicherung von Zeitversionen

Die Entscheidung, die Unterstützung von Zeitversionen tief im Systemkern auf Ebene des Subtuple-Managers zu realisieren, führte dazu, dass man sich mit diesem Thema und dessen Nebeneffekten schon in einer sehr frühen Entwurfs- und Implementierungsphase eingehend befasste.^[3]^[27]

Hinsichtlich der Speicherung der zeitversionierten Subtuple wurde entschieden, nur die aktuelle Version eines Subtuples in der aktuellen Datenbank und die älteren Versionen als chronologisch rückwärts verkettete „Deltas“ in einem separaten History-Pool zu speichern.^[23] – Diese „Deltas“ ähneln inhaltlich den „Undo“-Log-Einträgen in einem konventionellen Datenbanksystem, mit deren Hilfe die Änderungen einer Transaktion in der Datenbank bei ihrem Abbruch wieder rückgängig gemacht werden.^[28] Um die zu verarbeitenden Delta-Ketten nicht zu lang werden zu lassen, werden beim Speichern der Deltas zwischendurch immer wieder Vollversionen des Subtupels gespeichert.

Der Zugriff auf eine ältere Version eines Subtuples beginnt immer mit der Version in der aktuellen Datenbank. Sofern es hierzu eine ältere Version gibt (wie in den ersten beiden Fällen in Abb. 14), wird zunächst anhand des ZS_min-Eintrags im Kopf der Versionskette geprüft, ob das Subtupel zum gewünschten Zeitpunkt bereits existiert hat. Ist dies der Fall, wird im Vollversions-Index des Subtuples im History-Pool nachgeschaut, ob es eine passende „alte“ Vollversion des Subtuples gibt (im zweiten Fall in Abb. 14 existiert z. B. noch gar keine), mit der die Rekonstruktion der gewünschten Subtupel-Version begonnen werden kann, falls nicht, werden die Deltas von Beginn der Versionskette an dafür verwendet.

Anfragebearbeitung bei zeitversionierten Daten

Die Bearbeitung der in Abb. 11 dargestellten HDBL-Anfrage würde im Prinzip wie folgt ablaufen: Der Anfragebearbeitung würde durch die ASOF-Angabe erkennen, dass die zum Zeitpunkt '2016-12-01' gültige Version des Datenbankobjekts Robot_eNF2 angesprochen wird. Sie würde daraufhin für alle diese Objektversion betreffenden Zugriffe diese Zeitangabe transitiv via Catalog Manager → Complex Object Manager an den Subtuple Manger übermitteln, der – beginnend mit den Subtupeln der Katalogeinträge, über die Mini-Direktory-Subtuples der Datenbankobjekts bis zu dessen Subtupeln mit den (atomaren) Daten – alle Zugriff ASOF '2016-12-01' ausführt.

Abb. 13 illustriert, dass in einer Anfrage – in diesem Fall sogar dasselbe Datenbankobjekt – mit unterschiedlichen Aktualitätsniveaus angesprochen werden können. Für den oberen Teil der Anfrage würde die aktuellen Daten (inkl. des Katalogs), während für den unteren die Daten „ASOF“ herangezogen werden.

Für die Schichten oberhalb des Subtuple Managers ist die Bearbeitung einer „ASOF“-Anfrage somit völlig identisch zu einer Anfrage, die sich auf den aktuellen Zustand der Datenbank bezieht.

Zeitstempelung

Exkurs: Systempufferverwaltung in konventionellen DatenbanksystemenUm die Anzahl von (wiederholten und insbesondere verstreuten) Seitenzugriffen auf den Externspeicher zu reduzieren, wird ein vom Datenbanksystem verwalteter Systempuffer (Cache) verwendet, um Seiten – und insbesondere häufig verwendete Seiten – bereits im Hauptspeicher zu haben. Damit das Datenbanksystem das Ein- und Auslagern von Seiten unter Kontrolle hat, muss der Systempuffer im realen Hauptspeicher (d. h. nicht „virtuell“) angelegt werden. (In den 1980er Jahren war der (reale) Hauptspeicher noch sehr teuer, so dass man den Systempuffer (auch aus diesen Gründen) nicht beliebig groß machen konnte.) Wirde der Platz im Systempuffer knapp, dann werden geänderte Seiten auch schon vor dem Commit der Transaktion wieder auf den Externspeicher zurückgeschrieben. Durch das sog. Write-Ahead-Logging im Zusammenspiel mit der Sperrverwaltung wird sichergestellt, dass diese Änderungen bei einem Abbruch der Transaktion wieder rückgängig gemacht werden können.

Der Zeitstempel eines Subtuples befindet sich, wie in Abb. 14 illustriert im Header-Bereich des Subtuples. Er wird exklusiv vom Subtuple gesetzt und wird nachträglich nicht mehr geändert. Als Wert für den Zeitstempel für neu hinzugefügte oder von geänderten Subtuple wird der Commit-Zeitpunkt der Transaktion verwendet. Dies bedeutet jedoch auch, dass alle neuen oder geänderten Subtuple zum Eintrag dieses Zeitstempels (wieder) im Systempuffer des Datenbanksystems bereitstehen müssen, um diesen Eintrag vorzunehmen. Im ungünstigsten Fall wären dies fast alle Subtuple des Datenbankobjektes und würde entsprechend viele Zugriffe auf den Hintergrundspeicher nach sich ziehen. Für AIM-P hat man hierfür das im Abschnitt 'Transaction Workspace (TWS)' beschriebene Konzept entwickelt und implementiert.

Unterstützung von Nur-Lese-Transaktionen

„Historische“ Nur-Lese-Anfragen (read only queries) verursachen keinerlei Sperrkonflikte mit konkurrierenden Transaktionen, da sie sich praktisch ausschließlich im History-Pool bewegen und dort nur lesende Aktionen ausführen. Aber auch Nur-Lese-Transaktionen, die sich auf den aktuellen Zustand beziehen, profitieren von der Versionierung. Wird eine solche Transaktion im Read-Only-Modus gestartet, wird der Subtuple Manager^[20] diese mit den zum Startzeitpunkt der Lesetransaktion gültigen Subtuples beliefern.

Transaction Workspace (TWS)

Das Konzept des „Transaction Workspace“ war initial durch das oben beschriebene Problem der Zeitstempelung versionierter Subtuples motiviert. Im Verlauf der Evaluierungsphase rückte dann jedoch auch die Unterstützung langlaufender Transaktionen (z. B. Bearbeitung von komplexen CAD-Modellen) ins Blickfeld. Diese Art von Transaktionen können sich über Tage und Wochen erstrecken. Sie werden auch nicht wie normale Transaktionen „am Stück“ ausgeführt, sondern immer wieder unterbrochen, z. B. wegen Feierarbend oder weil zwischendurch andere Aufgaben erledigt werden müssen. Wenn eine normale Transaktion z. B. eines Systemabsturzes abgebrochen wird, wird sie vom Datenbanksystem als Recovery-Maßnahme einfach komplett zurückgesetzt und muss dann system- oder benutzerseitig neu gestartet werden. Im Falle einer Entwurfstransaktion würde dies zum Verlust der bisher innerhalb dieser Transaktion geleisteten Arbeit führen. Das Konzept des Transction Workspace löst beide Probleme, die Zeitstempelung der Subtuples versionierter Datenbankobjekte und die Unterstützung solch lang laufender Transaktionen, auf elegante Weise. Wie in Abb. 15 illustriert, weist der Systempuffer bei diesem Konzept zwei Bereiche auf. Der eine Bereich lagert, wie üblich, ganze Seiten vom Hintergrundspeicher ein und aus. Wird Subtupel in einer dieser Seiten geändert, so wird die geänderte Version dieses Subtuples in dem Transaktion zugeordneten TWS gespeichert und im Index dieses TWS eingetragen. Dieser TWS-Index wird bei jedem Tupelzugriff ein Transaktion inspiziert, ob dort bereits eine aktuellere Version vorhanden ist, ansonsten wird auf den normalen Seiten-Puffer zugegriffen.

Wenn der Platz im TWS einer Transaktion nicht mehr ausreicht, der Anwender dies veranlasst oder bei einem normalen Herunterfahren des Datenbanksystems werden die (restlichen) Subtuples in das dem TWS zugeordneten Redo-Log^[28]^[29] geschrieben. Da hier nur die Subtuples und nicht die gesamte Seite gesichert wird, geht dieses Sichern sehr rasch. Beim Commit der Transaktion wird das Subtuple mit dem Zeitstempel versehen, auf die Seite im Systempuffer zugegriffen und das Subtuple dort eingefügt oder, wenn es sich um eine Löschaktion handelt, das Subtuple dort gelöscht. Handelt es sich um eine normale Transaktion oder wird die lange Transaktion durch den Benutzer selbst abgebrochen, dann wird einfach der TWS gelöscht und der Speicherplatz für das zugeordnete Redo-Log (sofern es nicht noch für andere Zwecke (wie z. B. Media-Recovery^[29]) genutzt werden soll) frei gegeben. - Eine ausführlichere Beschreibung dieses Konzepts findet sich in 'K. Küspert et al.: The Recovery Manager of the Advanced Information Management Prototype'.^[30]

AIM-P – Weiterentwicklung und Erprobung im R²D²-Projekt (1986–1988)

Zielsetzung und Partner

1982 wurde das Kooperations-Projekt R²D² – „Ein Relationales Robotik-Datenbanksystem mit erweiterbaren Datentypen“ – mit den Instituten „Prozessrechentechnik und Robotik“ und „Programmstrukturen und Datenorganisation“ der Universität Karlsruhe (dem heutigen KIT Karlsruhe) gestartet. Das Ziel dieses Projektes war die Datenbankunterstützung für technischingenieurwissenschaftliche Anwendungen so zu realisieren, dass sich der Anwender bei der Interaktion mit der Datenbank in den Konzepten seiner eigenen Denk- und Arbeitswelt bewegen kann.^[31]

Das Institut für „Prozessrechentechnik und Robotik“ brachte hierzu sein profundes Wissen im Bereich des Computer Integrated Manufacturing (CIM) ein; und zwar insbesondere die aufgabenbezogene Konfiguration und Einrichtung von Fertigungszellen.^[32] Hierzu gehören auch die Auswahl der für eine bestimmte Aufgabe geeigneten Roboter, deren aufgabenspezifische Programmierung und die Überprüfung ihrer programmierten Armbewegungen auf mögliche Kollisionen mit den Armen anderen Robotern in dieser Fertigungszelle. Die Programmierung der Roboter solle außerdem nicht mehr durch direktes Anlernen, sondern mittels eines digitalen Zwillings an einer Workstation durchgeführt werden. Die Roboter müssen hierzu als 3D-Objekte in einem CAD-Modell repräsentiert werden, wobei deren beweglichen Teile mit sog. „Denavit-Hartenberg“-Matrizen (DH-Matrizen) assoziiert werden, um damit die möglichen Bewegungen berechnen und interaktiv visuell ausführen zu können.^[33]^[34]

Das Institut für „Programmstrukturen und Datenorganisation“ brachte seine Erfahrung und Interesse mit bzw. an der Realisierung „Abstakter Datentypen“ und an Datenbanksystemen mit ein. Der Beitrag des AIM-P-Projekts bestand darin, AIM-P bereit zustellen sowie einige wichtige Erweiterungen daran vorzunehmen bzw. zeitnah abzuschließen:

Unterstützung von benutzerdefinierten Datentypen und Funktionen
Realisierung einer hierzu passenden Anwendungsprogramm-Schnittstelle (API)
Erweiterung von AIM-P zu einer Workstation-Server-Architektur
Kooperative Objektbearbeitung durch Workstation und Datenbank-Server

Benutzerdefinierte Datentypen

Insbesondere für technisch-wissenschaftliche Datenobjekte reicht es nicht aus, für diese nur geeignete Speicherstrukturen bereitzustellen, sondern man benötigt in der Regel auch objekt-spezifische Funktionen um die Datenobjekte (oder Teile davon) zu erstellen, zu verändern und evtl. auch für ihre graphische Visualisierung.

Die Rolle von Datentypen in einem eNF²-Datenbanksystem

Wie oben im Abschnitt Entwurfsziele unter Punkt 3 beschrieben, soll jedes Ergebnis- und Zwischenergebnis einer Anfrage ein legales Objekt des Datenmodells sein, so dass es entweder in der Datenbank gespeichert oder als Zwischenergebnis in geschachtelten Anfragen verwendet werden kann. Natürlich muss bei geschachtelten Anfragen der Objekttyp des Zwischenergebnisses zu den gewünschten Operationen der nächsthöheren Ebene passen. (Wenn dieser z. B. keine Liste zurückliefert, so können auf der nächsthöheren Ebene keine listspezifischen Operationen darauf angewandt werden.) Eine derartige Konstellation muss von der Anfragebearbeitungskomponente des Datenbanksystems erkannt und die Ausführung dieser Anfrage mit Ausgabe einer entsprechenden Fehlermeldung verweigert werden.

Die Anfragebearbeitungskomponente des eNF²-Datenbanksysteme muss daher bei jeder Anfrage den Datentyp des Resultats sowie ggf. die Datentypen aller Zwischenergebnisse ermitteln um prüfen zu können, ob die jeweilige Anfrage syntaktisch korrekt ist und ausgeführt werden kann. (Bei 1NF- und reinen NF²-basierten Datenbanksystemen ist dies im Vergleich dazu nahezu trivial. Hier treten nur Mengen von Tupeln auf; lediglich die Anzahl und Art der Attribute müssen bestimmt werden.)

Ein weiterer Aspekt ist die Realisierung von benutzerdefinierten Funktionen, wenn diese benutzerdefinierte Datentypen als Aufruf-Parameter und/oder Rückgabe-Objekt verwenden. In diesem Fall muss der jeweilige Datentyp ggf. in eine Datenstruktur abgebildet werden, auf deren Basis mittels einer Programmiersprache diese Parameter- oder Resultat-Objekte „befüllt“ werden können.

Deklaration von benutzerdefinierten Datentypen

Benutzerdefinierte Datentypen werden im eNF²-Datenmodell von AIM-P verwendet

zur Wiederverwendung häufig benutzter Datenstrukturen in CREATE-Anweisungen
als Aufruf- und/oder Rückgabe-Parametertyp in benutzerdefinierten Funktionen
als optionale Möglichkeit um eNF²-Objekte via API (Application Programming Interface) vom Datenbanksystem zum Anwendungsprogramm und umkehrt zu transferieren

Die benutzerdefinierten Datentypen werden unter ihrem Namen im Katalog des Datenbanksystems gespeichert und können für alle diese Zwecke verwendet werden.

Deklaration mittels DECLARE TYPE

Bei DECLARE TYPE legt man selbst die Struktur des Datentyps fest, wie im nachstehenden Beispiel von 'matrix_4x4' illustriert.

Abb. 16: DECLARE TYPE (1)

Das nachfolgende Beispiele zeigt, wie der benutzerdefinierte Typ 'matrix_4x4' selbst wieder innerhalb einer anderen benutzerdefinierten Typ-Deklaration verwendet wird.

Unter Verwendung des 'robot_tuple'-Typs könnte die folgende CREATE-Anweisung das Erzeugen des Datenbank-Eintrags für 'Robot_eNF2 bewerkstelligen.

Abb. 18: CREATE object (1)

Deklaration mittels DERIVE TYPE

Bei dieser Art der Deklaration wird ausgenutzt, dass die Anfragebearbeitungskomponente des Datenbanksystems (wie oben beschrieben), für jede Anfrage deren Resultat-Typ ermittelt und benutzt diese Anfrage zur Ableitung und Deklaration des benutzerdefinierten Datentyps. Diese Art der Deklaration ist insbesondere dann interessant, wenn man ein Objekt dieses Typs zum Transfer vom Datenbanksystem zum Anwendungsprogramm und umkehrt nutzen möchte.

Im nächsten Beispiel wird der benutzerdefinierte Typ direkt vom gespeicherten Datenbankobjekt abgeleitet.

Abb. 20: DERIVE TYPE (2)

Angenommen, wir haben eine Funktion range (arm : robot_arm_type) entwickelt, die auf Basis eines Arm-Tupels aus Robot_eNF2 bestimmen kann, welche maximale Reichweite dieser Arm hat. Dann benötigen wir einen Aufrufparameter, der ein Arm-Tupel an diese Funktion zurückgeben kann. Die Ableitung eines solchen Typs könnte dann wie nachfolgend illustriert aussehen.

Oben hatten wir einen Typ 'matrix_4x4' mittels DECLARE TYPE deklariert. Wenn wir den Type von DH_Matrix mittels DERIVE TYPE deklarieren möchten, könnten wir das wie nachfolgend illustriert tun.

Deklaration als „gekapselter“ Typ

Es gibt eine Reihe von Objekten, bei denen es nicht sinnvoll ist, Änderungen mit elementaren HDBL-Änderungsoperationen durchzuführen. Betrachten wir z. B. ein CAD-Objekt '3D-Quader'. Diesen kann man u. a. durch seine 8 Eckpunkte als (x,y,z)-Koordinaten beschreiben und damit im 3D-Raum platzieren. Wenn man diesen Quader im 3D-Raum verschieben möchte, dann müssen alle seine Eckpunkte in konsistenter Weise angepasst werden, damit seine Eigenschaft als Quader sowie seine Kantenlängen erhalten bleiben. Ähnliches gilt, wenn man ihn vergrößern oder verkleinern möchte. Für Anwendungsfälle dieser Art wurden im Kooperationsprojekt R²D² ('A Robotics Database with Extensible Data Types')^[35]^[36] die benutzerdefinierten Datentypen von AIM-P um sog. „gekapselte“ Typen (encapsulated types)^[36] erweitert. Diese gekapselten Typen wirken ähnlich wie ein Abstrakter Datentyp, indem sie nur noch Zugriffe auf Objekte dieses Typs mittels typ-spezifischer Funktionen zulassen. Damit eine solche Kapselung wirksam wird, muss sie bereits in der CREATE-Anweisung für das „umgebende“ Datenbank-Objekt verwendet werden, damit diese Eigenschaft auch im Objekt-Katalog des Datenbanksystems entsprechend vermerkt werden kann. Jeder einfache HDBL-Lese- oder Änderungszugriff auf ein Objekt dieses Typs wird in diesem Fall von der Anfragebeareitungskomponente des Datenbanksystems zurückgewiesen.

Deklariert werden diese gekapselten Typen durch das Schlüsselwort ENC am Ende der Datentyp-Deklaration. Am Beispiel des 3D-Quaders könnte dies dann z. B. wie folgt aussehen:

Abb. 23: DECLARE TYPE (3)

Benutzerdefinierte Funktionen

Benutzerdefinierte Funktionen bestehen aus zwei Teilen: Einem Deklarationsteil für den Funktionskopf und einen Implementierungsteil für den Funktionsrumpf.

Deklaration von benutzerdefinierten Funktionen

Die Deklaration hat die syntaktische Form:

Abb. 24: Deklaration einer benutzerdefinierten Funktion

wobei 'pn_i' für 'Parametername_i' und 'ptyp_i' für 'Parametertyp_i' steht. Als Parametertyp sind alle system- und benutzerdefinierten Datentypen zugelassen.

Eine Funktion zur Berechnung der Addition zweier Matrizen vom Typ 'matrix_4x4' könnte dann z. B. wie folgt deklariert werden:

Abb. 25: DECLARE FUNCTION (1)

Die oben erwähnte Funktion 'range' könnte unter Verwendung des oben deklarierten Datentyps 'robot_arm_type' wie folgt deklariert werden:

Abb. 26: DECLARE FUNCTION (2)

Implementierung von benutzerdefinierten Funktionen

Die Implementierung der benutzerdefinierten Funktionen erfolgt nicht in HDBL, sondern mittels einer konventionellen Programmiersprache. Der Hauptgrund hierfür war, dass AIM-P als Workstation-Server-Datenbanksystem^[37]^[38] konzipiert war, bei dem die serverseitig implementierten Funktion zur Bearbeitung der Objekte – im Sinne einer „kooperativen Objektbearbeitung“^[39] – auch seitens der Workstation zur Verfügung stehen sollten.

Bei AIM-P wurde dies exemplarisch für die Programmiersprache Pascal von IBM realisiert. Die Deklaration des Funktionskopfes entspricht in diesem Fall syntaktisch bereits dem Funktionskopf der zu implementierenden Pascal-Funktion. Wurden bei der Funktionsdeklaration als Aufrufparameter oder Rückgabe-Typ benutzerdefinierte Datentypen verwendet, so konnte man sich vom Typ-Manager von AIM-P für jeden dieser Typen die äquivalenten Pascal-Typ-Deklarationen erzeugen lassen. – Für die Implementierung der Pascal-Funktion 'matrixAdd' (siehe DECLARE FUNCTION (1), Abb. 25) könnte der vom Typ-Manager vorgegebene Rahmen etwa wie nachstehend illustriert aussehen.^[18]^[40]

In AIM-P wurden Mengen und Liste intern logisch als „beliebig“ variabel lange Arrays realisiert, diese aber physisch nur in der tatsächlich benötigten Länge (im Hauptspeicher und auf Disk) gespeichert. Die obere Grenze in den VAL-Array-Feldern zeigt an, dass die Liste maximal 4 Elemente haben kann und das ACT_ELEM-Feld, wie viele es aktuell tatsächlich sind. Im konkreten Fall würde die Anfragebearbeitungskomponente von AIM-P bei den beiden Aufruf-Parametern bei allen Listen jeweils den Wert 4 eintragen. Im Rückgabe-Objekt 'matrixAdd' muss der Implementierer dieser Funktion diese Werte setzen. – Die roten Pfeile in Abb. 27 deuten an, an welchen Stellen der Implementierer tätig werden muss.

Wie im Abschnitt Deklaration als „gekapselter“ Typ erwähnt, kann auf Objekte dieser Art nur mittels auf diesen Datentyp zugeschnittener Funktionen lesend oder ändernd zugegriffen werden. Im Fall des dort deklarierten Typs 'quader3D_points' (siehe DECLARE ENC TYPE, Abb. 23) könnten dies z. B. die folgenden benutzerdefinierten Funktionen sein, die man für Zuweisungen in Update-Anweisungen verwenden könnte:

Möchte man den Inhalt des gekapselten Typs z. B. „as is“ auch in einer Anfrage ausgeben, dann deklariert man hierfür einen strukturgleichen „offenen“ Datentyp (d. h. ohne ENC) und realisiert eine Funktion mit dem gekapselten Typ als Inputparameter und dem „offenen“ Typ aus Rückgabe-Objekttyp, wie im folgenden Beispiel illustriert.

Abb. 29: DECLARE FUNCTION (6)

Die show_quader-Funktion könnte dann in einer SELECT-Anweisung zur Ausgabe der internen Daten eines solchen „gekapselten“ Quader-Objekts verwendet werden, wie z.B.

Abb. 30: Benutzerdefinierte Funktion

Anwendungsprogramm-Schnittstelle (API)

Im 1NF-Fall ist die Sache relativ einfach. Das Ergebnis einer SQL-Anfrage ist im Regelfall eine Menge von Tupeln und Tupel haben eine Struktur, die man in konventionellen Programmiersprachen als 'Datensatz' (engl.: 'record') kennt. Das sequentielle Lesen („one tuple at a time“) der Resultatmenge entspricht daher im Wesentlichen dem sequentiellen Lesen von Datensätzen in einer Datei. Auch das Schreiben (Update) funktioniert ähnlich. Man positioniert den „Datensatzzeiger“ (in SQL „cursor“ genannt) auf das zu ändernde Tupel in der Datenbank und überschreibt dieses mit der geänderten Version aus dem Anwendungsprogramm.

Bei AIM-P verfuhr man diesbezüglich wie folgt: ^[44]^[36] Jede Anfrage erzeugt ein Resultat-Objekt, für dessen Transfer ins Anwendungsprogramm (AP) man zwei Möglichkeiten hat:

Man leitet für das AP den Typ mittels DERIVE TYPE ab, legt für diesen äquivalente Datenstruktur im AP an und lädt das Resultat-Objekt via API in diese Struktur
Man legt sich eine eigene Datenstruktur im AP an und befüllt diese mittels hierarchisch organisierten Cursorn sukzessive mit den Daten des Ergebnis-Objekts

Bei der 2. Möglichkeit (hierarchisch organisierte Cursor), ist die Vorgehensweise im Prinzip etwa wie folgt:

Deklaration des Top-Cursors für das Resultat-Objekt in Abb. 31:
DECLARE CURSOR RobotsResult
FROM QUERY_STATEMENT
SELECT [ r.RobID, r.Rob_Descr, r.Arms ]
FROM r IN Robot_eNF2
dessen Ausführung das in Abb ... dargestellte Resultat-Objekt erzeugen würde.
Deklaration der hierarchisch abhängigen Cursor:
DECLARE CURSOR c_Arms WITHIN RobotsResult
DECLARE CURSOR c_Axxis WITHIN c_Arms
DECLARE CURSOR c_Matrix WITHIN c_Axxis
DECLARE CURSOR c_mElem WITHIN c_Matrix
Ausführen der Anfrage, Bewegen der Cursor und Transfer der durch sie zugreifbaren Daten ins Anwendungsprogramm

Die im API deklarierten Cursors stützen sich zur Ausführungszeit auf die entsprechenden Cursor des Complex Object Managers. Auf welche Daten sie jeweils zugreifen können und wie sich die abhängigen Cursor bewegen entspricht der Beschreibung im Abschnitt Zugriff auf die internen Datenstrukturen. Ist für ein Sub-Objekt des Anfrage-Objekts ein Typ abgeleitet und im Anwendungsprogramm die passende Datenstruktur angelegt worden, so kann der Cursor diese Datenstruktur direkt befüllen.

Workstation-Server-Architektur

Typische „normale“ Datenbankanwendungen sind Client-Server-basiert. Der Client holt sich mittels SELECT-FROM-WHERE-Anweisungen vom Datenbank-Server in das Anwendungsprogramm, führt die Änderungen an den Daten (Einfügen, Ändern, Löschen) im Anwendungsprogramm durch und schickt dann eine oder eine Folge von INSERT-, UPDATE- oder DELETE-Anweisungen an den Datenbank-Server, um die betroffenen Tupel in den betroffenen Relationen auf den neuen Stand zu bringen. Dies funktioniert bei Anwendungen, bei denen man mit relativ wenigen dieser Änderungsanweisungen auskommt, im Großen und Ganzen sehr gut. Ganz anders sieht es allerdings z. B. in der CAD-Welt aus, wenn man z. B. an die CAD-gestützte Konstruktion eines Pkw denkt. Nehmen wir an, dass das CAD-Modell des Pkw in eNF2-Datenstrukturen im Datenbanksystem gespeichert wird. Der Transfer zum Client, in diesem Fall einer Workstation, der großen Datenobjekte würde mit einigen wenigen HDBL-Anweisungen bequem erledigt werden können. Auf der Workstation würde dann mittels CAD-Anwendungsprogrammen das CAD-Modell evtl. stunden- oder tagelang bearbeitet, um dann wieder auf den Datenbank-Server übertragen zu werden. Würde man die vorgenommenen Änderungen in der oben beschriebenen Form durchführen, dann würde dies zu einer sehr, sehr langen Folge von INSERT-, UPDATE- und DELETE-Anweisungen führen und zu inakzeptabel langen Ausführungsdauern führen.

Im Kontext von CAD und ähnlich aufwendigen Anwendungen behalf man sich in den 1980er Jahren in der Regel dergestalt, dass diese Objektmodelle im proprietären Binärformat des Herstellers als Datei im Dateisystem gespeichert wurden, und im Datenbanksysteme lediglich beschreibende und Verwaltungsinformation sowie der Name der Datei hinterlegt wurde (für das Datenbanksystem war das Objektmodell daher im Wesentliche eine „black box“). In der Regel hat man zusätzlich noch eine Art von Ausleih- und Rückgabe- Funktion realisiert, um versehentliches gleichzeitiges Ausleihen und Ändern zu vermeiden. Mit Systemen für das Produktdatenmanagement (PDM) kamen im Laufe der 1980er und 1990er Jahre dann kommerzielle Lösungen dieser Art auf den Markt.

Ziel des R²D²-Projekts war, nicht nur die beschreibende und Verwaltungsinformation im Datenbanksystem zu speichern, sondern auch das Objektmodell selbst; und zwar nicht als „black box“, sondern in eNF²-Strukturen, damit verschiedene Anwendungen darauf zugreifen können. Da die Bearbeitung der Objekte in der Regel auf der Workstation erfolgt, wurde AIM-P dahingehend erweitert, dass ein Resultatobjekt nicht nur direkt an ein Anwendungsprogramm übergeben, sondern auch eine Workstation übersandt werden, dort bearbeitet und anschließend an das Datenbanksystem zurückübersandt werden kann. – Wie dies realisiert wurde, wird in den folgenden beiden Abschnitt beschrieben.

Object Cache

Der Object Cache erhält und speichert die von der Datenbank als „getyptes“ Objekt empfangenen Daten in der – vom Objekttyp abgeleitet – Programmiersprache-Datenstruktur als Abstrakter Datentyp. D.h. das Objekt im Object Cache wird nicht mehr mittels HDBL, sondern ausschließlich mittels objekt- und anwendungsbezogener Methoden bearbeitet. Diese Methoden sind auch die Programmierschnittstelle für die Anwendungssysteme, wie CAD-Modellierung, visuelle Roboterprogrammierung, Bahnkurvenanalysen usw.^[31] Der AIM-P-Server registriert, welches Objekt (mit all seinen Subobjekten) an die Workstation übersandt wurde (→ „Check-out“) und belegt dieses d mit Langzeitsperren entsprechend der Zugriffsart (Update oder Read-Only). Fordert eine andere Transaktion eine Sperre für ein Objekt an, das mit einer Langzeitsperre belegt ist, erhält die anfordernde Transaktion eine entsprechende Rückmeldung, so dass der Anwender entscheiden kann, ob er auf die Freigabe dieser Sperre warten möchte oder seine Transaktion abbricht. Wird die lange Transaktion mit Commit beendet, wird das Objekt wieder an den Server zurückgesandt (→ „Check-in“) und seine Änderungen dort nachvollzogen, die Langzeitsperre wieder aufgehoben und evtl. wartende Transaktionen informiert und fortgesetzt.

Der Object Cache stellt nicht nur Methoden für den lesenden oder schreibenden Zugriff auf das im Cache liegende Objekt bereit, sondern markiert in einer etwas erweiterten Kopie der Objektstruktur, wie sie im Abschnitt 'Interne Datenstrukturen' beschriebenen wurde, welche Änderungen am Objekt vorgenommen wurden. D.h. wo etwas geändert, neu eingefügt oder gelöscht wurde und speichert die neuen Versionen der betroffenen Subtuples. Bei der Rückübertragung des Objekts vom Objekt Cache an den Server werden nur die markierte Strukurinformation zusammen mit der geänderten Teilen übertragen und dort auf Ebene des Complex Object Managers und Subtuple Managers eingespielt. Die normale Anfragebearbeitung auf HDBL-Ebene ist hierbei nicht involviert.^[39]

Kooperative Objektbearbeitung

Die Implementierung dieser objekt- und aufgabenbezogenen Methoden für den Object Cache, erfolgt wie im Abschnitt 'Benutzerdefinierte Funktionen' beschrieben. D.h. diese Funktionen sind nicht nur im Kontext des Object Cache, sondern auch am AIM-P-Server für die Nutzung mittels HDBL verfügbar. Wenn z. B. nur eine relativ kleine Änderung an einem Objekt vorgenommen werden muss, kann der Anwender anstelle von Check-out → Object Cache → Methodenaufruf → Check-in diese Änderung über das Online-Interface der Workstation direkt auf dem AIM-P-Server ausführen. Wenn das Objekt bereits im Object Cache liegt, geht das direkte Ändern auf dem Server allerdings nicht mehr; dies wird durch die Langzeitsperre erkannt und verhindert.

AIM-P – Finaler Entwicklungsstand und Weiterführende Forschungs- und Entwicklungsarbeiten

Finaler Entwicklungsstand

Die Implementierungsarbeiten endeten etwa Anfang 1990. Zum einen hing dies mit der oben erwähnten Entsendung der beiden Mitarbeiter ans DBTI zusammen, zum anderen aber wegen der einsetzenden Veränderungen in Bezug auf die inhaltliche Ausrichtung und Mission des Wissenschaftlichen Zentrums, wie im Wikipedia-Beitrag „IBM Wissenschaftliches Zentrum Heidelberg“ beschrieben. Zwar gab es Anfang der 1990er Jahre noch die eine oder andere Installation von AIM-P an Universitäten und bei IBM-Kunden, dies waren aber keine umfangreiche Erprobungen mit Feedback wie z. B. im R²D²-Projekt.

Wie im Abschnitt 'Iterativer Entwurfs- und Entwicklungsprozess' beschrieben, war die Entwicklung des Datenmodells, der Anfragesprache HDBL und damit verbunden – der Entwurf und die Implementierung des Systemkerns von AIM-P ein integrativer Prozess. Nicht alle Erkenntnisse und daraus resultierende Erweiterungen (z. B. von HDBL) konnten daher in die AIM-P-Implementierung aufgenommen werden. Manchmal, weil dies zur starke nachträgliche Veränderungen nach sich gezogen hätte, manchmal aber auch, weil andere Implementierungsarbeiten, wie etwa die für das R²D²-Projekt benötigten Erweiterungen, eine höhere Priorität hatten.

Zum Abschluss der Entwicklung hatte AIM-P die folgende Funktionalität:^[4]

1NF- und NF²-Relationen, beide ungeordnet (Menge) oder geordnet (Liste). Zulässige Attributtypen waren atomare Werte, 1NF und NF²-Relationen sowie Mengen und Listen von atomaren Werten; Mengen von Mengen und Listen von Listen wurden nicht unterstützt
Eine große Teilmenge von HDBL wurde unterstützt, die Anfrageoptimierung war jedoch nur rudimentär entwickelt; die Unterstützung von Sichten gab es auch (noch) nicht.
Zugriff auf historische Daten in ASOF-Manier
Online-Interface und Anwendungsprogramm-Schnittstelle.
Benutzerdefinierte Datentypen und Funktionen.
Unterstützung von Text-Daten mit text-bezogenen Suchfunktionen, allerdings ohne Unterstützung durch einen Text-Index.
Unterstützung einer Workstation-Server-Architektur
Basis-Transaktionsunterstützung (commit und abort) sowie Langzeit-Sperren in einer Einbenutzer-Umgebung

Anmerkungen zu 'Listen von Listen wurden nicht unterstützt'

Wegen der (noch) fehlenden Unterstützung von 'Listen von Listen' konnten Matrizen in AIM-P nicht ganz so elegant wie in Abb. 5 dargestellt realisiert werden, sondern mussten als „Liste von Tupeln“ deklariert werden, wobei die Listenindices die Matrixzeilen und die Tupel-Attribute die Matrixspalten repräsentieren. Allerdings ist diese Einschränkung nicht ganz so gravierend, da ja nur „Listen von Listen“ oder „Mengen von Mengen“ nicht möglich waren, hingegen z. B. „Listen von Tupeln mit listenwertigen Attributen“ schon. Abb. 33 illustriert anhand der Robot_eNF2-Tabelle aus Abb. 5 die sich ergebenden Unterschiede. Auf HDBL-Ebene sehen die Zugriffe auf einzelne Listenelemente syntaktisch gleich aus, da HDBL auch den Attributzugriff via Positionsnummer (anstelle des Attributnamens) unterstützt und sich damit die „Zeilen-Tupel“ syntaktisch wie Listen verhalten. D.h. wenn ein Pfadausdruck eine Liste referenziert, dann wird z. B. das 4. Listenelement via pfadausdruck.4 adressiert. Referenziert der Pfadausdruck hingegen ein Tupel, wie in Abb. 33.b dargestellt, dann erfüllen sowohl pfadausdruck.Col4 als auch pfadausdruck.4 diesen Zweck.

Weiterführende Forschungs- und Entwicklungsarbeiten

HDBL und Anfragebearbeitung

Auch die Entwicklung der Datenbanksprache HDBL^[18]^[21]^[22] war natürlich direkt und unmittelbar vom oben beschriebenen „iterativen Entwurfs- und Entwicklungsprozess“ tangiert. Sehr früh wurde deshalb dazu übergegangen die Sprache formal und semantisch zu spezifizieren und mittels Parser hinsichtlich Übersetzbarkeit und anderer Eigenschaften zu überprüfen. Für die Übertragung und Implementierung in AIM-P war zum einen natürlich wichtig, dass was der „Unterbau“ hergab, d. h. welche Teile des eNF²-Datenmodells in AIM-P unterstützt wurden, zum anderen aber natürlich auch, ob alle semantischen oder verarbeitungstechnischen Fragen für gewisse Operationen, wie z. B. zur Sortierung und Duplikatelimierung^[45]^[46], hinreichend geklärt waren.

Darüber hinausgehend befasste man sich auch mit Erweiterungen der Sprache, wie z. B. die Formulierung und Ausführung rekursiver Anfragen^[47]^[48] oder die Unterstützung von Sichten^[49].

Text-Index

Wie im Abschnitt System-Architektur erwähnt, war geplant, in AIM-P einen Text-Index für die Unterstützung von Suchanfragen auf Text einzusetzen. Vorgesehen hierfür war der 'Fragment-Key-Index'.^[17] Da dieser besondere Eigenschaften hat und wie jeder komplexe Index besondere Herausforderungen an Index-Updates im Mehrbenutzerbetrieb mit sich bringt, soll er im Folgenden kurz dargestellt werden.

Die 'Fragment-Keys' sind Word-Fragmente, die nach einem speziellen Verfahren aus einer Menge von Beispieldokumenten bestimmt und als festgelegte Suchbegriffe in diesem Index verwendet werden.^[16] D.h. jedem Fragment-Key ist eine Liste von Referenzen auf Subtuples verbunden, in deren Textfeld dieses Wort-Fragment enthalten ist, wie in Abb. 34 illustriert.

Bei jedem einzufügenden Subtuple mit einem zu indexierenden Textattribut wird geprüft, welche 'Fragment Keys' des Textindex in diesem Text vorkommen und ggf. ein Eintrag der SubtupleID in diese Indexlisten vorgenommen. Bei Suchanfragen wird ähnlich vorgegangen: Aus dem Anfragestring werden, wie bei Textdokumenten, die darin enthaltenen Fragment Keys extrahiert. Alle SubtupleIDs, die in allen der so ermittelten Indexliststen vorkommen, bilden die Obermenge an Treffern für diese Suchanfrage. Nehmen wir an, wir würden nach allen Dokumenten suchen, die das Wort „Datenbank“ enthalten, dann würde die Analyse (beim Index in Abb. 34) die Fragment-Keys 'ank', 'ate' und 'ban' ermitteln und der Text-Index-Manager die Durchschnittsbildung der SubtupleID-Einträge dieser Indexlisten bilden. In dieser Liste von potentiellen Treffern sind sehr wahrscheinlich auch Dokumente enthalten, die zwar diese drei Fragment Keys, nicht jedoch das Wort „Datenbank“ enthalten. Deshalb ist die im Abschnitt 'System-Architektur' bereits erwähnte Nachinspektion zur Bestimmung der echten Treffer erforderlich.

Im Fall von schreibenden Zugriffe auf Textdaten, führen diese natürlich Änderungen im Textindex nach sich. Im Bereich Dokumentenretrieval werden (zumindest war das in den 1980er Jahren so) in der Regel Änderungen am Textindex nicht sofort beim Speichern neuer Dokumente, sondern erst zu einem späteren Zeitpunkt (z. B. in der Nacht) als Stapelverarbeitung (Batchverarbeitung) durchgeführt. Dies ist natürlich für mögliche Einsatzzwecke, wie z. B. Büroanwendungen, nicht optimal. Das Hauptproblem bei einem sofortigen Update des Textindex ist allerdings nicht der Lese-/Schreib-Aufwand für den Eintrag der Änderungen in dessen Datenstrukturen, sondern dass dies in einem realen System, mit vielen gleichzeitig tätigen Nutzern, konkurrierend zu parallelel laufenden Lese- und Schreib-Transaktionen geschehen muss; und natürlich nicht zu falschen Anfrage-Ergebnissen oder gar fehlerhaften Datenbankeinträgen führen darf.

Beim Einfügen eines neuen Subtuples mit zu indexierendem Textattribut können, je nach Umfang des Textes und konfigurierter Anzahl von Fragment-Keys, durchaus es mehrere hundert oder tausend Index-Listen sein, in welche die SubtupleID eingetragen werden muss. Konventionelle Sperrverfahren würde für diese Updates mindestens alle betroffenen Indexlisten sperren und während dieser Zeit alle parallel laufenden Transaktionen blockieren, die auf mindestens eine dieser Fragment-Key-Listen zugreifen müssen, die von diesem Update betroffen sind. – Für AIM-P wurde deshalb ein spezielles Verfahren entwickelt, das im folgenden Abschnitt 'Concurrency Control & Recovery' behandelt wird.

Concurrency Control & Recovery

Allgemeine Vorgehensweise

Der AIM-Forschungsbereich war sich der Bedeutung der Thematik 'Mehrbenutzerbetrieb' und den damit verbundenen Themen 'Concurrency Control' und 'Recovery' für Datenbanksysteme voll bewusst und hat sich daher für den anstehenden Entwurf und die Entwicklung von AIM-P personell mit entsprechendem aktuellem Know-how verstärkt.^[50] – Die Interessensschwerpunkte bei der Entwicklung und praxisnahen Erprobung von AIM-P lagen allerdings beim Datenmodell, der Datenbanksprache, der Anpasskeit an anwendungsspezifische Anforderungen durch benutzerdefinierte Datentypen und Funktionen sowie die Einbeziehung von Workstations bei der Bearbeitung von Datenbankobjekten mittels langlaufender Transaktionen. Für diese Zwecke und diese Projektphase war daher die rasche Realisierung eines Mehrbenutzerbetriebs nicht erforderlich. – Anstatt dessen wurden in Zusammenarbeit mit der FernUniversität Hagen im AIM-Forschungsbereich im Rahmen einer Dissertation geeignete Sperrverfahren für Objekte des eNF²-Datenmodells sowie die ins Auge gefassten Anwendungsszenarien entwickelt.^[51]^[52]^[53]

Man behielt die Aspekte Concurrency Control und Recovery beim Entwurf und Implementierung des Systems jedoch bereits von Anfang im Auge. Wie oben beschrieben, wurde der Subtuple-Manager bereits so entworfen und implementiert, dass er Nur-Lese-Transaktionen ohne Involvierung der Concurrency Control durch die Bereitstellung der zum Startzeitpunkt der Transaktion freigegebenen Subtuple-Versionen bediente.^[20] Auch die Transaction Workspaces dienen u. a. auch dem Zweck, das Zurücksetzen unvollständiger bzw. das Wiedereinspielen von Updates abgeschlossener Transaktionen zu vereinfachen.^[30]

Concurrency Control für den Fragment-Key-Index

Wie bereits oben bei der Beschreibung der Arbeitsweise des Text-Index erläutert, würden bei konventionellen Sperrverfahren beim Einfügen oder Ändern eines Textes potentielle sehr viele Fragment-Keys involviert damit deren Indexlisten durch die Sperrverwaltung während der Updates im Textindex gesperrt und dadurch potentielle viele parallel laufende Transaktionen blockiert werden. Nun liegt aber ein wirklicher Konflikt nur dann vor, wenn alle von der parallel laufenden Transaktion benötigten Fragment-Key-Listen von der „blockierenden“ Update-Transaktion benötigt werden.^[54] – Und noch ein anderer interessanter Aspekt: Während beim Einfügen und Ändern sehr viele Fragment-Key-Listen betroffen sind, sind dies – da Suchanfragen ja eher kurz sind – nur relativ wenige. Das für den Fragment-Key-Index entwickelte Verfahren „Selective Deferred Index Update & Concurrency Control “^[55] nutzt diese beiden Aspekte aus und führt diejenigen (in der Regel wenigen) Änderungen am Index, die parallel laufende Transaktion tatsächlich tangieren, mit hoher Priorität aus, während die anderen Änderungen evtl. erst später durchgeführt werden.

Dieses Konzept wurde in einer Stand-alone-Implementierung realisiert und das erwartete (positive) Verhalten im Mehrbenutzerbetrieb mittels Simulationen überprüft.^[55] – Da AIM-P, wie bereits erwähnt, jedoch bis zum Projektende nicht auf einen Mehrbenutzerbetrieb hin erweitert wurde, wurde dieses sehr interessante Verfahren nicht (mehr) ins AIM-P-System integriert.

Zeitversionen

Es war von vornherein vorgesehen, sowohl zeitpunkt- als auch zeitraum-bezogene Anfragen, d. h. „ASOF“- und „Walk through time (WTT)“-Anfragen in AIM-P zu unterstützen. Durch die Entscheidung, die Zeitversionierung direkt im Subtuple-Manager zu realisieren, waren ASOF-Anfragen sehr einfach zu implementieren, da – wie im Abschnitt 'Zeitversionen und deren Nebeneffekte' beschrieben – jegliche Zugriff auf das „alte“ Objekt, beginnend mit dem Zugriff auf den Katalog, in ASOF-Manier durchgeführt wurden. Man bekam deshalb, ohne weiteres Zutun, nicht die Inhalte dieses Objekts, sondern auch seine Struktur zum ASOF-Zeitpunkt als Anfrageergebnis zurückgeliefert.

WTT-Anfragen sind diesbezüglich etwas komplizierter, da sich über den WTT-Zeitraum nicht nur die Inhalte, sondern auch die Struktur des angefragten Objektes geändert haben können. Man muss daher entscheiden, in welcher Struktur das Anfrageergebnis angezeigt werden soll und wie man mit im WTT-Zeitraum aufgetretenen Strukturänderungen umgeht. Die hierzu begonnenen Konzeptarbeiten^[26] sollten an sich weitergeführt und ggf. in AIM-P umgesetzt werden, dazu kam es aber leider nicht mehr.

NF², eNF², AIM-P und die Entwicklung des SQL-Standards

Vorbemerkungen

Der seinerzeitige Versuch der ISO, eine einheitliche auf dem Netzwerk-Datenbankmodell basierende Datenbanksprache 'Network Database Language (NDL)' per ISO-Standard zu erreichen, war krachend gescheitert. Der als ISO 8907 im Jahr 1987 ratifizierte Standard wurde bereits im Jahr später wegen Irrelevanz wieder zurückgezogen.^[56] Der Grund für das Scheitern war, dass die Standardisierungsbemühungen den in vielen Punkten sehr unterschiedlichen Implementierungen der Hersteller ständig hinterherliefen. Deren Produkte waren am Ende derart weit vom NDL-Standard entfernt, dass kein Hersteller mehr ernsthaft beabsichtigte sein Produkt noch an diesen Standard anzupassen; außerdem waren zu diesem Zeitpunkt bereits von Oracle (1979) und IBM (SQL/DS für VM/CMS, 1981 und DB2 für MVS, 1983) die ersten kommerziell verfügbaren relationalen Datenbanksysteme auf dem Markt .

Für die Standardisierung von SQL wollte man daher anders verfahren.^[57] Der Standard sollte nach Möglichkeit stets „vor der Welle reiten“, d.h. die Hersteller sollten sich idealerweise bei der Implementierung ihrer Systeme entweder am SQL-Standard orientieren oder zumindest zeitnah nachträglich alternative standardkonforme Schnittstellen und/oder Sprachkonstrukte hinzufügen. Da bei den Herstellern die entsprechende Einsicht weitgehend vorhanden war^[58] und sie sich auch entsprechend aktiv in den Standardisierungsprozess einbrachten, hatte diese Standardisierung von SQL mit SQL-82, SQL-86 und SQL-92 einen guten Start.

Den Standardisierungsprozess man sich in etwa wie folgt vorstellen:

Die Mitglieder des ISO-Gremiums bringen zu Beginn der Arbeiten an einer neuen Version des Standards (aber bei Bedarf auch noch zwischendurch) Vorschläge für die nächste Version des Standards ein. Während die Vorschläge der Hersteller sich an den Erweiterungen orientieren, die sie für ihr Datenbanksystem in Planung oder bereits in der Entwicklung haben, evaluieren die institutionellen Vertreter aus den nationalen Standardisierungsorganisationen auch thematisch passende Beiträge aus der Wissenschaft^[59]. So ließ sich z.B. das 'National Institute of Standards and Technology' (NIST) in Gaithersburg, MD, USA, im Vorfeld aus erster Hand über AIM-P mit seinem eNF²-Datenmodell mit benutzerdefinierten Datentypen und Funktionen informieren.^[60]

Alle diese Vorschläge werden im ISO-Gremium diskutiert, hierbei eventuell auch noch Alternativvorschläge eingegebracht und sondiert, welche von diesen Vorschlägen man für die nächste Version des Standards vertieft betrachtet und welche man erst für spätere Versionen in Betracht zieht. Da der Standard implementierungsneutral sein soll, muss man für die neu hinzukommenden Dinge präzise Benennungen und Definitionen entwickeln und in das bestehende Werk so einfügen, dass das Ganze nach Möglichkeit „aufwärtskompatibel“ bleibt, d.h. alle Konstrukte aktuellen SQL-Standards auch noch im neuen gültig sind. Unter Umständen erkennt man erst bei diesen Detailarbeiten, ob man es überhaupt schaffen wird, die für einen bestimmten Vorschlag noch offenen Fragen bis zum geplanten Veröffentlichkeitszeitpunkt der geplanten Version voraussichtlich geklärt und die resultieren textuellen Ergänzungen ggf. fertiggestellt werden können.

SQL3: Alternative Ansätze und Richtungsentscheidung

Laut Jim Melton^[61], dem federführenden Editor aller SQL-Standards, begann sich das ISO-SQL-Gremium bereits in der Endphase der Fertigstellung von SQL'92 mit SQL3 und hierbei u.a. mit den Themen „Unterstützung komplexer Objekte“ sowie „Benutzerdefinierte Datentypen und Funktionen“ zu befassen. Die Publikationen des Wissenschaftlichen Zentrums der IBM in Heidelberg zu NF², eNF² und den benutzerdefinierte Datentypen und Funktionen lagen hierbei laut Melton „auf dem Tisch“. Im Verlauf der „Sondierungsphase“ schälten sich dabei zwei Gruppen heraus. Die eine favorisierte für SQL3 eine SQL-Erweiterung à la eNF², während die andere Gruppe die Beibehaltung des 1NF-Datenmodells und die Realisierung dieser Konzepte als Abstrakten Datentyp (ADT) favorisierte. Bei der ADT-Variante müssen die auf dem ADT ausgeführten Ausgabe-Funktionen letztlich stets ein zum 1NF-Relationenmodell kompatibles Resultat zurückliefern. Die Anfragebearbeitungskomponente des Datenbanksystems kann daher im Wesentlichen unverändert bleiben.

Abb. 35 illustriert die beiden Varianten auf der Typebene, während Abb. 36 dies beispielhaft für die Instanzebene tut.

Abb. 36 illustriert, dass es sich bei der „1NF+“-Variante aus Sicht der Anfragebearbeitung des Datenbanksystems weiterhin um das „flache“ Relationenmodell handelt. Die dunkelgrau eingefärbten Bereiche deuten an, dass Attribute dieses Typs für das SQL-Kernsystem eine „black box“ sind. Für den Zugriff auf diesen Attributtyp werden speziell für diesen definierte Funktionen verwendet.

Im weiteren Verlauf dieser Diskussion setzte sich (zunächst) die „eNF2-Fraktion“ durch und so wurde beschlossen, nur noch diesen Ansatz weiter zu verfolgen. Laut Jim Melton war ursprünglich vorgesehen etwa alle 3-4 Jahre eine neue Version des SQL-Standards herauszubringen. Aufgrund dem zu leistenden Aufwands zeigte sich aber relativ bald, dass man dafür länger Zeit brauchen würde; man peilte daher 1999 als Termin für SQL3 an. Da die Zielrichtung für SQL3 nun klar war, ihnen aber der Zeithorizont 1999 offensichtlich zu lang erschien, preschten Informix und Oracle vor und brachten bereits Mitte der 1990er erweiterte Versionen ihrer Datenbanksysteme auf den Markt.

Proprietäre SQL-Erweiterungen von Informix und Oracle

Informix führte die 'Collection data types' set, multiset und list ein. Das sieht auf den ersten Blick zwar sehr nach den Datenstrukturen des eNF²-Modells aus, allerdings können diese Konstrukte nur atomare Werte aufnehmen^[62] (siehe nachfolgendes Beispiel), was dann doch weit entfernt vom echten eNF²-Modell ist.

Oracle führte 1997 mit Version 8 seines Datenbanksystems in der 'Enterprise Edition mit Objects Option' echte NF²-Tabellen mit darauf abgestimmten, proprietären SQL-Erweiterungen ein.

Erläuterungen zu diesem Beispiel: In (1) wird der Typ namens TierTyp der einzuschachtelnden Tabelle deklariert. In (2) wird der Tabellen-Typ namens TierNT basierend auf Typ (1) deklariert. Die CREATE-Anweisung (3) legt nun die Tabelle Züchter mit dem relationswertigen Attribut Tiere vom Typ TierNT an. In (5) legt der Benutzer den Relationsnamen für die physische Speicherung der Tiere-Relation fest. In SELECT-, INSERT- und DELETE-Anweisungen spielt dieser „physische“ Relationsname dann keine Rolle mehr. Hier wird nur noch auf den Attributnamen und/oder den Typ der eingeschachtelten Relation Bezug genommen, wie die folgenden Beispiele zeigen.

Abb. 39: ORACLE-NF² - SELECT

Abb. 42: ORACLE-NF² - DELETE

SQL3-Diskussion: Stillstand und Kehrtwende

Der Klärungs-, Diskussions- und Abstimmungsbedarf für die ins Auge gefassten tiefgreifenden Erweiterungen von SQL3 war enorm. Nicht nur alle strukturbezogenen Begriffe und Definitionen mussten überprüft werden, ob sie in der bisherigen Form auch eNF²-Strukturen mit einschließen oder ob und ggf. wie sie geeignet erweitert werden müssen, sondern auch alle Konstrukte für Datenzugriff und -manipulation; und dann mussten auch noch geeignete Begriffe und präzise, implementierungsunabhängige Definitionen für die neu hinzukommenden Dinge gefunden werden. Da lag ein weiter und steiniger Weg vor den SQL-Standardisierern wenn man bedenkt, dass SQL'92 noch nicht einmal den „Typ“ Tabelle kennt. D.h. eine Anweisung der Art CREATE TABLE <tabname> OF <tabellentyp> gibt es dort noch nicht. Und dann: Eigentlich ist eine SQL-Relation eine „Multimenge“, da sie Duplikate enthalten kann. Soll man dann generell nur Kollektionen, bei denen die Reihenfolge keine Rolle spielt, vom Typ „Multiset“ im Datenmodell kennen oder sollte man auch den Typ „Menge“ anbieten?

Nun finden diese Diskussionen in den ISO-Gremien nicht nur in Form von persönlichen Treffen, sondern quasi weltweit verteilt auch in schriftlicher Form auf Basis von Zusammenfassungen des Diskussionsstands mit einer Liste der noch offenen Punkte statt, die tausend Seiten und mehr umfassen können.^[63]

Die Diskussion uferte laut Melton immer mehr aus und brachte zunehmend den gesamten Prozess ins Stocken und letztlich faktisch zum Stillstand. In dieser verfahrenen Situation brachte die „1NF+“-Gruppe wieder den alten „pragmatischen“ Vorschlag ins Spiel. Am Ende einigte man sich im ISO-SQL-Gremium schließlich darauf, diesen fortan als Grundlage für den zukünftigen SQL3-Standard zu nehmen, der dann auch als SQL:1999 und SQL:2003^[64]^[65] so publiziert wurde.

Diese Realisierungsform erfüllt leider nicht einmal annähernd die Anforderungen, die man im Bereich der technisch-wissenschaftlichen Anwendungen benötigt und die bei der Entwicklung von AIM-P im Vordergrund standen (siehe Abschnitt 'Explorationsphase und frühe Entwurfs-Entscheidungen' sowie den Wikipedia-Beitrag zu eNF²-Relationen).

Jim Melton zog in einem Radio-Podcast am 5. Juni 2009^[66] zu den objektorientierten Erweiterungen von SQL (ab Stelle 18:20) ins Deutsche übersetzt das folgende Fazit: „Ich glaube, dass der objektorientierte SQL-Teil keinen großen Erfolg hatte. Kein Anbieter den ich kenne hat das alles implementiert. Oracle hat einen Teil davon implementiert, Sybase hat einen Teil davon implementiert, IBM hat einen Teil davon implementiert und die Teile überschneiden sich auch alle, aber die überlappenden Teile, die Überschneidung von allem, ist meiner Meinung nach nicht groß genug, um sinnvolle Anwendungen zu erstellen. Folglich haben wir nicht die Akzeptanz und Kundennutzung erreicht, die wir uns erhofft hatten. Und die Entwicklung war extrem teuer. Wir haben eine Menge Lektionen daraus gelernt und ich hoffe, wir werden nie wieder etwas derart Substanzielles tun.“

IBM-interne Aspekte

AIM-P und IMS

Ab Mitte der 1980er Jahre zogen immer mehr IBM-Großkunden im Rahmen ihrer strategischen Planungen in Erwägung, das Datenbanksystem IMS durch DB2 abzulösen, sobald dieses die erforderliche Funktionalität, Stabilität und Performanz für einen produktiven Einsatz haben wird. Die wesentliche Herausforderung einer solchen Umstellung sind nicht die Daten und deren Transformation vom hierarchischen in das relationale Datenmodell, sondern die große Mengen von Anwendungsprogrammen mit zig- bis hunderttausenden Zeilen an Programmcode, die auf die Anwendungsprogrammschnittstelle von IMS aufsetzen, die völlig verschieden von der von DB2 ist. Erschwerend kommt hinzu, dass vielfach verschiedene Anwendungen auf denselben Datenbestand zugreifen. Aufgrund lückenhafter oder fehlender (aktueller) Dokumentation hierbei oftmals nicht so ohne weiteres feststellbar, welche Anwendungen mit welchen anderen Abhängigkeiten dieser Art haben. Aufgrund dieser und anderer Faktoren wird sich eine derartige Umstellung daher über viele Jahre hinziehen (manche Besucher am WZH schätzten sogar 10-15 Jahre für ihr Unternehmen) und macht während dieser Zeit einen Parallelbetrieb von IMS und DB2 erforderlich; und zwar unter Konsistenthaltung der Datenbestände in beiden Systemen.

In Diskussionen mit H.J. Schneider, der während seines zweiten Sabbaticals (siehe Abschnitt Gastwissenschaftler) mehrere Wochen am WZH weilte, kam die Idee auf einmal auszuprobieren, wie einfach oder schwierig es wäre, IMS mit seinem hierarchischen Datenmodell, mit einem AIM-P-Aufsatz als interaktive und ggf. auch als alternative Anwendungsprogramm-Schnittstelle versehen. Dieses AIM-P^IMS-System würde intern die hierarchischen Datenstrukturen des IMS-Datenmodells – soweit passend – als NF²- oder eNF²-Strukturen interpretieren und „nach oben“ mittels HDBL-Anfrage in der jeweils gewünschten Form ausgeben, d.h. als geschachtelte oder als flache Relation. Dies würde für die Migration perspektivisch die Möglichkeit eröffnen, die Daten zunächst einmal in IMS zu belassen und den neu zu implementierenden „relationalen“ Anwendungen mittels AIM-P^IMS bereits die zukünftige relationale Anwendungsprogrammschnittstelle von DB2 (oder ggf. dessen von HDBL inspiriertem Nachfolger) bereitzustellen. Die echte Migration auf das andere Datenbanksystem könnte man dann evtl. für ganze Gruppen von voneinander abhängigen Anwendungsprogrammen en bloc durchführen und sich damit u.U. eine redundante Datenspeicherung und die Problematik der Konsistenthaltung ersparen.

Dieses Vorhaben wurde dann mit zwei Diplomanden der TU Berlin (M. Didschuns, A. Perkhoff), die für ca. 1/2 Jahr ans WZH kamen, mit Unterstützung der AIM-Gruppe in Angriff genommen. Der Query Processor von AIM-P (siehe Abschnitt System-Architektur) konnte weitgehend unverändert verwendet werden, während der Complex Object Manager weitgehend neu implementiert wurde und der Subtuple-Manager durch die Schnittstelle zu IMS ersetzt wurde. Da IMS nicht im WZH-Rechenzentrum installiert war, wurde AIM-P^IMS im IBM Rechenzentrum in Düsseldorf installiert und die Datenbankanfrage mittels AIM-P^IMS von Heidelberg via Remote-Zugriff ausgeführt. Auf Seiten von IMS wurden für die Teile der Datenbank, auf die mittels AIM-P^IMS zugegriffen werden soll, sog. 'PSB'- und 'DBD'-Spezifikationen hinterlegt, die in gewisser Weise „Sichten“ auf die IMS-Datenbank bereitstellen, welche die mit diesen verbundene Anwendung zu sehen bekommt. Diese „Sichten“ wurden im AIM-P^IMS-Katalog abgelegt und von der Anfragebearbeitung mittels HDBL genutzt. (Ausführliche Beispiele zu IMS (Datenmodell, DL/1, Bedeutung von PSB und PCB usw.) finden sich bei Interesse in P. Dadam: Datenbanksysteme - Konzepte und Modelle.^[67])

Um den Aufwand zu begrenzen, wurden zwar nur lesende Zugriffe realisiert, aber selbst diese zeigten bereits eindrucksvoll, was mit diesem Ansatz im Prinzip möglich wäre. Allerdings ist es so, dass IMS den Anwendungen einen großen Spielraum lässt, was sie alles in die Datensätze (im IMS-Jargon „Segmente“) hineinpacken. Abgesehen davon, ob und wie gut dies dokumentiert ist, wurden auf diese Weise anwendungsspezifische Verbund-Datentypen realisiert, wo z.B. nur die Anwendung durch eine Kennzahl im ersten Byte des Datensatzes „weiß“, wie die restliche Folge von Bytes in diesem Datensatz zu interpretieren ist. Anwendungen, die auf solche Strukturen zugreifen, müsste man dann entweder außen vor lassen oder ein speziell „ausgebohrtes“ eNF² mit entsprechend erweiterter HDBL-Sprache realisieren.

In der Veröffentlichung „K. Küspert, A. Perkhoff: AIM-P^IMS: Konzepte einer NF²-Modell- und -Sprachoberfläche für ein hierarchisches Datenbanksystem“^[68], der auch Abb. 43 entnommen ist, finden sich noch weitere Informationen zu diesem interessanten Experiment.

**Abb. 43: Gesamt-Architektur der AIM-P^IMS-Realisierung**

Die IBM hatte sich zu diesem Zeitpunkt allerdings bereits entschieden eine „Connector“-Lösung für die Migrationsphase zu realisieren, so dass – wenn dafür eingerichtet – Updates auf IMS-Seite synchron entsprechende Updates auf DB2-Seite auslösen und umgekehrt. – Dies war eigentlich als „Übergangslösung“ gedacht, ist aber offensichtlich (auch im Jahr 2022) immer noch im Einsatz. Dasselbe gilt damit natürlich auch für IMS, wie man der IMS-Webseite von IBM entnehmen kann.

DB2: Vorgeschichte, Entwicklung und Herausforderungen

Nachdem Oracle 1979 mit Oracle V2 vorgeprescht war und damit auf dem Markt viel Aufmerksamkeit erregt hatte, zog IBM 1981 mit der ersten Version ihres relationalen Datenbanksystems mit der Bezeichnung SQL/DS und zwei Jahre später mit DB2 nach^[69]. Zu diesem Zeitpunkt hatte IBM allerdings bereits das weltweit mit großem Abstand am häufigsten eingesetzte Datenbanksystem IMS, einer wahren „Cash Cow“ für IBM, auf dem Markt. Man positionierte daher DB2 eher als eine Plattform für interaktive Datenanalysen, denn als produktiv einsetzbares Datenbanksystem. Dies stimmte in gewisser Weise auch, da IMS dem noch jungen DB2 in Sachen Performanz, praxis-relevanter Funktionalität sowie Ressourcenverbrauch für einen produktiven Einsatz haushoch überlegen war.

Die DB2-Entwicklung wurde im IBM Santa Teresa Lab, Cal., USA, angesiedelt. Den dort Verantwortlichen war klar, dass DB2 nur dann profitabel werden und damit im IBM-internen Konkurrenzkampf mit IMS bestehen konnte, wenn die Performanz, die Robustheit, die praxis-relevante Funktionalität sowie die Anforderungen an die Hardware von DB2 so verbessert werden können, dass es auch für einen produktiven Einsatz in performanzkritischen Anwendungsbereichen in Frage kommt. Wichtige Forschungs- und Entwicklungsthemen waren daher u.a. Verbesserung der Anfrageoptimierung, Parallelisierung der Anfragebearbeitung, Realisierung verteilter Datenbanken sowie bessere Integration von DB2 in das Betriebssystem (Prozessverwaltung, Interprozess-Kommunikation, Prozess-Synchronisation, Sperrverwaltung, Paging und vieles andere mehr).

DB2 und AIM-P

Nachdem bereits in den Jahren zuvor Berichte über das Entwicklungsvorhaben^[2]^[3] sowie über einzelne Aspekte^[14]^[27] publiziert worden waren, wurde 1986 erstmals AIM-P selbst (als lauffähiges System) durch einen Vortrag auf der ACM-Sigmod-Tagung in Washington, D.C., einer großen internationalen Tagung, der wissenschaftlichen Öffentlichkeit vorgestellt.^[1] Im Anschluss daran geschah dies auch IBM Alamaden Research Lab und dem Santa Teresa Lab, dort allerdings verbunden mit einer Live-Demonstration von AIM-P. Ab diesem Zeitpunkt gab es einen regen Informationsaustausch mit IBM Almaden Research und dem Santa Teresa Lab, der Ende der 1980er Jahre sogar zu einer zweijährigen Abordnung von zwei Mitarbeitern der AIM-Abteilung an das IBM Database Technology Institute (DBTI)^[70] in Santa Teresa führte, um sich mit ihrem Erfahrungshintergrund aus dem AIM-P-Projekt dort einzubringen. – Möglicherweise war die Abordnung der beiden Mitarbeiter nicht zuletzt auch dadurch motiviert, dass zu diesem Zeitpunkt, wie bereits oben erwähnt, das eNF²-Datenmodell und HDBL im ISO-SQL-Standardisierungsgremium für den zu entwickelnden SQL3-Standard^[71] diskutiert wurde.

DB2 komplett in Richtung nativer Unterstützung von eNF²-Strukturen umzukrempeln, war angesichts der im vorherigen Abschnitt beschriebenen Herausforderungen wohl keine ernsthafte Option für Almaden und Santa Teresa, denn die gemeinsamen Überlegungen gingen offensichtlich in die Richtung, eine NF²-ähnliche Sicht „on top“ von DB2 zu realisieren und es intern im Wesentlichen bei den flachen Relationen zu belassen.^[72]^[73]

AIM-P-Team

Die Entwicklung und Implementierung eines so großen und ambitionierten Systems wie AIM-P wäre ohne ein so großes „Kern-Team“ und ohne die Mitwirkung der vielen Gastwissenschaftler sowie die über Kooperationsprojekte mit Universitäten involvierten Wissenschaftler^[40] nicht möglich gewesen.

WZH-Mitarbeiter

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

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 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

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 (R²D²): Peter Lockemann, Rüdiger Dillmann, Alfons Kemper, Mechthild Wallrath, Martin Dürr, Martin Huck

Einzelnachweise

↑ ^a ^b ^c 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.
↑ ^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. Band 94. Springer Berlin Heidelberg, Berlin, Heidelberg 1985, ISBN 3-540-15196-6, S. 362–381, doi:10.1007/978-3-642-70284-6_26.
↑ ^a ^b ^c ^d ^e 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 0-89791-128-8, S. 115, doi:10.1145/602259.602276.
↑ ^a ^b ^c 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 (ieee.org [abgerufen am 10. Dezember 2022]).
↑ S. Abiteboul, P. C. Fischer, H. -J. Schek (Hrsg.): Nested Relations and Complex Objects in Databases (= Lecture Notes in Computer Science, 361). Springer, Berlin / Heidelberg 1989, ISBN 978-3-540-51171-7, doi:10.1007/3-540-51171-7.
↑ Ein Grund für diese Bekanntheit war - neben der Qualität der Forschungsarbeiten - sicherlich auch, dass sich am WZH eine verhältnismäßig große Gruppe von Wissenschaftlern in Vollzeit und damit in viel größerer Breite und Tiefe mit diesem Themenkomplex befassen konnte, als dies den überwiegend universitären Forschungsgruppen möglich war.
↑ Datenbankprototyp für technisch-wissenschaftliche Anwendungen: IBM-Entwickler basteln an NF2-Erweiterung. In: Computerwoche. 25. März 1988, abgerufen am 8. Januar 2023.
↑ Simon Hill: IBM returns to the DB2 drawing board. In: Computer Weekly. 16. März 1989 (researchgate.net – Der Artikel findet sich auf Seite 339 des Vorlesungsskripts).
↑ Albrecht Blaser: Die BTW im Wandel der Datenbank-Zeiten. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Springer Berlin Heidelberg, Berlin, Heidelberg 1995, ISBN 978-3-540-59095-8, S. 48–50, doi:10.1007/978-3-642-79646-3_3 (springer.com [abgerufen am 8. Januar 2023]).
↑ Die Abbildungen in diesem Beitrag sind - mit Genehmigung des Urhebers - überwiegend dem Vorlesungsskript "P. Dadam: Datenbanksysteme - Konzepte und Modelle", Kapitel 7, entnommen.
↑ ^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 0-89791-073-7, S. 207, doi:10.1145/582353.582390 (acm.org [abgerufen am 18. November 2022]).
↑ R. Lorie, D. McNabb, W. Plouffe, K. Dittrich: A Database System for Engineering Design. In: Datenbank-Systeme für Büro, Technik und Wissenschaft. Band 94. Springer Berlin Heidelberg, Berlin, Heidelberg 1985, ISBN 3-540-15196-6, S. 356–361, doi:10.1007/978-3-642-70284-6_25.
↑ 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 0-89791-070-2, S. 124, doi:10.1145/588111.588133.
↑ ^a ^b ^c ^d Hans-Jörg Schek, Peter Pistor: Data Structures for an Integrated Data Base Management and Information Retrieval System. In: VLDB '82: Proceedings of the 8th International Conference on Very Large Data Bases, Mexico City. September 1982, S. 197–207 (vldb.org [PDF]).
↑ H.J. Schek: TOLERATING FUZZINESS IN KEYWORDS BY SIMILARITY SEARCHES. In: Kybernetes. Band 6, Nr. 3, 1. März 1977, ISSN 0368-492X, S. 175–184, doi:10.1108/eb005450.
↑ ^a ^b H. -J. Schek: The reference string indexing method. In: Information Systems Methodology. Band 65. Springer Berlin Heidelberg, Berlin, Heidelberg 1978, ISBN 3-540-08934-9, S. 432–459, doi:10.1007/3-540-08934-9_92.
↑ ^a ^b ^c H.-J. Schek: Methods for the Administration of Textual data in Database Systems. In: SIGIR '80: Proceedings of the 3rd annual ACM conference on Research and development in information retrieval, Cambridge England. Juni 1980, S. 218–235, doi:10.5555/636669.636683.
↑ ^a ^b ^c ^d ^e P. Pistor, B. Hansen, M. Hansen: Eine Sequelartige Sprachschnittstelle für Das NF2-Modell. In: Sprachen für Datenbanken. Band 72. Springer Berlin Heidelberg, Berlin, Heidelberg 1983, ISBN 3-540-12733-X, S. 134–147, doi:10.1007/978-3-642-69297-0_9.
↑ M. Scholl, S. Abiteboul, F. Bancilhon, N. Bidoit, S. Gamerman, D. Plateau, P. Richard, A. Verroust: Verso: A database machine based on nested relations. In: Nested Relations and Complex Objects in Databases. Band 361. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-51171-7, S. 27–49, doi:10.1007/3-540-51171-7_19.
↑ ^a ^b ^c ^d ^e P. Dadam, R. Erbe, K. Staab: Sub Tuple Manager - External Interface Description - Subtuple Manager - Release 1.1. In: Interner Bericht AIM-P Projekt, IBM Wissenschaftliches Zentrum Heidelberg. 26. November 1984 (researchgate.net).
↑ ^a ^b Peter Pistor, Flemming 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]).
↑ ^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 (elsevier.com [abgerufen am 30. November 2022]).
↑ ^a ^b ^c ^d Peter Pistor, Peter Dadam: The advanced information management prototype. In: Nested Relations and Complex Objects in Databases. Band 361. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-51171-7, S. 1–26, doi:10.1007/3-540-51171-7_18.
↑ 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 3-540-15196-6, S. 441–459, doi:10.1007/978-3-642-70284-6_30.
↑ Peter Dadam: Datenbanksysteme - Konzepte und Modelle (Vorlesung). Kapitel 7: Relationales Datenmodell III:NF2- und eNF2-Relationenmodell, 2013, S. 269–342 (researchgate.net).
↑ ^a ^b P. Dadam, J. Teuhola: Managing Schema Versions in a Time-Versioned Non-First-Normal-Form Relational Database. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Band 136. Springer Berlin Heidelberg, Berlin, Heidelberg 1987, ISBN 3-540-17736-1, S. 161–179, doi:10.1007/978-3-642-72617-0_12.
↑ ^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]).
↑ ^a ^b Theo Härder, Erhard Rahm: Logging und Recovery. In: Datenbanksysteme. Springer Berlin Heidelberg, Berlin, Heidelberg 1999, ISBN 3-642-98017-1, S. 455–497, doi:10.1007/978-3-642-98016-9_15.
↑ ^a ^b Peter Dadam: Datenbanksysteme - Konzepte und Modelle (Vorlesung). Kapitel 14: Interne Aspekte von DBMS - 14.3 Fehlerbehandlung (Recovery), 2013, S. 78–80 (researchgate.net).
↑ ^a ^b 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, Januar 1990, S. 187–203, doi:10.1016/0951-8320(90)90063-S (elsevier.com [abgerufen am 20. November 2022]).
↑ ^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, Berlin, Heidelberg 1988, ISBN 3-540-19137-2, S. 289–303, doi:10.1007/978-3-642-73574-5_18.
↑ 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 5. Dezember 2022]).
↑ Rüdiger Dillmann: Types of Robols and Their Integration into Computer-Integrated Manufacturing Systems. In: Ulrich Rembold (Hrsg.): Robot Technology and Applications. 1. Auflage. CRC Press, Boca Raton 1990, ISBN 1-00-306634-8, S. 1–61 (https://www.taylorfrancis.com/books/edit/10.1201/9781003066347/robot-technology-applications-ulrich-rembold (PREVIEW PDF)).
↑ 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, Berlin, Heidelberg 1988, ISBN 3-540-19137-2, S. 355–372, doi:10.1007/978-3-642-73574-5_21.
↑ 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, Berlin, Heidelberg 1988, ISBN 3-540-19137-2, S. 289–303, doi:10.1007/978-3-642-73574-5_18.
↑ ^a ^b ^c P. Dadam, K. Küspert, N. Südkamp, R. Erbe, V. Linnemann: Managing Complex Objects in R2D2. In: Hector Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer Berlin Heidelberg, Berlin, Heidelberg 1988, ISBN 3-540-19137-2, S. 304–331, doi:10.1007/978-3-642-73574-5_19.
↑ 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. Band 126. Springer Berlin Heidelberg, Berlin, Heidelberg 1986, ISBN 3-540-16813-3, S. 565–580, doi:10.1007/978-3-642-71388-0_44.
↑ 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, Berlin, Heidelberg 1989, ISBN 3-540-51821-5, S. 274–286, doi:10.1007/978-3-642-75177-6_22.
↑ ^a ^b Klaus Küspert, Peter Dadam, Jürgen Günauer: Cooperative Object Buffer Management in the Advanced Information Management Prototype. In: VLDB '87: Proceedings of the 13th International Conference on Very Large Data Bases, Brighton, England. September 1987, S. 483–492.
↑ ^a ^b 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, 8. HDSC Staff Members and Visiting Scientists (214 S.).
↑ Michael Stonebraker: Inclusion of new types in relational data base systems. In: 1986 IEEE Second International Conference on Data Engineering. IEEE, Los Angeles, CA, USA 1986, ISBN 0-8186-0655-X, S. 262–269, doi:10.1109/ICDE.1986.7266230.
↑ ^a ^b Lawrence A. Rowe, Michael Stonebraker: The POSTGRES Data Model. VLDB '87: Proceedings of the 13th International Conference on Very Large Data Bases, Brighton, England, September 1987, S. 83–96 (semanticscholar.org).
↑ ^a ^b Bruce Lindsay, Laura Haas: Extensibility in the starburst experimental database system. In: Database Systems of the 90s. Band 466. Springer Berlin Heidelberg, Berlin, Heidelberg 1990, ISBN 3-540-53397-4, S. 217–248, doi:10.1007/3-540-53397-4_38.
↑ 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 1-4832-1313-7, S. 211–226, doi:10.1016/b978-1-4832-1313-2.50023-8 (sciencedirect.com [abgerufen am 17. November 2022]).
↑ G. Saake, V. Linnemann, P. Pistor, L. Wegner: Sorting, Grouping and Duplicate Elimination in the Advanced Information Management Prototype. In: VLDB '89, Proceedings of the 15th International Conference on Very Large Data Bases, Amsterdam, The Netherlands. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA Juli 1989, S. 307–316 (researchgate.net).
↑ K. Küspert, G. Saake, L. Wegner: Duplicate detection and deletion in the extended NF2 data model. In: Foundations of Data Organization and Algorithms. Band 367. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-51295-0, S. 83–100, doi:10.1007/3-540-51295-0_120.
↑ Volker Linnemann: Non first normal form relations and recursive queries: An SQL-based approach. In: 1987 IEEE Third International Conference on Data Engineering. IEEE, Los Angeles, CA, USA 1987, ISBN 0-8186-0762-9, S. 591–598, doi:10.1109/ICDE.1987.7272428.
↑ Volker Linnemann: Funktional rekursive Anfragen auf der Basis von geschachtelten Tabellen. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Band 204. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-50894-5, S. 408–427, doi:10.1007/978-3-642-74571-3_37.
↑ N. Südkamp, V. Linnemann: Elimination of View and Redundant Variables in a SQL-like Database Language for Extended NF2 Structures. In: VLDB 1990, Proceedings 16th International Conference on Very Large Data Bases,Brisbane, Queensland, Australia. August 1990, S. 302–313 (sigmod.org).
↑ Peter Dadam: Synchronisation und Recovery in verteilten Datenbanken: Konzepte und Grundlagen. In: Dissertation, Fachbereich Mathematik und Information der FernUniversität Hagen. Juni 1982.
↑ U. Herrmann, P. Dadam, K. Küspert, G. Schlageter: Sperren disjunkter, nicht-rekursiver komplexer Objekte mittels objekt- und anfragespezifischer Sperrgraphen. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Band 204. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-50894-5, S. 98–113, doi:10.1007/978-3-642-74571-3_9.
↑ 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. Band 416. Springer-Verlag, Berlin/Heidelberg 1990, ISBN 3-540-52291-3, S. 219–237, doi:10.1007/bfb0022173.
↑ Ulrich Herrmann: Mehrbenutzerkontrolle in Nicht-Standard-Datenbanksystemen. In: Informatik-Fachberichte (= Informatik-Fachberichte). Band 265. Springer-Verlag, Berlin / Heidelberg 1991, ISBN 3-540-53576-4, doi:10.1007/978-3-642-76360-1.
↑ Peter Dadam, Peter Pistor, Hans-Jörg Schek: A Predicate Oriented Locking Approach for Integrated Information Systems. In: Proceedings IFIP 9th World Computer Congress, Paris, France. September 1983, S. 763–768 (researchgate.net).
↑ ^a ^b Peter Dadam, Vincent Y. Lum, U. Prädel, Gunter Schlageter: Selective Deferred Index Maintenance & Concurrency Control in Integrated Information Systems. In: VLDB '85: Proceedings of the 11th international conference on Very Large Data Bases, Stockholm, Sweden. August 1985, S. 142–150 (vldb.org [PDF]).
↑ CODASYL. Abgerufen am 14. November 2022.
↑ The SQL Standardization Process. In: Advanced SQL:1999. Elsevier, 2003, ISBN 1-55860-677-7, S. 519–530, doi:10.1016/b978-155860677-7/50017-1 (elsevier.com [abgerufen am 1. Januar 2023]).
↑ SQL-Standards: Hersteller öffnen sich dem Wettbewerb - Standardisierung macht Datenbankprodukte und -Tools austauschbar. In: Computerwoche. 13. März 1992, abgerufen am 14. November 2022.
↑ The SQL Standardization Process. In: Advanced SQL:1999. Elsevier, 2003, ISBN 1-55860-677-7, S. 519–530, doi:10.1016/b978-155860677-7/50017-1 (elsevier.com [abgerufen am 1. Januar 2023]).
↑ 1988 hielt Peter Dadam, der Leiter des AIM-P-Projekts, auf Einladung des NIST in Gaithersburg einen ausführlichen Vortrag mit anschließender Diskussion über AIM-P, dessen eNF²-Datenmodell und Datenbanksprache sowie dessen Erweiterbarkeit durch benutzerdefinierte Datentypen und Funktionen. Wenige Wochen später waren dann zwei wissenschaftliche Mitarbeiter des NIST für eine Woche zu Gast am WZH, um sich anhand komplexer technisch-wissenschaftlicher Problemstellungen in Theorie und konkreter Praxis mit „hands-on“ am AIM-P-System, vertieft mit diesem technologischen Ansatz zu befassen.
↑ Gespräch von Jim Melton mit Peter Dadam und Manfred Reichert (zu diesem Zeitpunkt beide Professoren für Informatik an der Universität Ulm) am 28.03.2003 bei Oracle in Redwood City, CA, USA
↑ IBM (Hrsg.): IBM Informix Database Design and Implementation Guide - Informix Product Family Informix Version 12.10. SC27-4511-00, 1996.
↑ Jim Melton: (ISO-ANSI Working Draft) Database Language SQL (SQL3). In: ANSI TC X3H2 ISO/IEC JTC 1/SC 21/WG 3 Database. ISO International Organization for Standardization + ANSI American National Standards Institute, August 1994 (fu-berlin.de [PDF]).
↑ Jim Melton: Advanced SQL:1999 - Understanding Object-Relational and Other Advanced Features. Morgan Kaufmann Publishers, San Francisco, CA, USA 2003, ISBN 1-55860-677-7.
↑ Can Türker: SQL:1999 & SQL:2993 - Objektrelationales SQL, SQLJ & SQL/XML. 1. Auflage. dpunkt.verlag, Heidelberg 2003, ISBN 3-89864-219-4.
↑ Jim Melton, Bernd Kolb: Episode 137: SQL with Jim Melton. In: Software Engineering Radio - The Podcast for Professional Software Developers. 5. Juni 2009, abgerufen am 16. November 2022 (englisch).
↑ Peter Dadam: Datenbanksysteme - Konzepte und Modelle (Vorlesung). Kapitel 3: Hierarchisches Datenmodell, 2013, S. 56–87 (researchgate.net).
↑ Klaus Küspert, Axel Perkhoff: AIM-P-IMS: Konzepte einer NF2-Modell- und -Sprachoberfläche für ein hierarchisches Datenbanksystem. In: Udo W. Lipeck, Stefan Brass, Gunter Saake (Hrsg.): Kurzfassungen des 2. Workshops „Grundlagen von Datenbanken“, Volkse, Informatik-Berichte TU Braunschweig. Nr. 90-02, Juni 1990, S. 57–60.
↑ Charles J. Bontempo: Celebrating IBM Data Management - White Paper. September 1998 (sigmod.org [PDF]).
↑ Burton Grad (Moderator): RDBMS Workshop: IBM - Oral History Project. In: Computer History Museum. 2007, S. 28 (computerhistory.org [PDF]).
↑ dem späteren SQL:1999 und SQL:2003
↑ B. Mitschang, H. Pirahesh, P. Pistor, B. Lindsay, N. Sudkamp: SQL/XNF-Processing composite objects as abstractions over relational data. In: Proceedings of IEEE 9th International Conference on Data Engineering. IEEE Comput. Soc. Press, Vienna, Austria 1993, ISBN 0-8186-3570-3, S. 272–282, doi:10.1109/ICDE.1993.344055.
↑ H. Pirahesh, B. Mitschang, N. Südkamp, B. Lindsay: Composite-object views in relational DBMS: An implementation perspective. In: Advances in Database Technology — EDBT '94. Band 779. Springer Berlin Heidelberg, Berlin, Heidelberg 1994, ISBN 3-540-57818-8, S. 23–30, doi:10.1007/3-540-57818-8_38.

Kategorie:Heidelberg Kategorie:Datenbanktheorie

[:25-1] 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.

[:24-2] 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 3-540-15196-6, S. 362–381, doi:10.1007/978-3-642-70284-6_26.

[:3-3] 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 0-89791-128-8, S. 115, doi:10.1145/602259.602276.

[:17-4] 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 (ieee.org [abgerufen am 10. Dezember 2022]).

[5] S. Abiteboul, P. C. Fischer, H. -J. Schek (Hrsg.): Nested Relations and Complex Objects in Databases (= Lecture Notes in Computer Science, 361). Springer, Berlin / Heidelberg 1989, ISBN 978-3-540-51171-7, doi:10.1007/3-540-51171-7.

[6] Ein Grund für diese Bekanntheit war - neben der Qualität der Forschungsarbeiten - sicherlich auch, dass sich am WZH eine verhältnismäßig große Gruppe von Wissenschaftlern in Vollzeit und damit in viel größerer Breite und Tiefe mit diesem Themenkomplex befassen konnte, als dies den überwiegend universitären Forschungsgruppen möglich war.

[7] Datenbankprototyp für technisch-wissenschaftliche Anwendungen: IBM-Entwickler basteln an NF2-Erweiterung. In: Computerwoche. 25. März 1988, abgerufen am 8. Januar 2023.

[8] Simon Hill: IBM returns to the DB2 drawing board. In: Computer Weekly. 16. März 1989 (researchgate.net – Der Artikel findet sich auf Seite 339 des Vorlesungsskripts).

[9] Albrecht Blaser: Die BTW im Wandel der Datenbank-Zeiten. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Springer Berlin Heidelberg, Berlin, Heidelberg 1995, ISBN 978-3-540-59095-8, S. 48–50, doi:10.1007/978-3-642-79646-3_3 (springer.com [abgerufen am 8. Januar 2023]).

[10] Die Abbildungen in diesem Beitrag sind - mit Genehmigung des Urhebers - überwiegend dem Vorlesungsskript "P. Dadam: Datenbanksysteme - Konzepte und Modelle", Kapitel 7, entnommen.

[:9-11] 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 0-89791-073-7, S. 207, doi:10.1145/582353.582390 (acm.org [abgerufen am 18. November 2022]).

[12] R. Lorie, D. McNabb, W. Plouffe, K. Dittrich: A Database System for Engineering Design. In: Datenbank-Systeme für Büro, Technik und Wissenschaft. Band 94. Springer Berlin Heidelberg, Berlin, Heidelberg 1985, ISBN 3-540-15196-6, S. 356–361, doi:10.1007/978-3-642-70284-6_25.

[13] 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 0-89791-070-2, S. 124, doi:10.1145/588111.588133.

[:0-14] Hans-Jörg Schek, Peter Pistor: Data Structures for an Integrated Data Base Management and Information Retrieval System. In: VLDB '82: Proceedings of the 8th International Conference on Very Large Data Bases, Mexico City. September 1982, S. 197–207 (vldb.org [PDF]).

[15] H.J. Schek: TOLERATING FUZZINESS IN KEYWORDS BY SIMILARITY SEARCHES. In: Kybernetes. Band 6, Nr. 3, 1. März 1977, ISSN 0368-492X, S. 175–184, doi:10.1108/eb005450.

[:18-16] H. -J. Schek: The reference string indexing method. In: Information Systems Methodology. Band 65. Springer Berlin Heidelberg, Berlin, Heidelberg 1978, ISBN 3-540-08934-9, S. 432–459, doi:10.1007/3-540-08934-9_92.

[:12-17] H.-J. Schek: Methods for the Administration of Textual data in Database Systems. In: SIGIR '80: Proceedings of the 3rd annual ACM conference on Research and development in information retrieval, Cambridge England. Juni 1980, S. 218–235, doi:10.5555/636669.636683.

[:1-18] P. Pistor, B. Hansen, M. Hansen: Eine Sequelartige Sprachschnittstelle für Das NF2-Modell. In: Sprachen für Datenbanken. Band 72. Springer Berlin Heidelberg, Berlin, Heidelberg 1983, ISBN 3-540-12733-X, S. 134–147, doi:10.1007/978-3-642-69297-0_9.

[19] M. Scholl, S. Abiteboul, F. Bancilhon, N. Bidoit, S. Gamerman, D. Plateau, P. Richard, A. Verroust: Verso: A database machine based on nested relations. In: Nested Relations and Complex Objects in Databases. Band 361. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-51171-7, S. 27–49, doi:10.1007/3-540-51171-7_19.

[:2-20] P. Dadam, R. Erbe, K. Staab: Sub Tuple Manager - External Interface Description - Subtuple Manager - Release 1.1. In: Interner Bericht AIM-P Projekt, IBM Wissenschaftliches Zentrum Heidelberg. 26. November 1984 (researchgate.net).

[:22-21] Peter Pistor, Flemming 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]).

[:23-22] 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 30. November 2022]).

[:10-23] Peter Pistor, Peter Dadam: The advanced information management prototype. In: Nested Relations and Complex Objects in Databases. Band 361. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-51171-7, S. 1–26, doi:10.1007/3-540-51171-7_18.

[24] 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 3-540-15196-6, S. 441–459, doi:10.1007/978-3-642-70284-6_30.

[25] Peter Dadam: Datenbanksysteme - Konzepte und Modelle (Vorlesung). Kapitel 7: Relationales Datenmodell III:NF2- und eNF2-Relationenmodell, 2013, S. 269–342 (researchgate.net).

[:26-26] P. Dadam, J. Teuhola: Managing Schema Versions in a Time-Versioned Non-First-Normal-Form Relational Database. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Band 136. Springer Berlin Heidelberg, Berlin, Heidelberg 1987, ISBN 3-540-17736-1, S. 161–179, doi:10.1007/978-3-642-72617-0_12.

[:4-27] 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]).

[:11-28] Theo Härder, Erhard Rahm: Logging und Recovery. In: Datenbanksysteme. Springer Berlin Heidelberg, Berlin, Heidelberg 1999, ISBN 3-642-98017-1, S. 455–497, doi:10.1007/978-3-642-98016-9_15.

[:21-29] Peter Dadam: Datenbanksysteme - Konzepte und Modelle (Vorlesung). Kapitel 14: Interne Aspekte von DBMS - 14.3 Fehlerbehandlung (Recovery), 2013, S. 78–80 (researchgate.net).

[:19-30] 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, Januar 1990, S. 187–203, doi:10.1016/0951-8320(90)90063-S (elsevier.com [abgerufen am 20. November 2022]).

[:13-31] 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, Berlin, Heidelberg 1988, ISBN 3-540-19137-2, S. 289–303, doi:10.1007/978-3-642-73574-5_18.

[32] 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 5. Dezember 2022]).

[33] Rüdiger Dillmann: Types of Robols and Their Integration into Computer-Integrated Manufacturing Systems. In: Ulrich Rembold (Hrsg.): Robot Technology and Applications. 1. Auflage. CRC Press, Boca Raton 1990, ISBN 1-00-306634-8, S. 1–61 (https://www.taylorfrancis.com/books/edit/10.1201/9781003066347/robot-technology-applications-ulrich-rembold (PREVIEW PDF)).

[34] 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, Berlin, Heidelberg 1988, ISBN 3-540-19137-2, S. 355–372, doi:10.1007/978-3-642-73574-5_21.

[35] 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, Berlin, Heidelberg 1988, ISBN 3-540-19137-2, S. 289–303, doi:10.1007/978-3-642-73574-5_18.

[:6-36] P. Dadam, K. Küspert, N. Südkamp, R. Erbe, V. Linnemann: Managing Complex Objects in R2D2. In: Hector Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer Berlin Heidelberg, Berlin, Heidelberg 1988, ISBN 3-540-19137-2, S. 304–331, doi:10.1007/978-3-642-73574-5_19.

[37] 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. Band 126. Springer Berlin Heidelberg, Berlin, Heidelberg 1986, ISBN 3-540-16813-3, S. 565–580, doi:10.1007/978-3-642-71388-0_44.

[38] 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, Berlin, Heidelberg 1989, ISBN 3-540-51821-5, S. 274–286, doi:10.1007/978-3-642-75177-6_22.

[:14-39] Klaus Küspert, Peter Dadam, Jürgen Günauer: Cooperative Object Buffer Management in the Advanced Information Management Prototype. In: VLDB '87: Proceedings of the 13th International Conference on Very Large Data Bases, Brighton, England. September 1987, S. 483–492.

[:5-40] 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, 8. HDSC Staff Members and Visiting Scientists (214 S.).

[41] Michael Stonebraker: Inclusion of new types in relational data base systems. In: 1986 IEEE Second International Conference on Data Engineering. IEEE, Los Angeles, CA, USA 1986, ISBN 0-8186-0655-X, S. 262–269, doi:10.1109/ICDE.1986.7266230.

[:7-42] Lawrence A. Rowe, Michael Stonebraker: The POSTGRES Data Model. VLDB '87: Proceedings of the 13th International Conference on Very Large Data Bases, Brighton, England, September 1987, S. 83–96 (semanticscholar.org).

[:8-43] Bruce Lindsay, Laura Haas: Extensibility in the starburst experimental database system. In: Database Systems of the 90s. Band 466. Springer Berlin Heidelberg, Berlin, Heidelberg 1990, ISBN 3-540-53397-4, S. 217–248, doi:10.1007/3-540-53397-4_38.

[44] 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 1-4832-1313-7, S. 211–226, doi:10.1016/b978-1-4832-1313-2.50023-8 (sciencedirect.com [abgerufen am 17. November 2022]).

[45] G. Saake, V. Linnemann, P. Pistor, L. Wegner: Sorting, Grouping and Duplicate Elimination in the Advanced Information Management Prototype. In: VLDB '89, Proceedings of the 15th International Conference on Very Large Data Bases, Amsterdam, The Netherlands. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA Juli 1989, S. 307–316 (researchgate.net).

[46] K. Küspert, G. Saake, L. Wegner: Duplicate detection and deletion in the extended NF2 data model. In: Foundations of Data Organization and Algorithms. Band 367. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-51295-0, S. 83–100, doi:10.1007/3-540-51295-0_120.

[47] Volker Linnemann: Non first normal form relations and recursive queries: An SQL-based approach. In: 1987 IEEE Third International Conference on Data Engineering. IEEE, Los Angeles, CA, USA 1987, ISBN 0-8186-0762-9, S. 591–598, doi:10.1109/ICDE.1987.7272428.

[48] Volker Linnemann: Funktional rekursive Anfragen auf der Basis von geschachtelten Tabellen. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Band 204. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-50894-5, S. 408–427, doi:10.1007/978-3-642-74571-3_37.

[49] N. Südkamp, V. Linnemann: Elimination of View and Redundant Variables in a SQL-like Database Language for Extended NF2 Structures. In: VLDB 1990, Proceedings 16th International Conference on Very Large Data Bases,Brisbane, Queensland, Australia. August 1990, S. 302–313 (sigmod.org).

[50] Peter Dadam: Synchronisation und Recovery in verteilten Datenbanken: Konzepte und Grundlagen. In: Dissertation, Fachbereich Mathematik und Information der FernUniversität Hagen. Juni 1982.

[51] U. Herrmann, P. Dadam, K. Küspert, G. Schlageter: Sperren disjunkter, nicht-rekursiver komplexer Objekte mittels objekt- und anfragespezifischer Sperrgraphen. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Band 204. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 3-540-50894-5, S. 98–113, doi:10.1007/978-3-642-74571-3_9.

[:20-52] 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. Band 416. Springer-Verlag, Berlin/Heidelberg 1990, ISBN 3-540-52291-3, S. 219–237, doi:10.1007/bfb0022173.

[53] Ulrich Herrmann: Mehrbenutzerkontrolle in Nicht-Standard-Datenbanksystemen. In: Informatik-Fachberichte (= Informatik-Fachberichte). Band 265. Springer-Verlag, Berlin / Heidelberg 1991, ISBN 3-540-53576-4, doi:10.1007/978-3-642-76360-1.

[:15-54] Peter Dadam, Peter Pistor, Hans-Jörg Schek: A Predicate Oriented Locking Approach for Integrated Information Systems. In: Proceedings IFIP 9th World Computer Congress, Paris, France. September 1983, S. 763–768 (researchgate.net).

[:16-55] Peter Dadam, Vincent Y. Lum, U. Prädel, Gunter Schlageter: Selective Deferred Index Maintenance & Concurrency Control in Integrated Information Systems. In: VLDB '85: Proceedings of the 11th international conference on Very Large Data Bases, Stockholm, Sweden. August 1985, S. 142–150 (vldb.org [PDF]).

[56] CODASYL. Abgerufen am 14. November 2022.

[57] The SQL Standardization Process. In: Advanced SQL:1999. Elsevier, 2003, ISBN 1-55860-677-7, S. 519–530, doi:10.1016/b978-155860677-7/50017-1 (elsevier.com [abgerufen am 1. Januar 2023]).

[58] SQL-Standards: Hersteller öffnen sich dem Wettbewerb - Standardisierung macht Datenbankprodukte und -Tools austauschbar. In: Computerwoche. 13. März 1992, abgerufen am 14. November 2022.

[59] The SQL Standardization Process. In: Advanced SQL:1999. Elsevier, 2003, ISBN 1-55860-677-7, S. 519–530, doi:10.1016/b978-155860677-7/50017-1 (elsevier.com [abgerufen am 1. Januar 2023]).

[60] 1988 hielt Peter Dadam, der Leiter des AIM-P-Projekts, auf Einladung des NIST in Gaithersburg einen ausführlichen Vortrag mit anschließender Diskussion über AIM-P, dessen eNF²-Datenmodell und Datenbanksprache sowie dessen Erweiterbarkeit durch benutzerdefinierte Datentypen und Funktionen. Wenige Wochen später waren dann zwei wissenschaftliche Mitarbeiter des NIST für eine Woche zu Gast am WZH, um sich anhand komplexer technisch-wissenschaftlicher Problemstellungen in Theorie und konkreter Praxis mit „hands-on“ am AIM-P-System, vertieft mit diesem technologischen Ansatz zu befassen.

[61] Gespräch von Jim Melton mit Peter Dadam und Manfred Reichert (zu diesem Zeitpunkt beide Professoren für Informatik an der Universität Ulm) am 28.03.2003 bei Oracle in Redwood City, CA, USA

[62] IBM (Hrsg.): IBM Informix Database Design and Implementation Guide - Informix Product Family Informix Version 12.10. SC27-4511-00, 1996.

[63] Jim Melton: (ISO-ANSI Working Draft) Database Language SQL (SQL3). In: ANSI TC X3H2 ISO/IEC JTC 1/SC 21/WG 3 Database. ISO International Organization for Standardization + ANSI American National Standards Institute, August 1994 (fu-berlin.de [PDF]).

[64] Jim Melton: Advanced SQL:1999 - Understanding Object-Relational and Other Advanced Features. Morgan Kaufmann Publishers, San Francisco, CA, USA 2003, ISBN 1-55860-677-7.

[65] Can Türker: SQL:1999 & SQL:2993 - Objektrelationales SQL, SQLJ & SQL/XML. 1. Auflage. dpunkt.verlag, Heidelberg 2003, ISBN 3-89864-219-4.

[66] Jim Melton, Bernd Kolb: Episode 137: SQL with Jim Melton. In: Software Engineering Radio - The Podcast for Professional Software Developers. 5. Juni 2009, abgerufen am 16. November 2022 (englisch).

[67] Peter Dadam: Datenbanksysteme - Konzepte und Modelle (Vorlesung). Kapitel 3: Hierarchisches Datenmodell, 2013, S. 56–87 (researchgate.net).

[68] Klaus Küspert, Axel Perkhoff: AIM-P-IMS: Konzepte einer NF2-Modell- und -Sprachoberfläche für ein hierarchisches Datenbanksystem. In: Udo W. Lipeck, Stefan Brass, Gunter Saake (Hrsg.): Kurzfassungen des 2. Workshops „Grundlagen von Datenbanken“, Volkse, Informatik-Berichte TU Braunschweig. Nr. 90-02, Juni 1990, S. 57–60.

[69] Charles J. Bontempo: Celebrating IBM Data Management - White Paper. September 1998 (sigmod.org [PDF]).

[70] Burton Grad (Moderator): RDBMS Workshop: IBM - Oral History Project. In: Computer History Museum. 2007, S. 28 (computerhistory.org [PDF]).

[71] späteren SQL:1999 und SQL:2003

[72] B. Mitschang, H. Pirahesh, P. Pistor, B. Lindsay, N. Sudkamp: SQL/XNF-Processing composite objects as abstractions over relational data. In: Proceedings of IEEE 9th International Conference on Data Engineering. IEEE Comput. Soc. Press, Vienna, Austria 1993, ISBN 0-8186-3570-3, S. 272–282, doi:10.1109/ICDE.1993.344055.

[73] H. Pirahesh, B. Mitschang, N. Südkamp, B. Lindsay: Composite-object views in relational DBMS: An implementation perspective. In: Advances in Database Technology — EDBT '94. Band 779. Springer Berlin Heidelberg, Berlin, Heidelberg 1994, ISBN 3-540-57818-8, S. 23–30, doi:10.1007/3-540-57818-8_38.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

[72]

[73]