Kap. 5 : Datentypen

Datenbankarchitektur : eine etwas andere Sichtweise

Kap. 7 : Zeitschriften

Will man für ein gegebenes Datenbanksystem ein neues, internes Datenformat entwerfen, so muß man sich im Prinzip mit allen Fragen und Details beschäftigen, die in den vorangegangenen Übersichten zusammengestellt sind. Allein der Umfang der Tabellen läßt erkennen, daß die Aufgabe nicht eben trivial ist und aus viel mehr besteht als aus dem Zusammenstellen einer schlichten Liste von Datenfeldern. Nehmen wir aber einmal an, man hätte es geschafft, ein den eigenen Zielen vollauf genügendes Format zu erstellen, oder man macht es sich einfach und erklärt MAB zum Internformat (was allerdings nicht ohne lokale Erweiterungen abgeht, mindestens für Geschäftsgangsdaten). Man wird feststellen, daß damit noch nicht viel getan ist, sondern drei Herkulesarbeiten noch zu erledigen sind:

1. Umsetzung für die konkrete Software
Der Formatentwurf muß in eine Spezifikation für die besagte Datenbanksoftware umgesetzt werden. Das bedeutet, daß man das erstellte Format in einer zum Datenbanksystem gehörigen Datendefinitionssprache formulieren muß. Evtl. gibt es auch ein Hilfsprogramm, das diese Arbeit über eine Menüführung erleichtert.

Im Fall der allegro-Software bedeutet das z.B., daß man eine Konfigurationsdatei (Typ .CFG) zu erstellen hat. Deren zentraler Teil besteht (ab Version 13) aus einer Liste aller Datenfelder mit ihren jeweiligen Eigenschaften.

2.  Parametrierung für Anzeige, Index und Druck
Damit überhaupt Zugriffe möglich sind, braucht die Datenbank einen Index, und im allgemeinen soll ein solcher Index mehrere Register haben, in denen man getrennt suchen kann. Dem System ist daher mitzuteilen, welche Datenelemente zu indexieren sind und in welcher Weise. Für Bibliotheksdaten reicht eine schlichte Sortierung des Feldinhalts dabei nicht aus. Es muß Möglichkeiten geben, Feldinhalte zu zerlegen (etwa Titel in Wörter), Zeichen umzucodieren (etwa Umlaute aufzulösen), oder auch Feldinhalte zusammenzusetzen (etwa Sachgruppe+Jahr).

Im allgemeinen wird man ferner für unterschiedliche Zwecke (verschiedene Endbenutzer) auch unterschiedliche Anzeigeformen wünschen (ISBD mit unterschiedlicher Ausführlichkeit, Kurzanzeigen, Anzeigen mit Feldbezeichnungen, ...). Jede solche Form benötigt eine eigene Spezifikation, oft "Anwendersicht" oder auch "(Ausgabe)Format" genannt. Dasselbe gilt für Druckformen, wie z.B. Katalogkarten. Für die Produktion von sortierten Listen kommt hinzu, daß man die Art der Sortierung irgendwo und irgendwie festlegen muß, und diese Aufgabe ist gerade bei Bibliotheksdaten und speziell bei RAK-Daten ein ganzes Kapitel für sich.

Datenbanksysteme besitzen in der Regel eine Datenmanipulationssprache (oft auch "Reportgenerator") genannt, mit der man solche Aufgaben lösen kann. Oft sind aber die Mittel und Methoden für die Bildschirmanzeige und für Druckprodukte unterschiedlich! Für den Index kann es sein, daß die Spezifikationen mit der Datendefinitionssprache zu formulieren sind, also einen Teil der Formatdefinition bilden.

Im Fall allegro sind alle diese Aufgaben mittels Export-Parameterdateien zu lösen, insbesondere auch die Struktur des Index. Dieser ist somit weitgehend unabhängig von der Datendefinition. In der Praxis wird meist eine große Anzahl von Parameterdateien benötigt, während die Datenbank nur eine Konfigurationsdatei braucht.

3. Parametrierung für den Datenaustausch
Verbunddatenbanken und die Daten der Nationalbibliographien stellen wertvolle Datenquellen für Bibliotheken dar. Auch für Spezialbestände lohnt es immer mehr, solche Quellen anzuzapfen, also Fremddaten daraus in die eigene Datenbank zu übernehmen. Das setzt in jedem Fall eine Konvertierung der Fremddaten voraus, weil diese in aller Regel in einem anderen Format vorliegen. Aber auch wenn man intern MAB verwendet: völlig ohne eine Umwandlung geht es nie ab! Früher mußte man für jede konkrete Umwandlung ein eigenes Konvertierprogramm (in Cobol, Fortran o.a.) schreiben. Heute haben Datenbanksysteme meistens Schnittstellen für bestimmte andere Formate, und/oder es gibt Hilfsprogramme, die das Konvertieren erleichtern.

Im Fall allegro wird jede Konvertierung mit Hilfe des Importprogramms gelöst. Dieses erkennt aber kein Fremdformat automatisch, sondern man muß in jedem Fall eine Import-Parameterdatei schreiben, die das Fremdformat genau beschreibt und angibt, was mit den einzelnen Feldern passieren soll. Die Möglichkeiten zur Umwandlung auf der Feldebene sind sehr weitreichend, entsprechend der großen Vielfalt der anzutreffenden Datenformate. Diese Beschreibungen erfolgen in der sog. Importsprache.

Alle diese wirklich komplexen Aufgaben könnte man vergessen, gäbe es ein Standardformat für Bibliotheksdaten (nicht nur für bibliographische, sondern auch für Bestands- und Geschäftsgangsdaten!), und Normen für die Bildschirmanzeige, die Register, und für gedruckte Listen, und gäbe es eine Software, in die alles dieses schon eingebaut wäre. In der Tat verzweifeln Softwarehersteller über die Bibliothekare, weil diese sich nicht auf dergleichen Normen einigen können. Selbst dann aber, wenn auf nationaler Ebene solche Normen realisiert wären (MAB ist leider nicht einmal eine halbe Antwort), das Importproblem bliebe für ausländische Daten bestehen. Die von der Library of Congress gesetzten und auch international weitgehend akzeptierten Standards sind der deutschen Bibliothekswelt erstens ziemlich fremd (kaum jemand kennt sie wirklich genau), und zweitens würden sie zu einer Abkehr von anderen Normen zwingen, die sich hier wenigstens halbwegs durchgesetzt haben, als da sind RAK und RSWK.

Wenn man die verschiedenen Formate daraufhin untersucht, welche Eigenschaften die oben beschriebenen Aufgaben erleichtern oder erschweren, ergeben sich die folgenden Grundsätze für ein "anwendungsfreundliches" Format:

1. Auf den Zugriff kommt es an, oder: Online ist wichtiger als Offline

Die Erfordernisse der Online-Datenbank sollten im Vordergrund stehen, konventionelle Produkte (Zettel, Listen) sollten keinen bestimmenden Einfluß auf die Formatstruktur haben.
Es gibt Formate, deren Anordnung ganz oder teilweise der Struktur eines Katalogzettels o.ä. entspricht. (Beispiele: MARC, MAB). Das mag noch angehen, keinesfalls sollten aber die Erfordernisse der gedruckten Ausgabe darüber bestimmen, ob ein für den Online-Zugriff wichtiges Element erfaßt oder nicht erfaßt wird, und wie es erfaßt wird. Ein wichtiger Aspekt: Wenn ein Feld im Druckbild anders aussehen muß als es die Datenbank erfordert, ist es in einem zusätzlichen Feld zu erfassen. Sehen beide Formen gleich aus oder kann die Druckform per Programm aus der Datenbankform erzeugt werden, braucht die Druckform nicht erfaßt zu werden. Heutige Formate arbeiten oft umgekehrt: erfaßt wird primär immer die Druckform, wenn diese für den Datenbankzugriff nicht geeignet ist, wird zusätzlich eine Datenbankform erfaßt (z.B. MAB 310/331) - ein veralteter Ansatz. Wenn eines Tages der Zettelkatalog endgültig ausgedient hat, sollte man die zugehörigen Daten leicht loswerden können.

2. Ein Objekt - ein Datensatz

Die Objekte, die eine Datenbank beschreiben soll, sind genau zu definieren. Ein Objekt sollte durch genau einen Datensatz beschrieben werden. Insbesondere: Keine Satzverknüpfungen definieren, bei denen einer der verknüpften Sätze nur mit genau einem anderen Satz zusammen einen Sinn ergibt, also beide gemeinsam nur ein Objekt beschreiben.
Ein krasses Gegenbeispiel: die "Nachsätze" des MAB-Formats. Diese geben nur zusammen mit dem Hauptsatz einen Sinn. Sie wurden nur eingeführt, weil man nicht genug Feldnummern für den Titelsatz hatte und weil für die Bibliographieproduktion ein Vorteil damit verbunden war. Somit ist dies auch im Sinne von Nr. 1 bedenklich.  MAB2 kennt diese Nachsätze nicht mehr.

3. Zusammenhänge bewahren und erkennbar machen

Ein bibliothekarisches Format besteht zwangsläufig aus vielen einzelnen Feldern, die man deshalb in nicht zu viele, sinnvolle Gruppen gliedern sollte. Elemente, die nur zusammen einen Sinn ergeben, sind möglichst als Teilfelder zu einem Feld zusammenzufassen. Auf jeden Fall dann, wenn es sich um wiederholbare Elemente handelt.
Ein Plädoyer für Teilfelder! Formate wie MAB1, die konsequent ohne Teilfelder arbeiten, brauchen nicht nur übermäßig viele Feldnummern, sondern müssen "Periodenfeldgruppen" einrichten, d.h. zusammengehörige Felder, die sich als Gruppe wiederholen. Solche Erscheinungsformen sind unübersichtlich und ineffizient. Wo allerdings eine gebräuchliche Interpunktion sich zur Gliederung bewährt hat, ist sie der Teilfeldtechnik vorzuziehen. Das BNB-MARC z.B. geht noch weiter als USMARC, wenn es selbst die Vornamen von Personen noch als Teilfeld definiert statt sie schlicht mit "Komma Spatium" vom Familiennamen abzutrennen, wie es alte Praxis ist.
In MAB2 wurden mittlerweile Teilfelder eingeführt, "Unterfelder" genannt (sprachlich korrektere Übersetzung von "subfields").

4. Ein Feld - eine Nummer

Feldnummern sollten stets eindeutig sein. Zu vermeiden ist, in unterschiedlichen Satztypen gleiche Satznummern für unterschiedliche Inhalte zu verwenden. Wenn auch, programmtechnisch gesehen, zwei verschiedene Felder in verschiedenen Satztypen dieselbe Nummer haben können, so begünstigt ein solcher Entwurf doch Fehler und Mißverständnisse und erschwert die Programmierung und die Kommunikation der Katalogisierer. MAB und MARC begehen erstaunlicherweise ohne Not diesen Fehler recht ausgiebig: beide verwenden viele identische Nummern mit unterschiedlicher Bedeutung in Titel- und Namenssätzen oder Schlagwortstammsätzen.

5. Redundanz vermeiden

Wiederholung von Angaben in verschiedenen Feldern vermeiden. Elemente mit immer gleichem Inhalt (feststehende Angaben) oder mit einer begrenzten Zahl von möglichen Inhalten nach Möglichkeit verschlüsseln (Buchstabe, Ziffer, Notation) statt im Wortlaut zu speichern.
Dieses Kriterium spielt für Austauschformate eine weit geringere Rolle als für Formate in lokalen Online-Systemen. In der Tat ist insbesondere beim MAB-Format eine recht hohe Redundanz zu bemerken.
Es geht noch weiter: beispielsweise läßt sich sehr oft die "Verfasserangabe" ohne Problem aus der invertierten (Ansetzungs-)Form der Personennamen automatisch erzeugen. Eine Vorschrift, die Druckform der Verfasserangabe dennoch in jedem Fall erfassen zu müssen, ist kontraproduktiv und so gut wie sinnlos. (S.a. 1)

6. Gleicher Inhalt - gleiche Struktur

Felder mit gleichartigem Inhalt sollten auf die gleiche Art strukturiert werden, d.h. die interne Gliederung mittels Interpunktion oder Teilfeldern sollte identisch sein. Indikatoren und andere Strukturmerkmale gleichartiger Felder sollten sich ebenfalls entsprechen. Dies ist ein Prinzip, das in den heute üblichen und in dieser Arbeit dargestellten Formaten weitgehend, aber nicht ausnahmslos erfüllt ist.

7. Hierarchie und Verknüpfung

Mehrbändige Werke (s. Kap.8) sollten hierarchisch gegliedert darstellbar sein. Im Idealfall sollte ein System beides ermöglichen: hierarchische Satzstrukturen und verknüpfte Speicherung der Bestandteile eines Werkes. In MAB sind diese Möglichkeiten gegeben, wenn auch nicht besonders komfortabel, in MARC dagegen gibt es keine Hierarchie. Eine Verknüpfungslogik ist auf alle Fälle für die Verbindung zwischen Titelsätzen und den diversen Stammsätzen nötig. MARC-Daten enthalten i.a. keine Identnummern von Stammsätzen, sondern die jeweiligen Namen oder Schlagwörter im Klartext.

8. Normdaten

Das Format sollte Stammdatensätze für Personen, Körperschaften, Serien, Schlagwörter, und evtl. auch Klassifikationscodes und Einheitssachtitel vorsehen. Titelsätze müssen mit jedem dieser Satztypen in geeigneter Weise verknüpft werden können. Normierung erhöht die Konsistenz einer Datenbank und erleichtert ihre Pflege, stellt aber besondere Anforderungen an die Software. Obligatorisch dürfen die Verknüpfungen andererseits nicht sein, sonst kann man keine Altdaten unterbringen, die noch ohne Normierung erstellt wurden.

Drei größere Spezialthemen verdienen besondere Beachtung, wenn es an die Beurteilung von Formaten geht:

1. Zeitschriften,
2. mehrbändige Werke
3. Bestandsdaten