Der Advanced Information Management Prototype (AIM-P) war ein experimentelles Datenbankmanagementsystem (DBMS), das am Wissenschaftlichen Zentrum Heidelberg (WZH) der IBM von 1982 bis 1989 entwickelt und erprobt wurde. Der Entwurf, die Entwicklung sowie der anschließende Einsatz von AIM-P in technisch-wissenschaftlichen Anwendungsprojekten diente als „Proof of Concept“ für wesentliche Teile des am WZH entwickelten Datenmodells der „Erweiterten NF2-Relationen“ (eNF2-Relationen), der darauf abgestimmten SQL-ähnlichen Anfragesprache HDBL, den benutzerdefinierten Datentypen und Funktionen, der Programmierschnittstelle zur Anwendungsentwicklung (API), der Unterstützung temporaler Daten sowie dem neuartigen Ansatz für das kooperative Zusammenwirken von (CAx-)Workstations mit Datenbankservern („Workstation-Server-Kooperation“). Die Bezeichnung „Prototype“ diente der Klarstellung, dass es sich nicht um ein kommerzielles Produkt von IBM handelt, sondern um eine experimentelle Implementierung eines DBMS zur Erprobung dieser technologischen Konzepte. Die entstandenen Publikationen zeigen allerdings, dass die erarbeiteten Konzepte im Prinzip „produkttauglich“ sein sollten, wie z. B. die internen Datenstrukturen für die eNF2-Relationen zum effizienten Zugriff sowohl auf ein eNF2-Objekt als Ganzes als auch auf dessen Teile und die tief im Systemkern verankerte Unterstützung der Zeitversionen.
Am Entwurf und der Implementierung von AIM-P arbeiteten neben den WZH-Wissenschaftlern viele Gastwissenschaftler aus Deutschland, Europa und den USA sowie in Form von institutionellen Forschungskooperationen mit den Universitäten Darmstadt, der Fernuniversität in Hagen sowie der Universität Karlsruhe (dem heutigen KIT) mit. Dies spiegelt sich auch in den über 80 wissenschaftlichen Publikationen von Projektmitgliedern wider, die während ihrer Mitarbeit beim Entwurf, der Implementierung, der Entwicklung weiterer Konzepte und der Evaluation des AIM-P-Systems entstanden sind. Das AIM-P-Forschungs- und Entwicklungsprojekt (insbesondere der NF2-/eNF2-Ansatz) inspirierte weltweit zahlreiche Forschungsaktivitäten (wie z. B. in Australien, Finnland, Frankreich, Italien, Indien, Japan, Kanada, Niederlande und den USA). Teile des NF2-/eNF2-Ansatzes wurden später auch in kommerzielle relationale DBMS integriert (wie z. B. 1997 in Oracle Version 8 und 1999 in Informix Dynamic Server.2000) und gingen z. T. auch in den SQL-Standard ab SQL:2003 ein, allerdings in einer im Vergleich zum AIM-P-Ansatz stark eingeschränkten Form.
Vorgeschichte Ende der 1970er Jahre – also noch bevor die ersten kommerziellen relationalen DBMS auf den Markt kamen – experimentierten Wissenschaftler am IBM Research Laboratory in San Jose (dem späteren IBM Almaden Research Center) und am Wissenschaftlichen Zentrum Heidelberg der IBM mit den Einsatz von System R in Anwendungen, in denen komplex strukturierte Datenobjekte zu verwalten waren. In San Jose waren dies ingenieurwissenschaftliche, während es in Heidelberg Dokumentenretrieval-Anwendungen waren. Beide Gruppen kamen unabhängig voneinander zu dem Ergebnis, dass auf dem Relationenmodell von E.F. Codd basierende Datenbanksysteme mit ihren (wegen der 1. Normalform) „flachen“ Relationen (im Folgenden „1NF-Relationen“ genannt) für Anwendungen dieser Art nicht geeignet sein werden.
Während man im San Jose Research Lab der IBM den auf 1NF-Relationen ausgerichteten DBMS-Kern nicht anrührte und es mit einem „On-Top“-Ansatz (im Folgenden XSQL genannt) versuchte, erweiterte man am WZH die theoretische Grundlage des relationalen Datenmodells und die zugrundeliegende Relationenalgebra, so dass diese auch Relationen mit relationswertigen Attributen („geschachtelte Relationen“), unterstützen konnte. Da dieses erweiterte relationale Datenmodell die Forderung der ersten Normalform (1NF) aufgibt, nannte man es Non First Normal Form Relations (abgekürzt NF2-Relationen) und skizzierte auch einen Sprachvorschlag zur Erweiterung der Datenbank-Anfragesprache SQL.
Nachdem diese Schwächen der in Entwicklung befindenden relationalen DBMS erkannt wurden, richtete man Ende der 1970er Jahre am WZH den Forschungsbereich „Advanced Information Management“ (AIM) ein, um dort die Anforderungen an zukünftige Datenbanksysteme in neuen Anwendungsbereichen systematisch zu untersuchen und hierfür ggf. geeignete (und bei Bedarf auch über den NF2-Ansatz hinausgehende) Lösungskonzepte zu entwickeln. Zu Anfang wurden eine ganze Reihe von „Nicht-Standard“-Datenbankanwendungen, wie z. B. Computer Integrated Manufacturing (CIM), Computer Aided Design (CAD), Robotik, Geoinformationssysteme, Dokumenten-Verwaltung (Dokumenten-Retrieval), untersucht, um ihre Anforderungen an die benötigten Datenstrukturen und Datentypen, die Art der Anfragen und die daraus resultierenden Anforderungen an das Datenbanksystem zu ermitteln.
Die hierbei gewonnenen Erkenntnisse ließen erkennen, dass auch das NF2-Relationenmodell nicht alle Anforderungen abdecken kann, sondern dass ein noch mächtigeres Datenmodell, eine dazu passende Anfragesprache sowie die Unterstützung benutzerdefinierter Datentypen und Operationen benötigt werden. Außerdem sollten geeignete Konzepte für das Zusammenwirken von CAx-Workstations mit Datenbankservern („Workstation-Server-Kooperation“) sowie die Unterstützung zeitversionierter Daten (im Sinne einer temporalen Datenbank) erarbeitet werden.
System-Architektur Ende 1982 wurde dann am WZH entschieden einen DBMS-Prototyp zu bauen, in dessen Entwurf und Implementierung alle wesentlichen Erkenntnisse einfließen sollten, die sich im Verlauf des Projektes ergeben, so dass diese nach Fertigstellung dieses DBMS in realitätsnahen Anwendungsszenarien als Proof of Concept erprobt werden können. Dieser Prototyp erhielt den Namen „Advanced Information Management Prototype“ (AIM-P) und seine Anfragesprache das Akronym bzw. den Namen HDBL („Heidelberg Database Language“). Seine Architektur mit den wichtigsten Komponenten ist in der folgenden Abbildung dargestellt. ohne|mini|500x500px|Architektur des AIM-P-Datenbankservers Der Catalog Manager ist – wie bei den relationalen Datenbanksystemen auch – dafür zuständig, die in der Datenbank als reine Bytestrings variabler Länge gespeicherten Datensätze inhaltlich interpretieren zu können. Während es im 1NF-Fall in vielen Fällen genügt, für jede Relation zur Beschreibung der Struktur ihrer Tupel lediglich eine Liste der Attributtypen und ggf. deren Länge in Bytes zu speichern, kommen im eNF2-Fall noch zusätzliche „Struktur-Datensätze“ wie im Abschnitt Speicherstrukturen für das NF2-/eNF2-Relationenmodell beschrieben hinzu, deren inhaltliche Struktur ebenfalls im Datenbank-Katalog gespeichert werden muss. Dem Query Processor liefert der Catalog Manager eine logische Sicht auf das eNF2-Datenmodell, das in etwa der bildlichen Darstellung als geschachtelte Tabellen (wie z. B. in Abbildung Roboter-Tabelle als NF2-Relation illustriert) entspricht. Dem Complex Object Manager sowie dem Subtuple Manager werden hingegen die zugehörigen (internen) Struktur-Informationen zu allen Datensätzen geliefert, auf die sie zugreifen müssen.
Der Query Processor nimmt die in HDBL formulierten Anfrage- und Änderungsoperationen entgegen und transformiert diese in einen Operatorbaum in dem, ggf. (auch tief) geschachelt, die mit Aufrufparametern versehenen Operatoren der HDBL-Algebra für Selektion, Projektion usw. eingebettet sind. (Wenn nur 1NF-Relationen involviert sind, sieht dieser Operatorbaum sehr ähnlich aus wie der vom Anfrageoptimierer eines relationalen DBMS erzeugte.) Diesen Operatorbaum reicht der Query Processor an den Complex Object Manager weiter.
Der Complex Object Manager setzt die Operationen der HDBL-Relationenalgebra in Zugriffsoperationen auf die physischen Speicherstrukturen um, erzeugt das Resultat-Objekt und legt dieses in einem temporären Datenbanksegment als Übergabebereich für das Online-Interface oder die Anwendungsprogramm-Schnittstelle (API) ab. Mittels seiner Subkomponente Result Walk können diese auf das Resultat-Objekt in der gewünschten Form (attribut-weise, tupel-weise oder „en bloc“ (objekt-weise)) zugreifen.
Der Subtuple Manager ist für alle Arten von Zugriffen (lesend, schreibend, ändernd, löschend) für alle Arten von Datensätzen (aktuell oder historisch (siehe Abschnitt Unterstützung temporaler Daten)) zuständig. Außerdem obliegt ihm auch das transaktionsorientierte Logging und Recovery sowie das Setzen und Freigeben von Sperren, wie im Abschnitt System-interne Aspekte beschrieben.
Der Buffer Manager verwaltet einen zentralen Übergabebereich im Hauptspeicher, Systempuffer genannt, in dem die vom Subtuple Manager zum Lesen und Schreiben angeforderten aktuellen oder „historischen“ Datensätze abgelegt werden. Beim lesenden Zugriff reicht der Subtuple Manager i. W. anschließend einfach die Adresse des Datensatzes im Systempuffer via Complex Object Manager an den Query Processor oder die Anwendung weiter. Beim schreibenden Zugriff führt der Subtuple Manager die angeforderten Änderungen im Datensatz im Systempuffer selbst durch und kümmert sich auch um die Sicherung dieser Änderungen auf dem Hintergrundspeicher. Weitere Details dazu werden in den Abschnitten Transaction-Oriented Workspace (TWS) und Unterstützung temporaler Daten beschrieben.
Der Segment Manager interagiert mit dem Dateisystem des Betriebssystems, um Dateien für das Datenbanksystem anzulegen (zu „allokieren“) oder diese wieder freizugeben. In den meisten Fällen wird ein Segment auf Basis einer einzelnen Datei realisiert. Bei Bedarf können diese Segmente aber auch aus mehreren Dateien zusammengesetzt werden, die „nach oben“ wie ein einziger großer Speicherbereich in Erscheinung treten.
Konventionelle relationale DBMS und das „Complex Object“-Problem Für die „vor-relationalen“ DBMS, die auf dem hierarchischen Datenbankmodell oder dem Netzwerk-Datenbankmodell basieren ist typisch, dass man sich das gewünschte Anfrageergebnis in der Regel mit Folgen von einzelnen Datenbankanfragen quasi stückweise zusammensuchen muss. Im Gegensatz dazu ermöglichen relationale DBMS, solche DatenbankAnfragen mit einem einzigen Anfrageausdruck zu erledigen. Ermöglicht wird dies durch die diesem Datenmodell zugrundeliegende Relationenalgebra bzw. die darauf aufbauende Anfragesprache SQL. Die Relationenalgebra setzt voraus, dass alle Daten als 1NF-Relationen gespeichert werden.
Bei relativ einfach strukturierten Daten, wie sie z. B. im kaufmännischen Bereich vorkommen, funktionieren deren Abbildung auf 1NF-Relationen sowie Datenbank-Anfragen gegen diese in der Regel recht gut. Ganz anders sieht es hingegen bei großen und komplex-strukturierten Datenobjekten aus, wie sie z. B. bei CAD-Konstruktionsdaten von Motoren, Turbinen, PKW, Flugzeugen und Gebäuden auftreten. Als stark vereinfachtes Beispiel dient im Folgenden die Speicherung der Daten von Robotern, wie in der folgenden Abbildung illustriert (hierbei wird angedeutet, dass den Gelenken sog. DH-Matrizen zugeordnet sind, die zu Berechnungen im Zusammenhang mit Bewegungen der Roboterarme benötigt werden). ohne|mini|500x500px|Modellierung eines Roboters (vereinfacht)Für die Abbildung all dieser Daten eines realen Roboters zu dessen Auswahl, CAD-Modellierung, Programmierung und Bewegungsanalysen muss man in einem (relationalen) Datenbanksystem sehr viele Kenngrößen erfassen und speichern. Nachfolgend ein stark vereinfachtes Beispiel, das sich exemplarisch auf die Angaben von minimalen und maximalen Gelenkwinkeln (JA_min, JA_max), Masse (Mass), Beschleunigung (Accel) sowie die bereits erwähnten DH-Matrizen als 4x4-Matrizen (Matrices) beschränkt. Die resultierenden 1NF-Relationen könnten dann z. B. wie nachfolgend dargestellt aussehen:ohne|mini|700x700px|Speicherung der Roboter-Daten als 1NF-Relationen