UB BRAUNSCHWEIG
Symbolfoto
  • Impressum
  • Startseite
  • allegro-C von A-Z
  • Druckversion


allegro-C - Bemerkungen zur Architektur



Das bibliothekarische Datenbanksystem allegro-C hat zwar eine lange Geschichte - die Entwicklung begann im Jahre 1980 - aber seine innere Struktur, seine Architektur, ist ab 1995 auf eine neue Basis gestellt worden: eine sog. Klassenbibliothek, geschrieben in C++ und plattformunabhängig.

Diese Klassenbibliothek ist eine Sammlung von Datenstrukturen und zugehörigen Funktionen. Aus diesen Bausteinen sind alle Programme zusammengesetzt, die heute von den Anwendern eingesetzt werden, bis hin zum Datenbankserver avanti für die Web-Anbindung. Die Klassenbibliothek bildet in der Summe nichts anderes als eine "database engine" und hat keine eigenen Oberflächenelemente.

Die Sprache C++ wurde wegen der Effizienz der kompilierten Programme gewählt. Das Datenbanksystem "skaliert" bis hinauf zu 'zig Millionen Datensätzen mit hunderten Millionen Registereinträgen (s. VK-Datenbank), ohne daß es dann merklich langsamer würde beim Zugriff auf Register und Datensätze. Zwar ist die Grundstruktur der Basisklassen schon einige Jahre alt, aber sie wurden gerade hinsichtlich Effizienz immer wieder verbessert und funktional auch erweitert, so daß erst jetzt, Ende 2009, eine wirklich abgerundete Struktur vorliegt, die der Anwenderversion V30 zugrundeliegt. Die internen Änderungen haben gleichwohl nie erfordert, daß Anwender etwas an ihren Datenstrukturen, Konfigurierungen, Parametern oder Skripten zu ändern hatten, d.h. es wurde stets die Abwärtskompatibilität weitestgehend gewahrt. Auch die ältesten Datenbanken können daher ohne Umstände sofort mit der aktuellsten Version benutzt werden und von den neuesten Funktionen profitieren.

Die Klassenbibliothek, erstmals beschrieben 1995, besteht aus nur fünf Basisklassen, von denen jede aber eine Anzahl von sehr mächtigen Funktionen (Methoden) besitzt:

KONFIG : Konfiguration. Damit ist die interne Datenstruktur gemeint, d.h. welche Datenfelder es gibt und welche Eigenschaften sie haben sollen. Alle anderen Klassen brauchen eine Konfiguration als Grundlage.

RECORD : Datensatz. Ein Datensatz besteht aus Feldern, die der Konfiguration entsprechen. Felder können mehrfach besetzt sein, leere Felder brauchen keinen Platz, es gibt hierarchische Satzstrukturen. Für den Umgang mit alledem stellt diese Klasse die nötigen Methoden bereit, d.h. der Programmierer kann Datenfelder aus dem Objekt abfragen, ändern, neue einfügen oder z.B. auch eine Volltextsuche darin durchführen.

EXET : Exportparameter. Mit einer eigenen Sprache, der Exportsprache, kann man bis in die kleinsten Einzelheiten, z.B. die Ersetzung einzelner Zeichen durch andere, alles festlegen und jederzeit modifizieren. Alle Outputs und auch die Indexeinträge werden mit dieser Datenmanipulationssprache gebildet.

INDEX : Index. Er umfaßt die alphanumerischen Register der Datenbank und stellt die Funktionen für das Suchen (das Erstellen und Ordnen von Ergebnismengen und das Blättern in den Registern) bereit.

ABASE : Datenbank. Ihre wichtigsten Funktionen sind das Bereitstellen von RECORD-Objekten, mit denen der Programmierer dann arbeiten kann, sowie natürlich das Abspeichern solcher Objekte, wobei das INDEX-Objekt alle nötigen Änderungen in den Registern vornimmt.

Zum Teil bauen sie aufeinander auf: die "Datenbank" braucht z.B. eine Konfiguration und einen Index, und der Index braucht eine Export-Parameterstruktur.

Wer eigene Programme schreiben will, die auf dieser Grundlage aufbauen, hat zwei Möglichkeiten:

Ebene C++ : Hier kann man die Klassen und Methoden unmittelbar nutzen, muß aber eben in C++ programmieren.
Auf diese Weise sind die Programme a99, alcarta und avanti entwickelt.
Eine Notwendigkeit zu dieser Art der Programmierung ergibt sich höchst selten, weil die zweite, später entstandene Möglichkeit sehr mächtig ist:

Ebene FLEX : Sehr viele Anwender bedienen sich dieser höheren Skriptsprache, um Funktionen oder ganze Anwendungen zu gestalten. Auch die kompletten Subsysteme "Ausleihe", "Erwerbung" und "Zeitschriftenverwaltung" sind ausschließlich in dieser Sprache geschrieben und damit völlig "quelloffen". Nur selten noch braucht jemand sich mit der tiefer liegenden, als kryptisch empfundenen Exportsprache zu befassen, weil FLEX auch selber sehr vielseitige Ausgabefunktionen hat.
Der "Interpreter" für die Skriptsprache FLEX ist eingebaut in die Programme a99, alcarta und acon (für avanti).
FLEX kommt daher auch an der Webschnittstelle zum Einsatz: FLEX-Makros werden aus PHP oder Perl o.a. heraus dem avanti-Server übergeben, der sie ausführt und die Ergebnise zurückliefert. Dabei kann auch Ajax-Technik sehr komfortabel genutzt werden. Dies ist exemplarisch geschehen mit a30, einem RIA-Programm auf der Basis von Adobe Flex/Flash. Die Quelltexte für a30 sind frei verfügbar und können auch als umfangreiche Dokumentation für den Umgang mit FLEX für Web-Anwendungen dienen.
Denkbar bleibt gleichwohl, daß ein Programmierer ein ganz eigenes Funktionspaket direkt auf der Grundlage der Klassenbibliothek entwickelt und in ein eigenes, höheres Programm einbaut.

Bisher nur intern wurde und wird diskutiert, die Klassenbibliothek auch unter eine Open-Source-Lizenz  zu stellen. Der Bedarf dafür scheint zwar gering - schließlich ist C++ keine leichte Sache - aber zunehmend wird doch alle Software, die quasi als "black box" daherkommt, weniger gern angenommen. Das Ausmaß an Offenheit, das mit der FLEX-Ebene schon erreicht ist, läßt allerdings kaum Wünsche offen. Man könnte es auch so betrachten, daß letztlich auch solche Programmsysteme, die auf der Grundlage von Perl, PHP oder Python vorliegen, nicht völlig offen sind - sie benötigen ja den jeweiligen Interpreter, damit man damit arbeiten kann. (Mag sein, daß auch dessen Quellcode offenliegt, doch wer wird sich daran versuchen?) a99/alcarta und avanti sind eben solche Interpreter, und FLEX entspricht einer Sprache wie Perl etc., nur eben dediziert für die Arbeit mit einer allegro-Datenbank.

Man sollte vielleicht drei Aspekte der Offenheit unterscheiden:
  • Struktural: Die wichtigste Offenheit für den Anwender ist die Offenheit der eigenen Daten. Deren Struktur ist voll dokumentiert, seit langem stabil und mit der Exportsprache oder auch Perl u. dgl. jeder gewünschten Umformatierung zugänglich, wenn etwa migriert werden soll.
    Offen ist die Datenstruktur aber auch für eigene Erweiterungen: bis hin zur völligen Neugestaltung kann man sein Datenformat individuell konfigurieren. Für viele Sonderprojekte wurde davon ausgiebig Gebrauch gemacht, während "Normalanwender" sich mit etablierten und bewährten Standardformaten begnügen.

  • Prozedural: Dies betrifft das Verhalten der Software. Die Vorgänge für den Umgang mit den Daten müssen offen sein im Sinne von modifizierbar und erweiterbar. Dazu dient FLEX. dazu dienten vorher schon die Parameter, mit denen man Die Zugriffsregister und die Datenanzeige sowie Exporte aller Art gestalten kann.

  • Fundamental: Grundlage des Ganzen sollte ein Kernsystem sein, dessen Quellen (= Programmtexte) nicht irgendwo unter Verschluß sind, sondern offen verfügbar, frei verwendbar und vollständig dokumentiert. Der Normalanwender sollte nicht in die Situation kommen, sich mit diesen Grundlagen befassen zu müssen, aber es gibt ihm Sicherheit, daß dies prinzipiell möglich ist, bedeutet es doch, daß keine Abhängigkeit von ganz bestimmten Firmen oder Personen besteht. Diese Offenheit der Quellprogramme des Kernsystems wird für allegro erstmals zu Beginn 2010 Realität, wenn die in C++ geschriebenen Programme der Klassenbibliothek freigegeben werden. Zur Vorbereitung dieser Freigabe sind die Quelltexte gründlich revidiert und die Kommentierung überarbeitet worden.
Ab Nov. 2009 gibt es ein auf Adobe Flex/Flash basierendes Programm namens a30. Sein Quellode ist freigegeben und gestattet den Ausbau zu individuellen Rich Internet Applications (RIA) auf der Grundlage von allegro-Datenbanken. a30 ist offen in jedem der drei Aspekte. Es erfordert nur avanti-FLEX als Skriptsprache, weder Perl o.a., JavaScript, noch komplexes HTML mit CSS auf Systemseite, und nur Standard-Exportparameter auf Anwendungsseite.

Hinweis für Einsteiger: Es gibt eine Demo-Version mit Vollfunktion. Zur Installation und für die ersten Schritte eine Schnellstart-Anleitung.


[i] zuletzt aktualisiert: 08.04.2011
Email: ub@tu-bs.de