Datenbank: Warum denn das?

Ich bin ja immer etwas überrascht, was mir so unter dem Begriff „Datenbank“ in meinem bisherigen Historikerleben begegnet ist. Da ist vieles dabei, was wirklich eine Datenbank ist – aber auch vieles, was noch nie eine Datenbank war.

Ich bin freundlich und lasse Excel gerade noch durchgehen. Da stimmt die Idee, der Ansatz und die Exportfunktion (OpenOffice, LibreOffice, Numbers sind auch gemeint).

Was generell zu beobachten ist, ist, dass für die lokale Installation eigentlich nur Access und Open-/LibreOffice mitwachsen und einigermaßen eine Chance auf ein langes Leben hatten. Eigentlich recht gute Dinge wie Filemaker gehören inzwischen zur Computerarchäologie (und die Marke immerhin noch zu Apple) gehören. Die Daten bekommt man aus proprietärer Einzelplatz-Software in der Regel nie wieder raus, wenn man nicht rechtzeitig in offene Standardformate exportiert hat. 

Ich will daher dafür plädieren, den Begriff Datenbank für eine Software zu verwenden, die Daten strukturiert speichern und als Antwort auf eine Abfrage in einer endlichen Zahl an Datensätzen für eine Treffermenge auch wieder zurückzugeben. Und ich will dafür plädieren, darunter inzwischen auch vorrangig eine Serveranwendung zu verstehen. Wenn man sich die Moden über die letzten 20 Jahre mal betrachtet, dann sind alle Arten von SQL-Dialekten, die als Datenbankserver so am Markt waren, heute noch irgendwie lauffähig zu machen. Die Portierbarkeit, die Nachhaltigkeit und zumindest die Möglichkeit, eine Datenbank potenziell über lokales Netzwerk oder Internet zu öffnen, sprechen für einen „Standard“-Datenbankserver, selbst wenn er lokal auf einem Laptop läuft und nie Verbindungen jenseits von „localhost“ annehmen soll (oder qua Konfiguration darf).

Die meisten Daten der historischen Forschungsarbeit lassen sich hervorragend als relationale Datenbank abbilden (nicht zuletzt machen Werkzeuge wie Citavi genau das – Citavi-Projektdateien sind SQLite-Datenbanken). Überall, wo man von einem Objekt x eine beliebige Anzahl von Objekten des Typs y und eine andere beliebige Anzahl vom Typ z zuordnen kann, ist eine relationale Datenbank ein gutes Werkzeug.

Verfolgen wir also z.B. eine historische Person in Quellen, finden Belege über ihren (wechselnden) Wohnsitz, ihre Meldung in Melderegistern, dann ist zweckmäßig, einen Datensatz vom Typ „Person“ zu pflegen, und darauf mehrere Datensätze für recherchierte Wohnsitze und deren offizieller Nachweis durch Melderegister aus einer zweiten Tabelle für „Wohnungen“ heranzuziehen. Jetzt gewinnen wir einen logischen Vorteil: Wir können den Verlauf der Wohnsitze nachvollziehen und dabei jeden einzelnen Wohnsitz unmittelbar zu identifizieren. Wir könnten sogar einen ehemaligen Wohnsitz von Person A einer Person B zu einem anderen Zeitpunkt zuweisen. Dieses Konzept nennt man gemeinhin „Nachmieter“, und mit diesem kleinen Schritt haben wir nicht nur etwas Abstraktion von Daten erreicht, sondern auch die Chance, weitergehende Erkenntnisse aus den gesammelten Daten zu gewinnen. Und genau das soll der Einstieg für dieses Blog werden…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*