Votre avis sur un projet Access!
Résolu
Bobbyli
Messages postés
220
Date d'inscription
Statut
Membre
Dernière intervention
-
Bobbyli Messages postés 220 Date d'inscription Statut Membre Dernière intervention -
Bobbyli Messages postés 220 Date d'inscription Statut Membre Dernière intervention -
Hello hello!
J'aurais besoin de votre avis sur un projet que je mène, voir si la conception de ma base est cohérente et surtout s'il y a une méthode plus aisée/efficace pour la faire (que je soupçonne sérieusement d'exister au vue de mes limites en access).
Voici le cahier des charges (nous sommes dans un contexte de banque):
Une Agence s'occupe des comptes de ses clients à travers différents employés. En escalier, cela nous donne:
Agence --> "Gestionnaire CSS" --> "Corporate Banker" --> Client
Sachant que l'agence a à la fois un lien avec le gestionnaire, le corporate et le client. Elle peut avoir plusieurs personne pour chacun des postes, de même que le gestionnaire a plusieurs corporate et le corporate plusieurs clients.
Ce client, quant a lui, PEUT appartenir à un groupe d'entreprises. De plus, il possède une spécificité bancaire (et une seule).
Cette spécificité n'est pas unique à un client (et peut donc exister pour plusieurs). De plus, elle PEUT répondre à un mode opératoire (MOS) ou être sans mode.
En résumé pour le client, il possède plusieurs clés externes qui sont:
- N° de Spé (table spécificités)
- Nom de l'agence (table agence)
- Nom du Corporate Banker (table CB)
- Nom du Gestionnaire CSS (table G.CSS)
- Nom du Groupe (table Groupe)
Voici les Relations sur l'image suivante:
Merci d'avance pour votre aide! :)
J'aurais besoin de votre avis sur un projet que je mène, voir si la conception de ma base est cohérente et surtout s'il y a une méthode plus aisée/efficace pour la faire (que je soupçonne sérieusement d'exister au vue de mes limites en access).
Voici le cahier des charges (nous sommes dans un contexte de banque):
Une Agence s'occupe des comptes de ses clients à travers différents employés. En escalier, cela nous donne:
Agence --> "Gestionnaire CSS" --> "Corporate Banker" --> Client
Sachant que l'agence a à la fois un lien avec le gestionnaire, le corporate et le client. Elle peut avoir plusieurs personne pour chacun des postes, de même que le gestionnaire a plusieurs corporate et le corporate plusieurs clients.
Ce client, quant a lui, PEUT appartenir à un groupe d'entreprises. De plus, il possède une spécificité bancaire (et une seule).
Cette spécificité n'est pas unique à un client (et peut donc exister pour plusieurs). De plus, elle PEUT répondre à un mode opératoire (MOS) ou être sans mode.
En résumé pour le client, il possède plusieurs clés externes qui sont:
- N° de Spé (table spécificités)
- Nom de l'agence (table agence)
- Nom du Corporate Banker (table CB)
- Nom du Gestionnaire CSS (table G.CSS)
- Nom du Groupe (table Groupe)
Voici les Relations sur l'image suivante:
Merci d'avance pour votre aide! :)
A voir également:
- Votre avis sur un projet Access!
- Filigrane projet - Guide
- Gant projet - Télécharger - Gestion de projets
- Acer quick access - Forum Logiciels
- Access appdata - Guide
- Exemple base de données access à télécharger gratuit - Forum Access
5 réponses
Bonjour,
"Sachant que l'agence a à la fois un lien avec le gestionnaire, le corporate et le client. Elle peut avoir plusieurs personne pour chacun des postes, de même que le gestionnaire a plusieurs corporate et le corporate plusieurs clients. "
Pour retracer ce genre de liaisons, il faut des tables relais qui permettent de faire les liens dans un sens et dans l'autre. Exemple:
Table_Agence ==> Champs -> IdAg ; NomAg ; AdresseAg ; etc
Table_GestCSS ==> Champs -> IdGestCSS ; NomGestCSS ; etc
Table_CorpBanker ==> Champs -> IdCorpBanker ; NomCorpBanker ; etc
Les tables relais seront de la forme:
T_Relai_Agence-GestCSS ==> Champs -> IdRelAG ; IdAg ; IdGestCSS
T_Relai_GestCSS-CorpBanker ==> Champs -> IdRGest-CB ; IdGestCSS ; IdCorpBanker
J'ai mis les mêmes noms dans les tables ordinaires et dans les tables relais pour être plus compréhensibles, mais il convient de donner des noms un peu différents pour éviter les confusions dans la construction des requêtes.
Bonne suite
"Sachant que l'agence a à la fois un lien avec le gestionnaire, le corporate et le client. Elle peut avoir plusieurs personne pour chacun des postes, de même que le gestionnaire a plusieurs corporate et le corporate plusieurs clients. "
Pour retracer ce genre de liaisons, il faut des tables relais qui permettent de faire les liens dans un sens et dans l'autre. Exemple:
Table_Agence ==> Champs -> IdAg ; NomAg ; AdresseAg ; etc
Table_GestCSS ==> Champs -> IdGestCSS ; NomGestCSS ; etc
Table_CorpBanker ==> Champs -> IdCorpBanker ; NomCorpBanker ; etc
Les tables relais seront de la forme:
T_Relai_Agence-GestCSS ==> Champs -> IdRelAG ; IdAg ; IdGestCSS
T_Relai_GestCSS-CorpBanker ==> Champs -> IdRGest-CB ; IdGestCSS ; IdCorpBanker
J'ai mis les mêmes noms dans les tables ordinaires et dans les tables relais pour être plus compréhensibles, mais il convient de donner des noms un peu différents pour éviter les confusions dans la construction des requêtes.
Bonne suite
Re...
Pour la question que tu poses, la réponse est celle des tables relais.
Un exemple facile: Imaginons une équipe d'un club de foot de 22 joueurs participant à un championnat. Seuls 15 joueurs (avec les remplaçants) sont retenus pour chaque match. Il s'agit de retracer les matchs auxquels ont participé chacun des joueurs (Un à plusieurs) et les joueurs retenus pour chacun des matchs (Un à plusieurs également). Le seul moyen de se sortir du piège est d'utiliser une table-relai qui fait l'inter-face entre l'identifiant des matchs et l'identifiant des joueurs.
Pour la banque:
Dans le cas simple habituel, si des clients peuvent avoir plusieurs comptes, chaque compte n'est détenu que par un seul client. C'est une relation de: un à plusieurs.
Dans le cas des gestionnaires, le problème est plus difficile. Un gestionnaire s'occupe de plusieurs clients, ou de plusieurs comptes; donc il y a une relation de: 1 à plusieurs. Mais en même temps, chaque client peut s'adresser à plusieurs gestionnaire, et chaque compte peut être suivi par plusieurs gestionnaires selon le type d'opérations, ou au cours du temps quand les gestionnaires sont déplacés. Donc il y a des relations: un à plusieurs, mais dans l'autre sens.
Il s'agit donc de pouvoir passer, par exemple, du gestionnaire à client:
Gestionnaire ---> Clients
ou Gestionnaire ---> Comptes
et aussi de clients à gestionnaires, ou de comptes à gestionnaires:
Clients ---> Gestionnaire
ou Comptes ---> Gestionnaire
Les tables relais permettent de résoudre la difficulté de relation: plusieurs à plusieurs, en ayant à la place: Un --> Plusieurs + Un --> Un , le 2ème 'Un' correspond à chacun des identifiants sélectionnés grâce au couple de la table relai.
Cela n'alourdit que très peu la base parce que la table relai n'a que 2 ou 3 champs en comptant le champ Id_Lien qui n'est pas très nécessaire.
Inversement, il n'est pas utile d'avoir une table-relai entre les clients et les comptes parce que chaque compte n'est détenu que par un seul client. C'est une relation de un à plusieurs.
"Est-ce que c'est pertinent d'avoir une relation de l'agence vers le client par exemple si le gesCSS en a déjà une?"
Les agents des banques ne restent généralement pas très longtemps dans la même agence (2 ou 3 ans), il vaut mieux donc prévoir un système qui permettent de tenir compte du fait que dans une agence il y a plusieurs agents, mais aussi qu'un même agent peut naviguer entre plusieurs agences. Ne serait-ce que pour ne pas avoir à réparer par la suite.
Enfin, "L'objectif, évidemment, est ensuite de travailler sur des formulaires. "
Comme je répète toujours aux autres internautes, les formulaires et les états ne sont que la façade sur laquelle on travaille, mais le vrai boulot, le vrai traitement des données, c'est les tables et les requêtes. Quand je suivais les qq cours d'informatique que j'ai suivi, on ne m'a jamais appris les formulaires, seulement la conception des tables et des requêtes. Et dans les tutoriels que tu peux trouver sur CCM (voir ODBC) il n'est question que de l'aménagement des tables et des requêtes. Les formulaires, c'est comme la carrosserie d'une bagnole, vraiment pas le plus important.
Bonne suite
Pour la question que tu poses, la réponse est celle des tables relais.
Un exemple facile: Imaginons une équipe d'un club de foot de 22 joueurs participant à un championnat. Seuls 15 joueurs (avec les remplaçants) sont retenus pour chaque match. Il s'agit de retracer les matchs auxquels ont participé chacun des joueurs (Un à plusieurs) et les joueurs retenus pour chacun des matchs (Un à plusieurs également). Le seul moyen de se sortir du piège est d'utiliser une table-relai qui fait l'inter-face entre l'identifiant des matchs et l'identifiant des joueurs.
Pour la banque:
Dans le cas simple habituel, si des clients peuvent avoir plusieurs comptes, chaque compte n'est détenu que par un seul client. C'est une relation de: un à plusieurs.
Dans le cas des gestionnaires, le problème est plus difficile. Un gestionnaire s'occupe de plusieurs clients, ou de plusieurs comptes; donc il y a une relation de: 1 à plusieurs. Mais en même temps, chaque client peut s'adresser à plusieurs gestionnaire, et chaque compte peut être suivi par plusieurs gestionnaires selon le type d'opérations, ou au cours du temps quand les gestionnaires sont déplacés. Donc il y a des relations: un à plusieurs, mais dans l'autre sens.
Il s'agit donc de pouvoir passer, par exemple, du gestionnaire à client:
Gestionnaire ---> Clients
ou Gestionnaire ---> Comptes
et aussi de clients à gestionnaires, ou de comptes à gestionnaires:
Clients ---> Gestionnaire
ou Comptes ---> Gestionnaire
Les tables relais permettent de résoudre la difficulté de relation: plusieurs à plusieurs, en ayant à la place: Un --> Plusieurs + Un --> Un , le 2ème 'Un' correspond à chacun des identifiants sélectionnés grâce au couple de la table relai.
Cela n'alourdit que très peu la base parce que la table relai n'a que 2 ou 3 champs en comptant le champ Id_Lien qui n'est pas très nécessaire.
Inversement, il n'est pas utile d'avoir une table-relai entre les clients et les comptes parce que chaque compte n'est détenu que par un seul client. C'est une relation de un à plusieurs.
"Est-ce que c'est pertinent d'avoir une relation de l'agence vers le client par exemple si le gesCSS en a déjà une?"
Les agents des banques ne restent généralement pas très longtemps dans la même agence (2 ou 3 ans), il vaut mieux donc prévoir un système qui permettent de tenir compte du fait que dans une agence il y a plusieurs agents, mais aussi qu'un même agent peut naviguer entre plusieurs agences. Ne serait-ce que pour ne pas avoir à réparer par la suite.
Enfin, "L'objectif, évidemment, est ensuite de travailler sur des formulaires. "
Comme je répète toujours aux autres internautes, les formulaires et les états ne sont que la façade sur laquelle on travaille, mais le vrai boulot, le vrai traitement des données, c'est les tables et les requêtes. Quand je suivais les qq cours d'informatique que j'ai suivi, on ne m'a jamais appris les formulaires, seulement la conception des tables et des requêtes. Et dans les tutoriels que tu peux trouver sur CCM (voir ODBC) il n'est question que de l'aménagement des tables et des requêtes. Les formulaires, c'est comme la carrosserie d'une bagnole, vraiment pas le plus important.
Bonne suite
Je vois!
J'avais ce genre de table dans mes cours sans savoir réellement quelle était son utilité!
Merci :)
Ceci étant, c'est un projet qui se veut simplifié, dans les faits, avec une seule agence et 2 agents (CSS et corporate). Je vais toutefois suivre ton idée car ça permet de comprendre quelque chose de nouveau!
En gros, si j'ai bien compris, je dois utiliser une table-relai dès que j'ai une relation "plusieurs à plusieurs"?
D'ailleurs, en passant, comment, dans mes relations, je fais signifier une relation "1 à 1" (un client a 1 spécificité et 1 seule)
J'avais ce genre de table dans mes cours sans savoir réellement quelle était son utilité!
Merci :)
Ceci étant, c'est un projet qui se veut simplifié, dans les faits, avec une seule agence et 2 agents (CSS et corporate). Je vais toutefois suivre ton idée car ça permet de comprendre quelque chose de nouveau!
En gros, si j'ai bien compris, je dois utiliser une table-relai dès que j'ai une relation "plusieurs à plusieurs"?
D'ailleurs, en passant, comment, dans mes relations, je fais signifier une relation "1 à 1" (un client a 1 spécificité et 1 seule)
Eh bien! Tu fais une relation simple. Quand tu entres ta relation, l'assistant te demande quel type de relation tu veux. Donc pas de problème.
Pour sélectionner les types de liens: mettre le pointeur sur le lien, puis click droit et choix du type de lien.
La table "MOS", qu'est-ce que c'est? Pitié avec les sigles que toi seul comprends.
"celle-ci est de 0 à plusieurs": de 0 à plusieurs : ?????????????????????????????
La table "MOS", qu'est-ce que c'est? Pitié avec les sigles que toi seul comprends.
"celle-ci est de 0 à plusieurs": de 0 à plusieurs : ?????????????????????????????
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Peux-tu toutefois m'expliciter l'utilité de ces tables relais?
De même, penses-tu que c'est pertinent d'avoir une relation de l'agence vers le client par exemple si le gesCSS en a déjà une? L'objectif, évidemment, est ensuite de travailler sur des formulaires. Donc peut-être que ce que j'ai fait là alourdit inutilement ma base?