Es gibt für sog. Objektorientierte Datenbanken (OODB) zur Zeit noch keinen Standard wie für Relationale Datenbanken.

Eine 1993 gegründete und von Rick Cattell geleitete Object Data Management Group (ODMG) hat aber einen Industriestandard ausgearbeitet, an dem sich Datenbanken ausrichten sollen, die sich "objektorientiert" nennen.

Dieser Standard, dessen Version 3.0 (Januar 2000) auf dem Weg zu einer offiziellen Norm ist, fußt auf dem "Objektmodell". Dieses definiert die grundlegenden Konstrukte, mit denen objektorientierte Datenbanken operieren sollten.
Im Folgenden werden die fünf Postulate des Objektmodells vorgestellt und jeweils erläutert, wodurch und in welcher konkreten Weise allegro diese abstrakten Postulate erfüllt.
 

1. Die elementaren Bausteine des Objektmodells sind das Objekt und das Literal. Jedes Objekt hat einen eindeutigen Identifizierer. Ein Literal hat keinen Identifizierer.

Die Objekte in einer allegro-Datenbank sind die Datensätze. Sie bestehen aus Datenfeldern. Jedes Feld kann in sich strukturiert sein, normalerweise durch festgelegte Interpunktion oder Teilfeldcodes. Datenfelder (Attribute) in relationalen Datenbanken sind dagegen "atomar", d.h. eine weitere Strukturierung des Feldes wird vom RDBMS nicht unterstützt. Genau das ist bei objektorientierten Datenbanken und bei allegro anders: Literale können komplex strukturierte Bytefolgen sein, keineswegs nur Zahlen oder schlichte Zeichenketten, und das Objekt kann mit Methoden ausgestattet sein, um mit dieser Struktur umzugehen. Dies kann (muss aber nicht) bis hin zu Multimedia-Files als Bestandteil von Objekten gehen, denn letztlich sind auch solche immer strukturierte Bytefolgen. Soweit geht das bei allegro nicht, doch der Aufruf von geeigneten externen Programmen aus dem System heraus macht den Zugriff auch auf solche Dinge möglich.
Als Identifizierer sind in allegro beliebige Zeichenketten möglich. Sie können vom Nutzer eingebracht werden, das Datenbanksystem kann aber auch eigene Identifizierer von gewünschter Struktur zuteilen.
Besonderheiten: Wird auf einen allegro-Datensatz nicht durch eine Verknüpfung Bezug genommen, braucht er keinen Identifizierer. Wenn nötig, kann ein Satz aber auch mehr als einen (jeweils eindeutigen) Identifizierer haben.
 
 


2. Objekte und Literale lassen sich in Typen einteilen. Alle Elemente eines gegebenen Typs haben einen gemeinsamen Bereich von möglichen Zuständen (d.h. dieselbe Menge von möglichen Eigenschaften) und ein gemeinsames Verhalten (d.h. dieselben möglichen Operationen). Ein konkretes Objekt wird manchmal als Instanz seines Typs bezeichnet.

Der Typ eines allegro-Datensatzes kann durch die Konfiguration (Felddefinition) und die Parametrierung (das Verhalten z.B. bei Export und Indexierung) in jeder gewünschten Weise charakterisiert werden. Das Verhalten eines Objekts (Datensatzes) muss man betrachten
• Aus der Sicht der Datenbank und des Programmierers: das Speichern, Aktualisieren und Löschen von Sätzen sind Vorgänge, die als "Methoden" (Funktionen) im Objekt "Datenbank" eingekapselt sind
• Aus Nutzersicht: die Exportsprache, eine mächtige Datenmanipulationsprache, gestattet eine Ausgabe von Datensätzen in jeder für Anwendungen benötigten Form. Die Manipulation wird ausgeführt mittels einer Export-Parameterdatei: diese bildet zur Laufzeit ein Objekt, dem ein Datensatz nur übergeben werden muss.
Die Exportsprache ist universell: damit werden alle Manipulationen durchgeführt, die auf Datensatzobjekte anzuwenden sind, von der Bildschirmpräsentation des Einzelsatzes und der Ergebnismenge bis hin zur Bildung der Registereinträge im Index der Datenbank. Die Windows-Programme verfügen mit der FLEX-Sprache noch zusätzlich &uumk;ber eine Ausgabemethodik, die ohne Parametrierung auskommt.
 
 
3. Der Zustand eines Objekts ist dadurch definiert, welche Werte es für eine Anzahl von Eigenschaften besitzt. Diese Eigenschaften können Attribute des Objekts selbst sein oder aber Verknüpfungen (relationships) zu einem oder mehreren anderen Objekten.

Die Werte der Eigenschaften eines Objekts können sich normalerweise jederzeit ändern.

Die "Änderung der Eigenschaften" erfolgt durch manuelle Bearbeitung (Nutzerschnittstellen in DOS oder Windows) oder per Programm: Datensätze können von außen mit der FLEX-Methodik, über den avanti-Server oder durch Batchprozesse (Programm UPDATE) aktualisiert werden.
Verknüpfungen kennt allegro in zwei Ausprägungen:
 

• Über einen Identifizierer eines Hauptsatzes können beliebig viele Untersätze mit diesem verknüpft sein. Typischerweise wird diese Technik bei mehrteiligen Veröffentlichungen angewendet.

 
• Der Identifizierer eines "Stammsatzes" kann in beliebig vielen Datensätzen auftreten und dann bei Anzeige, Export oder Indexierung automatisch den Ersatz des Identifizierers durch einen Klartext bewirken. Diese Methode ist typisch für die Verknüpfung von Schlagwort- und Namensstammsätzen mit Titeldatensätzen.

 
 
4. Das Verhalten eines Objekts wird definiert durch die Menge der Operationen, die mit dem oder durch das Objekt ausgeführt werden können. Operationen können eine Liste von Eingabe- und Ausgabewerten haben, jeder von einem festgelegten Typ. Jede Operation kann auch einen Wert von bestimmtem Typ zurückgeben.

Die Exportsprache, siehe Punkt 2, ermöglicht es, Operationen beliebiger Art anwendungsspezifisch einzurichten. In den Windows-Programmen a99 / alcarta kommt hinzu, dass man mit der Makro-Sprache FLEX auf höherer Ebene Aktionen programmieren kann, die zwar auf den Methoden der C++-Klassen aufsetzen, deren genaue Kenntnis aber nicht voraussetzen.

Parameterdateien werden jedoch nicht mit dem Satztyp (der abstrakten Klasse) zusammen gespeichert, sondern bilden eine Klasse für sich, also zur Laufzeit eigene Objekte. Potentiell gibt es sehr viele wünschenswerte "Verhaltensweisen" von Datensätzen, gerade bei bibliothekarischen Daten! Deshalb ist es viel effizienter und wartungsfreundlicher, wenn man die Klasse "Datensatz" davon entlastet, auch noch alle jemals benötigten Unterprogramme für ihr Verhalten in sich aufnehmen zu müssen.
 
 

5. Eine Datenbank speichert Objekte und macht sie für mehrere Nutzer und für Anwendungen zugänglich.
Eine Datenbank beruht auf einem Schema, definiert in der "Object Definition Language" (ODL) und enthält Instanzen der Typen, die das Schema definiert.

allegro ist ein mehrplatzfähiges Datenbanksystem (eine "Einplatzversion" gibt es gar nicht, dennoch kann es problemlos auf einem Einzel-PC ohne Netz betrieben werden). Eine Datenbank kann zu gleicher Zeit sowohl von monolithischen Programmen lokal benutzt werden wie auch in Client/Server-Methodik über Inter- und Intranet.

Das Schema einer allegro-Datenbank ist in einer "Konfigurationsdatei" niedergelegt. Diese bildet zur Laufzeit ein eigenes Objekt im Programmsystem, das z.B. dazu dient, ein neu eingegebenes oder eingelesenes Datenfeld strukturell zu überprüfen, vor allem hinsichtlich der Wiederholbarkeit des Feldes, der erlaubten Teilfelder oder einiger anderer Eigenschaften. Es sorgt daneben auch für die Generierung von Zeitstempeln und neuen IdentNummern.

Anders als die anderen, abstrakten Postulate nimmt Nummer 5 Bezug auf eine konkrete Sprachdefinition, die ODL. Diese ist jedoch hersteller- und programmiersprachenunabhängig. Eine allegro-Konfiguration könnte in ODL formuliert werden. Nicht alle Konstrukte der ODL haben in allegro eine Entsprechung (d.h. nicht jede ODL-Deklaration könnte in einer allegro-Konfiguration abgebildet werden), andererseits gehen die Möglichkeiten aber hier und da über die der ODL hinaus: z.B. kann in ODL ein Attribut, das als Relation deklariert ist, nicht wahlweise im Datensatz auch mit einer normalen Zeichenkette belegt sein, es muss immer mit einem Identifizierer des der Relation entsprechenden Typs belegt sein. In allegro ist das anders. Deshalb sind nicht alle Eigenschaften, die ein Attribut haben kann, in der Konfiguration fest eingestellt, sondern können in der Parametrierung für den Index, die Anzeige und die Exporte realisiert werden
.

"Objektorientiert" wird hier als allgemeiner Oberbegriff verstanden; es bedeutet im Sinne einer "reinen Lehre" nicht automatisch ODL+OQL, so wenig wie "relational" automatisch SQL bedeutet oder "Betriebssystem" automatisch "Windows" heißt oder "UNIX". "Objektorientiert" bedeutet auch nicht, dass wirklich Objekte jeder erdenklichen Art innerhalb der Datenbank speicherbar sein müssen. allegro-Datensätze haben eigentlich keine sehr ausgefallenen Eigenschaften, als Objekte betrachtet. Aus der Sicht der relationalen Therie handelt es sich um "semistrukturierte Daten", wofür typisch ist, dass das Schema viele Elemente enthält, die häufig im Datensatz unbesetzt sind oder mehrfach auftreten können. Beides ist in der relationalen Welt problematisch, in der objektorientierten nicht.
Die höheren Sprachkonstrukte, die im avanti-Server bzw. in den Windows-Programmen (FLEX-Makros) implementiert sind, sollten jedoch, wie auch immer man die Sache theoretisch betrachtet, für konkrete Aufgaben eine Kommunikation zwischen allegro und OODB (wie auch RDBMS) ermöglichen.

Zur Marktsituation
Objektorientierte Datenbanksysteme haben derzeit einen sehr kleinen, ja sogar in relativen Zahlen sinkenden Marktanteil [3]. Die Dominanz der relationalen Systeme ist wohl unangreifbar. Wichtige Probleme sind die geringere Belastbarkeit (RDBMS "skalieren" besser) und vor allem das Fehlen einer genormten Sprache, die zumindest das allgegenwärtige SQL umfassen oder emulieren müsste.

Anmerkungen zur "objektorientierten Programmierung"

Die neueren allegro-Programme (der avanti-Server und die Windows-Programme) sind in der objektorientierten Sprache C++ geschrieben. Das allein bedeutet noch nicht, dass allegro deswegen ein OODB wäre, es erleichtert jedoch die Verwirklichung dieser Eigenschaft. Zunächst bedeutet es nur, dass die Grundlage der Programme eine "Klassenbibliothek" ist. Eine "Klasse" ist eine genaue Definition einer Datenstruktur einschließlich einer Sammlung von Funktionen (eine Art Unterprogramme, auch "Methoden" genannt), die mit dieser Struktur ausgeführt werden können.
Es gibt fünf wesentliche Klassen: Konfiguration, Datensatz, Export, Index und Datenbank. Damit kann man in Programmen umgehen, wobei dann der Programmierer nichts Genaues über die interne Funktionsweise der Datenbank wissen muss. Wenn im Programm mit einem Objekt der Klasse "Datensatz" gearbeitet wird, kann man diesem Objekt Befehle erteilen, z.B. ein neues Datenfeld in sich aufzunehmen oder ein vorhandenes herauszugeben oder zu löschen. Das Objekt "Datensatz" kann seinerseits einem Objekt "Export" übergeben werden, wodurch es dann mittels der dazu gehörigen Parameter umgeformt und in eine Datei oder einen Speicherbereich ausgegeben wird. Ein neues oder verändertes Objekt "Datensatz" kann ferner einem Objekt "Datenbank" übergeben werden, um es abspeichern zu lassen oder um einen vorhandenen Datensatz dadurch ersetzen zu lassen. Das Objekt "Datenbank" führt dann alle Operationen aus, die zum Speichern und insbesondere zum Indexieren gehören. Um alles das braucht sich der Programmierer daher nicht zu kümmern, sondern er kann sich z.B. auf eine funktionale Oberflächengestaltung konzentrieren. Client-Programme können folglich geschrieben werden, ohne Kenntnisse über die interne Arbeitsweise der Datenbank zu besitzen.
Weiter erleichtert wird das Entwickeln von Client-Software durch den avanti-Server, ein seinerseits auf der Basis der Klassenbibliothek geschriebenes Programm. Er kann über TCP/IP, also über Inter- und Intranet, kommunizieren und damit z.B. von außen auch aus Perl- oder Python-Programmen heraus angesprochen werden, nicht nur mit C++. Davon machen viele WWW-Anbindungen Gebrauch.

Zum Schluss ein Hinweis
Wer sich produktneutral über das Thema "Datenbankarchitektur aus bibliothekarischer Sicht" informieren möchte, kann auf einen Text mit dem Untertitel "Quergedanken über Datenbanken" zurückgreifen.

Literatur:

[1] Harrington, Jan L.: Object-oriented database design clearly explained. - Academic Pr., 2000. - 312 S. - ISBN 0-12-326428-6

[2] The Object Data Standard: ODMG 3.0 / ed. by R.G.G. Cattell and Douglas K. Barry. - Morgan Kaufman 2000. - 280 S. - ISBN 1-558-60647-5

[3] Leavitt, Neal:  Whatever Happened to Object-Oriented Databases? - IEEE Computer, August 2000, p. 16–19.