Discussion :

[Rince83]

Bonjour à tous, bonne année, et bonne rentrée sur Developpez.com

Je travaille sur un projet qui implique de faire de l'analyse fonctionnelle avec Access. J'ai préparé une base de donnée (simplifiée) pour expliquer mon problème. En voici les relations et la base est disponible en fichier attaché.

.

La variable 1 est liée aux variables 2 (le couple est nommé couple12, association unique via un index multi champ, merci encore à ClaudeLeloup pour le tuyau ) et 3 (le couple n'est pas nommé). A noter que toutes les combinaisons entre les variables 1,2 d'une part et 1,3 d'autre part ne sont pas possibles.
L'analyse fonctionnelle est composée d'un objet, auquel est associé une variable 1, une variable 2 (sous la forme du couple12) et une variable 3.

J'aimerais créer un formulaire qui ressemble un peu au formulaire ci dessous. L'utilisateur doit pouvoir :
- visualiser les associations déjà réalisées entre les objets, et les variables 1, 2 et 3
- faire des modifications ou des ajouts : utiliser un menu déroulant pour sélectionner une variable 1, puis un autre menu déroulant pour chacune des variables 2, 3 de telle manière que seules les associations 1, 2 et 1,3 prévues dans les tables couples associées soient proposées. (De cette manière, la zone de texte contenant le couple12, se met à jour automatiquement.)



J'ai l'impression qu'il faut faire un sous sous formulaire, mais je n'arrive pas à expliquer à Access que je veux restreindre les variables 2 et 3 aux seuls couples prévus dans les tables couple12 et couple13. De même, je n'arrive pas à expliquer à Access qu'il faut mettre à jour le contenu de la zone de texte couple12). J'ai essayé de jouer sur les propriétés "Ajout autorisé" et "Modif autorisée", de prédéfinir des requetes et des les utiliser dans les formulaires sans grand résultat.

Merci par avance pour vos conseils et votre aide

[ClaudeLELOUP]

Bonjour,

Peux-tu aussi poster une version Access2000 de ta db ?

[Rince83]

Bonjour et merci pour l'intéret porté à cette question,

Voici la db attachée au format access 2000

[ClaudeLELOUP]

merci pour l'intéret porté à cette question

... mais, même en regardant ta base, je ne comprends pas ce que tu veux faire.

En partant de la capture d'écran peux-tu montrer ce que tu voudrais obtenir comme résultat.

[Rince83]

Cette base de donnée est destinée à réaliser des études d'analyse fonctionnelle : il faut relier les objets aux 3 variables qui leurs sont associées. Ce qui est important de comprendre, c'est que toutes les combinaisons de variables ne sont pas possibles. La variable la plus "centrale" est la variable 1 puisqu'elle intervient dans les 2 associations 1-2 et 1-3.

Je cherche à créer un formulaire qui permette à l'utilisateur de visualiser et de saisir ses analyse fonctionnelles sans avoir à se palucher manuellement quelles associations 1-2 et 1-3 sont possibles. Pour celà, je voudrais qu'il puisse utiliser un menu déroulant pour saisir sa variable 1, et que le formulaire lui propose uniquement les associations 1-2 et 1-3 qui sont prévues dans les tables couple12 et couple 13.

Pour expliquer plus clairement je rappelle les tables et je donne l'exemple sur l'objet 2.

La table couple12 comporte les éléments suivants
c12_1 | var1.1 | var2.1
c12_2 | var1.2 | var2.3
c12_3 | var1.3 | var2.1
c12_4 | var1.3 | var2.2

et la table couple13
var1.1 | var3.1
var1.1 | var3.3
var1.2 | var3.2
var1.3 | var3.1

=> in fine, celà veut dire que seuls les associations suivantes sont possibles :
var1.1 | var2.1 | var3.1
var1.1 | var2.1 | var3.3
var1.2 | var2.3 | var 3.2
var1.3 | var2.1 | var3.1
var1.3 | var2.2 | var3.1

Actuellement, la table analyse fonctionnelle comporte les éléments suivants pour l'objet o2
o2 | c12_3 | var3.1

et le formulaire ressemble à ça :


Je voudrais qu'il y aie un petit menu déroulant au niveau des points 1, 2 et 3 associé respectivement aux variables 1, 2, 3 :

- L'utilisateur clique sur 1. Un menu déroulant à 2 colonnes lui propose de choisir parmi les valeurs de la variables1 possibles. Il choisit mettons 1.3.
=> Mise à jour de la zone de texte Label_var1

- L'utilisateur clique sur 2. Un menu déroulant à 2 colonnes lui propose de choisir parmi les variables2 possibles. Comme il a sélectionné la variable 1.3, le formulaire ne lui propose que de choisir entre les variables 2.1 et 2.2. Par exemple, il sélectionne 2.2
=> Mise à jour de la zone de texte Label_var2
=> Mise à jour de la zone de texte Id_couple12 qui affiche donc l'id du couple [var1.3, var2.2] soit c12_4.

- L'utilisateur clique sur 3. Un menu déroulant à 2 colonnes lui propose de choisir parmi les variables3 possibles. Comme il a sélectionné la variable 1.3, le seul choix que le formulaire lui propose est la variable 3.1. Il valide
=> Mise à jour de la zone de texte Label_var3
=> Création dans la table T_Analyse fonctionnelle de l’enregistrement suivant :
o2 | c12_4 | var3.1

J'espère que c'est un peu plus clair, mais en tout cas, merci pour le temps passé à lire ma prose

[ClaudeLELOUP]

Et si on recommençait depuis le début ?

Tes tables ne me paraissent pas bien structurées.
Par exemple ceci est une hérésie : l'index12 n'a pas de raison d'être

Et tu devrais prendre l’habitude de choisir un champ de type NuméroAuto comme clé primaire de tes tables.


Si tu es d’accord, je te propose de guider tes premiers pas.
Peux-tu énumérer quelques items de tes tables T_var1, T_var2 et T_var3 en donnant à chaque item un libellé explicite (plus concret que libellé_(i) !)
Je te ferai alors une proposition de modèle et ensuite on s’attaquera au formulaire.

[Rince83]

Pour l'index12 de la table T_couple13 => Ok supprimé (il s'agissait d'un premier essai)

Pour les clés primaires de mes tables => Je ne peux pas malheureusement parce que les personnes qui utilisent l'analyse fonctionnelle sont habituées et raisonnent avec des libellés "maison". Je me ferait copieusement lyncher si j'essayais de changer leur habitudes. Déjà que les faire passer sous Acces, c'est compliqué...

Concernant ta demande d'expliciter encore un peu, je modifie la db. Les objets sont en fait des évènements qui sont constatés sur un circuit placé dans une usine les var1 sont des actions automatiques (ou pas d'ailleurs) qui permettent de corriger ces évènements, les var2 sont des signaux qui induisent ces actions et les var3 sont des besoins fonctionnels.

Dans l'exemple ci dessous, nous avons une fuite d'un réservoir de stockage d'eau.
On appelle la maintenance action a5.

A quel moment ? Quand on détecte de l'eau par terre dans le local.
=> C'est le signal s3 Détection inondation local réservoir

Pourquoi ? Pour réparer la fuite et éviter que les autres matériels court circuitent.
=> Ce sont les besoins b3 et b4
b3 Protéger les autres matériels
b4 Réparer la fuite

Dans la base en PJ, je n'ai volontairement pas réalisé l'association entre l'action a5, sur signal s3 et sur besoin b4. Je voudrais qu'il y aie des menus déroulants pour pouvoir faire cette association simplement : d'abord je sélectionne mon action ensuite mon signal et ensuite mon besoin.




Et merci encore pour ton aide

[ClaudeLELOUP]

Ah ! Ça devient passionnant !

Je te reviens si tôt que possible...

[ClaudeLELOUP]

Voici ce que je comprends.

Tu as des atomes…
- Actions
Ex. : a5 Appeler la maintenance
- Signaux
Ex. : s3 Détection inondation local réservoir
- Besoins fonctionnels
Ex. : b3 Protéger les autres matériels
Ex. : b4 Réparer la fuite

… tu voudrais pouvoir construire des molécules (Événements)
Ex. : Fuite du réservoir de stockage

Actions	Signaux	Besoins
a5	s3	b3 et b4

Quelles sont les habitudes actuelles des utilisateurs pour une action, entre eux, disent-ils « a5 » ou bien « Appeler la maintenance » ?
Même question pour Signaux et Besoins.

Peux-tu citer quelques autres exemples d'événement ?

[Rince83]

Message posté à 4h50, et bien, tu es matinal ! Il ne faut pas en perdre le sommeil hein ^^


Les identifiants des actions et des signaux sont plus compliqués que simplement une lettre et un chiffre, mais il respectent ce formalisme. Ils permettent aux utilisateurs de repérer en un coup d'oeil quels sont les matériels impliqués : il y a quelque part une table de correspondance entre les id et les matériels. En conséquence, les acteur font plutôt référence à l'action a2 plutôt que "Isolement des purges du réservoir". Je te confirme donc que c'est bien un champ de type "texte"^^ et que les utilisateurs veulent maintenir les 2 informations dans les formulaires pour éviter des confusions.

Concernant les besoins, c'est encore plus compliqué car il y a des distinctions entre des famille de besoin (liés à la sécurité, production, environnement etc...), et ces distinctions sont notamment repérées dans l'id de l'information, c'est encore un champ de type "texte" ^^

Concernant les évènements, j'ai pris dans la base l'exemple d'une fuite de réservoir et de la surchauffe d'une pompe, mais on peut citer tout type d'évènement redouté dans une usine : un incendie, une intrusion, un accident de personne, le dysfonctionnement d'un matériel etc...

Pour la comparaison avec les atomes/molécules c'est à peu près ça, tout en sachant que certaines combinaisons d'atomes "action" avec les atomes "signaux" et "besoin" ne sont pas possibles.

[ClaudeLELOUP]

Pour la comparaison avec les atomes/molécules c'est à peu près ça, tout en sachant que certaines combinaisons d'atomes "action" avec les atomes "signaux" et "besoin" ne sont pas possibles.

C'est comme cela dans la nature aussi !

Je sais bien que les clés utilisées actuellement (du texte) doivent impérativement apparaître telles quelles sur le formulaire, mais ce n'est pas une bonne raison pour les utiliser en tant que clé pour le modèle de données.

Au lieu de jouer à cache-cache, ne peux-tu donner carrément un extrait des tables qui sont utilisées maintenant sans trahir le secret professionnel ? Au moins, on pourra raisonner sur des cas concrets plutôt que sur des concepts généraux

[Rince83]

Bonjour Claude,

Comme tu l'as deviné, je suis lié par le secret professionnel et je ne peux donc pas envoyer des vrais extraits de mes tables. J'apprécie beaucoup l'aide que tu m'as et que tu continue de m'apporter et ça m'embete un peu de te faire cette réponse. Je vais donc un peu enrichir la base de données avec des identifiants plus réalistes, mais je ne peux pas mettre de vraies données.

Comme je te l'expliquais les libellés permettent aux utilisateurs avertis d'identifier facilement quelles sont les matériels concernés.

Par exemple, la fermeture des purges du réservoir est une action dont le libellé est de la forme a-R-PURG-01 et l'ouverture de ces purges (en cas de trop plein) sera a-R-PURG-02 : le libellé suffit ainsi à l'utilisateur pour savoir que c'est une action (a), qui concerne le réservoir (R) et plus précisément ses purges (PURG).

Dans tous les cas la fermeture ou l'ouverture des purges seront effectives sur un signal élaboré par les même mesures de niveaux respectivement à la baisse ou à la hausse : s-R-NIV-01 et s-R-NIV-02 : signal qui concerne le niveau du réservoir.

Quand au besoin. L'usine à besoin de ce réservoir, pour fonctionner. Le besoin "Garantir le niveau du réservoir" est donc libellé "b-R-PROD-01" : besoin qui concerne le réservoir pour la productivité de l'usine. Par contre, la température du liquide contenu dans ce réservoir n'impacte pas la production, mais uniquement la sécurité des travailleurs. Le besoin va donc être libellé "b-R-SECU-01". Mettons qu'il y aie un besoin sur le pH du liquide du réservoir à la fois pour la production et la sécurité des ouvriers "b-R-PROD-02" -> garantir un pH du liquide du réservoir compris entre 5 et 10 pour la production et "b-R-SECU-02" -> garantir un pH du liquide du réservoir compris entre 6 et 8 pour la sécurité.

En me relisant, je me rends compte que ça ne répond pas forcément précisément à ta question... J'en suis désolé et je fais pourtant de mon mieux compte tenu de la complexité des données concernées et de mes contraintes ! Est ce que tout celà t'éclaire quant même un peu ?

base_exemple5.zip

[ClaudeLELOUP]

J’ai donc à l’écran, trois listes, en fait trois sous-formulaires qui affichent en continu chaque ligne des tables : tActions*, tSignaux* et tBesoins.

Les items sont classés par ordre alphabétique.

À côté de chaque item : une case à cocher.

L’utilisateur a la possibilité de cocher
- 1 case dans la liste des actions,
- 1 case dans la liste des signaux,
- plusieurs cases dans la liste des besoins.

L’ensemble des cases cochées constitue un événement.

L’utilisateur complète alors un champ du formulaire principal pour donner un nom à l’événement qu’il vient de composer.
Un clic sur un bouton déclenche le processus de mise à jour de la table tEvenements, donc autant d’enregistrements qu’il y a de cases cochées dans la liste des besoins. (1 par combinaison action/signal/besoin.)

Ce que je n’ai pas encore compris : le programme doit-il être capable de détecter si la combinaison des cases cochées est cohérente ?
En d’autres mots lorsqu’une case a été cochée dans les actions, faut-il réduire les choix possibles des signaux et quand le couple action/signal est formé, réduire les choix des besoins ?
Si oui, quel est l’algorithme qui permet ces restrictions successives ?


* Une zone de liste modifiable plutôt qu'un sous-formulaire

[Rince83]

J’ai donc à l’écran, trois listes, en fait trois sous-formulaires qui affichent en continu chaque ligne des tables : tActions*, tSignaux* et tBesoins.

Les items sont classés par ordre alphabétique.

À côté de chaque item : une case à cocher.

L’utilisateur a la possibilité de cocher
- 1 case dans la liste des actions,
- 1 case dans la liste des signaux,
- plusieurs cases dans la liste des besoins.

L’ensemble des cases cochées constitue un événement.

L’utilisateur complète alors un champ du formulaire principal pour donner un nom à l’événement qu’il vient de composer.
Un clic sur un bouton déclenche le processus de mise à jour de la table tEvenements, donc autant d’enregistrements qu’il y a de cases cochées dans la liste des besoins. (1 par combinaison action/signal/besoin.)

* Une zone de liste modifiable plutôt qu'un sous-formulaire

D'accord, j'étais parti un peu bille en tête sur un système avec des listes déroulantes, mais utiliser des cases à cocher peut aussi répondre au besoin. Serait il possible de voir une petite capture d'écran ?

Ce que je n’ai pas encore compris : le programme doit-il être capable de détecter si la combinaison des cases cochées est cohérente ?
En d’autres mots lorsqu’une case a été cochée dans les actions, faut-il réduire les choix possibles des signaux et quand le couple action/signal est formé, réduire les choix des besoins ?
Si oui, quel est l’algorithme qui permet ces restrictions successives ?

Tout à fait. Si tu préfères, et sur les exemples de la base : ça ne sert à rien de proposer à l'utilisateur la mise en service de l'appoint du réservoir en cas de surchauffe de la pompe. Les associations possibles sont celles qui sont explicitement définies dans les 2 tables couples.

[ClaudeLELOUP]

Bonjour,

Serait il possible de voir une petite capture d'écran ?

Encore rien de concret

J’ai donc à l’écran, trois listes,

c'est le produit de mon imagination...

D'accord, j'étais parti un peu bille en tête sur un système avec des listes déroulantes, mais utiliser des cases à cocher peut aussi répondre au besoin

Une zone de liste c'est OK lorsqu'il n'y a qu'un choix possible, donc OK pour actions et signaux, mais NOK pour besoins => case à cocher dans un sous-formulaire.

Ce à quoi je réfléchissais actuellement, c’était la création d’un événement.
Si on veut restreindre le choix dans ce formulaire-ci, il faut prévoir une étape antérieure dans laquelle un humain a constitué les couples autorisés, donc à l’aide d’un autre formulaire où on juxtapose la liste des actions et celle des signaux.
L'utilisateur choisit un membre dans chaque liste et clique un bouton qui garnira une table des couples.
Au fait, quand une action est choisie est-il possible de déterminer a priori les signaux encore susceptibles de former un couple ?

Ai-je compris ?


Si oui, il restera sans doute à créer un outil pour montrer les événements qui ont été construits.
As-tu déjà une idée de la manière ?

[Rince83]

re bonjour,

Une zone de liste c'est OK lorsqu'il n'y a qu'un choix possible, donc OK pour actions et signaux, mais NOK pour besoins => case à cocher dans un sous-formulaire.

Je ne suis pas sûr de voir ce que tu veux dire par "un (seul) choix" possible. Pour moi la zone de liste déroulante permet bien de choisir parmi plusieurs choix possible.
Par exemple pour les actions :

Si on veut restreindre le choix dans ce formulaire-ci, il faut prévoir une étape antérieure dans laquelle un humain a constitué les couples autorisés, donc à l’aide d’un autre formulaire où on juxtapose la liste des actions et celle des signaux.
L'utilisateur choisit un membre dans chaque liste et clique un bouton qui garnira une table des couples.
Au fait, quand une action est choisie est-il possible de déterminer a priori les signaux encore susceptibles de former un couple ?

C'est exact. Les couples actions/signaux sont prédefinis (c'est ce que je voulais dire quand je disais que ça ne servait à rien de proposer à l'utilisateur la mise en service de l'appoint du réservoir en cas de surchauffe de la pompe). Les associations possibles sont uniquement celles qui sont explicitement définies en "dur" dans la table T_couple12 qui m'est fournie par la direction de l'usine. Ils dépendent de la conception de l'usine et sont figés une bonne fois pour toute. A un point tel que nous n'avons pas identifié le besoin de créer un formulaire pour la remplir ^^.
Pour les couples actions/besoins, c'est un peu plus compliqué car il y a beaucoup de travail là dessus aujourd'hui. Mais il y a toujours cette idée que les associations possibles sont strictement celles qui sont définies dans la table T_couple13 : pas d'ajout possible.

Toujours pour clarifier, on cherche bien à remplir/afficher le contenu de la table T_AnalyseFonctionnelle : à une liste d'évènements donnés (définis à priori dans la table T_Evenement) est associé plusieurs triplets (action, signaux, besoins). Ces triplets sont composés des couples actions/signaux et actions/besoins qui sont définis à priori dans les tables T_couple12 et T_couple13.
Quand l'utilisateur choisit son action, il faut ainsi que l'outil soit capable de lui proposer uniquement de sélectionner le signal (resp. le besoin) parmi les signaux (resp besoins) prédefinis dans la table T_couple12 (resp T_couple13).

De manière occasionnelle, il peut y avoir ambiguïté sur le signal ou sur le besoin qui est pertinent : pour la fuite du réservoir, on peut imaginer par exemple que les purges puissent se fermer sur signal "baisse du niveau" ou sur signal "démarrage de l'appoint" sans trop savoir lequel arrivera en premier compte tenu de l'état des automates, de l'age du capitaine etc... Dans ce cas, qu'à celà ne tienne, ce sera à l'utilisateur de bien faire les choses et de créer 2 enregistrements dans la table T_AnalyseFonctionnelle (en utilisant le formulaire que nous sommes en train de créer).

[ClaudeLELOUP]

Je ne suis pas sûr de voir ce que tu veux dire par "un (seul) choix" possible. Pour moi la zone de liste déroulante permet bien de choisir parmi plusieurs choix possibles.

La zone de liste modifiable propose effectivement plusieurs items. Parmi ceux-ci, l’utilisateur peut élire n’importe lequel, mais un seul . Celui-ci restera affiché lorsque la liste sera repliée.

Je te propose de constituer un jeu de test.
Fournis-moi un fichier Excel avec 3 feuilles :
- une qui donne des exemples d’association action/signal ;
- une seconde qui donne des exemples d’association action/besoin.
N’hésite surtout pas à inclure le cas d’ambiguïté dont tu parles dans ton dernier paragraphe ;
- une troisième qui montre ce que tu voudrais voir dans la T_AnalyseFonctionnelle.