`Vorangehender Teil`   /   `Fortsetzung` 

10.2.6.8	Export: Normdaten-Verknüpfungen

Mit Version 14 kam ein neues Verfahren, mit dem die Verwendung von Norm- oder Stammsätzen aller Art stark vereinfacht und wesentlich wirkungsvoller gemacht wurde. Mit einem Satz: Identnummern für Namen, Schlagwörter etc. können automatisch durch Klartexte (Ansetzungsformen) ersetzt werden. 

Folgende Ziele wurden verfolgt:
·	Die Methode muß mit jedem Kategoriesystem realisierbar sein 
·	Es muß möglich sein, im selben Feld im einen Fall Identnummern, im andern Fall Klartexte zu verwenden (kein striktes Entweder-Oder). Damit hängt zusammen: 
·	Die nach bisherigen Mustern gestrickten Daten sollen nicht verändert werden müssen (also Handlungsbedarf nur dann, wenn die neue Methode angewandt werden soll) 
·	Existierende Exportparameter müssen ohne Änderung weiter funktionieren, inclusive "Nachladungen" 
·	Der Aufwand für die Anpassung von vorhandenen Indexparametern an die neue Methode sollte sehr gering sein 
·	Bei Änderung einer Ansetzungsform im Stammsatz: automatische Änderung der Registereinträge verknüpfter Sätze 
·	Unterstützung der Erfassung: Stammsatznummern müssen leicht auffindbar und kopierbar sein 
·	Die bisher bekannten unterschiedlichen Modalitäten des Umgangs mit Identnummern müssen unterstützt werden 
	(z.B. sind die Steuerzeichen verschieden, auch die Methoden der Wiederholbarkeit von Kategorien) 
·	Es muß parametrierbare Löschkontrollen geben: Stammsatz nicht löschbar, solange Verknüpfungen vorliegen 

Wie funktioniert die Lösung?
Die Programme (PRESTO etc.) ersetzen jeweils vor dem Abarbeiten der Index- oder Exportparameter die Identnummern der Stammsätze durch die Klartexte, also die Namen, Schlagwörter etc. Nachladungen sind dann unnötig. Nach dem Abarbeiten wird der Datensatz im Arbeitsspeicher wieder in den Originalzustand versetzt. Die Klartexte werden nicht durch Nachladen der Stammsätze herbeigeschafft, sondern aus einem geeignet konstruierten Register ("Ersetzungsschlüssel", s.u.) - nur so geht es schnell genug. Der Index wird zwar größer, doch er ufert keineswegs aus. 
(Anmerkung: Die Methode bezieht sich nur auf Stammsätze, nicht z.B. auf Verknüpfungen von mehrbändigen Werken. Dazu bleibt das "Nachladen" die einzige anwendbare Methode, siehe 10.2.6.7.) 

Was muß man tun?
Soweit die Forderungen und das Konzept der Lösung, nun zur Realisierung. Was alles ist zu bedenken und zu tun, um die neuen Fähigkeiten der Programme zu nutzen? Damit die Übersicht nicht verlorengeht, müssen ein paar Randbedingungen festgelegt werden: 

1.	Stammsätze benötigen Identnummern. Die Identnummern müssen rein alphanumerisch sein (also nur aus Buchstaben und Ziffern bestehen, ohne Leerzeichen, Punkt, Binde- oder Schrägstriche). Es braucht jedoch keine bestimmte Kategorie für die Identnummern festgelegt zu werden, d.h. Körperschaftsstammsätze können z.B. dafür eine andere verwenden als Schlagwortstammsätze. 
2.	Die Identnummern müssen alle im selben Register stehen, und zwar in der Form  nummer=Klartext. Hiervon hängt das Funktionieren der Ersetzungen ab. Das Register kann jedoch noch beliebige weitere Einträge enthalten. 
3.	Die Identnummern müssen eindeutig sein: es darf nicht z.B. dieselbe Nummer für ein Schlagwort und eine Körperschaft verwendet werden, obwohl dies ja unterschiedliche Stammsatztypen sind. (Das ist leicht durch ein Präfix wie p / k erreichbar!) Allerdings reicht es aus, die Nummern beim Indexieren durch ein Präfix eindeutig zu machen. Die Länge der Identnummern braucht nicht einheitlich zu sein. 
4.	Ein bestimmtes Zeichen muß als Steuerzeichen festgelegt werden. Das "konsolidierte Format" ($A.CFG) sieht dafür das Zeichen '_' vor. Das Pica-System verwendet '!'. Dieses Zeichen muß in den Titelsätzen stets vor eine Identnummer geschrieben werden, es kann (z.B. bei Pica) zusätzlich dahinter geschrieben werden. 
	Das Steuerzeichen darf aber auch an anderen Stellen als normales Zeichen verwendet werden, denn wenn es nicht von einer Identnummer gefolgt ist, passiert nichts. 
	Will man erreichen, daß für bestimmte Datenelemente keine automatische Ersetzung erfolgt, verwendet man für diese Fälle ein anderes Steuerzeichen, oder man steckt diese Nummern in ein anderes Register! Oder: man erzeugt keinen "Ersetzungsschlüssel" (s.u.) für diese Sätze. 

Für Titelsätze braucht man keine zusätzlichen Kategorien. Man gibt statt eines Namens oder eines Schlagwortes dessen Stammsatz-Identnummer in derselben Kategorie ein, aber das Steuerzeichen muß davor stehen. In ein und derselben Kategorie kann also wahlweise ein Klartext oder eine Identnummer eingesetzt werden. Das Entscheidende für die Parametrierung ist: man kann so tun, als ob in den Kategorien immer Klartext stünde. Man muß die nachfolgend beschriebenen Voraussetzungen schaffen, dann braucht man sich bei der Parametrierung nicht mehr mit den Identnummern zu befassen, denn vor der Abarbeitung der Parameter ersetzen die Programme jeweils alle Identnummern durch die zugehörigen Klartexte. Damit dies funktioniert, muß man in die Index-Parameterdatei (z.B. CAT.API) drei neue Befehle einbauen. Nur i5 muß unbedingt vorkommen, für die anderen beiden gibt es Standardwerte: 

i4=k	Die Ziffer k ist der Ersetzungsmodus:	Standardwert: i4=0
	Wenn im Datensatz eine Angabe wie _NNN steht, dann bewirkt der Wert 
	0 : Ersatz von _NNN durch den Klartext, hinter _NNN folgende Zeichen werden beseitigt 
	1 : dasselbe, aber wenn hinter _NNN noch Zeichen folgen, bleiben diese stehen 
	2 : wie 0, aber das Zeichen '_' bleibt stehen (sinnvoll für Kontrollzwecke) 
	3 : wie 1, aber das Zeichen '_' bleibt stehen 
	4 : _NNN_ bleibt stehen, der Klartext wird dahinter eingefügt, nachfolgende Zeichen verschwinden 
	5 : wie 4, aber nachfolgende Zeichen bleiben stehen. 
	Wenn in einer Kategorie mehrere Identnummern vorkommen können, kommen nur 1, 3 oder 5 in Frage. 
	Wird in einer Exportparameterdatei kein  i4  angegeben, erfolgt keine Ersetzung. 

	Der "Standardwert" für i4 (d.h. wenn der Befehl weggelassen wird) ist die Setzung "inaktiv". 
	Dieser Wert läßt sich durch  i4=-1  erreichen und bewirkt, daß gar keine Ersetzungen stattfinden. 

i5=x	Das Zeichen x ist das festgelegte Steuerzeichen	kein Standardwert! 
	Ohne den Befehl i5 werden keine Ersetzungen durchgeführt. Das bedeutet insbesondere: alle bisherigen Index-Parameterdateien, die ja diesen Befehl nicht enthalten, funktionieren unverändert. 

i5=xx  (zweimal dasselbe Zeichen) 
	Das Steuerzeichen  x  muß vor und hinter dem Schlüssel stehen. 
	Vorteil: Im Schlüssel können auch Sonder- und Leerzeichen vorkommen.
	   In diesem Fall, also z.B. i5=__, muß der Ersetzungsschlüssel vorn und hinten markiert sein, z.B. _tucho_

i6=i	Im Register i (mögliche Werte 1 - 11) stehen die Ersetzungsschlüssel (s.u.).	 Standard: i6=9 
	Alle für Ersetzungen nötigen Identnummern müssen dann in diesem Register stehen. 
	Dieses Register muß sich im Hauptindex befinden, also z.B.  cat.adx,  nicht cat.aex   o.a. 

Außerdem muß es bestimmte Typen von Schlüsseln geben, damit die Methode funktioniert. (Im Beispiel PICA.PPI ist die Parametrierung dieser Schlüssel exemplarisch durchgeführt und kommentiert.) 
Damit die Beschreibung nicht zu theoretisch wird, soll alles an konkreten Beispielen erläutert werden. 
Hier ist ein Personenstammsatz (wie er im Format $A.CFG aussehen muß): 

#00 123 
#4n Tucholsky, Kurt 
#4naTiger, Theobald; Wrobel, Ignaz; Panter, Peter 

In einem Titelsatz hätte man folglich z.B. dieses Datenfeld für Tucholsky als Verfasser: 

#40 _123         statt        #40 Tucholsky, Kurt

Beim Parametrieren für den Index kann man aber, wie gesagt, so tun, also ob man #40 Tucholsky,`Kurt hätte. 
Für den Stammsatz muß die Index-Parameterdatei folgende Schlüssel liefern, damit das klappt: 

|9123=|ATucholsky, Kurt			Ersetzungsschlüssel, 123 ist zugl. Primärschlüssel d. Stammsatzes 
|9tucholsky, kurt _123			Übernahmeschlüssel  (Erfassungshilfe) 
|1panter, peter -> tucholsky, kurt	Verweisungen im Namensregister 
|1tiger, theobald -> tucholsky, kurt
|1wrobel, ignaz -> tucholsky, kurt 

_1|1tucholsky, kurt				Pseudoschlüssel für automatische Änderung 

Wenn hier von "Namen" die Rede ist, gilt dasselbe immer auch für Schlagwörter, Notationen, und andere Datenelemente, für die man Stammsätze nutzen will. 
Die Parameter CAT.API enthalten ab V14 die Erzeugung dieser Schlüssel. 
Es folgt die Erklärung, was es mit den einzelnen Schlüsseln auf sich hat und wie alles zusammenhängt. 

Der Ersetzungsschlüssel dient dazu, die beschriebenen Ersetzungen durchzuführen. Bevor die Indexparameter abgearbeitet werden, sieht das Programm nach, ob in dem Datensatz das Zeichen x aus dem Befehl i5=x vorkommt. Wenn also z.B. i5=_ ist und in einem Datensatz irgendwo _123 steht (egal wo!), sucht das Programm im dem Register, das durch i6 festgelegt wurde, in diesem Fall also im Register 9, nach einer Zeile, die mit 123= anfängt. Den Klartext, der dahinter steht, hier also Tucholsky, Kurt (in Normalschreibweise, wohlgemerkt), setzt es dann statt der Nummer _123 ein. (Wenn 123 gefunden wird, aber "=..." fehlt, passiert nichts!) Die Angabe |A ist nur für das Programm INDEX nötig, damit dieses in seinem zweiten Durchgang korrekt arbeiten kann (d.h. die Umcodierung vornehmen kann, siehe unten, #-A ist die Sprungmarke dafür). Wenn alle diese Ersetzungen erledigt sind, werden die Indexparameter normal abgearbeitet. Danach werden die Ersetzungen sofort rückgängig gemacht, d.h. der Betrachter merkt von alledem nichts! Nur so ist es aber zu erklären, daß anschließend im Register 1 der Datensatz unter tucholsky,`kurt zu finden ist, nicht unter _123 - was bis Version 13 nicht lösbar war. 

Der Ersetzungsschlüssel kann zugleich Primärschlüssel sein: UPDATE vergleicht beim Einmischen nur den Teil, der vor dem '=' steht. 

Aber: Im Falle i5=xx , also z.B. i5=__, ist der Schlüssel im Kategorietext vorn und hinten zu markieren, z.B. _tucho_ .  Der Ersetzungsschlüssel muß dann aber so aussehen:  _tucho_=|2Tucholsky, Kurt . 

Der Übernahmeschlüssel ist als Erfassungshilfe gedacht. Man möchte ja auf bequeme und zuverlässige Art bei der Dateneingabe die Nummer statt des Namens eingeben können, oder besser: kopieren. Dieser Schlüssel muß nicht im Register 9 stehen, man muß nur bei der Erfassung wissen, wo man ihn findet. (Im Namensregister selbst würde er im OPAC womöglich eher irritieren.) Die Erfassung geht so: in dem Moment, wo ein Name einzugeben ist, z.B. in einer Abfragezeile, drückt man F6, das Register erscheint, schaltet auf das Übernahmeregister um und sucht nach dem Namen. Man setzt den Pfeil auf die Zeile, drückt <Enter>, dann <Strg><Enter>, und die Nummer steht an der gewünschten Stelle. Wenn allerdings noch kein Stammsatz für den Namen vorhanden ist, müßte man diesen zuerst anlegen - oder den Namen zunächst im Klartext erfassen. Nebenbei bemerkt: solange ein Name nur einmal auftritt und keine Verweisungsform benötigt, solange ist ein Stammsatz blanke Umstandskrämerei. 
Gelegentlich wird folgender Wunsch geäußert: In dem Moment, wo ein Name einzugeben ist, und wo man (oder das Programm) feststellt, daß es ihn im Katalog noch nicht gibt, muß ein Fenster aufgehen, wo man ihn als Stammsatz erfassen kann. Mit allegro geht das vorerst nicht. Es empfiehlt sich folgendes: vor der Erfassung des Titelsatzes kurz nachschauen (es geht ja wirklich schnell), ob die benötigten Namen etc. vorhanden sind; falls einer fehlt und man tatsächlich einen Stammsatz haben will, diesen zuerst anlegen, dann erst die Titelerfassung starten. Zuviel der Disziplin? 
Möglich ist der Einbau einer Programmierten Validierung (-Ø 10.2.8), wodurch ein eingegebener Name o.a. am Register geprüft und bei Übereinstimmung eine Meldung ausgegeben wird. 
Die Verweisungen sind ein wichtiger Grund, warum man überhaupt Stammsätze macht: sie führen im OPAC von der Verweisungsform zur Ansetzungsform und gelten für beliebig viele Titel, obwohl sie nur einmal, eben im Stammsatz, gespeichert sind. Eine neue Verweisung wird nur im Stammsatz ergänzt, an den Titelsätzen ist nichts zu tun. Die Anzahl der Verweisungen und die Art ihrer Darstellung in den Registern haben auf die Funktion der Verknüpfung keinen Einfluß. 
Der Pseudoschlüssel ist ein sehr wichtiges Hilfsmittel. Er wird nicht einsortiert (daher "Pseudo"), sondern nur für Kontrollzwecke gebraucht: Gesetzt den Fall, man ändert im Stammsatz die Ansetzungsform (#4n im Beispiel). Dann müssen ja auch die Titeleinträge, die unter tucholsky,`kurt standen, auf die neue Form geändert werden. Das Programm merkt, wenn sich bei einer Korrektur am Stammsatz der Pseudoschlüssel ändert. Dann sucht es die unter der alten Form stehenden Einträge zusammen und überführt sie auf die neue Form. Die Titelsätze werden dazu nicht angefaßt: dort steht ja nur die Nummer, und die ändert sich nicht. (Besser gesagt: sie sollte sich nicht ändern. Man setzt am besten in der .CFG mit ?P5 den Änderungsschutz auf die Kategorie #00). Wenn man in der Index-Parameterdatei keinen Pseudoschlüssel anlegt, finden derartige automatische Verlagerungen nicht statt. 
Der Pseudoschlüssel kann manchmal mit dem Löschkontrollschlüssel (s.u.) kombiniert werden. Im Beispiel ist "|1tucholsky,`kurt" zugleich der Schlüssel, der vor dem Löschen des Stammsatzes kontrolliert werden muß. 
Der Pseudoschlüssel beginnt mit dem Steuerzeichen i5, hier also mit '_'. Die Ziffer '1' dahinter hat eine wichtige Bedeutung: an dieser Stelle kann auch '0' stehen. Die '0' bedeutet, daß nur solche Einträge verlagert werden sollen, die exakt "tucholsky,`kurt" lauten. Die '1' dagegen bewirkt, daß alle Einträge verlagert werden, die mit tucholsky,`kurt beginnen, also z.B. Schlagwortketten mit diesem Namen als Anfangsteil. Diesen Modus kann man also für die einzelnen Stammsatztypen unterschiedlich festlegen. 

Beim Entwurf einer Datenbank sind noch zwei Dinge zu beachten: 

1. Je Stammsatz kann man mehr als einen Pseudoschlüssel definieren. Das bedeutet, daß mehrere Eintragungen automatisch verlagert werden können. Würde man z.B. neben dem Namensregister noch ein Verfasser/Titelregister machen, dann kann sich dort die Änderung des Stammsatzes auch auswirken. Dies wird z.B. bei der Parametrierung des Modells bolero für Musik-Katalogisierung angewandt. 

2. Vorsicht: Die automatische Verlagerung erfaßt auch solche Einträge, die gar nicht vom Stammsatz herrühren! Wenn man z.B. in manchen Titelsätzen #40`_123 stehen hat, in manchen anderen aber den Klartext #40`Tucholsky,`Kurt, dann sehen die Registereinträge für beide gleich aus. Bei einer Änderung der Ansetzungsform im Stammsatz werden dann beide verlagert, denn an das Programm greift dabei nicht auf die Titelsätze zu (das würde zu lange dauern!). Allerdings wird man, wenn man überhaupt mit Stammsätzen arbeitet, solche Mischanwendungen zu vermeiden suchen. Entweder hat man für eine Person einen Stammsatz, dann sollte man diesen in jedem Fall verwenden, oder man hat keinen, dann kann auch nichts schiefgehen. Mehr Überlegung ist nötig, wenn man den Ersetzungsmodus '1' anwendet. Insbesondere bei Schlagwörtern muß man prüfen, ob dann nicht doch Einträge betroffen werden, die tatsächlich nichts mit dem Stammsatz zu tun haben sondern nur zufällig denselben Anfangsteil besitzen. Will man in ein schon laufendes System sukzessive Stammsätze einführen, sollte man für jeden neuen Stammsatz die evtl. schon vorhandenen Klartexteinträge auf Nummern umstellen. 
   Diese zwei Einschränkungen sind nicht gravierend. Erstens sind Änderungen der Ansetzungsform in Stammsätzen ihrer Natur nach nicht eben häufig, zweitens werden die wirklich wesentlichen Einträge in jedem Fall geändert, drittens ist durch eine Neu-Indexierung im Notfall alles wieder zu korrigieren. 

Löschkontrolle
Sobald man mit Satzverknüpfungen arbeitet, ganz gleich für welche Zwecke, entsteht das Problem der Abhängigkeiten: z.B. können verknüpfte Bandsätze von mehrbändigen Werken nicht mehr ohne den Hauptsatz korrekt verarbeitet (angezeigt oder ausgedruckt) werden. Man wird also verhindern wollen, daß ein Hauptsatz gelöscht wird, solange es noch einen verknüpften Bandsatz gibt. Man wird auch verhindern wollen, daß ein Schlagwortstammsatz gelöscht wird, wenn dieser in irgendeinem Titelsatz benutzt wurde. Die Datenbanktheorie hat hierfür den Fachterminus "referentielle Integrität". Bestehende Beziehungen dürfen nicht unbeabsichtigt zerrissen werden. Wie aber soll man das verhindern, wie kann der Löschbefehl abgefangen werden, wo die Verknüpfungen doch so unterschiedlich aussehen können? PRESTO und seine Derivate, aber auch UPDATE ab Version 13a enthalten dafür eine Methode, die "Löschkontrolle" heißt. 
So installiert man eine Löschkontrolle: 
In der Indexparameterdatei richtet man einen Abschnitt mit der Sprungmarke #-- ein. Diese kann nicht normal angesprungen werden, da +- der Abbruchbefehl ist! Der Abschnitt wird nur dann von den Programmen herangezogen, wenn eine Löschung erfolgen soll. In dem Abschnitt hat zu stehen, welche Schlüssel vor jeder Löschung zu prüfen sind. Das können also auch mehrere sein. Nehmen wir als Beispiel die Verknüpfungen zwischen Haupt- und Untersätzen und die zwischen dem Sammelband und den enthaltenen Aufsätzen, wie sie im A-Format definiert sind. Der bewußte Abschnitt könnte dann so aussehen: 

#-- 
!00 p"|9" P"+" 
#t { C }         Zeilenvorschub zwischen den zwei Schlüsseln!
!00 p"|9" P"*" 
#+#

Wenn also ein Datensatz die Kategorie #00 123456 enthält, werden für die Löschkontrolle daraus die zwei Schlüssel 123456+  und 123456* gebildet, die beide im Register 9 zu prüfen sind. Werden dort Einträge gefunden, die mit diesen Zeichenkombinationen beginnen, wird die Löschung verweigert. 
Man beachte den Befehl #t{ C }, der normalerweise bei einem Export einen Zeilenvorschub auslöst. Hier trennt er zwei unterschiedliche Schlüssel, die getrennt zu prüfen sind. Ansonsten hat ein solcher Befehl in einer Indexparameterdatei nichts zu suchen. Auf diese Weise können bis zu 32 Löschkontrollschlüssel definiert werden. 

Aber wie funktioniert dann das Programm INDEX?
Genau diese Frage werden diejenigen stellen, die seit V11 unzufrieden waren, weil man in der Index-Parameterdatei nicht "nachladen" konnte (-Ø 10.2.6.7). Es ist natürlich immer noch so: das Programm INDEX kann die oben beschriebenen Ersetzungen nicht vornehmen, weil zu dem Zeitpunkt, wo es die Daten abarbeitet, der Index noch gar nicht vorhanden ist, aus dem es die Klartexte entnehmen müßte. Für das oben benutzte Beispiel bedeutet dies: INDEX erzeugt den Schlüssel _123 für den Titelsatz anstatt tucholsky,`kurt. Es entsteht also zunächst ein Index mit vielen solchen Einträgen. Diese müssen in einem zweiten Durchlauf aufgelöst werden. In diesem zweiten Durchlauf schaut INDEX nach, ob Einträge vorhanden sind, die mit '_' beginnen, also z.B. _123. Dann sucht es im Register i6 nach 123=, nimmt den Klartext, den es dahinter findet, führt die Befehle bei Sprungmarke #-A aus, und setzt das Ergebnis in das Register, wo _123 stand, und _123 wird dort gelöscht. Wenn "123=" im Register i6 nicht gefunden wird, bleibt es unverändert stehen. 
Den zweiten Durchlauf startet QRIX automatisch, man kann ihn aber auch von Hand starten: 
INDEX -fa1 -d*datenpfad -eindexparameter/datenpfad -kkonfig
d.h. INDEX hat eine neue Funktion -fa erhalten. Sind keine Einträge der bewußten Art vorhanden, geschieht natürlich nichts. Dieser Durchlauf kann auch gestartet werden, wenn die Datenbank schon (im Netz) in Betrieb ist. 

Für sehr große Datenbanken ist es von Vorteil, die Datenbank schon wieder freigeben zu können. Der zweite Durchlauf geht allerdings recht schnell, weil die Datensätze selbst nicht nochmals gelesen und ausgewertet werden müssen. 
Aus diesem Verfahren ergibt sich eine weitere Einschränkung: wenn man z.B. einen Namen in einer weiteren Indexeintragung benutzt als zweiten oder weiteren Bestandteil eines Schlüssels, kann INDEX diesen im zweiten Durchlauf nicht finden, und er bleibt als Nummer im Register stehen. Unter PRESTO würden die korrekten Einträge entstehen, da die Ersetzung vor dem Abarbeiten der Indexparameter stattfindet. Hier ist zu bemerken, daß mehrteilige Schlüssel eine allegro-Eigenheit sind, die andere Datenbanksysteme überhaupt nicht kennen. Auch die Bildung mehrerer Schlüssel aus einem Datenfeld ist in der Datenbankwelt eine eher seltene Besonderheit. 
    Es gibt noch eine Alternative: INDEX kann in einem ersten Durchlauf mit den Optionen -fi0 -@1 zunächst NUR die Primärschlüssel erstellen, in einem zweiten Durchlauf dann mit -fi1 -@2 alle anderen Schlüssel. Wenn es viele Stammsatzverknüpfungen gibt, ist diese Methode schneller! Mehr zu dem Thema: siehe Kap. 7.1. 

Und die Kurzanzeige?
Auch diese kann Elemente enthalten, z.B. den Verfassernamen, die in den Titelsätzen nur aus einer Stammsatznummer bestehen. INDEX korrigiert im zweiten Durchlauf auch die Kurzanzeige, wenn dies der Fall ist. Unter PRESTO ist es ohnehin kein Problem, da vor der Abarbeitung der Index-Parameterdatei, also auch der Kurzanzeige, die Ersetzungen automatisch erfolgen. 

SRCH
Nun zur Volltextsuche. Wenn man "tucho" als Suchwort eingibt, will man alle Datensätze finden, in denen diese Zeichenkette vorkommt, auch die, in denen statt dessen "_123" steht. Auch dieses funktioniert. SRCH liest bei Version 14, anders als früher, vor der Suchaktion die Index-Parameterdatei und informiert sich darüber, ob derartige Verhältnisse vorliegen können, d.h. es schaut sich die Befehle i5 und i6 an. Und dann tut es folgendes: es liest einen Datensatz ein, kopiert ihn in einen "Suchbereich", nimmt per Index die Ersetzungen vor und ersetzt dann noch mit Hilfe der Tabelle S1.ASP einzelne Zeichen (z.B. Groß- durch Kleinbuchstaben). Somit steht dann im Suchbereich tatsächlich "tucholsky". Genauer: dort steht "_123_tucholsky,`kurt". Das bedeutet: man kann sowohl nach dem Namen wie auch der Nummer suchen. Wenn man z.B. als Suchbegriff "#4,123" gibt, werden alle Sätze gefunden, die in einer Kategorie der Gruppe #4 die Ziffernfolge 123 enthalten. Wenn man "#4,tucho" gibt, werden alle Sätze gefunden, die in einer Kategorie der Gruppe #4 die Zeichenfolge "tucho" enthalten - auch dann, wenn diese durch Ersetzung erst über den Index hereingeholt wird, denn die Ersetzung passiert vor der Abarbeitung des Suchbefehls. 

Für den Export, den SRCH evtl. vornehmen soll, ist es freilich noch etwas anders: dafür steht im normalen Arbeitsspeicher der unveränderte Satz (also mit #40`_123). Es kann ja sein, daß man genau so und nicht anders exportieren will. Wenn man will, daß die Nummern durch Klartexte ersetzt werden, braucht man nur in der Export-Parameterdatei den Befehl i4=0 unterzubringen, das ist alles - Nachladen erübrigt sich. Oder i4=4, dann stehen Nummer und Name für den Export zur Verfügung. Der Wert i4 kann also für den Export anders aussehen als in der Index-Parameterdatei! Alle älteren Exporte funktionieren unverändert, denn sie enthalten keinen Befehl i4. 

UPDATE
Das Programm UPDATE verfügt ab V14 für die Behandlung der Verknüpfungen über dieselben Funktionen wie PRESTO. Wie oben erwähnt, kann der Ersetzungsschlüssel zugleich als Primärschlüssel dienen. UPDATE vergleicht ihn nur bis zum Zeichen '=' mit den vorhandenen Schlüsseln. Wenn also ein korrigierter Stammsatz geliefert wird, in dem die Ansetzungsform verändert wurde, kann UPDATE ihn erstens richtig zuordnen und zweitens die nötigen Veränderungen im betroffenen Register und evtl. in der Kurzanzeige vornehmen. 

Die auf PRESTO beruhenden Programme ALFA, APAC, MENUED etc. enthalten ebenfalls die neuen Funktionen. 
Noch zwei Kleinigkeiten: 
•	Wenn man bei PRESTO mit F5 auf Kategorieanzeige umschaltet, sieht man hinter allen Identnummern die Klartexte (so ähnlich wie beim Pica-System). Für den Katalogisierer ist das eine sehr wichtige Hilfe. Wenn man allerdings mit 'E' in die Bearbeitung geht, sieht man nur noch die Identnummern (anders als bei Pica, wo die Klartexte in Rot dahinter stehen.) 
•	Ein Druck auf ':' führt in der Titel- oder Kategorieanzeige die Ersetzungen durch, die sich durch die Angabe i4 in der Index-Parameterdatei ergeben. Das ist noch eine Kontrollmöglichkeit: man sieht auf diese Weise, wie der Datensatz aussieht, bevor die Indexparameter abgearbeitet werden. Bei F7 wird das alles automatisch ausgeführt (so daß man gleich die richtigen Schlüssel sieht), die Ersetzungen aber im Arbeitsspeicher sofort rückgängig gemacht. 

10.2.6.9  Satzübergreifende Suche : Das "Schiller-Räuber"-Problem

Seit es die verknüpften Sätze für mehrbändige Werke gibt (1993, V11.2), ist immer wieder einmal ein Disput über das "Schiller-Räuber-Problem" aufgeflammt. Dabei handelt es sich nicht um ein allegro-spezifisches Problem, sondern alle bekannten Systeme kranken daran (außer MARC-Systemen, weil sie keine Satzverknüpfungen kennen). Keine ganz geringe Herausforderung also, und es war lange Zeit unklar, wie dieses Problem am besten anzupacken wäre. Schließlich und endlich wurde für allegro eine sinnvolle Lösung gefunden und realisiert. Die folgenden, zur Lösung hinführenden Gedanken sollen zunächst das Problemverständnis fördern und mit instruktiven Beispielen den Lösungsweg begründen. 

Was ist überhaupt das Schiller-Räuber-Problem?
Wenn ein mehrteiliges Werk "Schillers Dramen" heißt, der Name "Schiller" aber nur im Hauptsatz und der Titel "Räuber" in einem verknüpften Untersatz steht, kann man nichts finden mit einer logischen UND-Verknüpfung zwischen  schiller  und  raeuber . 
Warum nicht? Zur Bildung von Ergebnismengen (und das gilt nicht nur für allegro) werden aus dem Index nur die Satznummern entnommen und verglichen, die beiden Suchwörter stehen aber in getrennten Sätzen. Das logische UND sieht also zwei ungleiche Nummern und erfaßt sie deshalb nicht. 
Eine gängige Abhilfe besteht darin, den Namen des Verfassers auch in jeden Untersatz mit einzutragen. Das erzeugt erstens unerwünschte Redundanz, löst aber zweitens nur einen Teil der Probleme dieses Typs, denn auch für andere Suchbegriffe, nicht nur für Verfasser, wird u.U. eine satzübergreifende Suche gewünscht oder stillschweigend erwartet, z.B. für Schlagwörter. 
    Hier ein anderes Beispiel, damit es noch deutlicher wird (nicht erfunden, dieses Werk gibt es!) 
Wir lassen alles weg, was mit dem Problem nichts zu tun hat. 

_________________________________________________________________________ 

Hauptsatz:    Vollmer, Gerhard: 
Nr.A          Was können wir wissen? 
              Schlagwort: Erkenntnistheorie 
_________________________________________________________________________ 

Untersatz:    Band 1 
Nr.B          Die Natur der Erkenntnis : Beiträge zur Evolutionären 
              Erkenntnistheorie. 
              Mitverf.: Lorenz, Konrad. 
_________________________________________________________________________ 

Untersatz:    Band 2 
Nr.C          Die Erkenntnis der Natur : Beiträge zur modernen 
              Naturphilosophie. 
              Schlagwort: Naturphilosophie 

Zur Erklärung: 
Die Nummern A, B und C sollen die internen Satznummern der drei Datensätze sein, nicht die Primärschlüssel. Die Ergebnismengen werden stets aus diesen Nummern gebildet, nicht aus Bestandteilen der Datensätze! Man könnte also z.B. haben:  A=13245, B=144923, C=55921. Das Programm vergibt sie beim Speichern selbst und man kann sie nicht verändern, daher haben diese Nummern keinen logischen Zusammenhang, und daher kann das Programm von sich aus nicht erkennen, daß ein Zusammenhang zwischen den Sätzen besteht. Aber, wie gesagt, beim Bilden von Ergebnismengen hat das Programm nur diese Nummern und sonst nichts, es schaut dabei nicht in die Sätze hinein (das würde viel zuviel Zeit kosten). Man muß also einen Weg finden, den Zusammenhang auch für das Programm erkennbar zu machen - das ist der programmiertechnische Kern des Problems. 

Übliche Retrievalsysteme erbringen in der Regel folgende Resultate, manchmal eben weniger als erwünscht: 
(Der Leser überlege für sich selbst, was wohl sinnvoll ist. Wir geben hier bewußt ziemlich viele Beispiele, damit deutlich wird, daß nicht jedes denkbare Ergebnis unbedingt erwünscht ist.) 

    Suchfrage:                       Resultat:       erwünscht: 
--------------------------------------------------------------- 

1.  vollmer                          A               A,B,C   ??? 

2.  wissen                           A               A,B,C   ??? 

3.  erkenntnis                       B,C 

4a. erkenntnis?                      A,B,C 
4b. naturphilosophie                 C               A,C     ??? 
4c. erkenntnisth? AND naturphil?     nichts          C 

5.  vollmer AND wissen               A               A,B,C   ??? 

6.  wissen AND natur                 nichts          B,C     ??? 

7.  vollmer AND natur                nichts          B,C   
    (entspricht schiller-raeuber) 

8.  vollmer AND naturphilosophie     nichts          C 
    vollmer AND lorenz               nichts          B 

9.  lorenz AND erkenntnis            B 

10. lorenz AND wissen                nichts          B       ??? 

(Die Suchfragen sind hier vereinfacht dargestellt. Von der Sache her spielt es keine Rolle, ob die Begriffe in verschiedenen Registern stehen oder im selben. Je nach Syntax des Systems sieht der eigentliche Befehl anders aus, bei a99/alcarta ist es wie bei Pica: 
"find per vollmer? and tit natur".  Das '?' ist auch bei Pica das Trunkierungssymbol.)
In den Fällen 1, 2, 4b, 5, 6 und 10 kann man wohl nicht generell sagen, daß die erweiterten Ergebnisse in jedem Fall erwünscht sind, sicher trifft das nur für die Fälle 4c, 7 und 8 zu. Es gibt natürlich keinen Algorithmus, der den tatsächlichen Wunsch erschließen kann und in jedem Fall korrekt eine erweiterte Suche (satzübergreifende Suche) durchführt oder nicht. Folglich wird man dem Benutzer auf irgendeine Art eine neue Option "erweiterte Suche"  oder "Expansion" zur Wahl stellen müssen und ihm die Sache hinreichend erklären. 
Das eigentliche Problem tritt nur bei den UND-Verknüpfungen auf. Die Fälle 1 bis 3 gehören nicht zum Problembereich. Wenn A gefunden wird, hat man implizit auch B und C, da diese dann ohnehin mit angezeigt werden können. Die nachfolgend skizzierte Lösungsidee wird zwar auch die logische NICHT-Verknüpfung mit einbeziehen (siehe unten Beispiele 5,6,10), aber der Leser mag sich selbst überlegen, wie sinnvoll das ist. 

Abstrakte Lösungsidee
Es wird ein Steuerzeichen eingeführt, und zwar '&'. Dieses kann vor jeden Suchbegriff einer kombinierten Suche gesetzt werden. 
Also z.B.   &vollmer   statt   vollmer. 
Ein so gekennzeichneter Begriff soll "erweitert" (satzübergreifend)  gesucht werden. (Man könnte auch von einer "Plus-Suche" sprechen.) Das bedeutet: alle Untersätze werden zu den Ergebnissen hinzugenommen. (Nur die UNTERsätze, nicht die ÜBERgeordneten!) Dann würde also im Beispiel  &vollmer   A,B,C  herauskommen statt nur schlicht  A. Mit  &lorenz  würde aber unverändert nur B herauskommen. Das erscheint sinnvoll, denn Vollmer hat viel mit B und C zu tun, Lorenz dagegen nicht viel mit A und womöglich gar nichts mit C. Diese Überlegung trifft wohl auch für andere Suchkriterien zu, denn schließlich erfaßt man ja ganz bewußt im Hauptsatz diejenigen Elemente, die auf das Gesamtwerk  zutreffen (also AUCH auf die Untersätze), in den Untersätzen aber diejenigen, die NUR für den jeweiligen Untersatz gelten.
Also nochmal ganz klar: die "erweiterte Suche" bezieht zu jedem Datensatz alle untergeordneten Sätze mit ein, und dies muß auf jeden Term einer kombinierten Suche einzeln anwendbar sein, sonst können durchaus unerwünschte Ergebnisse entstehen. 

Die nachfolgenden Beispiele sind nicht alle sinnvoll, d.h. man würde sie in der Praxis nicht alle anwenden. Das heißt, es wäre wohl nicht zu empfehlen, die Erweiterung grundsätzlich dauerhaft einzuschalten, also als ob automatisch vor jedes Suchwort ein '&' gesetzt würde. Es sollte aber einen "Hauptschalter" geben, der genau dieses bewirkt, wenn es gewünscht wird. 

    Suchfrage:                       Ergebnisse: 
------------------------------------------------ 
1.  vollmer                          A          
    &vollmer                         A,B,C 

2   wissen                           A 
    &wissen                          A,B,C 

3.  erkenntnis                       B,C 
    &erkenntnis                      B,C 

4.  erkenntnis?                      A,B,C 
    &erkenntnis?                     A,B,C 
    erkenntnis? AND naturphil?       C 
    erkenntnisth? AND naturphil?     nichts 
    &erkenntnisth? AND &naturphil?   C 

5.  vollmer AND wissen               A 
    &vollmer AND wissen              A 
    vollmer AND &wissen              A 
    &vollmer AND &wissen             A,B,C 

    vollmer NOT wissen               nichts 
    &vollmer NOT wissen              B,C 
    &vollmer NOT &wissen             nichts 

6.  vollmer AND natur                nichts     
    &vollmer AND natur               B,C 
    vollmer AND &natur               nichts 
    &vollmer AND &natur              B,C 

    vollmer NOT natur                A 
    &vollmer NOT natur               A 

7.  wissen AND natur                 nichts     
    &wissen AND natur                B,C 
    wissen AND &natur                nichts 
    &wissen AND &natur               B,C 

8.  vollmer AND naturphilosophie     nichts 
    &vollmer AND naturphil?          C 
    vollmer and lorenz               nichts 
    &vollmer AND &lorenz             B 
    
9.  lorenz AND erkenntnis            B 
    &lorenz AND erkenntnis           B 
    lorenz AND &erkenntnis           B 
    &lorenz AND &erkenntnis          B 

10. lorenz AND wissen                nichts     
    &lorenz AND wissen               nichts 
    lorenz AND &wissen               B 
    &lorenz AND &wissen              B 

    lorenz NOT wissen                B 
    lorenz NOT &wissen               nichts 

Es wird hieraus deutlich, daß mit der "Plus-Suche" jede gewünschte Erweiterung des Zugriffs differenziert durchgeführt werden kann. Voraussetzung: man muß sich klar sein, was man will, und die Plus-Suche bewußt einsetzen. 
Ob dies verstanden und ausgenutzt werden wird und wie oft, das ist eine ganz andere Frage. Man kann auch die Meinung hören, daß die Booleschen Verknüpfungen insgesamt von kaum einem Endbenutzer verstanden werden, wie auch immer man sie verpackt... Andererseits kann man sicher sein, daß die Wünsche nicht verstummen, nachdem dieses Verfahren realisiert ist. Mindestens wird die Frage kommen, wie es denn ist, wenn einer der Beispielsätze, oder alle drei, noch einem anderen oder mehreren anderen Werken untergeordnet sind, und wenn es mehrere Hierarchiestufen gäbe... 
Wahr ist aber auch: je größer unsere Datenbanken werden, umso mehr brauchen wir differenzierte Suchmöglichkeiten, auch wenn sie dann nur verhältnismäßig selten zum Einsatz kommen. 

Was muß man parametrieren?

Zum Glück wenig. Es genügen ein paar für Kenner sehr einfache Maßnahmen in den Indexparametern. 

1. Neuer Befehl  i7

Mit dem neuen Befehl  i7  wird zum einen das Register festgelegt, wo die notwendigen Hilfsschlüssel anzusiedeln sind, zum andern wird damit dem System signalisiert, daß die Datenbank eine Plus-Suche gestattet. 

i7=k		Nummer des SR-Hilfsregisters  (1 <= k <= 11)   Empfehlung: k= 9 oder 10. 

2. SR-Hilfsschlüssel: neuer Manipulationsbefehl  X

Jeder Untersatz, der bei einer Plus-Suche auffindbar sein soll, muß einen oder mehrere zusätzliche Schlüssel bekommen. Ein solcher "SR-Hilfsschlüssel" muß aus dem Primärschlüssel eines anderen Satzes bestehen (i.d.R. ist das der Hauptsatz eines mehrbändigen Werkes). Es kann zu einem Untersatz mehr als einen Hilfsschlüssel geben, d.h. die Unterordnung unter zwei oder mehr Gesamtwerke kann adäquat berücksichtigt werden. 
Ein solcher Hilfsschlüssel wird mit Hilfe des neuen Manipulationsbefehls X angelegt. Wie das geht, zeigen wir an einem 
Beispiel: Wir gehen vom Konsolidierten Format aus, wo der Primärschlüssel aus #00 gebildet wird und Untersätze in der #00 die IdNummer des Hauptsatzes mit angehängtem '+' enthalten. Die Primärschlüssel stehen im Register 9. Die Hilfsschlüssel sollen aber im Register 8 stehen. Es folgen die notwendigen Zeilen: 
(Eine reservierte Sprungmarke gibt es für diesen Zweck übrigens nicht.) 

i7=8				Die SR-Hilfsschlüssel sollen ins Register 8
... 
ak=zz+U			Für jeden Satz wird der Abschnitt #-U angesprungen ...
... 
#-U				... aber nur bei Untersätzen passiert hier wirklich etwas:
#00 +#00 c"+" e0	Kommt '+' vor, d.h. ist es ein Untersatz? 
#+-				wenn nicht, dann keine Aktion
#00 y0 e"+" X9	SR-Hilfsschlüssel aus Inhalt von #00 per Reg. 9 bilden.
#+#				(Für Register 10 muß es  X:  heißen; dann aber ':' aus Befehl i2 herausnehmen!)

Und was passiert dann? 

Das braucht man nicht unbedingt zu wissen, aber nützlich zum Verständnis dürfte es sein: 
Das Programm INDEX bildet zunächst nur einen temporären Schlüssel im Register 1. Wenn man z.B. #00 55555+17  in einem Untersatz hat, sieht der temporäre Schlüssel so aus: \|955555 (Mit F7 in PRESTO sieht man das). Im zweiten Durchlauf macht INDEX daraus den eigentlichen Hilfsschlüssel. Wenn der Hauptsatz (der mit dem Primärschlüssel 55555 im Register 9) die interne Nummer 123 hat, dann lautet der SR-Hilfsschlüssel  |123  und steht im Register 8. Das besagt also: der Untersatz gehört zum Satz mit der internen Nummer 123. 
Die Hilfsschlüssel dürfen auch im selben Register stehen wie die Primärschlüssel. 

Wenn die Plus-Suche dann ausgelöst wird, spielt sich folgendes ab: 
Das Programm nimmt sich die aktuelle Ergebnismenge vor. Diese besteht für das Programm immer nur aus einer Liste von internen Satznummern. (Wohlgemerkt: nur diese sind in dem Moment greifbar, nicht die Primärschlüssel.) Für jede dieser Nummern wird im Register i7 (im Beispiel also Register 8) nachgesehen, ob es Hilfseinträge unter dieser Nummer gibt. Wenn ja, werden die zugehörigen internen Nummern zur Ergebnismenge hinzugenommen. 

Daraus ergibt sich: die Plus-Suche muß auf einen Suchbegriff angewendet werden, bevor die logische UND-Verknüpfung ausgeführt wird. Nochmals: was ist dafür zu tun? 

In PRESTO und APAC kann jeweils nur die zum ersten Suchbegriff gehörige Ergebnismenge erweitern. In den Beispielen entspricht das dem Fall &vollmer AND natur, also genau dem originalen Schiller-Räuber-Problem. 
Man bilde also zuerst die Ergebnismenge zu demjenigen Begriff, der tatsächlich erweitert werden soll (d.h. der möglicherweise in einem Hauptsatz vorkommt, z.B. schiller oder vollmer). Danach Plus-Suche auslösen: 
In PRESTO wird '&' gedrückt (auf dem Registerbildschirm). 
In APAC ist dafür auf dem ESC-Menü die neue Funktion "Verknüpfungen`berücksichtigen"  zu finden. 
Die Ergebnismenge wird dann etwas größer, aber nur, wenn es zu mindestens einem der Sätze verknüpfte Untersätze gibt, für die ein SR-Hilfsschlüssel gebildet wurde. Nun führt man normal die Verknüpfung mit dem zweiten Begriff aus (also raeuber bzw. natur). 

Hauptschalter
Für PRESTO und APAC gibt es auch einen "Hauptschalter": wenn mit der neuen Option  -+  gestartet wird, ist die Plus-Suche fest eingeschaltet. Man überlege, ob dann nicht in vielen Fällen zuviel kommt. 

Oberflächenfragen
Ein paar Worte noch zur Präsentation an der Benutzeroberfläche. In der Praxis würde man natürlich nicht vom Endbenutzer verlangen, ein '&' vor jeden zu erweiternden Begriff zu setzen. Das wäre archaisch! Man würde in einer Web-Suchmaske zu jedem Suchbegriff einen Schalter setzen, der die Erweiterung für diesen Begriff einschalten würde. Wie für die Restriktionen gilt auch hier: innerhalb der Programme PRESTO und APAC ist eine wirklich benutzerfreundliche, also glasklar verständliche, Implementierung nicht möglich. 
In der avanti-Sprache braucht man jedenfalls nur das '&' vor jeden Begriff zu setzen, der satzübergreifend gesucht werden soll (siehe oben unter "Abstrakte Lösungsidee"). Anders als bei PRESTO/APAC kann dies jeder der verknüpften Suchbegriffe sein. 
Beispiele: (s.o. die Beispiele 5 und 8) 
		find per &vollmer? and tit &wissen 
		find per &vollmer? and &lorenz?
Dasselbe gilt für die Suchbefehle in a99/alcarta. 
Die korrekte Behandlung der Indexparameter für die Hilfsschlüssel ist in die Programme PRESTO, MENUED, ALFA, INDEX und UPDATE (schon seit V15.0) eingebaut, desgleichen in den avanti-Server und in die Windows-Programme. 

Drücken Sie auf den Fernglas-Button, dann sehen Sie, wie die Funktion in die Programme a99 und alcarta eingebaut ist: Das Kästchen "Mit Expansion" ist automatisch immer angekreuzt, WENN es SR-Schlüssel gibt. Wer ohne Expansion suchen will, muß es dann also abschalten. 

`Vorangehender Teil`   /   `Fortsetzung` 

?Vorangehender Teil=h ac10-9 
?Fortsetzung=h ac10-11