IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 confirmé
    Avatar de Jcpan
    Inscrit en
    août 2008
    Messages
    541
    Détails du profil
    Informations forums :
    Inscription : août 2008
    Messages : 541
    Points : 468
    Points
    468
    Par défaut Bonnes pratiques de conception d'une base de données
    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.

  2. #2
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 571
    Points : 33 384
    Points
    33 384
    Billets dans le blog
    13
    Par défaut
    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.
    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 !

  3. #3
    Membre éprouvé Avatar de Paprick
    Homme Profil pro
    Professeur des Universités
    Inscrit en
    juin 2019
    Messages
    291
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Professeur des Universités
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2019
    Messages : 291
    Points : 1 135
    Points
    1 135
    Par défaut
    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 :
    Nom : MCD Jcpan.jpg
Affichages : 63
Taille : 13,9 Ko
    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 :
    Nom : MCD Jcpan.jpg
Affichages : 59
Taille : 14,5 Ko

    Avec le MLD :
    Nom : MLD Jcpan.jpg
Affichages : 60
Taille : 10,5 Ko
    où Id_Client et DateC consituent la clé primaire de Crédit.

    Bonne continuation !
    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

  4. #4
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 501
    Points : 20 158
    Points
    20 158
    Billets dans le blog
    2
    Par défaut
    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

  5. #5
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 571
    Points : 33 384
    Points
    33 384
    Billets dans le blog
    13
    Par défaut
    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.
    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 !

  6. #6
    Membre éprouvé Avatar de Paprick
    Homme Profil pro
    Professeur des Universités
    Inscrit en
    juin 2019
    Messages
    291
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Professeur des Universités
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2019
    Messages : 291
    Points : 1 135
    Points
    1 135
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    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é.
    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
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 501
    Points : 20 158
    Points
    20 158
    Billets dans le blog
    2
    Par défaut
    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

  1. [Conception] Connexion à une base de données
    Par delmimi dans le forum PHP & Base de données
    Réponses: 16
    Dernier message: 14/02/2007, 14h15
  2. Conception d'une base de données
    Par yousron dans le forum Modélisation
    Réponses: 7
    Dernier message: 22/11/2006, 13h06
  3. [Conception] Connexion à une base de données AS400
    Par mirc00 dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 21/07/2006, 23h27
  4. Conception d'une base de données
    Par petitloup71 dans le forum Modélisation
    Réponses: 6
    Dernier message: 07/07/2006, 18h08
  5. [Conception] Modifier une base de données
    Par fabrice88 dans le forum PHP & Base de données
    Réponses: 12
    Dernier message: 09/06/2006, 10h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo