relation sous openoffice base

[toitoinebzh]

bonjour

voila je voudrais me lancer dans la création d une base de donnée sous openoffice-base.
mon projet est de réaliser une base de donnée généalogiques

mais voila tout juste que je commence que je rencontre un probleme pour creer les relations
j ai bien trouve la méthode pour réaliser une relation entre deux tables différentes
mais maintenant je me trouve coince avec la partie la plus importante

voila ma table "personne"
personne ( id_personne, nom_personne, prénom_personne, id_pere, id_mere)
ma cle primaire est id_personne
id_pere et id_mere sont sense etre des cles etrangeres que je souhaites mettre en relation avec id_personne
en partant du principe qu une personne a un unique pere et mere j ai ecris cette table de cette maniere

quelqu un saurait t il ou j ai pu faire une erreur

[korova08]

Je vais répondre à côté en posant une question :
Pourquoi ne pas utiliser un logiciel dédié à la généalogie ? Un certain nombre sont recensés dans cette rubrique de framasoft (parmi d'autres utilitaires)

[Christian77320]

Peut être en créant une table relations dans laquelle sont inclus les Id des autres tables.

[toitoinebzh]

salut

je souhaite repondre à korova08
je sais qu il existe des logiciels de genealogie mais je souhaite apprendre a utiliser base
et je pense que de petit projets comme celui la pourrait m apprendre à utiliser ce logiciel

[Marco]

table "personne"
personne ( id_personne, nom_personne, prénom_personne, id_pere, id_mere)
cle primaire est id_personne
id_pere et id_mere sont sense etre des cles etrangeres que je souhaites mettre en relation avec id_personne

Je ne saisis pas bien comment ta relation est-elle construite. Quant à moi, je remplirais les champs id_pere et id_mere de la personne en question avec les valeurs des champs id_personne des enregistrements, respectivement, de son père et de sa mère. C'est cela que tu demandes ? En fait, tu n'es pas en train de mettre en relation deux tables, mais bien des enregistrements différents d'une même table, qui recense toutes les personnes de ta base généalogique. À moins que tu ne veuilles prévoir deux tables différentes pour les parents et pour les enfants, mais cela entrainerait la création d'une multitude de doublons et je n'en vois pas l'utilité.

[obor2]

La réponse de Christian77320 me paraît la plus appropriée. Ce qu'il propose de faire, c'est de créer une seconde table qui comprendra l'identificateur du père et de la mère d'une "personne". La table personne n'aura plus qu'à pointer vers le couple de parents correspondant dans cette nouvelle table.

Cette séparation est aussi un méthode élégante de travailler. Imagine qu'après ton travail tu veuilles faire la relation des couples mariées... Misère, la galère si tu n'utilisais que ton unique table "personne".

Comme tu veux apprendre, je reste vague dans les explications.

[irimi]

+1 pour Marco.

Sinon pour ton prob de relation toitoinebzh soit tu le fais à la main, c'est-à-dire que tu sais par convention que tu mettras l'ID d'une personne dans tes champs id_pere et id_mere, et que tu sauras comment les récupérer, soit tu lis la doc d'OOo à ce sujet :

tu ouvres l'aide d'OOo (F1), puis onglet "Contenu" > "Fonctionnalité de la base de données" > "Tables, requêtes et index" > "Tables", et tu as un lien "Relations, clés primaires et clés externes", je pense que ça t'intéressera.

[toitoinebzh]

merci irmi

la methode que je veux suivre est bien celle de Marco
je m en vais regarder l aide de openoffice

[irimi]

La réponse de Christian77320 me paraît la plus appropriée. Ce qu'il propose de faire, c'est de créer une seconde table qui comprendra l'identificateur du père et de la mère d'une "personne". La table personne n'aura plus qu'à pointer vers le couple de parents correspondant dans cette nouvelle table.

Cette séparation est aussi un méthode élégante de travailler. Imagine qu'après ton travail tu veuilles faire la relation des couples mariées... Misère, la galère si tu n'utilisais que ton unique table "personne".

Comme tu veux apprendre, je reste vague dans les explications.

C'est en effet plus "propre" dans la mesure où aucun ID ne figure alors plus dans la table des personnes. Par contre ça ne ralentit pas un peu la requête ? En outre j'avais plutôt compris que Christian77320 proposait de faire une table de relation "N à N" (avec l'ID ), mais ton interprétation est plus cohérente en effet.

Pour les couples mariés, c'est différent à mon avis, on associerait plutôt de façon "symétrique" deux personnes, on peut donc créer une relation "N à N" à l'aide d'une table "mariages", avec l'ID de l'épouse, celui de l'époux. On peut même y ajouter plein de paramètres sur ledit mariage (date, témoins, ...). Dans ce cas les champs de la table "mariages" seront un peu comme des relations "N à N", "pondérées" par des paramètres supplémentaires. Ca permet même de fabriquer plusieurs mariages différents pour les mêmes personnes, à cause de divorces, de remariages, etc., ce qui est très proche de la problématique posée.

En structuration, mieux vaut faire au plus juste, et notamment au plus rigoureux par rapport à la réalité. En l'occurrence, pour une relation "parent/enfant", une relation "1 à N", avec l'id des parents dans la fiche "personnes", permet de voir à coup sûr, pour quelqu'un qui regarde juste la base, qu'une personne n'a qu'une mère et qu'un père. Ceci dit ta solution dans ce cas revient exactement au même à l'exécution, disons que c'est une étape d'optimisation par rapport à la structuration du problème...

De toute façon, modéliser "proprement" en base de données relationnelle c'est un peu utopique, les BDDR sont trop axées "tables" pour modéliser correctement quoi que ce soit (à part des listes plates). La modélisation OO est nettement plus adaptée (rien que pour l'héritage déjà !), mais les BDDO (libres et performantes en plus) ça court pas les rues !

[obor2]

Je crois qu'il ne faut pas directement se focaliser sur l'aspect performant du concept mais plus sur sa souplesse d'adaptation. Je suppose que notre ami n'a pas l'intention de partager son oeuvre dans des infrastructures nationales qui manipulent des millions d'enregistrements. En d'autre mots, que son programme reste d'ordre privé et que la vitesse du retour de résultat n'est pas totalement essentiel.

La parenté peut être aussi compliquée que les mariages, c'est plus rares mais c'est possible. Imaginons le cas théorique d'un enfant dont les parents actuels se révelent ne pas être ses parents biologiques et que ses parents tuteurs soient également les parents biologiques d'un des parents biologiques de l'enfant. Une table seule va amener une complexité de gestion dans ce cas là. On pourrait dire que j'exagère, cependant... ^^

Personnellement, je préfère séparer les attributs des relations, ça me permet d'avoir une vue plus claire du problème. Un peu comme ceci: voici toutes les personnes de ma graaaaandde famille et voici leur liens respectifs: de parenté biologique, de parenté tutélaire, de mariage, de couple, d'équipe sportive, etc.

Ca permet d'avoir également un point d'entrée inverse, voir un point de contact avec tout autre structure informative. On pourrait imaginer un croisement entre cette information de parenté et une toute autre source d'information telle que les lieux de résidence durant la parenté commune d'un couple: les enfants pouvant avoir été élevés loin de leur parents et donc n'habitant pas la même résidence, le lien parent/enfant n'est pas essentiel. Il y a encore un point qui peut encore jeter un peu plus de flou sur tout ça, si on prend en compte le concept de temporalité. Par exemple, les mêmes personnes se remariant et ayant à nouveau des enfants. En fait je pense qu'il peut y avoir tellement de cas de figures que séparer les attributs d'une personnes des liens qu'elle a, permet de facilement réagir dans les exceptions les plus insolites.

Bref! C'est comme ça que je le vois. Et je ne suis pas un expert DB !

Enfin, tout ça est théorique et ne vise qu'à l'explosion de quelques neurones. Et on s'éloigne fortement du sujet. Si toitoinebzh a mis à plat le but de l'exercice et sait ce qu'il veut faire, il saura certainement prendre en compte les exceptions que son modèle génèrera et prendre les actions nécessaires pour y palier.