IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Relations conjugales.. (extra) [MCD]


Sujet :

Schéma

  1. #1
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut Relations conjugales.. (extra)
    Bonjour à tous,

    Les relations liées au mariage me paraissent intéressantes... au niveau conceptuel MCD, j'entends.

    Ce post est, sans doute, incomplet... et contenant, peut-être, quelques boulettes.

    Cahier des charges :
    1. une personne ne peut pas se marier avec elle-même ;
    2. une personne peut se marier plusieurs fois (avec une personne différente ou pas) ;
    3. une personne peut se marier avec une autre personne du même sexe (à terme, peut-être) ;
    4. une personne peut se marier avec plusieurs personnes dans le cadre du même mariage ;
    5. l'ordre (la séquence) d'une personne dans le couple est indifférent.


    Relation :
    PERSONNES ---(0,n)---[est marié à]---(0,n) PERSONNES

    Entité PERSONNES
    - Id_Personne (PK)
    - Nom
    - Prenom
    ...

    Entité MARIAGES
    - Id_Conjoint_x
    - Id_Conjoint_y
    - Date_Mariage
    ...
    ==> x et y employés à dessein pour ne pas indiquer une sorte de hiérarchie (point 5 du cahier des charges).

    Je ne sais pas comment modéliser deux choses :
    Le point 1 du cahier des charges : Id_Conjoint_x doit être différent de Id_Conjoint_y ;
    Le point 5 du cahier des charges : un couple Id_Conjoint_x=154 et Id_Conjoint_y=2018 est le même que Id_Conjoint_x=2018 et Id_Conjoint_y=154.

    Au niveau PK, ça se corse...

    - Id_Conjoint_x PK
    - Id_Conjoint_y PK
    - Date_Mariage PK
    ==> permet de gérer la polygamie (pour une application multi-culturelle). Mais, attention à la non-modélisation du point 1 et 5 du cahier des charges.

    - Id_Conjoint_x PK
    - Date_Mariage PK
    - Id_Conjoint_y
    et Date_Mariage/Id_Conjoint_y doit être un index unique.
    ==> permet de gérer, uniquement, la monogamie. Mais, attention à la non-modélisation du point 1 et 5 du cahier des charges.


    Pas simple... également concernant le MCD...
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  2. #2
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2009
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juillet 2009
    Messages : 45
    Points : 58
    Points
    58
    Par défaut
    Salut,

    Je pense que pour modéliser le premier point du cahier des charges, une contrainte de partition ferait l'affaire.

    En ce qui concerne le cinquième point, je ne suis pas sûr qu'il soit à prendre en compte au niveau conceptuel. Étant donné qu'il s'agit d'une relation reflexive, ça me semble naturel.

    Pour finir, j'ajouterais une date de divorce pour pouvoir gérer les periodes.

  3. #3
    Responsable Arduino et Systèmes Embarqués


    Avatar de f-leb
    Homme Profil pro
    Enseignant
    Inscrit en
    Janvier 2009
    Messages
    12 579
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Janvier 2009
    Messages : 12 579
    Points : 56 603
    Points
    56 603
    Billets dans le blog
    40
    Par défaut
    bonjour,

    Citation Envoyé par Richard_35 Voir le message
    Cahier des charges :
    1. une personne ne peut pas se marier avec elle-même ;
    2. une personne peut se marier plusieurs fois (avec une personne différente ou pas) ;
    3. une personne peut se marier avec une autre personne du même sexe (à terme, peut-être) ;
    4. une personne peut se marier avec plusieurs personnes dans le cadre du même mariage ;
    5. l'ordre (la séquence) d'une personne dans le couple est indifférent.
    Avec un tel cahier des charges, j’écrirais :
    Mariage----2,n----marier-----0,n-----Personne

    Avec ça tu es tranquille, ton mariage permet de mélanger hommes et femmes sans aucune distinction des rôles époux/épouse, n’importe qui peut se marier autant de fois qu’il veut, quand il veut et avec qui il veut…

    Je ne sais plus qui a dit :
    " Modéliser les données d’un système logiciel, c’est construire une structure de données contraintes, représentative du réel observé. "

    Je ne sais pas dans quel pays ou sur quelle planète tu as pu observer cette réalité, mais avec ses mœurs très libérales les concepteurs de S.I doivent s’y ennuyer à mourir… 

  4. #4
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour Fabien,

    Merci de ta participation toujours pertinente.

    Je ne connais pas cette juste citation :
    Citation Envoyé par Fabien
    " Modéliser les données d’un système logiciel, c’est construire une structure de données contraintes, représentative du réel observé. "
    Effectivement, je n'ai jamais observé ce réel dans un même pays (et, a fortiori, dans une même planète), mais, chaque élément de ce cahier des charges existe dans des pays différents. Alors, façon science fiction, donc en extrapolant, nous pouvons imaginer regrouper tous ces éléments pour un même "pays" ou "supra-pays".

    D'autre part
    Citation Envoyé par Fabien
    .../... les concepteurs de S.I doivent s’y ennuyer à mourir
    Il me semble que l'objectif d'un SI, dans l'absolu, n'est pas de ne pas s'ennuyer, mais de répondre aux besoins d'une organisation (société, pays, planète, etc...).

    Ce cahier des charges imaginaire est une sorte d'exercice de style qui m'a paru, peut-être à tort, intéressant.

    Enfin, la relation que tu présente est, effectivement très maline :
    Citation Envoyé par Fabien
    Mariage----2,n----marier-----0,n-----Personne
    Comment verrais-tu les tables finales ?
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  5. #5
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 965
    Points : 30 777
    Points
    30 777
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par Richard_35 Voir le message
    Date_Mariage/Id_Conjoint_y doit être un index unique.
    La formulation est incorrecte. Certes, Maurice Nivat a écrit que l’informatique est la rencontre de la logique formelle et du fer à souder et, dans cet esprit, l’index (au sens des SGBD) fait partie de la quincaillerie technique, tandis que la paire {Date_Mariage, Id_Conjoint_y} est un ensemble au sens de la théorie des ensembles et représente une clé que l’on qualifier d’alternative quand on utilise le concept de clé primaire (qualificatif devenu du reste obsolète dans la théorie relationnelle en vertu du principe d'interchangeabilité). Avec SQL, cette paire fait l’objet d’une contrainte d’unicité au sein de l’instruction CREATE TABLE (ou ALTER TABLE) :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CREATE TABLE MARIAGE
    (    ...
         , CONSTRAINT MARIAGE_PK PRIMARY KEY (Id_Conjoint_x, Date_Mariage)
         , CONSTRAINT MARIAGE_AK1 UNIQUE (Id_Conjoint_y, Date_Mariage)
         ...
    ) ;
    Quand à la monogamie, comment l'éviter avec seulement la mise en œuvre des clés ?

    Selon votre représentation, la personne X peut épouser la personne Y aujourd’hui et la personne Z le lendemain, sans pour autant avoir divorcé d’avec la personne Y. A terme, X peut se marier avec tous les habitants de la planète, à raison de un par jour.

    Accessoirement, pour éviter que X se marie avec X :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    CREATE TABLE MARIAGE
    (    ...
         , CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x <> Id_Conjoint_y) 
         ...
    ) ;
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  6. #6
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour François,

    Tout d'abord, merci de ta participation, toujours pertinente. Et, encore une fois, félicitation pour tes publications et ta connaissance de la codification des modélisations.

    *1*
    Désolé, je ne connais pas Maurice Nivat, mais j'aime assez la formule
    Citation Envoyé par Maurice Nivat
    .../... la rencontre de la logique formelle et du fer à souder .../...
    Elle montre, en autre, que, en final, une application "classique" doit tourner (avec des écrans, des états, etc... tout cela, avec une base de données la plus pertinente possible) : d'où, l'utilisation, parfois, du fer à souder.
    *1*

    *2*
    Donc, le point 1 du cahier des charges n'est pas modélisable, mais résolu par
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x <> Id_Conjoint_y)
    Par contre, le point 5 reste difficile à résoudre.
    *2*

    *3*
    D'autre part,
    Citation Envoyé par François
    Quand à la monogamie, comment l'éviter avec seulement la mise en œuvre des clés ?
    il me semble qu'elle est gérée par
    Citation Envoyé par Richard
    - Id_Conjoint_x PK
    - Date_Mariage PK
    - Id_Conjoint_y
    et Date_Mariage/Id_Conjoint_y doit être un index unique.
    en admettant de ne pas gérer de date de divorce (mais qui serait nécessaire, comme l'a suggéré, fort justement, Bergie). Donc, dans la monogamie, nous admettrons qu'une nouvelle date de mariage implique qu'il y a eu divorce précédemment.
    Mais pas pour la polygamie car, des mariages successifs à différentes dates, sans divorce(s) précédent(s), est possible.
    *3*

    *4*
    Citation Envoyé par François
    Selon votre représentation, la personne X peut épouser la personne Y aujourd’hui et la personne Z le lendemain, sans pour autant avoir divorcé d’avec la personne Y. A terme, X peut se marier avec tous les habitants de la planète, à raison de un par jour.
    Exact, pour la raison évoquée précédemment.
    *4*
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  7. #7
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2009
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juillet 2009
    Messages : 45
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par Richard_35 Voir le message
    Donc, le point 1 du cahier des charges n'est pas modélisable
    Bien sur qu'il est modelisable, et comme je l'ai dit dans ma premiere réponse, il me semble qu'il s'agisse d'une contrainte de partition.

  8. #8
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour Bergie,

    Je viens de me documenter sur cette contrainte que je ne connaissais pas : merci.
    Mais cela ne semble pas correspondre au besoin :
    Exemple1
    Exemple2
    Comment représenterais-tu cette contrainte, dans le cas de cette association réflexive ?
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  9. #9
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2009
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juillet 2009
    Messages : 45
    Points : 58
    Points
    58
    Par défaut
    Exact, alors déjà, je voulais parler d'exclusion et non de partition, mais de toute façon, c'est faux aussi

    Donc après quelques recherches, je suis tombé sur une explication intéressante

    On peut être tenté de placer une contrainte d’exclusion sur l’association réflexive « succéder ».

    Nom : succeder1.png
Affichages : 452
Taille : 25,0 Ko

    Remarquez que, dans ce cas, il faut bien accrocher la contrainte aux « pattes ». Mais ce n’est pas sans conséquence. Interrogeons-nous, en effet, sur le sens de cette contrainte. Pour déterminer la signification d’une contrainte, il faut, en principe, en placer le pivot. Ici, franchement, est-ce bien nécessaire ? Tout est dit, puisque la contrainte est accrochée aux rôles. Il n’y a qu’une seule interprétation possible : un logiciel jouant le rôle de précédent ne peut jouer le rôle de succédant. On pourrait écrire :
    Succéder[LOGICIELprécédent] ∩ Succéder[LOGICIELsuccédant] = ∅.
    Or, cette contrainte n’est pas celle que nous voulions mentionner. Pis, elle est erronée : si le logiciel n° 15 succède au logiciel n ° 4 et le logiciel n° 33 succède au logiciel n° 15, nous voyons bien que, dans des couples différents, le logiciel n° 15 remplit alternativement les deux rôles. Ce que nous voulions dire est qu’un logiciel ne peut jouer les deux rôles dans le même couple, ce que nous pourrions écrire ainsi : ∀ S ∈ Succéder : S.LOGICIELprécédent ≠ S.LOGICIELsuccédant.
    Remarquez que la contrainte ainsi écrite nous amène à considérer la composition de chaque n-uplet et non à comparer des sous-ensembles dans leur globalité. En conséquence, la contrainte à mentionner n’est pas une contrainte ensembliste.
    Ce cas est un peu différent du nôtre, mais on se rend compte que ce type de contrainte ne correspond pas vraiment.
    Ce qu'il nous faudrait serait une contrainte d'antiréflexivité (On ne peut pas être son propre époux/épouse). Une association réflexive avec une contrainte d'antiréflexivité

    En fait, le modèle entité-association n’intègre pas l’expression de ces genres de contraintes même parmi ses diverses extensions. Un modèle américain s’attarde sur ces contraintes où elles sont nommées ring constraints. Nous nous en inspirons ci-dessous à propos du cas GRC.
    Dans le cas GRC, nous avons rencontré une association « réflexive », l’association « Succéder ». Précédemment, l’expression d’une contrainte nous a posé problème. Il s’agissait de montrer qu’un logiciel ne peut succéder à lui-même. La propriété correspondante est...
    l’antiréflexivité. En ORM, cela s’appelle irreflexive constraint notée 0 ir.

    Nom : succeder2.png
Affichages : 314
Taille : 27,4 Ko

    En fait, ici, il faudrait mentionner les autres contraintes comme l’asymétrie. Pourtant nous nous en tiendrons là. En effet, il ne s’agit pas pour nous de proposer de nouvelles extensions au MEA, bien assez riche déjà, mais de donner la possibilité à tout un chacun de maîtriser la notion de contrainte ensembliste en évitant de la confondre, dans les associations dites « réflexives », avec les propriétés des relations binaires correspondantes.
    Donc je n'apporte pas grand chose au sujet concrètement, mais je pense que je souligne un détail intéressant.

  10. #10
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 965
    Points : 30 777
    Points
    30 777
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par Richard_35 Voir le message
    Désolé, je ne connais pas Maurice Nivat
    Selon Jacques Arsac (Les machines à penser) Maurice Nivat était l’un des meilleurs spécialistes mondiaux en informatique théorique il y a vingt ans. Cette formule figure dans le rapport qu’il fit au premier ministre Pierre Maurois.


    Citation Envoyé par bergie Voir le message
    Ce qu'il nous faudrait serait une contrainte d'antiréflexivité
    A ce sujet, au lieu de coder :
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x <> Id_Conjoint_y)
    on préfèrera coder :
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x < Id_Conjoint_y)
    Sinon, on pourrait insérer des triplets fautifs :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO MARIAGE VALUES  (1, 2, 'd01') ;
    INSERT INTO MARIAGE VALUES  (2, 1, 'd02') ;

    Concernant la contrainte de monogamie, rien n’empêche de l’enfreindre. Par exemple, 2 épouse 1 à d01 et 3 le même jour :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO MARIAGE VALUES  (1, 2, 'd01') ;
    INSERT INTO MARIAGE VALUES  (2, 3, 'd01') ;


    Citation Envoyé par Richard_35 Voir le message
    dans la monogamie, nous admettrons qu'une nouvelle date de mariage implique qu'il y a eu divorce précédemment.
    Mais pas pour la polygamie car, des mariages successifs à différentes dates, sans divorce(s) précédent(s), est possible.
    Qu’il s’agisse de divorce, d’annulation ou de décès, la monogamie impose la prise en compte d’une date de fin, car on ne peut inventer celle-ci. En relationnel, on met en oeuvre le type INTERVAL_DATE, accompagné de l’opérateur de sélection :
    INTERVAL_DATE ( [deb : fin] )
    deb et fin étant des expressions de type DATE.

    Par ailleurs je ne vois pas en quoi on pourrait se dispenser de des intervalles de dates dans le cas de la polygamie. Autrement dit, on en revient à la séparations des données actives :
    x est marié avec y depuis telle date
    et des données historiques :
    x a été marié avec y durant l’intervalle [di : dj].
    Exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    PERSONNE {PersonneId, PersonneNom, PersonneSexe, ...}
        KEY {PersonneId}
    
    ÊTRE_ACTUELLEMENT_MARIÉ {PersonneId1, PersonneId2, Depuis}
    KEY {PersonneId1, PersonneId2}
        FOREIGN KEY {PersonneId1} REFERENCES PERSONNE {PersonneId}
        FOREIGN KEY {PersonneId2} REFERENCES PERSONNE {PersonneId}
    
    AVOIR_ÉTÉ_MARIÉ {PersonneId1, PersonneId2, Durant}
        KEY {PersonneId1, PersonneId2, Durant}
        FOREIGN KEY {PersonneId1} REFERENCES PERSONNE {PersonneId}
        FOREIGN KEY {PersonneId2} REFERENCES PERSONNE {PersonneId}
    L’attribut Durant est du type INTERVAL_DATE.

    S’il est besoin de le rappeler, la date de début d’un intervalle ne peut pas être postérieure à la date de fin de cet intervalle.

    Quelques contraintes basiques à vérifier (CONSTRAINT en Tutorial D, ASSERTION en SQL ou TRIGGER à défaut), mais hors de portée des MCD merisiens :

    (C1) Si Titi et Lili sont mariés depuis la date dx (variable ÊTRE_ACTUELLEMENT_MARIÉ), Titi et Lili ont déjà pu être mariés (à l’instar du couple Burton/Taylor), mais à condition que ce fut durant une période antérieure à dx (variable AVOIR_ÉTÉ_MARIÉ).

    =>

    (C2) Si Titi et Lili sont mariés depuis la date dy (variable ÊTRE_ACTUELLEMENT_MARIÉ), l'historique (variable AVOIR_ÉTÉ_MARIÉ) ne peut pas faire mention du fait qu'ils ont été mariés dans l'intervalle [dx : dy-1] (En effet, ils sont alors mariés depuis la date dx).

    (C3) Pour chaque paire de conjoints, chaque date de fin de l’attribut Durant de la variable AVOIR_ÉTÉ_MARIÉ doit être antérieure à chaque date de mariage en cours (attribut Depuis de la variable ÊTRE_ACTUELLEMENT_MARIÉ).

    (C4) Pour chaque paire de conjoints, il ne peut y avoir deux intervalles (attribut Durant) qui se chevauchent.

    (C5) Pour chaque paire de conjoints, la date de fin d’un intervalle (attribut Durant) ne peut pas être égale à la date de début - 1 d’un autre intervalle :
    Si Titi et Lili ont été mariés de dx à dy et de dy+1 à dz, il n’y a qu’un seul intervalle pour exprimer ce fait, à savoir [dx : dz].
    ...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  11. #11
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour François,

    Désolé (x2), je ne connais pas, non plus, Jacques Arsac ni "Les machines à penser"... mais, je vais essayer de m'attaquer, dare-dare, à mon inculture.

    *1*
    Citation Envoyé par François
    A ce sujet, au lieu de coder :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x <> Id_Conjoint_y)
    on préfèrera coder :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x < Id_Conjoint_y)
    ==> je ne vois pas pourquoi !... la première contrainte me paraît OK, la seconde, en revanche me paraît curieuse, non ?
    L'Id est un identifiant séquentiel qui ne doit pas être évaluer par rapport à l'Id d'un conjoint.
    Cet exemple est correct :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    Id_Conjoint_x   Id_Conjoint_y   Date_Mariage
    522             118             01/01/2011
    *1*


    *2*
    Citation Envoyé par François
    Sinon, on pourrait insérer des triplets fautifs :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO MARIAGE VALUES  (1, 2, 'd01') ;
    INSERT INTO MARIAGE VALUES  (2, 1, 'd02') ;
    ==> dans le cahier des charges présentés, ces triplés ne sont pas fautifs : 1 s'est marié avec 2 le d01 et 2 s'est marié avec 1 le d02. A partir du moment où d01<>d02 (ce que tu sembles indiquer par les 'xxx'), le mariage est valable.
    D'autre part, dans le cahier des charges est précisé : "5-l'ordre (la séquence) d'une personne dans le couple est indifférent". Donc le couple 1/2 est le même que le couple 2/1.
    *2*

    *3*
    Citation Envoyé par François
    Concernant la contrainte de monogamie, rien n’empêche de l’enfreindre. Par exemple, 2 épouse 1 à d01 et 3 le même jour :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO MARIAGE VALUES  (1, 2, 'd01') ;
    INSERT INTO MARIAGE VALUES  (2, 3, 'd01') ;
    ==> impossible, car (#1) :
    Citation Envoyé par Richard_35
    - Id_Conjoint_x PK
    - Date_Mariage PK
    - Id_Conjoint_y
    et Date_Mariage/Id_Conjoint_y doit être un index unique.
    ==> permet de gérer, uniquement, la monogamie. Mais, attention à la non-modélisation du point 1 et 5 du cahier des charges.
    *3*

    Pour la suite, je suis d'accord avec toi (et avec Bergie) concernant la date de fin de mariage, mais je voulais simplifier. D'autre part, il apparaît nécessaire de définir le type de mariage (monogame ou polygame). Les tables deviennent donc :
    Entité PERSONNES
    - Id_Personne (PK)
    - Nom
    - Prenom
    ...

    Entité MARIAGES
    - Id_Conjoint_x
    - Id_Conjoint_y
    - Type_Mariage (M=Monogame, P=Polygame)
    - Date_Mariage
    - Date_Fin_Mariage
    ...

    Concernant le cahier des charges :
    1. une personne ne peut pas se marier avec elle-même ;
      ==> non modélisable "graphiquement" : contrainte lors de la création de la table.
    2. une personne peut se marier plusieurs fois (avec une personne différente ou pas) ;
      ==> modélisable "graphiquement" (?) suivant le type et la date de mariage.
    3. une personne peut se marier avec une autre personne du même sexe (à terme, peut-être) ;
      ==> modélisable "graphiquement" de fait si l'on ne fait intervenir le sexe nulle part.
    4. une personne peut se marier avec plusieurs personnes dans le cadre du même mariage ;
      ==> modélisable "graphiquement" (?) suivant le type du mariage.
    5. l'ordre (la séquence) d'une personne dans le couple est indifférent.
      ==> non modélisable "graphiquement" : contrainte difficile à paramétrer, sauf à "balayer", à chaque création, l'ensemble des couples où x,y apparaissent.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  12. #12
    Membre actif
    Étudiant
    Inscrit en
    Avril 2008
    Messages
    311
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Avril 2008
    Messages : 311
    Points : 257
    Points
    257
    Par défaut
    Salut,

    je crois que la proposition de fsmrel concernant ton *1* est une astuce qui permet de ne jamais avoir le même mariage avec des identifiants simplement permutés. (ça me rappelle des problèmes de développement quand j'avais une relation réflexive est_ami).
    Pour faire cette même vérification on pourrait programmer un trigger (accompagné du CHECK) qui recherche pour un couple (P1, P2) si le couple (P2, P1) existe déjà mais c'est bien plus lourd (perte de performance) [=> ton point ==>5].

    Merci pour cette discussion intéressante !

    @+

  13. #13
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par fsmrel
    Citation Envoyé par Bergie
    Ce qu'il nous faudrait serait une contrainte d'antiréflexivité
    A ce sujet, au lieu de coder :
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x <> Id_Conjoint_y)
    on préfèrera coder :
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x < Id_Conjoint_y)
    Citation Envoyé par Titus159
    je crois que la proposition de fsmrel concernant ton *1* est une astuce qui permet de ne jamais avoir le même mariage avec des identifiants simplement permutés. (ça me rappelle des problèmes de développement quand j'avais une relation réflexive est_ami).
    Pour faire cette même vérification on pourrait programmer un trigger (accompagné du CHECK) qui recherche pour un couple (P1, P2) si le couple (P2, P1) existe déjà mais c'est bien plus lourd (perte de performance).
    Peut-être m'avancé-je un peu vite sur l'interprétation de la suggestion de fsmrel mais je verrais bien en effet un trigger qui mettrait les identifiants des deux mariés dans l'ordre ascendant afin de n'enregistrer que des mariages où id_conjoint_x serait inférieur à id_conjoint_y. Inutile alors de chercher le couple inverse. Par contre il faut aussi chercher si ce couple n'est pas déjà actuellement marié.

    Citation Envoyé par Richard_35
    Concernant le cahier des charges :
    1. une personne ne peut pas se marier avec elle-même ;
      ==> non modélisable "graphiquement" : contrainte lors de la création de la table.

    Rien n'interdit a priori d'ajouter des annotations au MCD qui faciliteront ensuite l'écriture des contraintes CHECK, voire de les générer si le logiciel de modélisation a prévu ce cas de figure.

    une personne peut se marier plusieurs fois (avec une personne différente ou pas) ;
    ==> modélisable "graphiquement" (?) suivant le type et la date de mariage.
    Les cardinalités 0,n suffisent non ?

    une personne peut se marier avec une autre personne du même sexe (à terme, peut-être) ;
    ==> modélisable "graphiquement" de fait si l'on ne fait intervenir le sexe nulle part.
    Même si on fait figurer le sexe de la personne, tant qu'il n'y a pas de contrainte sur la différence des sexes, pas de problème.
    Mais justement, si la loi du pays considéré interdit le mariage homosexuel, c'est une contrainte à prendre en compte dans la BDD. Il faudrait donc peut-être prévoir une clé étrangère référençant le pays où est officialisé le mariage afin de faire vérifier par le trigger si le mariage est valide ou non.

    une personne peut se marier avec plusieurs personnes dans le cadre du même mariage ;
    ==> modélisable "graphiquement" (?) suivant le type du mariage.
    Là encore, au minimum par une annotation dans le MCD. Je ne sais pas s'il y a une autre méthode.

    l'ordre (la séquence) d'une personne dans le couple est indifférent.
    ==> non modélisable "graphiquement" : contrainte difficile à paramétrer, sauf à "balayer", à chaque création, l'ensemble des couples où x,y apparaissent.
    Avec le système suggéré au début de ce message, le classement X < Y n'est qu'une astuce interne au SGBD et ne suppose pas une valeur d'ordre dans le couple.
    Je dirais donc qu'ainsi le "non-ordre" des mariés est implicite.


    fsmrel suggérait ceci :
    Citation Envoyé par fsmrel
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CREATE TABLE MARIAGE
    (    ...
         , CONSTRAINT MARIAGE_PK PRIMARY KEY (Id_Conjoint_x, Date_Mariage)
         , CONSTRAINT MARIAGE_AK1 UNIQUE (Id_Conjoint_y, Date_Mariage)
         ...
    ) ;
    Sauf erreur de ma part, rien n'interdit, dans une société polygame, qu'une personne puisse se marier avec plusieurs personnes le même jour ?

    Où sont passées mes jumelles ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  14. #14
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par fsmrel
    Citation Envoyé par Bergie
    Ce qu'il nous faudrait serait une contrainte d'antiréflexivité
    A ce sujet, au lieu de coder :
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x <> Id_Conjoint_y)
    on préfèrera coder :
    CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x < Id_Conjoint_y)
    Citation Envoyé par Titus159
    je crois que la proposition de fsmrel concernant ton *1* est une astuce qui permet de ne jamais avoir le même mariage avec des identifiants simplement permutés. (ça me rappelle des problèmes de développement quand j'avais une relation réflexive est_ami).
    Pour faire cette même vérification on pourrait programmer un trigger (accompagné du CHECK) qui recherche pour un couple (P1, P2) si le couple (P2, P1) existe déjà mais c'est bien plus lourd (perte de performance).
    Peut-être m'avancé-je un peu vite sur l'interprétation de la suggestion de fsmrel mais je verrais bien en effet un trigger qui mettrait les identifiants des deux mariés dans l'ordre ascendant afin de n'enregistrer que des mariages où id_conjoint_x serait inférieur à id_conjoint_y. Inutile alors de chercher le couple inverse. Par contre il faut aussi chercher si ce couple n'est pas déjà actuellement marié.

    Citation Envoyé par Richard_35
    Concernant le cahier des charges :
    1. une personne ne peut pas se marier avec elle-même ;
      ==> non modélisable "graphiquement" : contrainte lors de la création de la table.

    Rien n'interdit a priori d'ajouter des annotations au MCD qui faciliteront ensuite l'écriture des contraintes CHECK, voire de les générer si le logiciel de modélisation a prévu ce cas de figure.

    une personne peut se marier plusieurs fois (avec une personne différente ou pas) ;
    ==> modélisable "graphiquement" (?) suivant le type et la date de mariage.
    Les cardinalités 0,n suffisent non ?

    une personne peut se marier avec une autre personne du même sexe (à terme, peut-être) ;
    ==> modélisable "graphiquement" de fait si l'on ne fait intervenir le sexe nulle part.
    Même si on fait figurer le sexe de la personne, tant qu'il n'y a pas de contrainte sur la différence des sexes, pas de problème.
    Mais justement, si la loi du pays considéré interdit le mariage homosexuel, c'est une contrainte à prendre en compte dans la BDD. Il faudrait donc peut-être prévoir une clé étrangère référençant le pays où est officialisé le mariage afin de faire vérifier par le trigger si le mariage est valide ou non.

    une personne peut se marier avec plusieurs personnes dans le cadre du même mariage ;
    ==> modélisable "graphiquement" (?) suivant le type du mariage.
    Là encore, au minimum par une annotation dans le MCD. Je ne sais pas s'il y a une autre méthode.

    l'ordre (la séquence) d'une personne dans le couple est indifférent.
    ==> non modélisable "graphiquement" : contrainte difficile à paramétrer, sauf à "balayer", à chaque création, l'ensemble des couples où x,y apparaissent.
    Avec le système suggéré au début de ce message, le classement X < Y n'est qu'une astuce interne au SGBD et ne suppose pas une valeur d'ordre dans le couple.
    Je dirais donc qu'ainsi le "non-ordre" des mariés est implicite.


    fsmrel suggérait ceci :
    Citation Envoyé par fsmrel
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CREATE TABLE MARIAGE
    (    ...
         , CONSTRAINT MARIAGE_PK PRIMARY KEY (Id_Conjoint_x, Date_Mariage)
         , CONSTRAINT MARIAGE_AK1 UNIQUE (Id_Conjoint_y, Date_Mariage)
         ...
    ) ;
    Sauf erreur de ma part, rien n'interdit, dans une société polygame, qu'une personne puisse se marier avec plusieurs personnes le même jour ?

    Où sont passées mes jumelles ?

    Au final, je verrais bien une table des mariages structurée de la sorte :
    mariage (mar_id, mar_id_conjoint1, mar_id_conjoint2, mar_id_pays, mar_date_debut)
    mar_id serait autoincrémenté.
    mar_id_pays permettrait de vérifier si le pays référencé autorise le mariage homosexuel et/ou polygame.

    Quid de la date de fin ? Pour ne pas voir le bonhomme NULL s'immiscer dans nos affaires matrimoniales, fsmrel préférera sans doute modéliser les fins de mariage dans une autre table :
    fin_mariage (fmr_id_mariage, fmr_date_fin)

    "fmr", pas mal comme acronyme pour des mariages non ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  15. #15
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2009
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juillet 2009
    Messages : 45
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    Au final, je verrais bien une table des mariages structurée de la sorte :
    mariage (mar_id, mar_id_conjoint1, mar_id_conjoint2, mar_id_pays, mar_date_debut)
    mar_id serait autoincrémenté.
    mar_id_pays permettrait de vérifier si le pays référencé autorise le mariage homosexuel et/ou polygame.

    Quid de la date de fin ? Pour ne pas voir le bonhomme NULL s'immiscer dans nos affaires matrimoniales, fsmrel préférera sans doute modéliser les fins de mariage dans une autre table :
    fin_mariage (fmr_id_mariage, fmr_date_fin)

    "fmr", pas mal comme acronyme pour des mariages non ?
    J'aime assez. ^^
    Au niveau conceptuel, je représenterais ça de cette façon:

    Nom : mariage.png
Affichages : 310
Taille : 6,3 Ko


    Au niveau du cahier des charges:


    une personne ne peut pas se marier avec elle-même ;
    OK
    une personne peut se marier plusieurs fois (avec une personne différente ou pas) ;
    OK
    une personne peut se marier avec une autre personne du même sexe (à terme, peut-être) ;
    OK
    une personne peut se marier avec plusieurs personnes dans le cadre du même mariage ;
    NON
    l'ordre (la séquence) d'une personne dans le couple est indifférent.
    A mon avis, ce n'est pas à prendre en compte au niveau conceptuel.


    J'ai rajouté une contrainte d'inclusion pour qu'on ne puisse se séparer uniquement si l'on fait partie d'un couple marié.

    Reste donc l'union de plus de 2 personnes dans le cadre du même mariage.

  16. #16
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Ton schéma laisse la possibilité à un même couple de se marier dans deux pays différents.

    Et il ne correspond pas à ma description de tables puisque mes tables sont issues d'entités du MCD et non pas d'associations.

    Mon modèle (sans les contraintes) est le suivant :
    Personne -0,n----Contracter----(conjoint1)-1,1- Mariage -1,1----Situer----0,n- Pays
    |---------------0,n----Contracter----(conjoint2)-1,1-----| |-------0,1----Dater----(1,1)- Fin_mariage

    Du fait de l'identification relative (cardinalités entre parenthèses) du côté de Fin_mariage, la contrainte faisant qu'on ne peut divorcer que d'une personne avec laquelle on est marié est implicite puisque ça modélise la fin du mariage et non pas le fait qu'on se sépare d'une personne.

    On peut modéliser une contrainte d'exclusion entre les deux associations "Contracter" pour interdire à une personne de se marier avec elle même.

    Les contraintes autorisant ou non le mariage homo et/ou polygame dépendant du pays ou est "situé" le mariage ne sont pas modélisables à mon avis autrement que par des annotations.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  17. #17
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2009
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juillet 2009
    Messages : 45
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    Ton schéma laisse la possibilité à un même couple de se marier dans deux pays différents.
    Ah oui! Mais je ne vois pas en quoi ta version l'interdit.
    D'ailleurs, ça serait possible à partir du moment où ils se seraient séparés avant.

    Citation Envoyé par CinePhil Voir le message
    Et il ne correspond pas à ma description de tables puisque mes tables sont issues d'entités du MCD et non pas d'associations..
    En effet, mais à la limite, ça pourrait être fait des 2 façons non?

    Citation Envoyé par CinePhil Voir le message
    Du fait de l'identification relative (cardinalités entre parenthèses) du côté de Fin_mariage, la contrainte faisant qu'on ne peut divorcer que d'une personne avec laquelle on est marié est implicite puisque ça modélise la fin du mariage et non pas le fait qu'on se sépare d'une personne.
    Oui ça semble plus simple et plus logique tourné comme ça.

    Citation Envoyé par CinePhil Voir le message
    On peut modéliser une contrainte d'exclusion entre les deux associations "Contracter" pour interdire à une personne de se marier avec elle même.
    A ce propos, d'après ma réponse (#9), la contrainte d'exclusion ne me semblait pas convenir parfaitement, je n'ai peut-être pas très bien compris, mais l'antiréflexivité m'a paru plus logique. Non?


    Citation Envoyé par CinePhil Voir le message
    Les contraintes autorisant ou non le mariage homo et/ou polygame dépendant du pays ou est "situé" le mariage ne sont pas modélisables à mon avis autrement que par des annotations.
    Je suis plutôt d'accord.

  18. #18
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Citation Envoyé par CinePhil
    Au final, je verrais bien une table des mariages structurée de la sorte :
    mariage (mar_id, mar_id_conjoint1, mar_id_conjoint2, mar_id_pays, mar_date_debut)
    mar_id serait autoincrémenté.
    mar_id_pays permettrait de vérifier si le pays référencé autorise le mariage homosexuel et/ou polygame.
    ==> hum... je ne suis pas certain que ce soit une bonne idée. En effet, la double (voir triple) nationalité existe. Nous pouvons donc imaginer une personne possédant la double nationalité avec, le PaysA étant monogame et le PaysB (je ne parle pas d'économie...) polygame.

    Nous pouvons stocker l'information "monigame/polygame" au niveau du pays, mais ce ne serait qu'une information proposée, par défaut, en saisie du mariage (et donc modifiable). Et encore, proposée par défaut, uniquement si les deux conjoints font partie d'un pays avec cette information commune.... sinon, le "créateur" du mariage aura la responsabilité de saisir l'information correcte.

    Je ne sais pas si j'ai été bien clair, sur ce coup là...
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  19. #19
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2009
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juillet 2009
    Messages : 45
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par Richard_35 Voir le message
    ==> hum... je ne suis pas certain que ce soit une bonne idée. En effet, la double (voir triple) nationalité existe. Nous pouvons donc imaginer une personne possédant la double nationalité avec, le PaysA étant monogame et le PaysB (je ne parle pas d'économie...) polygame.
    Dans ce cas, ça ne dépendrait pas du pays (lieu du mariage) mais des nationalités des mariés.

    Mais comme le disait CinePhil:

    Citation Envoyé par CinePhil
    Les contraintes autorisant ou non le mariage homo et/ou polygame dépendant du pays ou est "situé" le mariage ne sont pas modélisables à mon avis autrement que par des annotations.

  20. #20
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Dans ce fil, nous imaginons, en fait, qu'il existe une sorte de gourvernement mondial qui demande à son service informatique de développer une application gérant les mariages terriens (en attendant les autres...).

    D'autre part, ce gouvernement ne souhaite pas imposer un type de mariage unique, mais laisser "en fonction" les traditions culturelles locales. Donc, avoir une entité Pays où stocker le type de mariage en vigueur semble une bonne idée, mais ce ne serait qu'une information. Le pays, effectivement, serait retrouvé via la nationalité des époux.

    Dans cette optique, il semble nécessaire de stocker l'information "monogame/polygame" au niveau du mariage : c'est ce niveau final qui l'emporterait.

    Il semble, également, que n'information "mariage homosexuel permis O/N" devra être stocké au niveau du pays... là, intervient, il me semble, un troisième larron : le PaysC, pays où est célébré le mariage... qui peut être plus (ou moins) "permissif" que le pays des nationalités des époux.

    De moins en moins simple, l'histoire...
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 3 123 DernièreDernière

Discussions similaires

  1. Mettre en relation les contrôles DBLookUpComboBox et DBGrid
    Par Gendarmette dans le forum Bases de données
    Réponses: 7
    Dernier message: 19/01/2004, 14h16
  2. [Relations] afficher les relations entre 2 tables
    Par dzincou dans le forum PostgreSQL
    Réponses: 5
    Dernier message: 14/01/2004, 18h07
  3. [EJB2.1 Entity] [CMR] Relation One to Many
    Par hamed dans le forum Java EE
    Réponses: 2
    Dernier message: 31/12/2003, 15h26
  4. Réponses: 2
    Dernier message: 26/09/2003, 16h54
  5. Problème avec mes tables de relation...
    Par mmike dans le forum PostgreSQL
    Réponses: 4
    Dernier message: 02/06/2003, 16h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo