Discussion :

[Nerva]

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é) :

[fsmrel]

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.

[escartefigue]

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 )

[Paprick]

Bonsoir,

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.

[Nerva]

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.

[Paprick]

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.

[Paprick]

Est-ce que, conceptuellement, le modèle ressemblerait à ça ?

[escartefigue]

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

Pièce jointe 584130

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

[fsmrel]

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 !

[CinePhil]

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

Pièce jointe 584130

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 !

[Nerva]

@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/d2.../#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.

[escartefigue]

@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

[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

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.

[escartefigue]

Le contrat est un type d'entité et devrait donc apparaître dans le modèle

[Nerva]

Le contrat est un type d'entité et devrait donc apparaître dans le modèle

???

[escartefigue]

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.

[Paprick]

Bonjour,

Une association 0,1 - 0,n devrait normalement entraîner la création d'une table associative si on chasse le bonhomme NULL !

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.

[fsmrel]

Bonsoir Nerva,

@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}.

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à.

[Nerva]

@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.

[escartefigue]

Bonjour Nerva

@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

@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.