Bibliothek Wiki | Bibliothek / Migration

Termin: 16. - 19. Mai: Zeitplan

organisatorische Maßnahmen

Aufbereitung der Daten in Alephino für ein Zweigstellensystem

durch uns

alle Texte in der mabtext.ger (Mahnungen, Erwerbung, Vormerkung, Bestellung) wurden bereits für die Version 4.1 angeglichen
Texte und Einstellungen im OPAC und Service-Modul angleichen - abgeschlossen
Rechnungsstellung für alle Nutzerkonten bis einschließlich 2012 LKZB erl.
Löschung inaktiver Nutzer:
1. Benutzerlisten der Mitarbeiter erstellen: Haus Birkach, Boll, OKR, OKR intern ohne Mahnung -> Daten gehen nicht verloren, falls ein Nutzer nie aktiv war und können bei Bedarf einer anderen Zweigstelle zugeordnet werden. Dazu ist ein Abgleich mit einer neuen Nutzerliste, die direkt nach der Migration erstellt werden muss, nötig. - für Boll, OKR, OKR intern erl.
2. Löschlauf: Sammellöschungen (Benutzer) Anzahl Tage seit letzter Aktivität: 865 -> alle Nutzer, die seit 865 Tagen nicht aktiv waren oder einen ungültigen Ausweis besitzen (Ablaufdatum z.T. auch bei Nutzern mit neuem Ausweis schon überschritten!) werden gelöscht, alle Nutzer mit Fehlermeldung "Ablaufdatum Benutzerausweis kann nicht ermittelt werden" kommen in eine Liste
3. Löschlauf: Sammellöschungen (Benutzer) Löschen von Liste -> Nutzer mit o.g. Fehlermeldung werden gelöscht -> bei Frau Zahrte angefordert, kann notfalls auch nach der Migration durchgeführt werden

Problem: Nutzer mit neuen Ausweisen, die bisher nur in einer Bibliothek aktiv waren
Löschlauf kann daher erst unmittelbar vor der Migration durchgeführt werden

Fernleihe: 1. Anbindung an das Fernleihportal des BSZ - Testzugang vh., Authentifizierung über Benutzernummer muss noch geklärt werden - nach der Migration
Fernleihe: 2. Benutzer füllen selbst Fernleihformulare über OPAC aus - Fernleihserver des BSZ im Zentralkatalog verlinken, für LKZB abgeschlossen

durch ExLibris

1. Allgemeines zum Verfahren der Zusammenführung der Datenbestände --- bleibt so

einheitliche Bennung der Quellen
Vorrangiges Ziel ist es, alle Daten aus den infrage stehenden 14 Quellen zuverlässig zusammenzuführen. Diese Quellen sind – in der Reihenfolge Ihrer Verarbeitung bzw. Priorität:

Umbenennungen und Reihenfolge der Zweigstellen :

Kürzel alt	Kürzel neu	Benennung	Sigel
OKRB	LKZB	Zentralbibliothek	Stg 117
HBIR	BIRK	Haus Birkach Bibliothek	Stg 257
BIRU	UMOD	Birkacher Unterrichtsmodelldatei	STG257X
BOLL	BOLL	Ev. Akademie Bad Boll	Bol 1
EVHS	EHLB	Ev. Hochschule Ludwigsburg	Rt 3
-	STFT	Ev. Stift Tübingen	Tü 69
HKIM	HKM	Ev. Hochschule für Kirchenmusik Tübingen	Ess 3
VKIM	VKM	Verband für Ev. Kirchenmusik	Stg 262
MEDI	OEML	Ökumenischer Medienladen	Stg 264
-	MAU	Ev. Seminar Maulbronn	Mau 1
MUSE	MUSE	Museale Sammlung im LKAS	Stg 117/4
SEMI	KSA	Seminar für Seelsorgefortbildung	Stg 274
KLOS	SULZ	Ev. Michaelsbruderschaft Kirchberg	Sul 1
-	HAH	Henri-Arnaud-Haus	Stg 117/1
DENK	PSTK	Ev. Pastoralkolleg	Stg 117/2
-	DEHN	Dekanat Heilbronn	Hb 5
REUT	DERT	Dekanat Reutlingen	Rt 6
SONS	PFAB	Pfarrbibliotheken	Stg 117/1

Im Sinne der Normalisierung der Daten sollen hierbei, wo immer möglich (und sinnvoll) Dubletten vereinigt werden. Es ist zu gewährleisten, daß abhängige Sätze zum jeweils richtigen „Eltern“-Satz verknüpft werden. Um die der ursprünglich im Quell-Pool vorhandenen Zuordnung äquivalente Verknüpfung von Kind- zu Elternsätzen auf allen Ebenen der migrierten Datenbank zu realisieren, wird folgendes Verfahren angewandt:
a. Jede Satzart der Alephino-Datenbank, die als Verknüpfungs-Ziel definiert ist, erhält ein wiederholbares Feld 020 = „Alte Identnummer“, welches via Suchbegriff „IDA“ recherchierbar ist. Dessen Inhalt besteht jeweils aus einem 4-stelligen Präfix, der die Quell-Datenbank kennzeichnet, und der 9-stelligen Identnummer des betreffenden Satzes in dessen Quell-Pool.
b. Alle Verknüpfungen werden über die erwähnte „Alte Identnummer“ hergestellt. Diese ist in den Ladedaten jeweils repräsentiert durch Link-Felder der Form $$a?IDA=<Alte Identnummer>

2. Migration von Normdaten (Autoren, Körperschaften, Schlagworte, Notationen) --- ausschließlich über Feld 026

3. Migration von Notationen --- bleibt so

Diese werden vereinbarungsgemäß nur aus dem vormaligen Datenpool BIRK gespeist. Geladen werden nur gültige Sätze, also jene mit einem Feld 800. (Von 8823 Notationen-Sätzen im untersuchten Datenbestand werden 5287 verworfen.)

4. Bibelstellen ------ nicht dedupliziert!

Werden nur aus den Datenpools OKRB und BIRU übernommen (und nicht dedupliziert).

5. Eliminierung der aus dem ersten Normdaten-Lade-Lauf resultierenden Dubletten --- bleibt so

a. Alle bereits geladenen (und erfolgreich deduplizieren) Normdaten werden entladen (exportiert).
b. Zunächst werden in einen neuen (leeren) Datenpool ausschließlich die Dubletten und im Anschluß die zuvor exportierten Daten wieder importiert.
Dies funktioniert, da die im ersten Lauf aufgrund Mehrdeutigkeit nicht zuordenbaren Dubletten jene Sätze repräsentieren, die keine Verbund-Identnummern, sondern zumeist nur eine einfache Ansetzungsform aufweisen. Lädt man die bereits deduplizierten Sätze im Anschluß, gelingt die Vereinigung ohne Rest-Dubletten.

6. Migration der Titeldaten --- nur 026

Exl> (zu allen vorstehenden Punkten): Nachdem die Dubletten-Erkennung ausschließlich auf Feld 026 (Verbund-Identnummer) umgestellt wurde, ergaben sich folgende Änderungen hinsichtlich der Anzahl resultierender Datensätze:

Satzart	Standard-Dublettenprüfung	Dubletten basierend auf 026
TIT	646.177	699.828
AUT	186.852	201.748
KOR	22.609	23.330
SWT	80.163	92.370
BIS	5.963	(ohne Dublettenprüfung) 5.968

Titelsätze werden nach folgenden Regeln dedupliziert:
Werden Dubletten identifiziert, wird der vorhandene Satz mit bislang nicht vorhandenen Feldern (auch Wiederholungen) aus dem neuen Satz aufgefüllt. Eine Ausnahme bildet das Feld 020. Dieses wird stets hinzugefügt, da es, wie erläutert, als Verknüpfungs-Identifikator dient. Der als Match&Merge bezeichnete Vorgang erlaubt lediglich eine formale Beschreibung von Regeln, augrund derer vorhandener und aktuell importierter Datensatz zusammengefügt werden, eine inhaltliche Priorisierung ist hingegen nicht möglich.

7. Migration Exemplare --- Zweigstellenkennung automatisch einfügen! einzelne Zweigstellen erhalten für alle Ex. Präsenz (Tabelle!)---- Option einzelne Zweistellen hinterher automatisiert wieder komplett auf ausleihbar zu ändern

Exl> Ja. Die Umstellung des Exemplarstatus für einen aufgrund des Zweigstellen-Kennzeichens definierten Bestand ist mithilfe der Alephino-Skriptsprache jederzeit möglich.
Da Exemplarsätze physikalische Einheiten repräsentieren, die mitunter mit Entleihungen, Vormerkungen etc. verknüpft sind, verbietet sich hier eine Deduplizierung, d.h. alle Datensätze sind ohne Änderung zu laden. Dublettenbereinigung abgeschlossen Anmerkung: angebundene Werke, unselbständige Werke haben kein Exemplarsätze und daher auch keine Zweigstellenkennzeichnung - Ausnahme Modelldatei

8. Migration Verwaltungsdaten --- bleibt so

Hierunter fassen wir all jene Datenarten der Alephino-Datenbank, die keinen bibliographischen Bezug haben. Es werden ausschließlich Daten aus den Quellen OKRB, EVHS und BIRK berücksichtigt. Hierbei erhalten alle Datenarten, die für die Abbildung zweigstellen-relevanter Funktionen genutzt werden, ein Zweigstellen-Kennzeichen entsprechend dem Ursprungs-Bestand (Datenpool).

9. Änderungen der Status von Verbuchungen, Benutzersätzen und Gebühren --- fernleiheinstellungen---okr, hbb im service-modul geändert, Tabellen an Herrn Bast

Exl> Die Änderung der Kodierung wird entsprechend berücksichtigt.
Aufgrund der notwendigen Vereinheitlichung der Status-Tabellen müssen z.T. Codes von Benutzerstatus und Gebührenart geändert werden.
Benutzer-Status von EVHS: '01' => '21', '02' => '22', '05' => '25', '11' => '24', '23' => '23' mit: 21 = Studierende/r EHLB
22 = Staff EHLB
23 = Lehrbeauftragte/r EHLB
24 = PH-Studierende/r EHLB
25 = Guest/Extern EHLB
Gebührenart von BIRK: '0007' => '0008', '0008' => '0018'
mit:
0008 = Kopierkosten
0018 = Faxe
Hilfreich wäre es, die Bibliotheken verzichteten bis zur produktiven Migration auf Änderungen nutzerdefinierter Tabellen, die einer erneuten Analyse und nachfolger Adaption der Konvertierungsprogramme bedürfen.
Ab wann ändert sich hier nichts mehr?

10. Benutzer und Benutzer-Adressen -------- Dublettenkontrolle nur anhand der Barcodes der Ausweise
d.h.: Löschlauf aller Nutzer vor 2012, doppelte Nutzer können nur in LB und OKR/HBB vorkommen, nach der Migration Liste erstellen und von Hand bereinigen

Exl> Möglicherweise habe ich mich mißverständlich ausgedrückt, denn mein Migrationskonzept sah bereits genau das vor: alleiniges Kriterium der Dublettenprüfung für Benutzer ist der Barcode. Die beigefügten Listen enthielten dublette Benutzersätze (mit identischen Barcodes), jedoch mitunter geringfügigen Unterschieden bei Namen, Geburtsdaten etc. Im Anhang dieser Nachricht finden Sie eine Datei „doubl_names.txt“, in der die Häufigkeit des Auftretens desselben Namens mit unterschiedlichem Barcode aufgelistet ist. Diese Liste werde ich anläßlich der produktiven Migration nochmals aktualisieren.
Datei: Attach:doubl_names.txt
Die Dublettenkontrolle aufgrund des Barcodes ergab insgesamt 2221 Überschneidungen zwischen den Nutzern in BIRK und OKRB. Im Anhang finden Sie hierzu:
a. Attach:bencodes_okrb_birk.txt = Liste der dubletten Barcodes
b. Attach:bencodes_okrb_birk_diff.txt = Details der Unterschiede zwischen Benutzerdaten bei identischem Barcode (Bitte beachten Sie die Erläuterungen im Kopf der Datei.)
Nach Durchsicht der Daten nehme ich an, daß es sich in allen Fällen ungeachtet der Unterschiede (Schreibung des Namens, fehlendes Geburtsdatum) stets um dieselbe Person handelt. Ich schlage daher vor, Benutzer dann im Rahmen der Migration zu deduplizieren, und bitte, mir das geplante Vorgehen unter Zuhilfenahme der angefügten Daten zu bestätigen.

Anmerk. EHLB (Fr. Kuffart): Bei den Benutzerdaten haben wir für die EH in den Stammdaten das Feld „Globale Notiz 1“ belegt, wenn es erforderlich war. Notiz 1 soll nur noch von Birkach belegt werden. Falls es von den Kolleginnen der anderen Bibliotheken für sinnvoll gehalten wird, müsste das Feld Notiz 1 für die EH pauschal umgesetzt werden auf Notiz 2.
Anmerk. BIRK (Fr. Wedemeier): Bisher hatten wir keine Zuordnung der Notizfelder zu Bibliotheken vorgenommen, ist das für die Zusammenspielung notwendig?

HBB hat in Globale Notiz 1 das Jahr, das anzeigt, das Adressangaben überprüft wurden u. ausgeliehen wurde Bei temporären Konten (Kurse), andere Angaben. Festgelegt hatten wir bei der Besprechung, dass in globale Notiz 3 bei (bisher) HBB u. OKR e. weitere mail-Adresse eingetragen wird, soweit vorhanden damit die Information nicht verloren geht.

Anmerk. EHLB (Fr. Kuffart): zum Punkt Globale Notiz habe ich mich an das Dokument „Feldbelegung von Benutzerdaten“ gehalten. Ich habe es so verstanden, dass Notizfeld 1 zukünftig für das Jahr (HBB) reserviert sein soll. Notizfeld 2 soll sonstige Notizen (alle Bibliotheken) enthalten und Feld 3 sonstige Mailadressen (alle Bibl.). Daher meine Frage, ob ein Umsetzen notwendig ist. Aber würde es wirklich sehr stören, wenn wir die „alten Notizen“ stehen lassen?

11. Bereinigung von Gebühren -------- bei der Deduplizierung der Nutzerdaten müssen die offenen Gebühren erhalten bleiben und zusammengeführt werden

EXL> Ja selbstverständlich.
Es werden nur offene Gebühren (s.Anhänge Stand:10.9.2013) übernommen. Historische, da bezahlte oder erlassene Gebühren werden verworfen.
Gebuehren_OKRB
Gebuehren_BIRK
Gebuehren_EVHS

12. Lieferanten und Lieferantenadressen ------ DIREKT kann bei OKRB gelöscht werden, Sonstige kann bei BIRK gelöscht werden, we 28.10. -> am 8.11.13 erl. Ste

EXL> Ein Löschen ist nicht möglich, da mit diesem Lieferanten (historische) Bestellungen verknüpft sind. Zur Herstellung der Eindeutigkeit der genannten Lieferantencodes schlage ich vor, diese vor der Datenmigration bereits im Quelldatenbestand wie folgt umzubenennen:

EVA -> EVA_O
DIREKT -> DIRECT_O
SONSTIGE -> SONSTIGE_H

Dublette Lieferantencodes wie folgt wurden im untersuchten Datenbestand ermittelt:
2 x DIREKT (BIRK und OKRB)
2 x EVA (EVHS und OKRB)
2 x SONSTIGE (BIRK und EVHS)\\ Da der Lieferantencode unbedingt eindeutig sein und die Zuordnung zu Bestellungen aus dem Quell-Datenbestand erhalten bleiben muß, ist es notwendig, diese manuell zu deduplizieren. Aufgrund deren geringer Zahl sollte dies kein Problem darstellen.

13. Die nachfolgenden Datenarten werden vollständig geladen, d.h. nicht dedupliziert: ---- bleibt so

abo = Abonnements
bud = Etats
vdr = Lieferanten
ord = Bestellungen
ivh = Allgemeine Rechnungen
ivp = Rechnungsposten
rtl = Umlauflisten
arr = Eingänge
btr = Etat-Transaktionen
lnh = Ausleih-Historie
orl = Bestell-Protokolle
prm = Benutzer-Berechtigungen
pub = Erscheinungsweisen
rtm = Umlaufteilnehmer
vad = Lieferanten-Adressen
vbu = Ausleihverbuchungen
vor = Vormerkungen/Bereitstellungen

14. Nachbearbeitung der Daten nach dem Laden und Verknüpfen --- soll die Nachbearbeitung vor der Migration erfolgen?, Listen d/e

EXL> Die Nachbearbeitung ist ein Arbeitsschritt im Rahmen der Migration, der automatisiert nach den von mir skizzierten Regeln abläuft. Zu Punkt d) finden Sie zwei Dateien im Anhang: „not700.txt“ und „notN01.txt“. Diese enthalten die Codes all jener Notationen, jeweils zusammengesetzt aus dem Kürzel des Quell-Datenpools und nachfolgender Identnummer, die aus den entsprechenden Titel-Feldern entfernt wurden. Was Punkt e) anbetrifft: Offen gestanden erkenne ich nicht, wozu Ihnen eine Liste neuer Identnummern von Verbuchungssätzen dienen kann. Die Notwendigkeit der unter e) erläuterten Nachbearbeitung ergibt sich aus der programm-internen Zugriffsmethode, wonach Exemplar- und ggfs. zugehöriger Verbuchungssatz stets zwingend dieselbe Identnummer besitzen müssen.
Einige Datenarten weisen Besonderheiten auf, die eine Nachbearbeitung erforderlich machen. Dies insbesondere, um im Sinne der Normalisierung Inkonsistenzen und „offene Enden“, also Ring-Verweise und Verweise auf nicht existierende Datensätze zu eliminieren.
a. Autoren, die per Feld 820 auf sich selbst verknüpft sind (Ringverweis) - Attach:aut_link.txt
b. Schlagworte, die per Feld 860, 870 oder 880 Verweise auf sich selbst oder nicht existierende Schlagworte enthalten (betrifft lediglich 14 Fälle). - Attach:swt_link.txt
c. Titel, die per GT0[1,2] oder QUE auf sich selbst verknüpft sind (Ringverweis) - Attach:tit_link.txt
d. Titel, die per 700 oder N01 auf Notationen verknüpft sind, die nicht migriert wurden - Attach:not700.txt , Attach:notN01.txt
e. Verbuchungen, da diese dieselbe Identnummer wie der zugehörige Exemplarsatz besitzen müssen

15. Zuordnung Exemplare zu Zweigstelle „HAH“ ---- alle Ex. mit Exemplarstatus Präsenz versehen

Exl> Dies ist bereits so vorgesehen.
Entladen aller Exemplare aus SONB aufgrund des vereinbarten Selektionskriteriums „MEX=3115*“, dann Belegen der Zweigstelle mit HAH und Reload.

sonstiges:

Nummernmuster
Nummernmuster im Service-Modul werden von Hrn. Bieber aufbereitet. Vor jeden Namen wird das Poolkürzel gesetzt.
im OKR-Pool würde beispielsweise "A11" zu "OA11"

Zeitrahmen für Migration
Antwort von Hrn.Bieber vom 27.6.13:
Wir gehen davon aus, dass auf der Grundlage einer Kopie Ihrer Datenbestände das Migrationsverfahren entwickelt und dabei mindestens eine Testmigration durchgeführt wird. Die reine Laufzeit der produktiven Datenmigration wird sich schließlich im Rahmen von 1-2 Tagen bewegen.

Pick-up location
Nutzer sollen für beliebige Medien aus beliebigen Zweigstellen einen Ausgabeort bestimmen können.
Anforderung: Transportbeleg für Ausgabe-Zweigstelle
Antwort von Hrn.Bieber vom 27.6.13:
Die Angabe des Abholortes (einer Zweigstelle) wird sowohl beim Vormerken via OPAC als auch mit dem GUI ermöglicht. Wurde ein anderer Ort als die Heimat-Zweigstelle des Mediums gewählt, erfolgt anläßlich der Bereitstellung des Mediums ein entsprechender Vermerk im Benachrichtigungs-Schreiben an den Nutzer. Zugleich wird ein Transportbeleg für die besitzende Bibliothek erzeugt (gedruckt).

Online-Ressourcen Anforderung:
Mit Online-Ressourcen sind die elektronischen Angebote der Bibliothek gemeint, also alle Titel mit folgender Feldbelegung für die Materialbenennung und die Umfangsangabe:
334 Elektronische Ressource
433 Online-Ressource
Diese Titel sollen nicht in das Zweigstellensystem übernommen werden. Sie sollen entfernt werden.
Andere Titel mit Url-Feldern sollen erhalten bleiben, wie sie sind.
SWB: Online-Ressourcen müssen für die Abzugsjobs gesperrt werden -> Fr. Maurer

Migration