allegro Systemhandbuch V26

11	Import-Parameter

`11.0`	Zum Konzept 
	1	`Struktur von allegro-Dateien` 
	2	`Inhalt einer Import-Parameterdatei` 
`11.1`	Wie macht man eine Import-Parameterdatei? 
`11.2`	Die Import-Sprache 
	1	`Basis-Parameter: 4 Typen von Fremddaten` 
	2	`Globale Konvertierungsbefehle` 
	3	`Die Kategorieliste - das Kernprogramm` 
	3.1	`Die Kategorie-Angabe` 
	3.2	`Positionierung` : Angabe des Textbeginns 
	3.3	`Textausschnitt bestimmen` 
	3.4-6	`Manipulationsbefehle, Vergleiche, Sprünge, Unterprogramme` 
`11.3`	Beispiel einer Umwandlung mit allegro

11.0  Zum Konzept

Der Ausdruck Import steht im allegro-System für die Umwandlung andersartig strukturierter Daten in eine allegro-Grundstruktur. 
Wie so etwas abläuft, wird in `Kap. 5` beschrieben. Lesen Sie zum besseren Verständnis den Abschnitt 5.0 vor der Lektüre dieses Kapitels. 

Dieses Kapitel führt in die Importsprache ein, mit der man Fremddaten von fast beliebiger Struktur beschreiben und ihre Überführung in eine allegro-Grunddatei (Typ .ALG) programmieren kann. Eine Grunddatei läßt sich anschließend, also in einem zweiten Schritt, mit dem Programm INDEX oder UPDATE in eine Datenbank umwandeln oder in eine vorhandene Datenbank einmischen. 
Legionen von Programmierern haben sich für gleiche oder sehr ähnliche Anwendungen die unterschiedlichsten Datenstrukturen ausgedacht. Genau aus diesem Grund ist eine universelle Importsprache nötig, weil man sonst für jede Umwandlung ein eigenes Programm in C, Pascal oder einer anderen "Hochsprache" schreiben müßte. Eine solche universelle Sprache muß weitaus mehr leisten als nur Datenfelder umgruppieren und anders numerieren. Dieses Kapitel beschreibt ausführlich, welche Einzelaufgaben anfallen können und wie man sie mit allegro löst. 
In der allegro-Importsprache als Spezialsprache erstellt man Umwandlungsprogramme, hat man sich einmal eingearbeitet, in Bruchteilen der Zeit, die man etwa für ein C- oder BASIC-Programm bräuchte. Auch ad-hoc-Umwandlungen für Einmal-Aktionen, die sonst am Aufwand scheitern würden, sind daher realisierbar. 

Nach Untersuchung einer größeren Zahl von Datenformaten stellte sich heraus, daß man alle überhaupt relevanten Formate in nur vier Typen einteilen kann:  (Beispiele siehe 11.1) 

A	feste Satz- und Feldlänge: alle Datensätze haben dieselbe Länge und sind an festgelegten Stellen in Felder untergliedert. Zu diesem Typ gehören die meisten kommerziellen Datenbanksysteme. Steuerzeichen für Feld- und Satzbegrenzungen gibt es in der Regel nicht, denn sie wären redundant. 

B	feste Anzahl Felder mit variabler Länge: die einzelnen Felder sind zwar (meist in Grenzen) variabel lang, aber es gibt eine feste Anzahl von Feldern, die durch ein bestimmtes Steuerzeichen (sog. "delimiter") oder eine Zeichenkombination getrennt sind. Bei diesem Typ haben die Felder meist keine Kategoriekennungen, sondern die Bedeutung ergibt sich aus ihrer Position innerhalb der Feldkette. 

C	variable Anzahl Felder mit variabler Länge: dieser Typ, zu dem auch allegro-Daten gehören, hat in der Regel eindeutige Feldkennungen, damit die einzelnen Datenfelder überhaupt identifizierbar sind. Es gibt Steuerzeichen oder Zeichenkombinationen, die als Satz- und Feldbegrenzungen fungieren. Jede Datenquelle hat hierbei ihre Besonderheiten. Die sog. "Download"-Dateien von Datenbank-Hosts und von den meisten CD-ROM-Datenbanken fallen unter diesen Typ. 

D	Satzstruktur mit "directory": nach einer internationalen Norm (ISO 2709 bzw. DIN 1506) werden bibliographische Austauschdaten auf Magnetband mit dieser Struktur geliefert. MARC- und MAB1-Daten sind oft, aber nicht immer, in dieser Form anzutreffen. Die Norm läßt noch einige Freiheitsgrade, die in der Praxis auch ausgenutzt werden. Die Feldkennungen stehen in einem "Inhaltsverzeichnis", die Feldinhalte davon getrennt in einem variablen Teil. Es kann, muß aber nicht, zusätzliche Feld- und Satzbegrenzungszeichen geben. Ansonsten liegt hier ebenfalls eine variable Anzahl Felder mit variabler Länge vor. 
	Das Format MAB2, das Anfang 1996 eingeführt wurde, wird von der Deutschen Bibliothek nicht mehr in ISO-Struktur verbreitet. Es gehört damit zum Typ C. 

Für den allegro-Anwender können noch zwei Sonderfälle wichtig werden: 

[E	Bibliofile-Daten: Die CD-ROM-Platten der Firma Library Corporation (in Deutschland vermutlich kaum noch in Gebrauch) enthalten im Prinzip die MARC-Daten der Library of Congress, jedoch erhält man beim "downloading" nicht die ISO-Struktur, sondern eine eigenwillige  Strukturierung, die Sonderbefehle erfordert (-Ø 11.2.1,Typ D; 11.2.3.2).   obsolet! ]

F	allegro-Daten. Damit sind .ALG-Dateien gemeint (-Ø 0.3), aber auch andere Dateien, in denen die korrekten Kategorienummern bereits als Feldbezeichnungen enthalten sind. Es kann vorkommen, daß ein Anwender seine eigenen Daten importieren will, um etwa die Fähigkeiten der Importsprache für gewisse Umwandlungen auszunutzen. Deshalb gibt es auch für diesen Datentyp noch besondere Möglichkeiten (-Ø11.2.3.1) 

Datenbanken, die intern nicht einem dieser Typen entsprechen, können in aller Regel eine Ausgabeform ("download" oder "export") produzieren, die unter Typ B oder C fällt. Bei dBASE z.B. produziert man eine Ausgabe vom Typ B mit dem Befehl  COPY TO filename DELIMITED WITH %% . Das Zeichen '%%' ist dann der "Delimiter", d.h. es begrenzt die einzelnen Felder.

11.0.1	Struktur von allegro-Dateien

allegro-Daten sind vergleichsweise einfach strukturiert (wenn man vom Index absieht): 
 •	Hauptsätze in Grunddateien (Typ .cLG) und in Datenbank-Dateien (Typ .cLD) beginnen mit dem Code 1 (01h), Untersätze mit 2...6 (02h...06h). In Datenbank-Dateien steht hinter dem Code 1 eine 4 Byte lange Satznummer, ansonsten sind beide Strukturen gleich. Ein Hauptsatz und beliebig viele Untersätze bilden eine Satzgruppe. Ein gelöschter Satz beginnt mit Code 9 statt 1, der Rest ist gleich. 
 •	die Datenfelder (Kategorien) beginnen mit festgelegten Kennungen aus zwei oder drei Ziffern oder Buchstaben und enden mit dem Code Null (00h). Am Bildschirm erscheint vor der Kategoriekennung das Zeichen '#', das aber nicht mit gespeichert wird. (Das anwendungsspezifische Kategorienschema steht von den Daten getrennt in einer Datei c.CFG (Standard: A.CFG). Darin sind die Nummern der erlaubten Felder, deren Eigenschaften und auch ihre interne Reihenfolge festgelegt. Beschreibung -Ø `Anhang A`.) 
 •	Die Kategorien sind als fortlaufende Zeichenketten gespeichert, also ohne Zwischenräume und ohne Zeilenumbrüche. 
 •	am Ende einer Satzgruppe, hinter dem abschließenden Code 0 des letzten Feldes, stehen die Codes 13`10 (0Dh`0Ah). Notwendig sind sie nur in Grunddateien (.cLG) und nur zum Sortieren. 
(Mehr zu diesem Thema: siehe auch -Ø 0.2.2) 
Will man irgendwelche Daten in diese Form bringen, muß man also ein bestimmtes Kategorienschema zugrundelegen (beschrieben in einer Konfigurationsdatei c.CFG), in welches man die Daten überführen will. Man erstellt dann eine Import-Parameterdatei, welche den Dateityp .cIM bekommt. Dadurch bleibt immer erkennbar, vor allem auch vom Programm aus, zu welchem Schema c die Parameter gehören: .AIM gehört zu A.CFG, .UIM zu U.CFG usw. 
Der Name der Parameterdatei ist ansonsten beliebig. 

Wer selbst programmiert (in Basic, C, Pascal o.a.) und seine Daten gut kennt, kann die hier beschriebene Form auch selbst herstellen, um sich die Einarbeitung in die Importsprache zu ersparen. Wenn die Einzelheiten dann genau stimmen, kann man eine solche Datei unmittelbar indexieren oder per UPDATE in eine Datenbank einmischen. 
Wenn man die Daten mit a99 einlesen und einspeisen will, kann man auch die leichter zu erstellende Struktur des Typs .ADT wählen (à Kap.0.2.2). a99 kann so eine Datei über das Menü "Datei / Weitere Offline-Datei laden" einlesen und mit dem FLEX-Befehl update auch genauso einspeisen, wie das DOS-Programm UPDATE es machen würde. 
Die Reihenfolge der Kategorien ist dabei nicht zwingend vorgeschrieben, nur die #00 muß am Anfang eines Satzes stehen. (Hierarchische Untersätze müssen mit #01,..,#06 beginnen.) Die Programme ordnen beim Einlesen dann die Kategorien innerhalb eines Satzes in der Reihenfolge, die in der CFG vorgegeben ist. 

11.0.2	Inhalt einer Import-Parameterdatei

Eine Import-Parameterdatei enthält folgende Bestandteile (in dieser Reihenfolge): 

a)	eine Anzahl Basis-Parameter, die man auch Rand- oder Nebenbedingungen nennen könnte: Steuerzeichen von Satzanfang- und -ende sowie Feldende (dabei kann es sich um beliebige Zeichenkombinationen handeln). Diese Angaben sind vom Typ der Fremddaten abhängig.	(-Ø 11.2.1) 

b)	evtl. Befehle für globale Ersetzungen von Zeichenketten, die an einem Fremdsatz vorzunehmen sind, bevor er umgewandelt wird,	(-Ø 11.2.2.2) 

c)	Zeichenumwandlungsbefehle unterschiedlicher Art: z.B. muß man gelegentlich von ANSI nach ASCII umcodieren. Oder man hat etwa in MARC-Daten Codierungen für Sonderzeichen (speziell für Umlaute), die aus jeweils einem Steuerzeichen (Protyp) und einem Textzeichen bestehen, z.B. "Φu" für 'ü'. Diese Kombinationen lassen sich in die Einzelzeichen umsetzen. Andere Zeichenmanipulationen können über die Exportfunktion vorgenommen werden. Man muß die eingelesenen Daten ohnehin über eine Export-Parameterdatei wieder ausgeben lassen (siehe Kap.5), daher kann man die Umwandlungsfunktionen der Export-Schnittstelle mitbenutzen. Im allgemeinen wird man I-1.cPR als Export-Parameterdatei nehmen, um die Fremddaten im allegro-Schema abzuspeichern. Dann müßte man die entsprechenden Zeichen-Umwandlungsbefehle in die Datei I-1.cPR einfügen.	(-Ø 11.2.2) 

d)	eine Liste der allegro-Kategorien, die aus dem vorliegenden Material gebildet werden sollen. 
	Diese Kategorien können in beliebiger Reihenfolge aufgeführt werden.	(-Ø 11.2.3) 
	Zu jeder der Kategorien muß bzw. kann es Befehle geben, die dem Programm sagen: 
	d.1.	wo der Anfang der betr. Kategorie im Fremddatensatz zu finden ist (dabei gibt es mehrere Modalitäten, je nach Typ); dieses macht man mit einem Positionierungsbefehl,	(-Ø 11.2.3.2) 
		Es ist dabei auch möglich, auf eine Fremdkategorie mehrfach zurückzugreifen oder eine nochmals aufzugreifen, die bereits umgewandelt wurde oder die als Variable im Hintergrundspeicher steht. 
	d.2.	wie das Ende bzw. die Länge des Kategorietextes zu bestimmen ist,	(-Ø 11.2.3.3) 
	d.3.	ob lokale Ersetzungen im Kategorietext durchzuführen sind. 	(-Ø 11.2.3.4) 
		Auch eine Umsetzung von Feldinhalten mittels Konkordanzlisten ist möglich. 
	d.4.	welche sonstigen Bearbeitungen am Kategorietext vorzunehmen sind. 	(-Ø 11.2.3.4) 
		Hierbei gibt es eine Anzahl von Spezialfunktionen. 
	d.5.	Ferner gibt es Vergleichs- und Sprungbefehle, die bei Vorliegen oder 	(-Ø 11.2.3.5/.6) 
		Nichtvorliegen bestimmter Bedingungen Verzweigungen im Ablauf auslösen. 
	d.6.	Zwei Möglichkeiten gibt es für mehrfach besetzte Kategorien: 	(-Ø 11.2.3.6) 
		solche können in jeweils eigene allegro-Kategorien oder gesammelt in eine einzige überführt werden, z.B. getrennt durch ';'. 
	d.7.	Hierarchisch gegliederte Datensätze 	(-Ø 11.2.3.4) 
		können in ebensolche allegro-Sätze überführt werden. 

e)	Kommentare: Jede mit Leerzeichen beginnende Zeile wird als Kommentar behandelt. 
	Zwei Leerzeichen hintereinander in einer Zeile bewirken, daß der Rest der Zeile ignoriert wird. 

11.1  Wie macht man eine Import-Parameterdatei?

Eine Import-Parameterdatei kann in gleicher Weise wie die Export-Parameter (-Ø 10.1) vom CockPit aus (über`μd) oder mit jedem Texteditor als Textdatei erstellt werden. Der Name muß von der allgemeinen Form iname.cIM sein, wobei iname ein beliebiger Name Ihrer Wahl ist, c der Kennbuchstabe Ihres Kategoriesystems. Standard wäre also .AIM. An der Dateikennung .cIM erkennt die Software, um was es sich handelt. So wird z.B. verhindert, daß man eine .PIM-Parameterdatei benutzt, wenn man gerade mit dem Kategoriesystem A.CFG arbeitet. 
Wo gehört die Parameterdatei hin? Sie darf auf dem Datenverzeichnis stehen, wo die Quelldaten untergebracht sind (d.h. die zu konvertierenden Daten; dort sucht das Programm zuerst danach), aber auch auf dem Programmverzeichnis (dort liegt sie im Normalfall), drittens auf dem Startverzeichnis, von wo aus IMPORT aufgerufen wird. 

Auch für den Import kann man sich, wie beim Export, an Beispiele halten. Zur Orientierung können folgende mitgelieferten und kommentierten Parameterdateien für die einzelnen Typen dienen: 

A	BAS.AIM	BAS-Format -Ø A.CFG 
				Die einzelnen Felder haben feste Positionen in Sätzen mit fester Länge. 

B	DBIII.AIM 	dBASE ASCII-Datei -Ø A.CFG 
				dBASE kann mit dem COPY-Befehl sog. "ASCII files" herstellen. Dabei sind dann die Datenfelder auf ihre tatsächliche Länge beschnitten und durch Begrenzungszeichen ("delimiter") eingeschlossen. Jeder Satz hat die gleiche Anzahl Felder. Unbesetzte Felder bestehen nur aus zwei Begrenzungszeichen. 
Tip: Mit dem Hilfsprogramm DB2DELIM kann man dBase-Daten vorbehandeln und die Details der Struktur herausbekommen. 

C	MEDIC.AIM	MEDLARS download -Ø A.CFG 
				Ein typischer Fall für Dateien, die man aus Recherchesitzungen erhalten kann. Der Satzanfang ist an einer bestimmten Zeichenkombination erkennbar, die Felder haben festgelegte Bezeichnungen. Zeilenumbrüche innerhalb von Feldern müssen beseitigt werden. 
	PICA.AIM	Pica3-Format (vom Verbund Niedersachsen ab Januar 1993) -Ø A.CFG 
	DBCD.AIM	CD-ROM-Daten der Deutschen Bibliothek (MAB-90) -Ø A.CFG  (s. 11.3) 
	MAB2.AIM	MAB2 -Ø A.CFG.   Beides MAB-Formate, aber ohne Directory. 
	MABDISK.AIM	Hiermit können auch ZDB-Daten umgewandelt werden. MABDISK ist für das ältere MAB1 gedacht, und zwar die Disketten-Variante. 

D	OCLC.AIM 	USMARC -Ø A.CFG 
				Das USMARC-Format z.B. von OCLC ist, wie MAB1, nach ISO 2709 konstruiert, hat aber ansonsten mit MAB1 wenig gemeinsam.  Diese Parameterdatei funktioniert auch mit Daten des RLIN-Verbundes und der Library of Congress. 
	BIEL.AIM 	Bielefeld MAB -Ø A.CFG   (nur noch historisch?) 
				Der Bielefelder CD-ROM-Katalog produzierte als Export ein weitgehend normgerechtes MAB1-Format mit Directory. 

F	ALG.AIM	allegro-Grunddatei (Typ .ALG) -Ø A.CFG 
	KAT.AIM	ASCII-Datei mit Kategorienummern -Ø A.CFG 
				Dateien, die bereits das richtige Kategoriesystem haben, können sehr bequem 
	KAT00.AIM	importiert werden, wobei man noch beliebige Vorbearbeitungen einbauen kann. 
				KAT00.AIM ist für den Re-Import von Exporten mit E-W.APR gedacht. 

?11.0=h =11.0  Zum Konzept 
?Struktur von allegro-Dateien=h =11.0.1 
?Inhalt einer Import-Parameterdatei=h =11.0.2 
?11.1=h =11.1  Wie 
?11.2=h ac11-1 
?Die Kategorieliste - das Kernprogramm=h ac11-2 
?Manipulationsbefehle, Vergleiche, Sprünge, Unterprogramme=h ac11-3 
?Globale Konvertierungsbefehle=h ac11-1=11.2.2  Globale 
?11.3=h ac11-4 
?Anhang A=h aca-1 
?Basis-Parameter: 4 Typen von Fremddaten=h ac11-1=11.2.1 
?Die Kategorie-Angabe=h ac11-2=11.2.3.1  K 
?Positionierung=h ac11-2=11.2.3.2  P 
?Textausschnitt bestimmen=h ac11-2=11.2.3.3  T 
?Kap. 5=h ac5