Wie in der Einleitung erwähnt, bedeutet die Verwendung proprietärer
Datenbanksysteme zur Speicherung von Korpora nicht nur Optimierung auf den
Einsatzzweck und damit bessere Performance, sondern auch Portabilitäts- und
Skalierungsprobleme, die die ursprünglich intendierte Optimierung leicht
zu einem Bumerang werden lassen. Diese Überlegungen führten 1999 im Rahmen
einer Magisterarbeit zur Entwicklung der Korpusdatenbank SanRemo,
die in [Künneth1999] ausführlich
beschrieben ist.
Sie basiert in der Referenzimplementierung auf dem Datenbanksystem
DB2 von IBM, ist aber durch die Verwendung von SQL zur
Kommunikation mit dem RDBMS grundsätzlich unabhängig davon. Die für die
Speicherung von Korpora erforderlichen Werkzeuge sind in der auf vielen
Systemen verfügbaren Skriptsprache PERL geschrieben, womit dem
Einsatz auf unterschiedlichsten Computern vom Homecomputer bis zum
Großrechner nichts im Wege steht. Durch die Verwendung kommerzieller oder
frei verfügbarer Datenbanksysteme kann die Behandlung systemspezifischer
Einschränkungen dem Hersteller des Datenbankkerns überlassen werden, und
Tests, Portierungen und Weiterentwicklungen werden so i.A. von einer viel
gößeren Zahl von Programmierern erledigt als dies bei einem allein
korpuslinguistisch genutzen, also auf eine relativ kleine Benutzergruppe
beschränkten, Datenbanksystem der Fall wäre.
Grundlage einer effizienten Speicherung von Korpora in relationalen
Datenbanken ist eine geeignete Tabellenstruktur, die
- Korpora (speicher-)effizient aufnehmen kann
- keine Beschränkungen im Bezug auf Suchanfragen auferlegt
- eine vernünftige Sucherperformance trotz des nicht auf Textspeicherung
optimierten Datenbakkerns erzielt
Die wichtigste Optimierung bezüglich Speicherplatz ist die Unterscheidung
und getrennte Speicherung von Types und Tokens. Jeder Type wird in der
Datenbank genau einmal gespeichert und bekommt in der entsprechenden
Tabelle eine eindeutige Nummer. Der eigentlich Text des Korpus, die
laufenden Wortformen oder Tokens, wird als Folge von Integerzahlen
gespeichert, die auf Types verweisen. So läßt sich zum einen vermeiden,
lange Wortformen bei jedem Vorkommen komplett speichern zu müssen, zum
anderen reduziert sich die Suche nach einer bestimmten Wortform auf eine
Serie von Integer-Vergleichen, was übliche Datenbankkerne wesentlich
zügiger durchführen können als String-Vergleiche.
Sämtliche in der Datenbank gespeicherten Korpora sind über die Tabelle
SanRemo.toc ansprechbar. Um zu große Token-Tabellen zu vermeiden,
was die suche unnötig verlangsamen und die Speicherung textbezogener
Informationen eerschweren würde, wird jeder Einzeltext eines Korpus in
einer eigenen Token-Tabelle gespeichert. Die Namen dieser Tabellen sowie
die Dateinamen der Originaltexte stehen in der textinfo-Tabelle;
d.h. über diese Tabelle sind alle Einzeltexte ansprechbar.
Zur Optimierung der Suche enthält jeder Eintrag in der Tabelle
types nicht nur laufende Nummer und Wortform, sondern auch einen
Zähler für die Anzahl der Vorkommen dieses Types im gesamten Korpus sowie
eine Bitmap, die das Korpus in Bereiche aufteilt und ein gesetztes Bit für
jeden Bereich mit mindestens einem Vorkommen des Types enthält.
Das untenstehende Bild zeigt noch einmal vereinfacht die Tabellenstruktur
als Ganzes, nicht dargestellt ist die in der aktuellen Implementation
vorhandene aber noch ungenutzte Tabelle info, die hierarchische
Informationen zu Texten (wie z.B. Genres) aufnehmen kann sowie das
Bitmap-Feld der Tabelle types.
Zurück zum Index
Letze Änderung: 20-Mar-2003, 21:27