Benutzer:Dokumentarix/Advanced Information Management Prototype

Dieser Artikel ist im Entstehen und noch nicht Bestandteil der freien Enzyklopädie Wikipedia.

Solltest du über eine Suchmaschine darauf gestoßen sein, bedenke, dass der Text noch unvollständig sein und Fehler oder ungeprüfte Aussagen enthalten kann. Wenn du Fragen zum Thema hast, nimm Kontakt mit dem Autor Dokumentarix auf.

Der „Advanced Information Management Prototype (AIM-P)“ gehörte in den 1980er und 1990er Jahren zu den bekanntesten 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. 1: Modellierung eines Roboters (vereinfacht)

Abb. 2: Relationale Speicherung der Roboter-Daten

Abb. 3: SQL-Anfrage zur Ausgabe der Daten zu Roboter 'Rob1'

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, tauchte man am WZH tief in die relationale Theorie und die zugrundeliegende Relationenalgebra ein 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.

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. – 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 sowie die Integration geeigneter Suchfunktionen in die SQL-Sprache von Interesse.

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
  • Computer Aided Design (CAD)
  • computer-aided manufacturing (CAM)
  • Betriebsdatenerfassung
• 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 und diese sukzessive für die jeweils neu hinzukommenden Strukturelemente zu erweitern. Hierbei gab es wichtige Ziele, die gemeinsam verfolgt werden mussten:

1. Die Datenbanksprache muss die strukturelle Mächtigkeit des Datenmodells (inkl. der temporalen Aspekte) voll unterstützen können
2. Die Datenbanksprache soll aufgrund klarer und einfacher Regeln einfach zu erlernen und zu verstehen sein
3. 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“.

Abb. 5: Speicherung von Roboter-Daten als eNF²-Relation

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. – 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. Der Entwurf sah vor, dass AIM-P über die folgende Funktionalitäten verfügen sollte:

• Unterstützung (der bereits bekannten Teile) des eNF²-Relationenmodells (dies waren NF² + Listen von Tupeln + „lange Felder“)
• 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: AIM-P System-Architektur

Abb. 6 illustriert die für AIM-P gewählte System-Architektur. 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. 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 – 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.

Abb. 7: Evolution der Datenmodelle

Die Datenbanksprache für dieses Datenmodell wurde dem entsprechend konzipiert und erhielt schließlich den Namen „Heidelberg Database Language“ (HDBL). 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. 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. Wenn die Mini-Directory-Subtuples physisch (mittels der Subtuple-Manager-Option „clustered insert“) 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“ 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.

Abb. 8: Minidirectory-Struktur zur internen Repräsentation der 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.

Abb. 9: Cursor des Complex Object Managers und ihre Abhängigkeiten

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“). 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, 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):

Abb. 13: HDBL-Anfrage mit ASOF (3)

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.

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

Abb. 14: Versionierte Datenspeicherung in AIM-P

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

Abb. 15: Transaction Workspace

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.

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

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.

Abb. 17: DECLARE TYPE (2)

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.

Abb. 19: DERIVE TYPE (1)

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.

Abb. 21: DERIVE TYPE (3)

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.

Abb. 22: DERIVE TYPE (4)

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') die benutzerdefinierten Datentypen von AIM-P um sog. „gekapselte“ Typen (encapsulated types) 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 konzipiert war, bei dem die serverseitig implementierten Funktion zur Bearbeitung der Objekte – im Sinne einer „kooperativen Objektbearbeitung“ – 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.

Abb. 27: Implementierung einer benutzerdefinierten Funktion

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:

Abb. 28: DECLARE FUNCTION (3) - (5)

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

Verwandte Ansätze

Die Idee, relationale Datenbanksysteme mit benutzerdefinierten Datentypen und Funktionen erweiterbar zu machen, hatte Michael Stonebraker 1986 mit seinem Papier „Inclusion of new types in relational data base systems“ in die Welt gesetzt, die in seinem im experimentellen Datenbanksystem Postgres auch implementiert wurde. Hierbei wurde der Basis-Datentyp 'String' dazu verwendet, die Daten des neuen Datentyps als lesbaren Text aufzunehmen. Sind diese Daten strukturiert, dann werden die einzelnen Teile durch Trennzeichen voneinander getrennt.

Angenommen, man möchte einen 2D-Quader mit seinen 4 Eckpunkten speichern, dann könnte man diesen etwa durch eine Folge von 8 Zahlen, die durch '#' getrennt werden, speichern. Wenn die Eckpunkte z. B. (2,1), (2,4), (4,4), (4,1) sind, dann würde die Zeichenkette etwa wie folgt aussehen: „2#1#2#4#4#4#4#1“. Alle Funktionen, die für diesen Datentyp deklariert werden, müssen diesen String parsen, die als Text repräsentierte Zahlen in einen INTEGER- oder REAL-Wert wandeln und dabei auch wissen, dass jeweils ein Paar von Zahlen einen Eckpunkt beschreibt.

Diese Idee wurde unter anderem auch von IBM Almaden Research im experimentellen Datenbanksystem Starburst – dem Nachfolger von System R – aufgegriffen. Der Ansatz wurde dabei dahingehend weiterentwickelt, dass man – je nach Eignung – alle im Datenbanksystem verfügbaren Basis-Datentypen als Implementierungsbasis verwenden konnte und die für diesen Basis-Datentyp verfügbaren Vergleichs- und Änderungsoperatoren durch Überladen (overloading) auch für den abgeleiteten Datentyp verfügbar machen konnte.

Natürlich könnte man diesen Ansatz auch dafür verwenden, um Objekte des Typs 'Robot_enNF2' als „quasi-atomaren“ benutzerdefinierten Datentyp zu speichern; man müsste sich nur eine geeignete lineare Darstellung und passende Trennzeichen überlegen. Aber der Aufwand für das Laden und Speichern eines solchen Objekts und die Implementierung der Funktionen wäre natürlich enorm. AIM-P mit seinem sein eNF²-Datenmodell den darauf zugeschnittenen benutzerdefinierten Datentypen und Funktionen hatte diesbezüglich daher eine funktionale Mächtigkeit, die weit über das hinausging, was andere experimentelle DBMS der 1980er und 1990er Jahre, wie etwa Postgres oder Starburst anzubieten hatten.

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: Jede Anfrage erzeugt ein Resultat-Objekt, für dessen Transfer ins Anwendungsprogramm (AP) man zwei Möglichkeiten hat:

1. 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
2. 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:

1. 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.
2. 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
3. Ausführen der Anfrage, Bewegen der Cursor und Transfer der durch sie zugreifbaren Daten ins Anwendungsprogramm

Abb. 31: Resultat-Objekt

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

Abb. 32: AIM-P-basierte Workstation-Datenbankserver-Architekur

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:

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

Abb. 33: Volles eNF² und eingeschränktes eNF² in AIM-P

Weiterführende Forschungs- und Entwicklungsarbeiten

HDBL und Anfragebearbeitung

Auch die Entwicklung der Datenbanksprache HDBL 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, 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 oder die Unterstützung von Sichten.

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

Abb. 34: Fragment Key Index

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

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. Auch die Transaction Workspaces dienen u. a. auch dem Zweck, das Zurücksetzen unvollständiger bzw. das Wiedereinspielen von Updates abgeschlossener Transaktionen zu vereinfachen.

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. – 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 “ 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. – 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 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. 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. 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 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. 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.

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, 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. 35: 1NF - 1NF+ - eNF² im Vergleich (Typ-Ebene)

Abb. 36: 1NF - 1NF+ - eNF² im Vergleich auf Instanzebene

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 (siehe nachfolgendes Beispiel), was dann doch weit entfernt vom echten eNF²-Modell ist.

Abb. 37: INFORMIX-Type Multiset

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.

Abb. 38: ORACLE-NF²-Tabellen

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

Abb. 40: ORACLE-NF2 - INSERT

Abb. 41: ORACLE-NF2 - UPDATE

Abb. 42: ORACLE-NF2 - 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.

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

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“, 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. 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 sowie über einzelne Aspekte 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. 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) 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 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.

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

Kategorie:Heidelberg Kategorie:Datenbanktheorie