Archivobjekt öffnen

Überführung bibliographischer Daten in ein
XML-Datenbanksystem
von
Volker Wildi
Bachelorarbeit
Eingereicht von Volker Wildi
zur Erlangung des akademischen Grades eines
Bachelor of Science (B.Sc.)
in Information Engineering
Erstgutachter: Prof. Dr. Scholl
Zweitgutachter: Prof. Dr. Deussen
FB Informatik und Informationswissenschaft
Universität Konstanz
April, 2005
Überführung bibliographischer Daten in ein
XML-Datenbanksystem
Volker Wildi
[email protected]
Universität Konstanz, 2005
Erstgutachter: Prof. Dr. Scholl
Zweitgutachter: Prof. Dr. Deussen
Zusammenfassung
Diese Bachelorarbeit stellt eine Lösung zur Konvertierung aus dem MAB2-Format, einem Austauschformat für deutschsprachige Bibliotheken, in das XMLFormat vor. Diese Lösung entstand im Rahmen des MedioVis-Projektes aus der
Notwendigkeit einer Datenbankanbindung an der Universit ät Konstanz. MedioVis ist eine moderne Art einer Suchmaschine mit vielen Innovationen.
Als erstes wurde ein Datenmodell in XML konstruiert, um die Bibliotheksdaten adäquat darin abzuspeichern. Zweitens wurden die bestehenden Bibliotheksdaten in dieses XML-Datenschema konvertiert. Als drittes wurde eine L ösung für
das Einspielen der täglichen Updates der Bibliotheksdaten vorgestellt. Abschließend wurde eine Evaluation an diesem System durchgeführt.
Der Einsatz von XML wurde deshalb gewählt, da neue Datenbanksysteme
effizient damit umgehen können. Beispiele für solche Datenbanksysteme sind
z. B. Pathfinder [4], TIMBER [17], X-Hive [21], usw.
i
Inhaltsverzeichnis
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1
Thematischer Hintergrund . . . . . . . . . . . . . . . . . . . . . . . .
1
2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1
2.2
2.3
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Aufbau einer XML-Datei . . . . . . . . . . . . . . . . . . . .
3
2.1.2
Festlegung der Dokumentstruktur . . . . . . . . . . . . . . .
4
2.1.3
Entitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Anfragen mit XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.1
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
Allgemeiner Aufbau . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.3
Abkürzungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.4
Pfadausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.5
Prädikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Der MAB2-Standard . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.1
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.2
Datensatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.3
Datenfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1
3.2
3.3
Konstruktion des XML-Datenschemas . . . . . . . . . . . . . . . . .
17
3.1.1
Grundstruktur . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.2
Umsetzung einzelner Datensätze in XML . . . . . . . . . . .
19
Konvertierung von MAB2 nach XML . . . . . . . . . . . . . . . . . .
21
3.2.1
Grundstruktur . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2.2
Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.3
Einsatz einer Stoppwortliste . . . . . . . . . . . . . . . . . . .
24
Einfügen von Aktualisierungen . . . . . . . . . . . . . . . . . . . . .
26
ii
3.3.1
3.3.2
Allgemeiner Aufbau . . . . . . . . . . . . . . . . . . . . . . .
Umsetzung in C++ . . . . . . . . . . . . . . . . . . . . . . . .
4 Leistungsmessung . . . . . . . . . . . . . . . . . .
4.1 Das eingesetzte Datenbanksystem . . . . . .
4.2 Vergleich zwischen den Formaten . . . . . . .
4.3 Typische Suchanfragen . . . . . . . . . . . . .
4.3.1 Identifizieren von typischen Anfragen
4.3.2 Erstellung von Suchanfragen . . . . .
4.3.3 Bessere Suchmöglichkeit . . . . . . . .
4.3.4 Bewertung der Suchanfragen . . . . .
4.3.5 Verbesserungsmöglichkeiten . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
26
28
33
33
34
36
36
37
41
42
43
5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Anhang A Zuordnung der XML-Tags . . .
A.1 Allgemeine Felder . . . . . . . . . .
A.2 Titeldatei . . . . . . . . . . . . . . .
A.3 Personendatei . . . . . . . . . . . .
A.4 Körperschaftsdatei . . . . . . . . .
A.5 Schlagwortdatei . . . . . . . . . . .
A.6 Medientypen . . . . . . . . . . . . .
A.7 Schlagwortattribute . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
47
47
48
52
53
53
54
55
Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
iii
iv
Kapitel 1
Einführung
1.1
Thematischer Hintergrund
Die Idee dieser Arbeit entstand aus der Notwendigkeit für eine Datenbankanbindung der Bibliotheksdaten für das Projekt MedioVis [11] am Fachbereich MenschComputer-Interaktion von Prof. Dr. Reiterer an der Universit ät Konstanz im Jahre 2004. Bei MedioVis handelt es sich um eine grafische Benutzeroberfl äche zum
Suchen und Stöbern in multimedialen Bibliotheken. Zusätzlich bietet MedioVis
weitere Innovationen.
Für MedioVis müssen die Mediotheksdaten aufbereitet werden, da sie in einem speziellen Format vorliegen. Die Entwicklung einer Lösung ist Gegenstand
dieser Arbeit. Zu Beginn der Testphase wurde ein kleiner Datenbankabzug von
knappen 10 MB in einer einfachen Textdatei gespeichert, f ür eine große Datenbank ist diese Lösung jedoch nicht anwendbar. Zu Testzwecken wurde von Seiten
des MedioVis-Projekts eine PostgreSQL-Datenbank [18] aufgesetzt, die allerdings
nicht alle Daten der Mediothek enthielt.
Problematisch an den Daten ist, dass nicht jeder Datensatz (z. B. ein m ögliches
Medium) gleich aufgebaut ist. Ein Medium in einer Bibliothek kann ein Buch, eine Zeitschrift, eine DVD oder sonst ein veröffentlichtes Werk sein. Weiter können
mehrere Verfasser ein Medium verfasst haben. Würde man dieses Szenario in einer relationalen Datenbank wie PostgreSQL realisieren wollen, w ürden aufgrund
der gewünschten Normalisierung, also zur Vermeidung der Abspeicherung von
redundanten Daten, sehr viele Tabellen entstehen. Diese Tabellen k önnen u. U.
sehr viele Nullwerte enthalten, welche sich negativ auf die Anfrageperformance
auswirken. Für die Zukunft ist geplant noch weitere Datenbanken anzubinden,
wie z. B. die Internet Movie Database (IMDb), diese können nicht ohne weiteres in
die bestehende Datenbank eingefügt werden.
1
2
KAPITEL 1. EINFÜHRUNG
Eine unstrukturierte Datei, wie z. B. Volltext, hält sich nicht an strukturelle
Vorgaben. Ein solcher Text weist keinerlei Struktur auf. Im Gegensatz dazu, zeichnen sich RDBMS gerade durch ihre Strukturiertheit aus. Diese RDBMS haben
folglich Probleme beim Umgang mit unstrukturierten Daten. Genau diese L ücke
schließt XML praktisch, indem einzelne Textbereiche in Strukturtags gesetzt werden, um eine gewünschte Struktur zu erhalten. Diese Art der Abspeicherung
wird als semistrukturiert bezeichnet. Für den komplexen Aufbau dieser bibliographischen Daten eignet sich daher XML sehr gut, da die Schemainformationen
mit den Daten abgespeichert werden.
Im Ausland existieren bereits erste Bestrebungen zur Umsetzung der bibliographischen Daten in das XML-Format, darunter für den nordamerikanischen
Standard MARC (Machine-Readable Cataloging) mit der Bezeichnung MARCXML
[15]. Dies sollte auch Motivation sein, um ebenfalls eine XML-L ösung für die
deutschsprachigen Bibliotheken zu konstruieren. Es dürfte eigentlich nur noch eine Frage der Zeit sein bis sich XML als Austauschformat der Bibliotheken durchsetzen wird.
All diese Gründe sprachen für den Einsatz einer XML-Datenbank für MedioVis. Somit ist nun ein weiterer Fachbereich an der Entwicklung an MedioVis beteiligt. Bei diesem Fachbereich handelt es um den Lehrstuhl Datenbanken und
Informationssysteme von Prof. Dr. Scholl, welcher das Datenbank-Backend entwickelt. Die Datenbank sollte anfänglich nur die Mediotheksdaten enthalten, allerdings auch mit Ausblick auf die Erfassung der ganzen Bibliotheksdaten.
Kapitel 2
Grundlagen
2.1
XML
In diesem Abschnitt sollen kurz die Eigenschaften von XML (Extensible Markup
Language) beschrieben werden, die dem Leser vielleicht nicht gel äufig sind und
bei dieser Arbeit verwendet wurden. Die gesamte Spezifikation von XML findet
sich unter [23].
2.1.1 Aufbau einer XML-Datei
Bei XML handelt es sich um ein einfaches und sehr flexibles Textformat. Ein wohlgeformtes XML-Dokument enthält einen oder mehrere Elemente, die durch die
Start- und Endtags begrenzt sind, und ordentlich ineinander verschachtelt sein
müssen. Die Tags können also beliebig verschachtelt werden, dürfen sich aber
nicht überlappen. Es entsteht eine sehr flexible Struktur. Listing 2.1 zeigt wie eine Film-Videokassette in XML beschrieben werden könnte. Dieser Datei können
noch weitere Felder hinzugefügt werden, ohne dass sie nicht mehr wohlgeformt
ist, vorausgesetzt sämtliche Felder sind wohlgeformt.
Soll nun die Flexibilität einer XML-Datei eingeschränkt werden, also eine bestimmte Struktur aufweisen um gültig zu sein, so müssen feste Regeln definiert
werden. Diese Regeln geben die Reihenfolge der XML-Tags vor und werden in einer so genannten DTD (Document Type Definition) gespeichert. H ält sich ein wohlgeformtes XML-Dokument an die Einschränkungen aus der DTD, so wird das
Dokument auch als gültig bezeichnet.
3
4
KAPITEL 2. GRUNDLAGEN
Listing 2.1: Einfaches Beispiel zu XML
<?xml v e r s i o n = ” 1 . 0 ” encoding = ”UTF−8” ?>
<f i l m e>
<vhs id=” 001 ” genre=” a c t i o n ”>
< t i t e l >Bad Boys − Harte Jungs</ t i t e l >
<j a h r>1996</ j a h r>
<s c h a u s p i e l e r>W i l l Smith</ s c h a u s p i e l e r>
<s c h a u s p i e l e r>Martin Lawrence</ s c h a u s p i e l e r>
<r e g i e>Michael Bay</ r e g i e>
</vhs>
</ f i l m e>
2.1.2 Festlegung der Dokumentstruktur
Die Regeln innerhalb der DTD werden mit Hilfe von regulären Ausdrücken definiert. Die Häufigkeit einzelner Elemente kann mit Hilfe von ’?’, ’+’ oder ’*’
nur grob eingeschränkt werden. Bei der Angabe von ’+’ oder ’*’ hinter dem Elementnamen kann keine obere Grenze angegeben werden. Falls eine weitere Einschränkung der Häufigkeitsangabe von Elementen erwünscht ist, so ist ein Übergang zu XML Schema [22] oder zu Relax NG [19] notwendig. Diese beiden Ans ätze
sind recht neu und werden zur Zeit nur teilweise ausreichend unterst ützt, deshalb wurden sie bei dieser Arbeit nicht eingesetzt. Eine bessere Unterst ützung
oder eine feinere Angabe der Häufigkeiten in der Zukunft könnten es notwendig
machen, die bisherige DTD in eine der Alternativen zu überführen.
Listing 2.2 zeigt eine Beispiel-DTD für eine Filmsammlung. Die möglichen Filme liegen auf DVD oder VHS vor. Jeder Film hat immer einen Titel, ein Ver öffentlichungsjahr, einen Regisseur, einen oder mehrere Schauspieler und vielleicht eine Angabe der Staffel, falls es sich um eine Serie handelt. Jedes Medium hat eine
eindeutige Nummer und wird einfachheitshalber nur einem bestimmten Genre
zugeordnet. Beide werden als Attribut beim Medientyp angegeben.
2.1.3 Entitäten
Die Merkmale titel, staffel, jahr, schauspieler und regie wiederholen sich
bei beiden Medientypen in der DTD, wobei dann die gleichen Zeilen stehen
müssten. Bei komplexeren Elementen leidet mit der Zeit die Übersichtlichkeit.
Deshalb gibt es unter XML das Konstrukt Entität.
Das Schlüsselwort ENTITY hat drei verschiedene Bedeutungen. Erstens kann
es zur Ersetzung von Strings dienen, wie ein #define in der Programmiersprache
C bzw. C++. Zweitens als Verknüpfung mit einer anderen XML-Datei oder als
2.1. XML
5
Listing 2.2: DTD für eine Filmsammlung
< ! ENTITY % A l l g F e l d e r
”titel ,
staffel ? ,
jahr ,
schauspieler + ,
regie
” >
< !ELEMENT filmsammlung
( dvd | vhs ) >
< !ELEMENT dvd
< ! ATTLIST dvd
(% A l l g F e l d e r ; ) >
id ID #REQUIRED
genre CDATA #REQUIRED >
< !ELEMENT vhs
< ! ATTLIST vhs
(% A l l g F e l d e r ; ) >
id ID #REQUIRED
genre CDATA #REQUIRED >
< !ELEMENT
< !ELEMENT
< !ELEMENT
< !ELEMENT
< !ELEMENT
( #PCDATA)
( #PCDATA)
( #PCDATA)
( #PCDATA)
( #PCDATA)
titel
jahr
staffel
regie
schauspieler
>
>
>
>
>
Platzhalter von Nicht-XML-Daten. Im Beispiel und bei dieser Arbeit wird die
erste Bedeutung benutzt.
Der Zugriff auf eine vorher definierte Entität erfolgt, indem dem Namen der
Entität ein ’%’ vorangestellt und am Ende ein ’;’ angehängt wird. Für die Entität
AllgFelder sieht dies wie folgt aus ’%AllgFelder;’. Allerdings k önnen auch einzelne Datenfelder zu bestimmten Medientypen hinzugef ügt werden, indem an
die allgemeinen Datenfelder mit dem Sequenzoperator ’,’ die erweiterten Felder
angereiht werden. So könnte vielleicht auch die Angabe der Kapitel auf der DVD
interessant sein und würde deshalb ein zusätzliches optionales Attribut namens
kapitel bekommen. Listing 2.3 zeigt wie dies in der DTD dann aussehen w ürde.
Ein Beispiel eines Datenbankauszugs zeigt Listing 2.4.
Listing 2.3: Erweiterung der Attribute
< !ELEMENT dvd
< !ELEMENT k a p i t e l
(% A l l g F e l d e r ; , k a p i t e l ? ) >
( #PCDATA) >
KAPITEL 2. GRUNDLAGEN
6
Listing 2.4: XML-Beispieldokument
<?xml v e r s i o n = ” 1 . 0 ” encoding = ”UTF−8” ?>
< !DOCTYPE filmsammlung SYSTEM ” filmsammlung . dtd ”>
<f i l m e>
<vhs id=” 001 ” genre=” a c t i o n ”>
< t i t e l >Bad Boys − Harte Jungs</ t i t e l >
<j a h r>1996</ j a h r>
<s c h a u s p i e l e r>W i l l Smith</ s c h a u s p i e l e r>
<s c h a u s p i e l e r>Martin Lawrence</ s c h a u s p i e l e r>
<r e g i e>Michael Bay</ r e g i e>
</vhs>
<dvd id=” 002 ” genre=” a c t i o n ”>
< t i t e l >Blade</ t i t e l >
<j a h r>1999</ j a h r>
<s c h a u s p i e l e r>Wesley Snipes</ s c h a u s p i e l e r>
<s c h a u s p i e l e r>Stephen D o r f f</ s c h a u s p i e l e r>
<r e g i e>Stephen Norrington</ r e g i e>
</dvd>
</ f i l m e>
2.2
Anfragen mit XQuery
Die im Bibliothekskontext auftretenden Datenbanken erfordern effektive Techniken zur Recherche in XML-Dokumenten. Hierfür ist der Einsatz der XML-Anfragesprache XML Query (XQuery) nahe liegend [16, 6]. Die bisherige Forschung
in der Datenbanktechnologie brachte effiziente XQuery-Implementierungen zur
XML-Verarbeitung hervor, wie z. B. Pathfinder [4], TIMBER [17] oder X-Hive [21].
Dies zeigt, dass Datenbanklösungen existieren, die riesige XML-Dokumente effizient verarbeiten können.
2.2.1 Einführung
XQuery wurde 1998 durch das W3C als strikte Anfragesprache spezifiziert. Im
Gegensatz zu SQL können keine neuen Relationen bzw. XML-Strukturen angelegt werden. Der Syntax von XQuery ist für XML-Umsteiger etwas gewöhnungsbedürftig, stellt sich aber nicht allzu schwierig dar. Ein integraler Bestandteil von
XQuery 1.0 ist XPath 2.0 [24], wodurch ein korrekter Ausdruck in XQuery auch
in XPath 2.0 gültig ist und umgekehrt. Dadurch kann in XQuery auf die meisten
Funktionen von XPath 2.0 zugegriffen werden. XQuery soll einmal das werden,
was SQL bei den relationalen Datenbanken heute ist.
2.2. ANFRAGEN MIT XQUERY
7
2.2.2 Allgemeiner Aufbau
Eine XML-Datei ist physikalisch gesehen nur eine reine Textdatei, kann also mit
einem Texteditor gelesen und bearbeitet werden. Betrachtet man aber die Verschachtelungen der einzelnen XML-Tags, entsteht dadurch eine logische Baumstruktur. Abbildung 2.1 zeigt die graphische Darstellung der XML-Datei aus Listing 2.4, wobei aber aus Gründen der Übersichtlichkeit auf die Darstellung der
Attributknoten verzichtet wurde.
Mit der gegebenen Baumstruktur gibt es fünf verschiedene Knotentypen zu
unterscheiden. Zuerst wäre der Elementknoten zu nennen, der wiederum mehrere
Kindknoten besitzen kann. Der Textknoten enthält einfachen Text und ist immer
ein Blatt im Baum. Die dritte Knotenart sind die Attributknoten, diese spielen eine besondere Rolle, da sie keine Kinder des zugehörigen Elementknotens sind,
sondern dem Elementknoten ’gehören’. Dies ist auch der Grund, warum die Attributknoten nicht in der Ergebnismenge der XQuery-Achsen vorkommen. Abschließend gibt es noch die Kommentarknoten und die Processing Instruction Knoten, letztere enthalten Anweisungen für die Anwendung und werden vom XMLProzessor nicht verarbeitet. Diese beiden sind ebenfalls Blattknoten im Baum.
Der oberste Elementknoten in einem Baum wird als Wurzelknoten bezeichnet.
In Abbildung 2.1 trägt der Wurzelknoten den Namen filme. Alle anderen Knoten
sind Kindknoten von diesem Knoten. Im Beispieldokument sind das die Knoten
mit der Bezeichnung Blade, 1996, Stephen Norrington usw.
Zum Vergleich ist ein Verzeichnis auf einem Dateisystem auch in einer Baumstruktur aufgebaut. Ein Ordner kann mehrere Unterverzeichnisse und auch Dateien enthalten. Diese Ordner sind die Elementknoten und die einzelnen Dateien
sind Blätter im Baum. Um die Stelle zu finden, wo eine bestimmte Datei abgelegt ist, ist ein Pfad anzugeben. Auf einem UNIX-System würde dieser wie folgt
aussehen: /etc/modules.conf. Damit ist im Ordner etc direkt unter dem Wurzelverzeichnis ’/’ die Datei modules.conf zu finden. Allerdings kann in einem
Dateisystem immer nur eine Datei mit dieser Bezeichnung existieren. In XML dagegen kann es durchaus mehrere Knoten mit der gleichen Bezeichnung geben.
Wie der Zugriff auf einen mehrfach vorkommenden Knoten in XQuery erfolgt,
wird im Abschnitt 2.2.5 näher beschrieben.
Der Baum einer XML-Datei ist – im Gegensatz zum Dateisystem – geordnet,
d. h. die Reihenfolge der XML-Knoten ist durch die Dokumentordnung vorgegeben. Die Dokumentordnung entspricht der Abarbeitung der Knoten bei einer
Tiefensuche von links nach rechts. Mit anderen Worten, ist dies die Originalreihenfolge der Knoten im Dokument. In Abbildung 2.1 geben die Nummern neben
Tagnamen diese Reihenfolge an.
KAPITEL 2. GRUNDLAGEN
8
ancestor
3
4
titel
5 jahr
2
dvd
7
schauspieler
1
filme
13
9
schauspieler
11
regie
”Blade”6”1996” 8 ”Wesley 10”Stephen 12 ”Stephen
Snipes” Dorff” Norrington”
preceding
descendant
14
15
titel
vhs
...
”Bad
Boys”
following
Abbildung 2.1: Baumdarstellung der XML-Datei
Bei genauerer Betrachtungsweise dieser Baumstruktur fällt auf, dass diese
Knoten alle miteinander in Beziehung stehen. Es gibt vier Hauptbeziehungen,
die als Vorfahre-, Nachkomme-, Vorgänger- und Nachfolger-Beziehung bekannt
sind. Diese Beziehungen werden in XQuery als Achsen bezeichnet. So ist z. B. der
Knoten dvd ein Vorfahre (ancestor) und der Knoten Wesley Snipes ein Nachkomme (descendant) vom Knoten regie. Die beiden schauspieler-Knoten z. B. sind
Vorgänger (preceding) vom Knoten regie. Nachfolger (following) sind sind z. B. die
Knoten vhs und titel. Eine wichtige Beobachtung dieser vier Regionen ist, dass
sie symmetrisch und disjunkt sind. Mit anderen Worten ausgedr ückt, liegen die
descendant- und die ancestor-Achse sich gegenüber, genauso wie die beiden Achsen preceding und following. Jeder Knoten ist in einer – und nur in einer – der vier
Regionen enthalten. Der aktuelle Knoten bezeichnet man auch als Kontextknoten.
In Abbildung 2.1 sind diese vier Hauptachsen farbig eingefärbt für den Kontextknoten regie. Dabei entsprechen die Farben den Achsen ancestor, descendant,
preceding und following.
Tabelle 2.1 gibt einen Überblick über die insgesamt 12 Achsen von XQuery.
2.2.3 Abkürzungen
Häufig benutzte Achsen können in XQuery auch abgekürzt werden. Die Achse attribute kann dadurch abgekürzt werden, indem ein ’@’ vor den Namen
des Attributes gesetzt wird. Der Grund für das Zeichen ’@’ lässt sich dadurch
erklären, da es als ’at’ ausgesprochen wird und daher im Wort ’attribute’ enthalten ist. Hingegen wird der Schritt descendant-or-self::node() durch ’//’
abgekürzt. Die Abkürzung für den Vaterknoten und den aktuellen Knoten werden, wie bei einem Dateisystem gewohnt, mit ’..’ und ’.’ abgek ürzt. Wird nur
ein Tagname angegeben, so ist dies die Abkürzung für die child-Achse.
2.2. ANFRAGEN MIT XQUERY
Achse α
ancestor
ancestor-or-self
child
descendant
descendant-or-self
following
following-sibling
parent
preceding
preceding-sibling
self
attribute
9
Erreichbare Knoten vom Kontextknoten c
Alle Vorfahren von c
Wie ancestor plus c
Kinder von c
Alle Nachkommen von c
Wie descendant plus c
Alle Nachfolger von c
Geschwister von c in der Nachfolger-Region
Vater von c
Alle Vorgänger von c
Geschwister von c in der Vorgänger-Region
c
Attribute von c
Tabelle 2.1: XQuery-Achsen
2.2.4 Pfadausdrücke
Eine XQuery-Anfrage besteht immer aus einem Pfadausdruck, dem Hauptkonstrukt von XQuery. Jeder Pfadausdruck besteht aus einem oder mehreren Schritten, die durch einen ’/’ getrennt sind. Ein Pfadausdruck gibt die Navigation
durch den Baum an. Allgemein ausgedrückt, sieht ein Pfadausdruck wie folgt
aus:
s0 /s1 / . . . /sn .
Absolute Pfadangaben beginnen, wie auch bei Dateisystemen, mit einem ’/’
am Anfang. Dieser Knoten wird auch als Dokumentknoten bezeichnet und ist eigentlich ein virtueller Knoten, welcher auf der Spitze jedes Dokumentes sitzt.
Ein Schritt wiederum besteht aus einer Achse α und einem Knotentest ν. Der
Knotentest filtert die Knoten aus, die nicht der spezifizierten Eigenschaft entsprechen. Tabelle 2.2 zeigt eine Übersicht über die verschiedenen Knotentests. Typischerweise sieht ein Schritt so aus:
α0 :: ν0 /α1 :: ν1 / . . . /αn :: νn .
Die beiden Knotentests ∗ (Wildcard) und Tagname werden als Namenstests
bezeichnet. Die restlichen vier Knotentests werden Typentest (engl. kind test) genannt.
Der Zugriff auf einen Dokumentknoten erfolgt mit der XQuery-Funktion doc,
dieser wird der Name der zu öffnenden Datei übergeben. Bei den nachfolgenden
Anfragen wird diese nicht mehr mit angegeben, da die Anfragen entscheidend
KAPITEL 2. GRUNDLAGEN
10
Node Test ν
node()
∗
Tagname t
text()
comment()
processing-instruction(t)
liefert Knoten der Art
jeder Knoten, egal welchen Typs
nur Elementknoten
nur Elementknoten mit Bezeichnung t
nur Textknoten
nur Kommentarknoten
nur Processing Instructions der Form <?t . . .? >
Tabelle 2.2: Mögliche Knotentests ν
sind und nicht die Datei, auf der sie angewendet werden. Um nun auf den Film
’Blade’ zuzugreifen, wird folgende Anfrage eingegeben:
doc ( ” dok . xml ” ) /descendant : : f i l m e / c h i l d : : dvd [ c h i l d : : t i t e l /
t e x t ( ) = ” Blade ” ]
Das Ergebnis einer Anfrage wird als Sequenz zurückgegeben, was einer Neuerung zu XPath 1.0 entspricht. Diese Sequenz kann als einfache Liste betrachtet
werden mit keinen, einem oder mehreren Elementen. Diese Elemente k önnen alle
unterschiedlichen Typs sein, z. B. Knoten aus dem XML-Baum, Strings oder Zahlen. Darüber hinaus sind diese Sequenzen flach, können also nicht verschachtelt
werden. Der XPath- bzw. XQuery-Prozessor würde aus der folgenden Sequenz
(1, 2, 3, (”vier”, ”fünf”, ”sechs”), 4, 5)
diese ’flachgeklopfte’ Sequenz machen
(1, 2, 3, ”vier”, ”fünf”, ”sechs”, 4, 5)
Weiter ist das Ergebnis einer Anfrage immer duplikatfrei und die Reihenfolge
der zurückgegebenen Knoten erfolgt in Dokumentordnung.
2.2.5 Prädikate
Wie weiter oben schon bereits erwähnt, können in einem XML-Dokument mehrere Knoten mit dem gleichen Tagnamen vorkommen. Um auf diese Knoten zuzugreifen oder eine Bedingung anzugeben, werden in XQuery so genannte Pr ädikate benutzt. Diese Prädikate werden an einen Schritt mit eckigen Klammern angefügt. Für den Schritt s und das Prädikat p würde dies wie folgt aussehen: s[p],
dabei kann das Prädikat p eins von drei möglichen Typen sein.
2.3. DER MAB2-STANDARD
11
Ist p ein numerischer Ausdruck, wobei p ≥ 1 ist, dann würde der p − te Knoten
der Sequenz des Schrittes s zurückgegeben, falls dieser überhaupt existiert. Dabei
gilt es zu beachten, dass bei Rückwärts-Achsen, wie z. B. ancestor, preceding oder
parent, die Nummerierung rückwärts erfolgt.
Bei obigem Beispiel spielen immer mehrere Schauspieler mit. Um nun alle
Schauspieler aufzulisten, die an zweite Stelle angegeben worden sind, lautet die
XQuery-Anfrage:
/child : : filme/child : : ∗ / schauspieler [ 2 ]
Handelt es sich bei p um einen boolschen Ausdruck, dann werden nur die Kontextknoten zurückgegeben, bei dem der Ausdruck p wahr ist. Die nachfolgende
Anfrage listet alle Filmtitel auf, die im Jahre 1999 veröffentlicht wurden.
/ c h i l d : : f i l m e / c h i l d : : ∗ [ c h i l d : : j a h r = 1999]/ c h i l d : : t i t e l
Ist p ein Pfadausdruck, dann wird jeder Kontextknoten c vom Schritt s zur ückgeliefert, falls der Pfadausdruck p mindestens einen Knoten enth ält. Das nachfolgende Listing soll dies besser verdeutlichen, da es alle Filme ausgibt, die eine
Staffelangabe besitzen, also Serien sind.
/ c h i l d : : f i l m e / c h i l d : : ∗ [ c h i l d : : s t a f f e l ]/ c h i l d : : t i t e l
Beim Einsatz von Prädikaten ist besonders darauf zu achten, dass diese eine
höhere Priorität haben, weshalb sie auf den Schritt angewendet werden und nicht
auf den ganzen Pfadausdruck. Somit gilt:
/s0 /s1 [p] 6= (/s0 /s1 )[p]
2.3
Der MAB2-Standard
2.3.1 Einführung
Die Daten der Bibliothek sind im so genannten MAB2-Format (Maschinelles Austauschformat für Bibliotheken, Version 2) [13] gespeichert. Die Version 2 l öste im Jahre 1995, nach zweijähriger Entwicklungszeit, die Version 1 von 1972 ab. Es erhielt
alle notwendigen inhaltlichen, strukturellen und technischen Erweiterungen, um
auch in Online-Umgebungen eingesetzt werden zu können. So sind z. B. ein neuer Zeichensatz, neue Strukturen und Segmente hinzugekommen und die Satztypen in der Titeldatei wurden gekürzt.
KAPITEL 2. GRUNDLAGEN
12
Dieses MAB2-Format ist das Standardformat deutschsprachiger Bibliotheken
und wurde von der DDB (Die Deutsche Bibliothek) [7] in Frankfurt am Main spezifiziert. Es dient primär als Austauschformat der Bibliotheken untereinander, um
auch gespeicherte bibliographische Daten, Norm- und Lokaldaten weiterzugeben. Dieser Standard wird heute noch immer durch den MAB-Ausschuss, einer
Expertengruppe der DDB gepflegt und weiterentwickelt. Das zeigt sich daran,
dass im Jahre 2002 die vierte Ergänzung ausgeliefert wurde. Die Leitung dieses
Ausschusses hat die DDB, die aus Vertretern der wichtigsten Einrichtungen des
deutschen Bibliothekswesens besteht. Aber es steht jedem MAB-Anwender zu,
Anträge auf Änderung oder Erweiterung zu stellen. Dies könnten zusätzliche
Anforderungen durch neue Medientypen, die Unicode-Umstellung oder neue
Funktionalitäten, wie Verbundleihe, sein [12].
Heutzutage besteht MAB2 aus fünf einzelnen Datenformaten:
• MAB-Format für bibliographische Daten (MAB-TITEL)
• MAB-Format für Personennamen (MAB-PND)
• MAB-Format für Körperschaftsnamen (MAB-GKD)
• MAB-Format für Schlagwörter (MAB-SWD)
• MAB-Format für Lokaldaten (MAB-LOKAL)
und zwei weiteren provisorischen MAB2-Formaten:
• MAB-Format für Adress- und Bibliotheksdaten (MAB-ADRESS)
• MAB-Format für Klassifikations- und Notationsdaten (MAB-NOTAT)
Die Dateinamen der einzelnen MAB2-Formate eines Datenbankabzugs unterscheiden sich nur in ihrer Dateiendung. So trägt die Titeldatei die Dateiendung
’t’ und die Körperschaftsdatei ein ’k’. Für die restlichen Dateien wird dies analog
fortgesetzt.
Jedes dieser Datenformate basiert auf einer einheitlichen, integrierten und f ür
alle Formate gültigen Feldstruktur. Die MAB-Dokumentation [8] definiert und
verdeutlicht durch zahlreiche Beispiele die Anwendung dieses Standards. Allerdings kann diese Arbeit nur eine allgemeine Einführung in diesen Standard
geben, da dieser Standard sehr komplex ist und einiges Wissen aus dem Bibliothekarswesen voraussetzt.
2.3. DER MAB2-STANDARD
13
2.3.2 Datensatz
Jede der oben erwähnten MAB2-Dateien enthält mehrere Datensätze, so beinhaltet z. B. die Titeldatei Datensätze, die die erfassten Medien darstellen. Zwei
Datensätze werden durch eine Leerzeile voneinander getrennt. Ein Datensatz
enthält mehrere Datenfelder, welche dann die eigentlich erfassten Daten aufweisen. Listing 2.5 zeigt ein Beispiel für einen vollständigen Datensatz aus der Titeldatei. Analog dazu ist der Aufbau der anderen Dateien.
Listing 2.5: Ein MAB2-Datensatz
### 00803 nM2 .01200024
h
001 00036210
029 mb
002 a19850101
003 20020823
005 n20040826
026 g8009202269
030 dz1dcr |||||17
037 zdt .
050 a |||||||||||||
051 m ||||||
070 KNUB
070 bZRED
076 k102235
076 v3
100 Grimm , Heinrich
102 00138073
331 Deutsche Buchdruckersignete des XVI . ...
335 Geschichte , Sinngehalt und Gestaltung ...
359 Heinrich Grimm
410 Wiesbaden
412 Pressleu
425 1965
425 a1965
433 365 S .
537 SW 580 klub / ssc ; NR / L1UB ; 720 ff . bvb
675 sechzehnten
700 g00295249
AN 21410
700 g00110453
AN 21400
KAPITEL 2. GRUNDLAGEN
14
902 g 00006213
902 s 00097657
902 z 00224220
904 aSWB
907 g 00006213
907 s 00130851
907 z 00224220
909 aSWB
Deutschland
Druckermarke
Geschichte 1500 -1600
Deutschland
Verlegermarke
Geschichte 1500 -1600
2.3.3 Datenfeld
Jeder Datensatz im MAB2-Format hat immer den gleichen Aufbau. Er besteht aus
mehreren Zeilen, wobei jede Zeile ein eigenes Feld darstellt. Die ersten drei Zeichen bzw. Zahlen werden als Feldnummer bezeichnet. Diese Feldnummer liegt im
Bereich von 001 bis 999, wobei nicht alle belegt sind. Das vierte Zeichen wird als
Indikator bezeichnet, da es die Feldnummer näher beschreibt. Ein leerer Indikator
bedeutet, dass die Feldnummer nicht näher spezifiziert ist. Nach dem Indikator
folgt das eigentliche variable Datenfeld, welches noch ein weiteres Subfeld enthalten kann. Dieses Subfeld bietet die Möglichkeit der weiteren Spezifizierung dieser Zeile. Schließlich folgt nach dem Datenfeld noch das Feldende-Zeichen (FE),
dass eine Zeile abschließt.
Graphisch dargestellt sieht eine Zeile wie folgt aus:
Feldnummer
Indikator
Daten
Subfeld
(variabel)
Daten
FE
Abbildung 2.2: Schematische Darstellung eines Datenfeldes
Die Feldnummer 001 enthält im Datenfeld die eindeutige Identifikationsnummer dieses Datensatzes. Hingegen steht im Feld 029 mit Indikator ’m’ der Medientyp, der von der Universität Konstanz aus anderen Feldnummern ausgewertet und somit aufbereitet wird, was eine leichtere Weiterverarbeitung erm öglicht.
In den Feldern 100, 104, . . . 196 stehen die Namen der 1., 2., . . . 25. Person in
Ansetzungsform. Die Ansetzungsform wird vom Bibliothekar vergeben, der dieses Medium erfasst, im Gegensatz zur Vorlageform, die so erfasst wird, wie sie auf
dem Medium angegeben ist. Die Feldnummern 102, 106, . . . 198 beinhalten die
2.3. DER MAB2-STANDARD
Indikator
c
f
g
k
p
s
t
z
15
Bedeutung
Unterschlagwort einer Ansetzungskette
Körperschaftsschlagwort: Ansetzung unter dem Ortssitz
Formsschlagwort
geographisch-ethnographisches Schlagwort
Körperschaftsschlagwort: Ansetzung unter dem Individualnamen
Personenschlagwort
Sachschlagwort
Werktitel als Schlagwort
Zeitschlagwort
Tabelle 2.3: Mögliche Arten von Schlagwörtern
Identifikationsnummer des zugehörigen Namens der 1., 2., . . . 25. Person. Diese Identifikationsnummer verweist auf einen Personendatensatz aus der MABPND-Datei. Bei einigen Feldnummern werden zur leichteren Lesbarkeit redundante Informationen gespeichert, wie die Feldnummern 102, 106, . . . , 198. Diese
können daran erkannt werden, dass sie neben einer Identifikationsnummer noch
zusätzlichen Text mit abspeichern, wie hier in den Feldern 100, 104, . . . , 196. Weitere Beispiele sind die Feldnummern 902, 907, . . . , 947, die die Schlagwortkette
darstellen. Der Hauptsachtitel in der Vorlageform eines vorliegenden Mediums
findet sich im Feld 331 wieder. Neben dem Hauptsachtitel gibt es noch einen
Einheits- und Parallelsachtitel, die jeweils noch in Ansetzungs- und Vorlageform
unterteilt sind. Der Einheitssachtitel wird bei Werken wie ’Faust’ oder dem ’Nibelungenlied’ vergeben, damit diese einheitlich erfasst werden. Hingegen werden
im Parallelsachtitel weitere Sachtitel erfasst unter denen das Werk zus ätzlich gefunden werden kann.
Die Informationen über den Ort und den Namen des Verlegers stehen in den
Feldnummern 410 und 412. Unter der Feldnummer 425 sind die unterschiedlichen Formen des Erscheinungsjahrs zusammengefasst.
In den Feldern 902, 907, . . . , 947 stehen die Verweise und die Ansetzungsformen der Schlagwörter, die mit diesem Medium verbunden sind. Der Indikator
gibt an, um welche Art von Schlagwort es sich handelt. In Tabelle 2.3 werden die
verschiedenen Arten aufgelistet. In diesem Datenfeld kommen zuerst zwei Leerzeichen, dann die eigentliche Identifikationsnummer des Schlagwortes mit der
Länge von acht Zeichen. Anschließend folgen zwölf Leerzeichen als Trenner zu
der redundanten Ansetzungsform.
Dieser Abschnitt sollte nur einige Feldnummern beschreiben, da die vollst ändige Beschreibung des MAB2-Formats zwei ganze Bände füllt und dadurch den
16
KAPITEL 2. GRUNDLAGEN
Rahmen dieser Arbeit überschreiten würde. Neben der vollständigen Beschreibung des MAB2-Formats existieren zusätzliche Excel-Dateien, die eine Übersicht
mit kurzer Beschreibung der vom Bibliotheksservice-Zentrum Baden-W ürttemberg (BSZ) unterstützten MAB2-Datenfelder auflistet. Diese Dateien sind unter
[2] im Abschnitt Konkordanzdateien zu finden.
Kapitel 3
Implementierung
Der Beginn dieser Arbeit bestand in der Konstruktion einer DTD, um den MAB2Standard so gut wie möglich abzubilden, da es keine existierenden Modellierungen gab, die dies adäquat lösten. Es existiert bereits eine Implementierung von
der DDB, die sich MABxml nennt und unter [14] zu finden ist. Die Konvertierung,
die MABxml durchführt, ist allerdings keine Modellierung im XML-Format, sondern nur eine 1:1-Überführung des MAB2-Formats in das XML-Format. Es gibt
einen Elementknoten mit der Bezeichnung feld mit zwei Attributen, eins f ür die
Feldnummer und eins für den Indikator.
Listing 3.1: Beispieleintrag von MABxml
<f e l d nr=” 335 ” ind=” ”>
nach dem S t u t t g a r t e r Hutzelm ännlein von Eduart M örike
</ f e l d>
Diese Arbeit will die Bibliotheksdaten möglichst adäquat in XML modellieren. MABxml überführt lediglich nur die MAB2-Felder in eine XML-Datei, der
Ansatz dieser Arbeit will der zugrundeliegenden Semantik besser Rechenschaft
tragen, womit eine Notwendigkeit nach einem neuen XML-Datenmodell bestand.
3.1
Konstruktion des XML-Datenschemas
3.1.1 Grundstruktur
Die Bibliothek Konstanz verarbeitet sechs der sieben MAB2-Formatdateien. Die
wichtigsten vier MAB2-Dateien sind die Titeldatei (MAB-TITEL), die Personendatei (MAB-PND), die Körperschaftsdatei (MAB-GKD) und die Schlagwortdatei (MAB-SWD). Zuerst musste analysiert werden, wie diese vier Dateien mitaneinander verknüpft sind. Dies geschah indem in den einzelnen Datenfeldern
17
KAPITEL 3. IMPLEMENTIERUNG
18
MAB-TITEL
102
MAB-PND
202
MAB-GKD
902
MAB-SWD
Abbildung 3.1: Schematische Grundstruktur
der Dateien nach Verweisen auf die anderen Dateien gesucht wurde. Nachdem
diese Verknüpfungspunkte gefunden waren, entstand ein erster Eindruck wie
diese Dateien zusammenhängen. Erst danach konnte mit der Modellierung begonnen werden. Grafisch dargestellt sehen die Beziehungen dieser vier Dateien
wie in Abbildung 3.1 aus. Die Verweise beziehen sich alle auf die Feldnummer
001 in der entsprechenden MAB2-Datei. So verweist eine Identifikationsnummer
in Feld 102 auf einen Datensatz in der Personendatei mit der zugeh örigen Identifikationsnummer in Feld 001. Dies gilt selbstverständlich auch für die beiden
anderen Dateien.
Bei der Modellierung des Datenschemas könnte unterhalb des Tags medien
eine weitere Spezifizierung, nämlich nach dem Medientyp stattfinden. So könnten alle Medien nochmals unter der Pluralbezeichnung ihres Typs unterschieden
werden. Zum Beispiel würde es einen Knoten buecher geben, der alle buch-Tags
enthielte. Diese Trennung der Medientypen würde die ganzen Datensätze eines
bestimmten Medientyps bündeln, was sich sehr effizient auf die Suche nach einem bestimmten Medientyp auswirken würde. Dieser Ansatz hätte allerdings
einen schwerwiegenden Nachteil, da die Datensätze in der Titeldatei willkürlich
angeordnet sind, müssten sie für jeden Medientyp einmal gelesen werden, damit
die Ausgabedatei sortiert nach den Medientypen geschrieben werden k önnte. Alternativ könnte die Titeldatei einmalig eingelesen werden und für jeden Medientyp würde eine eigene Ausgabedatei angelegt. All diese Ausgabedateien m üssten
dann in die XML-Datei zusammengefügt und somit nochmals geschrieben werden. Dies erhöht unnötig die Lese- und Schreibzugriffe auf die Festplatte, was
sich auf die Ausführungsgeschwindigkeit des gesamten Programms auswirken
würde. Diese Lösung eignet sich aus den aufgezeigten Gründen nicht für einen
effizienten Einsatz.
3.1. KONSTRUKTION DES XML-DATENSCHEMAS
19
Daher muss im Zentrum die Titeldatei stehen und die drei anderen Dateien als separate Datensätze gespeichert werden. Dies vermeidet eine redundante
Speicherung, da auf diese Datensätze per Identifikationsnummer aus der Titeldatei zugegriffen werden kann. Diese Konstellation eignet sich hervorragend f ür
den Aufbau eines Datenbankmodells, da die einzelnen MAB2-Dateien getrennt
voneinander gespeichert werden können. In der praktischen Umsetzung wurden daher vier Kindknoten an den Wurzelknoten bibliothek angeh ängt. Diese
vier Hauptknoten bzw. Sektionen tragen die Bezeichnungen medien, personen,
koerperschaften und schlagwoerter. Unter dem Hauptknoten medien ist nat ürlich die Titeldatei gemeint, die ja alle erfassten Medien in willk ürlicher Reihenfolge enthält. Die Zuordnung der MAB2-Dateien zu den restlichen drei Knoten
ist leicht ersichtlich. Listing 3.2 zeigt wie dies in XML umgesetzt wurde.
Listing 3.2: Die vier Hauptknoten
< !−− r o o t n o d e −−>
< !ELEMENT b i b l i o t h e k
( medien ,
personen ,
koerperschaften ,
schlagwoerter
) >
Nachdem die Zusammenhänge geklärt sind, geht es nun weiter mit den Gemeinsamkeiten, die alle vier Dateien verbindet. Jeder Datensatz besitzt eine eindeutige achtstellige Identifikationsnummer innerhalb einer MAB2-Datei, die in
der Feldnummer 001 gespeichert ist. Des weiteren wird in jedem Datensatz gespeichert, wann dieser angelegt, korrigiert und in die Datei eingebunden bzw.
transferiert wurde. Diese Daten werden dazu benutzt um zu erkennen, wann ein
aktualisierter Datensatz vorliegt. Hinzu kommt noch eine Versionsnummer, die
jedes Mal erhöht wird, falls eine Korrektur an diesem Datensatz durchgef ührt
wurde.
Die zwei anderen MAB2-Dateien sind die Lokaldatei und die Klassifikationsund Notationsdatei. Diese werden noch nicht von dieser Implementierung unterstützt, weshalb ihr Aufbau nicht näher beschrieben wird. In einer zukünftigen Implementierung werden diese beiden Dateien sehr wahrscheinlich enthalten sein.
3.1.2 Umsetzung einzelner Datensätze in XML
In diesem Abschnitt soll beschrieben werden, wie die einzelnen Datens ätze in
XML umgesetzt werden. Da jeder Datensatz in allen vier MAB2-Dateien eine
KAPITEL 3. IMPLEMENTIERUNG
20
eindeutige Identifikationsnummer besitzt, wird diese als Attribut zum jeweiligen
Elementknoten realisiert. Allerdings ist diese Identifikationsnummer immer nur
innerhalb ihrer MAB2-Datei eindeutig, womit nun jede Identifikationsnummer
innerhalb der ganzen XML-Datei eindeutig sein muss. Diese Eindeutigkeit der
Identifikationsnummer wird durch das Voranstellen eines Buchstaben erreicht.
Bei der Titeldatei wird ein ’m’ für Medium gewählt, bei den anderen drei ist es
jeweils der Anfangsbuchstabe der Datei in Kleinbuchstaben, also ’p’ f ür Personen, ’k’ für Körperschaften und ein ’s’ für Schlagwörter. Weiter müssen bei XML
die IDs mit einem Buchstaben, Unterstrich oder einem Doppelpunkt beginnen,
deshalb wird am Anfang der Identifikationsnummer künstlich ein Buchstabe angehängt.
Dieses Attribut trägt die Bezeichnung id und ist vom Typ ID, womit die Möglichkeit besteht via IDREF auf diesen Knoten zu verweisen, falls erforderlich. F ür
jeden Datensatz aus den vier MAB2-Dateien existiert ein Element mit einem solchen Attribut. Die Verweise in der Titeldatei zu den enthaltenen K örperschaften, Personen oder Schlagwörter werden durch ein leeres Element realisiert, das
nur ein Attribut vom Typ IDREF besitzt. Wie ein solcher Verweisknoten zu einer
Körperschaft in der DTD-Spezifikation aussieht, zeigt Listing 3.3. Ein Beispiel f ür
diese Vorgabe findet sich in Listing 3.4.
Listing 3.3: Ausschnitt aus der DTD
< !ELEMENT l k o e r p e r s c h a f t
< ! ATTLIST l k o e r p e r s c h a f t
EMPTY >
koerpID IDREF #REQUIRED >
Listing 3.4: Verweis auf Körperschaft
<l k o e r p e r s c h a f t korpID=” k12345678 ”
Der Elementknoten lkoerperschaft kann nur auf eine K örperschaft verweisen, da das Attribut nicht vom Typ IDREFS ist. Bei diesem Typ k önnte man mehrere Körperschaften-IDs unter diesen Knoten zusammenfassen, indem die IDs
durch Leerzeichen voneinander getrennt werden. Dies wurde aber aus Gr ünden
der besseren Lesbarkeit nicht umgesetzt.
Im Moment wird auf die Identifikationsnummer eines Mediums noch nicht
zugegriffen, aber in einer späteren Implementierung wird diese für die Abspeicherung der Exemplardaten benötigt. Dazu werden die Exemplare mit Verweis
auf einen Mediendatensatz abgespeichert, weil ja die Exemplare verliehen werden.
3.2. KONVERTIERUNG VON MAB2 NACH XML
21
Ein weiterer Grundgedanke bei der Konstruktion des Datenschemas war es,
so gut wie möglich zu gruppieren, dadurch können zusammengehörige Informationen auch geschlossen unter einem Begriff, realisiert durch einen Vaterknoten, zusammengefasst werden. Allerdings ist diese Entwicklung noch nicht abgeschlossen, da dies ohne das Wissen eines ausgebildeten Bibliothekars nicht
adäquat realisiert werden kann. Durch die Komplexität der Daten muss diese
Entwicklung sehr gründlich durchgeführt werden, indem es kontinuierlich weiterentwickelt wird.
3.2
Konvertierung von MAB2 nach XML
3.2.1 Grundstruktur
Der Grundstein war mit der Konstruktion eines geeigneten XML-Datenschemas
gelegt. Nun musste ein Programm implementiert werden, das die Daten von
MAB2 nach XML konvertiert und die Richtigkeit der Datensätze garantiert.
Die Implementierung dieses Programms wurde in C++ gelöst, da es eine objektorientierte Programmiersprache ist und auf vielen Rechnerarchitekturen verbreitet ist. Ein weiterer wichtiger Punkt war das Vorhandensein einer StringKlasse, die die textuelle Verarbeitung der ganzen Textzeilen vereinfacht.
Der Einsatz einer objektorientierten Sprache ermöglicht die Erstellung des
nachfolgenden Klassenmodells. Die Tatsache, dass die MAB2-Dateien den gleichen Aufbau und gemeinsame Datenfelder besitzen, verdeutlicht das folgende
Klassenmodell. Zuallererst musste eine Klasse erzeugt werden, die die Gemeinsamkeiten kapselt und gleichzeitig flexibel genug ist, weitere MAB2-Dateien zu
unterstützen. Dies führt zu einer besseren Übersichtlichkeit des Codes. Zu diesen
Gemeinsamkeiten zählen Datenfelder, die mindestens zwei der MAB2-Dateien
gemeinsam haben. Dazu gehören Datenfelder wie z. B. die SWB-spezifischen, die
Datensatz- und die Ländercode-Daten. Für diese Klasse wurde die Bezeichnung
CMAB2Parser gewählt. Die Eigenheiten der einzelnen MAB2-Dateien wurden jeweils in eine eigene Klasse gepackt, wobei diese als Unterklassen der Klasse
CMAB2Parser abgebildet wurden. Jede Unterklasse ist f ür das Parsen ihrer Datei
verantwortlich. So parst die Klasse CMAB2TitleParser die Titeldatei. Die Namen
der anderen drei Klassen lauten CMAB2PersonParser, CMAB2CorporationParser
und CMAB2BuzzWordParser. Der vollständige Quellcode befindet sich auf der beiliegenden CD.
KAPITEL 3. IMPLEMENTIERUNG
22
Das nachfolgende Klassendiagramm veranschaulicht die wichtigsten Details
noch etwas besser. Auf der beigelegten CD befinden sich alle ausf ührlichen Klassendiagramme.
#
+
#
#
CMAB2Parser
m strBuffer : CString
ParseFile(ofstream* pFile, const string& strFileName) : bool
hlpParseFieldNumber(CString& rstrLine) : bool
hlpCloseDataRecord() : void
CMAB2TitleParser
# m mMediumtype : MediumType
CMAB2CorporationParser
CMAB2PersonParser
CMAB2BuzzWordParser
Abbildung 3.2: Klassendiagramm des Konvertierungsprogramms
Die öffentlich zugängliche Methode ParseFile, die in der Basisklasse implementiert ist, regelt den Ablauf bei der Abarbeitung der einzelnen MAB2-Dateien.
Zuerst werden nacheinander die einzelnen Datensätze eingelesen, indem alle
Zeilen in einer doppelt verketteten linearen Liste von Strings gespeichert werden.
Dies geschieht mit Hilfe der Methode hlpReadDataRecord, die als Argumente eine Datei, aus der sie lesen soll, und eine Liste, in die sie die Zeilen speichern soll,
übergeben bekommt. Somit ist in der Liste ein ganzer Datensatz gespeichert, der
dann weiterverarbeitet werden kann. Diese Liste enth ält immer nur einen Datensatz, womit der Speicherverbrauch in einem akzeptablen Rahmen bleibt und
nicht von der Größe der Eingabedatei abhängig ist. Weiter ist eine Verarbeitung
eines ganzen Datensatzes nachvollziehbarer.
Jede enthaltene Zeile eines eingelesenen Datensatzes wird an die Methode
hlpParseFieldNumber weitergegeben. Diese Methode ist in der Basisklasse CMAB2Parser als abstrakt deklariert, womit jede von ihr abgeleiteten Klasse eine solche Methode implementieren muss. Mit dieser Klassenmodellierung k önnen nun
auch sehr leicht die noch nicht unterstützten MAB2-Formate, wie MAB-LOKAL
und MAB-NOTAT, hinzugefügt werden, ohne eine Reimplementierung des Klassenmodells notwendig zu machen. Beim Hinzufügen eines dieser Formate muss
3.2. KONVERTIERUNG VON MAB2 NACH XML
23
nur eine Unterklasse von CMAB2Parser erzeugt werden, die dann die Methode
hlpParseFieldNumber implementiert.
Dieses Konvertierungsprogramm trägt den Namen mab2toxml und wird wie
folgt aus einem Linux-System aufgerufen:
./mab2toxml -o <Datei> <MAB2-Präfix>
Beim Aufruf dieses Programms müssen nicht alle MAB2-Dateien einzeln angegeben werden, da sich diese bei einem Datenbankabzug nur an der Dateiendung unterscheiden, muss nur einmal der Dateiname, der die Bezeichnung
’MAB2-Präfix’ trägt, angegeben werden. Die bei der Konvertierung erzeugte XMLDatei erhält den Namen Datei.
3.2.2 Funktionsweise
Die Methode hlpParseFieldNumber verarbeitet jede Zeile eines eingelesenen Datensatzes, indem sie die Feldnummer und einen möglichen Indikator auswertet
und dann das Datenfeld in einen XML-Tag schreibt. Diese Tags werden mit der
Hilfsfunktion hlpBuildElementTag aus der Datei Tools.cc bewerkstelligt, wobei
ihr der Name des Tags, der Inhalt und die Anzahl der Einrückungen (Tabulatoren) am Anfang der Zeile übergeben werden. Diese Methode erleichtert den
Umgang mit dem Erzeugen der XML-Tags, da sie die Start- und Endtags erzeugt.
Weiter besteht die Möglichkeit ihr bis zu zwei Attribute zu übergeben, da es sich
um eine überladene Methode handelt.
Allerdings wird der so erzeugte XML-Tag nicht direkt in die Ausgabedatei
geschrieben, da dies die Anordnung innerhalb der XML-Struktur nicht gew ährleisten könnte. Die einzelnen Gruppierungen werden temporär in Variablen gespeichert, um dann am Ende eines Datensatzes alle Variablen in einer vorgegebenen Reihenfolge in den Puffer m strBuffer zu schreiben. Die einzelnen Variablen werden danach wieder geleert. All das geschieht in der abstrakten Methode
hlpCloseDataRecord, die von den Unterklassen überschrieben werden muss. Damit ist gewährleistet, dass jede Unterklasse die Reihenfolge festlegt, in der sie ihre
Tags in die Ausgabedatei schreibt.
Es gibt Attribute, die nicht jedem Medientyp zugeordnet werden d ürfen, so
kann z. B. nur der Medientyp Mikrofiche das Attribut mathematische angaben
aufweisen. Dieses Feld gibt den Maßstab an und ist somit nicht bei anderen Medientypen notwendig bzw. anwendbar. Diese Überprüfung soll auf Eingabefehler
hinweisen und kann somit der Ausbesserung von Fehlern dienen, die beim alten
Datenformat nicht aufgefallen sind. Um dies zu erkennen wird in der Variablen
24
KAPITEL 3. IMPLEMENTIERUNG
m MediumType der Medientyp gespeichert. Um nun Attribute in einem Medientyp auszuschließen, wird bei jedem Datenfeld auf diesen Medientyp gepr üft. Tritt
dieser auf, so gibt die Methode hlpParseFieldNumber falsch zur ück.
Die Methode ParseFile bricht in einem solchen Fehlerfall die Weiterverarbeitung des aktuellen Datensatzes ab und fährt mit dem nächsten Datensatz fort.
Damit der Benutzer den fehlerhaften Datensatz korrigieren kann, wird eine entsprechende Fehlermeldung auf der Standardausgabe ausgegeben. Diese Fehlermeldung enthält neben der Identifikationsnummer des entsprechenden Datensatzes auch noch die Angabe in welcher der MAB2-Dateien dieser Fehler auftrat.
Die Fehlerkorrektur kann nicht programmtechnisch durchgeführt werden, da
es sich bei dem Fehler um einen Eingabefehler (Tippfehler) oder der falschen Zuweisung eines Mediumtyps handeln kann. Erfolgte diese Prüfung ohne Fehler,
weist dies noch nicht auf einen fehlerfreien Datensatz hin, da es Datens ätze geben
kann, die bei der Feldnummer 076 aufhören. Diese sind somit nicht gültig, da die
Informationen über einen Datensatz erst bei Feldnummer 100 beginnen. Darauf
wird vor dem Schreiben, in der Methode hlpWriteDataRecord, gepr üft. Verläuft
diese Prüfung positiv, ist der vorliegende Datensatz gültig und kann schließlich
in die Ausgabedatei geschrieben werden. Die Variable m strBuffer, die zu diesem Zeitpunkt den kompletten Datensatz im XML-Format enth ält, wird in die
Datei geschrieben und dann anschließend geleert. Schlägt diese Überprüfung
fehl, wird eine Fehlermeldung mit der Identifikationsnummer ausgegeben und
der Aussage, dass dieser Datensatz zu kurz ist.
3.2.3 Einsatz einer Stoppwortliste
In einem Titelfeld, können Wörter auftauchen, wie z. B. der, die, das, und, etc.
Diese Wörter tragen nichts zum Titel bei, womit sie nicht beachtet werden sollen. Dazu werden diese Wörter im MAB2-Format in Nichtsortierzeichen (¬) gesetzt und beim Sortieren somit ausgeschlossen. Meist sind dies Stoppw örter, die
entfernt werden können, da sie sehr häufig vorkommen oder keine Relevanz aufweisen. In einer Stoppwortliste werden diese Stoppwörter meist alphabetisch angegeben.
Diese Stoppwörter tauchen nicht nur im Titelfeld auf, sondern auch bei Personennamen, wie z. B. ’Otto von Essen’, somit war dies Motivation genug, diese
Wörter innerhalb des Konvertierungsprogramms herauszufiltern. Da der gesamte Feldinhalt vorhanden bleiben muss, wird ein weiterer XML-Tag angelegt. Dieser Tag beginnt mit Tagnamen des zu reinigenden Feldes und erh ält weiter den
3.2. KONVERTIERUNG VON MAB2 NACH XML
25
Suffix normiert’ angehängt. So würde z. B. aus dem Tag gesamttitel nach Entfernen von Stoppwörtern gesamttitel normiert werden.
Auf den ersten Blick erscheint diese Abspeicherung redundant zu sein, allerdings spart sie kostbare Rechenzeit, da sie im Konvertierungsprogramm nur
einmal durchlaufen werden muss. Eine Suchanfrage in diesen Feldern k önnte
die Bearbeitungszeit beschleunigen, da nur die relevanten W örter in diesem Tag
enthalten sind. Würden diese Tags nicht redundant gespeichert, müsste bei jeder
Suche die Stoppwortentfernung bei jedem Tag durchgeführt werden. Bei einer
Suchanfrage muss die Stoppwortentfernung immer durchgeführt werden, aber
diese ist nicht allzu lang und kostet nicht viel Rechenzeit.
Die Stoppwortentfernung ist in der Methode hlpRemoveStopWords der Basisklasse implementiert. Damit diese Methode funktionieren kann, m üssen zuerst
einmal Stoppwörter bekannt sein. Diese werden aus einer Datei gelesen, deren
Dateiname dem Konstruktor der Unterklassen übergeben werden kann. Das Einlesen der Stoppwortliste erfolgt in der Methode hlpCreateStopWordList, wobei
dieser einen Dateinamen als Parameter übergeben wird. Diese Datei enthält in
jeder Zeile ein Stoppwort. Es ist sogar möglich, für jede der vier MAB2-Dateien
eine eigene Stoppwortliste zu verwenden.
Diese Liste wird in dem STL-Container Set gespeichert mit der Bezeichnung
m setStopWordList. Dieser Container garantiert, dass jedes Element nur einmal
enthalten ist. Bei einer Stoppwortliste ist es nicht maßgebend, wie oft ein Stoppwort vorkommt, sondern nur dass es enthalten ist. Allerdings ist es sehr unwahrscheinlich, dass ein Stoppwort mehrmals in einer solchen Liste vorkommt, trotzdem ist es besser diesen Container als zusätzlichen Schutz zu benutzen. Da bei
einem String-Vergleich zwischen Groß-und Kleinschreibung unterschieden wird,
werden die eingelesenen Stoppwörter komplett in Großbuchstaben gespeichert.
Die Felder, auf die diese Stoppwortentfernung angewendet wird, werden ebenfalls zum Vergleich in Großbuchstaben umgewandelt.
Beim Aufruf der Methode hlpRemoveStopWords wird als Argument ein String
übergeben, aus dem dann die Stoppwörter entfernt werden sollen. Der Rückgabewert ist der bereinigte String, der nun keine Stoppwörter mehr enthält, falls
dies vorher der Fall war. Enthielt der übergebene String keine Stoppwörter, so
sind beide Strings identisch.
Diese Methode kann überall dort im Konvertierungsprogramm benutzt werden, an denen Stoppwörter entfernt werden müssen. Beim jetzigen Stand der Implementierung werden nur die Felder Gesamttitel und Personennamen auf diese
Art bereinigt. Allerdings ist für die Zukunft der Einsatz bei weiteren Feldern geplant.
KAPITEL 3. IMPLEMENTIERUNG
26
3.3
Einfügen von Aktualisierungen
Nach erfolgreicher Konvertierung der vier beschriebenen MAB2-Dateien kann
der Datenbestand aktualisiert werden. Dazu können nicht immer die kompletten
Daten umkonvertiert werden, sondern es muss eine Möglichkeit geben, Aktualisierungen bzw. Updates einzuspielen. Um diesen Aktualisierungsprozess abzusichern, wurde auch berücksichtigt, dass bei den Aktualisierungen nicht immer
nur neuere Datensätze enthalten sind. Somit müssen zusätzlich noch weitere Vergleiche vorgenommen werden. Hierfür wurde ein weiteres Programm benötigt,
dass die Bezeichnung bibUpdater erhielt.
3.3.1 Allgemeiner Aufbau
Die täglichen Aktualisierungen sollten so schnell wie möglich eingespielt werden, da bei diesem Vorgang die gesamten Daten mindestens einmal eingelesen
werden müssen. Somit war die Zielsetzung des zu konstruierenden Algorithmus die Minimierung sowohl der Ressourcen als auch der Festplattenzugriffe.
Darüberhinaus sollte der Programmieraufwand und dadurch resultierende Fehlersuche ebenfalls so gering wie möglich sein. Dafür eignet sich der Einsatz einer bereits existierenden Datenbank sehr gut. In dieser Datenbank werden die
Datensätze aus den Aktualisierungsdateien gespeichert, wodurch nicht nur ein
Zugriff auf diese erleichtert wird, sondern auch der Datenbestand nur einmal
eingelesen wird. Beim Einsatz einer Datenbank wird auch der Vergleich eines
Datensatzes zwischen den beiden Datenständen ebenfalls erleichtert. Aber dazu
mussten zuerst noch einige Details zur Umsetzung geklärt werden.
Die erste Frage, die sich beim Einsatz einer Datenbank stellt, ist die Art der
Abspeicherung der Daten. Soll nur die Identifikationsnummer des Datensatzes
oder doch der ganze Datensatz abgespeichert werden? Ist diese Frage beantwortet, so muss als nächstes das Datenformat festgelegt werden, in dem sie gespeichert werden. In diesem Falle entweder im MAB2-Format oder schon im XMLFormat. In den nachfolgenden Abschnitten sollen die Antworten zu diesen Fragen gegeben werden.
Wird von einem Datensatz nur die Identifikationsnummer gespeichert, ist
dies sehr ressourcensparend, allerdings ist dann der Einsatz der Datenbank nutzlos, da ein Zugriff auf den Datensatz zur Folge hat, dass dieser erneut aus der
Datei gelesen werden muss. Wird hingegen der Datensatz komplett im Hauptspeicher gehalten, führt dies zu einem höheren Ressourcenverbrauch. Der Zugriff
3.3. EINFÜGEN VON AKTUALISIERUNGEN
27
auf die Datensätze wird jedoch wesentlich erleichtert und bei der heutigen Speicherausstattung von mehr als 512 MB Arbeitsspeicher sollte dies nicht so schwerwiegend sein.
Die Wahl der zu verwendenden Datenbank war mit der Abspeicherung eines
ganzen Datensatzes nun leicht zu treffen. Es muss eine Datenbank sein, die im
Hauptspeicher arbeitet und diesen nicht unnötig verschwendet. Die DatenbankBibliothek BerkeleyDB [1] von der Firma Sleepycat Software eignet sich daf ür sehr
gut. Sie bietet eine Vielzahl an Programmiersprachenanbindungen an, u. a. auch
für C++. Diese Bibliothek liegt in zwei Lizenzvarianten vor, einer Open-SourceLizenz bei einem Einsatz in Open-Source-Projekten und einer kostenpflichtigen
Variante. Weiter unterstützt sie keine aufwendigen Anfragen, weshalb sie schnell
und wenig speicherhungrig ist.
Diese Datenbank greift über ein so genanntes Schlüssel-Daten-Paar auf die in
ihr gespeicherten Datensätze zu. Der Schlüssel gibt an, unter welcher Bezeichnung ein bestimmter Datensatz gespeichert wird und auch wiedergefunden werden kann. Die eigentlichen Informationen über den Datensatz befinden sich im
Datenfeld. Die Informationen werden unter einer anderen k ürzeren Bezeichnung
abgelegt. Dies gleicht dem Konzept des STL-Containers Map (engl. Abbildung),
allerdings bietet dieser keine Optimierungen an, die BerkeleyDB mitbringt. F ür
die Implementierung ist diese Abbildung sehr nützlich, da ein kompletter Datensatz über seine Identifikationsnummer dargestellt wird und erleichtert somit den
Zugriff auf einen aktuelleren Datensatz aus der Datenbank.
Zuletzt stellt sich noch die Frage, in welchem Format die Datens ätze in der
BerkeleyDB-Datenbank abgespeichert werden sollen. Das Speichern im MAB2Format reduziert den Speicherplatz, jedoch erfordert es eine Konvertierung eines aktuelleren Datensatz aus der Datenbank in XML. Dies f ührt jedoch zwei
Nachteile mit sich: erstens würde es keine klare Trennung zwischen den beiden
Programmen geben, da das Aktualisierungsprogramm das Konvertierungsprogramm enthalten würde. Die beiden Programme lösen unterschiedliche Aufgaben, deshalb sind sie besser getrennt zu behandeln, damit kein großes monolithisches Programm entsteht. Zweitens dient diese Aufgabentrennung der Übersichtlichkeit. Ohne diese Trennung würde dies zu einem größeren Wartungsaufwand und zu Verständnisschwierigkeiten der nachfolgenden Entwickler führen,
da der Quellcode nicht mehr sauber voneinander getrennt werden kann. Diese
Lösung kam deshalb nicht in Betracht.
KAPITEL 3. IMPLEMENTIERUNG
28
3.3.2 Umsetzung in C++
Bei der Durchführung einer Aktualisierung muss daher zuerst das Update in
XML konvertiert werden. Nach diesem Schritt entsteht ein g ültiges und wohlgeformtes XML-Dokument, das keine fehlerhaften Datens ätze mehr enthält. Die
Hauptaufgabe ist nicht die Erkennung von Fehlern, welche ja schon beim Konvertierungsprozess ausgeschlossen wurden, sondern das korrekte Zusammenf ügen zweier vorher konvertierten XML-Dokumente.
Nachdem nun beide XML-Dateien auf der Festplatte existieren, kann mit dem
eigentlichen Update-Prozess begonnen werden. Auf Linux-Terminals sieht der
Aufruf des Programms bibUpdater wie folgt aus:
./bibUpdater -d <Datei1> -u <Datei2> -o <Datei3>
Datei1 ist der Dateiname des bestehenden Datenbestandes und Datei2 ist die
XML-Datei, die die Aktualisierungen enthält. Datei1 stellt somit die größere der
beiden Dateien dar. Da für jeden Datensatz in der Aktualisierungsdatei ein Eintrag in die BerkeleyDB-Datenbank erstellt wird, würde dies den Speicherverbrauch zusätzlich erhöhen. Das resultierende Ergebnis dieses Prozesses wird in
die dritte Datei Datei3 geschrieben. Fehlt diese Option, wird die XML-Datei in
die Standardausgabe geschrieben.
In diesem Abschnitt sollen die Details der Implementierung beschrieben werden. Hierzu wurde wieder eine eigene Klasse geschrieben, die diesen ganzen
Aktualisierungsvorgang kapselt. In einer zweiten Datei namens main.cc werden vorher noch die möglichen Kommandoparameter ausgewertet, um dann
schließlich diese Klasse auszuführen. Dies geschieht mit der öffentlichen Methode UpdateDatabase, der die drei Dateinamen der Kommandozeile übergeben
werden.
Als erstes wird der Kopf in die neue XML-Datei geschrieben, damit die verwendete XML-Version und Zeichensatz korrekt angegeben sind. Danach werden
nacheinander alle Datensätze der einzelnen vier Sektionen der Update-Datei in
die BerkeleyDB-Datenbank eingelesen, dies geschieht in der Methode hlpFillDatabase. Es befinden sich also nur die Datensätze einer Sektion zur gleichen Zeit
in der Datenbank. Dies hat erstens den Zweck, dass der Speicherverbrauch gering
gehalten wird und zweitens ist das Ende der Sektion bekannt. Danach wird ein
Datensatz aus der großen XML-Datei gelesen und in einer Variablen zwischengespeichert, das Gleiche geschieht mit der Identifikationsnummer. Als n ächstes
wird in der Datenbank geprüft, ob ein Datensatz mit dieser Identifikationsnummer existiert, falls nicht, wird dieser Datensatz in die Ausgabedatei geschrieben
3.3. EINFÜGEN VON AKTUALISIERUNGEN
29
und der nächste Datensatz wird eingelesen.
Gibt es jedoch einen Treffer in der Datenbank, so wird dieser ebenfalls in einer Variablen gespeichert und aus der Datenbank entfernt, danach werden die
möglich vorhandenen Korrekturdaten überprüft. Falls einer der beiden kein Korrekturdatum besitzt, wird der Datensatz in die Ausgabedatei geschrieben, der
das Korrekturdatum aufweist. Besitzen beide ein Korrekturdatum werden selbstverständlich beide Daten miteinander verglichen, um das neuere Datum zu finden.
Falls diese Überprüfung auch noch nicht eindeutig ist, werden schließlich
noch die Versionsnummern, die sich im Feld 076v befindet, miteinander verglichen. Eine höhere Nummer identifiziert den aktuelleren Datensatz.
Ist schließlich das Ende einer Sektion erreicht und es befinden sich noch Datensätze in der Datenbank, dann handelt es sich bei diesen um neue Eintr äge, die
alle in die Ausgabedatei geschrieben werden müssen. Danach ist die Datenbank
leer und auch der Endtag der Sektion kann in die Ausgabedatei geschrieben werden. Der gesamte Vorgang wiederholt sich für alle weiteren drei Sektionen, damit
enthält die Ausgabedatei am Ende alle Neuerungen. Die Datei ist wohlgeformt
und gültig, da die beiden anderen Daten dies ebenfalls waren.
Der Datensatz aus Listing 2.5 sieht nach der Konvertierung in das XML-Format wie in Listing 3.5 angegeben aus.
Listing 3.5: Datensatz nach Konvertierung
< buch id = " m00036210 " >
< datensatz >
< ersterfassung >
< datum > 19850101 </ datum >
< kennzeichen > KNUB </ kennzeichen >
</ ersterfassung >
< transaktionsdatum > 20040826 </ transaktionsdatum >
< korrektur >
< datum > 20020823 </ datum >
< kennzeichen > ZRED </ kennzeichen >
</ korrektur >
</ datensatz >
< swb >
< korrekturdatum > 102235 </ korrekturdatum >
< versionsnummer >3 </ versionsnummer >
</ swb >
< verfasser persID = " p00138073 " / >
30
KAPITEL 3. IMPLEMENTIERUNG
< verlag >
< ort > Wiesbaden </ ort >
< name > Pressler </ name >
</ verlag >
< erscheinungsjahr >
< vorlageform > 1965 </ vorlageform >
< ansetzungsform > 1965 </ ansetzungsform >
</ erscheinungsjahr >
< sprachencode >
< sc_swb > dt . </ sc_swb >
</ sprachencode >
< titel >
< hauptsachtitel >
< vorlageform > Deutsche Buchdruckersignete des XVI .
Jahrhunderts </ vorlageform >
< normiert > Deutsche Buchdruckersignete XVI .
Jahrhunderts </ normiert >
< zusaetze > Geschichte , Sinngehalt und Gestaltung
kleiner Kulturdokumente </ zusaetze >
</ hauptsachtitel >
</ titel >
< beschreibung >
< allgemein > Heinrich Grimm </ allgemein >
< kollationsvermerk > 365 S . </ kollationsvermerk >
< redaktionsbemerkung > SW 580 klub / ssc ; NR / L1UB ; 720
ff . bvb </ redaktionsbemerkung >
</ beschreibung >
< bib_verb_bayern > 8009202269 </ bib_verb_bayern >
< klassifikation >
< regensburger_verbundklass > 00295249 </
regensburger_verbundklass >
< regensburger_verbundklass > 00110453 </
regensburger_verbundklass >
</ klassifikation >
< stichwoerter > sechzehnten </ stichwoerter >
< lschlagwort slgID = " s00006213 " typ = " geographisch " / >
< lschlagwort slgID = " s00097657 " typ = " sach " / >
3.3. EINFÜGEN VON AKTUALISIERUNGEN
< lschlagwort slgID = " s00224220 " typ = " zeit " / >
< herkunftsangabe > SWB </ herkunftsangabe >
< lschlagwort slgID = " s00006213 " typ = " geographisch " / >
< lschlagwort slgID = " s00130851 " typ = " sach " / >
< lschlagwort slgID = " s00224220 " typ = " zeit " / >
< herkunftsangabe > SWB </ herkunftsangabe >
</ buch >
31
32
KAPITEL 3. IMPLEMENTIERUNG
Kapitel 4
Leistungsmessung
Im vorherigen Kapitel wurden die Implementierungen beschrieben, wie aus einer MAB2-Datei eine XML-Datei generiert wird und mögliche Aktualisierungen nachträglich eingebunden werden. Dieses Kapitel soll nun die Geschwindigkeit der entstandenen Programme untersuchen. In einem zweiten Schritt soll
die gesamte Datenbank noch anhand typischer Suchanfragen getestet werden,
um einen Vergleich zur anfänglich benutzten Textdatei des MedioVis-Projekts zu
ermöglichen. Allerdings gilt es zu beachten, dass kein direkter Vergleich m öglich
ist, da nicht die gleichen Datenbestände vorhanden sind und der Datenbestand
bei dieser Arbeit wesentlich größer ist als bei MedioVis. Die Analyse solcher
Suchanfragen bietet eine realistische Bewertung bzw. Einsch ätzung des erstellten
XML-Datenschemas, da nun eventuelle Modellierungsfehler sich in der Laufzeit
der gestellten Suchanfragen bemerkbar machen. Diese Erkenntnisse k önnten zu
einigen Nachbesserungen im Datenschema oder im Extremfall zu einer Neumodellierung führen.
4.1
Das eingesetzte Datenbanksystem
Als zugrunde liegendes XQuery-System wird das Projekt Pathfinder [4] benutzt,
das am Fachbereich für Datenbanken und Informationssysteme an der Universität Konstanz entwickelt wird. Pathfinder ist die Schnittstelle, an die die Suchanfragen für das Bibliotheksszenario gestellt werden. Dabei handelt es sich um das
Frontend zum Datenbank-Backend MonetDB [3], welches vom CWI, dem ’Institute for Mathematics and Computer Science Research of The Netherlands’ in Amsterdam seit 1993 entwickelt wird. Diese beiden Programme sind Open-Source.
Bei MonetDB handelt es sich ein Datenbanksystem, welches sich sehr gut f ür
komplexe Anfragen an große Datenbanken eignet. Beide Programme kombiniert
33
KAPITEL 4. LEISTUNGSMESSUNG
34
MAB-Datei
Titel
Person
Körperschaft
Schlagwort
Gesamt
#Datens. MAB2 (MB) XML (MB) Faktor ØDatens.
8.089
5,48
13,23
2,41
1.715
5.236
1,00
3,03
3,03
607
1.818
0,80
1,72
2,15
994
6.167
1,83
5,17
2,83
880
21.310
9,11
23,16
2,54
1.140
Tabelle 4.1: Datensätze der kleineren Testdatei
MAB-Datei
Titel
Person
Körperschaft
Schlagwort
Gesamt
#Datens. MAB2 (MB) XML (MB) Faktor ØDatens.
40.260
27,10
65,98
2,43
1.719
31.870
5,37
16,21
3,02
533
4.511
1,77
3,93
2,22
914
20.151
5,67
16,23
2,86
845
96.793
39,91
102,36
2,56
1.109
Tabelle 4.2: Datensätze der größeren Testdatei
ergeben ein XML-Datenbanksystem, welches beim MedioVis-Projekt als zuk ünftige Datenbankschnittstelle eingesetzt werden soll.
Die nachfolgenden Messungen wurden auf einem AMD Athlon64 3200+ mit
1024 MB RAM und einer SATA-Festplatte unter Gentoo Linux 2004.3 mit 64-BitUnterstützung durchgeführt. MonetDB und Pathfinder sind ebenfalls mit reiner
64-Bit-Unterstützung kompiliert worden. Beim Schreiben dieser Arbeit wurden
die CVS-Versionen (April 2005) der beiden Programme verwendet.
4.2
Vergleich zwischen den Formaten
In diesem Abschnitt geht es um die Leistungsmessung der entstandenen XMLDateien mit den beiden Programmen mab2toxml und bibUpdater. Bei dieser Messung standen zwei Abzüge aus der Bibliotheksdatenbank unterschiedlicher Größe zur Verfügung. Die Tabellen 4.1 und 4.2 geben einen detaillierten Überblick
über die einzelnen Datensätze innerhalb der beiden MAB2-Abzügen klein und
groß.
Dabei gibt die zweite Spalte die Anzahl der einzelnen Datens ätze an, die erfolgreich konvertiert werden konnten. Die dritte und vierte Spalte weisen die Dateigrößen der Formate aus. Die Spalte Faktor gibt an, um wie viel die XML-Datei
größer ist als die MAB2-Datei. In der letzten Spalte wird die durchschnittliche
Größe eines XML-Datensatzes angegeben, um später besser die Dateigröße für
die gesamten Bibliotheksdaten abschätzen zu können. Diese Größe ergibt sich, indem die Dateigröße der XML-Datei durch die Anzahl der enthaltenen Datens ätze
4.2. VERGLEICH ZWISCHEN DEN FORMATEN
MAB-Datei
Titel
Person
Körperschaft
Schlagwort
Gesamt
35
#Datensätze ØDatensatz (kB) XML (MB)
1.784.409
1.717
2.921,57
620.697
570
337,57
73.405
954
66,79
190.732
862
156,82
2.669.243
1026
3.482,74
Tabelle 4.3: Geschätzte Dateigrößen (Stand 14.02.2005)
dividiert wird. Die letzte Zeile in der Tabelle gibt das Gesamtverh ältnis an. So
benötigt der kleinere Datenbankabzug in XML konvertiert 23,16 MB auf der Festplatte.
Bei der Konvertierung der beiden Testdateien war jeweils ein Titelsatz nicht
konvertierbar. In der kleineren Titeldatei war der Datensatz nicht vollst ändig, da
dieser beim Feld 076 zu Ende war und somit keine Informationen über ein Medium enthielt. Im Falle der größeren Datei passte ein Attribut nicht zum angegebenen Medientyp und wurde deshalb zurückgewiesen.
Um eine möglichst genaue Schätzung abzugeben, wie groß die gesamten Bibliotheksdaten in XML sind, wurden für jede der vier Dateien die Mittelwerte
aus der sechsten Spalte der beiden Datenbankabzüge benutzt. Tabelle 4.3 gibt neben den aktuell erfassten Datensätze der Bibliothek und den Mittelwerten der
Datensatzgrößen je eine Schätzung der Dateigröße für die XML-Datei. Die Werte
der dritten und vierten Spalte sind ebenfalls in Bytes angegeben. In der letzten
Zeile wird die geschätzte Gesamtgröße angegeben mit 3.482,74 MB oder 3,4 GB.
Diese Größenordnung stellt für Pathfinder kein Problem dar. Hierbei ist zu beachten, dass die erzeugten XML-Dateien sehr oft die gleichen Tagnamen und zur
besseren Lesbarkeit viele Whitespaces enthalten. Diese kann Pathfinder sehr gut
komprimieren und ermöglicht dadurch eine effiziente Datenhaltung.
Abbildung 4.1 zeigt die Durchschnittszeiten grafisch dar, die mit dem LinuxKommando time gemessen wurden. Dabei geben die ersten beiden Balken die
durchschnittliche Durchführungszeiten des Konvertierungsprogramms an. Hingegen zeigt der letzte Balken die Ausführungszeit an, die das Zusammenfügen
der beiden XML-Dateien benötigte.
Beim Zusammenfügen der beiden Dateien klein.xml und groß.xml mit dem
Programm bibUpdater entstand die XML-Datei gesamt.xml mit einer Dateigr öße
von 118,87 MB. Diese Datei enthält 46826 Titel-, 35890 Personen-, 5727 Körperschaften- und 23078 Schlagwortdatensätze.
KAPITEL 4. LEISTUNGSMESSUNG
36
Datei
klein.xml
groß.xml
gesamt.xml
0
5
10
Zeit [s]
15
20
25
Abbildung 4.1: Durchschnittliche Verarbeitungszeit
4.3
Typische Suchanfragen
4.3.1 Identifizieren von typischen Anfragen
An die fertig erstellte XML-Datenbank sollen möglichst realistische und aussagekräftige Anfragen gestellt werden, um das System so realistisch wie m öglich zu
evaluieren. Damit dies möglich war, sollten typische Benutzeranfragen dazu benutzt werden, diese wurden bereits an MedioVis gestellt. Die Anfragen wurden
mit dem Programm DROID [9] vom Fachbereich Mensch-Computer-Interaktion
durchgeführt. DROID zeichnet sich dadurch aus, da es das Benutzerverhalten im
Hintergrund aufzeichnet und diese Ergebnisse dann in einer Datenbank abspeichert. Aus diesen Ergebnissen wurde dann die am häufigsten Anfragen extrahiert
und dienten als Richtungsweiser, welche denn genau die typischen Benutzeranfragen sind.
Neben Suchanfragen nach dem Medientyp im allgemeinen Suchfeld oder im
Medientypsuchfeld wurde auch nach Titeln und nach verschiedenen Richtungen
gesucht, wie z. B. Komödie oder Science-Fiction. In einigen Fällen wurde zusätzlich die Sprache eingegrenzt, um die Anzahl der Treffer weiter zu verkleinern.
In vielen Suchanfragen wurde auch nach Personen gesucht, die nicht nur Autoren waren, sondern auch Schauspieler. Diese wurden auch nicht immer im Suchfeld für Personen eingetragen, sondern auch sehr oft im allgemeinen Suchfeld.
4.3. TYPISCHE SUCHANFRAGEN
37
Das allgemeine Suchfeld ist ein einziges Eingabefeld, das mit dem Eingabefeld
von Google [10] vergleichbar ist. Der Umstand, dass sehr viele Anfragen im allgemeinen Suchfeld gestellt wurden, muss beim Konstruieren von Suchanfragen
berücksichtigt werden, da unerfahrene Benutzer sich leicht von erweiterten Optionen abschrecken lassen. Eine Überlegung wäre Eingaben im allgemeinen Suchfeld nicht nur im Titelfeld und im Personenfeld zu suchen, sondern auch weitere Felder zu durchsuchen. Dies würde die Ausführung einer solchen möglichen
Suchanfrage deutlich verlangsamen, da mit steigender Anzahl gespeicherter Informationen der Aufwand steigt.
Weiter muss die Eigenheit des MAB2-Formats berücksichtigt werden, da es
mehrere Titelfelder hat, die in Gesamttitel, Parallelsachtitel, Hauptsachtitel und
weitere Titel in Unterwerken unterteilt sind. Da dies sehr leicht mehr als zehn
Titelfelder pro Datensatz sind und momentan in der Bibliotheksdaten fast 1,8
Mio. Titeldatensätze gespeichert sind, würden rund 18 Mio. Felder durchsucht,
falls kein Medium eingegrenzt wird. Zusätzlich werden noch die Personenfelder durchsucht, die auf Datensätze in der Personensektion verweisen. Da verschiedene Schreibweisen oder Verweisungsformen der Personennamen existieren können, sind weitere Felder erforderlich, die durchsucht werden m üssen.
Es muss also ein Mittelweg erreicht werden, der einerseits eine große Treffermenge und andererseits nur sehr relevante Treffer zurückliefert. Dies wird erreicht, indem einige Felder nicht durchsucht, aber die übrigen genau durchsucht
werden.
4.3.2 Erstellung von Suchanfragen
Die nachfolgenden Suchanfragen sind in XQuery geschrieben und sollen die typischen Anfragen darstellen, die an MedioVis gestellt wurden. Diese Anfragen
wurden weder auf das Bestmögliche optimiert, noch wurden Hilfsstrukturen wie
Indizes verwendet, da dies den Rahmen dieser Arbeit sprengen w ürde. Weiter
werden bei jeder Suchanfrage immer die vollständigen Pfade angegeben, um das
Suchfenster soweit wie möglich einzugrenzen.
Die Zeitmessung erfolgte mit dem MonetDB-Programm MapiClient und dessen Option -t. Dabei geben die nachfolgenden Diagramme die durchschnittlichen Anfragezeiten an. Um bei der Zeiterfassung die reine Anfragezeit zu messen, wird auf die Serialisierung der Ergebnisknoten verzichtet. Ansonsten w ürde
auch die Ausgabe des verwendeten Terminals mit einfließen, dies wird durch
den Einsatz der Aggregationsfunktion count verhindert. Diese Funktion gibt die
KAPITEL 4. LEISTUNGSMESSUNG
38
Anzahl der Ergebnisknoten in der Suchanfrage zurück. Die nachfolgenden Messungen wurden mehrmals wiederholt und der Mittelwert daraus gebildet.
Der Zugriff auf ein bestimmtes Dokument erfolgt mit der XQuery-Funktion
doc("datei"). Da sich die nachfolgenden Anfragen nur im durchsuchenden Dokument unterscheiden, wird deshalb nur eine einzige Anfrage angegeben. Die
XML-Dokumente wurden mit Hilfe der Pathfinder-Funktion shred doc eingelesen.
Die Suche nach einem bestimmten Titel könnte wie folgt aussehen:
Listing 4.1: Suche im Titelfeld
count (/ c h i l d : : b i b l i o t h e k / c h i l d : : medien/ c h i l d : : ∗ [ some $ t i t e l
in c h i l d : : t i t e l // t e x t ( ) s a t i s f i e s c o n t a i n s ( $ t i t e l ,
” Reorganisation ”) ] )
Datei
klein.xml
groß.xml
gesamt.xml
0
0.2
0.4
0.6
0.8
Zeit [s]
1
1.2
1.4
1.6
Abbildung 4.2: Durchschnittszeiten für die Titelsuche
Sie deckt nur die wichtigen Titelfelder ab. Dazu gehören nicht die Titel der
Sekundärform oder der übergeordneten Einheit, wie dies im MAB2-Format bezeichnet wird. Würden diese Felder ebenfalls in Zukunft relevant werden, so
müssten entweder die Felder in den Tag namens titel hinzugef ügt werden oder
die obige Suchanfrage müsste um diese Felder erweitert werden. In der obigen
Anfrage werden alle Medien aufgelistet, die in ihrem Titel das Wort ’Reorganisation’ enthalten. Bei dieser Anfrage werden noch zwei weitere XPath-Funktionen
4.3. TYPISCHE SUCHANFRAGEN
39
benutzt. Das Konstrukt some-in-satisfies quantifiziert einen Ausdruck, der
zum Beispiel wie folgt aussehen kann:
some $x in $expr s a t i s f i e s $x > 10
Der Existenzquantor some gibt an, dass mindestens ein Element x aus der
Menge expr existiert, die nach dem Schlüsselwort in angegeben wird und den
Testausdruck $x > 10, das dem Schlüsselwort satisfies folgt, erfüllt. Im Gegensatz zu some müssen beim Allquantor every alle Elemente aus der Menge
den Testausdruck erfüllen.
Dieses Konstrukt muss immer in den Fällen verwendet werden, wo mehrere
Knoten vorkommen können. Die Methode contains ist eine String-Funktion, die
wahr zurückliefert, falls der zweite Parameter im ersten Parameter mindestens
einmal enthalten ist. Aufgrund der derzeitigen Implementierung ist diese Funktion allerdings sehr aufwändig und stellt daher den Flaschenhals dieser Anfrage
dar.
Eine weitere typische Anfrage wäre die Suche nach allen Medien, die von
einem bestimmten Verfasser (z. B. ’Martin Luther’) stammen. In XQuery ausgedrückt, sieht dies so aus:
Listing 4.2: Suche nach einem Person
/ c h i l d : : b i b l i o t h e k / c h i l d : : medien/ c h i l d : : ∗ [ id ( c h i l d : :
v e r f a s s e r /@persID ) [ some $name in ∗/ t e x t ( ) s a t i s f i e s (
c o n t a i n s ( $name , ” Luther ” ) and c o n t a i n s ( $name , ” Martin ” ) )
]]
Da in einem Titeldatensatz nur eine Referenz auf einen Personendatensatz
abgelegt ist, muss diese zuerst aufgelöst werden, damit in dessen Datenfelder
gesucht werden kann. Im allgemeinen XQuery-Standard gibt es die Funktion id,
die die Auflösung einer gegebenen ID übernimmt. Dazu bekommt sie eine ID als
Parameter übergeben und gibt den entsprechenden Knoten zurück.
Da bei vielen Anfragen schon ungefähr das Erscheinungsjahr bekannt ist,
könnte man die Treffer noch weiter einschränken. Die nachfolgende Anfrage soll
nur aufzeigen, wie in einer bestimmten Zeitperiode – zwischen 1999 und 2000 –
gesucht wird.
Listing 4.3: Suche innerhalb einer Zeitperiode
/ c h i l d : : b i b l i o t h e k / c h i l d : : medien/descendant : : ∗ [ c h i l d : :
e r s c h e i n u n g s j a h r / c h i l d : : vorlageform/ t e x t ( ) >= ”1999” and
c h i l d : : e r s c h e i n u n g s j a h r / c h i l d : : vorlageform/ t e x t ( ) <=
”2000”]
KAPITEL 4. LEISTUNGSMESSUNG
40
Datei
klein.xml
groß.xml
gesamt.xml
0
0.5
1
1.5
2
2.5
Zeit [s]
3
3.5
4
4.5
5
Abbildung 4.3: Durchschnittszeiten für die Personensuche
Die Suche nach einem bestimmten Medientyp stellt sich in diesem vorgestellten Datenmodell als sehr effizient heraus. Da dieser Fall der Anfrage bereits bei
der Modellierung bedacht wurde, wurde der Medientyp bewusst als Kindknoten
des Knotens medien modelliert.
Listing 4.4 listet alle Zeitschriftenknoten auf, die von dem Verleger ’Bertelsmann’ herausgegeben wurden.
Listing 4.4: Suche alle Zeitschriften vom Verleger ’Bertelsmann’
/ c h i l d : : b i b l i o t h e k / c h i l d : : medien/ c h i l d : : z e i t s c h r i f t [ some $x
in c h i l d : : v e r l a g / c h i l d : : name/ t e x t ( ) s a t i s f i e s c o n t a i n s (
$x , ” Bertelsmann ” ) ]
Weiter spielt XQuery die Vorteile der Kompositionalität seiner Anfragen vollends aus. Dies ermöglicht mehrere Anfragen miteinander zu verknüpfen, ohne dass diese einer Einschränkung unterliegen. Somit können die obig gezeigten
Suchanfragen beliebig miteinander verknüpft werden, dadurch kann sehr flexibel auf bestimmte Suchanfragen von Benutzern eingegangen werden.
4.3. TYPISCHE SUCHANFRAGEN
41
Datei
klein.xml
groß.xml
gesamt.xml
0
1
2
3
Zeit [s]
4
5
6
7
Abbildung 4.4: Durchschnittszeiten für die Zeitperiodenanfrage
4.3.3 Bessere Suchmöglichkeit
Eine Erweiterung gegenüber der einfachen Volltextsuche des MedioVis-Projekts
ist die Suchmöglichkeit nach Schlagwörtern. Damit kann nach Synonymen gesucht werden, was die Qualität der Suchtreffer deutlich erhöht. Die Volltextsuche des MedioVis-Projekts hat nur einen eingeschränkten Ausschnitt der vier
MAB2-Daten. Ein direkter Vergleich zwischen den Suchanfragen ist damit nicht
möglich. Die Volltextsuche ist in einer 10 MB Datei noch durchf ührbar, aber bei
einem Datenabzug von 100 MB ist dies nicht mehr möglich und bei 3,32 GB erst
recht unmöglich. Eine Suchanfrage an das vorgestellte XML-Modell ben ötigt etwas mehr Zeit, aber durchsucht dementsprechend auch mehr Datenfelder.
Bei einer Titelsuche nach dem Begriff ’Heiliges Römisches Reich Deutscher
Nation’ wird nur ein einziges Dokument, jedoch bei der Schlagwortsuche werden alle Dokumente ausgegeben, die mit dem Schlagwort verbunden sind. Es
können mehrere Schlagwörter sein, die diesen Begriff beinhalten, da in den Feldern Hauptschlagwort und Äquivalenzschlagwort gesucht wird. Listing 4.5 bildet diese Suchanfrage ab.
Genau nach dem obigen Muster kann auch nach Personennamen gesucht
werden, die nicht nur die typischen Schreibweisen aufweisen, sondern auch Alternativschreibweisen. Ein Beispiel wäre der Komiker Charlie Chaplin, der allerdings ausgeschrieben Charles Chaplin heißt. Die Suche nach Charlie Chaplin
KAPITEL 4. LEISTUNGSMESSUNG
42
Datei
klein.xml
groß.xml
gesamt.xml
0
0.5
1
1.5
Zeit [s]
2
2.5
3
Abbildung 4.5: Durchschnittszeiten für die Zeitschriftensuche
Listing 4.5: Suche nach einem Schlagwort
/ c h i l d : : b i b l i o t h e k / c h i l d : : medien/ c h i l d : : ∗ [ id ( . / c h i l d : :
l s c h l a g w o r t /@slgID ) [ some $x in ( c h i l d : : hauptschlagwort/
t e x t ( ) , child : : aequivalent/ t e x t ( ) ) s a t i s f i e s ( contains (
$x , ” H e i l i g e s ” ) and c o n t a i n s ( $x , ” R ömisches ” ) ) and
c o n t a i n s ( $x , ” Reich ” ) and c o n t a i n s ( $x , ” Deutscher ” ) and
c o n t a i n s ( $x , ” Nation ” ) ] ]
würde nicht unbedingt alle Treffer auflisten. Deshalb wird zuerst innerhalb der
Personen gesucht, um dann mit der Identifikationsnummer dieses Personendatensatzes in der Titeldatei nach Verweisen auf diese Nummer zu suchen.
4.3.4 Bewertung der Suchanfragen
Bei dieser Arbeit wurde mehr die Funktionalität der Anfragen als deren Optimierung ins Auge gefasst, um einen ersten Überblick über Anfragezeiten zu erlangen. Trotzdem wird deutlich, dass der Einsatz von Optimierungen zur Steigerung der Ausführungsgeschwindigkeit der oben angegebenen Suchanfragen
4.3. TYPISCHE SUCHANFRAGEN
43
Datei
klein.xml
groß.xml
gesamt.xml
0
5
Zeit [s]
10
15
Abbildung 4.6: Durchschnittszeiten für die Schlagwortsuche
notwendig ist. Zu diesen Optimierungen zählt z. B. die Verwendung von Indizes. Aber auch zukünftige Erkenntnisse könnten zur Geschwindigkeitssteigerung beitragen. Bei späterer Benutzung der fertigen Anwendung müssen die gestellten Suchanfragen der Benutzer wesentlich schneller sein. Dennoch machen
die obigen Ergebnisse Mut, um den Einsatz einer XML-Datenbank weiter voranzubringen. Erst die Zukunft kann zeigen, wie schnell diese Anfragen beim
vollständigen Einsatz an Optimierungen werden können.
4.3.5 Verbesserungsmöglichkeiten
Da die Methode contains und somit die Verarbeitung von Volltexten bereits als
Flaschenhals identifiziert wurde, so soll hier noch kurz auf eine Erweiterung von
XQuery zu diesem Problem verwiesen werden. Das W3C schlägt einen Standard
namens XQuery 1.0 and XPath 2.0 Full-Text [25] vor, wie die Unterst ützung von
Volltexten in XQuery hinzugefügt werden kann. Dabei handelt es sich um eine
Erweiterung zu XQuery. Die Suche in Volltexten kann mit Hilfe von Information
Retrieval-Techniken besser unterstützt werden, da Funktionen wie z. B. Phrasensuche, Annäherungssuche, Stemming und Thesauri angeboten werden.
Es existiert bereits eine erste Implementierung von diesem Standard und zwar
trägt sie die Bezeichnung TeXQuery [5]. Diese bietet sehr mächtige Konstrukte
44
KAPITEL 4. LEISTUNGSMESSUNG
zur Verarbeitung von Volltexten. Darunter wird auch die Effizienz der containsMethode gesteigert, womit sich die Anfragezeit aufwendiger Anfragen weiter
verringert.
Kapitel 5
Fazit
Durch die Entwicklung von MedioVis, einer innovativen ’Suchmaschine’ f ür multimediale Inhalte, entstand das Bedürfnis eines Datenbanksystems, welches die
bibliographischen Daten sehr gut abbilden und effizient durchsuchen kann. Dies
war die Geburtsstunde dieser Arbeit. Sowohl im Bereich der Benutzerinteraktion eines solchen Suchsystems, als auch in Bezug auf ein effizientes DatenbankBackend werden derzeit Prototypen an der Universität Konstanz entwickelt und
weiter gepflegt, womit eine enge Zusammenarbeit möglich ist.
Die Modellierung der Bibliotheksdaten im XML-Format benutzt die ganzen
Vorteile dieser Datenbanktechnologie. Es kann nicht nur der Semantik der Daten
gerecht werden, sondern ermöglicht darüber hinaus Anfragen effizient zu verarbeiten.
Mittlerweile hat sich XML als standardisiertes Austauschformat bew ährt und
durchgesetzt und da speziell ausländische Bibliotheken mit dem MAB2-Format
zu kämpfen haben, ist zu erwarten, dass auch die DDB längerfristig einen neuen Standard auf XML-Basis erarbeiten wird. Diese Arbeit sollte zeigen, dass ein
solcher Wechsel durchaus realistisch ist.
Weiter ist die Konvertierung des MAB2-Standards in XML praktisch komplett
umgesetzt worden, somit ist das vorgestellte XML-Datenmodell ebenfalls fast
komplett. Bei der Übersetzung in das XML-Format wurden auch bereits erste Optimierungen, wie die Stoppwortentfernung, eingesetzt. Diese erm öglicht effiziente Anfragen zu stellen, da bereits die unwichtigen Wörter innerhalb bestimmter
Datenfelder entfernt sind.
Diese Arbeit stellt eine Lösung vor, wie die täglichen Updates effizient und
ressourcensparend in die bestehenden Daten eingepflegt werden. Dabei muss
bei der Verarbeitung der aktuelle Datenbestand und die Aktualisierungsdaten
einmalig von der Festplatte gelesen werden.
45
46
KAPITEL 5. FAZIT
Zur Bewertung des vorgelegten Vorschlags wurde eine Evaluierung der SuchPerformance durchgeführt. Durch die bessere Darstellung der Semantik der Daten ist es nun möglich, qualitativ bessere Suchanfragen zu formulieren. Ein Beispiel dafür, wäre die Suche nach bestimmten Schlagworten. Die Verarbeitungszeit der gestellten Abfragen war schon sehr vielversprechend und durch den
Einsatz weiterer Optimierungen wird ein nochmaliger Geschindigkeitsvorteil erwartet. Nicht nur, dass Pathfinder weiterentwickelt wird, auch werden neue Erkenntnisse der Forschung eingepflegt. Dazu zählt auch die XQuery-Erweiterung
für Volltexte. Sie nutzt die Werkzeuge des Information Retrievals zur besseren
Suche in Volltexten.
Auch könnte die erste Verbindung der beiden Programme weitere Erkenntnisse liefern, indem mit der Analyse von DROID eventuelle Flaschenh älse aufgespürt werden könnten. Denn erst durch die Vereinigung des Frontends – der
grafischen Oberfläche – mit dem Backend – der XML-Schnittstelle – kann das System als Ganzes getestet und genutzt werden.
Weiter ist von Seiten des MedioVis-Projektes geplant, dass die bestehenden
Bibliotheksdaten mit zusätzlichen Daten angereichert werden. So sollen Zusammenfassungen, Rezessionen, Bilder, Trailer etc. hinzugef ügt werden. Diese stammen von anderen Quellen, wie z. B. von der IMDb (Internet Movie Database)
[20]. Diese Film-Datenbank bietet zu fast allen Filmen detaillierte Informationen
über die Schauspieler, den Regisseur, in welchen Sprachen diese erschienen sind
usw. Es werden damit Suchmöglichkeiten in Daten geschaffen, die nicht von den
herkömmlichen Bibliotheken erfasst wurden.
Anhang A
Zuordnung der XML-Tags
Die nachfolgenden Tabellen geben die Zuordnungen an, wie die MAB2-Felder in
XML überführt wurden. In der Spalte ’Vaterknoten’ werden die entsprechenden
Knoten angegeben, unter denen der Tag aus der Spalte ’XML-Tag’, untergeordnet
sind.
A.1
Allgemeine Felder
MAB2-Feldnr.
Ind. XML-Tag
Vaterknoten
001
als Attribut im Medientyp -
002
datum
datensatz, ersterfassung
003
datum
datensatz, korrektur
005
transaktionsdatum
datensatz
a
b
lc nspez
lc swd
laendercode
b
kennzeichen
kennzeichen
datensatz, ersterfassung
datensatz, korrektur
a
b
e
k
n
v
d
k
m
p
rech abrufzeichen
nrech abrufzeichen
swd id
korrekturdatum
neuzugangsdatum
versionsnummer
namensform
rkoerperschaft
massstab
rpersonen
036
070
076
077
47
swb
ANHANG A. ZUORDNUNG DER XML-TAGS
48
MAB2-Feldnr.
078
Ind. XML-Tag
s
t
u
v
a
b
f
k
p
v
bandzaehlung uw
opus nummer
feldinhalt
sonstige nummern
adressierung
bearbeitungshinweis
fehlermeldungen
kommentar
freie textfelder
lokaldaten konversion
besitzangabe
herkunftsangabe
080
525
A.2
Vaterknoten
swb
Titeldatei
MAB2-Feldnr.
Ind.
XML-Tag
Vaterknoten
010
uebergeordnet werk id
-
025
a
b
c
e
l
o
z
bna locdk id
ddb
bnb
casalini libri
ekz
loc
oclc
zdb
ueberregionale id
026
g
bib verb bayern
-
037
a
b
z
sc din
sc iso
sc swb
sprachencode
039
z
zeitcode
-
081
oberbegriff mehrb werkes
-
086
087
text
src
089
bandangabe VF
-
102, 106, . . . , 198
verfasser
-
202, 206, . . . , 298
lkoerperschaft
-
link
A.2. TITELDATEI
MAB2-Feldnr.
49
Ind.
XML-Tag
Vaterknoten
300
sammlungsvermerk
-
304
einheitstitel
titel,
einheitssachtitel
310
331
333
ansetzungsform
vorlageform
urheber
titel,
hauptsachtitel
334
materialbenennung
beschreibung
335
zusaetze
titel,
hauptsachtitel
ansetzungsform
vorlageform
urheber
zusaetze
titel,
parallelsachtitel
359
allgemein
beschreibung
360
unterreihe
titel
361
beigefuegte werke
-
365
zusatz gesamt
titel
369
verfasser gesamtvorlage
-
a
b
c
unter sachtitel
mit sachtitel
unter mit sachtitel
weitere sachtitel
b
c
d
normierter zs titel
coden
key title
kurztitel inis
normierter titel
403
auflage
-
405
erscheinungsverlauf
beschreibung
407
mathematische angaben
-
340, 344, . . . , 352
341, 345, . . . , 353
342, 346, . . . , 354
343, 347, . . . , 355
370
376
410
412
415
417
a
a
a
a
ort
verleger
drucker
name
verleger
drucker
ort
verleger
drucker
name
verleger
drucker
ANHANG A. ZUORDNUNG DER XML-TAGS
50
MAB2-Feldnr.
XML-Tag
Vaterknoten
vorlageform
ansetzungsform
erster band
letzter band
publikation
erscheinungsjahr
427
zusammenf bestandsang
-
432
433
437
zus offene bandfuehrung
kollationsvermerk
begleitmaterialien
beschreibung
vorlageform
gesamttitel id
ansetzungsform
bandzaehlung
bandzaehlung SF
gesamttitel
501
fussnote
beschreibung
502
beigefuegtes werk
einheitssachtitel
503
dt uebersetzung
hauptsachtitel
509
519
523
vermerk verfasserang
hochsch schrift verm
erscheinungsweise
beschreibung
526
titel rezensierter werke
titel
527
529
531
533
534
536
537
hinweis fortl beilagen
titel fortl beilagen
hinweis frueh ausg
hinweis spaet ausg
titelkonkordanzen
vorauss ersch termin
redaktionsbemerkung
beschreibung
540
isbn
-
541
ismn
-
542
issn
-
543
isrn
-
druckschriften nr
URN
int artikel nr
hochschulschrift nr
report nr
amtliche druckschriften nr
425
Ind.
a
b
c
p
451, 461, . . . , 491
453, 463, . . . , 493
454, 464, . . . , 494
455, 465, . . . , 495
456, 466, . . . , 496
551
552
553
554
a
b
a
a
A.2. TITELDATEI
51
MAB2-Feldnr.
Ind.
XML-Tag
Vaterknoten
556
b
c
a
b
c
564
566
568
574
kontrakt nr
task nr
patentschrift nr
offenlegungsschrift nr
auslegungsschrift nr
norm nr
firmenschrift nr
cip ddb nr
nat bibliograph nr
amtliche druckschriften nr
590
594
fussnote
erscheinungsort
quelle unselbst werk
595
vorlageform
596
bandzaehlung
quelle unselbst werk
599
selbstaend schrift id
-
fussnote einl
fussnote
ort
name
sekundaer form
619
vorlageform
sekundaer form,
erscheinungsjahr
621
623
624
625
626
633
vorlageform
gesamttitel id
ansetzungsform
bandangabe
bandszaehlung SF
abweichungen titel
sekundaer form
gesamttitel
634
637
638
640
isbn
umfangsangabe
begleitmaterialien
ausgabebezeichnung
sekundaer form
651
fussnote comp
-
655
$u → url
$x → sonstige url
-
562
610
611
613
a
u
u
e
quelle unselbst werk,
erscheinungsjahr
ANHANG A. ZUORDNUNG DER XML-TAGS
52
MAB2-Feldnr.
Ind.
XML-Tag
Vaterknoten
$z → lizenz url
a
b
c
normierter erscheinungsort
normierter erscheinungsort
hochschulort
beschreibung
675
stichwoerter
-
700
lokal
udc
ddc
lc
dnb
regensburger verbundklass
zdb systematik
klassifikation
lschlagwort
-
herkunftsangabe
-
673
a
b
c
d
g
z
902, 907, . . . , 947
904, 909, . . . , 949
A.3
a
Personendatei
MAB2-Feldnr.
028
Ind. XML-Tag
a
Übergeordenter Tag
normdaten id
-
675
stichwoerter
-
800
name AF
-
801
802
803
quelle
benutzungshinweis
bemerkung
RAK AF
804
a
ergebnislose-quelle
-
814
a
i
leben
funktion
daten
820
g
j
m
z
sonstige rak
aacr
aufgeloest
sonstige
weitere AF
name AF
-
830
A.4. KÖRPERSCHAFTSDATEI
A.4
53
Körperschaftsdatei
MAB2-Feldnr.
Ind. XML-Tag
655
url
-
800
name
-
daten AF
abkuerzung AF
-
uebergeordnet id
-
a
b
801
806
Übergeordneter Tag
810, 812, . . . , 849
verweisungsform -
852, 855, . . . , 894
k frueher id
-
stichwort
-
895
A.5
Schlagwortdatei
MAB2-Feldnr.
Ind. XML-Tag
Übergeordneter Tag
040
normdaten notation
-
800
hauptschlagwort
-
801, . . . , 805
unterschlagwort
-
quelle
definition
benutzungshinweise
redaktionelle bemerkungen
erlaeuterung
alternativ
-
untersw alternativ
-
830
aequivalent
-
845
oberbegriff
-
850
uebergeordnet
-
860
verwandt
-
870
frueher
-
880
spaeter
-
890
neues
-
891
altes
-
808
820
821, . . . , 830
a
b
c
d
ANHANG A. ZUORDNUNG DER XML-TAGS
54
A.6
Medientypen
Der Medientyp wird anhand des Datenfeldes der MAB2-Feldnummer 029 ermittelt. Die nachfolgende Tabelle zeigt die entsprechendende Überführung in XMLTags auf.
Datenfeld XML-Tag
Beschreibung
b
kart
mikro
ton
videk
videm
mk
cofz
crom
dvd
dvdr
disk
dias
se
so
uw
mb
mw
zs
zse
zscrom
zsdvdr
zt
zte
ztcrom
ztdvdr
interim
paket
Buch
Karten
Mikromaterial
Tonträger
Video (Kauf)
Video (Mitschnitt)
Medienkombination
Online-Quelle
CD-ROM
DVD
DVD-ROM
Disketten
Dias
Serien
Sonstiges Non-Book-Material
enthaltenes Werk
mehrteiliges Buch
mehrteiliges Werk
Zeitschrift
Online-Zeitschrift
Zeitschrift auf CD-ROM
Zeitschrift auf DVD-ROM
Zeitung
Online-Zeitung
Zeitung auf CD-ROM
Zeitung auf DVD-ROM
Interim
Paket-ABO
buch
karte
mikrofiche
tontraeger
video
video mitschnitt
medienkombination
online quelle
cdrom
dvd
dvdrom
diskette
dias
serie
—
enthaltenes werk
mehrband buch
mehrband werk
zeitschrift
online zeitschrift
cd zeitschrift
dvd zeitschrift
zeitung
online zeitung
cd zeitung
dvd zeitung
—
—
A.7. SCHLAGWORTATTRIBUTE
A.7
55
Schlagwortattribute
Die Schlagwörter werden in Kategorien unterteilt, um ein Schlagwort besser zu
spezifizieren zu können. Die möglichen Schlagwortkategorien zeigt die nachfolgende Tabelle.
Indikator
XML-Attribute
c
f
g
k
p
s
t
z
unter
koerperschaft ort
form
geographisch
koerperschaft
person
sach
werktitel
zeit
56
ANHANG A. ZUORDNUNG DER XML-TAGS
Literaturverzeichnis
[1] BerkeleyDB. http://www.sleepycat.com/products/db.shtml.
[2] Bibliotheksservice-Zentrum Baden-Württemberg. http://cms.bsz-bw.de/
cms/service/datendienste/export3-mab2/index_html#Export.
[3] P. A. Boncz. Monet: A Next-Generation DBMS Kernel For Query-Intensive Applications. Ph.D. Thesis, Universiteit van Amsterdam, Amsterdam, The Netherlands, May 2002.
[4] Peter Boncz, Torsten Grust, Stefan Manegold, Jan Rittinger, and Jens Teubner. Pathfinder: Relational XQuery Over Multi-Gigabyte XML Inputs in Interactive Time. Technical Report INS-E0503, CWI, 2005.
[5] Chavdar Botev, Sihem Amer-Yahia, and Jayavel Shanmugasundaram. A
TeXQuery-Based XML Full-Text Search Engine. In SIGMOD Conference, 2004.
[6] Michael Brundage. XQuery - The XML Query Language. Addision-Wesley,
2004.
[7] Die Deutsche Bibliothek. http://www.ddb.de.
[8] Die Deutsche Bibliothek. Hrsg. in Zsarb. mit d. MAB-Ausschuß im Auftr. d.
Dt. Forschungsgemeinschaft. Maschinelles Austauschformat für Bibliotheken.
Dt. Bibliothek, Leipzig, 1999.
[9] DROID. http://hci.uni-konstanz.de/research/projects/droid/.
[10] Google. http://www.google.de.
[11] Christian Grün. Entwicklung eines visuellen Metadaten-Browsers für die
Mediothek Konstanz. Master’s thesis, Universit ät Konstanz, 2004. http:
//hci.uni-konstanz.de/downloads/MA-CG.pdf.
[12] Josef Labner. MAB2 – Grundsätzliches, Status und Perspektiven. http://
www.onb.ac.at/koop-litera/termine/kooplitera2003/labner_2003.pdf.
57
LITERATURVERZEICHNIS
58
[13] MAB2-Standard. http://www.ddb.de/professionell/mab.htm.
[14] MABxml. http://www.ddb.de/professionell/mabxml.htm.
[15] MARCXML. http://www.loc.gov/standards/marcxml/.
[16] James McGovern, Per Bothner, Kurt Cagle, James Linn, and Vaidyanathan
Nagarajan. XQuery - Kick Start. SAMS, Indianapolis, 2004.
[17] Stelios Paparizos, Shurug Al-Khalifa, Adriane Chapman, H. V. Jagadish,
Laks V. S. Lakshmanan, Andrew Nierman, Jignesh M. Patel, Divesh Srivastava, Nuwee Wiwatwattana, Yuqing Wu, and Cong Yu. TIMBER: A Native
System for Querying XML. In SIGMOD Conference, page 672, 2003.
[18] PostgreSQL. http://www.postgresql.org/.
[19] Relax NG. http://www.relaxng.org/.
[20] The Internet Movie Database. http://www.imdb.com/.
[21] X-Hive. http://www.x-hive.com.
[22] XML Schema. http://www.w3.org/TR/xmlschema-1/.
[23] XML Spezifikation. http://www.w3c.org/xml/.
[24] XPath 2.0. http://www.w3.org/TR/xpath20/.
[25] XQuery 1.0 and XPath
xquery-full-text/.
2.0
Full-Text.
http://www.w3.org/TR/