Votre avis sur un projet Access!
Résolu/Fermé
Bobbyli
Messages postés
220
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
-
Modifié par Bobbyli le 26/07/2015 à 17:23
Bobbyli Messages postés 220 Date d'inscription vendredi 19 avril 2013 Statut Membre Dernière intervention 3 janvier 2016 - 31 juil. 2015 à 11:25
Bobbyli Messages postés 220 Date d'inscription vendredi 19 avril 2013 Statut Membre Dernière intervention 3 janvier 2016 - 31 juil. 2015 à 11:25
A voir également:
- Votre avis sur un projet Access!
- Musique projet x ✓ - Forum Musique / Radio / Clip
- Comment projeter une image sur un mur - Forum TV & Vidéo
- Access runtime ✓ - Forum Access
- Acer quick access - Forum Logiciels
- Filigrane projet - Guide
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
Bobbyli
Messages postés
220
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
28 juil. 2015 à 08:43
28 juil. 2015 à 08:43
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.
Bobbyli
Messages postés
220
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
28 juil. 2015 à 10:45
28 juil. 2015 à 10:45
Ben dans la fenêtre ça me marque juste "1 à plusieurs" sans que j'ai la possibilité de passer
Et d'ailleurs, me suis gouré (dans mes relations, j'ai déjà ce qu'il faut!)
C'est pour la table "MOS", celle-ci est de 0 à plusieurs. Une spé à 0 MOS jusqu'à plusieurs
Et d'ailleurs, me suis gouré (dans mes relations, j'ai déjà ce qu'il faut!)
C'est pour la table "MOS", celle-ci est de 0 à plusieurs. Une spé à 0 MOS jusqu'à plusieurs
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 : ?????????????????????????????
Bobbyli
Messages postés
220
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
28 juil. 2015 à 13:15
28 juil. 2015 à 13:15
Haha autant pour moi. Mais tu ne vois pas l'image que j'ai mis sur mon post (1e)?
Toujours est-il que le mos est un mode opératoire qui est lié à une spécificité. En clair, soit la spé en a 1 (ou +), soit elle en a pas
Toujours est-il que le mos est un mode opératoire qui est lié à une spécificité. En clair, soit la spé en a 1 (ou +), soit elle en a pas
Bobbyli
Messages postés
220
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
28 juil. 2015 à 14:42
28 juil. 2015 à 14:42
Imagine une table "Boissons" et une table "Glaçons". Ta boisson peut avoir 0 glaçon tout comme elle peut en avoir 1 ou plusieurs
Eh bien les spé, sont des boissons, les mode opératoire des glaçons
Eh bien les spé, sont des boissons, les mode opératoire des glaçons
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Bobbyli
Messages postés
220
Date d'inscription
vendredi 19 avril 2013
Statut
Membre
Dernière intervention
3 janvier 2016
1
31 juil. 2015 à 11:25
31 juil. 2015 à 11:25
Eh bien, Tessel75, ça tombe bien que tu m'aies proposé ta solution avec les tables relais, quand j'vais finalement en avoir besoin!
Je teste puis je clôture la question si j'm'en sors :)
Merci encore!
Je teste puis je clôture la question si j'm'en sors :)
Merci encore!
26 juil. 2015 à 21:11
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?