• Anzeigen
• Bearbeiten
• Versionen
• Anhängen
• Druckansicht

VerfahrenZurMigration

zurück zu Migration

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:

OKRB = Evangelischer Oberkirchenrat
BIRK = Haus Birkach
EVHS = Evangelische Hochschule Ludwigsburg
BOLL = Bad Boll
DENK = Denkendorf
BIRU = Birkach Unterrichtsmodelldatei
HKIM = Hochschule für Kirchenmusik
KLOS = Kloster Kirchberg
MUSE = Landeskirchliches Museum
MEDI = Medienzentrale
SEEL = Seminar für Seelsorgefortbildung
SONB = Sonstiger Bestand
REUT = Dekanat Reutlingen
VKIM = Verband für Kirchenmusik
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

Für diese Datenarten erfolgt eine Deduplizierung nach folgenden Regeln:
Vorangig werden Dubletten aufgrund der Felder 025 = „Überreg. IDN“, 026 = „Reg. IDN“ und 028 = „Normdaten IDN“ ermittelt. Nachrangig erfolgt die Dubletten-Ausscheidung aufgrund der Ansetzungsformen (Felder 800), bei Schlagworten zusätzlich über die Felder 801ff (Kettenglieder).
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.

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, Teil 2 erübrigt sich??

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:

Titelsätze werden nach folgenden Regeln dedupliziert:
Vorangig werden Dubletten aufgrund der Felder 025 = „Überreg. IDN“, 026 = „Reg. IDN“ sowie ISBN, ISSN und ISMN ermittelt. Nachrangig erfolgt die Dubletten-Ausscheidung aufgrund einer Kombination von Ansetzungssachtitel und Hauptsachtitel mit Autor, Körperschaft und Erscheinungsjahr.
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.

Die aus dem ersten Ladelauf resultierenden Dubletten werden anschließend nochmals importiert. Da diesmal eine modifizierte Generierung zum Einsatz kommt, bei der allein die Verbund-Identnummer (026) zur Dubletten-Ausscheidung definiert ist, gelingt das Laden dieser Sätze ohne daß Rest-Dubletten verbleiben.

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. Für die Datenpools OKRB, BIRK und EVHS finden Sie eine Liste der aufgrund identischer Barcodes ermittelten Dubletten in den angefügten Dateien: Attach:barcodes_okrb.txt, Attach:barcodes_evhs.txt, Attach:barcodes_birk.txt. (Merkwürdig erscheinende, ggfs. zu korrigierende Barcodes sind gleichfalls enthalten.) Relativ wenige Überschneidungen bei Exemplar-Barcodes gibt’s gleichfalls wie folgt:
MEDI in OKRB enthalten: STG117$1797646, STG117$1797719
MUSE in OKRB enthalten: STG117$1798952, STG117$2106949
Dublettenbereinigung erfolgt bereits in den einzelnen Bibliotheken

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.
Attach:Gebuehren_OKRB.pdf
Attach:Gebuehren_BIRK.pdf
Attach:Gebuehren_EVHS.pdf

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 „HAHA“ ---- 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 HAHA und Reload.