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 Methode hlpFill-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 >

< verlag >

< ort > W i e s b a d e n </ ort >

< name > Pressler </ name >

</ verlag >

< 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 geei-neriert 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.