Stammbaum-Erzeugung

[hansklok]

Hallo,

ich habe hier schon sehr oft, sehr erfolgreich Hilfe von Euch erhalten. Danke dafür. Und heute versuche ich es wieder.

Geplant ist die Erstellung einer Genealogie-Anwendung, in der Benutzer ihre Stammbäume verwalten können. Die Daten sollen in einer Datenbank gespeichert werden (SQLite) mit folgenden Tabellen (sehr vereinfachtes Schema, da es um den Grundaufbau gehen soll):

Persons

• Gender: Varchar
• Name: Varchar
• StartPerson: Boolean

Families

• PartnerA: Integer
• PartnerB: Integer

Children

• FamilyID: Integer
• PersonID: Integer
• Order: Integer

StartPerson kann zur Laufzeit im Programm jeder x-beliebigen Person in der Personen-Tabelle zugewiesen werden (beispielsweise über eine ListBox, die alle Personen abbildet), jedoch darf nur eine Person diesen True-Wert erhalten. Ausgehend davon, welche Person aktuell als StartPerson selektiert ist, soll dann vermutlich durch eine Baumstruktur, der Stammbaum erstellt werden. Dabei gibt es den Probanden (Root-Knoten) und zu diesem sollen nun rekursiv alle Verwandten aus der Datenbank ausgelesen werden (Vater, Mutter, Kinder, Geschwister, Partner(innen)). Diesen wiederum sollen solange alles Verwandten ausgelesen werden, bis es keine Verknüpfungen mehr gibt. Genau da hakt mein Denkansatz, da ich keinerlei Ahnung habe, wie ich das rekursiv umsetzen soll. Geplant ist nämlich eine Art Verwandtschaftsrechner, der ausgehend von der StartPerson zu einer x-beliebigen anderen Person der Personen-Tabelle den Verwandtschaftsgrad ausgibt (Sohn/Tochter, Frau/Mann, Großmutter/-vater, Urgroßmutter/-vater, Neffe, Enkel etc.), vorausgesetzt, es gibt ein Verwandtschaftsverhältnis. Wie könnte sich das Umsetzen lassen, wie schaut solch eine Datenstruktur aus bzw. ist der Datenbankansatz der richtige?

Fragt mit dankenden Grüßen,

hansklok

[jobo]

Ich würde sagen, du sammelst die Herkunftsknoten nach oben (Richtung Oppa&Omma) der beiden Personen und prüfst, ob es einen identischen Knoten gibt.
Wie das sql technisch aussieht, hängt von der konkreten Implementiernug des Stammbaums ab.

[hansklok]

Zitat:

Zitat von jobo (Beitrag 1317906)

Ich würde sagen, du sammelst die Herkunftsknoten nach oben (Richtung Oppa&Omma) der beiden Personen und prüfst, ob es einen identischen Knoten gibt.
Wie das sql technisch aussieht, hängt von der konkreten Implementiernug des Stammbaums ab.

Kannst Du das bitte etwas ausführlicher erläutern?

[mkinzler]

Die Startperson gehört nicht zum Objekt Person.
Families würde ich PartnerShip o.ä. nennen, da eine Familie ja weiter gefasst ist.
Children besser ParentShip ( im Sinne ist Kind von: Person -> Person). Diese würde ich auch unabhängig von PartnerShip modellieren ( unehelige Kinder, Alleinerziehende usw.)

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1317912)

Die Startperson gehört nicht zum Objekt Person.
Families würde ich PartnerShip o.ä. nennen, da eine Familie ja weiter gefasst ist.
Children besser ParentShip ( im Sinne ist Kind von: Person -> Person). Diese würde ich auch unabhängig von PartnerShip modellieren ( unehelige Kinder, Alleinerziehende usw.)

Es würde sicb als Begrifflichkeit Zeugungsgemeinschaft anbieten. Und wenn man das Vormittagsprogramm auf den privaten Sendern anschaut, so legt man dort eine 1:n Struktur dahinter :mrgreen:

[hansklok]

Zitat:

Zitat von mkinzler (Beitrag 1317912)

Die Startperson gehört nicht zum Objekt Person.

In dem Falle hast Du recht, aber da die Daten nur in der SQLite-Tabelle gespeichert werden und bei einem erneuten Programmaufruf die StartPerson automatisch gezeigt werden soll, muss ich sie ja irgendwo kenntlich machen und abspeichern. Deshalb :)

Zitat:

Families würde ich PartnerShip o.ä. nennen, da eine Familie ja weiter gefasst ist.
Children besser ParentShip ( im Sinne ist Kind von: Person -> Person). Diese würde ich auch unabhängig von PartnerShip modellieren ( unehelige Kinder, Alleinerziehende usw.)

Die Namensgebung ist im Moment zweitrangig, ich weiß, was Du meinst. Es gibt einen zugrundeliegenden Standard, @Sir Ruf kennt ihn aus älteren Beiträgen. Er heißt GEDCOM-Standard. Alleinerziehende Familien werden einfach durch Auslassen eines der beiden Partner gekennzeichnet (Wert -1 beispielsweise).

[mkinzler]

Zitat:

In dem Falle hast Du recht, aber da die Daten nur in der SQLite-Tabelle gespeichert werden und bei einem erneuten Programmaufruf die StartPerson automatisch gezeigt werden soll, muss ich sie ja irgendwo kenntlich machen und abspeichern. Deshalb

Aber nicht bei jeder einzelnen Person. Besser in Ini/XML oder gesonderten Tabelle

[hansklok]

Zitat:

Zitat von mkinzler (Beitrag 1317917)

Zitat:

In dem Falle hast Du recht, aber da die Daten nur in der SQLite-Tabelle gespeichert werden und bei einem erneuten Programmaufruf die StartPerson automatisch gezeigt werden soll, muss ich sie ja irgendwo kenntlich machen und abspeichern. Deshalb

Aber nicht bei jeder einzelnen Person. Besser in Ini/XML oder gesonderten Tabelle

Eine gesonderte Tabelle mit dann immer nur einem Datensatz, der die StartPerson kennzeichnet? Ini/Xml bietet sich nicht an, da der Benutzer ja beliebig viele Familiengeschichten (Stammbaum-Datenbanken) aufzeichnen kann.

[mkinzler]

Mit eine Datensatz pro Stammblatt

[BUG]

Zitat:

Zitat von mkinzler (Beitrag 1317912)

Diese würde ich auch unabhängig von PartnerShip modellieren ( unehelige Kinder, Alleinerziehende usw.)

Potenziell lässt sich das alles als Ereignis modellieren. Damit lässt sich auch eine Menge Zusatzinformation unterbringen, die sonst oft null wäre.

Was macht jemand zum leiblichen Kind? Die Geburt, womöglich mit zwei bekannten biologischen Eltern und einem Datum.
Wie kommt das Kind in eine andere Familie? Durch eine Adoption, mit extra Datum und dem anderem Verwaltungskram.

Families ist schon eine 2er-Relation, ließe sich aber auch gut in Ereignisse umwandeln: Begin/Ende der Partnerschaft, Verlobung, Heirat/Trennung mit jeweils einem eigenem Datum.


Als Datensammlung/Archiv würde ich solche Ereignisse nützlicher finden als einen einfachen Baum. Wenn du diese ganzen Informationen erfassen kann, kannst du die dann natürlich nach Belieben zu einer traditionellen Baumansicht zusammenfassen.
BTW: Interessant wäre es auch, Ereignisse untereinander ordnen zu können ohne Zeitangaben zu kennen: z.B. A und B haben geheiratet vor C und D, B und D hatten ein Kind nach der der Heirat von E und F. Dazu passend wäre eine Unterstützung für Zeiträume: z.B. es ist bekannt das Herr A mit null/unbekannt zwischen 1960 und 1970 einen verschollenen Sohn hatten.

[Sir Rufo]

Wenn sich nichts grundlegend geändert hat, dann entstehen Kinder aus einer Verbindung von Mann und Frau.

Entgegen einiger Meinungen, muss diese Verbindung nicht zwangsläufig mit dem Prädikat "Ehe" oder "Beziehung" belegt sein. Sowas kann auch durch einen ONS entstehen. Wenn überhaupt, dann sind die Eltern ganz oder teilweise unbekannt. Das trifft auch auf Kinder von Alleinerziehenden zu.

@BUG Ich sehe, wir verstehen uns ;)

[hansklok]

Zitat:

Zitat von BUG (Beitrag 1317921)

Potenziell lässt sich das alles als Ereignis modellieren. Damit lässt sich auch eine Menge Zusatzinformation unterbringen, die sonst oft null wäre

Recht hast Du, dafür wird es aber eine extra Tabelle geben, die genau dies berücksichtigt. Es geht nur erst einmal um Partnerschaften. Eine Ehe, Scheidung, Adoption würde dann als Ereignis (inklusive Ort, Datum etc.) aufgenommen und mit dem Partnerschafts-/Personendatensatz verknüpft.

Also um es besser nachvollziehen zu können hier die gesamten geplanten Tabellen:

Personen

• Geschlecht: VarChar(1) // M, F, U
• Name: VarChar

Partnerschaften (ob mit oder ohne Kinder völlig egal)

• PartnerA: Integer
• PartnerB: Integer

Kinder

• PersonenID: Integer
• PartnerschaftsID: Integer
• Order: Integer

PersonenEreignisse (Geburt, Taufe, Tod, Bestattung, Konfirmation etc.)

• PersonenID: Integer
• Order: Integer
• Datum: Date
• Ort: VarChar

PartnerschaftsEreignisse (Ehe, Scheidung etc.)

• PartnerschaftsID: Integer
• Order: Integer
• Datum: Date
• Ort: VarChar

Sind aus einer Partnerschaft mehrere Kinder hervorgegangen, so sind diese automatisch, sofern sie nicht der Proband (StartPerson) sind als Geschwister anzuzeigen.
Ist die StartPerson Mitglied mehrerer Partnerschaften, so sind die jeweiligen Partner anzuzeigen, nicht nur einer!

[mikhal]

Zitat:

Es würde sicb als Begrifflichkeit Zeugungsgemeinschaft anbieten. Und wenn man das Vormittagsprogramm auf den privaten Sendern anschaut, so legt man dort eine 1:n Struktur dahinter

@Sir Rufo: Made my day!

Grüße
Mikhal

[ADelph]

...ich weiß nicht, ob es noch relevant ist...

Ich würde das weiter verallgemeinern. Ich würde eine Tabelle für Personen, eine für Ereignisse und eine für Relationen vorsehen. Relationen wären dann z.B. Familien, Partnerschaften, Kinder, Adoptivkinder (die ja ebenfalls Kinder von Personen sind) etc. Es kann also auch Relationen von Relationen geben, ebenso wie Ereignisse von/zu Relationen etc. Nach meinem Kenntnisstand sind Stammbäume eher Netze als Bäume, besonders wenn z.B. mehrfache (Quer-)Beziehungen auftreten können.

Ist nur eine Anregung...

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1317923)

Wenn sich nichts grundlegend geändert hat, dann entstehen Kinder aus einer Verbindung von Mann und Frau.

Nun, es soll auch schon Schwangerschaften durch Samenspende gegeben haben -> Mater semper certa est


Da ist die Frage wie weit man es treiben will, ebenso ist die rechtliche und die biologische Vaterschaft, nicht immer deckungsgleich.

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1318660)

Zitat:

Zitat von Sir Rufo (Beitrag 1317923)

Wenn sich nichts grundlegend geändert hat, dann entstehen Kinder aus einer Verbindung von Mann und Frau.

Nun, es soll auch schon Schwangerschaften durch Samenspende gegeben haben -> Mater semper certa est


Da ist die Frage wie weit man es treiben will, ebenso ist die rechtliche und die biologische Vaterschaft, nicht immer deckungsgleich.

Gruß
K-H

In der Genealogie spielt es keine Rolle, wie die Frau zum Kinde kam (ob direkt oder geschleudert ist also egal) und auch nicht wer rechtlich der Vater ist, sondern

Zitat:

Im weiteren Sinne bezeichnet Genealogie den genetischen Zusammenhang einer Gruppe von Lebewesen...

Ok, Maria stellt wohl eine besondere Ausnahme dar ... den Fall müsste man also ausklammern ;)

[jobo]

ot:

Zitat:

Zitat von p80286 (Beitrag 1318660)

Da ist die Frage wie weit man es treiben will..

Das bilden wir ja nur datentechnisch ab und überlassen die Details .. ach egal..
sorry, ich konnte nicht anders

[p80286]

Zitat:

Zitat von jobo (Beitrag 1318677)

ot:

Zitat:

Zitat von p80286 (Beitrag 1318660)

Da ist die Frage wie weit man es treiben will..

Das bilden wir ja nur datentechnisch ab und überlassen die Details .. ach egal..
sorry, ich konnte nicht anders

Solange noch jemand mit grinst:stupid:

Gruß
K-H

[hansklok]

So, jetzt melde ich mich mal wieder zu Wort, nachdem das Thema anfangs Richtung "Harz IV-TV" abgedriftet war.

JA, das Thema ist noch sehr relevant. Ich habe mich eben mal angesetzt und ein vereinfachtes Datenbank-Schema erstellt (siehe Anhang). Daraus sollte die Struktur ersichtlich sein. Ich habe mich genau für diesen Aufbau entschieden, da es für die Speicherung genealogischer Daten die Gedcom 5.5.1 Struktur gibt.

Meine Frage lautet wiederholt, wie sieht eine Datenbank-Abfrage zur Erstellung folgenden Baums aus (Beispiel) für die Vorfahren:

| Max Mustermann
| - Jonas Mustermann (Großvater)
| - Inka Mustertest (Großmutter)
| -- Hans Mustermann (Vater)
| --- Elke Musterfrau (Mutter)
| ---- Friedrich Mustermann (Bruder) // optional
| ---- Heike Mustermann (Schwester) // optional

bzw. für die Nachkommen:

| Max Mustermann
| - Martina Musterfrau (Partnerin)
| -- Elias Mustermann (Kind)
| -- Richard Mustermann (Kind)
| - Paula Musterdamm (Partnerin 2)

http://i57.tinypic.com/vhxl79.jpg

Anhang 44066

[BUG]

Zitat:

Zitat von hansklok (Beitrag 1318707)

wie sieht eine Datenbank-Abfrage zur Erstellung folgenden Baums aus (Beispiel) für die Vorfahren:

Um das in einem Schritt machen zu können, brauchst du rekursive SQL-Abfragen. Ein einfaches Beispiel findest du hier; leider auch die Erkenntnis das es erst ab SQLite 3.8.3 geht.

Ansonsten musst du dir halt rekursiv die nötigen Informationen abfragen.