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

  1. #1
    Membre régulier
    Nouvelle demande concernant une table de liaison
    Bonjour.

    Je pars de 3 tables, T_BENEFICIAIRES, T_SALARIES, T_CONTACTS, reliées à T_PERSONNES. Les bénéficiaires sont des retraités ; les salariés des personnels de maison ; les contacts sont les tuteurs de certains bénéficiaires à qui les documents (factures, etc) sont envoyés.

    Je cherche donc à relier ces contacts aux bénéficiaires correspondant mais je ne sais pas comment faire. J'ai essayé d'insérer une FK CON_ID dans T_BENEFICIAIRES et ensuite une FK BEN_ID dans T_CONTACTS mais dans les deux cas je bute sur le NOT NULL de ces 2 colonnes, sachant que chaque bénéficiaire ne dispose pas d'un contact. Pour corser l'affaire, certains contacts peuvent avoir plus d'un bénéficiaire à charge (dans la pratique, deux maximum, mari et femme, qui ont chacun leur propre dossier, leur propres heures et donc leur propres factures). Je pense qu'il faut ajouter une table mais....................

    Merci.

    Schéma (très abrégé) :


  2. #2
    Expert éminent sénior
    Bonjour Nerva,


    Selon les pattes et les cardinalités de votre diagramme :

    (R1) Une personne est en relation avec au moins et au plus une bénéficiaire

    (R2) Un bénéficiaire est en relation avec au moins et au plus une personne

    Il y a donc bijection entre les ensembles T_PERSONNES et T_BENEFICIAIRES, ce qui est source d’emm... pour la base de données et la prudence et l’usage veulent que de ces deux tables on n’en fasse qu’une.

    Cela dit, vous fournissez certaines règles de gestion, comme celle-ci :  

    « Les bénéficiaires sont des retraités »

    Cela implique la mise en oeuvre de la spécialisation des entités-types. Il s’ensuit que la bijection est à remplacer par une injection (en mode patte d’oie) :

    [T_PERSONNE]--||---------o|--[T_BENEFICIAIRE]


    Je rappelle à cette occasion que les collègues ne connaissent pas nécessairement MySQL Workbench ! Et comme on vous l’a déjà dit, vous auriez avantage à utiliser Looping.
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  3. #3
    Expert éminent sénior
    Bonjour,

    Je n'aime pas ce type de représentation, un MCD serait le bienvenu.
    j'ai l'impression que bénéficiaires et contacts sont des sous-types de personnes, c'est bien ça ?
    Si c'est le cas, on retrouve le numéro de personne dans chacune des 4 tables, "personnes" bien sûr, et chacune des tables correspondant à chaque sous-type

    Ensuite, pour identifier quelle personne est sous tutelle de tel contact, il faut une association au niveau conceptuel entre contact et bénéficiaire.
    Donc une table associative ayant deux identifiants de personnes en attribut (personne bénéficiaire et personne contact)

    Je profite de l'occasion pour indiquer que le varchar n'est utile que pour les données dont la longueur effective varie et peut dépasser 20 à 25 caractères.
    En deçà, préférez le char fixe, ce sera plus performant (ex : pour ne numéro de sécurité sociale dont la longueur est fixe et bien inférieure à 25 caractères )

  4. #4
    Membre éprouvé
    Bonsoir,
    Citation Envoyé par fsmrel Voir le message
    Je rappelle à cette occasion que les collègues ne connaissent pas nécessairement MySQL Workbench! Et comme on vous l’a déjà dit, vous auriez avantage à utiliser Looping.
    Le problème de cette représentation Workbench, c'est qu'elle se situe au niveau logique avec des peudo-cardinalités à la UML...
    Comme indiqué par mes collègues, à ce stade de la réflexion, un MCD serait le bienvenue.
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  5. #5
    Membre régulier
    Je donne déjà quelques réponses parce que je n'ai pas le temps d'approfondir tout de suite.

    Concernant Looping, je tourne principalement sous Linux et il plante au lancement sous WINE. Comme bien souvent avec WINE, difficile de trouver la cause.

    Le VARCHAR pour le numéro de sécu était une erreur d’inattention, corrigée.

    Bénéficiaires, contacts et employés sont bien des sous-types de Personnes (toutes des personnes physiques, donc), avec le même ID et différenciées par le PER_TY_ID (j'ai simplement modifié la dénomination de chaque ID dans les 3 tables pour ne pas m’emmêler les pinceaux). Et c'est effectivement à une table associative à laquelle je pensais en postant ce sujet.

    Donc, le méthode que vous m'avez donné dans un précédent sujet pour relier les sous-types de personnes fonctionne très bien, jusqu'au moment où une association est nécessaire entre 2 de ces sous-types.

  6. #6
    Membre éprouvé
    Citation Envoyé par Nerva Voir le message
    Concernant Looping, je tourne principalement sous Linux et il plante au lancement sous WINE. Comme bien souvent avec WINE, difficile de trouver la cause.
    Assurez-vous juste que vous avez une version de Wine qui exécute les programmes 32 bits (Wine64 ne le fait pas sans une batterie de librairies) ; autrement, à partir de la version 5, tout se passe bien habituellement.
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  7. #7
    Membre éprouvé
    Est-ce que, conceptuellement, le modèle ressemblerait à ça ?
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  8. #8
    Expert éminent sénior
    Voici une ébauche réalisée avec Looping, je n'ai retenu que quelques attributs, l'essentiel est dans l'héritage d'une part et dans l'association entre deux sous-types d'autre part.
    J'ai supposé qu'un bénéficiaire ne pouvait avoir qu'un seul tuteur et qu'un tuteur pouvait avoir plusieurs bénéficiaires.
    Si un bénéficiaire peut avoir plusieurs tuteurs, alors l'association deviendra une table mais le principe restera le même

    Notez les noms donnés aux "pattes" de l'association (très simple avec looping, on clique sur la patte et une zone permet de saisir ce nom : ce nom du MCD est utilisé pour renommer l'identifiant de la personne tutrice dans la table BE_beneficaire du MLD

    C'est Paprick, le papa, qu'il faut remercier, c'est tellement simple que ça en est désarmant



    EDIT oups, Paprick m'a devancé

    @Paprick : du coup une question me vient sur les liens courbes, mais je vais la poser dans le forum Looping pour que tout le monde en bénéficie

  9. #9
    Expert éminent sénior
    Nerva,

    Avec MySQL Workbench, pour associer les tables BENEFICIAIRE et CONTACT, faites comme au paragraphe 5.1.2 « Non Identifying Relationship » de mon article.


    Chers équipiers du vaisseau Loo,

    Qui se ressemble, s’assemble... J’allais proposer un MCD équivalent aux vôtres, mais avant d’envoyer mon message, j’ai vu que vous m’aviez devancé, caramba !
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  10. #10
    Modérateur

    Citation Envoyé par escartefigue Voir le message
    Voici une ébauche réalisée avec Looping, je n'ai retenu que quelques attributs, l'essentiel est dans l'héritage d'une part et dans l'association entre deux sous-types d'autre part.
    J'ai supposé qu'un bénéficiaire ne pouvait avoir qu'un seul tuteur et qu'un tuteur pouvait avoir plusieurs bénéficiaires.
    Si un bénéficiaire peut avoir plusieurs tuteurs, alors l'association deviendra une table mais le principe restera le même

    Notez les noms donnés aux "pattes" de l'association (très simple avec looping, on clique sur la patte et une zone permet de saisir ce nom : ce nom du MCD est utilisé pour renommer l'identifiant de la personne tutrice dans la table BE_beneficaire du MLD

    C'est Paprick, le papa, qu'il faut remercier, c'est tellement simple que ça en est désarmant



    EDIT oups, Paprick m'a devancé

    @Paprick : du coup une question me vient sur les liens courbes, mais je vais la poser dans le forum Looping pour que tout le monde en bénéficie
    Une association 0,1 - 0,n devrait normalement entraîner la création d'une table associative si on chasse le bonhomme NULL !
    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 !

  11. #11
    Membre régulier
    @Fsmrel, je reviens sur votre première réponse, concernant les deux tables qui ne devraient en faire plus qu'une car je ne comprends pas ce que vous voulez dire. Les 3 entités, bénéficiaires, salariés et contacts sont 3 sous-types de personnes, que j'ai reliées selon vos conseils dans un autre sujet (client et employé, sous-types de personne physique) :

    https://www.developpez.net/forums/d2094485/general-developpement/alm/modelisation/schema/meilleures-methode-table-liaison/#post11637991

    Lorsque j'ai restructuré cette base, j'ai donc suivi la même procédure initiale (comme je le fais dorénavant dans toute base incluant des entités similaires).

    @Paprick, les dépendances pour les programmes 32 bits sont satisfaites. Plutôt que de m'arracher les cheveux à essayer de le faire tourner sous WINE, je vais m'y plonger sur un PC Windows.

    Quant au modèle, il ressemble effectivement à celui que vous avez présenté.

    @Escartefigue, la supposition est bonne :

    - 1 bénéficiaire ne peut avoir que 0 ou 1 contact.
    - 1 contact (qui n'est créé que si 1 bénéficiaire dépend de lui, comme dirait La Palice) peut avoir 1 ou plusieurs bénéficiaires.

    Néanmoins, j'avais peut-être la solution devant mes yeux et je ne l'ai pas vue. En effet, j'ai déjà créé une table associative bénéficiaires/salariés pour les affectations, structurée comme ceci :



    La différence est que dans ce cas, un bénéficiaire peut avoir plusieurs employés et qu'un employés peut avoir plusieurs bénéficiaires.

  12. #12
    Expert éminent sénior
    @Cinephil : oui, nous avons déjà échangé sur ce sujet 0,1 - 0,n
    Je ne suis pas partisan de la chasse au "null" dans ce cas, deux écoles, les deux raisonnements ont leurs arguments, c'est en général la politique locale du client qui tranche


    @Nerva : si la table T_contrat est issue de l'association, alors l'identifiant CON_id est artificiel et n'a pas lieu d'être, l'identifiant d'une table associative se compose uniquement des identifiants des types d'entités entrant en jeu dans l'association

  13. #13
    Membre régulier
    Citation Envoyé par escartefigue Voir le message
    si la table T_contrat est issue de l'association, alors l'identifiant CON_id est artificiel et n'a pas lieu d'être, l'identifiant d'une table associative se compose uniquement des identifiants des types d'entités entrant en jeu dans l'association
    Oui, d'accord pour l'association bénéficiaires/contacts, mais dans le cas de cette copie d'écran, chaque contrat est numéroté, d'où un identifiant.

  14. #14
    Expert éminent sénior
    Le contrat est un type d'entité et devrait donc apparaître dans le modèle

  15. #15
    Membre régulier
    Citation Envoyé par escartefigue Voir le message
    Le contrat est un type d'entité et devrait donc apparaître dans le modèle
    ???

  16. #16
    Expert éminent sénior
    Revenons à l'essentiel, à savoir le modèle conceptuel (MCD), le reste et notamment les tables en découle.

    Le MCD doit décrire la réalité du contexte, à savoir tous les objets de gestion : les bénéficiaires, les salariés et bien sûr les contrats
    Un contrat est une chose important, c'est porteur d'informations et c'est en interaction avec d'autres objets de gestion (par exemple un contrat est signé par tel client à telle date, clôturé à telle autre date, contenir telle et telle ligne détail...).
    Le numéro de contrat ne peut donc pas être un simple attribut apparaissant dans une table, il doit être porté par une entité-type [CONTRAT] du MCD qui deviendra une table CONTRAT dans le MLD.

  17. #17
    Membre éprouvé
    Bonjour,
    C'est une possibilité systématiquement proposée par Looping dans la définition de l'association lorsqu'une cardinalité 0,1 est présente.
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  18. #18
    Expert éminent sénior
    Bonsoir Nerva,


    Citation Envoyé par Nerva Voir le message
    @Fsmrel, je reviens sur votre première réponse, concernant les deux tables qui ne devraient en faire plus qu'une car je ne comprends pas ce que vous voulez dire.
    Dans ma 1ere réponse (post #2) j’ai précisé que vous aviez modélisé des bijections. Ce n’est sans doute pas ce que vous vouliez faire, mais c’est pourtant ce qu’exprime votre diagramme.

    Dans cette 1re réponse, j’ai aussi précisé qu’il fallait en passer par la mise en oeuvre de la spécialisation des entités-types pour modéliser correctement, donc remplacer la bijection par une injection :

    [T_PERSONNE]--||---------o|--[T_BENEFICIAIRE]


    Ou encore, graphiquement parlant, selon la notation que vous utilisez (notez la cardinalité 0..1) :



    En passant, dans votre diagramme la clé primaire de la table T_PERSONNES est la paire {PER_TY_ID, PER_ID}, donc si T_BENEFICIAIRES était une spécialisation (un sous-type) de T_PERSONNES, la paire d’attributs {PER_TY_ID, PER_ID} devrait aussi être présente en tant que clé primaire (et clé étrangère) de T_BENEFICIAIRES, à la place de {BEN_ID}.





    Citation Envoyé par Nerva Voir le message
    Les 3 entités, bénéficiaires, salariés et contacts sont 3 sous-types de personnes, que j'ai reliées selon vos conseils dans un autre sujet (client et employé, sous-types de personne physique)


    J’avais bien compris ce que vous cherchiez à faire, mais dans votre diagramme les cardinalités et les clés primaires et étrangères sont complètement à reprendre.

    N.B. La présence de l’attribut PER_TY_ID dans les clés primaires est mal venue du point de vue de la modélisation, mais dans votre diagramme du post #11, vous avez rectifié le tir, ok pour ce point-là.
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  19. #19
    Membre régulier
    @Escartefigue, dans le diagramme que j'ai posté, les tables sont épurées de tout ce qui est superflu. Bien évidemment que la table des contrats est particulièrement complète et précise.

    @Fsmrel, à vrai dire, je n'aime pas trop cette représentation, préférant de loin celle "à la Access".

    Voilà où j'en suis arrivé :



    TJ_BEN_SAL : table de liaison bénéficiaires/salariés qui définit les affectations ; 1 bénéficiaire peut avoir plusieurs salariés et 1 salarié peut avoir plusieurs bénéficiaires.
    TJ_BEN_TUT : table de liaison bénéficiaires/tuteurs (j'ai préféré renommer "contacts", trop vague, en "tuteurs") ; 1 tuteur peut avoir plusieurs bénéficiaires et 1 bénéficiaire ne peut avoir qu'1 seul tuteur.

    Note : la table T_TUTEURS ne dispose d'aucun autre attribut que l'ID. Les seuls attributs indispensabes sont les coordonnées, dans la table T_PERSONNES, comme pour les autres sous-types.

  20. #20
    Expert éminent sénior
    Bonjour Nerva
    Citation Envoyé par Nerva Voir le message
    @Escartefigue, dans le diagramme que j'ai posté, les tables sont épurées de tout ce qui est superflu. Bien évidemment que la table des contrats est particulièrement complète et précise.
    Yes, autant pour moi, dans T_contrat EMP_id et BEN_id sont des FK



    Citation Envoyé par Nerva Voir le message
    @Fsmrel, à vrai dire, je n'aime pas trop cette représentation, préférant de loin celle "à la Access".
    Pour ma part, je préfère un MCD (et je crois pouvoir dire que je ne suis pas le seul).
    Dans un MCD on ne s'encombre pas des FK, on voit directement les règles de gestion au travers des cardinalités et des CIF.
    C'est autrement plus parlant qu'un modèle tabulaire.


    Dans votre dernier diagramme, vous ajoutez une table associative entre salarié et bénéficiaire.
    Quelle est fonctionnellement la nature de cette association ?
    Autant pour un tuteur on voit bien, autant pour le salarié c'est moins clair.

###raw>template_hook.ano_emploi###