Discussion :

[Jcpan]

j'ai une

table des employés
table client
table de crédit




Dans ma conception, dois-je créer une jointure manytomany dans l'employé et le client ou créer une colonne emplye_id et client_id dans la table de crédit? sachant que la table des clients et des employés est grande de 20 miles chacun et si je crée des colonnes dans la table de crédit j'aurais moins de code côté PHP ... Mais j'aimerais savoir la bonne manière de faire les choses.

[CinePhil]

Avant de passer d'emblée aux tables, commencez par établir clairement les règles de gestion de vos données puis réalisez un MCD. Vous y verrez beaucoup plus clair.

Il semble y avoir ici deux associations à modéliser :
- entre credit et customer ;
- entre credit et employee.

Si credit représente UN crédit accordé à UN client, alors la règle de gestion est la suivante :
R1 : Un crédit est proposé à un seul client et un client peut se voir proposer plusieurs crédits.

Si credit représente une offre générique de crédit proposée par l'étblissement financier (crédit logement, auto, prêt personnel, investissement d'entreprise...) - mais dans ce cas il me semble que l'entité type devrait s'appeler credit_type - alors la règle de gestion serait plutôt celle-là :
R1' : Un credit peut être proposé à plusieurs clients et un client peut se voir proposer plusieurs crédits.

Je vous laisse continuer la réflexion pour la seconde association en vous aidant de mon article.

[Paprick]

Bonjour,
Tout à fait d'accord avec CinePhil et, dans son hypothèse 1, je pense qu'il faut considérer qu'un crédit doit être géré par un employé, un employé pouvant bien sûr gérer plusieurs crédits.
Ce qui nous donnerait :

A ce stade, vous avez 2 possibilités :

• soit affecter un identifiant à Crédit,
• soit considérer, comme vous le suggérez, qu'un crédit est identifié par Id_Client et Id_Employé (dans ce cas, Crédit pourrait effectivement faire office d'association).

Le problème, dans cette 2ème hypothèse, c'est qu'un client ne pourra pas avoir 2 crédits différents gérés par le même employé... ce qui me semble être limitatif.
La solution consiste alors à rajouter, par exemple, la date du crédit dans son identification... et dans ce cas-là, pour respecter la règle d'irréductibilité, Id_Employé ne doit plus faire partie de la clé primaire de Crédit.
Avec cette dernière approche, nous aurions :

Avec le MLD :

où Id_Client et DateC consituent la clé primaire de Crédit.

Bonne continuation !

[escartefigue]

Bonsoir,

Je suis d'accord avec ce qui précède et j'ajoute qu'il est peut être possible (les règles de gestion nous le diront) qu'un client soit aussi un employé : il est fréquent que les employés d'une banque souscrivent un prêt (parfois bonifié) dans cette même banque.
Auquel cas, clients et employés sont des personnes qui partagent les mêmes attributs (nom, prénom, date de naissance...) et ont certains attributs spécifiques (le numéro d'employé ne concerne que les employés...).
Du coup, la modélisation par héritage s'impose.
Mais dans ce cas, on peut supposer (là aussi, les règles de gestion manquent) qu'un employé ne gère pas un crédit accordé pour lui même, c'est à un autre employé de le faire, peut être même une certaine catégorie d'employés.
Comme vous le voyez, un modèle qui peut sembler simple au départ est sujet à bien des variations selon les règles de gestion

[CinePhil]

Je ne suis pas fan de l'absence d'identifiant propre au crédit.
Certes, le crédit n'a pas d'existence sans le client qui le souscrit mais, dans la règle de gestion que j'ai écrite, j'emploie le verbe "proposer". Il serait ainsi possible qu'un employé fasse plusieurs propositions de crédit à un même client lors de son rendez-vous du 01/12/2020.
Et même si on n'enregistre ici que les crédits souscrits, imaginons un entrepreneur victime d'une catastrophe naturelle qui a besoin d'un crédit pour financer la reconstruction de son atelier et d'un autre crédit pour remplacer son véhicule de travail : 2 crédits consentis par le même employé le même jour au même client.

Selon moi, le crédit doit avoir son identifiant propre.
Autant une ligne de commande n'a pas de sens sans la commande dont elle fait partie et doit être identifiée relativement à la commande, autant un crédit n'est pas une partie d'un client mais la matérialisation d'une relation contractuelle entre un client et sa banque. Un compte, un crédit, une assurance... doivent à mon sens avoir leur identifiant propre.

[Paprick]

Selon moi, le crédit doit avoir son identifiant propre.
Autant une ligne de commande n'a pas de sens sans la commande dont elle fait partie et doit être identifiée relativement à la commande, autant un crédit n'est pas une partie d'un client mais la matérialisation d'une relation contractuelle entre un client et sa banque. Un compte, un crédit, une assurance... doivent à mon sens avoir leur identifiant propre.

C'est effectivement préférable, et c'est d'ailleurs la première possibilité que j'ai proposée.
Pour les histoires de crédits le même jour, on peut toujours horodater avec un DATETIME, mais je préfère aussi la solution de l'identifiant propre à la classe Crédit qui paraît assez naturelle avec un une notion, par exemple, de numéro de dossier. Id_Client et Id_Employé deviennent alors des clés étrangères classiques ne participant pas à la clé primaire de la table Crédit.
Il y a aussi la possibilité d'avoir un numéro de dossier propre au client, auquel cas l'identification relative peut rester d'actualité.

[escartefigue]

Bien sûr que le crédit est un type d'entité avec ses propres attributs et son identifiant.
Les crédits sont de différents types (immobilier, à la consommation, renouvelable, crédit relais...), ont une durée, un taux qui peut être fixe ou variable, sont renégociables ou pas, font partie d'une offre pour certains.
Une même personne peut souscrire différents crédits, à titre individuel ou en nom collectif, auprès d'un même organisme ou de différents établissements...
Sauf si le contexte est particulier (mais où sont les règles de gestion ? ) il faut donc modéliser une entité-type "credit"