| Startseite | Projekt | Datenbank | Auswertung | Kontakt | Links |
| Zur Einführung | Auswertung der Ergebnisse | Auswertung des Datenbankprogramms | Weitere Untersuchungen |
Die hier in Teilen erschlossene Datenbank wurde ursprünglich mit dem Microsoft-Programm Access 97 konzipiert. Dieses Programm ermöglicht den Aufbau einer relationalen Datenbank, ohne bereits Vorgaben dafür zu machen; der Nutzer kann also die Datenbank individuell auf seine Bedürfnisse hin einrichten. Das hat erhebliche Vorteile, aber auch eine Reihe von Nachteilen. Der folgende Text ist keine allumfassende Beschreibung des Funktionsumfangs von Access 97, sondern soll eine kurze Einführung in das Programm und seine Funktionsweise mit einem Erfahrungsbericht verknüpfen, der auf der Arbeit im anglistischen Unterprojekt des SFB 529 basiert. Viele der Feststellungen lassen sich vermutlich in ähnlicher Weise für die beiden Konkurrenzprodukte, das Lotus- und das StarOffice-Paket, treffen; die Verwendung von Access beruhte in erster Linie darauf, daß das Microsoft Office-Paket im Gegensatz zu seinen Konkurrenten bereits vorhanden war.
Eine relationale Datenbank speichert die Datensätze in Tabellen, die thematisch gegliedert und miteinander in Beziehung gesetzt sind. Access 97 enthält zwar eine Reihe von Vorlagen, bereits vorstrukturierten Datenbankmodellen, ermöglicht aber auch das Erstellen einer völlig neuen Datenbank mit selbst definierten Tabellen. Dabei kann zwischen einer selbständigen und einer durch einen Assistenten angeleiteten Einrichtung gewählt werden; es besteht auch die Möglichkeit, Tabellen zu importieren. Zur Verknüpfung der Tabellen ist jeweils die Vergabe eines Primärschlüssels notwendig, über den die Datensätze für das Programm eindeutig identifizierbar - und damit auch auf andere Datensätze beziehbar - werden. Für jedes Feld der Tabelle lassen sich eine Reihe von Setzungen vornehmen; diese betreffen beispielsweise die Anzahl der zulässigen Zeichen in einem Feld, das Text aufnehmen soll, die Angabe, ob ein Feld Daten enthalten muß oder ob auch leere Felder möglich sind, oder ob ein Feld lediglich eine ja/nein-Auswahl akzeptiert.
Im vorliegenden Fall - bezogen auf den hier zugänglichen Teil der Datenbank - handelt es sich um vier Kerntabellen:
Jede Quelle, aber auch jede Belegstelle ist über eine Ziffernfolge eindeutig zu identifizieren. Diese Ziffernfolge dient gleichzeitig dazu, die Tabellen miteinander zu verknüpfen. So enthält die Belegstellen-Tabelle unter anderem folgende Felder (Screenshot anzeigen):
| Belegnummer | Identifikationszahl der Belegstelle |
| Überschrift | für etwaige Kapitelüberschriften oder Gedichtstitel |
| Text | für den eigentlichen Textauszug |
| Band, Seite | machen diesen Textauszug innerhalb der Quelle auffindbar |
| Fundortnummer | Identifikationszahl der Quelle dieses Textes |
Diese Fundortnummer ist die Identifikationszahl der Quelle; über dieses Feld ist die Belegstellen-Tabelle an die Fundort-Tabelle mit einer n:1-Beziehung geknüpft - n, potentiell also unendlich viele, Belegstellen stammen aus einer einzigen Quelle. Auf diese Weise wird vermieden, für jeden Textauszug einer bestimmten Quelle die Fundortangaben neu einfügen zu müssen; die Angabe der Fundortnummer fungiert wie ein Link auf die Quelle.
Während eine n:1-Beziehung - wie auch eine 1:1-Beziehung - sehr einfach einzurichten und zu beschreiben ist, liegt die Situation bei der Verknüpfung der Belegstellen- mit der Topoisammlungs-Tabelle etwas anders. Eigentlich müßte hier eine n:m-Beziehung eingerichtet werden: der Topos x ist potentiell in unendlich vielen Belegstellen vertreten, wie auch unendlich viele Topoi an eine Belegstelle y gekoppelt sein können. Access sieht eine solche Verknüpfung jedoch nicht vor. Um diese Zuordnung trotzdem zu erhalten, wurde zwischen die beiden Tabellen eine weitere eingeschoben: die Belegstellen-und-Topoi-Tabelle.
Jede Belegstelle ist eindeutig über ihre Belegnummer zu identifizieren; jeder projektinterne Topos über die ihm zugewiesene Toposkennziffer. Die Datensätze dieser Tabelle enthalten nun jeweils die Belegstellennummer und einen ihr zugewiesenen Topos. Einer Textstelle aus Sir William Temples "Essay on Health and Long Life" beispielsweise wurde die Belegnummer 261 zugewiesen. Sie beinhaltet eine Begründung für die spezifische Ausprägung des englischen Nationalcharakters (Topos 7) wie auch Aussagen über die besonders freiheitlichen politischen und gesellschaftlichen Verhältnisse in England (Topos 20b). In der Tabelle Belegstelle-und-Topoi finden sich mithin zwei Datensätze (Tupel):
| Topos | Belegnummer |
|---|---|
| 7 | 261 |
| 20b | 261 |
Über die Belegnummer ist diese Mittler-Tabelle mit der Belegstellen-Tabelle verbunden; es handelt sich um eine n:1-Beziehung: Die in der Belegstellen-Tabelle nur einmal auftretende (1-Seite der Beziehungsdefinition) Textstelle ist mit n-mal derselben Belegnummer in der Belegstelle-und-Topoi-Tabelle verbunden. Da diese n Datensätze der Identifikationsziffer - und damit der Textstelle - jeweils einen Topos zuordnen, bedeutet diese Verknüpfung also, daß jede Belegstelle unendlich viele interne Topoi enthalten können.
Die andere Seite der Mittler-Tabelle ist mit derjenigen Zusammenstellung verbunden, die die internen Topoi mit einer Beschreibung versieht. Auch hier handelt es sich um eine n:1-Beziehung: Unendlich (n) viele Toposnennungen in der Belegstelle-und-Topoi-Tabelle sind mit nur einem einzigen und damit eindeutig definierten Datensatz in der Topoisammlungs-Tabelle verbunden. So wird gewährleistet, daß jeder einzelne Topos unendlich häufig an Belegstellen geknüpft sein kann.
Die Notwendigkeit einer solchen Tabelle ergibt sich aus dem Konzept einer relationalen Datenbank: Beziehungen von unendlich vielen Datensätzen zu unendlich vielen anderen sind für ein Programm wie Access 97 nicht analysierbar, nicht einmal nachzuvollziehen. Daher muß eine solche Beziehung in mehrere Teilaspekte aufgeschlüsselt werden. Für den Nutzer bedeutet das meist in der Dateneingabe einen Schritt mehr und ist insofern etwas ärgerlich; wichtiger ist jedoch, daß solche Tabellen bereits beim Entwurf der Datenbank berücksichtigt werden müssen, weil sie nur schlecht im nachhinein eingebaut werden können.
Die direkte Eingabe von Daten in Tabellen ist unter Access 97 zwar möglich, bietet sich aber besonders bei Tabellen mit vielen Feldern nicht gerade an. Einfacher, besonders für computertechnisch weniger versierte Nutzer - wie auch für den gleichzeitigen Zugriff mehrerer Bearbeiter auf dieselbe Datenbank - ist die Erstellung von graphischen Oberflächen, die eine Maske für die Dateneingabe und -ansicht darstellen. Bei Access 97 werden diese Oberflächen als 'Formulare' bezeichnet. Wie bereits bei der Definition von Tabellen stellt Access 97 einen Assistenten bereit, der einzelne Aspekte abfragt, ansonsten aber einen Großteil der Formatierung automatisch erledigt. Der Entwurf läßt sich allerdings im nachhinein ohne Schwierigkeiten verändern. Parallel dazu gibt es jedoch auch hier die Möglichkeit, Formulare selbst zu erstellen.
Die Grundlage für ein Formular ist entweder die Tabelle selbst oder eine Abfrage, die Daten aus mehreren Tabellen zusammenstellt. Die jeweiligen Felder lassen sich im drag and drop-Verfahren direkt auf die Formularoberfläche ziehen. Sowohl die äußere Gestaltung als auch die Dateneingabe beziehungsweise -wiedergabe lassen sich beeinflussen: Von farblichen Veränderungen über variable Schriftarten bis hin zum Blockieren von Feldern, so daß nur das Lesen, nicht aber die Eingabe von Daten erfolgen kann, ist alles möglich. Zudem können weitere Schaltflächen eingefügt werden, die Makros ausführen - Access stellt eine Reihe von häufig wiederkehrenden Makros zur Verfügung, mit denen sich unter anderem Formulare öffnen oder schließen lassen, Daten an den Drucker oder an eine andere Office-Komponente geschickt werden können. Auch die Einbettung anderer Formulare ist möglich. Wird Access 97 in der Version für Datenbankentwickler verwendet, können sogar eigene shortcuts und Hilfefunktionen eingerichtet werden.
Für die vorliegende Datenbank wurden insgesamt vier Formulare erstellt und miteinander verbunden; die Daten stammen dabei jeweils aus den dazugehörigen Tabellen:
Screenshot des Fundort-Formulars
Über eine 'Taste' ("die dazugehörigen Belegstellen anzeigen") ist es möglich, aus dem Fundort-Formular heraus alle Belegstellen zu einer bestimmten Quelle angezeigt zu bekommen - Access öffnet dazu das Belegstellen-Formular und sortiert die einzelnen Belege wie auf Karteikarten hintereinander. Ebenso lassen sich jedoch die Fundort-Angaben zu einer spezifischen Textstelle anzeigen, indem über eine Schaltfläche im Belegstellen-Formular das Fundort-Formular mit den Daten der betreffenden Ortnummer aufgerufen wird (Screenshot anzeigen).
Schwierigkeiten bereitet allerdings die Anbindung des Belegstellen-und-Topoi-Formulars. Besteht eine fest definierte Beziehung zwischen Tabellen, werden die Daten erst dann in einem Formular angezeigt, wenn alle Angaben in allen damit in Verbindung stehenden Tabellen vorhanden und gespeichert sind. Erst nach dem Abspeichern der Toposeingaben zeigt das Belegstellen-Formular den vollständigen Datensatz an oder arbeitet auch nur damit; sollen beispielsweise mehrere an die Belegnummer gekoppelte Daten gespeichert werden, muß diese erst in der Datenbank 'verstaut' werden, bevor das Programm weitere damit verbundene Eingaben akzeptiert. Besonders bei Formularen, die mehrere Unterformulare enthalten, bietet sich daher eine Schaltfläche an, die die Aktualisierung von Datensätzen ermöglicht. Eine Alternative besteht in einem entsprechenden Makro.
Dieses Problem hängt damit zusammen, daß ein Formular Datensätze nur dann vollständig anzeigt, wenn alle notwendigen - das heißt auch: alle damit verknüpften - Angaben abrufbar sind. Fehlen solche Angaben, sind die bereits eingegebenen Daten zwar in den Tabellen abgespeichert und auch zu finden, nicht aber durch die Formulare. Das kann zu Datensatzduplikaten führen. Access weist nicht immer ausdrücklich auf solche Schwierigkeiten hin; bereits im Entwurf von Formularen sollten sie daher eingerechnet und umgangen werden.
Die Aufsplitterung von Daten in verschiedene Tabellen hat zur Folge, daß meist Daten aus mehreren Tabellen zusammengestellt werden müssen, um eine bestimmte Frage zu beantworten. In der vorliegenden Datenbank muß für eine vollständige Anzeige der bereits angesprochenen Stelle aus Temples "Essay on Health and Long Life" sowohl die Belegstellen- als auch die Fundort-Tabelle benutzt werden. Für solche und ähnliche Fälle stellt Access die Möglichkeit bereit, Abfragen zu erstellen - oder mit Hilfe eines Assistenten erstellen zu lassen.
Das Abfrage-Fenster ist horizontal zweigeteilt (Screenshot anzeigen). Die obere Seite weist die ausgewählten Tabellen mit ihren Beziehungen aus, die untere hat die Form einer weiteren, leeren Tabelle, deren Felder aus den Feldlisten der ausgewählten Tabelle zusammengestellt werden können. Außerdem läßt sich hier einstellen, ob die Datensätze bereits nach bestimmten Aspekten sortiert werden sollen, oder ob das Programm von vornherein nur definierte Datensätze suchen soll.
Im Fall der vorliegenden Datenbank wurde beispielsweise eine Reihe von Abfragen erstellt, die die Suche nach frei wählbaren Stichwörtern im Text ermöglichen. Dafür ist eine Parameterabfrage notwendig, die, wenn sie gestartet wird, die Eingabe der relevanten Parameter in einem Popup-Fenster anfordert. Die Formulierung des Entwurfs solcher Parameterabfragen ist in einfachen Fällen nicht schwierig; Access erlaubt Eingaben wie (Datensatz soll sein) "Wie [x]", "Wie [x] Oder Wie [y]", "Wie [x] Und Wie [y]". Zu beachten ist dabei allerdings, daß das Programm nach Datensätzen sucht; eine Abfrage nach "Fred" weist zunächst einmal nur den Datensatz aus, der "Fred" beinhaltet. Einen Datensatz wie "Fred sagt" ignoriert das Programm hingegen. Um dies zu umgehen, sollten solche Parameterabfragen von vornherein mit wildcards ausgestattet werden, einem Zeichen also, das das Programm anweist, lediglich die Zeichenfolge 'Fred' innerhalb eines Datensatzes zu finden, nicht einen vollständigen Datensatz. Das wildcard-Zeichen unter Access ist das Sternchen (*), das zweckmäßigerweise vor und hinter den zu suchenden Parameter eingegeben wird.
Während der Umgang mit solchen Abfragen vergleichsweise einfach ist, stellen sich erheblich größere Probleme, wenn nach einer bestimmten Angabe gesucht werden soll, die in zwei verschiedenen Feldern auftreten kann. Der Abfrageentwurf unter Access berücksichtigt dergleichen nicht. Eine Suchanweisung muß für jedes Feld einzeln gestellt werden; programmintern verbindet Access diese Anweisungen mit dem Befehl 'und'. Beinhaltet der Entwurf für eine Abfrage also die Suchanweisungen nach "Fred" im Text und "Max" im Verfasserfeld, zeigt Access lediglich dann einen Datensatz an, wenn einem Autor mit "Max" im Namen ein Textauszug mit "Fred" im Textfeld zugewiesen worden ist. Alle Datensätze, die von einem Autor "Max" stammen, aber nicht "Fred" enthalten, werden hingegen ignoriert wie ebenso auch alle Textbelege, die zwar "Fred" beinhalten, aber nicht von "Max" stammen. Diese Sortierfunktion läßt sich offenbar nicht umgehen, wenn nicht komplizierte Makros programmiert werden sollen.
Zunächst mag dies wie eine wenig relevante Einschränkung des Programms aussehen. In der Praxis hat sich jedoch erwiesen, daß so etwas bereits im Entwurf der Datenbank eingerechnet werden muß. In der vorliegenden Datenbank sind eine große Anzahl Textbelege enthalten, die sich mit dem Autor William Shakespeare beschäftigen. Dabei muß der Name nicht unbedingt im Textauszug selbst erscheinen; in einigen Fällen findet er sich statt dessen in der Überschrift, der im Tabellenentwurf ein eigenes Feld zugewiesen wurde. Eine Suche nach allen den Datensätzen, in denen Shakespeare diskutiert wird, muß nach den - nicht einmal explizit formulierten! - Abfrageregeln doppelt ausgeführt werden: einmal für die Nennungen im Textfeld, ein zweites Mal für diejenigen in der Überschrift. Duplikate - Textstellen, in denen der Name sowohl im Text- als auch im Überschriftsfeld erscheinen und die daher in beiden Abfragen auftauchen - sind dabei durchaus möglich, aber vom Programm nicht ohne weiteres herauszufiltern. Der Umfang der Belegstellen in der hier zugrunde gelegten Datenbank ist nicht so groß, daß sich solche Doppelungen nicht überblicken ließen; für eine größere Datenbank stellt dies jedoch ein ernstzunehmendes Problem dar, das sich nur gegebenenfalls durch einen Programmierer lösen läßt. Hier stößt der 'normale' Computernutzer ohne Programmierkenntnisse sehr schnell an Grenzen.
Formulare erleichtern die Anzeige von Daten am Bildschirm, sind aber nur bedingt im Ausdruck zu nutzen. Abfragen stellen die Daten in einer Tabelle zusammen. Diese läßt sich zwar nach MS Excel oder MS Word exportieren oder auch direkt aus Access heraus drucken, bleibt aber eine Tabelle und damit - besonders wenn es sich um größere Textmengen handelt - potentiell unübersichtlich. Berichte hingegen stellen die Daten druckergerecht zusammen (Beispiel anzeigen). Wie bereits bei Tabellen und Formularen stellt Access auch für den Bau eines Berichts einen Assistenten zur Verfügung; das individuelle Zusammenstellen ist jedoch trotzdem eine Alternative.
Ein Bericht basiert, wie ein Formular, auf einer Tabelle oder einer Abfrage. Er beinhaltet standardmäßig einen Berichtskopf und -fuß, einen Seitenkopf und -fuß sowie einen Detailbereich, der um weitere Bereiche - Gruppenköpfe und -füße - erweitert werden kann. Seitenkopf und -fuß erscheinen, wenn sie definiert sind, auf jeder Seite; Berichtskopf und -fuß jedoch nur einmal. Für die weiteren Bereiche gilt, daß individuell festgelegt werden kann, ob sie wiederholt werden sollen oder nicht, welche Daten angezeigt werden sollen, oder ob die Daten sortiert werden. Auf den ersten Blick sieht dies nach viel gestalterischem Freiraum aus. Tatsächlich wird dieser jedoch durch einige Fußangeln eingeschränkt.
Daten nach Kriterien zu sortieren ist nur in bestimmten Fällen möglich. In der vorliegenden Datenbank, in der Texte mit häufig sehr langen Titeln gespeichert sind, wurde das Titelfeld in der Fundort-Tabelle mit dem Attribut 'Memo' versehen: 'Memo'-Felder haben keine Längenbegrenzung, während 'Text'-Felder maximal 255 Zeichen enthalten können. Bei Titeln aus dem 17. oder 18. Jahrhundert, die häufig aus 500 oder mehr Zeichen bestehen, reicht diese Längenbegrenzung daher nicht aus. Access 97 vermag jedoch nicht, 'Memo'-Felder alphabetisch zu sortieren - was nicht weiter verwunderlich ist in Anbetracht der Tatsache, daß theoretisch unendlich viele Zeichen enthalten sein können. Das bedeutet jedoch, daß die für die Datenbank erstellten Berichte die Belegstellen zwar alphabetisch nach dem Verfassernamen, nicht aber alphabetisch nach dem Titel sortieren können. Wiederum gilt, daß dieses Manko im vorliegenden Fall keine gravierenden Folgen hat, weil der Datenbestand überschaubar ist; für umfangreiche Datenbanken kann dies jedoch anders aussehen.
Ein weiteres Problem betrifft die Anzeige von Daten aus verschiedenen Tabellen. Analog der Vorgehensweise bei den Formularen besteht auch bei den Berichten die Möglichkeit, andere Berichte einzubetten ('Unterberichte'), die andere Daten zusammenfassen. Was sowohl in der Access-eigenen Hilfefunktion als auch in den einschlägigen Handbüchern als ein überaus praktisches Hilfsmittel erscheint, stellt sich in der Praxis als weit weniger handhabbar heraus, wie folgendes Beispiel zeigt.
Im Fall der vorliegenden Datenbank sollten alle Textstellen eines Autors zusammen mit den ihnen zugewiesenen Topoi angezeigt werden. Einen Bericht zu erstellen, der Textstellen nach Eingabe des Autornamens auflistet, war nicht schwierig; dasselbe galt für den Entwurf eines weiteren Berichts, der den Textstellen die Toposkennziffern zuordnet. Auch die Einbettung dieses zweiten Berichts erwies sich als einfach. Allerdings wies der so entstandene komplexe Bericht die Textstellen jeweils mehrfach aus. Alles Herumtricksen - beispielsweise die Festlegung, daß einzelne Felder nicht sichtbar angezeigt werden sollten, oder die Aktivierung der Duplikatsunterdrückung - fruchtet nicht; der Bericht war und blieb unbrauchbar, weil er entweder Daten doppelt auflistete oder statt der Daten leere Flächen enthielt. Nach einigen Konsultationen und dem Versuch, zumindest die Doppelungen mit Hilfe eines Makros zu entfernen, wurde in der Belegstellen-Tabelle ein Feld nachträglich eingefügt, das alle zugewiesenen Topoi zusammenfassend auflistet. Auf diese Weise erspart sich der Nutzer zwar viel Ärger, aber das eigentliche Prinzip einer relationalen Datenbank wird dadurch unterlaufen. Auch hier gilt, daß ein normaler, nicht mit weitergehenden Programmierkenntnissen ausgestatteter Nutzer zwar einen einfachen Bericht ohne Schwierigkeiten erstellen und individuell anpassen kann, komplexere Fälle hingegen entweder einem Spezialisten überlassen oder darauf verzichten muß.
Keiner der Mitarbeiter des anglistischen Projekts verfügt über tiefgreifende Programmierkenntnisse; insofern betreffen die folgenden Bemerkungen nur den Wissensstand eines normalen, durchschnittlich mit Computern und -programmen vertrauten Nutzers. Für Anwender mit Kenntnissen in der Programmiersprache SQL - oder einem ihrer Ableger - stellt sich die Lage sicherlich anders dar.
Makros sind kleine Programme, die bestimmte vorgegebene Aufgaben erledigen: ein Fenster schließen, Filter ein- oder ausschalten, Warnmeldungen bei falschen Eingaben zeigen. Access enthält standardmäßig die Möglichkeit, Makros selbst zu schreiben - oder wie in einem Baukastensystem zu 'basteln'; der dazugehörige Assistent zeigt ein Fenster mit Steckmodulen, die nur kombiniert werden müssen - und diese zu größeren Einheiten, Modulen, zusammenzufassen. Einfache Makros zu schreiben ist nicht weiter schwierig; die accessinterne Hilfefunktion ist zwar nicht sonderlich zweckmäßig, gibt aber zumindest einige verwendbare Tips. Mit ein bißchen Herumprobieren lassen sich die meisten auftretenden Probleme lösen. Einige Makros sind sogar ausgesprochen hilfreich: Ein autoexec genanntes Makro wird automatisch beim Öffnen der Datenbank gestartet, in dem es enthalten ist. Da Access eine Datenbank nicht automatisch in einem maximierten Fenster startet, was zumindest im vorliegenden Fall stets zu erheblichen Anzeigeverlusten führte, kann über dieses Makro bereits festgelegt werden, daß das Programm die Datenbank in einem maximierten Fenster starten soll.
Bei schwierigeren Makros hingegen sind Kenntnisse im Programmieren unumgänglich. Bereits bei dem Versuch, eine if / if not / else if-Prozedur anzuschließen - also beispielsweise ein Makro, das ein Fenster nicht nur mit Ja/Nein-Tasten öffnet, sondern mit einer Dreierauswahl von einer Ja-, einer Nein- und einer zusätzlichen Abbrechen-Taste, - scheiterten alle Konsultationen von Hilfefunktion und Handbüchern kläglich. In SQL ist eine solche Prozedur vergleichsweise einfach; die Voraussetzung ist aber eben, daß SQL wenigstens in Rudimenten beherrscht wird. Ist dies nicht der Fall, ist auch der Rekurs auf die Hilfefunktion nicht von Erfolg gekrönt.
Access 97 ist ein in vieler Hinsicht ausgesprochen zweckmäßiges Programm. Seine Stärken liegen zum einen darin, daß der Entwurf einer Datenbank relativ einfach und für die individuellen Bedürfnisse anzupassen ist, zum anderen aber auch darin, daß Access nur ein Teil des Office-Paketes ist. Das Programm ist von vornherein darauf ausgerichtet, Daten an andere Office-Komponenten wie MS Word oder MS Excel weiterzugeben, mit denen eine weitergehende Analyse möglich ist. Diese Einbettung ist ausgesprochen komfortabel. Allerdings muß hinzugefügt werden, daß zumindest in der im Projekt verwendeten Version der Export in ein *.rtf-Dokument nicht immer reibungslos funktionierte; immer wieder gingen Daten dabei verloren.
Hinzu kommt die von anderen Office-Komponenten vertraute Oberfläche; Anwender müssen sich nicht erst in neue, fremde Oberflächen einarbeiten, sondern finden meist sehr schnell beispielsweise die Menübefehle, die sie suchen. Das verringert besonders bei wenig computerversierten Nutzern, deren es in den Geisteswissenschaften doch noch vergleichsweise viele gibt, ganz erheblich die Hemmschwelle. Die insgesamt einfache Erstellung neuer Abfragen oder Berichte macht Access 97 zudem zu einem leicht nutzbaren Programm. Für die meisten Arten der Datenabfrage lassen sich Lösungen finden, auch ohne ein Programmierer extra hinzugezogen wird; das ist insbesondere für Anwender, die keinen Access- oder SQL-geschulten Computerexperten am Institut haben, von Vorteil.
Der Aufbau und die Nutzung der Datenbank durch das anglistische Projekt haben gezeigt, daß Access durchaus auch für solche Textdatenbanken Verwendung finden kann, die nicht nur eine bibliographische Zusammenstellung von Quellen beinhalten, sondern auszuwertende Texte. Es gibt allerdings eine Reihe von Einschränkungen, die von vornherein berücksichtigt werden müssen und besonders für Literaturwissenschaftler von Bedeutung sind:
Werden diese Abstriche, die die Form und Funktion einer Datenbank zumindest für Literaturwissenschaftler durchaus etwas einschränken, von vornherein berücksichtigt, kann Access 97 als Datenbankprogramm gute Dienste leisten.
Die unter Access erstellte Datenbank kann - in der auch über das Internet recherchierbaren Teilfassung - hier heruntergeladen werden. Die Datenbank läuft sowohl unter Access 97 als auch unter Access 2000, muß allerdings unter der 2000er Version erst konvertiert werden.
| (c) F. Reitemeier |
