allegro und Relationale Datenbanken (RDBMS) - Vergleichende Gegenüberstellung


Regelmäßig werden Fragen gestellt wie "Was für ein Standard-Datenbanksystem steckt in allegro?" oder "Kann man eine allegro-Datenbank mit SQL abfragen?"
Man erlebt in solchen Unterhaltungen leicht, wie der eine sehr viel von relationalen Datenbanken versteht, von
allegro aber ganz wenig, bzw. umgekehrt. Dann wird es mühsam und Fehleinschätzungen  sind auf beiden Seiten vorprogrammiert. Um diesem Übelstand abzuhelfen und das gegenseitige Verstehen zu fördern, ist hier der Versuch gemacht, vergleichende Aussagen zu den Konzepten und Eigenschaften der beiden Datenbankwelten zu machen, und zwar mit möglichst wenig Fachjargon und mit Blick mehr auf die Praxis als auf die Theorie. Diese "Welten" sind von höchst unterschiedlicher Größe und Bedeutung, das ist klar, doch darum geht es hier nicht, schon gar nicht um die immer nur für konkrete Anwendungen, aber nicht allgemein entscheidbare Frage "Was ist besser?" Wer aber wegen eines konkreten Projekts vor eben dieser Frage steht, soll hier Hilfen zur Einschätzung erhalten. Zudem werden de facto immer wieder relationale Daten nach allegro überführt bzw. soll Datenaustausch in umgekehrter Richtung stattfinden, und auch dabei können ein paar übergreifende Kenntnisse nützen.

Ab Version 25 gibt es vom System her eine Unterstützung für den Austausch zwischen den Welten: aresqa.
Sicher kann man noch viel mehr sagen, vermutlich müssen einige der Aussagen weiter präzisiert oder modifiziert werden. Jeder Leser ist eingeladen, konstruktive Kritik zu üben, damit wir diese Übersicht weiter verbessern können.

Für den vorliegenden Text ist Dank zu sagen an Thomas Berger (Bonn), Mathias Manecke (DB Leipzig) und Dr. Annemarie Tews (UB Leipzig) für Beiträge und Diskussionen.

Relationale Datenbank-Management-Systeme (RDBMS) und allegro, das sind recht unterschiedliche Gebilde, die man im Grunde nicht leicht vergleichen kann. Vor allem waren die Entwicklungsziele nicht dieselben. RDBMS wurden primär (doch nicht ausschließlich) entwickelt mit Blick auf solche Anwendungen, die Berechnungen und Auswertungen erfordern, also im weitesten Sinne Faktensammlungen sowie Geschäfts- und Verwaltungsanwendungen. allegro dagegen zielte von vornherein (aber auch nicht ausschließlich) auf strukturierte Textdaten; dazu gehören als Spezialfall bibliothekarische Katalogdaten. (Als eine dritte Kategorie könnte man vielleicht die Internet-Suchmaschinen betrachten wollen, die aber nur für das Retrieval in unstrukturierten Texten geschaffen wurden, nicht für die Verwaltung dieser Texte. Daher kann man sie kaum als Datenbanksysteme bezeichnen, und nur um solche geht es hier.)


Die nachfolgende Übersicht versucht, für Vertreter beider Umgebungen verständlich zu sein, stellt hauptsächlich strukturelle Aspekte gegenüber und beschränkt sich auch in dieser Hinsicht auf wenige, für Bibliothekszwecke wichtige Punkte. Für eine Einschätzung in konkreten Zusammenhängen wird man meistens noch weitere Kriterien berücksichtigen müssen, bis hin zu den Kosten, die hier außen vor bleiben. (Bibliotheken sind auf's Ganze gesehen, und kommerziell betrachtet, nur eine Nische, das darf man nicht verkennen.)

Vor Jahren hat einmal die DFG in ihren Förderrichtlinien empfohlen, Standard-Datenbanksysteme statt proprietärer (firmeneigener) Lösungen zu bevorzugen. De facto hieß das, man solle ein RDBMS einsetzen, denn andere umfangreichere und durchgesetzte Standards gab es und gibt es noch immer nicht, etwa für sog. "objektorienterte" Datenbanken. Die DFG-Empfehlung entsprang nicht einer Erkenntnis, solche Datenbanken seien die bestgeeigneten für bibliothekarische Zwecke - und bis heute hat sich das weder theoretisch noch praktisch erwiesen. Hinter der Empfehlung stand vielmehr die Hoffnung, dadurch zu herstellerunabhängigen Anwendungen kommen zu können. Idealerweise, so die Vorstellung, sollte man die Hardware und das Datenbanksystem wechseln können, ohne viel Aufwand in die Anpassung der Anwendungssoftware stecken zu müssen. Diese Hoffnung hat sich noch nirgends überzeugend erfüllt, die Abhängigkeit der Anwendungssoftware von den spezifischen Besonderheiten einer Datenbankgrundlage ist denn doch immer recht groß: insbes. hat jedes SQL seine Eigenheiten. Ist der Standard also nur vermeintlich ein solcher, oder ein zu schwacher?

Das Entity-Relationship-Modell, die Grundlage der RDBMS-Theorie und -Praxis, ist ein mathematisch fundiertes Konstrukt. Es sachgerecht anzuwenden ist eine anspruchsvolle Aufgabe. Dazu gehört die Erstellung einer sog. "normalisierten" Tabellenstruktur. Wenn RDBMS häufig eingesetzt werden, ohne auf ein schlüssiges, gründlich durchdachtes, theoretisch sauberes ER-Modell aufzusetzen, dann ist das nicht dem relationalen Konzept, sondern den Entwicklern anzulasten. Zu fragen bliebe also, ob sich bibliothekarische Sachverhalte in einem ER-Modell wirklich elegant und effizient abbilden lassen. Diese sehr komplexe Aufgabe ist wohl noch immer nicht umfassend und allgemeingültig gelöst. Noch jeder, der es versuchte, konnte erleben, wie auf diesem Gebiet viel mehr Teufel in viel mehr Details stecken als man gedacht hätte und infolgedessen viel mehr Zeit zur Umsetzung gebraucht wird als man angesetzt hatte, unerwartet viele Tabellen nötig sind und die Anwendungsprogramme deshalb unerwartet groß und kompliziert werden. Es kommt erschwerend hinzu: ein theoretisch stimmiges Modell allein reicht nicht aus. Zwar wird oft ein Modell mit einigen hundert oder ein paar tausend Datensätzen gut funktionieren, dann aber bei weiterem Anwachsen "in die Knie gehen". Es gibt manche Dinge, über die man bei kleineren Datenmengen gar nicht nachzudenken braucht, die mit Millionen Daten aber auch auf stärkster Hardware nicht mehr zufriedenstellend schnell funktionieren (z.B. "views" und vor allem "joins"). Solche Effekte, die dann leicht zu Kompromissen zwingen, sind bei allegro, so darf man aus Erfahrung sagen, weniger gravierend.

Relationale Datenbanken allegro   (Unterstrichen-kursive Wörter verweisen auf das
Glossar der allegro-Begriffe)

Struktur der Daten
Zentrales Konzept der relationalen Welt ist das Entity-Relationship-Modell (ER-Modell). Dessen Grundlage ist es, die in der Datenbank abzubildenden Sachverhalte in Eigenschaftsgruppen (Entitäten) zu gliedern, wobei jede Ausprägung einer jeden Entität mit jeder anderen Ausprägung dieser oder einer anderen Entität in Beziehung stehen kann (d.h. jeder Datensatz mit jedem anderen verknüpft sein kann).  Physisch ist dieses Modell in RDBMS in Tabellenform realisiert. Jede Tabelle repräsentiert eine Entität, jede Zeile (auch "Tupel" genannt) eine Ausprägung der Entität, jede Spalte ("column") eine Eigenschaft ("attribute"). 
Wichtigste Aufgabe bei der Entwicklung einer relationalen Datenbank- Applikation ist also die Umsetzung des abzubildenden Sachverhaltes in ein ER-Modell (Normalisierung nach Codd), um aus diesem die Tabellenstruktur (Codd sagte "relation" statt "table") zu entwickeln. (Ist das nicht sinnvoll möglich, so ist das RDBMS von vornherein nicht das geeignete Werkzeug!) 
Logisch gesehen entspricht einer Entität in allegro einem Satztyp. Die Tabelle als Konzept gibt es nicht. In einer Datenbank-Datei können Sätze aller Typen zugleich ohne strukturelle Zuordnung vorkommen. Ein Datensatz ist ein zusammenhängender, durch Steuerzeichen strukturierter Text. Wodurch der Satztyp bestimmt wird und welche Funktionen und Zusammenhänge er hat, ist Sache der Parametrierung, nicht der Dateistruktur.
Relationen können im Prinzip genau so wie bei einem RDBMS durch Bezugnahme auf den Primärschlüssel eines anderen Datensatzes gebildet werden.
Eine automatische Integritätsüberwachung für die Datensätze gibt es nicht. Die Primärschlüssel werden durch geeignete Index-Parametrierung gebildet. Über programmierte Validierung lassen sich auch Elemente der Integritätsüberwachung (z.B. Verhinderung von Doppeleinträgen, Löschverweigerung für verknüpfte Sätze) in eine Anwendung einbauen.
Eine Tabelle hat keine bestimmte Ordnung. Selektierte Teilmengen können aber per SQL nach jedem Attribut (Tabellenspalte) sowie nach Kombinationen von Attributen geordnet werden. 
Ein Index dient nicht der geordneten Sicht auf die Daten, sondern der beschleunigten Selektion bei größeren Tabellen. Der Index selbst wird nicht sichtbar. Will man das erreichen, ist dafür eine eigene Tabelle zu machen. 
Neben realen kann es auch virtuelle Tabellen geben, sog. "Views". Die Software zeigt dann genau diejenigen Dinge, die für eine Funktion oder von einem Nutzer gebraucht werden, doch es gibt dafür keine wirkliche Tabelle.
Eine Datenbank-Datei hat keine bestimmte Ordnung. Geordneter Überblick wird durch Indexieren ermöglicht (s.u.), wobei die Register durchgeblättert und zur Bildung von Ergebnismengen benutzt werden können. Ergebnismengen können nach mehreren Kriterien auf- und abwärts sortiert angezeigt werden. Ein eigenes Sortierprogramm kann Ordnungen herstellen (offline, für Reports und Listen), die sich nicht unmittelbar aus Feldinhalten oder aus den Registern ergeben. Die Indexierung ist das zentrale Element zur Präsentation der Daten in geordneter Form. Daneben können Ergebnismengen nach Elementen der Kurzanzeige, aber auch nach jedem Feldinhalt geordnet werden ("View"-Technik).
Jede Zeile einer Tabelle kann man als Datensatz ansehen, jeder Datensatz hat genau soviele Felder ('Attribute') wie die Tabelle Spalten hat, wobei einzelne leer sein können.  Auch ein leeres Feld braucht jedoch Platz. (Wieviel, hängt von der internen Architektur ab. Manche füllen die Spalten mit Leerzeichen auf.) Durch Vermeidung von Redundanz (Normalisierung!) kann man andererseits Platz sparen. Jeder Datensatz enthält nur die jeweils belegten Felder.
Es gibt im Grunde keine leeren, sondern nur abwesende Felder.
Ein solches tritt im Datensatz gar nicht in Erscheinung, belegt also Null Byte. Es gibt Kategoriesysteme mit über 1000 Feldern (z.B. Pica: über 1.400), von denen dann viele nur selten belegt sind, da macht das denn doch etwas aus.
Die Struktur der Datensätze (der Tabellenzeilen) ergibt sich sozusagen aus der Kopfzeile der Tabelle, in der steht, was die einzelnen Spalten bedeuten und was für Eigenschaften sie haben. 
Moderne Systeme speichern die "Kopfzeilen" aber in besonderen Tabellen der Datenbank. 
Im Datenfeld selbst, das ist ein Unterschied zu allegro, steht kein Feldname oder Kategorienummer, sondern allein die Position bestimmt die Bedeutung des Elementes.
Jede Tabellenspalte hat einen Namen (das könnte auch z.B. eine MAB-Kategorienummer sein)und wird in Abfragen und Programmen immer über diesen Namen (zusammen mit dem Namen der Tabelle) angesprochen. 
In SQL dient der Befehl CREATE zur Definition von Tabellen, Views und Indizes. 
Eine Konfigurationsdatei (CFG) legt fest, welche Felder es in einer Datenbank geben darf. Dazu dient die "Kategorieliste", die jedem logischen Datenfeld eine Nummer (engl. tag) zuordnet und seine Eigenschaften definiert. Die Reihenfolge dieser Nummern hat keine funktionale Bedeutung, die Nummern müssen nicht fortlaufend sein und auch nicht rein numerisch. Zu entscheiden ist, ob es 2-, 3- oder 4-stellige tags sein sollen. In den Parameterdateien und in der FLEX- Makrosprache werden diese "tags" (und nicht die Feldnamen) benutzt, um Felder anzusprechen. Es gibt Kategoriesysteme mit über 1500 Kategorien (wobei aber viele Wiederholungsfelder mitgezählt sind). 
Die Konfiguration legt nicht fest, ob und wie die Felder indexiert oder angezeigt werden. Das ist die Aufgabe von Parameterdateien.
Jedes Feld hat einen Typ  (numerisch, Datum, Text, u.a.), Textfelder haben jeweils eine festgelegte maximale Länge. Vorteil: die typspezifischen Eigenschaften können für Selektion und Integritätsüberwachung ausgenutzt werden. (Soundex-Suche bei Text, Größer-, Kleiner-Vergleich bei Datum, not nul und unique bei Primärschlüssel ...) Jedes Feld enthält Text (automatisch bis zu 3000 Zeichen je Feld), jedoch kann jedes Feld auch zum Rechnen verwendet werden. (Neben einer Zahl kann das Feld dann trotzdem noch beliebige andere Angaben enthalten.) Bei der Eingabe können programmierbare Validierungen den Inhalt hinsichtlich gewünschter Eigenschaften abtesten und ggfls. Fehlermeldungen produzieren.
Felder sind nicht wiederholbar - das würde den Grundsätzen der Theorie widersprechen. Sollen z.B. 5 Schlagwörter eingebbar sein, wären dafür 5 separate Tabellenspalten einzurichten. 
Soll ein Feld frei wiederholbar sein (Paralleltitel, Mitarbeiter) so ist der "saubere" Weg, die sog. 1. Normalform, es in eine eigene Tabelle auszulagern. Dies spart Speicherplatz und das Feld ist dann auch wirklich "frei" wiederholbar, nicht nur zwei oder sieben oder fünfzigmal. Falls solche Angaben allerdings eine Reihenfolge haben (1. Verfasser vor 2.), oder qualifiziert sind (Personen als Verfasser, Herausgeber  oder Mitarbeiter) oder beides (Herausgeber vor 1. Mitarbeiter vor 2. Mitarbeiter), müssen in dieser  zusätzlichen Tabelle zusätzliche Spalten zum Erhalt der Reihenfolge und Funktionsbezeichnungen eingefügt werden. Für die Anzeige eines Datensatzes  müssen diese über Tabellen verstreuten Angaben zusammengesetzt und dem Anwender präsentiert werden. Nach einer Veränderung müssen die Angaben wieder auf alle betroffenen Tabellen verteilt werden. Der Datensatz existiert dann nur als logische Einheit, seine Teile sind verstreut. 
Eine halbwegs funktionsreiche bibliothekarische Anwendung kommt schnell auf Dutzende bis Hunderte von verschiedenen Tabellen und Hilfstabellen, für die dann Suchanfragen und Views programmiert werden müssen. Auf die Leistung und die Durchführbarkeit von Änderungen wirkt sich dies nachteilig aus.
Jedes Feld ist beliebig wiederholbar, falls man dies nicht in der CFG ausdrücklich verbietet. 
In den meisten allegro-Anwendungen sind mehrfach auftretende  Angaben in sogenannten Wiederholkategorien abgelegt: Hinter der Kategorienummer wird ein Folgezeichen "hochgezählt": 2,3,4,...,  A,B,C, ..., a,b,c, ... Wenn nötig, kann man auf diese Art auf eine etwa 200fache Wiederholung kommen, die Reihenfolge bleibt dabei erhalten (sie wird durch die Ordnung der Folgezeichen bestimmt). 
Die Funktion z.B. von Personen kann je nach Anwendung auch an Kategorienummern gebunden sein (alle Herausgeber kommen dann vor allen Mitarbeitern), in anderen ist die Funktionsbezeichnung oder ein Kürzel dafür in den Daten selbst enthalten, angehängt oder in einem Teilfeld. Die Reihenfolge ist dann stets die der Eingabe, dafür ist man freier in der Vergabe von Funktionsbezeichnungen. Hat man hier einen undurchdachten Entwurf gemacht, kann das nachträgliche Ändern schwierig werden. 
Ein allegro-Datensatz kann nicht mehr als 500 Indexeinträge erzeugen und darf auch nicht größer als 20.000 Byte sein. Für einen Datensatz 200 Schlagworte und 200 beteiligte Personen (soll schon vorgekommen sein) und diverse Stichworte aus Freitextbeschreibungen und Dutzende von Parallelsignaturen, die alle recherchierbar sein sollen, bringen das System an oder über seine Grenzen.
Soll ein neues Feld eingeführt oder die maximale Länge eines Textfeldes vergrößert werden, hat man u.U. die gesamte Tabelle zu reorganisieren (geht nicht im laufenden Betrieb), bei neueren Systemen nicht unbedingt. 
Die eigentliche Arbeit bei der Einführung neuer Felder ist aber die Festlegung der damit verbundenen Funktionen. Das neue Attribut hat ja einen Zweck; diesen gilt es in veränderte Anzeigemasken, Suchfunktionen,  Ausgaberegeln usw. umzusetzen. Der Aufwand für die Reorganisation der Tabelle ist in Bezug auf den Gesamtaufwand zu vernachlässigen.
Das Einführen eines neuen Feldes geschieht durch eine Eintragung in der Kategorieliste der CFG-Datei. (Das geht jederzeit, auch im laufenden Betrieb.) Von da an kann jeder Datensatz, auch jeder schon vorhandenene, dieses Feld zusätzlich erhalten, ohne dafür eine Datei reorganisieren zu müssen. Um das neue Feld auch indexiert und angezeigt zu bekommen, ist es in die zuständigen Parameterdateien einzubauen. Für die Erfassung ist das neue Feld in ein Formular oder die "Abfrageliste" einzufügen, evtl. ist eine programmierte Validierung zu parametrieren (für die Eingabeüberprüfung).
Felder ('Attribute') dürfen in sich strukturiert sein, jedoch wird so etwas von der Theorie und z.B. von SQL nicht unterstützt (denn Attribute sollen "atomar" sein, unteilbar also). Dafür hätte man eigene Anwendungsprogramme zu schreiben. Z.B. könnte man 5 Schlagwörter auch in eine Tabellenspalte hintereinander schreiben (vorausgesetzt, man hat die maximale Länge hoch genug eingestellt), aber mit SQL kann man dann nicht die Schlagwörter einzeln indexieren. Es können (redundante) zusätzliche Tabellen dafür angelegt werden, um das Suchen zu unterstützen. Felder können in sich beliebig strukturiert sein, normalerweise werden die Teilfelder durch Steuerzeichen wie $a, $b usw. identifiziert (typisch für MARC-Formate), doch es reicht auch eine konsistente Interpunktion. 
Die Parametrierung bietet viele Möglichkeiten für den Umgang mit Teilfeldern und anders strukturierten Feldinhalten, ebenso die Verfahren der Eingabe und Bearbeitung. Attribute sind also keineswegs unteilbar sondern lassen sich in jeder sinnvollen Weise zerlegen.
Insbesondere können Teilfelder individuell indexiert werden.
In moderneren Datenbanken kann man oft "Objekte", also 
Textdokumente, PDF-Dateien, Video- und Soundclips, Graphiken, komplexe Tabellenkalkulationen einbeziehen und anzeigen, abspielen oder bearbeiten. Dies ist vergleichbar mit "Plugins" in Internet- Browsern, die im Browserfenster bzw. sogar nur Ausschnitten davon agieren.
Die Organisation solcher Objekte ist dem Anwender selbst überlassen. In geeigneten Kategorien des  Datenformats können allerdings Links auf diese  Objekte hinterlegt werden, über sogenannte "Flips"   unterstützt allegro dann den Aufruf einer Anwendung  für die Anzeige etc. der Objekte. Dies ist vergleichbar  mit den Helper-Applikationen in Internet-Browsern, die installiert und bekanntgegeben werden. 
Beziehungen zwischen Tabellen werden durch IdNummern oder andere Schlüssel dargestellt. Wenn z.B. Tabelle A in Spalte 5 eine Nummer hat, die innerhalb A eindeutig ist, können sich andere Tabellen auf diese Nummer beziehen, d.h. in Tabelle B kann z.B. Spalte 7 Nummern enthalten, die in A5 vorkommen müssen. So werden auch Bestandteile zusammengehalten, die zu einem logischen Satz gehören, wenn dieser physisch auf mehrere Tabellen verteilt ist (s.o.). In einem View können genau die Elemente erscheinen, die für den Betrachter wichtig sind, d.h. keine IdNummern u.dgl., sondern Klartexte. Beziehungen zwischen Datensätzen werden durch IdNummern oder andere Schlüssel dargestellt. Das Prinzip ist logisch gesehen dasselbe wie in relationalen Datenbanken.
Für die Anzeige von Datensätzen und für die Indexierung gibt es außerdem eingebaute Mechanismen, die eine IdNummer durch einen Klartext ersetzen. Die scheinbare "Flachheit" der Dateien wird dadurch in ein potentiell komplexes Beziehungsgeflecht verwandelt, die Organisation der Dateien selbst und die Austausch- und Bearbeitungsvorgänge bleiben aber immer unkompliziert.
Für den schnellen Zugriff und für geordnetes Browsing kann jede Spalte jeder Tabelle indexiert werden. Es wird jeweils der gesamte Feldinhalt indexiert. Eine Zerlegung des Feldinhalts z.B. für eine Stichwortindexierung gibt es normalerweise nicht, dazu müssen zusätzliche Programme geschrieben oder Extra-Tabellen angelegt werden, in jedem Fall ein recht hoher Aufwand.

Ein Index  kann in SQL nicht direkt angezeigt und durchgeblättert werden, sondern nur über Views. Ein Index hat eine andere Funktion als bei allegro! (s.o.)
Modernere Datenbanken kennen auch Spalten, in denen die Einträge variable Länge als Text haben und indexierbar sind. (Die variablen Textfelder von dBase waren nicht indexierbar.)  Bei MySQL gibt es eine Volltext-Indexierung, die auf ausgewählte Felder angewendet werden kann. Ein sichtbares Register ist auch damit nicht verbunden.

Mehrere Spalten können einen gemeinsamen Index bilden. (Wenn man mehrere Spalten für Namen oder Schlagwörter pro Satz hat, wäre das sonst ein großes Problem.) 


 

Für den schnellen Zugriff und für geordnetes Browsing kann jedes Datenfeld oder Teilfeld indexiert werden. Die Indexdatei einer Datenbank, eine B*-Baumstruktur, kann bis zu 11 Register umfassen. Die Parametrierung ermöglicht jede Art der Manipulation des Feldinhaltes sowie eine Mehrfachindexierung eines Feldes und auch das Zerlegen in beliebiger Weise (Stichwortindex!). Bei einem String-Index (Titel) können Nichtsortierwörter wie Artikel am Anfang von der Ordnung ausgeschlossen werden. 
In Registern kann man blättern, sogar trunkieren, und direkt Ergebnismengen bilden (mit Operatoren UND, ODER, NICHT). Registerausschnitte kann man kopieren. In Registern können Verweisungen erscheinen, die bei Anwahl zu einem anderen Registerabschnitt hinführen. 
Mehrere oder auch alle Felder können im selben Register indexiert werden. Jedes Feld oder Teilfeld kann in unterschiedlicher Form in mehreren Registern indexiert werden. 
Innerhalb eines Registers können durch beliebige Präfixe mehrere Abteilungen (logische Register) gebildet werden. Die Zahl 11 ist also keine Grenze. Register 11 kann aber nur mit bestimmten Privilegien benutzt werden (Datenschutz). 
Anzeige und Sortierung des Index sind dennoch trennbar, denn Sortierhilfen (Reduzierung auf Kleinschreibung, Einfügen von Leerschritten ...) können auch verborgen werden. In Client- Server-Anwendungen kann man noch mehr tun, um Verwirrung zu vermeiden.
Zusammengesetzte Schlüssel (aus verschiedenen Spalten) sind meistens  möglich (also nicht unbedingt plattformunabhängig). Wenn ja, ist zu fragen, was passiert, wenn  z.B. das erste von zwei Feldern nicht besetzt ist. D.h. die Frage ist, ob es Möglichkeiten der Ausnahmebehandlung gibt. Beliebige zusammengesetzte Schlüssel sind möglich. Die Parametrierung kann sinnvolle Behandlungen von Fällen vorsehen, wo einzelne Teile des Schlüssels im Datensatz nicht vorkommen. Ein allegro-Register ist, im Vergleich gesehen, eher so etwas wie ein "View", eine virtuelle Tabelle also. (Der Index wird in Realzeit aktualisiert)
Hierarchische Datensätze gibt es nicht, sie können nur als Teilmengen von Tabellen dargestellt werden. D.h. sie werden nicht durch Relationen zwischen mehreren Tabellen, sondern durch Relation einer Tabelle zu sich selbst dargestellt. Je nach Architektur sind verschiedene Strategien zur Lösung der satzübergreifenden Suche (sog. Schiller-Räuber-Problem) realisierbar. Es gibt mehrstufige hierarchische Sätze, aber auch eine Abbildung von Hierarchien durch Satzverknüpfungen (heute die bevorzugte Methode). Dafür kann auch eine satzübergreifende Suche mittels Parametrierung eingerichtet werden (sog. "Schiller-Räuber-Problem").

Zugriffsfragen
Auch ohne Index kann (mit Hilfe des Befehls SELECT von SQL) auf alles zugegriffen werden. Kleinere Datenbanken (unter 10.000 Sätze, nur wenige sind größer, auf's Ganze gesehen) werden oft ohne Index betrieben! Bei größeren Datenbanken dauert dies jedoch für den Normalbetrieb zu lange, besonders bei geordneter Anzeige und bei den beliebten "Joins" (Verbindung von Tabellen über gemeinsame Attribute).  Ohne Index kann mittels Volltextsuche zugegriffen werden. Die Datenbankgröße hat hier ebenfalls Bedeutung: Weniger als 30 Sekunden für 1 Mio Datensätze sind aber realistisch. Es wird praktisch keine Datenbank ohne Index betrieben, auch sehr kleine nicht, denn der Index ist integraler Teil des Konzepts. Die Indexzugriffe sind auch bei mehr als 10 Mio Sätzen noch sehr schnell. Weniger als 1 Sekunde ist hier realistisch. "Join"-Funktionen werden logisch gesehen über den Index bzw. über Satzverknüpfungen realisiert - das System muss dazu keine internen Hilfstabellen oder so etwas aufbauen.
Fast jede Art von Abfrage und Auswertung kann mit Hilfe des SQL-Befehls SELECT programmiert werden, bis hin zur Ordnung und Gruppierung von Ergebnismengen.  Zugegriffen wird i.d.R. über die Register, mit logischen Kombinationen und Restriktionen können Ergebnismengen eingeschränkt werden. Erstellung komplexer Listen mit spezifischer Ordnung und Gruppierung oder Auswertung erfordert Kenntnisse der Parametrierung (Exportsprache). Die Windows- Programme erleichtern die Listensretellung sehr stark durch die neue  "View-Technik"  (V20a).
Typische Anfragen an eine relationale Datenbank: 
"Bitte alle Angaben zu XYZ!" (Wobei XYZ typischerweise relativ kurz ist, etwa ein Name oder eine Bezeichnung, und seine genaue Schreibweise meistens bekannt.) 
"Wieviel Umsatz machten die Außendienstler im letzten Quartal?" 
"Welche Produkte waren im Vorjahr die Renner?" 
"Bei welchen Lieferanten kaufen wir am meisten?" 
"Welche Rechnungen des Vormonats sind noch offen? Was ist deren Summe?" 
Der Umgang mit Zahlen, das wird daraus klar, ist äußerst wichtig. Mit der Sprache SQL kann man solche Anfragen formulieren und Antworten in der gewünschten Form erhalten (geeigneter Datenbankentwurf vorausgesetzt). 
In Bibliotheken sind Fragen solchen Typs z.B. in den Geschäftsgängen Ausleihe und Erwerbung interessant, kaum im Katalogwesen.
Typische Anfragen an eine allegro-Datenbank: 
"Bitte alle Angaben zu XYZ!" (Wobei XYZ oft ziemlich lang ist und seine genaue Schreibweise häufig nicht bekannt.) 
"Ist eine deutsche Ausgabe von 'The agony and the ecstasy' vorhanden?" (Wobei  oft unbekannt ist, wie der deutsche Titel lautet (hier 'Michelangelo').) 
"Welche Werke von Tschaikowsky sind da?" (Und man erwartet eine vollständige und nach Werktiteln geordnete Liste, obwohl es über 30 Schreibweisen des Namens gibt und auch die Werktitel immer wieder anders geschrieben werden.) 
"Was gibt's zum Thema 'Drogensucht'?" (Egal, ob dieses Wort im Titel vorkommt oder z.B. 'Rauschgiftsucht' etc., auch englische Titel sind erwünscht, auch Arbeiten über Alkoholismus - oder solche eben gerade nicht.) 
Diese Fragen machen eins deutlich: Man braucht sichtbare Register zum Browsing und auch solche Dinge wie Einheitstitel und Normdaten für Namen und Schlagwörter.

Datenaustausch
Die Ausgabe von Daten in der jeweils benötigten Form ist Sache der Anwendungsprogrammierung. SQL selber hat dazu nur geringe Mittel, es liefert nicht viel mehr als Tabellenzeilen mit einem Trennzeichen (meist TAB) zwischen den Feldern, ein sog. "CSV-File". 
Sehr erleichtert  wird das Erstellen von Listen aber durch Reportgeneratoren. Flexible, leicht erstellbare Reports sind der wichtigste Zweck vieler RDBMS-Lösungen. Sie bilden eine wichtige Komponente von "Management-Informationssystemen". Datensätze im MAB-Format auszugeben ist dagegen eine ganz andersartige Aufgabe.
Es existiert eine Exportsprache (eine eigens entwickelte Programmiersprache), mit der man Daten in fast beliebiger Aufbereitung ausgeben kann (z.B. auch in MAB oder MARC oder in der Form einer CSV-Datei, wie ein RDBMS es einlesen kann). Aus Gründen der Effizienz (z.B. hohe Geschwindigkeit beim Indexieren) ist die Sprache sehr kompakt und daher nicht leicht zu erlernen.  Zwar kann man vielseitige Module schaffen, und es gibt solche für verschiedene Typen von Listen, aber so etwas wie einen universellen Reportgenerator gibt es noch nicht. Reports sind in den meisten allegro-Anwendungen eher Nebenprodukte. Oft reichen die Register oder die Kurzlisten, wenn sie geschickt gestaltet sind. 
Die Umwandlung von Fremddaten ist gleichfalls durch Anwendungsprogramme zu lösen, SQL kann nur eine fertig vorbereitete Struktur verarbeiten (Felder mit Trennzeichen, CSV-Files also). Oft wird die Umwandlung mit eigenen Perl-Programmen o.a. erledigt. Es existiert eine Datenmanipulationssprache, (sog. "Importsprache") mit der man Fremddaten fast beliebiger Struktur in die eigene Struktur umwandeln kann, bevor man sie mit dem DOS-Programm UPDATE oder dem Windows-Programm a99 in die Datenbank einmischt. Auch CSV-Files kann man leicht importieren, denn sie haben eine immer gleiche Anzahl von Trennzeichen, das reicht als Struktur aus. 
Das Vorbereiten der Daten kann aber auch mit Perl o.ä. geschehen.
Ab V25 kann der Austausch in beiden Richtungen dank aresqa in vielen Fällen ganz ohne Parametrierung auskommen.

Programmierung
SQL kann in andere Programmiersprachen (z.B. auch Perl oder PHP) eingebettet werden, insbes. für Web-Anwendungen. Neben den autonomen ("monolithischen") Zugriffsprogrammen (DOS, UNIX, Windows) gibt es für alle Plattformen den avanti-Server, dessen Abfragesprache in andere Sprachen (z.B. PHP oder Perl, für Web-Anwendungen) eingebettet werden kann.
Ein RDBMS kann nur in einer  Anwendungsumgebung (geschrieben z.B. in C, Visual Basic oder einer anderen geeigneten Sprache) arbeiten. Es hat keine für Anwendungen unmittelbar geeignete Benutzungsoberfläche. Es gibt jedoch mächtige Entwicklungssysteme, mit denen maßgeschneiderte (meistens maskenorientierte) Anwendungen ohne viel Programmierung interaktiv erstellt werden können. Die Übertragbarkeit auf ein anderes RDBMS ist dann aber wieder in Frage gestellt, auch die Optimalität für große Datenmengen ist nicht unbedingt gegeben. Wenn es aber um ad-hoc-Schnellschüsse für begrenzte Zwecke geht, hat man dafür hervorragende Werkzeuge. allegro enthält alle Mittel, eine Anwendung komplett zu gestalten, bis hin zu einer mehrsprachigen Oberfläche. Im Prinzip braucht man also keine Programmiersprache zu können. Zur normalen Benutzung einer Datenbank (Katalogisieren, OPAC) braucht man nichts zu programmieren.  Einbindung in Perl, PHP oder andere Sprachen (z.B. auch Delphi) ist aber gleichfalls möglich, etwa für Web-Anwendungen. Die wichtigsten Mittel sind die Exportsprache zur Gestaltung aller Anzeigen und Ausgaben sowie die FLEX-Makrosprache zur Programmierung von Abläufen (Windows). 
Das Sortiment der allegro-eigenen Sprachen für Export, Import, Konfigurierung, Formulare und FLEXe ist allerdings auch nicht gerade sehr leicht zu erlernen. Es gibt Hilfen für den schnellen Aufbau einfacher Anwendungen, doch jenseits davon braucht man längere Einarbeitung.
Ein RDBMS arbeitet bei Mehrplatzbetrieb in der Regel als Client/Server-System. Anwendungsprogramme "unterhalten" sich also mit dem Server und greifen nicht selber direkt auf die Datenbank zu. Besonders für Web-Anwendungen ist die Client/Server-Architektur geradezu zwingend. Es gibt sowohl monolithische Programme (unter DOS, Windows, UNIX), die selbständig lesend und schreibend (mehrplatzfähig) auf die Datenbank zugreifen, als auch einen Datenbankserver (avanti), für den man beliebige Client-Programme schreiben kann, auch für's Web. In lokalen Netzen wird fast nur mit den monolithischen Programmen gearbeitet (weil am schnellsten, und man braucht keinen Server zu betreiben). Auch das Einmischen von neuen Daten kann im laufenden Betrieb durch monolithische Programme geschehen.
Mit sogenannten ODBC-Schnittstellen, oder auch den Perl-DBM-Modulen wird versucht, Anwendungen eine "generische" relationale Datenbank vorzuspiegeln. Zum Beispiel sind mit und für Microsoft Access (kein Client/Server) entwickelte Anwendungen dann ohne Änderung auch mit dem Microsoft SQL-Server funktionsfähig. 
Auch bibliothekarische Software unterstützt stellenweise mehrere relationale Datenbanken: "Bibliotheca Win" etwa das Centura RDBMS (vormals Gupta) als Low-Cost-Variante oder Oracle als High-Cost-Alternative. 
In der Windows-Welt gibt es über das COM-Konzept (Component Object Model) die Möglichkeit, aus anderen Programmen heraus mit einem unsichtbaren Microsoft Access (z.B. lizenzierte Runtime-Version) oder einer anderen Datenbanksoftware über SQL-Befehle Datenbanken zu verwalten.
Client/Server-Anwendungen können über TCP/IP den avanti-Datenbankserver in dessen Sprache ansteuern oder aber per sog. FLEX ein auf derselben Maschine laufendes Windows-allegro (a99). Dies ist eine Fernsteuerungsmethode vergleichbar mit der Fernsteuerung von Anwendungen über Visual Basic, hier aber mit einer allegro-eigenen Sprache. Diese Methodik für Windows-Anwendungen ist noch sehr neu und breitet sich zur Zeit erst unter Experten aus. Es wurden damit bereits Erwerbungs- und Ausleihfunktionen realisiert, aber auch eine neue Web-Schnittstelle ("RuckZuck").
Das Trigger-Konzept ermöglicht es, Programme zu schreiben, die immer dann automatisch ablaufen, wenn sich bestimmte Veränderungen ereignen. So kann man komplexe Bedingungsprüfungen und nachfolgende Aktionen programmieren.
Mit Hilfe des PV-FLEX (Programmierte Validierung) kann man logisch gesehen dasselbe für eine allegro-Datenbank realisieren. Bei jedem Speichervorgang wird dann ein Makro ausgeführt, welches vor oder nach dem Speichern des Satzes jede gewünschte Prüfung und/oder Aktion durchführen kann.

Plattformen
Etliche RDBMS haben Versionen für UNIX, Linux und Windows. Aktuelle Versionen für DOS gibt es wohl nicht mehr, zumindest nicht für SQL-Systeme. (dBaseIII war zwar relational, hatte aber kein echtes SQL und war nur begrenzt mehrplatzfähig.) Ob zwischen den Plattformen funktionale Unterschiede bestehen und ob Datenbanken unmittelbar kopiert werden können, ist man jeweils zu prüfen. allegro existiert für DOS, Windows (ab '95), Linux und UNIX (Solaris). Datenbanken können ohne Änderung zwischen den Plattformen kopiert oder auch via Samba zugleich von zwei Plattformen aus benutzt werden. Auch sehr alte PCs können immer noch als DOS-OPAC-Terminals dienen, während zugleich neuere Geräte unter Win'95 usw. zugreifen.

Sicherheitsfragen
Jede Schreib-Transaktion sollte auf ganz bestimmte Weise abgesichert sein, und zwar müssen die sog. ACID-Bedingungen eingehalten werden:
Atomicity: Aktion wird ganz oder gar nicht ausgeführt 
Consistency: Zustand nach der Trans. soll wieder "integer" sein 
Isolation: das Ergebnis soll so sein, als liefe zugleich kein anderer Vorgang. Dazu müssen alle Vorgänge "serialisierbar" sein (d.h. nicht echt parallel). 
Durability: Ergebnis soll hinterher sofort dauerhaft in der Datenbank stehen (nicht zuerst nur in einem Cache o.dgl.)
Die ACID-Bedingungen werden durch geeignete Maßnahmen erreicht. Insbesondere gehört dazu das Sperren auf Satzebene bzw. im Index bereichsweise und wo nötig auch in anderen Dateien (Adressentabelle). Vor dem Speichern können programmierte Validierungen die Integrität prüfen. 
Die Satzsperre ist nie eine Lesesperre, d.h. Sätze, an denen gearbeitet wird, können im OPAC oder von anderen Bearbeitern jederzeit gelesen werden. 
Bleibt eine Satzsperre etwa durch Absturz eines PC bestehen, kann sie leicht aufgehoben werden. Eine Hilfsfunktion kann solche Sätze finden.
Alle Transaktionen werden in einem "Logbuch" aufgezeichnet, das im Falle eines Zusammenbruchs oder Systemfehlers für "Rollback" und "Recovery" sorgen kann. Alle Speichervorgänge werden in der Reihenfolge des Ablaufs (serialisiert) in einer LOG-Datei aufgezeichnet (die auf einer anderen Platte liegen kann). Diese kann auch zur regelmäßigen Aktualisierung einer Schattendatenbank dienen, aber primär wird sie gebraucht, um aus einer Sicherungskopie der Datenbank wieder den Zustand unmittelbar vor einem Zusammenbruch zu rekonstruieren. 
Zu sichern braucht man im Prinzip nur die Nutzdaten, alle anderen Dateien (Index, Kurztiteldatei etc.) sind daraus rekonstruierbar. Völliger Neuaufbau kann z.B. bei 1 Mio. Datensätzen in unter 8 Stunden ablaufen.

Leistungsbedarf
Generell brauchen große, komplizierte Datenbanken große, schnelle Maschinen mit viel Arbeitsspeicher, um hohe Leistung zu erzielen. SQL-Systeme können z.B. bei Massenänderungen in einzelnen Tabellenspalten sehr schnell sein, denn oft wird dabei die gesamte Tabelle in den Arbeitsspeicher geladen. allegro-Datenbanken mit Millionen Sätzen laufen immer noch mit guter Leistung auf normalen Novell- oder Win-Servern und fordern weder für Client noch Fileserver extrem viel Arbeitsspeicher. Auch die Anforderungen an die Rechenleistung sind eher gering. Das Updating größerer Mengen von Sätzen ist aber zeitkritisch, weil jeder Satz dabei mehrere Zugriffe erfordert. Da kommen schnell mal 1 oder 2 Sekunden pro Satz zusammen.
Der Speicherbedarf je Datensatz ist nicht bei jedem System gleich, er hängt vor allem davon ab, ob Tabellenspalten zur maximalen Länge mit Leerzeichen aufgefüllt werden oder nicht, und vom Bedarf der Indexdateien. Selbst wenn aber bis zu 5K je Satz gebraucht werden, wird das bei heutigen Plattenpreisen nicht mehr als Problem empfunden. Und im Vergleich zu Volltexten von Büchern brauchen Katalogdaten selbstverständlich in jedem Fall sehr wenig Platz. Typische Katalogdatensätze brauchen im Schnitt unter 1000 Byte, einschließlich der Indexdatei und der sonstigen Zusatzdateien. In den Sätzen gibt es keine Leerräume, und der Index wird mit einer Komprimierungstechnik klein gehalten. 
Von Vorteil ist dies, wenn eine Datenbank auf CD-ROM veröffentlicht werden soll (Maximum 640 MB). Es gibt Beispiele mit über 2 Mio. Datensätzen auf einer CD.


Wer bis hierher gelesen hat, kann die Fragen des ersten Satzes leicht beantworten: "Keins" bzw. "Nein". Die zugrundeliegenden Vorstellungen, was denn eine Datenbank für Eigenschaften haben und was sie leisten soll, unterscheiden sich einfach zu stark. Manche Typen von SQL-Abfragen wird man mit Hilfe der FLEX-Technik und der Parametrierung nachbilden können, nicht jedoch die gesamte Bandbreite der SQL-Funktionen. Schließlich ist SQL ausdrücklich für RDBMS geschaffen worden, allegro aber hat aus guten Gründen ein anderes Konzept. Die Erwartung, beide könnten weitgehend kompatibel gemacht werden, ist also unrealistisch. (Umgekehrt könnte man mit SQL auch nicht alles nachbilden, was man mit allegro machen kann. Z.B. das Blättern in Registern und die hierarchischen Satzstrukturen.)

Diese Übersicht macht hinreichend die Stärken und Schwächen beider Datenbankkonzepte deutlich. Hätte eines der beiden keine Schwächen, würde es entweder allegro nicht geben, oder aber die UB Braunschweig wäre inzwischen die reichste Bibliothek der Welt.
Aber Scherz beiseite: durchaus denkbar sind hybride Anwendungen, die sich der Vorteile beider Systeme bedienen. Warum nicht z.B. Katalogisierung und OPAC mit allegro, Erwerbung und Ausleihe mit einem RDBMS. Beide können über ihre Schnittstellen sowohl die andere Datenbank befragen als auch ihr Auskünfte geben! Denkanstöße in dieser Richtung kann der hier vorliegende Vergleich möglicherweise geben.

Vergleichweise noch weitaus seltener anzutreffen und in der Standardisierung noch nicht so weit fortgeschritten sind Objektorientierte Datenbanksysteme (OODB). Zu deren Grundkonzept hat allegro eine viel größere Ähnlichkeit als zum RDBMS-Konzept.



P.S. Gefunden im Archiv von "slashdot" (für solche Leser, denen die Komplexität von Bibliotheksanwendungen noch nicht recht einleuchtet):
Things a library system needs 

-- on Tuesday August 22, 2000, @04:34PM (#836100)
(http://www.apnic.net/ | Last Journal: Thursday June 13, @11:02AM)

# Be able to read any of three or four dozen MARC "standards"
# Search on any word (but the stop dictionary for words such as the and to of ect.) for a word in any
one of over 1K places in the marc record.
# Be able to handle more than one library,
# be able to store books in different locations within the library,
# do user tracking by overdue, notes on the user, automatically import from other databases or text files,
have any one of several options for the user such as loan period
(but checks the holding to see if the standard period is longer or shorter,
or if the fine for overdue is less or more), be able to block a user,
# be able to block a user based on what library they are a user for, much much more,
# be able to route books between libraries,
# be able to route books to outside vendors such as binders, restorers, storage, ect.ect.ect.
# be able to find out who checked out a book last,
# be able to change the default loan period.
# Maintain statistics on the book such as size, no. pages, language, print size, ISBN, LCCN,
how many times used in the library, checked out, inventoried, price, "extras" such as clear cover,
a place for notes for the whole library system and another place for each library,
ability to search on the note, title author, publisher, copyright date, date purchased,
dewey, LCN cataloging or some other system, age limits for checking out.
# Keep track of budget and invoices, orders, barcodes, much much more.
# Ability to keep track of when the next magizne is due, when the subscription runs out,
where the old copies vs. new copies are, index the mags.,
# Print reports on just about anything so throw a report generator at it.
And if you want more, there is about five hundred pages of basic requirements in any
book on library science. Add to that you have to know who a user is and if they are
authorized to do any particular function, (Some can check out, but not in, others can
add a note but not edit the book, some can edit books but not at any library except
where they are assigned) you get the picture.

Off hand, I'd say that a good library system is about four hundred times more difficult than writing Linux.
I know. I do Unix admin and Library systems for a living.

Trust me, this is not simple. I do think it very worthwhile though.



[i] zuletzt aktualisiert: 20.04.2011
Email: b-eversberg@gmx.de