Création d'une base de donnée complexe avec risques de doublons [Résolu/Fermé]

Signaler
Messages postés
218
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
-
Messages postés
218
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
-
Hello hello!

J'aimerais votre aide pour créer une base qui s'avère plus complexe que prévue...

Voici le cahier des charges (nous sommes dans un contexte de banque):

Une agence gère les comptes de plusieurs clients.
Le client est en relation avec un "Corporate Banker", qui est en relation avec un ou plusieurs "Gestionnaire(s) CSS" qui sont avec une ou plusieurs Agence(s).
Le client est en relation avec chacun de ces 3 intermédiaires.

De plus, le client peut appartenir ou non à un "Groupe", celui-ci ayant plusieurs clients.
Egalement, le client possède une seule "spécificité bancaire", qui a elle-même 0 ou plusieurs "mode(s) opératoire(s)". A noter que cette spé peut être commune à plusieurs clients.

Merci d'avance pour votre aide précieuse!

3 réponses

Messages postés
28963
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
3 juin 2020
2 484
Messages postés
218
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
Bonjour Jordane,

Merci pour ton rappel à l'ordre très justifié (non ironique, vraiment) :). Et excuse-moi, d'ailleurs^^.

Pour suivre les règles, je rajoute ici quelques précisions.

J'ai déjà tenté ma chance sur ce projet, qui était à la base simplifié (pas de relation de plusieurs à plusieurs...), dont voici l'image des relations (ne correspondant plus au cahier ci-dessus car sinon, je ne serais point là!) :



Ma difficulté majeure se situe donc sur l'existence de doublons du fait de la relation plusieurs-plusieurs.
Dans une précédente question ici, Tessel75 m'a proposé la solution des tables relais mais je ne sais pas du tout comment en faire la mise en place, d'autant plus que je travaille sur une base de donnée ayant déjà des données liées aux différentes tables (même si j'ai à côté une base "brouillon").

J'espère que ces informations sont suffisantes...!

Et merci d'avance =)
Messages postés
28963
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
3 juin 2020
2 484

Tessel75 m'a proposé la solution des tables

C'est à dire ?

Perso... je pense que la mise en place de UNIQUE KEY dans les tables où tu ne souhaites pas avoir de doublon est la plus simple des solutions.

Par exemple, tu pourrais mettre une clé unique sur ta table Corporate Banker ayant comme clés la combinaison des champs : client + gestionnaire
Pour ta table gestionnaires ... une clé unique sur le champ nom gestionnaire ...


Pour le reste.... ton MCD me semble correcte et je vois pas à quels autres endroits tu pourrais rencontré un souci de doublon.


NB : par contre.. il serait préférable de travailler avec des ID (de préférence numérique) plutôt que de travailler directement avec des STRING (varchar ou autre...)
=> Ajout de champs ID auto-incrémenté sur tes tables : agence, gestionnaires, clients, groupe ..etc....

NB2 : Pour le nom des champs et de tes tables :
- Ne pas utiliser d'accents ou tout autre caractère spécial
- Ne pas mettre d'espace
- Préférer l'écriture en tout en minuscule
Messages postés
218
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
Pour Tessel75, c'est à dire que selon lui, il me faudrait ajouter une table "intermédiaire" entre Agences et Gestionnaire CSS qui permettrait de faire le lien "plusieurs à plusieurs". Et j'ai du mal à la mettre en place (quelles clés utilisées etc.)

Peux-tu expliciter ce que tu entends pour unique keys et les combinaisons que tu évoques dans ton 2e paragraphe s'il te plaît?

Comme je le disais, les relations que j'ai faite ne prennent pas en compte le cas où le gestionnaire a plusieurs agences du coup j'imagine que ça complique la chose...

Quel est l'inconvénient des ID string? Les erreurs potentielles de saisies?
Je maîtrise mal l'autonum, surtout quand il s'agit de rattraper les problèmes de saut de chiffre (avoir ligne 4 puis 6 car 5 supprimée...). Une idée pour mettre ça à jour sur une base remplie..?

Merci pour tes informations :)
Messages postés
28963
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
3 juin 2020
2 484

Pour Tessel75, c'est à dire que selon lui, il me faudrait ajouter une table "intermédiaire" entre Agences et Gestionnaire CSS qui permettrait de faire le lien "plusieurs à plusieurs". Et j'ai du mal à la mettre en place (quelles clés utilisées etc.)

D'où l'interret d'utiliser des clés primaire de type Numérique ( auto-incrementées)
Et ta table de relation serait tout simplement :
id_agence / id_gestionnaire


Quel est l'inconvénient des ID string?

Avant tout .. les performances. cela va plus vite, pour une BDD, de traiter des nombres plutôt que tu texte.


Peux-tu expliciter ce que tu entends pour unique keys et les combinaisons que tu évoques dans ton 2e paragraphe s'il te plaît?

Ben... tu dis que le couple de valeur client + gestionnaire doit être unique.
par exemple ... le client toto .. et le gestionnaire titi ... ne peuvent exister qu'une seule fois ensemble.
Recherche sur le net l'utilisation des clés "UNIQUE" ... et tu comprendras.



Je maîtrise mal l'autonum, surtout quand il s'agit de rattraper les problèmes de saut de chiffre (avoir ligne 4 puis 6 car 5 supprimée...). Une idée pour mettre ça à jour sur une base remplie..?

Il n'y a pas à mettre à jour quoi que ce soit...
La ligne a été supprimée ... et bien soit.... le fait qu'il y ait des "trous" .. est normal ... et il ne faut surtout pas essayer de les combler !

Messages postés
218
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
Hum par rapport à ta solution, comment je fais alors pour ajouter les "attributs" de chacun table (nom, numéro tel...) si je n'ai que l'id_agence et id_gestionnaire dedans..?

Effectivement, toto et titi (belle imagination! :P) ont une relation unique (les coquins). Même si le gestionnaire a plusieurs clients (le salo).

Je regarde cette histoire de clé unique dès que je peux et je te dirai ensuite :)

Je vois ceci dit un problème a avoir des valeurs numériques... Qui a peut-être une solution.
Prenons le gestionnaire, qui a un client, qui a une spécificité. Sans parler de formulaire, si je déroule ce gestionnaire pour voir le client, j'aurai pour sa spé seulement le code numérique (bon, dans ce cas vu les spé vaut mieux des codes autonum, mais c'est pour l'exemple), et donc pas la spé liée. Le probleme de manquer de visibilité sur la spé (il faudrait ensuite voir le code et retrouver la spé...). Est-ce normal car cela se fait ensuite via la configuration d'un formulaire ou il y a t il une solution adéquate?
Messages postés
28963
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
3 juin 2020
2 484

Prenons le gestionnaire, qui a un client, qui a une spécificité. Sans parler de formulaire, si je déroule ce gestionnaire pour voir le client, j'aurai pour sa spé seulement le code numérique (bon, dans ce cas vu les spé vaut mieux des codes autonum, mais c'est pour l'exemple), et donc pas la spé liée. Le probleme de manquer de visibilité sur la spé (il faudrait ensuite voir le code et retrouver la spé...). Est-ce normal car cela se fait ensuite via la configuration d'un formulaire ou il y a t il une solution adéquate?


C'est normal....
Et pour avoir les infos.. il faut utiliser des JOINTURES pour faire tes requêtes SELECT.....
Par exemple :
SELECT *
FROM table1 t1
LEFT JOIN table2 t2 on t2.id = t1.id_truc


... mais bon... tout ça fait parti des bases à connaitre pour utiliser/créer des BDD ..... et tu trouveras toutes les infos nécessaires sur le net......
Je n'ai pas le temps (et ne suis pas là pour ça....) de te faire un cours !
Messages postés
218
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
Haha en effet! Je n'ai que les bases des bases malheureusement, mais j'apprends!
Ceci dit, si j'ai fait du SQL, je n'ai pas approfondi (n'en ayant pas l'utilité pour favoriser une approche manuelle peut-être moins efficace mais plus facile à prendre en main).

Aurais-tu des adresses pour que je puisse approfondir Access, toutefois?

Et en passant, merci grandement pour ton aide précieuse :)