Wie Genealogie-Programme die Daten verwalten

Datenbank vs. Datenbank

Eine Datenbank ist nicht gleich Datenbank.

Genauso wie ein Auto nicht gleich Auto ist.

Es gibt Personenwagen für 2 Personen und auch welche für 7 Personen.
Im Prinzip ist ein Bus auch ein Personenwagen.

Ebenso gibt es Autos die für den Transport von Lasten ausgelegt sind.

Diese Unterschiede kann man genauso auf Datenbanken beziehen.

Wer noch mit Windows zu Zeiten von 3.1 gearbeitet hat, kennt vielleicht noch den Karteikasten. 

Auch das war im Prinzip eine Datenbank.

Die erste Form der Genealogischen Datenbanken war das GedCom-Format.

PAF nutzte dieses Format um die Daten für den Export zu FamilySearch ermöglichen zu können.

Diese Art war einfach aufgebaut um Personen, Familien und deren Beziehungen darstellen zu können.

Mit der Zeit wuchsen die Ansprüche an Genealogie-Programme.

Daten sollten grafisch dargestellt werden, oder in Buchform ausgegeben werden.

Vor allem bei großen Genealogien ist ein textbasiertes Datenbanksystem nicht so gut für die Verwaltung geeignet.

Nun gibt es im Computerbereich unterschiedliche Arten für die Verwaltung von Daten.

Sequentielle Datenbanken

Fast jeder hat schon mit Excel- oder OpenOffice-Tabellen gearbeitet.

Man kann diese Tabellen mit Karteikästen vergleichen, bei denen die einzelnen Zeilen den Karteikarten entsprechen.

Das Problem bei diesen Tabellen aber ist, sowie ich immer gleiche Daten habe, müssen diese auch immer gleich eingegeben werden.

Schauen wir uns ein Beispiel an.

Wir bearbeiten einen kleinen Ort, um ein Ortsfamilienbuch zu erstellen.

Dieser Ort, nennen wir ihn ‚Nirgendwo‘, ist ein Teilort der Gemeinde ‚Irgendwo‘.

Wenn wir nun die Personen zeilenweise erfassen, haben wir in der Masse der Personen diesen Ort in den Ereignissen einzugeben. Wir haben also jeweils eine Spalte bei der 

  • Geburt
  • Taufe
  • Tod
  • Beerdigung

sowie bei diversen Ereignissen die wir zusätzlich erfassen.

Keiner von uns ist davor gefeit diesen Ort immer richtig zu schreiben. 

Haben wir bei durchschnittlichen Genealogien von vielleicht 2-3000 Personen, so haben wir den Ort in der Regel mindestens 8-10.000 mal erfasst.

wenn nur 5% davon Fehleingaben sind, kommen wir immerhin auf ca 4000 falsche Orte.

(Alles nur grob überschlagen)

Filtere ich nun die Daten nach dem Ort ‚Nirgendwo‘ fallen alle Falscheingaben aus dem Filter raus und werden nicht angezeigt.

Dieses Beispiel können wir beliebig für andere Eingaben anwenden.

Und hier noch ein weiterer, noch größerer Nachteil von Sequentiellen Daten.

Wenn man nicht nur Personen, sondern auch die Familien erfassen möchte, wird es richtig kompliziert.

Sie geben die Personen mit ihren Ehepartnern ein. Was ist wenn eine der Personen mehrmals geheiratet hat?

Geben Sie die Person dann mehrmals mit allen ihrer Daten neu ein?

Was ist mit den Eltern? Was mit den Kindern? Und wie stellen Sie die Verbindung der Kinder mit ihren Eltern und Großeltern her.

Alle diese Fragen hat sich mit Sicherheit jeder schon einmal gestellt.

Selbst für eine reine Verkartung von Kirchenbüchern ist diese Methode nur bedingt geeignet.

Hier kommt jetzt der Vorteil der relationalen Datenverwaltung ins Spiel.

Relationale Datenbanken

Wollen wir doch erst mal erklären was sich hinter diesem Begriff verbirgt.

Was sagt uns Wikipedia dazu?

Eine relationale Datenbank ist eine digitale Datenbank, die zur elektronischen Datenverwaltung in Computersystemen dient und auf einem tabellenbasierten relationalen Datenbankmodell beruht. Grundlage des Konzeptes relationaler Datenbanken ist die Relation. Sie stellt eine mathematische Beschreibung einer Tabelle dar und ist ein im mathematischen Sinn wohldefinierter Begriff; siehe Datenbankrelation. Operationen auf diesen Relationen werden durch die relationale Algebra bestimmt.

Das zugehörige Datenbankmanagementsystem wird als relationales Datenbankmanagementsystem oder RDBMS (Relational Database Management System) bezeichnet. Zum Abfragen und Manipulieren der Daten wird überwiegend die Datenbanksprache SQL (Structured Query Language) eingesetzt, deren theoretische Grundlage die relationale Algebra ist.

Das hört sich zunächst komplizierter an, als es in Wirklichkeit ist.

Stellen wir uns vor wir hätten 2 Karteikästen. In dem einen sind die Karteikarten für die Personen. Im anderen Kasten haben wir Karteikarten für die Orte.

Wenn wir nun in den Kasten für die Personen eine neue Karte ablegen verbinden wir nun die Person mit Hilfe eines Bandes mit der Karteikarte des Ortes.

Ziehen wir nun eine Person aus dem Karteikasten, kommt automatisch der Ort aus seiner Kiste.

Ziehen wir einen Ort aus seinem Kasten, kommen alle Personen, die mit dem Ort verknüpft sind, ebenfalls aus ihrem Kasten. 

Das entscheidende dabei ist, in beiden Tabellen benötigen wir korrespondierende Einträge.

Jeder Eintrag in eine Tabelle benötigt einen sogenannten ‚eindeutigen Schlüssel‘.

In unserer Ortstabelle ist dies dir ‚OrtNr‘. Diese darf in der Tabelle nur einmal vorkommen.

In der Personen-Tabelle wird nun nicht der Ort eingetragen, sondern lediglich die ‚OrtNr‘.

Man nennt dies eine 1:n Verknüpfung. Ein Ort kann mit beliebig vielen Personen verknüft sein.

Noch komplizierter wird es wenn zum Beispiel eine Person mehrere Berufe hat.

Natürlich kann man die Tabelle der Person mit mehreren Spalten für Berufe erstellen. Nur wie soll man nach den Berufen suchen?

In Spalte Beruf1, Beruf2 usw.

Wie viele Berufe kann eine Person haben?

Ich habe zum Beispiel in meinem Leben bisher mehr als 5 Berufsbezeichnungen gehabt.

Und da ein Beruf auch von mehr als einer Person ausgeführt werden kann, muss das in der Struktur der Datenbank mit berücksichtigt werden.

Dies wird mit einer sogenannten m:n Verknüpfung realisiert.

Man kann sich also vorstellen, dass je mehr Daten erfasst, je mehr Ereignisse aufgenommen werden umso mehr Verknüpfungen in einer solchen Datenbank vorhanden sind.

Der große Vorteil einer relationalen Datenbank ist auch, dass Abfragen recht zügig ausgewertet werden.

Natürlich gibt es bei solchen Systemen auch Unterschiede.

Je größer die Datenmenge ist, und je schneller solch ein System arbeitet, vor allem wenn mehrere Personen gleichzeitig an einer solchen Datenbank arbeiten.

Die Preise solcher Systeme können je nach Anforderung und Herstelle sehr schnell in einen 6 stelligen Eurobereich gehen.

Aber es gibt auch Systeme die kostenlos sind.

  • Firebird
  • MySQL
  • MariaDB
  • und auch die ‚Internal Database‘ von Windows

Aber natürlich sind diese kostenlosen Systeme bei weitem nicht so Leistungsfähig wie kommerzielle Systeme, was für uns auch keine so große Rolle spielt.

Da aber die Programmierer von Genealogieprogrammen, so sie denn ihr Programm auf relationale Datenbanken aufsetzen, unterschiedliche Systeme einsetzen, ist der Austausch von Daten doch recht kompliziert.

Datenaustausch zwischen Genealogieprogrammen

In einem anderen Artikel habe ich mich schon einmal über das Austauschen von Daten mit GedCom ausgelassen.

Hier soll es nun mal aus der Sicht der Programmierer geschehen.

 

Da alle Daten im GedCom-Format bestimmten Tags zugeordnet werden müssen. Und dabei auch noch eine bestimmte Reihenfolge beachtet werden muss, ist dies für den Programmierer eine regelrechte Sisyphos-Arbeit.

Es gibt immer einen Tag auf Ebene 1. Alle dazugehörigen Daten müssen in der nächsten Ebene angesiedelt werden. Je tiefer die Verschachtelung, umso mehr Ebenen werden benötigt.

Der Export muss also alle Daten GedCom-Konform erstellen.

Noch komplizierter wird es dann beim Import aus anderen Programmen.

Die Verbindungen die in der GedCom Datei nur rudimentär abgebildet werden (@Ziffer@) müssen in die eigenen Tabellen übernommen werden. Des weiteren muss das Programm beim Import prüfen welche Daten wie und wo im eigenen Datenbankschema abgelegt werden. 

Je komplexer das Schema ist, umso länger dauert es natürlich bis die Daten importiert sind.

Man kann also sagen:

Programme mit flachen Strukturen importieren Daten schneller als Programme mit komplexen Strukturen.

Aber je flacher eine Struktur ist, umso anfälliger für Fehleingaben ist sie.

Es ist also nicht immer ein Hinweis auf ein ’schlechtes‘ Programm wenn der Import länger dauert.

Ein Programm das viele Funktionen anbietet und vielseitig eingesetzt werden kann, muss komplex in seiner Datenbehandlung sein um ein optimales Ergebnis erzielen zu können.

Schreiben Sie einen Kommentar

Consent Management mit Real Cookie Banner