Discussion :

[new_wave]

Bonjour,

A propos des associations de type 1:1, voici l'explication que je trouve concernant le passage du mcd au mld
Les tables concernées par ce type d'association doivent avoir la même clef.

Mais plus loin je vois écrit que certains proposent une autre solution, et l'on voit que la clef de la table côté 1,1 migre vers la table coté 0,1 et devient clef étrangère de cette table.
Si je prends l'exemple de l'association "avoir conjoint" et de l'entité "individu" dont l'identifiant est id_individu.
On peut dire qu'un individu peut avoir 0 ou 1 conjoint et qu'un conjoint peut être le conjoint d'aucun ou de un individu.
Cette association est donc de type (1,1) avec les cardinalités (0,1) et (0,1).
Au niveau du MLd, ne devrais je pas créer une nouvelle table qui aurait pour clé primaire la conjonction de deux id_individu : la partie droite de l'identifiant representerait l'individu conjoint .
Que doit on faire exactement dans les trois cas précis suivants:

association de type 1,1 avec les cardinalités
(0,1), (1,1)
(0,1) ,(0,1)
(1,1),(1,1)

Merci infiniment de votre aide et de votre patience pour m'expliquer correctement ce qui doit être fait.

Bien cordialement et avec tous mes voeux de bonne année 2008.

Nathalie

[fsmrel]

Bonsoir,

Les tables concernées par ce type d'association doivent avoir la même clef.

Qu’est-ce que vous entendez par "avoir la même clef" ? Illustrez à l’aide d’un exemple concret.

On peut dire qu'un individu peut avoir 0 ou 1 conjoint et qu'un conjoint peut être le conjoint d'aucun ou de un individu.

Il est vrai qu’un individu a facultativement un conjoint. Mais, quand on est conjoint, c’est nécessairement de quelqu’un. Quand vous écrivez qu'un conjoint peut être le conjoint d'aucun ou de un individu, vous formulez une contradiction.

Au niveau du MLd, ne devrais je pas créer une nouvelle table qui aurait pour clé primaire la conjonction de deux id_individu

Qu’entendez-vous par "conjonction" ? L’union au sens de la théorie des ensembles ? Utilisez la langue française à bon escient, ou à tout le moins illustrez une fois de plus avec des exemples concrets. Je vais quand même supposer que vous suggérez que la clé primaire de votre nouvelle table est composée d’un couple {id_individu1, id_individu2}. Si tel est le cas, vous admettez implicitement que les cardinalités initiales sont 0,N et 0,N, ce qui est contradictoire avec votre hypothèse de départ (cardinalités 0,1 et 0,1).


Concernant vos 3 cas relatifs au thème "association de type 1,1 avec les cardinalités" : La 1re règle est de ne pas produire de valeurs nulles dans les tables dérivées de vos MCD.
Soit A et B deux entités-types en relation par le biais de l’association-type R et ayant pour identifiants respectifs cola et colp.
Considérons votre 1er cas :

A --- (0,1) ---- R ---- (1,1) --- B

Au niveau du MLD, on obtient quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
Create Table A
    (cola  typea   not null, 
     colb  typeb   not null, 
     ...,
   Primary key (cola))  ;
Create Table B
    colp  typep   not null, 
    colq  typeq   not null, 
    ...,
    cola  typea   not null,
   Primary key (colp))  ;
   Foreign Key (cola) References A  ;

Ou encore, si B est identifiée relativement à A :

Create Table B
    cola  typea   not null, 
    colq  typeq   not null, 
    ...,
   Primary key (cola))  ;
   Foreign Key (cola) References A  ;

En tout état de cause, la table A n’a pas à faire référence à la table B :

1) Ça créerait un cycle dont on ne pourrait se débarrasser.
2) Ça engendrerait des valeurs nulles.
3) Le rasoir d’Ockham nous incite à ne pas créer des choses inutiles et redondantes. En effet, par jointure naturelle sur cola, on sait tout de B à partir de A, inutile d’en rajouter.

Vous aurez noté l’absence de valeurs nulles. Ceci doit vous guider pour trouver la solution aux deux autres cas de figure.

Annexe :
Nous voulons bien prendre la peine de vous donner un coup de main, mais nous aimerions savoir si cela vous est utile. Votre silence incite à penser qu’il n’en est sans doute rien. Cf. :
http://www.developpez.net/forums/sho...d.php?t=459380
http://www.developpez.net/forums/sho...d.php?t=419916
http://www.developpez.net/forums/sho...d.php?t=419899
http://www.developpez.net/forums/sho...d.php?t=466740

[hed62]

Personnellement, j'ajouterais juste une propriété "Conjoint" dans la table "Individu". Cette propriété = 0 si pas de conjoint, ou X, X étant l'identifiant de l'individu conjoint.

[elbj]

Bonjour

Effectivement la solution de hed62 est envisageable, néanmoins elle va poser un problème de redondance. En effet, soit deux personnes A et B. Si je dois indiquer dans la colonne Conjoint de A l'ID de B alors il faut aussi que j'indique dans le colone Conjoint de B l'ID de A.

On peut aussi créer une table T_Conjoints qui contiendra une colonne pour le premier conjoint et une colonne pour le second conjoint. Chaque colonne devra avoir une contrainte d'unicité et d'exclusivité (si un ID apparait dans la première colonne, il ne doit pas apparaître dans la seconde et vice et versa). Pour la PK, je pense à un auto_incrément tout simple car aussi bien la colonne du premier conjoint que celle du second sont des clefs candidates valables mais elles ne me semblent pas pertinentes. Oublions aussi une PK formée de la concaténation des deux colonnes.

Enfin on crée une Vue, V_Conjoints, qui présentera l'intégralité de la liste, c'est elle qui sera utilisée dans les jointures. Ci-dessous je présente un code "light", il faudra bien entendu gérer les FK et autres contraintes.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE T_CONJOINTS_CJT (
  CJT_ID INTEGER IDENTITY PRIMARY KEY,
  PER_ID01 INTEGER UNIQUE,
  PER_ID02 INTEGER UNIQUE...)

CREATE VIEW V_CONJOINTS_VCJ
AS
SELECT
  PER_ID01 AS VCJ_ID01,
  PER_ID02 AS VCJ_ID02
FROM T_CONJOINTS_CJT
UNION
SELECT
  PER_ID02 AS VCJ_ID01,
  PER_ID01 AS VCJ_ID02
FROM T_CONJOINTS_CJT

Donc ça devrait donner quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
T_CONJOINTS_CJT
---------------
CJT_ID  PER_ID01 PER_ID02
------  -------- --------
   1        1         2
   1        3         5
   1        4         6
   1        8         7
   1        9         10

V_CONJOINTS_VCJ
---------------
VCJ_ID01  VCJ_ID02
--------  --------
    1         2
    2         1
    3         5
    4         6
    5         3
    6         4
    7         8
    8         7
    9        10
    10        9

Ainsi, lorsque je veux trouver le conjoint d'une personne je vais faire une jointure entre l'ID de la Personne et VCJ_ID01 de la Vue, cela me permet d'obtenir son conjoint.

Cordialement

[hed62]

Effectivement la solution de hed62 est envisageable, néanmoins elle va poser un problème de redondance. En effet, soit deux personnes A et B. Si je dois indiquer dans la colonne Conjoint de A l'ID de B alors il faut aussi que j'indique dans le colone Conjoint de B l'ID de A.

En effet, je n'y avais pas pensé sur le coup..

[elbj]

Un dernier avantage de ma proposition est de pouvoir la faire évoluer vers une qualification de la relation entre deux personnes (Mariés, Vie Maritale, etc...) qui peut aller plus loin que la notion de relation amoureuse (Parent, Collègue, etc...). Je dis cela parce que dans mon boulot nous avions eu à faire évoluer la base d'un de nos clients pour pouvoir stocker ce genre d'information. Donc en créant une table T_Relations_REL, on pourra avoir un REL_ID dans T_Conjoins_CJT (qui d'ailleurs ne devras plus se nommer ainsi car la sémantique de la table change).

+++