Discussion :

[ctobini]

Bonjour,

Dans le cadre d'un exercice, je souhaite effectuer le lien entre une entreprise et un client pour un contrat.

Une entreprise peut établir n contrats et un contrat est rattaché à une seule entreprise.
Un client peut souscrire à n contrats mais peut ne pas y souscrire (se désister), un contrat est rattaché à un seul client

J'ai pensé à une relation de ce type :



L'entité contrat contient à ce moment :
CONTRAT
idContrat clé primaire
idEntreprise clé étrangère référence Entreprise(idEntreprise) NOT NULL
idEntreprise clé étrangère référence CLIENT(idClient) NULL

Ce qui permet de retrouver l'entreprise émettrice et la souscription client, et de garder la trace du contrat même si le client se désiste. En cas de désistement il faudra supprimer la FK CONTRAT(idClient).

Je me pose la question de regrouper client et entreprise dans la même entité "TIERS" (en admettant que ce soit la même typologie), il faudra à ce moment voir si la relation est possible avec contrat.

Pourriez-vous svp me donner votre avis ?

Merci,

C. Tob

[escartefigue]

Bonjour,

Le plus souvent, le système d'information ne gère que les contrats de sa propre entreprise, l'entité-type "entreprise" n'est donc pas requise.
Mais si on veut gérer un S.I. pour plusieurs entreprises, alors cette entité-type est nécessaire.
Ensuite, avoir positionné une cardinalité minimale de zéro coté client implique qu'un prospect (client n'ayant jamais signé de contrat) est déjà considéré comme un client. Est-ce bien ce qui est souhaité ?
De plus, la cardinalité minimale de zéro coté contrat vers client implique que certains contrats ne concernent aucun client , peut-être s'agit il de contrats fournisseur ? Mais en ce cas il faut modéliser l'entité-type fournisseur (qui peut être un sous-type d'une personne qui engloberait aussi les clients) et mettre en place une contrainte d'exclusion entre les deux associations (le contrat étant lié soit à un fournisseur, soit à un client, mais pas les deux)

Enfin, il ne faut pas confondre le modèle conceptuel et le modèle tabulaire, dans le modèle conceptuel, la notion de clef et donc a fortiori de clef étrangère est absente (pas de clef donc dans les types d'entité). C'est dans le modèle tabulaire (MLD et MPD) que les identifiants deviennent des clefs et qu'on les retrouve sous forme de FK dans les tables qui en héritent.

Pour ce qui est du regroupement des différents types de personnes (clients, fournisseurs, mandataires...) c'est toujours une reflexion à avoir et c'est le plus souvent utile. On utilise en ce cas l'héritage

[ctobini]

Bonjour escartefigue et merci pour ces explications,

Tout à fait, le client est tout de même saisi même s'il n'a pas contractualisé.

J'ai un souci justement avec cette association Client 0,n ---> 0,1 Contrat pour laquelle il me semble que l'identifiant Client doit se retrouver côté Contrat. Plutôt que d'avoir un idClient NULL côté Contrat, il me semblerait plus judicieux de placer une table associative CLIENT_CONTRAT(idClient, idContrat) ce qui permettrait de supprimer l'enregistrement en cas de désistement du client. Il ne me semble pas néanmoins que ce soit la règle, une table associative devant être créée en cas de relation n à n.

Merci pour cette précision du MCD / MLD je vais y faire attention 😊

[escartefigue]

désolé je n'avais pas vu votre réponse et j'ai enrichi la mienne dans l'intervalle

Attention : le positionnement des attributs et les cardinalités ne doivent pas être la conséquence de considérations pratiques pour la mise en oeuvre des traitements. Ce sont les règles de gestion qui pilotent le modèle de données.

Les règles de gestion étant
R001 : un contrat est possédé par un et un seul client
R002 : un client possède zéro à plusieurs contrats

le modèle conceptuel est donc [CLIENT] 0,n --- (posseder) --- 1,1 [CONTRAT]

la présence ou pas d'une table associative est la conséquence directe des cardinalités.
Dans le cas particulier de cardinalités minimales à zéro, on peut toutefois forcer la création d'une table associative pour éviter les marqueurs "null". Mais comme un contrat a forcément un client rattaché, on n'est pas dans cette situation

Ensuite, on peut gérer une notion de "statut" du contrat (ouvert, fermé, annulé...) qui sera un attribut de l'entité-type "contrat" et permettra de savoir où on en est dans son cycle de vie

[ctobini]

Ha oui effectivement, gérer par un statut permettra d'éviter les NULL.

Merci beaucoup pour l'aide 😊