allegro-C BlueChyp V27.2 |
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 |