allegro news

Nr. 58

"Aufklärung ist der Ausgang des Menschen aus seiner selbstverschuldeten Unmündigkeit."
Aus der Schulzeit kennt wohl jeder diesen Satz, der Immanuel Kants Schrift "Was ist Aufklärung?" einleitet. Die Aufklärung wurde spätestens mit der Französischen Revolution unumkehrbar, d.h. vor 211 Jahren. Selbst Kant ist also mittlerweile doch reichlich grau vom Staub der Jahrhunderte - oder vielleicht doch nicht? Ruft man besagte Schrift von gutenberg.aol.de ab und liest nur die erste Seite, wird man schonungslos eines anderen belehrt. Zwar spielen Kants Ausführungen an vielen Stellen auf die vom Großen Friedrich gewährte Meinungs- und Religionsfreiheit an und preisen die Weisheit dieses Monarchen. Die Einleitung aber ist überall dort und unverändert noch heute gültig, wo Menschen die Freiheit des Geistes noch nicht erlangt oder wieder verloren haben. Oder den Verlust gar nicht bemerken (wollen) ...

"In the future we will treat users just like computers - they are both programmable." soll Bill Gates gesagt haben. Das lassen Sie dem Mann durchgehen? Denken Sie daran, wenn Sie das nächste Mal mit der Maus auf [OK] klicken, denn das müssen Sie gar nicht, Sie können auch die Hand an der Tastatur lassen und Enter drücken. Das wäre der kleinste mögliche Protest gegen die Point-and-Click-Mentalität, auf die fast alle Windows-Anwender schon programmiert sind. Millionen denken so, wie es die Programme aus der M$-Schmiede suggerieren; verborgen bleibt allzu oft, dass man mit Kanonen auf Mücken schießt oder überflüssigen (aber Zeit und Bandbreite kostenden) Firlefanz in Kauf nimmt. Doch ist das schon Unmündigkeit oder ist es nur der pragmatische Kompromiss, Nebeneffekt der im Interesse von Effizienz und Produktivität nun einmal notwendigen Konventionen und Standards? Gab es "Sachzwänge" nicht zu allen Zeiten, und muss nicht individuelle Freiheit immer Zugeständnisse an das Allgemeinwohl machen? Dazu Kant: "Satzungen und Formeln, diese mechanischen Werkzeuge eines vernünftigen Gebrauchs oder vielmehr Mißbrauchs seiner Naturgaben, sind die Fußschellen einer immerwährenden Unmündigkeit." Satzungen und Formeln - dazu gehören Konventionen, Normen und heute auch sogenannte Standardsoftware. Aus dieser Sicht der Dinge gehen wir längst über den kleinsten möglichen Protest weit hinaus, indem allegro-Datenbanken unverändert auch auf anderen Plattformen laufen können. In naher Zukunft soll ferner der avanti-Server, der Zugriffe aus anderen Umgebungen heraus ermöglicht, weiter verbessert werden. Neue Offenheit, neue Mündigkeit für Entwickler!

"Unmündigkeit ist das Unvermögen, sich seines Verstandes ohne Leitung eines anderen zu bedienen.", lautet Kants zweiter Satz in der zitierten Schrift. Fällt es schon in diese Rubrik, wenn man, zu reformiertem Schreiben gehalten, nicht mehr ohne ein Rechtschreibprüfprogramm auszukommen meint? Das meistgenutzte (laut Testberichten nicht das beste) dieser Programme kommt - Sie ahnen woher. Unversehens wird so für immer mehr Zeitgenossen der Mann aus Redmond indirekt zu einem jener "Vormünder, die die Oberaufsicht über sie gütigst auf sich genommen haben". (Nicht viel fehlt, und jede Schreibung gilt als akzeptabel, die in WinWord durchgeht.) Das mag indessen ein bloßes Randproblem in der Übergangszeit sein; die Reformer haben das sicher so nicht gewollt, sie handelten vielmehr in tiefem Verantwortungsbewusstsein für das Kulturgut "Schriftsprache": zu wertvoll ist dieses, als dass man die Hoheit darüber einem Parlament ausliefern dürfte. Hier muss vielmehr der Volksverstand sich der umsichtigen Leitung durch die Kultusministerkonferenz anvertrauen. Zudem will letztere mitnichten "das Volk" entmündigen, ihr Dekret bindet nur Schulen und Behörden. Alle anderen sind ausdrücklich frei, sich ihres eigenen Verstandes zu bedienen. Den Zwang zu einheitlicher Schreibung, eine jener "Fußschellen", hat also de facto nicht ein sich aufklärendes Volk selber abgestreift, sondern eine Obrigkeit hat ihn zum alten Eisen geworfen. Das grenzt an friderizianische Weisheit - jeder darf nach eigener Fasson kreativ werden, Nichtbeherrschung der Orthografie kann keine Chancen mehr zunichte machen, denn es gibt "die" Orthographie nicht mehr. Und allenthalben, selbst z.B. im SPIEGEL, kann man jetzt beobachten, wie die neue Freiheit frische, früher nie gesehene Fehlerblüten treibt: notwändig, Glaß, Preis geben, Aussage kräftig, zu nichte, mit Nichten, schlechtest gekleidetste, Gefahr drohend, am schwer wiegendsten, bein halten. Man ist versucht, Schiller umkehrend, den Reformern zuzurufen: "Eure Zauber teilen wieder, was Kultur einst streng geeint".

Genug davon, diese Blätter sind kein Organ für Kulturkritik - jeder bediene sich des eigenen Verstandes zum Weiterdenken, "Sapere aude!" nach Kant, nur Mut! Die Auswirkungen der Rechtschreibreform auf unsere Kataloge, das ist ein Thema, dem wir uns in unserem Umfeld zu stellen haben, wenn es auch vom öffentlichen Problembewusstsein so gut wie ignoriert wird. Eine Untersuchung fand schon vor zwei Jahren statt, die Resultate sind auf unserem Webserver nachzulesen. Es gab in der Folge auch ein paar Verbesserungen an den Standard-Indexparametern. Nicht alle Differenzen kann man abfangen, das muss gesagt werden; insbesondere die neuen Getrenntschreibungen ("nicht linear" statt "nichtlinear" etc.) werden Ärger machen. Einer Leitung durch den künstlichen "Verstand" kann man sich nicht bedienen, man muss noch mehr mitdenken als zuvor.

In Programmiersprachen ist es mit der Orthografie noch schlimmer als in natürlichen Sprachen. Fehlfunktionen bis hin zu Abstürzen kann der kleinste Verstoss nach sich ziehen. Auch die allegro-Exportsprache ist eine Programmiersprache. Abschaffen kann man sie nicht, aber die Notwendigkeit zurückdrängen, sie benutzen zu müssen. Das wurde bereits im DOS-System versucht (in den Paketen QUEX, QUANT, PRONTO). In a99/alcarta kann man jetzt gleichfalls Listen produzieren, ohne zu parametrieren, und zwar ganz besondere Listen, sog. Views, die neue Sichten auf Ergebnismengen gewähren (ab S.2).

Sogenannte Standard-Software kommt nicht nur von der Gates-Company. Eine neue Sicht des Gesamtsystems stellen wir vor in einer "Vergleichenden Gegenüberstellung" mit Relationalen Datenbanksystemen, die weithin als Standard gelten. Dadurch wird endlich die Kommunikation mit nichtbibliothekarischen Datenbänkern erleichtert, in deren Katechismus "SQL" steht. Als diese Übersicht im Web erschien, zeigten die Reaktionen bald: das ist willkommene Aufklärung (ab S. 10).

"Warschauer Paket"

Ergebnismengen können bislang nur mit Hilfe der Kurztiteldatei der Datenbank (.STL) betrachtet werden. In der Kurzanzeige sieht man zu jedem Satz die zugehörige Kurzzeile. Zum Ordnen der Ergebnismenge können in a99/alcarta nur diejenigen Kriterien verwendet werden, die in der Kurzzeile auftreten (oder mit Alt+s die interne Satznummer).

Nicht immer ist für einen konkreten Zweck die Kurzzeile gut geeignet, weil sie immer gleich aussieht (denn es gibt nur genau eine je Satz). Manchmal bräuchte man einen Überblick mit anderen Datenelementen, manchmal auch müsste man eine andere Ordnung herstellen können. Zum Beispiel sind die Kurzlisten bei einer bolero-Datenbank nach dem Einheitstitel geordnet, manchmal ist aber eine Übersicht nach Opusnummern erwünscht oder auch nach Interpreten, Dirigenten, Aufführungsjahren, Orchestern ... nichts davon steht aber in der Kurzliste.

Man hätte also gern geschmeidige Alternativen zur Standard-Kurzanzeige, um Ergebnismengen in einer dem Zweck angemessenen Form und Reihenfolge durchsehen oder auch exportieren zu können. Denn Datenbanken können viele unterschiedliche Satztypen enthalten und es können immer neue und neuartige Ansprüche über eine Datenbank hereinbrechen, z.B. wenn man Geschäftsgänge damit unterstützt oder betreibt.

Angedacht wurde schon einmal, dass es mehr als nur eine STL-Datei geben könnte. Zwar würde dies für eine Reduzierung gähnender Leerräume auf zeitgenössischen Festplatten sorgen, dennoch aber hätte man nur eine begrenzte Zahl von letztlich auch wieder voreingestellten und wenig anpassungsfreudigen Sichtweisen, weil man dazu gute Parametrierkenntnisse braucht und schnelle Änderungen selten machbar sind, im laufenden Betrieb überhaupt nicht.

Kurzum: die Sicht (engl. view) der Dinge, sprich der Ergebnismengen, sollte flexibel einstellbar sein und wenn irgend möglich ohne großes Insiderwissen kurzfristig, am besten ad-hoc neue An- und Einsichten eröffnen.  Schließlich ist die Datenbank kein Selbstzweck, sondern sie soll Früchte tragen.

Aus der Sicht des classico-Systems ist außerdem noch festzustellen:

Per CockPit können aus Ergebnismengen beliebig sortierte Listen erstellt werden (siehe Handbuch Kap. 6), doch wird dies trotz Vereinfachungen noch immer als relativ umständlich empfunden. Im Windows-System soll es mindestens soviel Flexibilität geben, aber man wünscht sich entscheidend weniger Parametrierarbeit und die Möglichkeit, die Vorgänge online durchzuführen und mit sofortiger Betrachtung der sortierten Liste, wahlweise jedoch auch mit einer Druck- oder Dateiausgabe in Listen- oder Tabellenform. Letztere könnte dann nebenbei unter Windows die "alten" CockPit-Funktionen der Listenproduktion ersetzen.

Aber wieso "Warschauer Paket"?

Um die genannten Ziele zu erreichen, ist das "View"-Konzept entwickelt worden. Weil die ersten Ideen schon vor einer Weile bei einem Arbeitsbesuch in der polnischen Hauptstadt skizziert wurden, kam für die heranreifende Sammlung von FLEXen, Parametern und Hilfedateien dieser eigenartige Codename auf.

Wir sprechen bei der fertigen Lösung nun aber im Klartext von "ViewListen":

Im Folgenden wird immer das englische Wort "View" statt des deutschen "Sicht" benutzt.

Unter derselben Bezeichnung gibt es etwas Ähnliches, aber grundsätzlich doch Anderes bei relationalen Datenbanken. Dort ist ein View ein zur Datenbankstruktur gehöriges Element, einzurichten vom Systemverwalter und dann permanent vorhanden, aber selten schnell realisierbar oder änderbar. Für allegro ist ein View eine temporäre Datei, erstellbar durch jeden Datenbankbenutzer, jederzeit und sofort. Die entwickelte Methodik ist einerseits sofort einsetzbar, ohne langes Vorstudium, andererseits kann man mit einschlägigen Kenntnissen, wie bei allegro üblich, für lokale Zwecke und kompliziertere Aufgaben beliebige Varianten und Verfeinerungen ausarbeiten. Das gilt für die Parameterdateien sowohl wie für die FLEXe.

Datentechnisch besteht eine ViewListe aus einer sehr einfachen Textdatei mit je einer Zeile für jeden Datensatz. Solche Dateien können leicht und schnell erstellt werden, auch außerhalb von a99/alcarta, z.B. mit PRESTO oder SRCH. Die View-Funktionen gibt es nur für a99/alcarta , nicht für die konventionellen Programme; es wurde dafür der neue FLEX-Befehl "View" eingerichtet.

Aber nicht nur Ergebnismengen können als "ViewListe" präsentiert und genutzt werden, auch Textlisten aller Art und beliebiger Größe: Auswahllisten für Codes oder Systematiken, Menülisten (wobei hinter jeder Zeile ein FLEX stecken kann). Und diese Listen können komfortabel durchsucht werden. Vielleicht wird die praktische Bedeutung dieser Sonderfunktion nicht geringer sein als die der Ergebnismengen-Nutzung.
 
 

Einzelteile des View-Konzepts [Hintergrundwissen für Allegrologen]

Nutzung der View-Technik setzt voraus, dass man auf dem Arbeitsverzeichnis Schreibrecht hat. Wenn in der INI-Datei kein Befehl DbAux=... steht (mit dem man das Arbeitsverzeichnis setzt), wird dasjenige genommen, das in der Environment-Variablen TEMP steht. Meistens ist dies c:\windows\temp. Dort kommen die temporären Dateien zu liegen, die nach Ende einer Sitzung ohne Weiteres gelöscht werden können. Die Parameterdateien (vom Typ v-*.cpr ), die man nicht selten später erneut gebrauchen kann, werden auf das Startverzeichnis geschrieben, desgleichen Exporte, was man durch Eingriff in die FLEXe aber ändern könnte.

Eine ViewListe hat die Extension .VW. Sie besteht aus Zeilen von exakt gleicher Länge (Auffüllung am Ende mit Leerzeichen!). Ist das beim Aufruf nicht gegeben, wird das Programm selbständig eine Kopie der Datei erstellen und darin alle Zeilen an der längsten ausrichten. Jede ViewListe kann aber ihre individuelle, passende Zeilenlänge haben.

So sieht, schematisch, ein Datensatz, d.h. also eine Zeile, in einer ViewListe aus:

00001234|TEXT                                        ^{13 10}

Die hochgestellten, unterstrichenen Zahlen 13 und 10 sind die üblichen ASCII-Steuercodes für die Zeilentrennung. Warum die feste Länge? Diese macht es viel schneller, die Anzeige dann erscheinen zu lassen und darin zu blättern, als wenn die Zeilen variabel wären. Bei Ergebnismengen von mehreren tausend Sätzen wirkt sich dies sehr spürbar aus. ViewListen sind in aller Regel temporär, daher kann man sich diese Ineffizienz leisten. (Übrigens: Hat eine ViewListe ausnahmsweise Zeilen unterschiedlicher Länge, merkt das Programm dies beim Einlesen und korrigiert es, d.h. die Datei wird entsprechend verändert; es dauert nur etwas länger, bis sie dann erscheint! Tip: Wenn man eine ViewListe von Hand anlegt, mache man die erste Zeile mindestens so lang wie die längste Zeile, dann geht das Einlesen am schnellsten.)

Der Inhalt eines View-Satzes ist zweiteilig: eine interne Satznummer (hier 8stellig mit führenden Nullen, das ist jedoch nicht verbindlich), und ein davon durch das Zeichen '|' getrennter TEXT, eine beliebige Zeichenkette. Diese besteht normalerweise aus Elementen des Datensatzes, dessen Nummer vorn steht, und zwar genau den Elementen, die man für einen bestimmten Zweck braucht. In der Regel wird dieser Text in sinnvoller Weise sortierbar sein, wobei die zum Sortieren dienenden Elemente vorn stehen müssen.

Erfreuliche Nebenwirkung: Jede Datei xyz, die so aussieht, kann mit dem FLEX-Befehl View xyzals ViewListe angezeigt werden, egal wie man sie erstellt hat! Im Extremfall ist es eine Textdatei ohne ein '|' oder mit jeweils "abc|" am Anfang jeder Zeile, wobei 'abc' nicht mit einer Ziffer beginnt. Die ViewListe wird angezeigt im Kurzanzeige-Fenster und erlaubt dann die Auswahl einer Zeile. Beginnt die Zeile mit einer Nummer größer als Null, wird der zugehörige Satz sofort angezeigt, wenn der Leuchtbalken darauf geht. Man hat hier nebenbei eine Alternative zum FLEX-Befehl "select", denn:

Anschließend (nach Druck auf [Enter]) steht die ausgewählte Zeile dann in der "internen Variablen". D.h. die Angabe "abc", im View nicht sichtbar, kann dann auch per FLEX ausgewertet werden! Kommt kein '|' vor, ist die ganze Zeile sichtbar.

Wie könnte nun der TEXT zusammengestellt werden? Vielleicht einfach so, dass man die gewünschten Kategorienummern angibt? Das mag in einfachen Fällen reichen und wird auch über ein Formular komfortabel gelöst, siehe unten (Seite 6), aber wenn die gesamte Bandbreite der potenziellen Wünsche abgedeckt werden soll, muss man vieles bedenken:

1. Nicht jedes Feld kommt jedesmal vor, manchmal wird statt eines fehlenden Feldes ersatzweise ein anderes an seine Stelle treten sollen. Das ist vor allem dann wichtig, wenn eine Ergebnismenge unterschiedliche Satztypen enthält.
2. Wenn die Datenbank mit V14-Ersetzungen arbeitet, möchte man Klartexte statt Stammsatznummern.
3. Manchmal wird man Teilfelder oder andere Bestandteile als Elemente brauchen, nicht den gesamten Feldtext.
4. Die Länge jedes am TEXT beteiligten Feldes muss begrenzbar sein.
5. Nichtsortierzeichen sollten sich berücksichtigen lassen.
6. Zeichenumcodierungen und Textersetzungen können nötig sein.
7. Zahlenwerte sollten aus Textfeldern herausgelöst oder auch aus mehreren Feldinhalten berechnet werden können.
8. Die Sortierung wird nicht immer unmittelbar durch den Inhalt eines Feldes definiert werden können, es muss vielmehr die Möglichkeit geben, einen veränderten und/oder zusammengesetzten Sortierschlüssel zu definieren. Korrekte Sortierung von Umlauten und Akzentbuchstaben wird man ebenfalls erwarten.
9. Es sollte möglich sein, die ViewListe in Gruppen einzuteilen, d.h. Zwischenüberschriften zu erzeugen.
10. Zahlen sollte man addieren und im Falle von Gruppierungen auch Zwischensummen bilden können.
11. Mehrfach besetzte Felder sollen evtl. mehrere Einträge in der Liste erzeugen.
12. Letzte, aber für viele Anwender vielleicht sogar wichtigste Wunschvorstellung: Eine ViewListe muss exportiert werden können, und zwar wahlweise die vollständigen Datensätze mit allen geeigneten Druckparametern oder die Liste als Tabelle, mit einem eindeutigen Trennzeichen zwischen den (ungekürzten) Datenfeldern, damit sie dann leicht in andere Programme übernommen werden kann (Textsysteme, Tabellen- und relationale Datenbanksysteme).

1. die TEXT-Zeilen sind unmittelbar sortierfähig. Dann kann die Liste direkt in der beschriebenen Form exportiert und dann sortiert werden, bevor man sie anzeigen lässt.
2. die TEXT-Zeilen sind nicht unmittelbar sortierfähig. Dann muss die Erstellung der ViewListe über einen Umweg laufen: es wird zuerst eine sortierbare Grunddatei mit zwei Kategorien je Satz erstellt. Die erste Kategorie, #u1, enthält den Sortierwert, die zweite, #u2, die anzuzeigende Zeile. Beide können in ihrer Form, aber auch im Inhalt, ganz verschieden sein. Nach dem Sortieren wird dann die #u1 ganz beseitigt und es bleibt die geordnete ViewListe übrig.

Eine ViewListe entsteht in beiden Fällen als Export einer Ergebnismenge mit Hilfe einer View-Parameterdatei, kurz ViP genannt, mit einem Namen der Form V-XYZ.APR, die immer denselben Aufbau hat. Den Teil mit den allgemeinen Exportparametern kann man für andere Kategoriesysteme einfach kopieren. Die speziellen, auf den jeweiligen Zweck bezogenen Angaben bilden einen Block, der jeweils für eine neue Aufgabe zu bearbeiten ist. Im classico-System entsprechen diesen Dateien die Parameterdateien S-*.APR zur Erstellung einer Sortierdatei. Es kann beliebig viele solche ViPs geben.

Das Erstellen von ViP-Dateien ist Sache des Systemverwalters, der dafür aber nur relativ wenige Parametrierkenntnisse braucht (es sei denn, man hat sehr diffizile Wünsche).

Das Anwenden der ViPs ist, wie das Anwenden der Sortierdateien im classico-System, ohne Parameterkenntnisse möglich, zumal wenn die Anwendung auch noch in FLEXe eingebettet wird. Als kommentierte Vorlage benutzt man die Datei V-STAND1.APR oder V-STAND2.APR (letztere mit Gruppierung und Summierung) oder eine andere vorhandene ViP.

Hier ein Beispiel:

In der Datei V-STAND2.APR (für den Standard-View 2 ) findet man in der Mitte diesen Abschnitt:

Will man für die ViewListe eine Spaltenanordnung, kann man das jeweils mit den Befehlen en sn erreichen, also z.B. e20 s20um die Länge des Abschnitts auf 20 Zeichen zu begrenzen und mit Leerzeichen aufzufüllen.

Für die Differenzierung der Anzeige des Views gibt es zwei Möglichkeiten. Dabei wird nach dem Sortieren die Parameterdatei VIEWGRUP.APR benutzt, die man unverändert auch für andere Kategoriesysteme einsetzen kann.

1. Gruppierung: Dazu muss hinter dem ersten Feld ein ':' stehen statt irgendeines anderen Trennzeichens, dann wird der Inhalt des ersten Feldes als Zwischenüberschrift verwendet
2. Summierung: Dazu muss vor das letzte Feld ein '_' statt irgendeines anderen Trennzeichens gesetzt werden. Dies führt, wenn "Gruppierung" eingestellt ist, nicht nur zur Gesamtsummierung, sondern auch auch zur Errechnung von Zwischensummen für die Gruppen.

Daraus macht das Programm SRCH mit der Parameterdatei VIEWGRUP.APR eine übersichtliche ViewListe. Die Funktion der Zeichen : und _ ist nicht im Programm "verdrahtet", sondern nur in VIEWGRUP.APR. Wer parametrieren kann, darf sich auch ganz andere Dinge ausdenken, um die ViewListe zu erstellen.

Folgende Funktionen braucht man für den Umgang mit Views:

1. Ergebnismenge in eine ViewListe umwandeln : FLEXe view1.flx und view2.flx mit vorgegebenen ViPs, viewform.flx und viewpara.flx für ad-hoc erstellbare ViPs.
2. ViewListe betrachten, Sätze auswählen und bearbeiten: FLEX-Befehl View
3. ViewListe exportieren: FLEX-Befehl download view

Aber noch mehr: die schlichte Struktur der ViewListen erlaubt es sogar, Auswahllisten beliebiger Art in derselben Form zu erstellen, die dann mit dem Befehl View präsentiert werden können. Zeilen, die nicht mit einem Satz verbunden sind, sollten am Anfang die Angabe "0|" haben oder aber das Zeichen '|' nicht enthalten. Die ausgewählte Zeile geht dann in die interne Variable über und kann beliebig weiter verwertet werden. Im FLEX sieht das so aus:

ViewListe anzeigen:

View dateiname (Achtung:View mit großem V, sonst keine Anzeige, sondern nur Dateiöffnung)
Es wurde [Esc] gedrückt:
if cancel jump xxx
Es wurde eine Zeile ausgewählt (mit Enter oder [OK]): in #uaw kopieren
ins #uaw
...

In #uaw hat man anschließend die ausgewählte Zeile aus der ViewList und kann damit beliebig umgehen.

Tip: Um eine bestimmte ViewListe, die man vorher produziert hat, erneut zu sehen, kann man sie auch manuell aufrufen: man gibt im Schreibfeld ein

x View dateiname

Verbesserungen von ASORT

Das DOS-Sortierprogramm ASORT.EXE wurde so verbessert, dass es die Aufgaben des View-Konzepts wahrnehmen kann, wenn auf DOS-Ebene eine ViewListe hergestellt werden soll:

Option -u3

Wie erstellt und nutzt man eine ViewListe?

Dazu gibt es mehrere Möglichkeiten, die mit fertigen Parametern und FLEXen unterstützt werden. Weitere Methoden und Varianten lassen sich entwickeln, wenn man die Bausteine erst einmal beherrscht (siehe oben).

Zuerst braucht man eine Ergebnismenge. Wie man eine macht, wissen Sie. Was darin ist und wie groß sie ist, spielt keine Rolle. Der Name steht unten auf der langen Schaltfläche, wie immer. Was macht man, um eine "Neue Sicht" dieser Daten zu erhalten?

Geben Sie im Schreibfeld ein: h view , dann erscheint in der Anzeige dieses Menü:
 

Eine ViP ist eine View-Parameterdatei, also eine Vorschrift zum Erstellen der ViewListe.

Tip: Geben Sie h view.rtf ein, dann sieht man auch die zu den Menüpunkten gehörenden FLEXe.

Das Menü hat links die Funktionen zum Erstellen neuer ViewListen, rechts die zur Benutzung vorhandener ViewListen.

Der Reihe nach:

ViewListen erstellen

Mit Standard-ViPs (Ein Doppelklick genügt und alles läuft automatisch ab)

Hier wurde eingegeben, dass #75 (Verlag) das erste Feld sein soll, begrenzt auf 15 Zeichen. Nach diesem Feld wird also sortiert und auch gruppiert (unter "Gruppierung" ist j eingetragen). Zusätzlich werden #20 (Titel) und #76 (Jahr) ausgegeben. Das Feld #95 enthält einen Geldbetrag und soll mit 5 Stellen und 2 Nachkommastellen ausgegeben werden. Es wird dann summiert, sowohl nach Gruppen als auch insgesamt. F1 bringt Hilfe! (Hilfetext  HUV)

Dieses Formular ist in der Datei view2.frm definiert. Die Eingaben kommen in Variablen #uvA - #uvZ und werden vom FLEX viewform.flx dann zu einer Parameterdatei verarbeitet. Diese wird benutzt, um die Ergebnismenge in eine ViewListe zu verwandeln. Wer jedoch Parametrierkenntnisse hat, kann in den Eingabezeilen "Feld 1" bis "Feld mit Zahl" auch Manipulationsbefehle mit unterbringen, z.B. #20 e" : ", damit vom Feld #20 (Sachtitel) der Zusatz abgeschnitten wird.

Neue ViP anlegen: Mit Parametern(fürAllegrologen , man braucht hierfür Parametrierkenntnisse)

(Start: x var "Start"\ins #uYa\var "X viewpara.flx"\ins #uZa\h viewpara )

Der dann erscheinende Hilfetext (Datei VIEWPARA.RTF) sieht so aus:

Wählen Sie die Kategorien, die in Ihrer ViewListe erscheinen sollen

1. Ist Gruppierung gewünscht; dann ":" zwischen dem ersten und zweiten Feld (s.o. #20)

2. Ist Summierung gewünscht: "_" vor dem letzten Element, das dann als Zahl interpretiert wird (s.o. #77).

Die Kategoriezeilen, die man hier eingibt (mit '#' beginnend), werden anschließend als Mittelteil der ViP verwendet.

Wenn man auf Start doppelklickt, wird VIEWPARA.FLX gestartet und der Text im Anzeigefeld verarbeitet.

(Den Befehl X viewpara kann man auch mit der Hand im Schreibfeld eingeben, um dies auszulösen.)

Tip: will man die in der aktuellen Sitzung zuletzt betrachtete ViewListe erneut sehen: im Schreibfeld eingeben

x view again

Die neu entstehenden ViewListen haben bei diesen Prozeduren immer den Namen VVV.VW. Anschließend hat man die Möglichkeit, ihr einen anderen Namen zu geben und damit für eine längere Aufbewahrung zu sorgen.

Und jetzt zu den Funktionen auf der rechten Seite des Menüs:

ViewListen benutzen

Aktuelle ViewListe = liste

neu anzeigen

Hat man gerade einen View erstellt, kann man mit dem neuen FLEX-Befehl download view die zum View gehörigen Datensätze in der durch den View gegebenen Reihenfolge exportieren. Benutzt dazu werden die aktuell eingestellten Exportparameter. Mit dem xport-Befehl kann man natürlich vorher die Ausgabedatei und/oder die Exportparameter auch anders einstellen.

Die mit 'X' markierten Zeilen werden nicht exportiert. Ansonsten wird jede Zeile der ViewListe verarbeitet, auch diejenigen, die keine Satznummer haben: In den Exportparametern hat man immer die aktuelle View-Zeile in der Variablen #uxV und kann diese darauf prüfen, ob sie mit einer Zahl beginnt, z.B. mit den Zeilen (siehe auch Kommentar in v-stand2.apr)

#uxV +A x">0" e0

... hier die Befehle für den Fall, dass kein Datensatz vorliegt, sondern z.B. eine Überschrifts- oder Summenzeile

#+#

#-A hier geht's weiter, wenn ein Datensatz vorliegt

Ist eine ViewListe xyz.vw vorhanden, egal wie und wann sie erzeugt wurde, kann man jederzeit in einem FLEX schreiben:

view xyz.vw

down view

um den Export auszulösen.

Mit X View xyz.vw kann man die ViewListe wieder betrachten, wenn man "view" schreibt, also klein, wird nur die Datei geöffnet.

View-Erstellung in eigene FLEXe einbauen

In den FLEXen view1.flx und view2.flx sieht man, wie es gemacht wird. Diese Dateien sind ausführlich kommentiert, damit man sieht, wo eingegriffen werden kann. FLEXologen können diese Grundmodelle beliebig ausbauen.

Neue FLEX-Befehle

Neu ist: ein FLEX-Befehl kann direkt ins Schreibfeld eingegeben werden: x Befehl(sfolge) oder X flexdateiname .

Nur wenige Befehle wurden erweitert bzw. neu geschaffen, einige davon speziell für die View-Technik:

set c0/c1

FLEXe für wichtige Funktionen

Volltextsuche

Geben Sie im Schreibfeld ein: X fts . Dann wird fts.flx aktiviert. Dieser FLEX startet das DOS-Volltextsuchprogramm SRCH.EXE. Die Ergebnisse allerdings werden hinterher als a99-Ergebnismenge präsentiert und lassen sich dann genauso sortieren und exportieren. Man muss natürlich bedenken, dass eine Volltextsuche bei großen Datenmengen erheblich länger dauert als ein Registerzugriff, aber wenn für eine Auswertung nach Feldinhalten gesucht werden muss, die nicht indexiert sind, gibt es oft keinen anderen Weg. Für Allegrologen:  SRCH benutzt zum Exportieren die Parameter fts.apr. Diese geben nichts anderes aus als die interne Satznummer eines jeden gefundenen Datensatzes. Korrekt funktioniert das nur mit einem SRCH.EXE ab 1.9.2000, ältere haben ein Problem in Fällen, wo es mehrere Datenbankdateien gibt (Typ .cLD).

Registerabschnitte mit Schwellenwerten

Mit dem CockPit konnte man seit langem über "Funktionen / QRIX" Abschnitte aus Registern in Dateien kopieren lassen, und zwar mit der Möglichkeit, nur Einträge mit einer gewissen Mindestzahl von Treffern (sog. "Schwellenwert") auszugeben. Dasselbe geht mit dem FLEX qrix.flx. Geben Sie also im Schreibfeld ein: X qrix, dann werden einige Fragen gestellt und die gewünschte Liste erscheint danach im Anzeigefeld. Von dort kann man sie mit Cut-and-Paste, wie immer, in andere Programme übernehmen oder aber per Menü "Datei | Anzeige speichern als ..." direkt in eine Datei kopieren.

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 würde man vielleicht die sog. Suchmaschinen betrachten wollen, die aber nur für das Retrieval in Sammlungen von schwach strukturierten Texten geschaffen wurden, nicht für die Verwaltung dieser Texte. Daher kann man sie nicht 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, dass solche Datenbanken die bestgeeigneten für bibliothekarische Zwecke seien - und bis heute hat sich das weder theoretisch noch praktisch schlüssig erwiesen. Die Empfehlung entsprang vielmehr der 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 allerdings noch nirgends überzeugend erfüllt, die Abhängigkeit der Anwendungssoftware von den spezifischen Besonderheiten einer Datenbankgrundlage ist denn doch immer recht groß, auch wenn überall "SQL" draufsteht. Ist der Standard also nur vermeintlich ein solcher, oder jedenfalls 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. Dass RDBMS so häufig eingesetzt werden, ohne auf ein schlüssiges, gründlich durchdachtes, theoretisch sauberes ER-Modell aufzusetzen, ist 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, musste feststellen, dass 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 notwendig sind, die Anwendungsprogramme also unerwartet groß und komplex werden. Erschwerend kommt hinzu: ein theoretisch stimmiges Modell allein reicht nicht aus. Es kann leicht passieren, dass ein Modell mit einigen hundert oder ein paar tausend Datensätzen gut funktioniert, dann aber bei weiterem Anwachsen "in die Knie geht". Es gibt manche Dinge, über die man bei kleineren Datenmengen gar nicht nachdenken muss, 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 meistens zu unbequemen Kompromissen zwingen, sind bei allegro, so darf man aus Erfahrung sagen, weniger gravierend.
 
 

Wer bis hierher gelesen hat, kann die Fragen des ersten Satzes leicht beantworten: "Keins" bzw. "Nein". Die zugrunde liegenden 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 schlichtweg unrealistisch. (Umgekehrt könnte man mit SQL auch nicht alles nachbilden, was man mit allegro machen kann, z.B. das Blättern in Registern.)

Es wird aus dieser Übersicht hinreichend ersichtlich, dass beide Datenbankkonzepte ihre Stärken und Schwächen haben und welche das sind. 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. Zu deren Grundkonzept hat allegro eine viel größere Ähnlichkeit als zum RDBMS-Konzept. Mehr zu diesem Thema steht unter http://www.allegro-c.de/allegro/a-o.htm .

CockPit-Funktionen in a99

1. Wichtige Dateien

Die wichtigen Dateien, die zu einer Datenbank gehören, kann man jetzt alle direkt aus a99  heraus zur Bearbeitung abrufen.

Start: Im Schreibfeld gibt man ein: h adm

Dann erscheint im Anzeigefeld dieses Menü:
 

a99 : Management-Funktionen  Angaben zur Datenbank
INI-Datei   (Vorgaben zu dieser Sitzung)   Konfiguration  (Feldstruktur der Datenbank)   Anzeigeparameter  (mit sofortiger Aktualisierung)   Druckparameter   (mit sofortiger Aktualisierung)   Indexparameter  (sofortige Aktualisierung möglich)  Formulardatei  (zur Unterstützung des Editierens)  Hilfedatei  (Hilfe zur Datenbank)	Satz sperren/freigeben  (für Schreibzugriffe)  Schreibsperre/-freigabe  (für gesamte Datenbank)  Totalsperre  (setzen/aufheben)       HILFE..HILFE..HILFE   (Was bedeutet das denn alles?)	Empfehlung: Wer mit den hier auftretenden Begriffen wenig anzufangen weiß, sollte sich das Kapitel 0 des Systemhandbuchs zu Gemüte führen. Die Begriffe werden dort erklärt. Wenn man z.B. auf das Wort "Konfiguration" doppelklickt, wird die Konfigurationsdatei der Datenbank zum Bearbeiten vorgelegt. Dazu öffnet sich ein DOS-Fenster und darin erscheint die Datei. Nur keine Panik! Anhang D des Hand-buchs erklärt auf nur einer Seite, wie die Bearbeitung mit dem sog. X-Editor geht.

Wenn man auf  HILFE..HILFE..HILFE  doppelklickt, kommt eine ausführlich kommentierte Fassung desselben Menüs (Datei admin.rtf). Es erübrigt sich deshalb, hier alle Punkte zu erläutern. Wer das CockPit kennt, kann sich denken, was gemeint ist, ansonsten gibt die Online-Hilfe genügend Hinweise.

Interessant für Allegrologen: die bisher nur bei den Anzeigeparametern bekannte Testmethode "Merseburger Testschleife" gilt nun auch für die Indexparameter und für die Konfiguration, sowie für die INI-Datei: Direkt nach der Änderung kann diese sofort aktiviert und die Wirkung geprüft werden.

Als Editor zur Bearbeitung der Dateien wird standardmäßig der X-Editor benutzt, mit dem Befehl Editor=... kann man in der INI-Datei einen anderen einstellen. Notepad, Wordpad oder andere Windows-spezifische Editoren empfehlen sich nicht, weil diese alle mit ANSI-Codes arbeiten, für die Parameter und CFG ist aber ASCII notwendig. Schrecken Sie vor dem X-Editor nicht zurück! Es braucht wirklich nur 2 Minuten, die notwendigen Dinge zu erlernen, eine einzige Seite im Handbuch reicht dafür aus (Anhang D). Das ist das geringste Problem, viel schwieriger ist die Exportsprache, die man für Index-, Druck- und Anzeigeparameter kennen muss. Für die Konfiguration ist auf Handbuch-Anhang A zu verweisen.

Für die Hilfedatei wird der Editor Wordpad aufgerufen, da es sich um eine RTF-Datei handelt. Die Datei heißt bei der Demo-Datenbank CATGER.RTF (bzw. CATENG.RTF, wenn die Sprache Englisch eingestellt ist). Für Ihre eigene Datenbank müssten Sie sich eine solche Datei mit Hilfe des Wordpad-Editors erst noch anlegen. Sie können dabei von einer Kopie der Datei CATGER.RTF ausgehen.

Auf der rechten Seite gibt es drei Funktionen zum Sperren und Freigeben:

Satz sperren/freigeben

Tip: Die "Organisier"-Funktionen des konventionellen CockPit sind auch verfügbar: geben Sie ein h org
 
 

2. Dokumentation (Online-Hilfe)

Eine Übersicht der Online-Dokumentation erhält man, wenn man im Schreibfeld h doku eingibt:
Im Anzeigefeld erscheint dann diese Übersicht:
 

a99 Dokumentation
Allgemeines	allegro - Was ist das?  Elemente des Programms  Grundbegriffe
Daten	Datenschema Formulare  -  Dateneingabe Fremddaten-Import  - Export, Listen  - Views Tastenfunktionen  - Phrasen Sonderzeichen-Eingabe - Zeichensatz  (ANSI-Codes)
Systemverwaltung	Management-Funktionen Installationshinweise  -  Liste der Dateien Initialisierung (INI-Datei)  FLEX-Sprache Hilfekonzept Systemhandbuch Hintergründe

Die unterstrichenen Bezeichnungen stehen jeweils für eine RTF-Datei, die mit Doppelklick aufzurufen ist. In manchen Fällen, so z.B. im Fall "Systemhandbuch", kommt eine Übersicht, die wiederum unterstrichene Bezeichnungen enthält. Wie bei einem Web-Browser kann man den "Zurück"-Button links oben dazu benutzen, zu vorher aufgerufenen Texten zurückzuschalten.

Ist wieder ein Datensatz in der Anzeige, kann man die zuletzt besichtigte Hilfeseite über das Menü "Anzeige" wieder zurückholen.

Tip: Machen Sie Kopien der Datei doku.rtf oder adm.rtf, wenn Sie ähnliche Menüs mit eigenen RTF-Dateien und/oder FLEXen anlegen wollen. Die Bearbeitung solcher Dateien ist am bequemsten mit dem Programm WordPad, das zu Windows gehört. (Die Datei help.rtf, die hinter "Hilfekonzept" steckt, erläutert alles Weitere.)

Installation der V20a

Die CD-ROM V20a enthält eine aktualisierte V20. Zur Installation gilt dieselbe Schlüsselzahl, die auf der Rechnung für die V20 mitgeteilt wurde. Fertigen Sie also mit Hilfe dieser Zahl zuerst die 3 Installationsdisketten an, dann legen Sie die erste davon ein, wenn eine Neuinstallation vorzunehmen ist, sonst die zweite. Im ersten Fall ist INSTALL.BAT von der Diskette zu starten, im zweiten Fall wählt man im CockPit den Menüpunkt "Routinen / Neue Version installieren / Update-Installation".

Wir empfehlen wie immer dringend, dass Sie Ihre vorhandene Installation aktualisieren. Änderungen an Datenbanken oder eigenen Parametern sind nicht notwendig. Sieht hinterher die Anzeige anders aus oder die Registereinträge, oder ist die Abfrage neuer Daten anders als vorher: reaktivieren Sie Ihre alten Parameter über den CockPit-Menüpunkt "X : EXTERN" unter "Routinen", danach die Funktion "0 - Eine alte Datei wieder aktivieren" und D-1.APR wählen für die Datenanzeige, CAT.API für die Indexparameter, $A.CFG für die Abfrageliste. Das ist alles. Nur keine Angst: es kann nichts kaputtgehen, Sie gewinnen im Gegenteil mehr Sicherheit.

Hinweis für die Windows-Programme: Benutzen Sie die Datei FILELIST.TXT als Checkliste.

E-Mail-Diskussionsliste [DIE Adresse für alle akuten Fragen und Probleme]

Man schließt sich den ca. 280 Lesern der allegro-Liste an, indem man an die Adresse maiser@buch.biblio.etc.tu-bs.de eine Botschaft mit nur einer Zeile sendet: subscribe allegro . Man wird dann sofort eingetragen und erhält eine Mitteilung mit weiteren Informationen, insbesondere, wie man sich wieder abmeldet. Es gibt auch ein Archiv der Liste.