allegro-Homepagehttp://www.allegro-c.de allegro-C
BlueChyp
V27.2
BlueChyp
Neuer- und Verbesserungen

7. Mai 2007







Mehr zu den Themen:


 

 

 allegro-C

MultiX  für  GigaBanken

 Mehrere Indexdateien statt nur einer

ab V27.2

 

Vor V25.5 ist es so gewesen: Jede Datenbank hat eine, aber nur eine Indexdatei. Diese kann bis zu 11 separate Register besitzen, mehr jedoch nicht. Man kann mit den Windows-Programmen und mit avanti die 11 physischen Register in bis zu 100 logische Abteilungen zerlegen (bis V30: 50), denen man beliebige (aber immer dreibuchstabige) symbolische Namen zuteilt. Zum Beispiel DIS für die Abteilung im Register 1, deren Einträge mit D und Leerzeichen beginnen:

I DIS 1D. "Dissertationen: Ort,Jahr"

Mit a99 und avanti kann man seit  V26.6  in den logischen Registern so blättern als seien es physische, d.h. man sieht es ihnen nicht an, weil das Präfix dann nicht zu sehen ist. Im Indexfenster, oben in der Dropdown-Liste, findet man zur Auswahl neben den numerierten (physischen) Registern auch die Namen der symbolischen.

 

Damit kommt man zwar sehr weit, es gab aber bislang eine unüberschreitbare Grenze: die gesamte Indexdatei konnte als Datei nur bis zu zwei Gigabyte groß werden. Das ist nicht eben wenig! Erstmals erreicht wurde diese Grenze mit der alten VK-Datenbank, als versucht wurde, deren 15 Mio. Sätze zusätzlich zu allem anderen auch noch mittels Phrasentechnik zu indexieren.

Hoher Platzbedarf im Index ergibt sich vor allem aus folgenden fünf Anforderungen:

 

1.       Phrasenindexierung, wie schon genannt

2.       Zusätzlicher ALL-Index (sämtliche Wörter fast aller Datenfelder)

3.       Linkstrunkierungs-Index  (alle Teilwörter enthaltend, die durch Abschneiden von links her entstehen)

4.       Indexierung von Abstracts oder anderen Textpassagen

5.       Besondere Register mit sehr langen Einträgen, z.B. als eine Art zusätzliche Kurztitelliste oder bei der sog. Register-Maskerade, bei der jeder Eintrag aus zwei Teilen besteht: dem Sortierteil und dahinter dem Anzeigeteil.

 

Da nun einmal bibliothekarische Datenbanken zu unablässigem Wachstum neigen und außerdem die Erwartungen gleichfalls wachsen, was man denn wie abfragen oder präsentieren können sollte, sind die 2 GB keine gar so astronomische Zahl mehr. Wenn man bedenkt, daß heute bereits die billigsten Aldi-PCs mit wenigstens 80 GB Plattenspeicher daherkommen, fände auch niemand etwas dabei, wenn die Indexdatei 10 GB beanspruchte - wenn sie das denn könnte. Die vermeintlich großzügige Grenze wird also zu einer durchaus ärgerlichen Schranke. Datenbanken, die an dieser Barriere bisher gescheitert wären, nennen wir GigaBanken, der Betreiber einer solchen heißt GigaBanker.

 

Die 2 GB sind nur leider aus Granit. Eine Art "Aufbohrung", wie sie ja für die Gesamtzahl der Sätze gelungen war, konnte aus technischen Gründen nicht gelingen. Als Ausweg aus dem Dilemma bot sich aber an: Statt nur einer Indexdatei könnte man mehrere ermöglichen. Der Weg zur Umsetzung dieser Idee wurde schon auf dem Expertentreffen 2005 skizziert, doch erst auf dem Treffen 2007 konnte mit V27.2 die fertige Lösung freigegeben werden.

 

Am  Ende dieses Textes  findet der eilige Leser die zwei häufigsten Szenarien beschrieben und ganz knapp die wenigen Handgriffe, die dabei zu erledigen sind. Hier folgt zunächst noch eine detaillierte Beschreibung des Konzepts für neugierige Experten.

 

"Transparenz"

Schon immer konnte der Endnutzer nicht erkennen, ob die Register alle in einer Datei stehen oder in mehreren! Der OPAC-Nutzer bemerkt deshalb von der Erweiterung nichts. Es gibt keine zusätzlichen Buttons oder Menüpunkte, sondern nur vielleicht einen neuen symbolischen Registernamen, wenn ein neues Register hinzukommt. Der Endnutzer drückt nur auf die Knöpfe und das System öffnet die richtigen Dateien. Man könnte im Extremfall jedem Register eine eigene Datei geben. Empfohlen wird das aus Gründen der Leistung beim Speichern neuer Sätze zwar nicht, doch bei der Katalogbenutzung würde man davon nichts merken.

 

Einfachheit der Einrichtung

Ganz ohne zusätzliches Wissen und Tun kommt der Systemverwalter zwar nicht aus, aber der Aufwand ist minimal.

Für den Einrichter sieht die Lösung auf den ersten Blick so aus: Es gibt nicht mehr nur die eine Indexdatei cat.adx, sondern es können weitere hinzukommen, deren Namen dann  cat.azx lauten müssen. Für z kann man jeden Buchstaben und auch jede Ziffer einsetzen mit Ausnahme von d, denn die cat.adx gibt es ja schon. Zwischen Groß- und Kleinbuchstaben kann jedoch nicht unterschieden werden. Damit ergibt sich eine theoretische Gesamtzahl von 36 Indexdateien. Mit potentiellen 72 GB sollte nun jeder Anwender für eine lange Weile wieder ruhig schlafen können!

Empfohlen wird jedoch, nicht gleich 10 oder mehr Indexdateien anzulegen, sondern sich erst einmal mit einer weiteren zu begnügen, in die man nichts weiter als das umfangreichste Register verlagert, um die alte Indexdatei zu entlasten. Jede der weiteren Indexdateien kann auch wiederum 11 Register umfassen. (Man sieht, wie sinnvoll die Unterscheidung der Begriffe "Index" und "Register" ist.)

 

Der bisherige Index, z.B. cat.adx, bleibt bestehen und wird Primärindex genannt. An seiner Parametrierung braucht man nichts zu ändern. Er behält unter den Indexdateien eine Vorrangstellung, siehe unten Punkt 7.

 

Für die weiteren Indexdateien wird keine zusätzliche Parameterdatei angelegt, die Schlüssel werden vielmehr alle in die bisherigen Parameter zusätzlich eingebaut.

 

Oft wird es ja so sein, daß man bestimmte Schlüssel nicht mehr im Primärindex haben will, sondern in einem anderen - aus welchen Gründen auch immer, es müssen nicht unbedingt Platzgründe sein. Das ist leicht zu erreichen:

 

1. Indexparameter

Als Indexpräfix setzt man statt "|1" den Wert "~z1", wenn ein Schlüssel nicht in den Primärindex soll, sondern in das Reg. 1 der Indexdatei z.

Hinweis: "~d1" statt "|1" funktioniert nicht.

 

2. Indexproduktion

INDEX.EXE und QRIX.EXE sind darauf eingerichtet, die neuartigen Indexpräfixe korrekt zu verarbeiten, also die Dateien cat.adx und eventuelle cat.azx im selben Durchlauf zu erzeugen. Man braucht dazu keine besondere Option zu setzen noch sonst irgendetwas zu tun.

Selektiv indexieren: Will man z.B. nur die Indexdatei  cat.aex  neu erzeugen, startet man  index.exe  mit den Optionen 

-fi0 -Ze -@2 .

Der Befehl, um der Demo-Datenbank den Index e hinzuzufügen, sieht so aus:

index -fi0 -Ze -@2 -n0 -m0 -ka -d*DEMO2\CAT_* -eCAT/c:\ALLEGRO\DEMO2

(Zu starten auf c:\allegro in der Standard-Installation, nachdem man den unten im Beispiel gezeigten Abschnitt eingebaut hat in cat.api).

Hinweis: Bisher hat das Programm INDEX.EXE die Indexdatei unmittelbar selber hergestellt, wenn es sich um eine kleine Datenmenge handelte und deshalb nur eine Zwischendatei ii1 entstanden wäre. Das war Luxus und nur auf den ganz frühen, sehr langsamen PCs brachte es einen geringen Zeitgewinn. Jetzt wird in jedem Fall diese Zwischendatei erstellt und stets durch QRIX.EXE die Indexdatei angefertigt. INDEX.EXE ist dadurch kleiner geworden, was sich positiv auf die Anzahl der Zwischendateien auswirkt, und dieser Effekt macht sich bei großen Datenmengen bemerkbar, was sehr viel sinnvoller ist.

 

3. Symbolische Register

Wenn man eine Indexdatei  cat.aex  hat und deren Register 1 soll die symbolische Bezeichnung WFR (Wortfragmente) haben, Register 2 soll PHR (Phrasenindex) heißen, so kann man in den Indexparametern schreiben:

I WFR e1 "Wortfragmente"

I PHR e2 "Phrasenindex"

Wenn der Buchstabe fehlt, gilt d (für .adx) - also der bisherige Standard.

Mehr als 100 logische Register kann es insgesamt auch weiterhin nicht geben (bis V30: 50). Mehr als drei zusätzliche Indexdateien mit je 11 Registern wären also derzeit nicht sinnvoll, man könnte aber durchaus mehr Indexdateien mit nur je einem oder zwei Registern machen, was aus Effizienzgründen aber nicht ratsam ist.

 

4. Zuordnung der 10 Registerbuttons

Die 10 Buttons des Indexfensters sind im Normalfall den Registern der primären Indexdatei zugeordnet. Man kann aber jeden Button auch einer anderen Indexdatei zuordnen. Das geschieht mit dem neuen Befehl ix=...

Soll z.B. bei Druck auf Button 3 bzw. 5 nicht das Register 3 bzw. 5 der primären Indexdatei erscheinen, sondern jeweils dasjenige der e-Datei, so schreibt man in die Indexparameter:

ix=ddededddddd

Dies wurde deshalb so eingerichtet, damit man bei Bedarf jedes der numerierten Register in eine andere Indexdatei auslagern kann, ohne daß der Nutzer etwas merkt. Die Änderung der Indexparameter ist dann mininal:

-- wo bisher "|3" steht, schreibt man "~e3" ,

-- dann die ix-Zeile mit dem e an der dritten Position und

-- den Buchstaben e in die symbolischen Namen der Register einbauen (siehe 3.).

-- Dann Index erneuern - und das war's.

(Es würde, wenn's schnell gehen soll, genügen, zuerst einmal nur selektiv die Indexdatei e zu erstellen, siehe 2.) Wenn die primäre Datei dann immer noch andere Einträge in Reg. 3 bzw. 5 hat, kann man diese nur noch über symbolische Namen dieser Register erreichen.

 

Der Parameter ix wirkt sich auch aus auf die FLEX-Befehle find, qrix und index, wenn dabei ein Zugriff per |i gemacht wird statt über symbolische Register.

Die Überschriftszeilen für die Register 3 und 5, also die mit |3 und |5 beginnenden Zeilen in den Indexparametern, müssen nicht verändert werden, es sei denn man ändert etwas am Gehalt der betr. Register.

Hinweis: Das Indexpräfix eines Registers behält seine Bedeutung. Wenn man in den Indexparametern p"|3" schreibt, ist damit immer das Register 3 des Primärindex gemeint, mit p"~e3" immer das Reg. 3 des  e-Index. M.a.W.: ix hat hier keine Wirkung, sondern nur für die Nutzung.

Was man aber nicht machen kann: z.B. den Button 3 dem Register 5 einer anderen Indexdatei zuordnen.

 

Die manchmal so wichtige Umcodierung der Nutzereingabe passiert in jedem Fall z.B. bei der Sprungmarke

#-3, wenn ein Register 3 benutzt wird - egal welche Indexdatei es ist.

Allerdings gibt es eine neue Sondervariable #ax, in der der Buchstabe der aktuellen Indexdatei steht und an zweiter Stelle die Nummer des aktuellen Registers, also z.B. d4 oder e1. Damit hat man alle Möglichkeiten, die Nutzereingabe entsprechend zu behandeln.

 

5a. a99 / alcarta

Mit dem FLEX-Befehl  index sym abc  kann man den bei abc beginnenden Abschnitt des Registers sym anzeigen lassen, das gilt auch für die neuen Indexdateien, sobald man deren Registern symbolische Namen gegeben hat (wie in  3 gezeigt.)

Mit index |3 abc erhält man aber das Register 3 der Datei cat.aex, wenn man die oben gezeigte ix-Zeile angelegt hat. Dasselbe gilt für den Befehl qrix. Mit

index ~zi abc          bzw.        qrix ~zi abc  

kann man gezielt jedes einzelne Register i in jeder Indexdatei z ansprechen.

 

5b. a99, avanti, PHPAC

In beiden Programmen kann man mit find und qrix auf alle realen und symbolischen Register zugreifen.

Beide erzeugen beim Schreiben die korrekten Einträge in den richtigen Registerdateien bzw. löschen Einträge, wo es nötig ist.

Wenn man PHPAC als Web-Schnittstelle einsetzt, muß an den Skripten und Parametern nichts geändert werden, falls man zusätzliche Indexdateien anlegt.

 

6. PRESTO, APAC und UPDATE

Die DOS-Programme PRESTO und UPDATE werden gleichfalls mit den zusätzlichen Indexdateien fertig, d.h. PRESTO kann sie anzeigen und beide können die nötigen Veränderungen beim Speichern darin vornehmen. Wer will, kann also auch eine V27.2-Datenbank noch mit PRESTO benutzen - natürlich nur mit einer Ausführung ab V27.2.

Das Umschalten in PRESTO geht so: Im Registerbildschirm z.B.   ~e4 Enter  eingeben, um in die Indexdatei  cat.aex  zu schalten. Es erscheint deren Register 4, und zwar an der entsprechenden Stelle. Hat man eine ix-Zeile, wie oben in 4. gezeigt, wird auch in PRESTO und APAC mit Alt+3 bzw. Alt+5 auf die Register des Index e umgeschaltet.

Ganz so komfortabel wie in a99 ist dies nicht, da man im Bedarfsfall um die Existenz der zusätzlichen Indexdateien und ihrer Register wissen muß - PRESTO kennt weiterhin keine symbolischen Register. Jedoch wird man kaum weiterhin alle Arbeiten nur mit PRESTO machen wollen...

 

7. Wichtige Hinweise

Die sekundären Indexdateien sind nicht in jeder Hinsicht dem Hauptindex gleichwertig:

1. Die Primär-, Löschkontroll- und SR-Schlüssel müssen alle im Hauptindex liegen

2. Das Nachladen beim Export und die V14-Ersetzungen können nur aus dem Hauptindex erfolgen

3. Die Präfixtechnik ermöglicht schon lange, daß man dem Nutzer weit mehr als 10 symbolische Register anbieten kann! Hier liegt also kein Grund, eine zusätzliche Indexdatei anzulegen. Auch in der zusätzlichen Indexdatei kann man jedoch Präfixe verwenden!

 

Mögliche Vorteile

·       Zu empfehlen ist, eine zusätzliche Indexdatei hauptsächlich als Entlastung des Hauptindex zu verstehen, damit dieser die 2GB nicht überschreitet.

·       Bequem ist ein zusätzlicher Index auch dann, wenn er nur temporär gebraucht wird. Irgendwann löscht man den Zusatzindex und den/die ak-Befehle sowie den ix-Befehl in den Indexparametern - fertig.

·       Günstig kann es auch sein, wenn man möglicherweise öfter zu erneuernde Register in einen Zusatzindex legt. Diesen kann man selektiv erneuert, siehe 2., was bei großen Sub-Giga-Datenbanken schon ein Zeitvorteil sein kann.

·       Der Zusatzindex kann außerdem dazu diesen, dienstliche Register anzulegen, d eiein Nutzer auf keinen Fall sehen soll (falls man fürchtet, das Reg. 11 des Primärindex zu überfrachten). Auch in diesem Fall wird man wohl kaum mehr als eine zusätzliche Indexdatei anlegen müssen. Je mehr Indexdateien, das ist klar, umso langsamer ist das Speichern neuer Sätze.

Sonstige echte Vorteile gibt es nicht.

 

 

Anhang : Die zwei häufigsten Szenarien

... und die wenigen Handgriffe, die dazu nötig sind

Die unten gezeigten INDEX-Aufrufe kann man normalerweise automatisch erledigen lassen: Der Menüpunkt

  Index erneuern  

auf dem ORG-Menü wurde dafür erweitert! Es kommt ein Zwischenmenü mit der Auswahl, ob man eine Gesamt-Neuindexierung möchte (die bisherige Funktion) oder gezielt die Erstellung einer der zusätzlichen Indexdateien,

 

Szenario 1. Einzelne Register auslagern

Beispiel: Man will das Reg. 3 (Stich- und Schlagwörter) des Standardsystems in eine Indexdatei cat.aex auslagern.

·         In die Indexparameter diese Zeile einfügen:

      ix=ddedddddddd

·         Das symbolische Register TIT so ändern:

            I TIT e3 "Titelwörter, Schlagwörter"    [also e3 statt 3 ]

·         An den Stellen, wo bisher |3 steht, dafür ~e3 einsetzen, außer in der Überschriftszeile, die mit |3= beginnt.

Ist das geschehen, Index erneuern. Anschließend hat man einen kleineren CAT.ADX und einen neuen CAT.AEX. Ansonsten ist nichts zu ändern, weder in in Parametern noch z.B. in FLEXen.

Wenn die Datenbank sehr groß ist, kann es schneller gehen, keine Index-Gesamterneuerung zu machen, sondern

1. Selektiv den Index cat.aex zu erstellen:

            index -fi0 -Ze -@2 -n0 -m0 -ka -d*DEMO2\CAT_* -eCAT/c:\ALLEGRO\DEMO2

2. ... und dann das Register 3 aus dem Index cat.adx zu entfernen:

            qrix -fc -W3 -dDEMO2 -eCAT/c:\ALLEGRO\DEMO2

 

Szenario 2. Ein ganz neues Register schaffen und in eine Indexdatei cat.axx packen

Das neue Register soll Wortfragmente der Titelwörter enthalten. Anders gesagt: ein Linkstrunkierungs-Index. So könnte das aussehen:

 

ak=20"[ -]"+ô     #20 bei Spatium und - auseinandernehmen

...

#-ô

#u1 y2 =u9 e0

#-ò

!uu9 y0 u>> p{ 8 "~x1" }

#uu9 +ò y0 b1 =u9   Schleife: immer vorn ein Zeichen wegnehmen

#+#

Hier ist angenommen, daß man eine zweite Stoppwortliste  eingebaut hat, die mit  u>> geprüft wird. Eintragung im Register 1 der zusätzlichen Indexdatei  cat.axx  erfolgt dann nur, wenn das Wort nicht in jener Liste steht. (Der Code 8 wird hier gebraucht, wie auch sonst, um die in der Schleife entstehenden Einträge voneinander zu trennen.)

Außerdem wird nur noch eine weitere Zeile gebraucht:

 

I WFR x1 "Wortfragmente der Titelwörter"

 

Anschließend braucht man den Index cat.adx nicht zu erneuern, sondern nur den neuen zu erstellen - das geht schneller. Man macht das mit diesem Befehl:

 

INDEX -fi0 -@2 -Ze -ka -d*c:\ALLEGRO\demo2\cat_* -ecat/c:\ALLEGRO\demo2

 

In PRESTO kann man dieses Register dann nur erreichen, wenn man im Indexfenster  ~x1  eingibt.

In a99 erscheint WFR in der Liste der symbolischen Register (Auswahlliste oben im Indexfenster).

 

Tip: Auf der Seite "Datenbank-Information" sieht man unten die Liste der symbolischen Register. Dort erkennt man auch, welche zusätzlichen Indexdateien in den Parametern eingerichtet sind. Wenn da z,B. diese Zeile steht:

PHR f1=Phrasen

dann weiß man: Es ist eine zusätzliche Indexdatei cat.afx  definiert.

 

2007-03-28

 

 

 

 

 


http://www.allegro-c.de/bluechyp/



Bernhard Eversberg, UB Braunschweig 2007-05-03