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.