Quand faut-il une table associative ?

Publié le par

Mise à jour du 11/12/2012 : Ajout des contraintes d’unicité sur le cas 01. Merci à Richard_35 pour la suggestion et le travail complémentaire.

Ceux qui connaissent le modèle conceptuel de données (MCD) de la méthode Merise savent que lorsque les cardinalités maximales d’une association sont toutes deux à n, cela entraînera la création d’une table associative dans la base de données.

Mais il y a d’autres cas et certains suscitent quelques débats au sein des forums.

Examinons tous les cas possibles…

Soit deux entités A et B et une association entre elles. Les 16 associations possibles sont les suivantes :
01) A -0,1—-associer—-0,1- B
02) A -0,1—-associer—-1,1- B
03) A -0,1—-associer—-0,n- B
04) A -0,1—-associer—-1,n- B
05) A -1,1—-associer—-0,1- B
06) A -1,1—-associer—-1,1- B
07) A -1,1—-associer—-0,n- B
08) A -1,1—-associer—-1,n- B
09) A -0,n—-associer—-0,1- B
10) A -0,n—-associer—-1,1- B
11) A -0,n—-associer—-0,n- B
12) A -0,n—-associer—-1,n- B
13) A -1,n—-associer—-0,1- B
14) A -1,n—-associer—-1,1- B
15) A -1,n—-associer—-0,n- B
16) A -1,n—-associer—-1,n- B

On remarque que les cardinalités de l’association 02 sont inversées par rapport à l’association 05, de même pour la 03 et la 09, la 04 et la 13, la 07 et la 10, la 08 et la 14, la 12 et la 15.
Il ne reste donc plus que les 10 cas suivants :
01) A -0,1—-associer—-0,1- B
02) A -0,1—-associer—-1,1- B
03) A -0,1—-associer—-0,n- B
04) A -0,1—-associer—-1,n- B
06) A -1,1—-associer—-1,1- B
07) A -1,1—-associer—-0,n- B
08) A -1,1—-associer—-1,n- B
11) A -0,n—-associer—-0,n- B
12) A -0,n—-associer—-1,n- B
16) A -1,n—-associer—-1,n- B

Commençons par les cas les plus faciles…
Comme dit en introduction, il faut une table associative lorsque les cardinalités maximales sont à n. Il s’agit ici des 3 derniers cas, 11, 12 et 16.
Lorsque que les cardinalités sont à 1,1 d’un côté d’une association, il y aura une clé étrangère dans la table issue de l’entité située du côté des cardinalités 1,1. Il s’agit ici des cas 02, 07 et 08. Le cas 06 appelle des commentaires que je ferai plus tard…

Inscrivons ces cas simples dans le tableau :
01) A -0,1—-associer—-0,1- B
02) A -0,1—-associer—-1,1- B => Clé étrangère dans la table issue de l’entité B
03) A -0,1—-associer—-0,n- B
04) A -0,1—-associer—-1,n- B
06) A -1,1—-associer—-1,1- B
07) A -1,1—-associer—-0,n- B => Clé étrangère dans la table issue de l’entité A
08) A -1,1—-associer—-1,n- B => Clé étrangère dans la table issue de l’entité A
11) A -0,n—-associer—-0,n- B => Table associative
12) A -0,n—-associer—-1,n- B => Table associative
16) A -1,n—-associer—-1,n- B => Table associative

Examinons maintenant les cas qui restent, en commençant par le 06, qui semblerait entrer dans la seconde catégorie des cas faciles…

Cas 06) A -1,1—-associer—-1,1- B
Lorsque les deux couples de cardinalités sont à 1,1, on doit se demander si on peut fusionner les deux entités. Si elles représentent des choses sémantiquement différentes ou si on les conserve pour une raison technique (ajout de table à une BDD existante, amélioration des performances par séparation de données importantes en volume mais rarement lues…), on a le choix de la table qui accueillera la clé étrangère.

Cas 04) A -0,1—-associer—-1,n- B
La clé étrangère ne peut pas aller dans B puisque un B peut être associé à plusieurs A. Mais elle ne peut pas non plus aller dans A puisque un A peut ne pas être associé à un B. Il faut donc une table associative. Et comme un A sera associé au maximum une seule fois à un B, la clé primaire de la table associative sera la clé étrangère référençant A.

Cas 03) A -0,1—-associer—-0,n- B
Aucune des deux entités n’est systématiquement associée à l’autre (cardinalités minimales à 0). Il faut donc une table associative dont la clé primaire sera, pour la même raison que dans le cas 04, la clé étrangère référençant A.

Cas 01) A -0,1—-associer—-0,1- B
Pour la même raison que dans le cas 03, il faut une table associative. Et pour la même raison que dans le cas 06, on a le choix de la clé étrangère qui sera également clé primaire, l’autre clé étrangère devant être munie d’une contrainte d’unicité.

Complétons le tableau :
01) A -0,1—-associer—-0,1- B => Table associative avec le choix de la clé primaire.

  • A (IdA, …) ;
  • B (IdB, …) ;
  • AB (#IdA, #IdB, …) + index unique sur #IdB
    ou AB(#IdB, #IdA, …) + index unique sur #IdA.

02) A -0,1—-associer—-1,1- B => Clé étrangère dans la table issue de l’entité B

  • A (IdA, …) ;
  • B (IdB, #IdA, …).

03) A -0,1—-associer—-0,n- B => Table associative dont la clé primaire référence A

  • A (IdA, …) ;
  • B (IdB, …) ;
  • AB (#IdA, #IdB, …).

04) A -0,1—-associer—-1,n- B => Table associative dont la clé primaire référence A

  • A (IdA, …) ;
  • B (IdB, …) ;
  • AB (#IdA, #IdB, …).

06) A -1,1—-associer—-1,1- B => Fusion des deux entités ou clé étrangère dans A ou B

  • AB (IdAB, {attributs de A}, {attributs de B}, …).

ou :

  • A (IdA, #IdB, …) ;
  • B (IdB, …).

ou

  • A (IdA, …) ;
  • B (IdB, #IdA, …).

07) A -1,1—-associer—-0,n- B => Clé étrangère dans la table issue de l’entité A

  • A (IdA, #IdB, …) ;
  • B (IdB, …) ;

08) A -1,1—-associer—-1,n- B => Clé étrangère dans la table issue de l’entité A

  • A (IdA, #IdB, …) ;
  • B (IdB, …) ;

11) A -0,n—-associer—-0,n- B => Table associative

  • A (IdA, …) ;
  • B (IdB, …) ;
  • AB (#IdA, #IdB, …).

12) A -0,n—-associer—-1,n- B => Table associative

  • A (IdA, …) ;
  • B (IdB, …) ;
  • AB (#IdA, #IdB, …).

16) A -1,n—-associer—-1,n- B => Table associative

  • A (IdA, …) ;
  • B (IdB, …) ;
  • AB (#IdA, #IdB, …).

Sur 10 cas, il y en a donc 6 qui nécessitent une table associative !

== Mise à jour du 20/09/2011 ==
Suite à une question posée par cretthie dans une discussion du forum MySQL/Requêtes, j’apporte des précisions pour les cas demandant une table associative.

01) Il y aura une clé étrangère référençant A et une autre référençant B. On a le choix de décider quelle clé étrangère constituera également, toute seule, la clé primaire de la table. L’autre colonne portant la seconde clé étrangère sera en plus munie d’une contrainte d’unicité (index de type UNIQUE chez MySQL) pour respecter la cardinalité 0,1.
03) et 04) Là aussi, la clé primaire n’est constituée que d’une seule des deux clés étrangères : celle référençant A. L’autre est une clé étrangère « ordinaire ».
11), 12) et 16) Dans ces trois cas, la clé primaire de la table associative est composée des clés étrangères référençant A et B.

38 réflexions au sujet de « Quand faut-il une table associative ? »

  1. Article intéressant (je pense qu’on peut également parler de table intermédiaire) qui permet de réduire le flou à ce sujet.

    En parlant du MCD/MLD, je me demande si les tables clé+valeur (deux colonnes) auraient une raison d’être d’un point de vue analyse/modélisation ainsi que les structures créées à la volée par un utilisateur où l’on ne connais pas la nature d’une entité et ses données à l’avance.

  2. je pense qu’on peut également parler de table intermédiaire

    Je préfère utiliser le terme « table associative » car elle est issue d’une association du MCD.

    je me demande si les tables clé+valeur (deux colonnes) auraient une raison d’être d’un point de vue analyse/modélisation

    Oui, notamment pour les tables de référence telles que : civilité, pays, type, genre, catégorie… encore que certaines des tables que j’ai citée peuvent avoir plus de deux colonnes.

    ainsi que les structures créées à la volée par un utilisateur où l’on ne connais pas la nature d’une entité et ses données à l’avance

    Là c’est plus délicat ! Dans quel cas un utilisateur peut-il être amené à créer de nouvelles données pouvant constituer des entités ne figurant pas dans le modèle d’origine ?

  3. Il y a une table pays ains que d’autres tables du genre au niveau d’un site sur lequel je travaille. Ce qu’il y a aussi c’est une table utilisé par un forum (FluxBB pour le nommer) qui ressemble à ceci:

    Structure:
    conf_name varchar(255)
    conf_value text

    Contenu:
    o_additional_navlinks
    o_admin_email admin@***.com
    o_announcement 0
    o_announcement_message Enter your announcement here.
    o_avatars 1
    o_avatars_dir img/avatars
    o_avatars_height 60
    o_avatars_size 10240
    o_avatars_width 60
    …

    C’est assez inhabituel et je ne vois pas ce qui justifierais cette approche au niveau d’une analyse.

    « Là c’est plus délicat ! Dans quel cas un utilisateur peut-il être amené à créer de nouvelles données pouvant constituer des entités ne figurant pas dans le modèle d’origine ? »

    Je ne sais pas si c’est un bon exemple mais je pense au modèle d’une médiathèque qui possède une entité Media et des entités secondaires pour reprendre les détails spécifiques à chaque type de média. On pourrais avoir des entités reprenant respectivement les informations propres aux livres, aux cd audio, aux dvd vidéo et aux cd-roms.

    Si un nouveau média fait son apparition on devra modifier la base de données. Ou alors on refait une analyse de sorte à prévoir la possibilité de définir un nouveau média. Dans ce cas, j’imagine qu’on pourrait avoir une entité « TypeMedia » et une entité « DonneesMedia » avec une table associative entre les deux. Si cette solution serait valable d’un point de vue conceptuel (?) il resterais à effectuer un choix au niveau de l’implémentation avec les différents types de données qui peuvent exister.

  4. Tu veux dire que le forum est sur une seule table composée des deux colonnes conf_name varchar(255) et conf_value text et que la seconde est composée de plusieurs données o_quelque_chose ?

    Si c’est ça ce n’est pas un schéma relationnel normalisé !

    Effectivement, si on a potentiellement une infinité de types de media, alors il faut penser à la modélisation par métadonnées ou à l’association entre les types de media et leurs caractéristiques.
    type_media -1,n—-avoir—-1,n- caracteristique

    Pour arriver à chaque media physique, il faut transformer l’association ci-dessus en entité :
    type_media -1,n—-avoir—-(1,1)- carac_type_media -(1,1)—-caractériser—-1,n- caracteristique

    Ensuite on peut associer carac_type_media à media :
    media -1,n—-avoir—-0,n- carac_type_media
    |——1,1—-typer—-0,n- type_media

    Et il faut prévoir une contrainte d’inclusion entre les associations « avoir » et « typer » de manière à empêcher qu’un media ait des caractéristiques qui ne correspondent pas à son type.

    il resterais à effectuer un choix au niveau de l’implémentation avec les différents types de données qui peuvent exister.

    Dans ce genre de schéma, comme les valeurs des caractéristiques peuvent être de tout type (numérique, alphanumérique, booléen, date…), on peut créer des colonnes pour chaque type, ce qui entraîne systématiquement des colonnes à NULL, ou bien prendre seulement le type VARCHAR et faire un transtypage dans les requêtes.

    Il y a eu plusieurs discussion sur ces sujets dans le forum Schéma.

  5. Tu veux dire que le forum est sur une seule table composée des deux colonnes conf_name varchar(255) et conf_value text et que la seconde est composée de plusieurs données o_quelque_chose ?

    Si c’est ça ce n’est pas un schéma relationnel normalisé !

    Oui. Donc c’est tout à fait normal et au niveau MCD on aurait une entité configuration avec comme attributs nom_configuration et valeur_configuration. Merci pour les explications concernant le deuxième cas de figure. Je jetterais un coup d’oeil au forum.

  8. Une question plus générale serait: est-ce qu’une association–2,2–()–0,n– est équivalente à deux associations –1,1—()–0,n ?

    Tu joues au tiercé ;-) ?
    Tiercé—-3,3—-classer—–0,n—–Cheval

    Avec la table Tiercé(idTiercé, DateCourse, Hippodrome,…,#idChevalVainqueur, #idChevalDeuxieme, #idChevalTroisieme)

    Si tu voulais avec une requête rechercher le nombre de tiercés où le cheval « Rafale des Ongrais » apparait, ne préfèrerais-tu pas avoir une table associative (#idTiercé, #idCheval, Classement) ?

  9. Une question plus générale serait: est-ce qu’une association–2,2–()–0,n– est équivalente à deux associations –1,1—()–0,n

    En théorie, je dirais oui. Mais tu cites juste après le cas réel du tiercé qui s’avère peu pratique.
    Et dans la mesure où une course de chevaux ne classe pas seulement les 3 premiers mais tous les participants, lesquels sont en nombre variable selon les courses, il est évident qu’une table associative porteuse de la place obtenue par le cheval à l’arrivée est plus appropriée.

  10. Bonjour,

    En lisant votre article, j’ai été surpris notamment par la création d’une table d’associations sur une relation A -0,1—-associer—-1,n- B (cas 4).
    En effet,il aurait paru logique de définir la relation sur A, si celle-ci existe, et de laisser la valeur à null si elle n’existe pas.

    Quels sont les avantages d’utiliser une table d’associations ?

    Merci d’avance pour votre réponse.

  11. Parce que NULL est banni de la théorie relationnelle et est à bannir autant que possible des bases de données relationnelles. Cherche les messages de fsmrel, notamment sur le forum Schéma, il explique ça longuement.

    Une raison plus pragmatique est que A peut être associé rarement à B. Plutôt que d’avoir une majorité de lignes avec la clé étrangère, faisant référence à B, à NULL, il vaut mieux avoir une table associative qui ne concernera que la minorité de lignes en association avec un B.

  12. Effectivement, cependant cela implique également une jointure supplémentaire lorsque l’on souhaite récupérer nos objets liés.

    Du coup, en admettant que j’ai 50% de mes objets A qui sont liés à un objet B, est-ce toujours préférable d’utiliser une table d’association, même en terme de performances ?

  13. Il ne faut pas avoir peur des jointures, c’est l’opération la plus optimisée dans les SGBD dignes de ce nom !

    Avec une petite quantité de données, la différence sera imperceptible. Avec des millions de lignes, il est fort possible que certaines opérations soient polluées par la profusion de NULL dans la table.

    Pour plus d’explications sur le bonhomme NULL : voir le chapitre que fsmrel lui consacre;

    Voir aussi mon message dans une discussion qui est je pense à l’origine de cet article, ainsi que la réponse de fsmrel.

    Et un autre message de fsmrel !

  14. Bravo pour l’exhaustivité (à 95%) des cas possibles ! Tout le monde devrait avoir cette liste sous le coude.

    Pourquoi « (à 95%) » ?
    Parce que le cas présenté par F-leb est, de mon point de vue, intéressant : il consiste à analyser les « 0,x / x,x / x,0″ (avec x1 et x0) différemment des « 0,1 / 1,1 / 1,0″. Mais, c’est vrai, nous n’utilisons pas souvent ces cardinalités.

    Néanmoins, avec ce genre de cardinalité, je pense qu’il est préférable de créer une table associative afin de stocker la clé concernée dans un seul champ. Dans l’exemple de F-leb :
    Tiercé(#idTiercé, #idCheval, Classement) me semble préférable à Tiercé(idTiercé, DateCourse, Hippodrome,…,#idChevalVainqueur, #idChevalDeuxieme, #idChevalTroisieme).

  15. C’est peut-être pour ça que la méthode Merise ne semble pas prévoir, à ma connaissance, de cardinalité différente de 0, 1 ou n, contrairement au diagramme de classes UML ou il n’est pas interdit de mettre une multiplicité différente de 0, 1 ou *.
    Exemple :
    droite *———–2 point

    Une droite est définie par deux points et un point peut définir plusieurs lignes.

  16. Merci de ton retour.

    Si la méthode Merise n’a pas prévu ce genre de cardinalité, il serait peut-être bon, humblement, de la compléter.

    Ces cardinalités se présentent, notamment, pour des entités à nombre d’éléments déterminés : mois de l’année, jours de la semaine, tiercé, loto, etc…

  17. Les cas où ces cardinalités déterministes et supérieures à 1 sont nécessaires me semblent toutefois très rares !

    J’ai parlé plus haut du cas du tiercé où, en fait, le classement concerne tous les chevaux, même si on ne retient que les 3 premiers pour le palmarès.

    En supposant qu’un MCD présente une association de ce type :
    entite -12,12—-association—-0,n- mois

    J’inviterais le concepteur à se demander s’il est vraiment utile d’enregistrer 12 fois d’un coup l’association entre l’entité et le mois !
    Soit l’association ne porte pas de donnée et on enregistre en fait 12 fois la même information pour chacun des mois, soit elle est porteuse de données et en fait on enregistrera successivement 12 associations différentes, c’est à dire 12 lignes dans la table associative, ce qui revient à des cardinalités 0,n à la place de 12,12.

  18. Les cardinalités mini du genre 2 et plus, les cardinalités maxi du genre 2 et plus (définies) sont utilisées depuis les débuts de Merise (voyez page 22 du document officiel de 1979 : Ministère de l’Industrie – Mission à l’informatique – Centre technique informatique – Méthode de définition d’un système d’informations – Fascicule 4, guide pratique pour l’élaboration des modèles de données et de traitements – juin 1979).

    D. Nanci écrit que ces cardinalités sont possibles (Ingénierie des systèmes d’information Merise, deuxième génération).

    Y. Tabourier s’en sert (cf. « De l’autre côté de Merise »).

    Voyez aussi son métamodèle de contraintes :
    http://www.developpez.net/forums/d1059085/general-developpement/conception/methodes/merise/nouvel-outil-modelisation-merise/#post5879976

  19. Merci François.
    Dans le long message que tu m’as envoyé et que j’ai découvert avant ta courte réponse ici, tu fournis un schéma figurant dans le document officiel que tu cites et dont je reproduis ci-dessous une association qui nous intéresse dans cette discussion :
    Elle concerne les enfants et les personnes qui les élèvent (parents ou tuteurs légaux).
    personne -0,n—-elever
    |———0,2———|
    Traduction : Une personne peut élever plusieurs personnes et une personne (un enfant) peut être élevée par au maximum deux personnes (ses parents par exemple).

    J’ai plus de mal à traduire la seconde association de ce même schéma comprenant une cardinalité supérieure à 1 :
    personne -0,1—-compte_bancaire—-1,2- domiciliation

    Pour moi, un compte bancaire serait plutôt une entité type et la domiciliation une association !

    Comme quoi, pour qu’un MCD soit lisible, il vaut mieux utiliser des verbes pour les associations et des noms pour les entités types !

  20. Bonjour CinePhil,

    Jusque là, je n’avais pas trop compris l’usage, et donc, l’intérêt, des parenthèses dans les cardinalités.

    Il me semble avoir compris que celles-ci sont utilisées quand une entité « ne peut pas vivre » sans celle qui lui est associée. Donc, dans les 10 cas « survivants » à ton analyse, cela concernerait toutes les cardinalités x,y dont x différent de 0, non ?

    Si la mienne est correcte (l’analyse), l’information transmise par les parenthèses est redondante, donc non nécessaire.

    Si elle n’est pas correcte, où se placeraient-elles ?

  21. Jusque là, je n’avais pas trop compris l’usage, et donc, l’intérêt, des parenthèses dans les cardinalités.

    Les parenthèse autour des cardinalités dans les MCD signifient en principe qu’il s’agit d’une identification relative.

    Exemple : Facture -1,n—-comprendre—-(1,1)- Ligne_facture

    => La ligne de facture est identifiée relativement à la facture. En conséquence, quand on passera à la génération des tables, l’identifiant de la facture fera partie de la clé primaire de la table ligne_facture :
    facture (fac_id, …)
    ligne_facture (lf_id_facture, lf_numero…)

    Donc, dans les 10 cas « survivants » à ton analyse, cela concernerait toutes les cardinalités x,y dont x différent de 0, non ?

    Non, l’identification relative est loin d’être systématique.
    Rien que dans mon exemple ci-dessus, il y a une ligne de facture au minimum mais ce n’est pas la facture qui est identifiée relativement à la ligne mais bien le contraire !

  22. Exact.

    « La ligne de facture est identifiée relativement à la facture. »
    ==> effectivement, une ligne de facture « ne peut pas vivre » sans la facture.

    La « règle » pourrait donc être :
    « Dans les 10 cas « survivants » à ton analyse, cela concernerait toutes les cardinalités x,y dont x différent de 0, uniquement pour les parties droites (complément d’objet direct de l’association exprimée en français). »

    Non ?

  23. Non, ça n’a rien à voir !

    Personne -0,n—-diriger—-1,1- Projet
    Cette association exprime le fait que le projet est dirigé par une seule personne mais il n’est pas identifié relativement à la personne, il a son existence propre et si le chef de projet quitte l’entreprise, on le remplacera par un autre mais on ne détruira pas le projet.

    L’autre cas classique où on utilise une identification relative est l’héritage de données :
    salarie -(1,1)—-etre—-0,1- personne
    contact -(1,1)—-etre—-0,1- personne

    Tables :
    personne (prs_id, [colonnes communes à toutes les personnes])
    salarie (slr_id_personne, [colonnes spécifiques aux salariés])
    contact (cnt_id_personne, [colonnes spécifiques aux contacts]

  25. Je me lance dans les BDR avec H2 en java pour un projet perso auquel je reviendrai.
    J’ai essayé d’appliquer les conseils trouver sur le tutoriel « Conception d’une base de données » de Cyril Gruau puis cet article.
    Malheureusement je n’y arrive pas malgré de nombreuses heures de travail et je pense que c’est avant tout parce qu’un certain nombre de choses m’échappent. Voici le problème :
    Je dispose d’un ensemble de textes dont les attributs sont un identifiant bien sûr, un titre. J’ai aussi une table de sujets dont les attributs sont un identifiant et un nom. Chaque texte correspond à un sujet et un seul. Chaque sujet eut correspondre à aucun ou plusieurs textes. Jusque là c’est simple.
    textes 1,1 —- correspondre —- 0,n sujets
    Je n’ai pas très bien compris l’histoire des parenthèses.
    Là où cela se complique c’est que chaque texte est mis en relation avec 0, 1 ou plusieurs autres textes. Ces relations sont de 2 types : suivant ou précédent

    Un texte A peut avoir de 0 à n suivants
    Un texte A peut avoir de 0 à n précédents
    A est suivant de B si et seulement si B est précédent de A

    textes 0,n —- suivre —- 0,n textes
    Mais comment représenter cela et quelle table associative utilisée ?
    Je suis désolé si ma question vous parait simpliste mais je n’y arrive vraiment pas. J’aurai d’ailleurs d’autres questions à venir.

  26. @Patrice Henrio
    Cette question aurait plus sa place dans le forum Schéma mais bon…

    Un texte A peut avoir de 0 à n suivants
    Un texte A peut avoir de 0 à n précédents
    A est suivant de B si et seulement si B est précédent de A

    textes 0,n —- suivre —- 0,n textes
    Mais comment représenter cela et quelle table associative utilisée ?

    Plutôt que de parler de précédents et de suivants, contentons-nous de l’association suivre que vous avez correctement modélisée et qui correspond à la règle de gestion suivante :
    Un texte peut suivre plusieurs textes et un texte peut être suivi par plusieurs textes.

    Dès lors, la table associative à créer est évidente :
    txt_suivre_txt (tst_id_texte_fils, tst_id_texte_pere)

  31. Svp , je m’excuse car je débute mais expliquez moi comment en doit interpréter les cardinalités car j’avais eu du par exemple :

    A -0,1—-associer—-0,1- B

    veut être ineterprété comme suit
    A min,max—-associer—-min,max- B

    que question doit on poser pour déterminer d’abord le min sur A ensuite son max
    et parei pour le B (min, max)
    pour le min je comprends un peu on doit se poser la question s’il y a 1 ou voire n’y a pas 0 qui s’associe pareil pour le b
    après c’est sur le max que je suis un peu perdu
    dire que A 0 ,1 veut qire qu’il n’y a qu’une et une seule relation accepté pour s’associer à B mais être ne pas associer aussi est acceptable ??

  32. Pour lire une association, comme disait M. Mazet, mon prof du CNAM, « on s’arrête à la patate ! »
    C’est à dire qu’on coupe l’association en deux et qu’on lit les deux morceaux séparément.

    Pour reprendre ton exemple :
    A -0,1—-associer—-0,1- B

    Je coupe en deux :
    1) A -0,1—-associer
    2) associer—-0,1- B

    La partie 1 va déterminer combien de fois A participe à l’association ; ici, au minimum zéro et au maximum une fois.

    Idem pour la partie 2 qui va déterminer combien de fois B participe à l’association ; ici, au minimum zéro et au maximum une fois.

    Donc la règle de gestion qui implique ce MCD est la suivante :
    Un A peut être associé une seule fois à un B et un B peut être associé une seule fois à un A.

  34. C’ est plus fort que moi! je ne pouvais m’ empêcher de vous tirer bas le chapeau et de vous dire un grand MERCI pour ces explications. D’ un coup grâce à elles j’ apprivoise un p’ tit peu les mérises.
    Je ne prétends pas en être devenue experte (car j’ ai besoin d’ exercises) mais le travail fait par vous, les explications précises et concises ansi que la patience dont vous faîte preuve m’ apportent (personnelement) beaucoup.
    MERCI encore!

  35. Merci CinePhil.
    J’ai trouvé votre discussion du cas (0;1)-(0;1) très intéressante. D’ailleurs, la méthode concurrente anglo-saxonne SSADM interdit de laisser ce cas scindé.
    Mais je reconnais que je n’ai pas compris le cas 04):
    « Mais elle ne peut pas non plus aller dans A puisque un A peut ne pas être associé à un B. » –> Pourquoi?
    -Peut-être cela mériterait d’être explicité avec des tables A et B peuplées (juste une enregistrement de chaque.
    À +!

    • Commençons par rappeler ici ce cas 04 :
      04) A -0,1—-associer—-1,n- B
      Pourquoi la clé étrangère ne peut-elle pas aller dans A ?
      Et bien parce que la cardinalité mini du côté de A est zéro.
      Exemple : Imaginons l’affectation des clés des bureaux et bâtiments aux personnes de l’entreprise.
      Règle de gestion :
      Une clé peut être confiée à une seule personne et une personne se voit confier de une à plusieurs clés.

      MCD :
      Clé -0,1—-confier—-1,n- Personne

      Tables :
      te_cle_cle (cle_id, cle_numero…)
      te_personne_prs (prs_id, prs_matricule, prs_nom, prs_prenom…)
      tj_cle_confier_prs_ccp (ccp_id_cle, ccp_id_personne, ccp_date_attribution…)

      La clé primaire de la table tj_cle_confier_prs_ccp sera ccp_id_cle puisqu’une clé ne peut être confiée à seulement une seule personne et ne sera donc présente qu’une seule fois dans la table associative.

      • Merci CinePhil,
        Mais, excusez-moi si je vous parais borné, mais vous expliquez – si j’essaie de résumer bien – une fois que la table associative (ou j’imagine que tj signifie table de jointure) est créé, en fait, que sa nécessité se justifie par elle-même (sa clé primaire, plus particulièrement).
        (Oui, on aimerait bien que ce qui se conçoit bien s’énonce clairement, mais ça n’empêche les raisonnements circulaires.)
        Or la question était de savoir si nous devions créer, simplement, cette table associative (vous affirmez en début de blog que oui).

        Personnellement, mon raisonnement est concis, et consiste à rappeler qu’une clé étrangère n’est pas forcément requise!

        Ainsi, si j’ai [null] pour la clé étrangère des clefs d’immeuble, elle sera liée à rien, en particulier: aucune personne, le cas de la cardinalice zéro est respecté.

        Si par contre, j’ai une valeur pour cette clé étrangère dans un autre enregistrement (des clefs d’immeuble), elle sera liée à la clé primaire de la personne…

        Donc, honnêtement, je ne vois toujours pas de nécessité de table associative. Désolé.

        • Ainsi, si j’ai [null] pour la clé étrangère

          Comme expliqué plus haut dans les commentaires et abondamment par ailleurs par fsmrel, NULL est à bannir des bases de données !
          À plus forte raison des clés étrangères !
          La présence d’une clé étrangère signifie qu’une table est liée à une autre.
          Il est par contre possible d’avoir une valeur liée qui correspond à une information inconnue.

          Exemple avec le sexe d’une personne…
          On décide que toute personne a un sexe et on modélise ainsi :
          Personne -1,1—-avoir—-0,n- Sexe

          Du coup on fait les tables suivantes :
          tr_sexe_sxe (sxe_id, sxe_code, sxe_libelle, sxe_ordre)
          te_personne_prs (prs_id, prs_id_sexe, prs_nom, prs_prenom…)

          Et on commence par remplir la table de référence :
          tr_sexe_sxe (sxe_id, sxe_code, sxe_libelle, sxe_ordre)
          1, ‘H’, ‘Homme’, 1
          2, ‘F’, ‘Femme’, 2

          Puis on remplit petit à petit la table des personnes :
          te_personne_prs (prs_id, prs_id_sexe, prs_nom, prs_prenom…)
          1, 1, ‘Dupont’, ‘Alain’…
          2, 2, ‘Durand’, ‘Brigitte’…
          3, 1, ‘Martin’, ‘Xavier’…

          Mais on se rend compte après coup que l’information sur le sexe de la personne n’est pas toujours connue, quand on veut enregistrer Dominique Latour !
          On peut alors, sans changer le modèle, ajouter une ligne à la table de référence, plutôt que de laisser la clé étrangère référençant le sexe à NULL (ce qui est normalement interdit).
          tr_sexe_sxe (sxe_id, sxe_code, sxe_libelle, sxe_ordre)
          3, ‘I’, ‘Inconnu’, 4

          Et du coup je peux enregistrer Dominique Latour en attendant d’avoir l’information :
          te_personne_prs (prs_id, prs_id_sexe, prs_nom, prs_prenom…)
          4, 4, ‘Latour’, ‘Dominique’…

Laisser un commentaire