Membre émérite
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 !
Modérateur
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
Modérateur
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.
Membre émérite
Envoyé par
CinePhil
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é.
Modérateur
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"
+ Répondre à la discussion
Cette discussion est résolue.
Discussions similaires
-
Réponses: 16
Dernier message: 14/02/2007, 13h15
-
Réponses: 7
Dernier message: 22/11/2006, 12h06
-
Réponses: 4
Dernier message: 21/07/2006, 22h27
-
Réponses: 6
Dernier message: 07/07/2006, 17h08
-
Réponses: 12
Dernier message: 09/06/2006, 09h21
×
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité,
merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager