Digital resources in the Social Sciences and Humanities OpenEdition Our platforms OpenEdition Books OpenEdition Journals Hypotheses Calenda Libraries OpenEdition Freemium Follow us

Datenbankaufbau und -design

Zur Verwaltung der Datenmengen, die bei der Digitalisierung der Akten und bei der Meldeamtsrecherche anfallen, musste eine Datenbankmanagementsoftware gefunden werden, die folgende Bedingungen erfüllt:

  • Sie soll größere Datenmengen verwalten können, beispielsweise mehrere zehntausend Bilddateien.
  • Sie soll einfach zu bedienen und schnell zu erlernen sein.
  • Sie soll bei einer Fortsetzung der Digitalisierung Möglichkeiten zur Datenaufbereitung und Datenausgabe bieten und dabei skalierbar sein.
  • Sie soll für mehrere Benutzer nutzbar sein und eine fein steuerbare Rechteverwaltung beinhalten.
  • Sie soll günstig in den Entwicklungskosten sein.
  • Sie soll weitgehende Exportmöglichkeiten bieten, damit bei wechselnden Anforderungen andere Software genutzt werden kann.

Verschiedene Software- bzw. Datenbanklösungen wurden bereits bei Costa (2005)1 mit Vor- und Nachteilen diskutiert. Die Entscheidung fiel in diesem Projekt für die Datenbankmanagementsoftware Filemaker Pro 122. Vorteilhaft ist, dass die Einrichtung einfacher als bei Datenbanksprachen wie PHP auf Basis vom Datenbanksystem SQL zu erlernen ist. Die Ausgabefunktionen sind für die vielseitigen Ansprüche denkbar gut geeignet, beispielsweise die Ausgabe von Serienbriefen, die Erstellung von Diagrammen und der Export der Daten als Webseite, als Excel-Datei oder per ODBC-Anbindung an SQL-Datenbanken. Die Anschaffungskosten waren durch die flache Lernkurve im Vergleich niedriger zu den Kosten für die Einstellung eines ausgebildeten PHP-Entwicklers. Filemaker lässt sich um Serverkomponenten erweitern, welche die Nutzung als Multi-User-System ermöglichen. Es lässt sich mit Filemaker ein Web-Interface anbieten, dass einen rechtebasierten Online-Zugriff auf die Daten ermöglicht, ein Vorteil im Hinblick auf eine mögliche spätere Vernetzung mit Forschern an unterschiedlichen Standorten.

Ein Nachteil ist, dass Filemaker auf ein eigenes, monolithisches Dateiformat setzt (d.h. Layout und Daten werden in der gleichen Datei gespeichert), dabei lassen sich jedoch die Daten selbst beliebig exportieren, Skripte und Layouts jedoch nicht. Der Export von Skripten ist bei anderen Lösung ebenso nur bedingt möglich. Ein weiterer Nachteil kann sein, dass eine Abhängigkeit vom Entwickler entsteht. Diese Gefahr besteht bei allen Datenbanksystemen aufgrund der rasch entstehenden Komplexität und der speziellen Skripte, die nur in einer Programmiersprache funktionieren. Die folgende Dokumentation der Datenbank und die Weitergabe des Wissens an die anderen Mitarbeiter ist daher von hoher Bedeutung.

Filemaker existiert in Versionen sowohl für Windows als auch für Mac, aber die Layouts z.B. zur Erstellung von Serienbriefen können auf den verschiedenen Systemen unterschiedlich dargestellt werden, beispielsweise wegen fehlender Schriftarten oder unterschiedlicher Standardzeichengrößen in den Betriebssystemen. Die Lösung für dieses Problem besteht darin, Layouts speziell für ein Betriebssystem zu entwickeln und ggfs. doppelt vorzuhalten, jeweils in einer Version für Windows und in einer Version für MacOS.

Auf SQL-basierte Lösungen wurde wegen des hohen Lernaufwands und der dadurch entstehenden Verzögerungen verzichtet. Einfache Datenbankmanagementsysteme („Out-of-the-Box“-Systeme) oder Tabellenkalkulationsprogramme, die bei Costa3 empfohlen wurden, würden wiederum sehr schnell an Grenzen stoßen und keine nachhaltige Weiterentwicklung der Datenbank im Laufe eines Projekts ermöglichen.

Beim Aufbau der Datenbank wurde direkt bei Beginn eine Backup-Strategie entwickelt und Maßnahmen zur Sicherung des Datenschutzes umgesetzt. Letzteres resultierte sowohl in einem Rechtemanagement und Passwortschutz der Datenbank, als auch in einer Trennung von alten Aktennummern (und damit verbunden, der alten Adressen sowie weiterer personenbezogenen Informationen aus den Akten) und neuen Personennummern (für die aktualisierten Adressen).

Sobald die Stichprobenreaktivierung abgeschlossen ist, wird die relationale Verknüpfung dieser beiden Nummern wieder getrennt. Danach ist eine Zuordnung von alten Untersuchungsakten zu aktuellen Adressen nur noch in den Fällen möglich, bei denen eine Zustimmung vorliegt. Alle anderen personenbezogenen Daten für deren Verarbeitung keine Zustimmung vorliegt, werden bei Abschluss der Reaktivierung dauerhaft gelöscht bzw. vernichtet.

Übersicht über die Datenbankstruktur und die enthaltenen Variablen

Übersicht über die Datenbankstruktur und die enthaltenen Variablen

Quelle: Foerster, S. (2013). Von den „Deutschen Nachkriegskindern“ zu einer Längsschnittstudie der Entwicklung über die Lebensspanne. Evaluation der Methodologie einer Stichprobenreaktivierung (Diplomarbeit). Rheinische Friedrich-Wilhelms-Universität, Bonn, S. 23-25.

  1. Costa, R. (2005). Von der „Deutschen Nachkriegskinder-Studie“ zu einer Längsschnittstudie des Erwachsenenalters – theoretische und methodologische Probleme der Stichprobenrevitalisierung. Magisterarbeit, Bonn. []
  2. FileMaker. (2013). Datenbank-Software. FileMaker 12 Pro. Abgerufen 4. August 2013, von http://www.filemaker.de/ []
  3. Costa, R. (2005). Von der „Deutschen Nachkriegskinder-Studie“ zu einer Längsschnittstudie des Erwachsenenalters – theoretische und methodologische Probleme der Stichprobenrevitalisierung. Magisterarbeit, Bonn. []

OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Sascha Foerster (26. Juli 2016). Datenbankaufbau und -design. Deutsche Nachkriegskinder rev. Abgerufen am 14. Oktober 2024 von https://doi.org/10.58079/vc56


Das könnte dich auch interessieren …

Schreibe einen Kommentar

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.