Familienverhältnisse - Problem mit Datenbankstruktur

[Jonas]

Hallo,
arbeite mit Win 98 und einer WAMP Umgebung.
Habe in meiner MySql Datenbank eine Tabelle mit "Menschen" und möchte nun jedem dieser "Menschen" seine familiären Verhältnisse zuordnen also Vater, Mutter, Grossväter, Grossmütter, Brüder, Schwestern, Enkel, etc....

Hat da jemand eine schlaue Idee wie man das macht ohne doppelte Datensätze zu erzeugen (ala Mensch 1 ist sohn von Mensch 2 - Mensch 2 ist Vater von Sohn 1)

Da gibt es sehr wahrscheinlich eine sehr einfache Lösung aber ich stehe total auf dem Schlauch (war aber auch eine lange Woche)

Danke und Grüße,
Jonas

[Sorgenkind Mech]

moinsen

aalso
die einfachste möglichkeit wäre doch zum beispiel in der tabelle menschen im feld "Vater" die ID (sofern vorhanden, ich hoffe doch ;) der person einzutragen, die in der tabelle der vater ist ........

und dann halt bei der abfrage dies zu berücksichtigen

hoffe es hilft, weiß nämlich nich genau, ob ich dein problem korrekt verstanden habe

gruß

[Jonas]

moinsen

Tach auch,

aalso
die einfachste möglichkeit wäre doch zum beispiel in der tabelle menschen im feld "Vater" die ID (sofern vorhanden, ich hoffe doch ;) der person einzutragen, die in der tabelle der vater ist ........

und dann halt bei der abfrage dies zu berücksichtigen

hoffe es hilft, weiß nämlich nich genau, ob ich dein problem korrekt verstanden habe

nich so ganz habe in der Tabelle Mensch die Kategorien Vorname, Nachname, Gebut, Tod, Bio (kann man natürlich noch Spalten dazufügen)
bei direkten Familienvehältnissen ist es auch noch einfach (Vater und Mutter sind eindeutig hoffentlich...) aber bei Geschwistern, oder wenn man Generationen weitergeht wird es schon schwieriger.
Also z.B.
Mensch "1" ist Sohn von Mensch "2" und Mensch "3", Enkeln von Mensch "4" , "5", "6", "7", Bruder von Mensch "8", "9", "10".
Mensch "8" ist Sohn von Mensch "2", "3", Enkel von Mensch "4", "5", "6", "7" Bruder von "1", "9", "10", etc.
Mensch "2" ist Sohn von Mensch "4", "5" Enkel von "11", "12", "13", "14" Vater von "1", "8", "9", "10", etc.

sprich wenn ich nicht nur eine Familie sondern viele in meiner Datenbank speichere habe ich unheimlich viele doppelte Datensätze:
"1", "2" "3" "4" "5" "6" "7" "8" "9" "10"
"8" "2" "3" "4" "5" "6" "7" "9" "10" "1"
Sprich genau gleicher Datensatz nur umgekehrte Reihenfolge
etc pp.

da muß es doch eine Möglichkeit geben über join o.ä. auf die ID jedes Datensatzes um die Verhältnisse einfacher klar zu legen ohne Doubletten zu erzeugen - oder sehe ich nur den Wald vor lauter Bäumen nicht?

gruß

[Thomas Schmieder]

Hallo nochmal,

also zur Zeit ist das noch so, dass jeder Mensch genau einen Vater und genau eine Mutter hat. Insofern ist die Methode von Mech schon eine mathematisch elegante. Alle anderen Verwandtschaftsbezeiehungen lassen sich ja aus diesen beiden Parent-Beziehungen ableiten.

ID_MENSCH
ID_VATER
ID_MUTTER
GENERATION_LEVEL    (nur zur Sicherheit, kann von -oo bis +oo gehen)

Wenn Du also die Geschwister suchst zu einem Menschen, dann musst Du in sein ID_MUTTER-Feld schauen und alle diejenigen suchen, die in ihrem ID_MUTTER-Feld die gleiche ID haben. Sollen es Vollgeschwister sein, dann müssen auch die ID_VATER übereinstimmen.

Und wenn du die Großeltern suchst, dann kannst Du das mütterlicherseits und väterlicherseits durch zwimaliedes Klettern (Rekursion) schaffen.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Thomas Schmieder]

Hallo,

T_MENSCH
ID_MENSCH
NAME
und die ganzen Blah-Felder
1   Carola
2   Bernd
3   Klaus
4   Wiebke
5   Fritz
6   Peter

T_EIGENSCHAFT           1     Tochter
ID_EIGENSCHAFT          2     Sohn
BEZEICHNUNG             3     Vater
                        4     Mutter
                        5     Bruder

T_ISTVON
ID_ISTVON
ID_EIGENSCHAFT
ID_MENSCH
ID_MENSCH2

1   1    4    2         (ist tochter von) (Wiebke) -> (Bernd)
2   2    2    3         (ist Bruder von)  (Bernd)  -> (Klaus)
3
4
5
6

Das ganze nennt sich dann n-zu-m-selbstbezug

Um mit Selbstbezügen intelligent arbeiten zu können, öffnet (spricht an) man die selbe daei einfach unter zwei verschiedenen Aliasen.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Jonas]

Hallo,
danke erstmal

T_ISTVON
ID_ISTVON
ID_EIGENSCHAFT
ID_MENSCH
ID_MENSCH2

1   1    4    2         (ist tochter von) (Wiebke) -> (Bernd)
2   2    2    3         (ist Bruder von)  (Bernd)  -> (Klaus)

Aber in deinem Beispiel muß ich doch auch bei Klaus eingeben ist Bruder von Bernd.
Oder?
Sprich ich habe auch hier einen Doppelten Datensatz
Grüße,
Jonas

[Thomas Schmieder]

Hi,

Aber in deinem Beispiel muß ich doch auch bei Klaus eingeben ist Bruder von Bernd.
Oder?
Sprich ich habe auch hier einen Doppelten Datensatz

nein, doppelte Datensätze hast Du nicht, da die Beziehungs-Richtung sich ändert. Allerdings weiß ich, was du meinst. ob da nun   1-3-2 oder 2-3-1 steht (3 ist hier mal die Beziehungsart) ist ja für das Geschwisterverhältnis egal.

Da ist die rekursive Methode sicherlich sauberer.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Sven Rautenberg]

Moin!

T_ISTVON
ID_ISTVON
ID_EIGENSCHAFT
ID_MENSCH
ID_MENSCH2

1   1    4    2         (ist tochter von) (Wiebke) -> (Bernd)
2   2    2    3         (ist Bruder von)  (Bernd)  -> (Klaus)
3
4
5
6

Das ganze nennt sich dann n-zu-m-selbstbezug

Um mit Selbstbezügen intelligent arbeiten zu können, öffnet (spricht an) man die selbe daei einfach unter zwei verschiedenen Aliasen.

Meinst du wirklich, dass solch eine komplexe Tabelle sinnvoll ist? Ich finde, man kann doch einfach den natürlichen Weg der Geburt abbilden: Ein Mensch hat Vater und Mutter, die für seine Entstehung verantwortlich sind. Also kriegt jeder Mensch in der Tabelle zwei weitere Felder Vater und Mutter, in denen andere Menschen der Tabelle stehen.

Damit wären Vater und Mutter geklärt. Die Kinder des Menschen findet man, indem man nach allen Einträgen in der Tabelle sucht, die die eigene ID als Vater oder Mutter enthalten (wobei das "oder" nur in den seltensten Fällen benötigt wird - aber sicher ist sicher).

Die Geschwister findet man, indem man die Eltern-IDs feststellt und dann alle Menschen sucht, die beide (oder mindestens eine) der IDs als Mutter oder Vater enthält.

Und durch mehrere Stufen hindurch kann man dann im Prinzip den gesamten Stammbaum herauskriegen.

Das Problem ist nur: Eine relationale Datenbank ist für solche Konstrukte nicht wirklich die ideale Speicherungsform. Würde ich noch mit Turbo Pascal arbeiten, würde ich die Daten nicht auf Festplatte lassen, sondern ins RAM einlesen und mit Zeigern "verdrahten", damit man schnell durch die Datenstruktur wandern kann. Und wenn das zuviel Platz braucht, bliebe immer noch die Möglichkeit, direkt auf der Festplatte wahlfrei zu lesen (seek).

Die Datenbank hingegen wird als einzige Stärke ihre Datenspeicherkapazität einbringen können - wirklich helfen tut das nicht. Im Gegenteil wird sie vermutlich von vielen kleinen SELECT-Querys gequält, denn JOIN hilft zwar im Prinzip weiter, aber man kann da sehr leicht endlose JOIN-Ketten bilden, die irgendwann auch nicht mehr performant sind.

- Sven Rautenberg

[Thomas Schmieder]

Hallo Sven,

Ja, du hast natürlich recht, wenn es ausschließlich um die zur Zeit noch gültige rein biologische Abstammung geht. (wird ja gerade geändert. Demnächst haben wir dann zwei Väter und drei Mütter).

Hatte ich eben auch schon weiter untern eingeräumt, dass Mech da vollkommen richtig lag.

Allerdings funktioniert das Verfahren nicht mehr, wenn man auch die rechtlichen Verhältnisse abbilden muss. Da gibt es Adoptiveltern, Stiefeltern, Pflegeeltern auf Zeit usw. In die n:m-Datensätze kann man locker auch den Gültigkeitsbereich des Satzes eintragen. Da kann dann auch einer mehrere Eltern nacheinander oder zur gleichen Zeit haben.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Sven Rautenberg]

Moin!

Allerdings funktioniert das Verfahren nicht mehr, wenn man auch die rechtlichen Verhältnisse abbilden muss. Da gibt es Adoptiveltern, Stiefeltern, Pflegeeltern auf Zeit usw. In die n:m-Datensätze kann man locker auch den Gültigkeitsbereich des Satzes eintragen. Da kann dann auch einer mehrere Eltern nacheinander oder zur gleichen Zeit haben.

Wenn man so weit geht, dann hat man ohnehin ein Problem. Da bleibt dann eigentlich wirklich nur, je Mensch eine Liste zu führen, in der dieser Mensch mit seinen Eltern verknüpft wird. Das ist dann aber immer noch eine 1:n-Beziehung, und ich würde das auch in jedem Falle so lassen, und keine n:m-Beziehung draus machen.

Also statt der festen, im eigentlichen Datensatz vorhandenen Felder "Vater" und "Mutter" wird eine eigene Tabelle "Eltern (und andere ;) )" eröffnet, in der dann steht:

mensch_id elternmensch_id beziehungstyp

Und der Beziehungstyp ist dann flexibel handhabbar: Eltern, Stiefeltern, Adpotiveltern (jeweils Vater und Mutter möglich). Auch für gleichgeschlechtliche Lebensgemeinschaften gibts da keine Probleme, weil ein Mensch so eben leicht zwei Mütter oder fünf Väter haben kann. Auch der für künstliche Befruchtung zuständige Arzt kann mit einem eigenen Beziehungstyp eingetragen werden, oder Arzt und Genspender beim Klonen - als Typbezeichnung würde ich dann aber "Kopiervorlage" verwenden, nicht "Eltern".

Du hast also in der Tat recht: Ein starres Schema, welches nur auf die biologischen Erzeuger traditioneller Methode abzielt, ist definitiv zu unflexibel angesichts der technischen und rechtlichen Möglichkeiten, die es derzeit schon gibt und die uns noch ins Haus stehen. Dennoch würde ich ausschließlich festhalten, welche Eltern (im weitesten Sinne) zu einem Menschen  gehören, aber nicht noch umgekehrt, welche Geschwister, Kinder, Enkelkinder, Großeltern etc. ein Mensch gehabt hat. Das kann man, wie du ja auch feststellst, alles rekursiv aus den Daten entnehmen.

Aus Performancegründen bietet sich vielleicht an, solch eine Datenstruktur zu pflegen. Aber sie macht die Sache unnötig kompliziert. Außerdem gibt es nur für die engsten Verwandtschaftsgrade geläufige Bezeichnungen - und das sind alles Daten, die man relativ schnell auch rekursiv herausfinden kann. Für umfassende Ausgaben muss man mit der erzielbaren Geschwindigkeit einfach leben.

- Sven Rautenberg

[Thomas Schmieder]

Hallo Sven,

mensch_id elternmensch_id beziehungstyp

Und der Beziehungstyp ist dann flexibel handhabbar: Eltern, Stiefeltern, Adpotiveltern (jeweils Vater und Mutter möglich). Auch für gleichgeschlechtliche Lebensgemeinschaften gibts da keine Probleme, weil ein Mensch so eben leicht zwei Mütter oder fünf Väter haben kann. Auch der für künstliche Befruchtung zuständige Arzt kann mit einem eigenen Beziehungstyp eingetragen werden, oder Arzt und Genspender beim Klonen - als Typbezeichnung würde ich dann aber "Kopiervorlage" verwenden, nicht "Eltern".

Ich sehe, Du hast mich verstanden *ggg*

Systeme in der EDV können eben nur so gut sein, wie ihre Vorlage in der Realität. Ich hoffe nur, dass es noch eine Weile dauert, bis wir doch die "große Datenbanklösung" brauchen.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Jonas]

Hallo
und vielen Dank an Euch - waren ein paar sehr interessante Denkansätze dabei. Werde also jetzt mal in mich gehen und überlegen wie ich das für meinen speziellen Fall am besten Löse.
ALso nochmals tausend Dank hat mich sehr weitergebracht.
Grüße,
Jonas