[AC-2010] gérer Plusieurs bases avec même tables et ID [Résolu]

[manutek]

Bonjour,

Mes cours d'Access sont loin...J'ai commencé à travailler sur un projet Access mais j'ai peur de mal m'orienter dès le départ sur la structure, donc je demande votre avis.

Le projet consiste à la récolte et la compilation de données sur une étude de marché.
Les données seront collectées par des commerciaux itinérants "au fil de l'eau".
Ceux-ci ne devront avoir accès qu'à "leurs" données.
Le directeur commercial doit avoir accès à la totalité des données collectées, ainsi qu'à des requêtes et états de compilation spécifiques.

Mon problème, dans l'idéal, les commerciaux itinérants doivent pouvoir entrer des données en étant "hors ligne". Je me suis donc orienté vers une base par commercial sur leur pc, chacune étant identique en structure et une base (pas encore créée) pour le directeur commercial qui fait des requêtes sur les autres.
Est-ce la bonne solution où je risque d'avoir des problèmes lors de la "compilation des données" car chaque base aura une table "Tiers" avec comme clé "IdTiers" par exemple, mais le IdTiers 0001 correspondra à un client/prospect différent suivant la base?
Ou dois-je étudié les solutions "base dorsale" ?
Ou dois-je ajouter partout dans mes bases "commercial itinérant", un code pour identifié la base dans les clés (qui sont actuellement en n° auto)?

Je vous joins mon graph et relations des tables en PJ.

Un tiers à un secteur (commercial) unique.
Un tiers peu avoir plusieurs fiches "marchés".
Une fiche "marché" est définie par la combinaison d'un tiers+code segment+code application, il ne peut y en avoir 2 avec cette combinaison.
Le code application dépend du code segment (sous-rubrique), mais cette vérité est susceptible d'être modifiée (indépendance des 2 champs).
Un tiers pourra dans le futur avoir qu'un seul et unique code segment, mais là encore c'est pas encore figé
La fiche "marché" est composée de lignes avec des qtés, prix, références et infos techniques.

Voilà, vous savez tout
Merci pour vos conseils.

Manu

[f-leb]

bonjour,

je ne suis pas spécialiste de ce genre de technique mais regarde du côté de la réplication:

Définition de la réplication
La réplication est une technique qui consiste dupliquer une base de donnée pour pouvoir utiliser des copies sur plusieurs postes en même temps. Ainsi, plusieurs personnes sur le réseau peuvent chacun avoir leur copie de la base de donnée sans avoir à ouvrir le même fichier MDB, et récupérer ou envoyer les données supprimées, ajoutées ou modifiées à l’aide d’une synchronisation avec une base commune que l’on place sur un réseau commun aux utilisateurs de cette base de données.

[curt]

Bonsoir,

F-leb, il me semble que la synchronisation n'existe plus dans Access 2010

manutek, je regarde comment contourner le problème.

Curt

[manutek]

Bonjour,

Oui, la réplication de base n'existe plus.

Si je considère que je suis obligé d'avoir une base par commercial, dois-je créé une sorte d'identifiant par base dans toutes les tables la composant?
Par exemple faire un champ "secteur" dans toutes les tables en mettant une valeur par défaut non modifiable en plus des n° auto (clés des tables) et fixer la valeur pour chaque commercial?

Si je décide d'avoir une seule base et que les commerciaux doivent se connecter au vpn pour y avoir accès, est-il facile de gérer l'accès qu'au tiers qu'ils ont créé et à leurs fiches ?

J'ai mis à jour les relations, cf PJ.

Merci de vos lumières et retour d'expérience.

[Richard_35]

Bonjour Manutek, Curt et Fabien,

Tout d'abord, bravo pour ta première approche !

Sur la forme :
Je te suggère de retirer les flèches à gauche (RIGHT JOIN) qui, je trouve, pollue un peu ton MCD (mais c'est juste mon avis). Dans tes requêtes, suivant tes besoins, tu devras alors décider si tu as besoin de flèche à droite ou de flèche à gauche.

Sur le fond :
Tu pourrais créer une même table locale sur la base Access des commerciaux avec un seul enregistrement qui serait :
- Code_commercial (clé primaire sans numéro auto)
- Nom
- Prenom
...

Effectivement, dans ce cas, il faut ajouter le champ Code_commercial à toutes les tables qui sont susceptibles d'être alimentées par les commerciaux et en faire une première clé primaire, en plus de l'actuelle présentée. Les tables contenant des données fixes n'ont pas besoin du code commercial (les données sont entrées en centrale). Il faudra donc coupler toutes les relations.

Notes que Code_commercial pourra être "forcé" en saisie des formulaires avec la valeur qu'il a dans la table locale. Notes, aussi, que l'application reste la même, quelque soit le commercial.

Enfin, dans l'application du directeur commercial, cela semble "être du gâteau" de traiter les tables locales des commerciaux.

[f-leb]

bonjour à tous,

pour info, la réplication a disparu avec le format .accdb apparu depuis la version 2007 d'Access.

Par contre rien n'empêche d'utiliser la réplication avec Access 2007&2010 à condition d'enregistrer la base au format .mdb.

Je me demande même si on ne peut pas utiliser une frontale au format .accdb, une dorsale au format .mdb, dorsale qui serait donc réplicable.

Merci au spécialiste de passage de confirmer que je ne raconte pas de bêtises.

[manutek]

Bonjour,

Merci pour votre aide.

J'avoue ne pas comprendre pourquoi mes relations (RIGHT JOIN) polluent mon MCD si c'est la traduction de la "réalité" ?
Il y a juste les relations codeSegment/codeApplications qui me semblent pas "propre".

Si je créé une seconde clé primaire "CodeCommercial" dans plusieurs tables, dois-je la lier à celle existante ou bien chacune est "indépendante" ?

Si je décide de faire une seule et unique base accessible via cpn+carte 3G, croyez vous que c'est utilisable ou cela va ramer et provoquer des problèmes ?

Je n'ai vu aucune option et/ou choix pour enregistrer ma base sous un autre format que le format accdb dans Access 2010 :'(

A suivre.

MErci
Manu

[Richard_35]

Bonjour Manutek,

Envoyé par Manutek

J'avoue ne pas comprendre pourquoi mes relations (RIGHT JOIN) polluent mon MCD si c'est la traduction de la "réalité" ?

==> Désolé, le mot est, sans doute, un peu fort. Et, en plus, c'est seulement mon avis. Le RIGHT/LEFT JOIN est proposé par Access au niveau des relations afin de le proposer, par défaut, dans les requêtes utilisant les deux tables concernées. C'est une facilité d'Access qui n'est pas, réellement, partie intégrante du MCD. En plus, dans certaines requêtes, tu pourrais avoir besoin du JOIN inverse à celui indiqué dans le MCD. Mais bon, c'est un détail et, encore une fois, ce n'est que mon humble avis.

Envoyé par Manutek

Il y a juste les relations codeSegment/codeApplications qui me semblent pas "propre".

==> Suivant ton MCD, Application est une sous-catégorie de Segment. De ce fait, tu pourrais ne stocker que CodeApplication dans la table Fiche (puisque 1 code application "appartient" à un et un seul code segment), mais, par facilité (requêtes), ce stockage est "permis"...

Envoyé par Manutek

Si je créé une seconde clé primaire "CodeCommercial" dans plusieurs tables, dois-je la lier à celle existante ou bien chacune est "indépendante" ?

==> Il faut recréer des liaisons sur 2 champs (mais je ne suis pas sûr d'avoir bien compris ta question...)

[f-leb]

bonsoir,

Envoyé par manutek

Je n'ai vu aucune option et/ou choix pour enregistrer ma base sous un autre format que le format accdb dans Access 2010 :'(

Fichier→Enregistrer et publier→Enregistrer la base de données sous→...

[manutek]

Bonjour du jour !

Pour les histoires de segments et applications, pour l'instant une application dépend d'un segment. Mais cette vérité pourra changer à l'avenir, une application pourrait être utilisée dans différents segments.
Du coup, j'ai corrigé mes liaisons et supprimé tout lien entre les 2 tables.
Je devrais pouvoir faire des sélections restrictives pour remplir mes fiches(si segment="01", alors applications comprise entre x et y) sur les formulaires de saisie et ainsi pouvoir faire évoluer la base ?
J'ai également supprimer les jointures LEFT et RIGHT suivant tes conseils. Je ne me suis pas encore penché sur les requêtes, mais je te fais confiance.

Pour l'enregistrement au format 2003, effectivement j’avais raté le menu qui est bien plus bas que les "Enregistrer sous...". ensuite apparaît des options de réplicats sous Access. Du coup j'ai une nouvelle question sur les réplicats, peut-on faire que de la synchronisation uniquement "ascendante", des réplicats vers la base "maitre" ?

Enfin, j'ai découvert le "numéro automatique" avec une taille de champ "entier long" et nouvelles valeurs "aléatoire".
Du coup je me demande si je pourrais pas prendre ça comme clé. Il y a peu de chance que j'ai 2 tiers de 2 commerciaux avec le même entier long aléatoire.
Qu'en pensez-vous ou sinon CodeCommercial dans toutes les tables ?

Merci

Manu

[Richard_35]

Bonjour Manutek,

Envoyé par Manutek

Il y a peu de chance que j'ai 2 tiers de 2 commerciaux avec le même entier long aléatoire.

==> peu, jusqu'à ce que... cela arrive. Ensuite, la sacro-sainte maxime :
"nous passons 80% de notre temps à gérer des situations qui arrivent dans 2% des cas"
s'appique à ton cas, me semble-t-il.

Personnellement, mais c'est mon avis, il me semble plus "propre" de prévoir le code commercial dans toutes les tables qu'ils sont susceptibles de remplir ; les autres (éventuelles) tables n'en ont pas besoin.

Enfin, si tu prévoies une table locale (sur chaque PC) qui contient le code commercial, ton application sera identique sur tous les PC (le code commercial sera "variabilisé").

[manutek]

Re,

Je viens de mettre à jour mes tables suivant tes conseils et pour éviter les cas aléatoirement possibles
En revanche, en ayant créé des clés primaires sur 2 champs dans les tables concernées (ID+CodeSecteur), je n'arrive plus à faire de liaison avec l'option cochée "intégrité référentielle".
J'ai un message d'erreur, "Index unique introuvable pour le champ référencé d'une table principale".
Je comprends le concept, mais comment dire à Access de faire une liaison en clé étrangère et clé primaire "double"(2champs) ?

[Richard_35]

Le commercial dont tu parles est donc un secteur.

Les tables "imposées" aux secteurs (non modifiables par eux) sont donc :
- Secteur ;
- Segment ;
- Applications ;
- TypesMachines ;
- Fournisseurs ;
- TypesMoteurs.

Ils ne peuvent donc saisir que dans les tables :
- Tiers ;
- Fiches ;
- LignesFiches.

Le message dont tu parles apparaît quand les données présentes dans les tables sont incompatibles avec l'intégrité référentielle que tu veux établir. Pour être tranquille, il faut donc :
- vider de leurs données les tables concernées (pas celles qui contiennent des données "imposées" aux secteurs) ;
- recréer les intégrités référentielles.

[Richard_35]

Un peu rapide sur l'interprétation du message...

Access impose de créer un index unique sur la table source afin que la clé primaire (deux champs) puisse être acceptée par l'intégrité référentielle.

Je ne sais pas si j'ai été clair, sur ce coup là...

[manutek]

Re,

En faites, c'est qu'il faut utiliser la touche "CTRL" pour sélectionner deux champs simultanément pour effectuer les liaisons.

Voici, le graph maj mais cela ressemble à une usine à gaz.

Est-ce que c'est ok ?
Si c'est ok, je vais me pencher sur les formulaires et sous formulaires

Merci pour ta patience,
Manu

[Richard_35]

Envoyé par Manutek

Voici, le graph maj mais cela ressemble à une usine à gaz.

==> ça dépends comment tu agences tes tables.

Tu peux t'affranchir de lier Secteur à toutes les tables qui contiennent sa clé, celle-ci étant "distribuée" à partir de la première relation.

[manutek]

Merci, c'est effectivement nettement plus lisible, on touche au but !

Je vois encore deux choses à éclaircir :

1-secteur auto sur base enfant
Ma table "secteurs" contient la liste de tous les secteurs existants, et sera utilisée pour les requêtes du Responsable Commercial.
Pour "identifier" chaque base (une par secteur), est-ce que j'ajoute un champ "Actif" a cette table en mettant par exemple un "1" au secteur "propriétaire" de la base ?

2-Modification de secteur
Mes secteurs sont définies de façon géographique. La répartition des secteurs peut de temps en temps être ajustée.
comment faire pour avoir la possibilité de modifier le secteur d'un tiers et les enregistrements liés si le code secteur faire parti des clés ?
Cette manipulation ne sera effectuée que par le Responsable Commercial.

Désolé mais une réponse, m'amène de nouvelles interrogations !

Merci
Manu

[Richard_35]

Précision :
Tu n'as pas réagi lorsque je t'ai dit :

Envoyé par Richard_35

Le commercial dont tu parles est donc un secteur.

1 commercial possède-t-il plusieurs Secteurs ?

[manutek]

Désolé

Un commercial = un secteur, c'est la même chose dans cette base.
Un commercial ne peut pas avoir plusieurs secteurs.
Par contre un tiers(client/prospect) peut changer de secteur/commercial dans de rare cas.

Pour donner des notions de quantité :
Nous avons 6 secteurs.
J'estime obtenir 400 tiers par secteur en moyenne (de 200 à 600 suivant secteur).
J'estime obtenir 3 fiches par tiers en moyenne (de 1 à 8).

Un changement de secteur va représenter la modification de 20 tiers.
On peut tabler sur 2 changements de secteur par an soit 40 tiers.

Si c'est trop compliqué, lors d'un changement de secteur on donnera les infos du secteur précédent et le commercial du nouveau secteur créera un tiers.
Nous supprimerons ensuite les données provenant de l'ancien secteur (tiers, fiches, ...).

Merci pour ta patience mise a rude épreuve
Manu

[Richard_35]

Ah OK, j'ai eu peur... donc :

Envoyé par Manutek

1-secteur auto sur base enfant
Ma table "secteurs" contient la liste de tous les secteurs existants, et sera utilisée pour les requêtes du Responsable Commercial.
Pour "identifier" chaque base (une par secteur), est-ce que j'ajoute un champ "Actif" a cette table en mettant par exemple un "1" au secteur "propriétaire" de la base ?

==> c'est une idée. Mais tu seras obligé, dans toutes tes requêtes avec Secteur en primaire, avec flèche à droite (LEFT JOIN), de sélectionner le secteur actif. Pourquoi ne pas avoir qu'un seul enregistrement dans la table Secteur (celui du commercial qui "transporte" la base) ?

Envoyé par Manutek

2-Modification de secteur
Mes secteurs sont définies de façon géographique. La répartition des secteurs peut de temps en temps être ajustée.
comment faire pour avoir la possibilité de modifier le secteur d'un tiers et les enregistrements liés si le code secteur faire parti des clés ?
Cette manipulation ne sera effectuée que par le Responsable Commercial.

==> sauf erreur, il s'agit d'une contrainte de dernière minute... tout d'abord, un commercial doit-il pouvoir créer des tiers (dans son application) ?