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¨orperschaftsPersonen-datei (MAB-GKD) und die Schlagwortda-tei (MAB-SWD). Zuerst musste analysiert werden, wie diese vier DaSchlagwortda-teien mit-aneinander verkn ¨upft sind. Dies geschah indem in den einzelnen Datenfeldern
17
102
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 DatDatei-ens¨atze gespeichert werdDatei-en. 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 wur-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 ¨ur¨ur-licher 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 −−>
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.