Vorwort - Content

Vorwort
Das vorliegende Buch entstand als eigenständiges Forschungsergebnis, das über den
Rahmen des Forschungsprojekts „Katholische Missionsschulen in Deutschland 1887–
1940“ deutlich hinaus ging. Dieses interdisziplinäre Forschungsprojekt wurde von September 2004 bis August 2007 von der Deutschen Forschungsgemeinschaft gefördert. Es
war in der Sektion Historische Pädagogik am Lehrstuhl von Prof. Dr. Uwe Sandfuchs,
Technische Universität Dresden, angesiedelt.
Die Entwicklung und Anwendung der Missionsschulen-Datenbank ließ es als dringend
erforderlich erscheinen, diesen eigenständigen Prozess und sein Ergebnis ausführlich
darzustellen. Als Beispiel dient hierbei die Datenbank der ältesten Missionsschule
Deutschlands, die von 1887–1940 in der Erzabtei St. Ottilien bestand. Wir danken dem
Erzabt von St. Ottilien, P. Jeremias Schröder OSB, für die Erlaubnis, die Bestände der
Erzabtei einsehen zu dürfen. Dem Archivar, Br. David Gantner OSB, sei für die vielfältigen Hilfen und Auskünfte gedankt. Die Datenbank wird nach der wissenschaftlichen
Analyse und Auswertung dem Archiv von St. Ottilien zur Verfügung gestellt, damit die
Erzabtei ihre personenbezogenen Daten datenschutzrechtlich selbst verwaltet. In unsere
Untersuchung gehen die Ergebnisse lediglich anonymisiert ein. Die Datenbank und die
Dokumentation zum Datensatz ist im Archiv nach den üblichen archivrechtlichen Bestimmungen für wissenschaftliche Zwecke einsehbar. Die Personennamen der Beispiele
in diesem Buch sind erfunden, Ergebnisse in der Regel für das Exempel eigens aufbereitet.
In diesem Buch zeigen wir, wie wir die Aufgabe einer quantitativen und qualitativen
Auswertung des Quellenmaterials zur Missionsschule St. Ottilien gelöst haben. Es geht
also darum, verlässliche, durch Zahlen und Zahlenverhältnisse belegte Aussagen über
die Missionsschule als Institution und über deren Personal, Schüler und Lehrer, zu treffen. Die Fragestellungen sind dabei sehr weit gefasst und tangieren grundlegende bildungshistorische Forschungsfragen.
Darüber hinaus erläutern wir am Beispiel des Missionsschulen-Projekts das generelle
Vorgehen beim Aufbau einer wissenschaftlichen Datenbank. Wir zeigen erstmals den
gesamten Prozess, von der Definition der Anforderungen bis zur konkreten Umsetzung
der Datenbank in einem relationalen Datenbanksystem, und legen so offen, wie die
Datenbank in einem (bildungs)historischen Projekt verwendet wurde. Dabei führen wir
auch in die notwendigen Grundlagen der Datenmodellierung ein und zeigen die technische Realisierung. Wir bleiben jeweils konsequent in der Sichtweise des Anwenders: Es
geht darum, zu verstehen, wie Datenbanken grundsätzlich eingesetzt werden können,
welche Vorteile und Möglichkeiten sie bieten, aber auch welche Gefahren und neue
Komplexität sie mit sich bringen. Die Übertragung auf andere Projekte beschränken wir
auf bildungshistorische Untersuchungen. Wichtig ist es uns dabei, die Aufgaben- und
Kompetenzverteilung zwischen Anwendern und Entwicklern offen zu legen, um die
Notwendigkeit enger Kooperation und Kommunikation zwischen beiden zu demonstrieren.
Prof. Dr. Uwe Sandfuchs (Braunschweig) und Prof. Dr. Herbert Klaeren (Tübingen)
danken wir für die kritische Durchsicht des Manuskripts und die wertvollen Hinweise.
Prof. Dr. Axel Nath (Lüneburg) verdanken wir eine äußerst anregende Diskussion unserer Ergebnisse und die Ermutigung zu dieser Publikation, Dipl.-Math. Dr. phil. Joachim
Neander (Kraków) die kritische Überprüfung des 5. Kapitels. Dem Verlag Julius Klinkhardt danken wir für die Aufnahme des Buches in die Reihe Forschung. Wir hoffen, mit
unserer Darstellung einen grundlegenden Beitrag für die Optimierung historischer Forschungen durch Datenbanken zu liefern.
Tübingen, München und Saarbrücken im August 2009
Holger Gast
10
Antonia Leugers
August H. Leugers-Scherzberg
1 Einleitung
1.1 Datenbanken in der Historischen Forschung
Die Nutzung von Datenbanken in der Historischen Forschung wurde seit den 1960er
Jahren diskutiert. Bald schon setzte sich die Erkenntnis durch, dass die Möglichkeiten
der elektronischen Datenverarbeitung für die Auswertung serieller Quellenbestände
sowie für Editions- und Publikationsvorhaben von entscheidender Bedeutung waren.1
Zu Beginn der 1970er Jahre prognostizierte gar der französische Historiker Emmanuel
LeRoy Ladurie, dass im Bereich der quantifizierenden Geschichtsforschung (l'histoire
quantitative) der Historiker der Zukunft „Programmierer sein oder nicht mehr sein werde“.2 Kam es in den 1970er und 1980er Jahren noch zu grundlegenden wissenschaftstheoretischen Erörterungen über den Wert oder Unwert des Einsatzes von Datenverarbeitungsprogrammen im Bereich der Geschichtswissenschaft, so wurden diese Diskussionen durch die massenhafte Verbreitung von Computern und leistungsfähiger
Computersoftware seit Mitte der 1980er Jahre faktisch überholt. Der einzelne Wissenschaftler stand nicht mehr vor dem Problem, ob er die bis dahin kostspielige Investition
in Computertechnologie auch wissenschaftstheoretisch gegenüber potentiellen Geldgebern legitimieren könne. Leistungsstarke Geräte der elektronischen Datenverarbeitung
zu Discount-Preisen erübrigten die Frage nach dem „ob“. Computer und Computersoftware gehörten fortan wie selbstverständlich zur Ausstattung eines jeden Forschungsprojekts. Der Einsatz der EDV-Technik wurde quasi obligatorisch, ohne dass
Fachwissen in Informatik vorausgesetzt oder gefordert wurde. Daraus entwickelte sich
eine weit verbreitete amateurhafte Anwendung der neuen Technologien, die im krassen
Gegensatz zu den technischen Möglichkeiten der Datenverarbeitung und zum Ruf nach
strenger Wissenschaftlichkeit im Bereich der historischen Zunft steht. Die Feststellung
der Münsteraner Mediävistin Stefanie Rüther, die in einem Datenbankprojekt eine leitende Stellung einnahm, beschreibt den Status Quo: „Entgegen der Prognose von Le
Roy Ladurie ist der Historiker eben nicht zum Programmierer geworden, sondern zum
user, der die ihm dargebotenen Möglichkeiten nutzt, wie es ihm gerade sinnvoll und
notwendig erscheint, ohne die darunterliegenden Strukturen durchschauen zu müssen
oder zu wollen.“ 3
1
2
3
Dabei sei v.a. auf Manfred Thaller und die Datenbank verwiesen, vgl. Bodarwé 2007, S. 49.
LeRoy Ladurie 1973, S. 14. Stefanie Rüther missversteht das Wort von LeRoy Ladurie, da sie übersieht,
dass er es mit Blick auf die „histoire quantitative“ abgegeben hat. Sie meint dagegen, dass er es auf die Geschichtswissenschaft überhaupt bezogen hat; vgl. Rüther 2007, S. 77.
Rüther 2007, S. 78.
12
Einleitung
Die traditionellen Formen des historischen Arbeitens, das Exzerpieren und Paraphrasieren von Quellen und Sekundärliteratur und das Anlegen von „Zettelkästen“, gab in
vielen Fällen auch die Struktur des Aufbaus von Datenbanken vor, die sich sukzessive
zu größeren Datenbankprojekten weiterentwickelten.4 Diese „Zettelkasten-Datenbanken“ stehen heute z.T. vor gravierenden technischen Problemen. So wurde bei einem
Symposion über den Einsatz von Datenbanken in den Geisteswissenschaften berichtet,
dass beim Aufbau einer internationalen Klosterdatenbank, die aus regionalen Vorarbeiten zusammengefügt werden soll, so grundlegende Probleme aufgetaucht seien wie die
Unmöglichkeit einer historisch-geographischen Auswertung der Klosterlandschaft,
einer exakten chronologischen Darstellung der Klostergründungen oder der Abbildung
der wechselnden Zugehörigkeiten der Klöster zu verschiedenen Orden.5 Im Sonderforschungsbereich 496 der Universität Münster, in dem von vornherein eine eigens für das
Projekt geschaffene relationale Datenbank entwickelt wurde – allerdings ohne Einbindung kompetenter Informatiker –, bilden inzwischen die Ortsnamen ein Problem, da die
beteiligten Kunsthistoriker die italienischen Ortsnamen in italienischer Form, die übrigen Wissenschaftler die Ortsnamen aber in deutscher Form eingegeben haben. Eine
datenbankübergreifende Suche nach italienischen Orten auf der Grundlage einer Volltext-Suche ist damit nicht mehr möglich.6
Dass historische Forschung, die Personen, Gruppen, Institutionen, Strukturen und Ereignisse über einen längeren Zeitraum betrachtet, um historisch relevante Entwicklungen und ihre Bedingungen zu untersuchen, nicht mit einer „Zettelkasten-Datenbank“
auskommen kann, gehört inzwischen zum common sense des Faches. Allerdings scheint
die Einsicht noch keine allzu weite Verbreitung gefunden zu haben, dass in gängigen
Datenbankprogrammen weit mehr Möglichkeiten für die historische Forschung stecken,
als Textsammlungen zu erstellen oder Massendaten quantitativ auszuwerten.
1.2 Anwendungsfall „Missionsschulen“
Im Rahmen des Missionsschulen-Projekts der Technischen Universität Dresden, das in
Kapitel 2 ausführlicher erläutert wird, war von vornherein vorgesehen, die Schüler- und
Lehrerschaft der zu untersuchenden Missionsschulen in einer Datenbank zu erfassen
und das Material mit Hilfe dieser Datenbank sozialstatistisch auszuwerten. Der Versuch,
eine entsprechende Datenbank aufzubauen, der von einer damit beauftragten Historikerin unternommen wurde, scheiterte letztlich, da es nicht möglich war, systematische
Abfragen der Datensätze mit Blick auf sozialhistorisch relevante Fragestellungen durchzuführen. In einem zweiten Anlauf wurde in interdisziplinärer Zusammenarbeit mit
einem Informatiker eine vollkommen neue Datenbank entworfen. Holger Gast (Eberhard Karls Universität Tübingen) entwickelte nach den Vorstellungen der Anwender
und geisteswissenschaftlichen Mitarbeiter des Projekts die Missionsschulen-Datenbank,
4
5
6
Vgl. Bodarwé 2007, S. 49.
Vgl. dazu Bodarwé 2007, S. 54–56.
Rüther 2007, S. 88f. Das Problem hätte sich übrigens von vornherein nicht gestellt, wenn die Orte über IDs
identifizierbar gemacht worden wären und nicht über eine Volltexteingabe, die selbst schon aufgrund der
Gefahr von Verschreibungen äußerst fehleranfällig ist.
Einleitung
13
die nicht nur die Fehler des ersten Versuchs vermied. Die Datenbank entwickelte sich
aufgrund seines Einsatzes zu einem methodischen Hilfsmittel, das weit mehr als die
übliche quantitative Analyse von Massendaten zu leisten vermag.
Die spezifische Architektur der Datenbank, die in den folgenden Kapiteln erläutert wird,
erlaubt es nicht nur, das verarbeitete Quellenmaterial möglichst vollständig zu erfassen,
sondern es auch unter den unterschiedlichsten sozial- und bildungshistorischen Fragestellungen auszuwerten. Die Form der relationalen Datenbank, die Gast in das Projekt
einbrachte, bietet prinzipiell unbegrenzte Möglichkeiten, die Daten sowohl individualgeschichtlich als auch massenstatistisch auszuwerten, Merkmale zu kombinieren und
Abfragen unter je neuen Gesichtspunkten zu formulieren und durchzuführen.
1.3 Datenbanken in historischen Forschungsprojekten
Die Entscheidung, ein bestimmtes historisches Forschungsvorhaben mit Hilfe einer
Datenbank anzugehen, birgt viele Implikationen für den Verlauf des Projektes. Die
meisten dieser Implikationen sind nicht offensichtlich und ergeben sich erst aus den
späteren Erfahrungen. Nichtsdestotrotz müssen die wesentlichen Entscheidungen bereits
zu Beginn des Projektes getroffen werden, weshalb die folgenden Ausführungen hier
auch als Einleitung und Vorüberlegung stehen. Sie beleuchten die Datenbank im historischen Forschungsprojekt aus vier Blickrichtungen und unter vier Fragestellungen: Welche Chancen, aber auch Risiken bringt der Einsatz einer Datenbank mit sich? Wie ist
eine Datenbank grundsätzlich aufgebaut und welche Punkte müssen deshalb bei ihrer
Erstellung bedacht werden? Wie ändert der Einsatz einer Datenbank die Arbeitsabläufe?
Und schließlich: Wie wird die Arbeit zwischen Historikern und Entwicklern der Datenbank so aufgeteilt, dass Risiken minimiert, Fehlschläge vermieden und das Projekt zu
einem Erfolg geführt wird?
1.3.1 Chancen und Risiken von Datenbanken
Elektronische Datenbanken können die Arbeit in historischen Projekten, insbesondere
solchen mit umfangreichen Quellen, vereinfachen und effektiver gestalten. Sie bündeln
die verfügbare Information an einer zentralen Stelle und konsolidieren so den Quellenbestand in Hinblick auf die Forschungsfragen des Projektes. Die verschiedenen Mitarbeiter können gemeinsam auf die gespeicherten Informationen zugreifen und so von den
Fortschritten der anderen profitieren, wodurch die eingebrachte Arbeit zur mehrfachen
Nutzung offen steht. In der Auswertung der Quellen ergibt sich durch die Datenbank
eine Objektivierung, die dem (natur-)wissenschaftlichen Ideal der prinzipiellen Wiederholbarkeit von Experimenten nahe kommt: Die Datenbank liefert Ergebnisse durch
vorgeschriebene Rechenschritte und jeder, der Zugriff auf den Datenbestand hat, kann
prinzipiell Abfragen formulieren, um die Aussagen anderer zu überprüfen. Die Datenbank ist die Basis und der Prüfstein aller Ergebnisse. Schließlich ist es, wieder in Anlehnung an das naturwissenschaftliche Experiment, möglich, Varianten von Abfragen
zu formulieren und damit Versuchsreihen durchzuführen: Abfragen erlauben es, die in
der Datenbank gespeicherten Informationen und Merkmale neu zu kombinieren oder in
Gruppen zu kontrastieren und Ausschnitte des Datenbestandes zu bilden. Damit können
14
Einleitung
Zusammenhänge sichtbar gemacht werden, Hypothesen geprüft und Aussagen differenziert und präzise belegt werden.
Der Einsatz einer Datenbank birgt jedoch auch Risiken: Durch ihre zentrale Stellung im
Projekt diktiert die Datenbank weitgehend dessen Planung und Ablauf. Sie ist im Methodenrepertoire des Historikers (noch) nicht etabliert, so dass neue wissenschaftstheoretische Fragen behandelt werden müssen. Ihre Arbeitsweise ist größtenteils verdeckt,
insofern als der Forscher nicht mehr – wie in hergebrachten Arbeitsweisen – jeden
Nachweisschritt zwischen Quelle und Ergebnis im Einzelnen selbst nachvollziehen
kann, sondern bereits zusammengestellte, aufbereitete Ergebnisse vorfindet, die sich in
irgendeiner Form aus den eingegebenen Daten herleiten. Durch diese indirekte Herleitung stellt sich die Frage nach der Verlässlichkeit der gewonnen Ergebnisse, und damit
auch wieder nach deren Objektivität: Diese ist durch den Schein von Transparenz und
durch verdeckte Fehler weit mehr gefährdet als durch letztlich nachweisbare, bewusste
Manipulationen.
Schließlich führt die Datenbank eine neue Komplexität in das Projekt ein, die nicht
durch fachimmanente Fragestellungen motiviert ist: Die Struktur der Quellen muss so
weit analysiert und festgelegt werden, dass verwandte Informationen die gleiche Form
erhalten und so als Gruppe in der Datenbank gespeichert und verarbeitet werden können. Die Anforderungen an die Strukturierung gehen dabei weit über die geordnete
Auflistung von Hand hinaus: Sachverhalte, die sich nicht in die festgelegte Struktur
eingliedern, lassen sich mit der Datenbank überhaupt nicht mehr sinnvoll verarbeiten.
Die Strukturierung muss überdies im Voraus geleistet werden, noch bevor die ersten
Quellen in der Datenbank erfasst sind, da spätere Änderungen aufwendig und fehleranfällig sind. Sie muss nicht nur die Struktur der Quellen abbilden, sondern auch schon die
später gewünschten Abfragen in den Blick nehmen, da schon die Entscheidungen über
die Speicherung der Daten deren später mögliche Auswertungen mitbestimmen.
Die gerade genannten Auswirkungen zeigen vor allem eines: Der Historiker kann in
einem Projekt, in dem eine Datenbank an zentraler Stelle eingesetzt wird, keinesfalls
mehr nur „user [sein], der die ihm dargebotenen Möglichkeiten nutzt“, sondern er muss
auch die „darunterliegenden Strukturen“7 soweit nachvollziehen, dass er die Auswirkungen auf seine Arbeit abschätzen kann: Wo es um die Verlässlichkeit von Forschungsergebnissen geht, darf kein Schritt in der Nachweiskette unbedacht bleiben. Der Forscher
kann die Verantwortung für die Richtigkeit grundsätzlich nicht an die Entwickler der
Datenbank abgeben. Er muss die „Möglichkeiten“ und die „Strukturen“ sogar aktiv mit
gestalten, denn nur er selbst kann abschätzen, welche Funktionalität die Datenbank im
Einzelnen bieten muss, wie genau die zu erfassenden Quellen aufgebaut sind und welche Forschungsfragen schließlich untersucht werden sollen.
Zusammenfassend gesagt müssen beim Einsatz von Datenbanken in der historischen
Forschung zwei Aspekte durchgängig bedacht werden: Die Verwendbarkeit der Datenbank für ein spezifisches Projekt und die Verlässlichkeit der Ergebnisse. Es müssen alle
relevanten Quellen, die vorkommenden Spezial- und Sonderfälle eingeschlossen, mit
Hilfe der Datenbank erfasst und verarbeitet und die Bedeutung der berechneten quanti7
Rüther 2007, S. 78.
Einleitung
15
tativen Ergebnisse im Detail bis zu den Quellen zurückverfolgt werden können. Es
dürfte sich von selbst verstehen, dass dies auf Seiten der Historiker die vollständige
wissenschaftliche Erforschung des Quellenbestandes voraussetzt.
Bevor in den nachfolgenden Kapiteln gezeigt wird, wie diese Herausforderungen für das
Missionsschulen-Projekt im Einzelnen gelöst wurden, soll nun zunächst eine Übersicht
über den allgemeinen Aufbau von Datenbanksoftware gegeben werden, um eine Einordnung der Fragen auf den verschiedenen Ebenen zu erlauben.
1.3.2 Die Schichtenarchitektur von Datenbanksoftware
Datenbanken sind komplexe Softwareprodukte: Sie müssen Dateneingaben durch den
Benutzer genauso realisieren wie die Speicherung der Daten in einzelnen Dateien auf
der Festplatte. Sie müssen Zugriffe auf die Daten, wie sie der Benutzer formuliert, umsetzen in Lese- und Schreiboperationen auf den verwendeten Datenstrukturen. Zur Beherrschung dieser Komplexität und zur Strukturierung der Gesamtsoftware verwendet
die Informatik eine Einteilung in Schichten (oder auch Ebenen). Alle Schichten erfüllen
grundsätzlich die gleichen Aufgaben, allerdings auf unterschiedlichen Abstraktionsstufen: Auf der untersten Schicht besteht das Auslesen von Daten tatsächlich aus einem
Zugriff auf die Festplatte, auf der obersten Schicht könnte der Benutzer beispielsweise
eine Anzeige erhalten, die das Aussehen der Quellen nachbildet.
Für Datenbanksoftware hat sich eine Einteilung in Schichten nach dem verwendeten
Datenmodell durchgesetzt, das die Struktur der Daten beschreibt. Die Struktur der Daten wird in diesem Zusammenhang auch als Schema bezeichnet.8 Das externe Schema
beschreibt die Struktur der Daten aus Sicht der einzelnen Benutzer. Es unterscheidet
zwischen verschiedenen Benutzergruppen und ordnet ihnen jeweils die Ausschnitte aus
dem Datenbestand zu, auf den sie Zugriff haben. Damit definiert es verschiedene Sichten auf die Datenbank. In der darunter liegenden Schicht beschreibt das konzeptuelle
Schema die Struktur der Gesamtdatenbank, ohne jedoch auf die tatsächliche Realisierung einzugehen. Das Datenmodell dieser Schicht definiert die Entitäten und Relationen
(vgl. Kapitel 3), die in der Datenbank abgelegt werden sollen. Wenn mehr Details benötigt werden, kann hier auch schon ein relationales Datenmodell (vgl. Kapitel 4) eingeführt werden. In der untersten Schicht legt das interne Schema fest, wie die Daten tatsächlich gespeichert werden. Das entsprechende physische Datenmodell beschreibt den
genauen Aufbau der einzelnen Dateien und die möglichen Zugriffswege zu den Daten.
Es ist in üblichen Datenbankprogrammen überhaupt nicht zugänglich, sondern wird
automatisch aus einem relationalen Datenmodell abgeleitet.
Im Folgenden wird eine Anwendung dieser grundsätzlichen Einteilung auf historische
Forschungsprojekte gegeben (vgl. auch Abb. 1, Seite 16). Weil hier häufig die Benutzer
eine einzige homogene Gruppe mit weitgehend ähnlichen Rechten und Sichten auf die
Daten bilden, wird das externe Schema vernachlässigt. Stattdessen wird die Benutzerschnittstelle als eigenständige Schicht eingeführt, weil sie wesentlich zur Verwendbarkeit der Datenbank beiträgt. Das Hauptaugenmerk der Darstellung liegt auf den Beiträgen jeder Schicht zu den Fragen der Verwendbarkeit und der Verlässlichkeit der
8
Vgl. Elmasri/Navathe 2000, Abschnitte 2.1 und 2.2.
16
Einleitung
Repräsentations-Modell
Konzeptuelles
Modell
Benutzerschnittstelle
Schicht
Aufgaben
Inhalte
Anforderungen
ƒ Verbergen von Interna ƒ Eingabeformulare ƒ Arbeitsprozesse
abbilden
ƒ Komfortable Bedienung ƒ Übersichten
ƒ Zusammenfassun- ƒ Aktuelle Anzeige
ƒ Unterstützung des
Benutzers
gen
ƒ Kommunikation
ƒ Dokumentation
ƒ Bedeutung von Daten
festlegen
ƒ EntityRelationshipDiagramm
ƒ Dokumentationstext
ƒ Realisierung der Daten- ƒ Tabellen
bank in Software
ƒ Vollständigkeit
ƒ Verständlichkeit für
Benutzer
ƒ Abbildung des
konzeptuellen Modells
ƒ Freiheit von Programmierfehlern
Abb. 1: Schichtenarchitektur von Datenbanksystemen.
Ergebnisse, sowie auf den Entscheidungen, die in jeder Schicht getroffen werden müssen. Diese Sichtweise erlaubt es, die komplementären Beiträge von Historikern und
Informatikern bei der Erstellung der Datenbank sichtbar zu machen.
1.3.2.1 Benutzerschnittstelle
Der Historiker als Benutzer einer Datenbank ist in seiner täglichen Arbeit nicht an den
internen Vorgängen und nicht einmal am konzeptuellen Schema interessiert. Für eine
effektive Arbeit muss er sich auf seine fachlichen Ziele konzentrieren, die Datenbank ist
nur Hilfsmittel. Die Benutzerschnittstelle leistet genau diese Trennung der Interessen:
Obwohl der Historiker natürlich technisch gesehen immer mit den konkreten Datenstrukturen auf der Festplatte arbeitet, erscheint ihm diese Arbeit als eine normale Quellenauswertung. Er kann die relevanten Informationen, so wie er sie vorfindet, in der
Datenbank ablegen und sich anschließend einen Überblick über die gespeicherten Informationen verschaffen. Die Benutzerschnittstelle setzt dabei Eingaben auf dem Bildschirm in Änderungen an den Daten um, und zeigt umgekehrt die gespeicherten Daten
in Formularen oder Tabellen so an, dass der Benutzer sie direkt interpretieren kann.
Diese Aufgabe ist keinesfalls trivial: Bei der Modellierung (Kapitel 3) müssen häufig
Merkmale kodiert werden, so dass die Datenbank intern nur Listen von Zahlen abspeichert, die den Benutzer verwirren würden. In der Benutzerschnittstelle werden daher die
Zahlen in erklärende Texte übersetzt und bei der Eingabe umgekehrt die Texte in Zahlen kodiert. Weil intern keine Redundanzen in den Daten vorkommen dürfen, müssen
Einleitung
17
außerdem für die Ein- und Ausgabe häufig Daten aus verschiedenen Tabellen kombiniert werden, damit der Benutzer die Zusammenhänge überblicken kann.
Die Herausforderung für die Verwendbarkeit der Datenbank liegt vor allem in der Unterstützung etablierter Arbeitsweisen und -prozesse: Wenn beispielsweise eine Quellengattung eine bestimmte Kombination von Merkmalen zusammenstellt, dann sollte die
Benutzerschnittstelle ein entsprechendes Eingabeformular bereitstellen, das genau diese
Kombination abfragt. Die Alternative bestünde darin, dass der Benutzer für jede Information immer wieder neu die Stelle suchen muss, an der die Datenbank die Eingabe
genau dieser Information erlaubt, was offensichtlich zeitaufwendig und auch fehleranfällig ist. Viele Datenbankprogramme im Office-Bereich bieten die Möglichkeit, die
internen Tabellenstrukturen direkt in Eingabeformulare umzusetzen. Diese verführerisch einfache Vorgehensweise sorgt jedoch dafür, dass sich der Benutzer in seiner täglichen Arbeit mit den Interna auseinandersetzen muss, anstatt sich auf seine eigentliche
Arbeit zu konzentrieren.
In Hinblick auf die Verlässlichkeit der Ergebnisse sind zwei relevante Vorkehrungen zu
treffen: Die auf dem Bildschirm angezeigten Daten müssen jederzeit den aktuellen Datenbestand widerspiegeln und es muss Übersichtsdarstellungen geben, die unabhängig
von der Eingabemaske den tatsächlichen Datenbestand so zusammenstellen, dass der
Benutzer ihn einfach mit den vorliegenden Quellen abgleichen kann. Durch diese Maßnahmen, besonders wenn auch die Eingabeformulare schon die Quellenstruktur widerspiegeln, kann der Benutzer zeitnah Fehler erkennen und korrigieren. Weil die späteren
Abfragen (Abschnitt 4.6) sehr viele Daten automatisiert zusammenstellen, können an
dieser Stelle keine Fehler mehr entdeckt werden, sie müssen schon bei der Dateneingabe ausgeschlossen werden. Die Qualität der Ergebnisse hängt direkt von der Qualität der
gespeicherten Daten ab.
1.3.2.2 Konzeptuelles Datenmodell
Das konzeptuelle Datenmodell dient der Kommunikation zwischen Benutzern und Entwicklern. Zu Beginn des Projektes muss notwendigerweise der Benutzer seine Anforderungen an die Datenbank beschreiben, die der Entwickler dann in eine Software umsetzt. Dabei bedient er sich natürlich seiner Fachterminologie, um möglichst präzise
Aussagen zu treffen und schließlich eine Datenbank zu erhalten, die seinen fachlichen
Bedürfnissen gerecht wird. Allerdings ist ihm im Grunde unklar, welche Informationen
der Entwickler genau benötigt, da er die zu treffenden Entscheidungen nicht kennt.
Umgekehrt ist der Entwickler normalerweise selbst kein Historiker, oder zumindest mit
dem spezifischen Arbeitsgebiet nicht vertraut, so dass er die Aussagen des Benutzers
nur unzulänglich nachvollziehen kann. Nichts ist für den Projekterfolg schädlicher, als
wenn der Entwickler an dieser Stelle das fehlende Verständnis durch eigene Ideen ausgleichen möchte: Da er selbst kein Experte ist, wird er beinahe sicher die falschen Entscheidungen treffen.
Um diese zentrale Aussage zu unterstreichen, sei an dieser Stelle ein Beispiel aus der
Missionsschulen-Datenbank genannt: Zur Auswertung der regionalen Herkunft der
Schüler sollten deren Geburtsorte und die damit verbundene politische Zuordnung zu
Kreisen, Regierungsbezirken, bis hin zu den Staaten aufgenommen werden. Der Infor-
18
Einleitung
matiker versteht die benötigte Datenstruktur sofort: Eine Hierarchie führt zu einer so
genannten Baumstruktur, die sich in relationalen Datenbanken leicht über 1:N Beziehungen und Fremdschlüsselattribute nachbilden lässt (vgl. Abschnitte 3.2.2 und 4.4.3).
Erst bei Rückfrage an die Historiker wird klar, dass diese Datenstruktur nicht der Wirklichkeit entspricht und dass sie damit die Quellen nicht wiedergeben kann: Die Gebietszuordnungen änderten sich aufgrund von Kriegen und politischen Prozessen, aus Sicht
der Informatik wird der „Baum“ zu einem so genannten gerichteten, azyklischen Graph.
In der Datenbank muss also bei jeder Zuordnung auch gespeichert werden, in welchem
Zeitraum sie gültig ist. Ob dabei eine Beschränkung auf ganze Jahre erlaubt oder sinnvoll ist, kann wieder nur der Anwender entscheiden.
Die Zusammenarbeit zwischen Entwicklern und Historikern wird weiter unten noch
genauer zu betrachten sein. An dieser Stelle bleibt zunächst festzuhalten, dass es eine
Form der Rückkopplung geben muss, bei der der Entwickler sein zunächst unvollständiges und fehlerhaftes Verständnis so ausdrückt, dass der Benutzer das Ergebnis mit
seinem Verständnis abgleichen und Fehler aufzeigen kann. Genau diese Möglichkeit
bietet das konzeptuelle Datenmodell. Es muss für Benutzer und Entwickler gleichermaßen verständlich sein und bietet eine lingua franca zwischen den gegensätzlichen Fachterminologien. Damit verlangt es vom Entwickler eine Abstraktion über die konkrete
Programmierung der Datenbank, vom Benutzer die begrenzte Einpassung seines Fachverständnisses in die durch die Informatik vorgegebenen Strukturen. Eine geeignete
Sprache bieten die Entity-Relationship-Modelle (Kapitel 3): Entitäten entsprechen direkt den Dingen der Wirklichkeit, mit denen der Benutzer in seiner Arbeit konfrontiert
ist. Sie werden näher beschrieben durch Attribute, die letztlich als Daten in der Datenbank gespeichert werden, so dass eine Entität aus Entwicklersicht genau zu einem Datensatz wird. Über die Zwischenstufe der Entität können also das Verständnis des Benutzers und das Verständnis des Entwicklers gegeneinander abgeglichen werden. Die
Relationen des Modells entsprechen direkt Beziehungen zwischen Entitäten, wie sie in
der Wirklichkeit vorkommen. Da jede Relation auch wieder zu einem Datensatz wird,
oder zumindest zu einem Bestandteil eines Datensatzes, können Entwickler und Benutzer über die benötigten Relationen sprechen.
In Hinblick auf die Verwendbarkeit der Datenbank ist ein detailliertes und durchdachtes
konzeptuelles Modell von zentraler Bedeutung: Im ersten Verständnis der Aufgabe sind
immer die großen Strukturen, die normalen Fälle betont, weil dadurch die Grundidee am
besten transportiert wird. Damit die Datenbank jedoch in der täglichen Arbeit verwendbar ist, müssen gerade auch die Spezialfälle berücksichtigt werden, die erst bei kritischen Rückfragen offenbar werden und die Abweichungen vom Alltagsverständnis
offen legen, wie das obige Beispiel gezeigt hat.
Auch wenn auf dieser Ebene tatsächlich keine Daten gespeichert werden, spielt das
konzeptuelle Modell doch eine herausragende Rolle für die Verlässlichkeit der Ergebnisse, indem es die Bedeutung der in der Datenbank abgelegten Daten definiert. Wie
Abschnit 4.6 zeigt, sind Abfragen rein technische Artefakte, deren Ausgaben dennoch
als Ergebnisse über die Wirklichkeit interpretiert werden sollen. Dies kann wiederum
nur gelingen, wenn alle internen Berechnungsschritte direkt auf die Bedeutung der Daten, so wie sie der Benutzer versteht, zurückbezogen werden können.
Einleitung
19
1.3.2.3 Realisierung der Datenbank
Die unterste Schicht der Datenbankanwendung bildet ein Repräsentationsmodell (oder
auch Darstellungsmodell). Es schreibt genau fest, welche Daten in welchen Formaten
an welcher Stelle in der Datenbank abgelegt werden sollen. Die Beschreibungssprache
ist üblicherweise die Datendefinitionssprache von SQL (Structured Query Language).
Alternativ kann der Entwickler die graphische Schnittstelle des Datenbankproduktes
nutzen, um das Datenmodell festzulegen. Das Ziel der Realisierung muss es sein, das
konzeptuelle Datenmodell so genau wie möglich und nach festgelegten, nachvollziehbaren – letztlich also objektiven – Regeln umzusetzen (vgl. Abschnitt 4.5). Der Entwickler
trifft hier keine wesentlichen eigenen Entscheidungen mehr, sondern realisiert nur noch
die zuvor mit dem Benutzer abgestimmten Schritte.
Der direkte und transparente Bezug zum konzeptuellen Modell sichert sowohl dessen
Verwendbarkeit als auch Verlässlichkeit: Die Bedeutung der Daten, wie sie in der Datenbank abgelegt sind, und auch die Gesamtheit der Eingabemöglichkeiten ergeben sich
bereits aus diesem Modell. Der Entwickler muss bei der Realisierung nur in der Rolle
eines zuverlässigen Handwerkers sicherstellen, dass sich auf der technischen Ebene
keine Programmierfehler einschleichen. Die Beherrschung von Programmierfehlern
kann jedoch nicht Thema dieses Buches sein, sondern wird im Gebiet der Softwaretechnik ausführlich behandelt.9
Der Vollständigkeit halber sei noch vermerkt, dass unterhalb des Repräsentationsmodells das physische Modell in einer eigenen Schicht angesiedelt ist. Es legt fest, wie
genau die Daten des Repräsentationsmodells auf der Festplatte gespeichert werden und
welche Möglichkeiten des Zugriffs auf einzelne Datensätze bestehen. Diese Schicht
wird innerhalb der verwendeten Datenbanksoftware realisiert. Der Entwickler hat keinen Einfluss auf die dort getroffenen Entscheidungen. Genauso wie das konzeptuelle
Modell den Benutzer von der Aufgabe entlastet, die Details der Realisierung zu verstehen, so entlastet das Repräsentationsmodell den Entwickler von der Aufgabe, die Daten
tatsächlich auf der Festplatte ablegen zu müssen, so dass er sich auf die Realisierung der
konkreten Datenbank konzentrieren kann.
1.3.3 Ergebnisgewinnung mit Hilfe einer Datenbank
Unser Ziel für den Einsatz von Datenbanken in der historischen Forschung ist die Gewinnung verlässlicher quantitativer Ergebnisse. Die Komplexität der Datenbankanwendung selbst und die Problematik ihrer Erstellung sind bereits besprochen worden.
Daneben zwingt die Datenbank jedoch auch dem Projektablauf eine besondere Struktur
auf: Während im traditionellen Arbeitsprozess Ergebnisse gerade beim Quellenstudium
gefunden werden können, liegen beim Einsatz einer Datenbank zwischen dem Quellenstudium und dem ersten Ergebnis mehrere umfangreiche Arbeitsschritte, die für sich
genommen zunächst keine Beiträge aus historischer Sicht liefern, sondern nur dem
Aufbau eines geeigneten Datenbestandes dienen, aus dem schließlich die Ergebnisse
gewonnen werden. Im Folgenden sollen diese Schritte und die jeweiligen Herausforde-
9
Vgl. Sommerville 2007, Teil V.
20
Einleitung
rungen aufgezeigt werden, um so komplementär zur bereits gegebenen Beschreibung
des Endprodukts eine Beschreibung des Weges dorthin zu erhalten.
In der ersten Projektphase muss zunächst die Datenbankanwendung erstellt werden,
wobei die oben genannten Herausforderungen zu bewältigen sind. Um das Kriterium
der Verwendbarkeit zu erfüllen, müssen zu Beginn die Anforderungen von Seiten der
Historiker geklärt werden, wozu wiederum zwei Arbeitsschritte erforderlich sind: Es
müssen alle relevanten Quellen gesichtet und die zu bearbeitenden Forschungsfragen
formuliert werden. Auch wenn diese Schritte am Anfang jedes historischen Forschungsprojektes stehen, kommt ihnen beim Einsatz einer Datenbank besondere Bedeutung zu, da die einmal getroffenen Festlegungen nur schwer oder gar nicht revidiert
werden können. Dazu tragen drei Faktoren bei: Es ist um ein Vielfaches aufwendiger,
einmal geschriebene Software abzuändern, als sie von vornherein richtig zu konzipieren. Weiterhin müssten bei Änderungen in späteren Projektphasen bereits vorhandene
Daten in eine neue Form gebracht und konsistent erweitert werden. Schließlich verlangt
die Konstruktion einer Datenbank eine vollständige, detaillierte und präzise Auflistung
der relevanten Informationen und Fragestellungen, wenn das Produkt vollständig und
präzise die Arbeit der Historiker unterstützen soll.
Die Forderung, auch die Forschungsfragen bereits an dieser Stelle weitgehend zu definieren oder zumindest im Gespräch mit dem Entwickler zu skizzieren, mag befremdlich
erscheinen. Sie hat sich jedoch sowohl im Missionsschulen-Projekt als auch im früheren
Lebensbilder-Projekt10 bewährt. Die Definition eines Datenmodells muss aus Sicht der
Informatik grundsätzlich nicht nur die zu speichernden Daten selbst enthalten, sondern
immer auch die auf den Daten auszuführenden Operationen. Die Forschungsfragen
umreißen diese Operationen und können so dem Entwickler Anhaltspunkte geben. Es
sei jedoch bemerkt, dass der Fragenkatalog keineswegs vollständig sein muss, denn eine
solche Forderung wäre unverträglich mit einem flexiblen Einsatz der Datenbank: Wenn
es gilt, eine feste Liste von Fragen zu beantworten, erledigt man dies effektiver durch
einmalige Durchsicht der Quellen. Der Fragenkatalog grenzt daher nur die Themengebiete ein, die zu behandeln sind, zeigt benötigte Merkmalskombinationen auf und dient
damit als Messlatte für die Reife der Datenbank. Da relationale Datenbanksysteme sehr
mächtige Operationen auf den Daten unterstützen (vgl. Abschnitt 4.6), sind im Normalfall auch analoge Fragestellungen problemlos bearbeitbar.
In der zweiten Phase wird die Datenbank mit Daten aus den Quellen gefüllt. Da Änderungen an der Datenbank in dieser Phase nur schwierig möglich sind, muss zuvor die
erste Phase vollständig abgeschlossen sein. Die Dateneingabe selbst stellt hohe Anforderungen an den Benutzer: Selten können Quellen direkt vom vorliegenden Papier in
die Datenbank übertragen werden. Es müssen Informationen aus verschiedenen Quellen
zusammengetragen und unklare Angaben recherchiert und interpretiert werden. Da bei
späteren Abfragen der Datenbestand als letzte Instanz gilt und nur noch mit großem
Aufwand, nämlich durch erneute Durchsicht aller Quellen, hinterfragt werden kann,
werden Fehler bei der Dateneingabe ziemlich sicher zu nicht erkennbaren Fehlern in
den Ergebnissen führen. Da überdies Daten mehrfach benutzt werden, setzt sich ein
10
Vgl. Mainka-Mehling 2007; Gast/Mainka-Mehling 2007.
Einleitung
21
Fehler an dieser Stelle in vielen Ergebnissen fort. Darüber hinaus muss der Benutzer
auch die beim Entwurf festgelegte Bedeutung der einzelnen Merkmale in der Datenbank
kennen und verstehen, denn bei den späteren Abfragen wird gerade diese Bedeutung
wieder zur Interpretation der Ergebnisse herangezogen. Wenn sich der eingebende Bearbeiter und der abfragende Bearbeiter über die Interpretation der Daten nicht einig
sind, enthalten die Ergebnisse wieder subtile Fehler. Die Aufgabe des Historikers, der
das Forschungsprojekt durchführt, umfasst daher alle Teilschritte, von der Erforschung
des Quellenbestandes über die Dateneingabe bis zur Interpretation der Ergebnisse, und
keiner dieser Schritte kann delegiert werden.
Die nun folgende dritte Projektphase dient der Auswertung der eingegebenen Daten, um
die Forschungsfragen zu beantworten. Dazu formuliert der Historiker jede Frage als
Hypothese über erwartete Zahlenverhältnisse und vergleicht diese Erwartung mit den
tatsächlichen Gegebenheiten. Die Abfragen an sich sind relativ technisch in der Sprache
SQL11 zu formulieren und können wahrscheinlich nur vom Entwickler, nicht vom Historiker, bereitgestellt werden. Sie beziehen sich überdies auf das relationale Datenmodell, das nur dem Entwickler bekannt ist. Wie schon bei der Erstellung der Datenbank
dient das konzeptuelle Datenmodell aus der ersten Projektphase als Referenz: Der Historiker kann darin die benötigten Daten für eine Forschungsfrage lokalisieren, der Entwickler kann es nutzen, um die Ergebnisse der geschriebenen Abfrage zu erklären.
Aus dieser Darstellung ergibt sich, dass die dritte Phase schon beginnen kann, bevor die
zweite abgeschlossen ist, solange immer nur vollständig eingegebene Teilbereiche des
Datenbestandes abgefragt werden. In der Missionsschulen-Datenbank ist es beispielsweise möglich, die regionale Herkunft der Schüler auszuwerten, auch wenn die Informationen zu den einzelnen Klassen noch nicht eingegeben sind. Ein weiteres Argument
für einen zügigen Beginn ist die Tatsache, dass Abfragen, wenn sie einmal geschrieben
sind, ohne viel Aufwand mit einem aktuelleren Datenbestand ausgeführt werden können. Man kann also schon während der zweiten oder sogar ersten Projektphase Abfragen schreiben und mit den bereits vorhandenen Daten testen, um später im Projekt Zeit
zu sparen.
1.3.4 Arbeitsteilung zwischen Anwendern und Entwicklern
Die vorangegangene Beschreibung hat die Risiken eines Datenbankeinsatzes, die Komplexität der Datenbanksoftware selbst und die relativ festgelegte Struktur eines Projektes mit Datenbanken aufgezeigt. Eine Folgerung ist nun offensichtlich: Das technische
Wissen, die praktische Erfahrung und die fachliche Übersicht, die notwendig sind, um
Datenbanken in letzter Konsequenz erfolgreich einzusetzen, lassen sich nicht nebenbei
erwerben. Damit ist es relativ unwahrscheinlich, dass die aktiv forschenden Historiker
die benötigte Datenbank selbst erstellen können. Sie werden technische Hilfestellung
benötigen. Umgekehrt werden jedoch selbst sehr erfahrene Informatiker nicht in der
Lage sein, die Datenbank eigenständig zu erstellen, weil ihnen das historische Fachwissen fehlt. Sie durchschauen zwar die technischen Zusammenhänge, übersehen aber
wahrscheinlich viele der Auswirkungen, die ihre Entscheidungen für die Verwendbar11
Vgl. Elmasri/Navathe 2000, Kapitel 6.
22
Einleitung
keit der Datenbank haben. Diese leidvolle Erfahrung haben sicherlich schon viele Anwender hinter sich. Eine solche „professionell“ entwickelte, aber nicht auf das konkrete
Problem zugeschnittene Datenbank ist schließlich nutzloser als eine von den beteiligten
Historikern selbst erstellte, die vielleicht technische Mängel aufweist, aber doch die
Forschungsaufgabe unterstützt.
Die geschilderte Situation ist in der Softwareentwicklung alltäglich: In jedem Projekt
wenden sich die Anwender einer zu erstellenden Software an erfahrene Entwickler,
tragen ihnen ihre Anforderungen und Wünsche vor, woraufhin die Entwickler eine Software schreiben, die diesen Anforderungen genügt. In jedem Softwareprojekt ergibt sich
daher das gleiche Problem: Anwender und Entwickler missverstehen sich häufig bei der
Formulierung der Anforderungen, weil sie keine gemeinsame Sprache besitzen, die
präzise genug die fachlichen Aussagen der Anwender und die technischen Festlegungen
der Entwickler erfasst. Daher müssen die Entwickler die Aussagen der Anwender immer übersetzen, wobei sie ihr eigenes, unzureichendes Verständnis des Anwendungsgebietes benützen. Im Ergebnis haben nun Anwender und Entwickler jeweils eine sehr
konkrete Vorstellung von der zu erstellenden Software, allerdings unterscheiden sich
diese Vorstellungen voneinander, so dass schließlich auch die erstellte Software den
Erwartungen der Anwender nicht gerecht wird.
Eine moderne Antwort der Informatik auf dieses Problem heißt inkrementelle Entwicklung12: Wenn es unmöglich ist, dass sich Anwender und Entwickler von Anfang an über
die gewünschte Software präzise verständigen, dann sollten wenigstens die Missverständnisse und Unsicherheiten so früh wie möglich erkannt, beseitigt und Folgefehler
vermieden werden. Die Entwicklung der Software verläuft daher in Iterationen, in denen jeweils ein kleiner Teil der Software, ein Inkrement zur vorhergehenden Version,
fertig gestellt und den Anwendern übergeben wird. Die Rückmeldung der Anwender
fließt dann direkt in die Entwicklung der nächsten Iteration ein, notwendige Änderungen können zeitnah durchgeführt werden.
Mit dieser Organisationsform sind die Anwender selbst aktiv in den Entwicklungsprozess eingebunden. Sie sind nicht nur Auftraggeber, sondern gestalten die Software im
Entstehen mit. Die Methode des Extreme Programming führt diesen Gedanken weiter,
indem sie die Rechte und Pflichten der Anwender und Entwickler explizit macht.13
Die Anwender treffen im Projekt grundsätzlich alle Entscheidungen, die den Wert der
Software für sie selbst betreffen. Sie geben den benötigten Umfang, die genaue Funktionalität und den Zeitpunkt der Abgabe vor. Die Funktionalität teilen sie dabei in möglichst unabhängige Elemente ein, so genannte Features, und geben für jedes Feature
auch die Wichtigkeit an, die sie ihm beimessen. Es sind auch die Anwender, die entscheiden, welche Features überhaupt und in welcher Reihenfolge realisiert werden. Bei
der Planung einer Iteration erstellen die Anwender so genannte Story Cards, die jeweils
ein wünschenswertes Feature aus Sicht des Anwenders beschreiben. Der Begriff „Card“
ist wörtlich zu nehmen: Die Beschreibung soll auf eine mittelgroße Karteikarte passen,
sie muss nicht vollständig sein, sondern ist nur „eine Übereinkunft, dass Anwender und
12
13
Vgl. Sommerville 2007, Kapitel 17.
Vgl. Beck 2000, Kapitel 14; Beck/Fowler 2001, Kapitel 4; vgl. auch Sommerville 2007, Kapitel 17.
Einleitung
23
Entwickler über dieses Feature sprechen werden.“14 Zu Beginn des Projektes entscheiden die Anwender über die zu verwendenden Softwareprodukte, weil dadurch häufig
organisatorische Rahmenbedingungen berührt sind: Die Kosten für Lizenzen, die Schulung der Anwender, die vorhandene Hard- und Software-Landschaft müssen mitbedacht
werden, wenn sich die neue Software in die Arbeitsprozesse einfügen soll.
Die Entwickler sind allein verantwortlich für alle technischen Aspekte der Realisierung.
Sie haben damit zwei Aufgaben im Planungsprozess: Zunächst geben sie für jedes Feature eine Schätzung ab, wie viel Aufwand die Realisierung bedeuten würde. Aufgrund
dieser Information entscheiden dann die Anwender über die Reihenfolge der Realisierung. Im Hintergrund dieser Aufteilung steht das Ziel, dass sich die Anwender über den
benötigten Aufwand bewusst werden, damit nicht die Entwickler allein vor der Aufgabe
stehen, mit begrenzten Ressourcen unbegrenzte Wünsche umsetzen zu müssen. Da sich
die Entwickler auf ihre bisherigen Erfahrungen verlassen müssen, dürfen sie ihre Schätzung während der Entwicklung noch korrigieren, woraufhin die Anwender ihre Entscheidungen revidieren dürfen. Die zweite große Aufgabe der Entwickler ist die Offenlegung von technischen Konsequenzen, die sich aus den Entscheidungen der Anwender
ergeben. Das Entwicklerteam plant dazu die Umsetzung einer Story Card, indem es
mehrere Task Cards erstellt. Während die Story Card das Feature aus Anwendersicht
beschreibt, halten die Task Cards die technischen Erweiterungen und Änderungen an
der Software fest, die zur Realisierung notwendig sind. Relativ häufig kommt es dabei
zu Situationen, in denen andere Story Cards indirekt dadurch betroffen sind, dass ihre
Realisierung einfacher, schwieriger oder sogar undurchführbar wird. Auf solche Konsequenzen müssen die Entwickler die Anwender hinweisen, denn hier ist die Entscheidungskompetenz der Anwender berührt.
Es ist an dieser Stelle sinnvoll, umgekehrt einmal aufzuzeigen, welche Kompetenzen
die beiden Gruppen gerade nicht besitzen sollten, denn in gescheiterten Projekten haben
oft gerade diese falsch zugestandenen Kompetenzen zum Misserfolg geführt. Die Anwender dürfen keinesfalls gleichzeitig den Umfang und den Zeitpunkt der Fertigstellung
eines Features vorgeben, denn den Aufwand können nur die Entwickler einschätzen.
Wenn Entwickler gezwungen werden, zu schnell Ergebnisse zu liefern, werden sie beinahe unweigerlich fehlerhafte, unzuverlässige Software erstellen. Die Anwender dürfen
weiterhin die technischen Interna der Software nicht festlegen, denn fachlich nicht fundierte Entscheidungen behindern später die Entwickler. Umgekehrt treffen die Entwickler niemals Entscheidungen über Features der Software, über die relative Wichtigkeit
von Features und die Zeitplanung des Projektes. Dieser Punkt bezieht sich direkt auf die
frühere Feststellung, dass die Entwickler normalerweise nicht über das Fachwissen
verfügen, um Konsequenzen im Bereich der Features richtig einzuschätzen. Darüber
hinaus neigen Entwickler dazu, technisch interessante und herausfordernde Features zu
bevorzugen, wodurch sie den Aufwand nicht immer dort investieren, wo er dem Anwender am meisten Nutzen bringt. Schließlich treffen die Entwickler niemals selbst
Entscheidungen über die verwendeten Softwareprodukte: Sie können und sollen den
Anwendern die möglichen Alternativen und deren Konsequenzen aufzeigen, aber es
14
Beck/Fowler 2001, S. 46.
24
Einleitung
sind letztlich die Anwender, die mit der getroffenen Entscheidung über Jahre leben
müssen. Diese Einsicht wird leider gerade in solchen Projekten vernachlässigt, in denen
die Anwender das Gefühl haben, technisch wenig kompetent zu sein und deshalb den
Entwicklern „freie Hand“ lassen. Die Entwickler werden dann ohne Rücksicht auf die
Interessen der Anwender diejenigen Werkzeuge auswählen, mit denen sie aufgrund
ihrer Ausbildung oder sonstigen Erfahrung am meisten vertraut sind – häufig sind das
leider gerade solche Produkte, die nur von technisch versierten Benutzern überhaupt
bedient werden können.
Diese Kompetenzverteilung in allgemeinen Softwareprojekten lässt sich leicht auf den
Spezialfall von Datenbankanwendungen übertragen. Besonders die Trennung zwischen
fachlicher und technischer Entscheidungskompetenz fügt sich gut in die Schichtenarchitektur für Datenbanken ein: Direkt relevant für die Anwender ist zunächst die Benutzerschnittstelle, durch die sie mit der Datenbank interagieren. Die Entscheidung über benötigte Eingabemasken und Übersichtsfunktionalität liegt daher bei ihnen. Da sich
praktisch das Problem stellt, dass unerfahrene Anwender nicht einschätzen können,
welche Masken überhaupt realisierbar sind, können die Entwickler hier Beispiele und
Hinweise geben, wobei sie sich streng am Anwendungsbereich, nicht an der technisch
einfachsten Variante, orientieren. Die Entwickler sollten dabei die Anwender ermuntern, zunächst frei ihre Wunschvorstellung zu artikulieren und die Einschätzung über die
Realisierbarkeit den Entwicklern zu überlassen.
Das konzeptuelle Datenmodell steht im Zentrum des Projektes, indem es die größten
Herausforderungen an die Kommunikation zwischen Anwendern und Entwicklern stellt.
Gleichzeitig wird hier am deutlichsten, wie sich fachliche und technische Kompetenzen
ergänzen müssen, um eine funktionsfähige Datenbank zu erhalten. Die Anwender geben
vor, welche Informationen aufgrund der vorliegenden Quellen und zu bearbeitenden
Forschungsfragen überhaupt in die Datenbank aufgenommen werden müssen, damit der
Datenbestand später für sie „wertvoll“ ist. Vor allem aber können sie die Bedeutung der
einzelnen gespeicherten Daten aus historischer Sicht präzise benennen und die inhaltlichen Querbezüge zwischen den Daten nachvollziehen. Sie müssen daher darüber wachen, dass das Datenmodell aus fachlicher Sicht verständlich ist und sie die gespeicherten Daten sinnvoll interpretieren können. Die Entwickler hingegen beherrschen die
Datenmodellierung und übersehen auch die Konsequenzen in der Realisierung. Es ist
daher ihre Aufgabe, den Wunsch, Informationen zu verwalten, in konkret zu speichernde Daten umzusetzen. Dazu erstellen sie das konzeptuelle Modell und erläutern es dem
Anwender. Wichtig ist jedoch, dass sie nicht selbst über das Modell entscheiden. Sie
zeigen nur die aus ihrer Sicht möglichen alternativen Modelle auf und machen die Konsequenzen deutlich, die sich für die Anwendung der Datenbank im Projekt ergeben.
Aufgrund dieser Information entscheiden dann die Anwender, wie das Modell im Einzelnen auszusehen hat.
Zusammenfassend gesagt beruht der Erfolg historischer Datenbankprojekte letztlich auf
den sich ergänzenden, komplementären Kompetenzen von Anwendern und Entwicklern: Die Historiker können die Anforderungen beschreiben und die fachlichen Konsequenzen von Entscheidungen einschätzen, die Entwickler hingegen beherrschen die
technische Umsetzung und können technische Konsequenzen und die sich daraus erge-
Einleitung
25
benden Implikationen für die Benutzung überschauen. Die beiden Gruppen kommunizieren so lange über Zwischenergebnisse, Fehleinschätzungen und Änderungswünsche,
bis die Datenbanksoftware den Anforderungen der Anwender genügt und die Dateneingabe beginnen kann.
Die geschilderte Rollenverteilung zeichnet sich vor allem durch Symmetrie aus: Keine
der Gruppen hat einen stärkeren oder gar alleinigen Einfluss auf bestimmte Aspekte der
entstehenden Software, alle Entscheidungen werden nach Austausch über die Folgen
getroffen. Wenn dies der Idealzustand ist, ergibt sich im Umkehrschluss, dass eine häufig anzutreffende Projektorganisation beinahe sicher zum Scheitern verurteilt ist: Die
Datenbank kann nicht von Hilfskräften erstellt werden, während sich die Forscher von
der technischen Seite vollständig distanzieren. Die Verwendbarkeit der Datenbank und
die Verlässlichkeit der Forschungsergebnisse selbst hängen wesentlich davon ab, dass
das Fachwissen der Historiker in die Erstellung der Datenbank im Detail einfließt und
die wesentlichen Entscheidungen über den Inhalt und die Funktion der Datenbank aufgrund von fachlichen, nicht von technischen Kriterien, getroffen werden.