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¨at Konstanz
April, 2005
XML-Datenbanksystem
Volker Wildi
wildi@inf.uni-konstanz.de Universit¨at Konstanz, 2005 Erstgutachter: Prof. Dr. Scholl Zweitgutachter: Prof. Dr. Deussen
Zusammenfassung
Diese Bachelorarbeit stellt eine L¨osung zur Konvertierung aus dem MAB2-For- mat, einem Austauschformat f ¨ur deutschsprachige Bibliotheken, in das XML- Format vor. Diese L¨osung entstand im Rahmen des MedioVis-Projektes aus der Notwendigkeit einer Datenbankanbindung an der Universit¨at Konstanz. Medio- Vis ist eine moderne Art einer Suchmaschine mit vielen Innovationen.
Als erstes wurde ein Datenmodell in XML konstruiert, um die Bibliotheksda- ten ad¨aquat darin abzuspeichern. Zweitens wurden die bestehenden Bibliotheks- daten in dieses XML-Datenschema konvertiert. Als drittes wurde eine L ¨osung f ¨ur das Einspielen der t¨aglichen Updates der Bibliotheksdaten vorgestellt. Abschlie- ßend wurde eine Evaluation an diesem System durchgef ¨uhrt.
Der Einsatz von XML wurde deshalb gew¨ahlt, da neue Datenbanksysteme effizient damit umgehen k¨onnen. Beispiele f ¨ur solche Datenbanksysteme sind z. B. Pathfinder [4], TIMBER [17], X-Hive [21], usw.
i
Inhaltsverzeichnis
Zusammenfassung . . . i
1 Einf ¨uhrung . . . 1
1.1 Thematischer Hintergrund . . . 1
2 Grundlagen . . . 3
2.1 XML . . . 3
2.1.1 Aufbau einer XML-Datei . . . 3
2.1.2 Festlegung der Dokumentstruktur . . . 4
2.1.3 Entit¨aten . . . 4
2.2 Anfragen mit XQuery . . . 6
2.2.1 Einf ¨uhrung . . . 6
2.2.2 Allgemeiner Aufbau . . . 7
2.2.3 Abk ¨urzungen . . . 8
2.2.4 Pfadausdr ¨ucke . . . 9
2.2.5 Pr¨adikate . . . 10
2.3 Der MAB2-Standard . . . 11
2.3.1 Einf ¨uhrung . . . 11
2.3.2 Datensatz . . . 13
2.3.3 Datenfeld . . . 14
3 Implementierung . . . 17
3.1 Konstruktion des XML-Datenschemas . . . 17
3.1.1 Grundstruktur . . . 17
3.1.2 Umsetzung einzelner Datens¨atze in XML . . . 19
3.2 Konvertierung von MAB2 nach XML . . . 21
3.2.1 Grundstruktur . . . 21
3.2.2 Funktionsweise . . . 23
3.2.3 Einsatz einer Stoppwortliste . . . 24
3.3 Einf ¨ugen von Aktualisierungen . . . 26 ii
3.3.2 Umsetzung in C++ . . . 28
4 Leistungsmessung. . . 33
4.1 Das eingesetzte Datenbanksystem . . . 33
4.2 Vergleich zwischen den Formaten . . . 34
4.3 Typische Suchanfragen . . . 36
4.3.1 Identifizieren von typischen Anfragen . . . 36
4.3.2 Erstellung von Suchanfragen . . . 37
4.3.3 Bessere Suchm¨oglichkeit . . . 41
4.3.4 Bewertung der Suchanfragen . . . 42
4.3.5 Verbesserungsm¨oglichkeiten . . . 43
5 Fazit . . . 45
Anhang A Zuordnung der XML-Tags . . . 47
A.1 Allgemeine Felder . . . 47
A.2 Titeldatei . . . 48
A.3 Personendatei . . . 52
A.4 K¨orperschaftsdatei . . . 53
A.5 Schlagwortdatei . . . 53
A.6 Medientypen . . . 54
A.7 Schlagwortattribute . . . 55
Literaturverzeichnis. . . 57
iii
Kapitel 1 Einf ¨uhrung
1.1 Thematischer Hintergrund
Die Idee dieser Arbeit entstand aus der Notwendigkeit f ¨ur eine Datenbankanbin- dung der Bibliotheksdaten f ¨ur das ProjektMedioVis[11] am Fachbereich Mensch- Computer-Interaktion von Prof. Dr. Reiterer an der Universit¨at Konstanz im Jah- re 2004. Bei MedioVis handelt es sich um eine grafische Benutzeroberfl¨ache zum Suchen und St¨obern in multimedialen Bibliotheken. Zus¨atzlich bietet MedioVis weitere Innovationen.
F ¨ur MedioVis m ¨ussen die Mediotheksdaten aufbereitet werden, da sie in ei- nem speziellen Format vorliegen. Die Entwicklung einer L ¨osung ist Gegenstand dieser Arbeit. Zu Beginn der Testphase wurde ein kleiner Datenbankabzug von knappen 10 MB in einer einfachen Textdatei gespeichert, f ¨ur eine große Daten- bank ist diese L¨osung 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 ¨ogliches Medium) gleich aufgebaut ist. Ein Medium in einer Bibliothek kann ein Buch, ei- ne Zeitschrift, eine DVD oder sonst ein ver ¨offentlichtes Werk sein. Weiter k¨onnen mehrere Verfasser ein Medium verfasst haben. W ¨urde man dieses Szenario in ei- ner relationalen Datenbank wie PostgreSQL realisieren wollen, w ¨urden aufgrund der gew ¨unschten Normalisierung, also zur Vermeidung der Abspeicherung von redundanten Daten, sehr viele Tabellen entstehen. Diese Tabellen k ¨onnen u. U.
sehr viele Nullwerte enthalten, welche sich negativ auf die Anfrageperformance auswirken. F ¨ur die Zukunft ist geplant noch weitere Datenbanken anzubinden, wie z. B. dieInternet Movie Database (IMDb), diese k ¨onnen nicht ohne weiteres in die bestehende Datenbank eingef ¨ugt werden.
1
Eine unstrukturierte Datei, wie z. B. Volltext, h¨alt sich nicht an strukturelle Vorgaben. Ein solcher Text weist keinerlei Struktur auf. Im Gegensatz dazu, zeich- nen sich RDBMS gerade durch ihre Strukturiertheit aus. Diese RDBMS haben folglich Probleme beim Umgang mit unstrukturierten Daten. Genau diese L ¨ucke schließt XML praktisch, indem einzelne Textbereiche in Strukturtags gesetzt wer- den, um eine gew ¨unschte Struktur zu erhalten. Diese Art der Abspeicherung wird als semistrukturiert bezeichnet. F ¨ur den komplexen Aufbau dieser biblio- graphischen Daten eignet sich daher XML sehr gut, da die Schemainformationen mit den Daten abgespeichert werden.
Im Ausland existieren bereits erste Bestrebungen zur Umsetzung der biblio- graphischen Daten in das XML-Format, darunter f ¨ur den nordamerikanischen StandardMARC (Machine-ReadableCataloging)mit der BezeichnungMARCXML [15]. Dies sollte auch Motivation sein, um ebenfalls eine XML-L ¨osung f ¨ur die deutschsprachigen Bibliotheken zu konstruieren. Es d ¨urfte eigentlich nur noch ei- ne Frage der Zeit sein bis sich XML als Austauschformat der Bibliotheken durch- setzen wird.
All diese Gr ¨unde sprachen f ¨ur den Einsatz einer XML-Datenbank f ¨ur Medio- Vis. Somit ist nun ein weiterer Fachbereich an der Entwicklung an MedioVis be- teiligt. Bei diesem Fachbereich handelt es um den Lehrstuhl Datenbanken und Informationssysteme von Prof. Dr. Scholl, welcher das Datenbank-Backend ent- wickelt. Die Datenbank sollte anf¨anglich nur die Mediotheksdaten enthalten, al- lerdings 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¨aufig 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 wohl- geformtes XML-Dokument enth¨alt einen oder mehrere Elemente, die durch die Start- und Endtags begrenzt sind, und ordentlich ineinander verschachtelt sein m ¨ussen. Die Tags k¨onnen also beliebig verschachtelt werden, d ¨urfen sich aber nicht ¨uberlappen. Es entsteht eine sehr flexible Struktur. Listing 2.1 zeigt wie ei- ne Film-Videokassette in XML beschrieben werden k ¨onnte. Dieser Datei k¨onnen noch weitere Felder hinzugef ¨ugt werden, ohne dass sie nicht mehr wohlgeformt ist, vorausgesetzt s¨amtliche Felder sind wohlgeformt.
Soll nun die Flexibilit¨at einer XML-Datei eingeschr¨ankt werden, also eine be- stimmte Struktur aufweisen um g ¨ultig zu sein, so m ¨ussen feste Regeln definiert werden. Diese Regeln geben die Reihenfolge der XML-Tags vor und werden in ei- ner so genanntenDTD (Document Type Definition)gespeichert. H¨alt sich ein wohl- geformtes XML-Dokument an die Einschr¨ankungen aus der DTD, so wird das Dokument auch als g ¨ultig bezeichnet.
3
Listing 2.1: Einfaches Beispiel zu XML
<?xml version = ” 1 . 0 ” encoding = ”UTF−8” ?>
<filme>
<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>Will 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>
</filme>
2.1.2 Festlegung der Dokumentstruktur
Die Regeln innerhalb der DTD werden mit Hilfe von regul¨aren Ausdr ¨ucken de- finiert. Die H¨aufigkeit einzelner Elemente kann mit Hilfe von ’?’, ’+’ oder ’*’
nur grob eingeschr¨ankt werden. Bei der Angabe von ’+’ oder ’*’ hinter dem Ele- mentnamen kann keine obere Grenze angegeben werden. Falls eine weitere Ein- schr¨ankung der H¨aufigkeitsangabe von Elementen erw ¨unscht ist, so ist ein ¨Uber- gang zuXML Schema [22]oder zuRelax NG [19]notwendig. Diese beiden Ans¨atze sind recht neu und werden zur Zeit nur teilweise ausreichend unterst ¨utzt, des- halb wurden sie bei dieser Arbeit nicht eingesetzt. Eine bessere Unterst ¨utzung oder eine feinere Angabe der H¨aufigkeiten in der Zukunft k¨onnten es notwendig machen, die bisherige DTD in eine der Alternativen zu ¨uberf ¨uhren.
Listing 2.2 zeigt eine Beispiel-DTD f ¨ur eine Filmsammlung. Die m¨oglichen Fil- me liegen auf DVD oder VHS vor. Jeder Film hat immer einen Titel, ein Ver ¨offent- lichungsjahr, einen Regisseur, einen oder mehrere Schauspieler und vielleicht ei- ne 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¨aten
Die Merkmaletitel, staffel, jahr, schauspielerundregie wiederholen sich bei beiden Medientypen in der DTD, wobei dann die gleichen Zeilen stehen m ¨ussten. Bei komplexeren Elementen leidet mit der Zeit die ¨Ubersichtlichkeit.
Deshalb gibt es unter XML das KonstruktEntit¨at.
Das Schl ¨usselwortENTITY hat drei verschiedene Bedeutungen. Erstens kann es zur Ersetzung von Strings dienen, wie ein#definein der Programmiersprache C bzw. C++. Zweitens als Verkn ¨upfung mit einer anderen XML-Datei oder als
Listing 2.2: DTD f ¨ur eine Filmsammlung
<!ENTITY % AllgFelder ” t i t e l ,
s t a f f e l ? , jahr ,
s c h a u s p i e l e r + , r e g i e
” >
<!ELEMENT filmsammlung ( dvd | vhs ) >
<!ELEMENT dvd (%AllgFelder ; ) >
<!ATTLIST dvd id ID #REQUIRED
genre CDATA #REQUIRED >
<!ELEMENT vhs (%AllgFelder ; ) >
<!ATTLIST vhs id ID #REQUIRED
genre CDATA #REQUIRED >
<!ELEMENT t i t e l (#PCDATA) >
<!ELEMENT j a h r (#PCDATA) >
<!ELEMENT s t a f f e l (#PCDATA) >
<!ELEMENT r e g i e (#PCDATA) >
<!ELEMENT s c h a u s p i e l e r (#PCDATA) >
Platzhalter von Nicht-XML-Daten. Im Beispiel und bei dieser Arbeit wird die erste Bedeutung benutzt.
Der Zugriff auf eine vorher definierte Entit¨at erfolgt, indem dem Namen der Entit¨at ein ’%’ vorangestellt und am Ende ein ’;’ angeh¨angt wird. F ¨ur die Entit¨at AllgFeldersieht dies wie folgt aus ’%AllgFelder;’. Allerdings k ¨onnen auch ein- zelne Datenfelder zu bestimmten Medientypen hinzugef ¨ugt werden, indem an die allgemeinen Datenfelder mit dem Sequenzoperator ’,’ die erweiterten Felder angereiht werden. So k¨onnte vielleicht auch die Angabe der Kapitel auf der DVD interessant sein und w ¨urde deshalb ein zus¨atzliches optionales Attribut namens kapitelbekommen. Listing 2.3 zeigt wie dies in der DTD dann aussehen w ¨urde.
Ein Beispiel eines Datenbankauszugs zeigt Listing 2.4.
Listing 2.3: Erweiterung der Attribute
<!ELEMENT dvd (%AllgFelder ; , k a p i t e l ? ) >
<!ELEMENT k a p i t e l (#PCDATA) >
Listing 2.4: XML-Beispieldokument
<?xml version = ” 1 . 0 ” encoding = ”UTF−8” ?>
<!DOCTYPE filmsammlung SYSTEM ”filmsammlung . dtd”>
<filme>
<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>Will 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 Dorff</ 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>
</filme>
2.2 Anfragen mit XQuery
Die im Bibliothekskontext auftretenden Datenbanken erfordern effektive Techni- ken zur Recherche in XML-Dokumenten. Hierf ¨ur ist der Einsatz der XML-Anfra- gesprache 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¨osungen existieren, die riesige XML-Dokumente effi- zient verarbeiten k¨onnen.
2.2.1 Einf ¨uhrung
XQuery wurde 1998 durch das W3C als strikte Anfragesprache spezifiziert. Im Gegensatz zu SQL k¨onnen keine neuen Relationen bzw. XML-Strukturen ange- legt werden. Der Syntax von XQuery ist f ¨ur XML-Umsteiger etwas gew¨ohnungs- bed ¨urftig, stellt sich aber nicht allzu schwierig dar. Ein integraler Bestandteil von XQuery 1.0 istXPath 2.0[24], wodurch ein korrekter Ausdruck in XQuery auch in XPath 2.0 g ¨ultig 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.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 Ver- schachtelungen der einzelnen XML-Tags, entsteht dadurch eine logische Baum- struktur. Abbildung 2.1 zeigt die graphische Darstellung der XML-Datei aus Lis- ting 2.4, wobei aber aus Gr ¨unden der ¨Ubersichtlichkeit auf die Darstellung der Attributknoten verzichtet wurde.
Mit der gegebenen Baumstruktur gibt es f ¨unf verschiedene Knotentypen zu unterscheiden. Zuerst w¨are derElementknotenzu nennen, der wiederum mehrere Kindknoten besitzen kann. DerTextknoten enth¨alt einfachen Text und ist immer ein Blatt im Baum. Die dritte Knotenart sind dieAttributknoten, diese spielen ei- ne besondere Rolle, da sie keine Kinder des zugeh ¨origen Elementknotens sind, sondern dem Elementknoten ’geh¨oren’. Dies ist auch der Grund, warum die At- tributknoten nicht in der Ergebnismenge der XQuery-Achsen vorkommen. Ab- schließend gibt es noch dieKommentarknoten und die Processing Instruction Kno- ten, letztere enthalten Anweisungen f ¨ur die Anwendung und werden vom XML- Prozessor nicht verarbeitet. Diese beiden sind ebenfalls Blattknoten im Baum.
Der oberste Elementknoten in einem Baum wird als Wurzelknoten bezeichnet.
In Abbildung 2.1 tr¨agt der Wurzelknoten den Namenfilme. Alle anderen Knoten sind Kindknoten von diesem Knoten. Im Beispieldokument sind das die Knoten mit der BezeichnungBlade,1996,Stephen Norringtonusw.
Zum Vergleich ist ein Verzeichnis auf einem Dateisystem auch in einer Baum- struktur aufgebaut. Ein Ordner kann mehrere Unterverzeichnisse und auch Da- teien enthalten. Diese Ordner sind die Elementknoten und die einzelnen Dateien sind Bl¨atter im Baum. Um die Stelle zu finden, wo eine bestimmte Datei abge- legt ist, ist ein Pfad anzugeben. Auf einem UNIX-System w ¨urde dieser wie folgt aussehen: /etc/modules.conf. Damit ist im Ordner etcdirekt unter dem Wur- zelverzeichnis ’/’ die Datei modules.conf zu finden. Allerdings kann in einem Dateisystem immer nur eine Datei mit dieser Bezeichnung existieren. In XML da- gegen 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¨aher beschrieben.
Der Baum einer XML-Datei ist – im Gegensatz zum Dateisystem – geordnet, d. h. die Reihenfolge der XML-Knoten ist durch die Dokumentordnung vorge- geben. Die Dokumentordnung entspricht der Abarbeitung der Knoten bei einer Tiefensuche von links nach rechts. Mit anderen Worten, ist dies die Originalrei- henfolge der Knoten im Dokument. In Abbildung 2.1 geben die Nummern neben Tagnamen diese Reihenfolge an.
filme dvd
titel
”Blade”
jahr
”1996”
schau- spieler
”Wesley Snipes”
schau- spieler
”Stephen Dorff”
regie
”Stephen Norrington”
vhs titel
Boys””Bad
. . .
1 2
3
4
5
6
7
8
9
10
11
12
13 14
15
ancestor
descendant
preceding following
Abbildung 2.1: Baumdarstellung der XML-Datei
Bei genauerer Betrachtungsweise dieser Baumstruktur f¨allt auf, dass diese Knoten alle miteinander in Beziehung stehen. Es gibt vier Hauptbeziehungen, die als Vorfahre-, Nachkomme-, Vorg¨anger- und Nachfolger-Beziehung bekannt sind. Diese Beziehungen werden in XQuery als Achsen bezeichnet. So ist z. B. der Knotendvdein Vorfahre (ancestor) und der KnotenWesley Snipesein Nachkom- me (descendant) vom Knoten regie. Die beiden schauspieler-Knoten z. B. sind Vorg¨anger (preceding) vom Knotenregie. Nachfolger (following) sind sind z. B. die Knotenvhsundtitel. Eine wichtige Beobachtung dieser vier Regionen ist, dass sie symmetrisch und disjunkt sind. Mit anderen Worten ausgedr ¨uckt, liegen die descendant- und dieancestor-Achse sich gegen ¨uber, genauso wie die beiden Ach- senprecedingundfollowing. Jeder Knoten ist in einer – und nur in einer – der vier Regionen enthalten. Der aktuelle Knoten bezeichnet man auch alsKontextknoten.
In Abbildung 2.1 sind diese vier Hauptachsen farbig eingef¨arbt f ¨ur den Kon- textknotenregie. Dabei entsprechen die Farben den Achsenancestor,descendant, precedingundfollowing.
Tabelle 2.1 gibt einen ¨Uberblick ¨uber die insgesamt 12 Achsen von XQuery.
2.2.3 Abk ¨urzungen
H¨aufig benutzte Achsen k¨onnen in XQuery auch abgek ¨urzt werden. Die Ach- se attribute kann dadurch abgek ¨urzt werden, indem ein ’@’ vor den Namen des Attributes gesetzt wird. Der Grund f ¨ur das Zeichen ’@’ l¨asst sich dadurch erkl¨aren, da es als ’at’ ausgesprochen wird und daher im Wort ’attribute’ ent- halten ist. Hingegen wird der Schritt descendant-or-self::node() durch ’//’
abgek ¨urzt. Die Abk ¨urzung f ¨ur den Vaterknoten und den aktuellen Knoten wer- den, wie bei einem Dateisystem gewohnt, mit ’..’ und ’.’ abgek ¨urzt. Wird nur ein Tagname angegeben, so ist dies die Abk ¨urzung f ¨ur diechild-Achse.
Achseα Erreichbare Knoten vom Kontextknoten c
ancestor Alle Vorfahren von c
ancestor-or-self Wieancestorplus c
child Kinder von c
descendant Alle Nachkommen von c
descendant-or-self Wiedescendantplus c
following Alle Nachfolger von c
following-sibling Geschwister von c in der Nachfolger-Region
parent Vater von c
preceding Alle Vorg¨anger von c
preceding-sibling Geschwister von c in der Vorg¨anger-Region
self c
attribute Attribute von c
Tabelle 2.1: XQuery-Achsen
2.2.4 Pfadausdr ¨ucke
Eine XQuery-Anfrage besteht immer aus einem Pfadausdruck, dem Hauptkon- strukt von XQuery. Jeder Pfadausdruck besteht aus einem oder mehreren Schrit- ten, die durch einen ’/’ getrennt sind. Ein Pfadausdruck gibt die Navigation durch den Baum an. Allgemein ausgedr ¨uckt, sieht ein Pfadausdruck wie folgt aus:
s0/s1/ . . . /sn.
Absolute Pfadangaben beginnen, wie auch bei Dateisystemen, mit einem ’/’
am Anfang. Dieser Knoten wird auch alsDokumentknoten bezeichnet und ist ei- gentlich 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 entspre- chen. Tabelle 2.2 zeigt eine ¨Ubersicht ¨uber die verschiedenen Knotentests. Typi- scherweise 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 werdenTypentest (engl. kind test) ge- nannt.
Der Zugriff auf einen Dokumentknoten erfolgt mit der XQuery-Funktiondoc, dieser wird der Name der zu ¨offnenden Datei ¨ubergeben. Bei den nachfolgenden Anfragen wird diese nicht mehr mit angegeben, da die Anfragen entscheidend
Node Testν liefert Knoten der Art
node() jeder Knoten, egal welchen Typs
∗ nur Elementknoten
Tagname t nur Elementknoten mit Bezeichnung t
text() nur Textknoten
comment() nur Kommentarknoten
processing-instruction(t) nur Processing Instructions der Form<?t . . .?>
Tabelle 2.2: M¨ogliche 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 : : filme/child : : dvd [child : : t i t e l / t e x t ( ) = ” Blade ”]
Das Ergebnis einer Anfrage wird als Sequenz zur ¨uckgegeben, was einer Neue- rung zu XPath 1.0 entspricht. Diese Sequenz kann als einfache Liste betrachtet werden mit keinen, einem oder mehreren Elementen. Diese Elemente k ¨onnen alle unterschiedlichen Typs sein, z. B. Knoten aus dem XML-Baum, Strings oder Zah- len. Dar ¨uber hinaus sind diese Sequenzen flach, k ¨onnen also nicht verschachtelt werden. Der XPath- bzw. XQuery-Prozessor w ¨urde aus der folgenden Sequenz
(1,2,3,(”vier”,”f¨unf”,”sechs”),4,5) diese ’flachgeklopfte’ Sequenz machen
(1,2,3,”vier”,”f¨unf”,”sechs”,4,5)
Weiter ist das Ergebnis einer Anfrage immer duplikatfrei und die Reihenfolge der zur ¨uckgegebenen Knoten erfolgt in Dokumentordnung.
2.2.5 Pr¨adikate
Wie weiter oben schon bereits erw¨ahnt, k¨onnen in einem XML-Dokument mehre- re Knoten mit dem gleichen Tagnamen vorkommen. Um auf diese Knoten zuzu- greifen oder eine Bedingung anzugeben, werden in XQuery so genannte Pr¨adi- kate benutzt. Diese Pr¨adikate werden an einen Schritt mit eckigen Klammern an- gef ¨ugt. F ¨ur den Schritts und das Pr¨adikatpw ¨urde dies wie folgt aussehen:s[p], dabei kann das Pr¨adikatpeins von drei m¨oglichen Typen sein.
Istpeinnumerischer Ausdruck, wobeip ≥1ist, dann w ¨urde derp−teKnoten der Sequenz des Schrittesszur ¨uckgegeben, falls dieser ¨uberhaupt existiert. Dabei gilt es zu beachten, dass bei R¨uckw¨arts-Achsen, wie z. B.ancestor, preceding oder parent, die Nummerierungr ¨uckw¨artserfolgt.
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: :∗/ s c h a u s p i e l e r [ 2 ]
Handelt es sich beipum einenboolschen Ausdruck, dann werden nur die Kon- textknoten zur ¨uckgegeben, bei dem der Ausdruckpwahr ist. Die nachfolgende Anfrage listet alle Filmtitel auf, die im Jahre 1999 ver ¨offentlicht wurden.
/child : : filme/child : :∗[ child : : j a h r = 1999]/child : : t i t e l IstpeinPfadausdruck, dann wird jeder Kontextknotencvom Schrittszur ¨uck- geliefert, falls der Pfadausdruck p mindestens einen Knoten enth¨alt. Das nach- folgende Listing soll dies besser verdeutlichen, da es alle Filme ausgibt, die eine Staffelangabe besitzen, also Serien sind.
/child : : filme/child : :∗[ child : : s t a f f e l ]/child : : t i t e l
Beim Einsatz von Pr¨adikaten ist besonders darauf zu achten, dass diese eine h¨ohere Priorit¨at 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 ¨uhrung
Die Daten der Bibliothek sind im so genannten MAB2-Format (Maschinelles Aus- tauschformat f¨ur Bibliotheken, Version 2) [13] gespeichert. Die Version 2 l ¨oste im Jah- re 1995, nach zweij¨ahriger 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 ¨onnen. So sind z. B. ein neu- er Zeichensatz, neue Strukturen und Segmente hinzugekommen und die Satzty- pen in der Titeldatei wurden gek ¨urzt.
Dieses MAB2-Format ist das Standardformat deutschsprachiger Bibliotheken und wurde von derDDB (Die Deutsche Bibliothek)[7] in Frankfurt am Main spezi- fiziert. Es dient prim¨ar als Austauschformat der Bibliotheken untereinander, um auch gespeicherte bibliographische Daten, Norm- und Lokaldaten weiterzuge- ben. 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¨anzung 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¨age auf ¨Anderung oder Erweiterung zu stellen. Dies k ¨onnten zus¨atzliche Anforderungen durch neue Medientypen, die Unicode-Umstellung oder neue Funktionalit¨aten, wie Verbundleihe, sein [12].
Heutzutage besteht MAB2 aus f ¨unf einzelnen Datenformaten:
• MAB-Format f ¨ur bibliographische Daten (MAB-TITEL)
• MAB-Format f ¨ur Personennamen (MAB-PND)
• MAB-Format f ¨ur K¨orperschaftsnamen (MAB-GKD)
• MAB-Format f ¨ur Schlagw¨orter (MAB-SWD)
• MAB-Format f ¨ur Lokaldaten (MAB-LOKAL) und zwei weiteren provisorischen MAB2-Formaten:
• MAB-Format f ¨ur Adress- und Bibliotheksdaten (MAB-ADRESS)
• MAB-Format f ¨ur Klassifikations- und Notationsdaten (MAB-NOTAT) Die Dateinamen der einzelnen MAB2-Formate eines Datenbankabzugs unter- scheiden sich nur in ihrer Dateiendung. So tr¨agt die Titeldatei die Dateiendung
’t’ und die K¨orperschaftsdatei ein ’k’. F ¨ur die restlichen Dateien wird dies analog fortgesetzt.
Jedes dieser Datenformate basiert auf einer einheitlichen, integrierten und f ¨ur alle Formate g ¨ultigen Feldstruktur. Die MAB-Dokumentation [8] definiert und verdeutlicht durch zahlreiche Beispiele die Anwendung dieses Standards. Al- lerdings kann diese Arbeit nur eine allgemeine Einf ¨uhrung in diesen Standard geben, da dieser Standard sehr komplex ist und einiges Wissen aus dem Biblio- thekarswesen voraussetzt.
2.3.2 Datensatz
Jede der oben erw¨ahnten MAB2-Dateien enth¨alt mehrere Datens¨atze, so bein- haltet z. B. die Titeldatei Datens¨atze, die die erfassten Medien darstellen. Zwei Datens¨atze werden durch eine Leerzeile voneinander getrennt. Ein Datensatz enth¨alt mehrere Datenfelder, welche dann die eigentlich erfassten Daten aufwei- sen. Listing 2.5 zeigt ein Beispiel f ¨ur einen vollst¨andigen Datensatz aus der Titel- datei. Analog dazu ist der Aufbau der anderen Dateien.
Listing 2.5: Ein MAB2-Datensatz
### 00803 nM2 . 0 1 2 0 0 0 2 4 h 001 00036210
029 mb
002 a 1 9 8 5 0 1 0 1 003 20020823 005 n 2 0 0 4 0 8 2 6 026 g 8 0 0 9 2 0 2 2 6 9 030 dz1dcr |||||17 037 zdt .
050 a | | | | | | | | | | | | | 051 m ||||||
070 KNUB 070 bZRED 076 k102235 076 v3
100 Grimm , Heinrich 102 00138073
331 Deutsche B u c h d r u c k e r s i g n e t e des XVI . ...
335 Geschichte , S i n n g e h a l t und G e s t a l t u n g ...
359 Heinrich Grimm 410 W i e s b a d e n
412 Pressleu 425 1965 425 a1965 433 365 S .
537 SW 580 klub / ssc ; NR / L1UB ; 720 ff . bvb 675 s e c h z e h n t e n
700 g 0 0 2 9 5 2 4 9 AN 21410
700 g 0 0 1 1 0 4 5 3 AN 21400
902 g 00006213 D e u t s c h l a n d
902 s 00097657 D r u c k e r m a r k e
902 z 00224220 G e s c h i c h t e 1500 -1600
904 aSWB
907 g 00006213 D e u t s c h l a n d
907 s 00130851 V e r l e g e r m a r k e
907 z 00224220 G e s c h i c h t e 1500 -1600
909 aSWB
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 Zei- chen bzw. Zahlen werden alsFeldnummerbezeichnet. Diese Feldnummer liegt im Bereich von 001 bis 999, wobei nicht alle belegt sind. Das vierte Zeichen wird als Indikatorbezeichnet, da es die Feldnummer n¨aher beschreibt. Ein leerer Indikator bedeutet, dass die Feldnummer nicht n¨aher spezifiziert ist. Nach dem Indikator folgt das eigentlichevariable Datenfeld, welches noch ein weiteresSubfeldenthal- ten kann. Dieses Subfeld bietet die M ¨oglichkeit der weiteren Spezifizierung die- ser 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:
Feld- nummer
Indi- kator
Daten (variabel)
Subfeld Daten FE
Abbildung 2.2: Schematische Darstellung eines Datenfeldes
Die Feldnummer 001 enth¨alt im Datenfeld die eindeutige Identifikationsnum- mer dieses Datensatzes. Hingegen steht im Feld 029 mit Indikator ’m’ der Me- dientyp, der von der Universit¨at Konstanz aus anderen Feldnummern ausgewer- tet und somit aufbereitet wird, was eine leichtere Weiterverarbeitung erm ¨oglicht.
In den Feldern 100, 104, . . . 196 stehen die Namen der 1., 2., . . . 25. Person in Ansetzungsform. DieAnsetzungsform wird vom Bibliothekar vergeben, der die- ses Medium erfasst, im Gegensatz zurVorlageform, die so erfasst wird, wie sie auf dem Medium angegeben ist. Die Feldnummern 102, 106, . . . 198 beinhalten die
Indikator Bedeutung
Unterschlagwort einer Ansetzungskette
c K¨orperschaftsschlagwort: Ansetzung unter dem Ortssitz
f Formsschlagwort
g geographisch-ethnographisches Schlagwort
k K¨orperschaftsschlagwort: Ansetzung unter dem Indivi- dualnamen
p Personenschlagwort
s Sachschlagwort
t Werktitel als Schlagwort
z Zeitschlagwort
Tabelle 2.3: M¨ogliche Arten von Schlagw¨ortern
Identifikationsnummer des zugeh¨origen Namens der 1., 2., . . . 25. Person. Die- se Identifikationsnummer verweist auf einen Personendatensatz aus der MAB- PND-Datei. Bei einigen Feldnummern werden zur leichteren Lesbarkeit redun- dante Informationen gespeichert, wie die Feldnummern 102, 106, . . . , 198. Diese k¨onnen daran erkannt werden, dass sie neben einer Identifikationsnummer noch zus¨atzlichen Text mit abspeichern, wie hier in den Feldern 100, 104, . . . , 196. Wei- tere 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. DerEinheitssachtitelwird bei Werken wie ’Faust’ oder dem ’Nibe- lungenlied’ vergeben, damit diese einheitlich erfasst werden. Hingegen werden imParallelsachtitel weitere Sachtitel erfasst unter denen das Werk zus¨atzlich ge- funden werden kann.
Die Informationen ¨uber den Ort und den Namen des Verlegers stehen in den Feldnummern 410 und 412. Unter der Feldnummer 425 sind die unterschiedli- chen Formen des Erscheinungsjahrs zusammengefasst.
In den Feldern 902, 907, . . . , 947 stehen die Verweise und die Ansetzungsfor- men der Schlagw¨orter, 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 Leer- zeichen, dann die eigentliche Identifikationsnummer des Schlagwortes mit der L¨ange von acht Zeichen. Anschließend folgen zw ¨olf Leerzeichen als Trenner zu der redundanten Ansetzungsform.
Dieser Abschnitt sollte nur einige Feldnummern beschreiben, da die vollst¨an- dige Beschreibung des MAB2-Formats zwei ganze B¨ande f ¨ullt und dadurch den
Rahmen dieser Arbeit ¨uberschreiten w ¨urde. Neben der vollst¨andigen Beschrei- bung des MAB2-Formats existieren zus¨atzliche Excel-Dateien, die eine ¨Ubersicht mit kurzer Beschreibung der vom Bibliotheksservice-Zentrum Baden-W ¨urttem- berg (BSZ) unterst ¨utzten 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 MAB2- Standard so gut wie m¨oglich abzubilden, da es keine existierenden Modellierun- gen gab, die dies ad¨aquat l¨osten. Es existiert bereits eine Implementierung von der DDB, die sichMABxmlnennt und unter [14] zu finden ist. Die Konvertierung, die MABxml durchf ¨uhrt, ist allerdings keine Modellierung im XML-Format, son- dern nur eine 1:1- ¨Uberf ¨uhrung des MAB2-Formats in das XML-Format. Es gibt einen Elementknoten mit der Bezeichnungfeldmit zwei Attributen, eins f ¨ur die Feldnummer und eins f ¨ur 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 ¨annlein von Eduart M ¨orike
</ f e l d>
Diese Arbeit will die Bibliotheksdaten m ¨oglichst ad¨aquat in XML modellie- ren. MABxml ¨uberf ¨uhrt 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 Personen- datei (MAB-PND), die K¨orperschaftsdatei (MAB-GKD) und die Schlagwortda- tei (MAB-SWD). Zuerst musste analysiert werden, wie diese vier Dateien mit- aneinander verkn ¨upft sind. Dies geschah indem in den einzelnen Datenfeldern
17
102 202 902
MAB-TITEL
MAB-PND MAB-GKD MAB-SWD Abbildung 3.1: Schematische Grundstruktur
der Dateien nach Verweisen auf die anderen Dateien gesucht wurde. Nachdem diese Verkn ¨upfungspunkte gefunden waren, entstand ein erster Eindruck wie diese Dateien zusammenh¨angen. Erst danach konnte mit der Modellierung be- gonnen 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 ¨origen Iden- tifikationsnummer in Feld 001. Dies gilt selbstverst¨andlich auch f ¨ur die beiden anderen Dateien.
Bei der Modellierung des Datenschemas k¨onnte unterhalb des Tags medien eine weitere Spezifizierung, n¨amlich nach dem Medientyp stattfinden. So k ¨onn- ten alle Medien nochmals unter der Pluralbezeichnung ihres Typs unterschieden werden. Zum Beispiel w ¨urde es einen Knotenbuechergeben, der allebuch-Tags enthielte. Diese Trennung der Medientypen w ¨urde die ganzen Datens¨atze eines bestimmten Medientyps b ¨undeln, was sich sehr effizient auf die Suche nach ei- nem bestimmten Medientyp auswirken w ¨urde. Dieser Ansatz h¨atte allerdings einen schwerwiegenden Nachteil, da die Datens¨atze in der Titeldatei willk ¨urlich angeordnet sind, m ¨ussten sie f ¨ur jeden Medientyp einmal gelesen werden, damit die Ausgabedatei sortiert nach den Medientypen geschrieben werden k ¨onnte. Al- ternativ k¨onnte die Titeldatei einmalig eingelesen werden und f ¨ur jeden Medien- typ w ¨urde eine eigene Ausgabedatei angelegt. All diese Ausgabedateien m ¨ussten dann in die XML-Datei zusammengef ¨ugt und somit nochmals geschrieben wer- den. Dies erh¨oht unn¨otig die Lese- und Schreibzugriffe auf die Festplatte, was sich auf die Ausf ¨uhrungsgeschwindigkeit des gesamten Programms auswirken w ¨urde. Diese L¨osung eignet sich aus den aufgezeigten Gr ¨unden nicht f ¨ur einen effizienten Einsatz.
Daher muss im Zentrum die Titeldatei stehen und die drei anderen Datei- en als separate Datens¨atze gespeichert werden. Dies vermeidet eine redundante Speicherung, da auf diese Datens¨atze per Identifikationsnummer aus der Titel- datei zugegriffen werden kann. Diese Konstellation eignet sich hervorragend f ¨ur den Aufbau eines Datenbankmodells, da die einzelnen MAB2-Dateien getrennt voneinander gespeichert werden k¨onnen. In der praktischen Umsetzung wur- den daher vier Kindknoten an den Wurzelknotenbibliothekangeh¨angt. Diese vier Hauptknoten bzw. Sektionen tragen die Bezeichnungenmedien, personen, koerperschaftenundschlagwoerter. Unter dem Hauptknotenmedienist nat ¨ur- lich die Titeldatei gemeint, die ja alle erfassten Medien in willk ¨urlicher Reihen- folge enth¨alt. 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 node −−>
<!ELEMENT b i b l i o t h e k ( medien ,
personen ,
koerperschaften , schlagwoerter ) >
Nachdem die Zusammenh¨ange gekl¨art sind, geht es nun weiter mit den Ge- meinsamkeiten, die alle vier Dateien verbindet. Jeder Datensatz besitzt eine ein- deutige achtstellige Identifikationsnummer innerhalb einer MAB2-Datei, die in der Feldnummer 001 gespeichert ist. Des weiteren wird in jedem Datensatz ge- speichert, 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¨oht wird, falls eine Korrektur an diesem Datensatz durchgef ¨uhrt wurde.
Die zwei anderen MAB2-Dateien sind die Lokaldatei und die Klassifikations- und Notationsdatei. Diese werden noch nicht von dieser Implementierung un- terst ¨utzt, weshalb ihr Aufbau nicht n¨aher beschrieben wird. In einer zuk ¨unfti- gen Implementierung werden diese beiden Dateien sehr wahrscheinlich enthal- ten sein.
3.1.2 Umsetzung einzelner Datens¨atze in XML
In diesem Abschnitt soll beschrieben werden, wie die einzelnen Datens¨atze in XML umgesetzt werden. Da jeder Datensatz in allen vier MAB2-Dateien eine
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 ¨ur Medium gew¨ahlt, bei den anderen drei ist es jeweils der Anfangsbuchstabe der Datei in Kleinbuchstaben, also ’p’ f ¨ur Perso- nen, ’k’ f ¨ur K¨orperschaften und ein ’s’ f ¨ur Schlagw¨orter. Weiter m ¨ussen bei XML die IDs mit einem Buchstaben, Unterstrich oder einem Doppelpunkt beginnen, deshalb wird am Anfang der Identifikationsnummer k ¨unstlich ein Buchstabe an- geh¨angt.
Dieses Attribut tr¨agt die Bezeichnungidund ist vom TypID, womit die M ¨og- lichkeit besteht viaIDREFauf diesen Knoten zu verweisen, falls erforderlich. F ¨ur jeden Datensatz aus den vier MAB2-Dateien existiert ein Element mit einem sol- chen Attribut. Die Verweise in der Titeldatei zu den enthaltenen K ¨orperschaf- ten, Personen oder Schlagw¨orter werden durch ein leeres Element realisiert, das nur ein Attribut vom TypIDREF besitzt. Wie ein solcher Verweisknoten zu einer K¨orperschaft in der DTD-Spezifikation aussieht, zeigt Listing 3.3. Ein Beispiel f ¨ur 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 EMPTY >
<!ATTLIST l k o e r p e r s c h a f t koerpID IDREF #REQUIRED >
Listing 3.4: Verweis auf K¨orperschaft
<l k o e r p e r s c h a f t korpID=” k12345678 ”
Der Elementknotenlkoerperschaftkann nur aufeineK ¨orperschaft verwei- sen, da das Attribut nicht vom TypIDREFSist. Bei diesem Typ k ¨onnte man meh- rere K¨orperschaften-IDs unter diesen Knoten zusammenfassen, indem die IDs durch Leerzeichen voneinander getrennt werden. Dies wurde aber aus Gr ¨unden der besseren Lesbarkeit nicht umgesetzt.
Im Moment wird auf die Identifikationsnummer eines Mediums noch nicht zugegriffen, aber in einer sp¨ateren Implementierung wird diese f ¨ur die Abspei- cherung der Exemplardaten ben¨otigt. Dazu werden die Exemplare mit Verweis auf einen Mediendatensatz abgespeichert, weil ja die Exemplare verliehen wer- den.
Ein weiterer Grundgedanke bei der Konstruktion des Datenschemas war es, so gut wie m¨oglich zu gruppieren, dadurch k¨onnen zusammengeh¨orige Infor- mationen auch geschlossen unter einem Begriff, realisiert durch einen Vaterkno- ten, zusammengefasst werden. Allerdings ist diese Entwicklung noch nicht ab- geschlossen, da dies ohne das Wissen eines ausgebildeten Bibliothekars nicht ad¨aquat realisiert werden kann. Durch die Komplexit¨at der Daten muss diese Entwicklung sehr gr ¨undlich durchgef ¨uhrt werden, indem es kontinuierlich wei- terentwickelt 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¨atze garantiert.
Die Implementierung dieses Programms wurde inC++gel ¨ost, da es eine ob- jektorientierte Programmiersprache ist und auf vielen Rechnerarchitekturen ver- breitet ist. Ein weiterer wichtiger Punkt war das Vorhandensein einer String- Klasse, die die textuelle Verarbeitung der ganzen Textzeilen vereinfacht.
Der Einsatz einer objektorientierten Sprache erm ¨oglicht die Erstellung des nachfolgenden Klassenmodells. Die Tatsache, dass die MAB2-Dateien den glei- chen Aufbau und gemeinsame Datenfelder besitzen, verdeutlicht das folgende Klassenmodell. Zuallererst musste eine Klasse erzeugt werden, die die Gemein- samkeiten kapselt und gleichzeitig flexibel genug ist, weitere MAB2-Dateien zu unterst ¨utzen. Dies f ¨uhrt zu einer besseren ¨Ubersichtlichkeit des Codes. Zu diesen Gemeinsamkeiten z¨ahlen Datenfelder, die mindestens zwei der MAB2-Dateien gemeinsam haben. Dazu geh¨oren Datenfelder wie z. B. die SWB-spezifischen, die Datensatz- und die L¨andercode-Daten. F ¨ur diese Klasse wurde die Bezeichnung CMAB2Parsergew¨ahlt. Die Eigenheiten der einzelnen MAB2-Dateien wurden je- weils in eine eigene Klasse gepackt, wobei diese als Unterklassen der Klasse CMAB2Parserabgebildet wurden. Jede Unterklasse ist f ¨ur das Parsen ihrer Datei verantwortlich. So parst die KlasseCMAB2TitleParserdie Titeldatei. Die Namen der anderen drei Klassen lauten CMAB2PersonParser, CMAB2CorporationParser undCMAB2BuzzWordParser. Der vollst¨andige Quellcode befindet sich auf der bei- liegenden CD.
Das nachfolgende Klassendiagramm veranschaulicht die wichtigsten Details noch etwas besser. Auf der beigelegten CD befinden sich alle ausf ¨uhrlichen Klas- sendiagramme.
CMAB2Parser
# m strBuffer :CString
+ ParseFile(ofstream* pFile, const string& strFileName) :bool
# hlpParseFieldNumber(CString& rstrLine) :bool
# hlpCloseDataRecord() :void
CMAB2TitleParser
# m mMediumtype :MediumType CMAB2PersonParser
CMAB2CorporationParser CMAB2BuzzWordParser
Abbildung 3.2: Klassendiagramm des Konvertierungsprogramms
Die ¨offentlich zug¨angliche MethodeParseFile, die in der Basisklasse imple- mentiert ist, regelt den Ablauf bei der Abarbeitung der einzelnen MAB2-Dateien.
Zuerst werden nacheinander die einzelnen Datens¨atze eingelesen, indem alle Zeilen in einer doppelt verketteten linearen Liste von Strings gespeichert werden.
Dies geschieht mit Hilfe der MethodehlpReadDataRecord, die als Argumente ei- ne Datei, aus der sie lesen soll, und eine Liste, in die sie die Zeilen speichern soll,
¨ubergeben bekommt. Somit ist in der Liste ein ganzer Datensatz gespeichert, der dann weiterverarbeitet werden kann. Diese Liste enth¨alt immer nur einen Da- tensatz, womit der Speicherverbrauch in einem akzeptablen Rahmen bleibt und nicht von der Gr¨oße der Eingabedatei abh¨angig ist. Weiter ist eine Verarbeitung eines ganzen Datensatzes nachvollziehbarer.
Jede enthaltene Zeile eines eingelesenen Datensatzes wird an die Methode hlpParseFieldNumberweitergegeben. Diese Methode ist in der BasisklasseCMAB2- Parser als abstrakt deklariert, womit jede von ihr abgeleiteten Klasse eine sol- che Methode implementieren muss. Mit dieser Klassenmodellierung k ¨onnen nun auch sehr leicht die noch nicht unterst ¨utzten MAB2-Formate, wie MAB-LOKAL und MAB-NOTAT, hinzugef ¨ugt werden, ohne eine Reimplementierung des Klas- senmodells notwendig zu machen. Beim Hinzuf ¨ugen eines dieser Formate muss
nur eine Unterklasse von CMAB2Parser erzeugt werden, die dann die Methode hlpParseFieldNumberimplementiert.
Dieses Konvertierungsprogramm tr¨agt den Namen mab2toxmlund wird wie folgt aus einem Linux-System aufgerufen:
./mab2toxml -o <Datei> <MAB2-Pr¨afix>
Beim Aufruf dieses Programms m ¨ussen nicht alle MAB2-Dateien einzeln an- gegeben werden, da sich diese bei einem Datenbankabzug nur an der Datei- endung unterscheiden, muss nur einmal der Dateiname, der die Bezeichnung
’MAB2-Pr¨afix’ tr¨agt, angegeben werden. Die bei der Konvertierung erzeugte XML- Datei erh¨alt den NamenDatei.
3.2.2 Funktionsweise
Die MethodehlpParseFieldNumberverarbeitet jede Zeile eines eingelesenen Da- tensatzes, indem sie die Feldnummer und einen m ¨oglichen Indikator auswertet und dann das Datenfeld in einen XML-Tag schreibt. Diese Tags werden mit der HilfsfunktionhlpBuildElementTagaus der DateiTools.ccbewerkstelligt, wobei ihr der Name des Tags, der Inhalt und die Anzahl der Einr ¨uckungen (Tabula- toren) am Anfang der Zeile ¨ubergeben werden. Diese Methode erleichtert den Umgang mit dem Erzeugen der XML-Tags, da sie die Start- und Endtags erzeugt.
Weiter besteht die M¨oglichkeit ihr bis zu zwei Attribute zu ¨ubergeben, da es sich um eine ¨uberladene 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¨ahr- leisten k¨onnte. Die einzelnen Gruppierungen werden tempor¨ar in Variablen ge- speichert, um dann am Ende eines Datensatzes alle Variablen in einer vorgege- benen Reihenfolge in den Pufferm strBufferzu schreiben. Die einzelnen Varia- blen werden danach wieder geleert. All das geschieht in der abstrakten Methode hlpCloseDataRecord, die von den Unterklassen ¨uberschrieben werden muss. Da- mit ist gew¨ahrleistet, 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 ¨urfen, 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 Me- dientypen notwendig bzw. anwendbar. Diese ¨Uberpr ¨ufung 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
m MediumType der Medientyp gespeichert. Um nun Attribute in einem Medien- typ auszuschließen, wird bei jedem Datenfeld auf diesen Medientyp gepr ¨uft. Tritt dieser auf, so gibt die MethodehlpParseFieldNumberfalsch zur ¨uck.
Die MethodeParseFilebricht in einem solchen Fehlerfall die Weiterverarbei- tung des aktuellen Datensatzes ab und f¨ahrt mit dem n¨achsten Datensatz fort.
Damit der Benutzer den fehlerhaften Datensatz korrigieren kann, wird eine ent- sprechende Fehlermeldung auf der Standardausgabe ausgegeben. Diese Fehler- meldung enth¨alt neben der Identifikationsnummer des entsprechenden Daten- satzes auch noch die Angabe in welcher der MAB2-Dateien dieser Fehler auftrat.
Die Fehlerkorrektur kann nicht programmtechnisch durchgef ¨uhrt werden, da es sich bei dem Fehler um einen Eingabefehler (Tippfehler) oder der falschen Zu- weisung eines Mediumtyps handeln kann. Erfolgte diese Pr ¨ufung ohne Fehler, weist dies noch nicht auf einen fehlerfreien Datensatz hin, da es Datens ¨atze geben kann, die bei der Feldnummer 076 aufh¨oren. Diese sind somit nicht g ¨ultig, da die Informationen ¨uber einen Datensatz erst bei Feldnummer 100 beginnen. Darauf wird vor dem Schreiben, in der MethodehlpWriteDataRecord, gepr ¨uft. Verl¨auft diese Pr ¨ufung positiv, ist der vorliegende Datensatz g ¨ultig und kann schließlich in die Ausgabedatei geschrieben werden. Die Variablem strBuffer, die zu die- sem Zeitpunkt den kompletten Datensatz im XML-Format enth¨alt, wird in die Datei geschrieben und dann anschließend geleert. Schl¨agt diese ¨Uberpr ¨ufung 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¨onnen W¨orter auftauchen, wie z. B. der, die, das, und, etc.
Diese W¨orter tragen nichts zum Titel bei, womit sie nicht beachtet werden sol- len. Dazu werden diese W¨orter im MAB2-Format in Nichtsortierzeichen (¬) ge- setzt und beim Sortieren somit ausgeschlossen. Meist sind dies Stoppw ¨orter, die entfernt werden k¨onnen, da sie sehr h¨aufig vorkommen oder keine Relevanz auf- weisen. In einer Stoppwortliste werden diese Stoppw ¨orter meist alphabetisch an- gegeben.
Diese Stoppw¨orter tauchen nicht nur im Titelfeld auf, sondern auch bei Per- sonennamen, wie z. B. ’Otto von Essen’, somit war dies Motivation genug, diese W¨orter innerhalb des Konvertierungsprogramms herauszufiltern. Da der gesam- te Feldinhalt vorhanden bleiben muss, wird ein weiterer XML-Tag angelegt. Die- ser Tag beginnt mit Tagnamen des zu reinigenden Feldes und erh¨alt weiter den
Suffix normiert’ angeh¨angt. So w ¨urde z. B. aus dem Taggesamttitelnach Ent- fernen von Stoppw¨orterngesamttitel normiertwerden.
Auf den ersten Blick erscheint diese Abspeicherung redundant zu sein, al- lerdings spart sie kostbare Rechenzeit, da sie im Konvertierungsprogramm nur einmal durchlaufen werden muss. Eine Suchanfrage in diesen Feldern k ¨onnte die Bearbeitungszeit beschleunigen, da nur die relevanten W ¨orter in diesem Tag enthalten sind. W ¨urden diese Tags nicht redundant gespeichert, m ¨usste bei jeder Suche die Stoppwortentfernung bei jedem Tag durchgef ¨uhrt werden. Bei einer Suchanfrage muss die Stoppwortentfernung immer durchgef ¨uhrt werden, aber diese ist nicht allzu lang und kostet nicht viel Rechenzeit.
Die Stoppwortentfernung ist in der MethodehlpRemoveStopWordsder Basis- klasse implementiert. Damit diese Methode funktionieren kann, m ¨ussen zuerst einmal Stoppw¨orter bekannt sein. Diese werden aus einer Datei gelesen, deren Dateiname dem Konstruktor der Unterklassen ¨ubergeben werden kann. Das Ein- lesen der Stoppwortliste erfolgt in der MethodehlpCreateStopWordList, wobei dieser einen Dateinamen als Parameter ¨ubergeben wird. Diese Datei enth¨alt in jeder Zeile ein Stoppwort. Es ist sogar m ¨oglich, f ¨ur jede der vier MAB2-Dateien eine eigene Stoppwortliste zu verwenden.
Diese Liste wird in dem STL-Container Setgespeichert 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 Stopp- wort vorkommt, sondern nur dass es enthalten ist. Allerdings ist es sehr unwahr- scheinlich, dass ein Stoppwort mehrmals in einer solchen Liste vorkommt, trotz- dem ist es besser diesen Container als zus¨atzlichen Schutz zu benutzen. Da bei einem String-Vergleich zwischen Groß-und Kleinschreibung unterschieden wird, werden die eingelesenen Stoppw¨orter komplett in Großbuchstaben gespeichert.
Die Felder, auf die diese Stoppwortentfernung angewendet wird, werden eben- falls zum Vergleich in Großbuchstaben umgewandelt.
Beim Aufruf der MethodehlpRemoveStopWordswird als Argument ein String
¨ubergeben, aus dem dann die Stoppw¨orter entfernt werden sollen. Der R ¨uckga- bewert ist der bereinigte String, der nun keine Stoppw ¨orter mehr enth¨alt, falls dies vorher der Fall war. Enthielt der ¨ubergebene String keine Stoppw¨orter, so sind beide Strings identisch.
Diese Methode kann ¨uberall dort im Konvertierungsprogramm benutzt wer- den, an denen Stoppw¨orter entfernt werden m ¨ussen. Beim jetzigen Stand der Im- plementierung werden nur die Felder Gesamttitel und Personennamen auf diese Art bereinigt. Allerdings ist f ¨ur die Zukunft der Einsatz bei weiteren Feldern ge- plant.
3.3 Einf ¨ugen von Aktualisierungen
Nach erfolgreicher Konvertierung der vier beschriebenen MAB2-Dateien kann der Datenbestand aktualisiert werden. Dazu k ¨onnen nicht immer die kompletten Daten umkonvertiert werden, sondern es muss eine M ¨oglichkeit geben, Aktua- lisierungen bzw.Updateseinzuspielen. Um diesen Aktualisierungsprozess abzu- sichern, wurde auch ber ¨ucksichtigt, dass bei den Aktualisierungen nicht immer nur neuere Datens¨atze enthalten sind. Somit m ¨ussen zus¨atzlich noch weitere Ver- gleiche vorgenommen werden. Hierf ¨ur wurde ein weiteres Programm ben¨otigt, dass die BezeichnungbibUpdatererhielt.
3.3.1 Allgemeiner Aufbau
Die t¨aglichen Aktualisierungen sollten so schnell wie m ¨oglich eingespielt wer- den, da bei diesem Vorgang die gesamten Daten mindestens einmal eingelesen werden m ¨ussen. Somit war die Zielsetzung des zu konstruierenden Algorith- mus die Minimierung sowohl der Ressourcen als auch der Festplattenzugriffe.
Dar ¨uberhinaus sollte der Programmieraufwand und dadurch resultierende Feh- lersuche ebenfalls so gering wie m¨oglich sein. Daf ¨ur eignet sich der Einsatz ei- ner bereits existierenden Datenbank sehr gut. In dieser Datenbank werden die Datens¨atze 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¨anden ebenfalls erleichtert. Aber dazu mussten zuerst noch einige Details zur Umsetzung gekl¨art 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 beantwor- tet, so muss als n¨achstes das Datenformat festgelegt werden, in dem sie gespei- chert werden. In diesem Falle entweder im MAB2-Format oder schon im XML- Format. In den nachfolgenden Abschnitten sollen die Antworten zu diesen Fra- gen gegeben werden.
Wird von einem Datensatz nur die Identifikationsnummer gespeichert, ist dies sehr ressourcensparend, allerdings ist dann der Einsatz der Datenbank nutz- los, da ein Zugriff auf den Datensatz zur Folge hat, dass dieser erneut aus der Datei gelesen werden muss. Wird hingegen der Datensatz komplett im Haupt- speicher gehalten, f ¨uhrt dies zu einem h¨oheren Ressourcenverbrauch. Der Zugriff
auf die Datens¨atze wird jedoch wesentlich erleichtert und bei der heutigen Spei- cherausstattung von mehr als 512 MB Arbeitsspeicher sollte dies nicht so schwer- wiegend 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 ¨otig verschwendet. Die Datenbank- BibliothekBerkeleyDB[1] von der FirmaSleepycat Softwareeignet sich daf ¨ur sehr gut. Sie bietet eine Vielzahl an Programmiersprachenanbindungen an, u. a. auch f ¨ur C++. Diese Bibliothek liegt in zwei Lizenzvarianten vor, einer Open-Source- Lizenz bei einem Einsatz in Open-Source-Projekten und einer kostenpflichtigen Variante. Weiter unterst ¨utzt sie keine aufwendigen Anfragen, weshalb sie schnell und wenig speicherhungrig ist.
Diese Datenbank greift ¨uber ein so genanntes Schl¨ussel-Daten-Paarauf die in ihr gespeicherten Datens¨atze zu. Der Schl ¨ussel gibt an, unter welcher Bezeich- nung ein bestimmter Datensatz gespeichert wird und auch wiedergefunden wer- den kann. Die eigentlichen Informationen ¨uber den Datensatz befinden sich im Datenfeld. Die Informationen werden unter einer anderen k ¨urzeren Bezeichnung abgelegt. Dies gleicht dem Konzept des STL-ContainersMap(engl. Abbildung), allerdings bietet dieser keine Optimierungen an, die BerkeleyDB mitbringt. F ¨ur die Implementierung ist diese Abbildung sehr n ¨utzlich, da ein kompletter Daten- satz ¨uber 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¨atze in der BerkeleyDB-Datenbank abgespeichert werden sollen. Das Speichern im MAB2- Format reduziert den Speicherplatz, jedoch erfordert es eine Konvertierung ei- nes aktuelleren Datensatz aus der Datenbank in XML. Dies f ¨uhrt jedoch zwei Nachteile mit sich: erstens w ¨urde es keine klare Trennung zwischen den beiden Programmen geben, da das Aktualisierungsprogramm das Konvertierungspro- gramm enthalten w ¨urde. Die beiden Programme l¨osen unterschiedliche Aufga- ben, deshalb sind sie besser getrennt zu behandeln, damit kein großes monoli- thisches Programm entsteht. Zweitens dient diese Aufgabentrennung der ¨Uber- sichtlichkeit. Ohne diese Trennung w ¨urde dies zu einem gr¨oßeren Wartungsauf- wand und zu Verst¨andnisschwierigkeiten der nachfolgenden Entwickler f ¨uhren, da der Quellcode nicht mehr sauber voneinander getrennt werden kann. Diese L¨osung kam deshalb nicht in Betracht.
3.3.2 Umsetzung in C++
Bei der Durchf ¨uhrung einer Aktualisierung muss daher zuerst das Update in XML konvertiert werden. Nach diesem Schritt entsteht ein g ¨ultiges und wohl- geformtes XML-Dokument, das keine fehlerhaften Datens¨atze mehr enth¨alt. Die Hauptaufgabe ist nicht die Erkennung von Fehlern, welche ja schon beim Kon- vertierungsprozess ausgeschlossen wurden, sondern das korrekte Zusammenf ¨u- 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¨alt.Datei1stellt somit die gr¨oßere der beiden Dateien dar. Da f ¨ur jeden Datensatz in der Aktualisierungsdatei ein Ein- trag in die BerkeleyDB-Datenbank erstellt wird, w ¨urde dies den Speicherver- brauch zus¨atzlich erh¨ohen. 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 wer- den. Hierzu wurde wieder eine eigene Klasse geschrieben, die diesen ganzen Aktualisierungsvorgang kapselt. In einer zweiten Datei namens main.cc wer- den vorher noch die m¨oglichen Kommandoparameter ausgewertet, um dann schließlich diese Klasse auszuf ¨uhren. Dies geschieht mit der ¨offentlichen Me- thodeUpdateDatabase, der die drei Dateinamen der Kommandozeile ¨ubergeben werden.
Als erstes wird der Kopf in die neue XML-Datei geschrieben, damit die ver- wendete XML-Version und Zeichensatz korrekt angegeben sind. Danach werden nacheinander alle Datens¨atze der einzelnen vier Sektionen der Update-Datei in die BerkeleyDB-Datenbank eingelesen, dies geschieht in der MethodehlpFill- Database. Es befinden sich also nur die Datens¨atze 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 zwischen- gespeichert, das Gleiche geschieht mit der Identifikationsnummer. Als n¨achstes wird in der Datenbank gepr ¨uft, ob ein Datensatz mit dieser Identifikationsnum- mer existiert, falls nicht, wird dieser Datensatz in die Ausgabedatei geschrieben
und der n¨achste Datensatz wird eingelesen.
Gibt es jedoch einen Treffer in der Datenbank, so wird dieser ebenfalls in ei- ner Variablen gespeichert und aus der Datenbank entfernt, danach werden die m¨oglich vorhandenen Korrekturdaten ¨uberpr ¨uft. Falls einer der beiden kein Kor- rekturdatum besitzt, wird der Datensatz in die Ausgabedatei geschrieben, der das Korrekturdatum aufweist. Besitzen beide ein Korrekturdatum werden selbst- verst¨andlich beide Daten miteinander verglichen, um das neuere Datum zu fin- den.
Falls diese ¨Uberpr ¨ufung auch noch nicht eindeutig ist, werden schließlich noch die Versionsnummern, die sich im Feld 076v befindet, miteinander vergli- chen. Eine h¨ohere Nummer identifiziert den aktuelleren Datensatz.
Ist schließlich das Ende einer Sektion erreicht und es befinden sich noch Da- tens¨atze in der Datenbank, dann handelt es sich bei diesen um neue Eintr¨age, die alle in die Ausgabedatei geschrieben werden m ¨ussen. Danach ist die Datenbank leer und auch der Endtag der Sektion kann in die Ausgabedatei geschrieben wer- den. Der gesamte Vorgang wiederholt sich f ¨ur alle weiteren drei Sektionen, damit enth¨alt die Ausgabedatei am Ende alle Neuerungen. Die Datei ist wohlgeformt und g ¨ultig, da die beiden anderen Daten dies ebenfalls waren.
Der Datensatz aus Listing 2.5 sieht nach der Konvertierung in das XML-For- mat wie in Listing 3.5 angegeben aus.
Listing 3.5: Datensatz nach Konvertierung
< buch id = " m 0 0 0 3 6 2 1 0 " >
< d a t e n s a t z >
< e r s t e r f a s s u n g >
< datum > 19850101 </ datum >
< k e n n z e i c h e n > KNUB </ k e n n z e i c h e n >
</ e r s t e r f a s s u n g >
< t r a n s a k t i o n s d a t u m > 20040826 </ t r a n s a k t i o n s d a t u m >
< k o r r e k t u r >
< datum > 20020823 </ datum >
< k e n n z e i c h e n > ZRED </ k e n n z e i c h e n >
</ k o r r e k t u r >
</ d a t e n s a t z >
< swb >
< k o r r e k t u r d a t u m > 102235 </ k o r r e k t u r d a t u m >
< v e r s i o n s n u m m e r >3 </ v e r s i o n s n u m m e r >
</ swb >
< v e r f a s s e r persID = " p 0 0 1 3 8 0 7 3 " / >
< verlag >
< ort > W i e s b a d e n </ ort >
< name > Pressler </ name >
</ verlag >
< e r s c h e i n u n g s j a h r >
< v o r l a g e f o r m > 1965 </ v o r l a g e f o r m >
< a n s e t z u n g s f o r m > 1965 </ a n s e t z u n g s f o r m >
</ e r s c h e i n u n g s j a h r >
< s p r a c h e n c o d e >
< sc_swb > dt . </ sc_swb >
</ s p r a c h e n c o d e >
< titel >
< h a u p t s a c h t i t e l >
< v o r l a g e f o r m > Deutsche B u c h d r u c k e r s i g n e t e des XVI . J a h r h u n d e r t s </ v o r l a g e f o r m >
< normiert > Deutsche B u c h d r u c k e r s i g n e t e XVI . J a h r h u n d e r t s </ normiert >
< zusaetze > Geschichte , S i n n g e h a l t und G e s t a l t u n g kleiner K u l t u r d o k u m e n t e </ zusaetze >
</ h a u p t s a c h t i t e l >
</ titel >
< b e s c h r e i b u n g >
< a l l g e m e i n > Heinrich Grimm </ a l l g e m e i n >
< k o l l a t i o n s v e r m e r k > 365 S . </ k o l l a t i o n s v e r m e r k >
< r e d a k t i o n s b e m e r k u n g > SW 580 klub / ssc ; NR / L1UB ; 720 ff . bvb </ r e d a k t i o n s b e m e r k u n g >
</ b e s c h r e i b u n g >
< b i b _ v e r b _ b a y e r n > 8 0 0 9 2 0 2 2 6 9 </ b i b _ v e r b _ b a y e r n >
< k l a s s i f i k a t i o n >
< r e g e n s b u r g e r _ v e r b u n d k l a s s > 00295249 </
r e g e n s b u r g e r _ v e r b u n d k l a s s >
< r e g e n s b u r g e r _ v e r b u n d k l a s s > 00110453 </
r e g e n s b u r g e r _ v e r b u n d k l a s s >
</ k l a s s i f i k a t i o n >
< s t i c h w o e r t e r > s e c h z e h n t e n </ s t i c h w o e r t e r >
< l s c h l a g w o r t slgID = " s 0 0 0 0 6 2 1 3 " typ = " g e o g r a p h i s c h " / >
< l s c h l a g w o r t slgID = " s 0 0 0 9 7 6 5 7 " typ = " sach " / >
< l s c h l a g w o r t slgID = " s 0 0 2 2 4 2 2 0 " typ = " zeit " / >
< h e r k u n f t s a n g a b e > SWB </ h e r k u n f t s a n g a b e >
< l s c h l a g w o r t slgID = " s 0 0 0 0 6 2 1 3 " typ = " g e o g r a p h i s c h " / >
< l s c h l a g w o r t slgID = " s 0 0 1 3 0 8 5 1 " typ = " sach " / >
< l s c h l a g w o r t slgID = " s 0 0 2 2 4 2 2 0 " typ = " zeit " / >
< h e r k u n f t s a n g a b e > SWB </ h e r k u n f t s a n g a b e >
</ buch >
Kapitel 4
Leistungsmessung
Im vorherigen Kapitel wurden die Implementierungen beschrieben, wie aus ei- ner MAB2-Datei eine XML-Datei generiert wird und m ¨ogliche Aktualisierun- gen nachtr¨aglich eingebunden werden. Dieses Kapitel soll nun die Geschwin- digkeit der entstandenen Programme untersuchen. In einem zweiten Schritt soll die gesamte Datenbank noch anhand typischer Suchanfragen getestet werden, um einen Vergleich zur anf¨anglich benutzten Textdatei des MedioVis-Projekts zu erm¨oglichen. Allerdings gilt es zu beachten, dass kein direkter Vergleich m ¨oglich ist, da nicht die gleichen Datenbest¨ande vorhanden sind und der Datenbestand bei dieser Arbeit wesentlich gr¨oßer ist als bei MedioVis. Die Analyse solcher Suchanfragen bietet eine realistische Bewertung bzw. Einsch¨atzung des erstellten XML-Datenschemas, da nun eventuelle Modellierungsfehler sich in der Laufzeit der gestellten Suchanfragen bemerkbar machen. Diese Erkenntnisse k ¨onnten zu einigen Nachbesserungen im Datenschema oder im Extremfall zu einer Neumo- dellierung f ¨uhren.
4.1 Das eingesetzte Datenbanksystem
Als zugrunde liegendes XQuery-System wird das ProjektPathfinder [4] benutzt, das am Fachbereich f ¨ur Datenbanken und Informationssysteme an der Univer- sit¨at Konstanz entwickelt wird. Pathfinder ist die Schnittstelle, an die die Suchan- fragen f ¨ur das Bibliotheksszenario gestellt werden. Dabei handelt es sich um das Frontend zum Datenbank-BackendMonetDB[3], welches vom CWI, dem ’Institu- te for Mathematics and Computer Science Research of The Netherlands’ in Ams- terdam seit 1993 entwickelt wird. Diese beiden Programme sind Open-Source.
Bei MonetDB handelt es sich ein Datenbanksystem, welches sich sehr gut f ¨ur komplexe Anfragen an große Datenbanken eignet. Beide Programme kombiniert
33
MAB-Datei #Datens. MAB2 (MB) XML (MB) Faktor ØDatens.
Titel 8.089 5,48 13,23 2,41 1.715
Person 5.236 1,00 3,03 3,03 607
K¨orperschaft 1.818 0,80 1,72 2,15 994
Schlagwort 6.167 1,83 5,17 2,83 880
Gesamt 21.310 9,11 23,16 2,54 1.140
Tabelle 4.1: Datens¨atze der kleineren Testdatei
MAB-Datei #Datens. MAB2 (MB) XML (MB) Faktor ØDatens.
Titel 40.260 27,10 65,98 2,43 1.719
Person 31.870 5,37 16,21 3,02 533
K¨orperschaft 4.511 1,77 3,93 2,22 914
Schlagwort 20.151 5,67 16,23 2,86 845
Gesamt 96.793 39,91 102,36 2,56 1.109
Tabelle 4.2: Datens¨atze der gr¨oßeren Testdatei
ergeben ein XML-Datenbanksystem, welches beim MedioVis-Projekt als zuk ¨unf- tige 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-Bit- Unterst ¨utzung durchgef ¨uhrt. MonetDB und Pathfinder sind ebenfalls mit reiner 64-Bit-Unterst ¨utzung 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 XML- Dateien mit den beiden Programmen mab2toxml und bibUpdater. Bei dieser Mes- sung standen zwei Abz ¨uge aus der Bibliotheksdatenbank unterschiedlicher Gr ¨o- ße zur Verf ¨ugung. Die Tabellen 4.1 und 4.2 geben einen detaillierten ¨Uberblick
¨uber die einzelnen Datens¨atze innerhalb der beiden MAB2-Abz ¨ugen kleinund groß.
Dabei gibt die zweite Spalte die Anzahl der einzelnen Datens¨atze an, die er- folgreich konvertiert werden konnten. Die dritte und vierte Spalte weisen die Da- teigr¨oßen der Formate aus. Die Spalte Faktor gibt an, um wie viel die XML-Datei gr¨oßer ist als die MAB2-Datei. In der letzten Spalte wird die durchschnittliche Gr¨oße eines XML-Datensatzes angegeben, um sp¨ater besser die Dateigr¨oße f ¨ur die gesamten Bibliotheksdaten absch¨atzen zu k¨onnen. Diese Gr¨oße ergibt sich, in- dem die Dateigr¨oße der XML-Datei durch die Anzahl der enthaltenen Datens¨atze
