Discussion :

[michael_g]

Bonjour,

Ne parvenant pas établir de nouvelles conditions pour la construction des trains, en plus des conditions que l'on a déjà pu mettre en évidence auparavant, que penses-tu de mettre de côté le programme pour le moment et de revenir à une construction "manuelle" des trains et non pas automatisée via un programme ?

Je m'explique. Dans les débuts de notre conversation lorsque l'on raisonnait uniquement en requêtes access (avec nos tables "Causes", "Effets" et "EffetsQuiSontDesCauses"), ce que tu avais finalement fait c'était de débuter la création des trains jusqu'au 2ème wagon-composant (Causes --> Effets pour déterminer le 1er wagon-composant puis "EffetsQuiSontDesCauses" --> "Effets" pour déterminer le 2è wagon-composant). Pour alors poursuivre l'ajout d'un 3ème wagon, pourquoi ne pas refaire alors une requête access du même type pour déterminer "EffetsQuiSontDesCauses_2" qui contiendraient les effets qui sont aussi des causes de la table précédente ? Et on noterait le num_compo associé à cette nouvelle relation cause/effet pour ajouter un nouveau wagon-composant au train. Schématiquement (je tente un petit dessin pour éclaircir mon propos!), ça donne ça :



On revient à chaque fois à notre première table ("AMDEsout") car c'est elle qui contient l'ensemble des relations cause/effet possible.

Certes, le problème c'est qu'on n'automatise pas le processus, mais je suis quasi sûr qu'après quelques requêtes telles que décrites ci dessus ça va s'arrêter parce qu'à mon avis nos trains vont être courts.

[ClaudeLELOUP]

Bonjour,


Il me semble que ce que tu proposes, c'est ce que fait le programme actuel.
Je me demande si l’origine du résultat inattendu n’est pas à chercher du côté de la structure particulière de la table : si tu compares les colonnes « LesCauses » (le code) et « Causes » (le libellé), on a pour un même code plusieurs libellés possibles et pire, une même cause (CCS_SS_1) peut inférer deux effets (MR_SS) qui ont des libellés différents… que l’on retrouve à nouveau dans la colonne « Causes ». Je ne connais pas la problématique « métier », mais j’ai le sentiment que cela va provoquer un carrousel !





Je vais essayer de prendre UNE combinaison Cause/Effet et suivre sa démultiplication à la trace.

[michael_g]

Bonjour,

Oui je pense bien que c'est déjà ce que fait le programme que tu as créé. Ma proposition de faire ça en "manuel" permettrait de s'assurer qu'il n'y aurait pas un souci quelconque dans le programme qui expliquerait les drôles de résultats observés.

Ton intuition me semble intéressante en effet concernant les causes-code et les causes-libellé mais je ne peux qu'être d'accord sans argument particulier pour défendre ! Ceci dit, en termes de problématique "métier", tout l'intérêt du travail que l'on réalise avec ce programme, c'est justement de mettre en évidence ces chaînes causes/effets car une même cause peut engendrer plusieurs effets et un même effet peut être généré par plusieurs causes, ce qui complique atrocement mon sujet. D'où la BdD, et d'où le programme pour tenter d'y voir plus clair.

Tiens moi au courant pour la démultiplication de LA cause/effet que tu suis à la trace.

Un dernier mot. Le souci quant à la démultiplication énormissime que l'on observe ne viendrait-elle pas (en partie au moins...!) du fait que l'on ait des trains de ce genre :

• 1er train : A --> B --> C --> D --> E
• 2è train : B --> C --> D --> E
• 3è train : C --> D --> E

Ici, seul le 1er train est pertinent à garder car le 2ème et 3ème train ne sont que des "sous-trains" du 1er. Si on laisse le programme faire ce genre de "sous-trains", ça peut vite en créer beaucoup pour pas grand chose !

Merci à toi.

[ClaudeLELOUP]

Avec le seul couple CCS_SS_1/CCS_SS_2, le programme crée 286 618 trains, tous différents.



156 trains comportent 19 wagons dont le 19e est toujours I_SS_8 (Requête2).

La BdD est ici : http://claudeleloup.developpez.com/&...0v28052014.mdb

[michael_g]

Bonjour,

Et merci pour cette nouvelle BdD.
Le nombre de trains (ainsi que le nombre de wagons, qui ne s'est arrêté qu'à 19 car tu as stoppé le programme) est encore une fois bien trop grand. Bien que les trains soient tous différents, comme dans les essais précédents, la plupart ne sont "physiquement" pas possible dès les 3ème wagon dans la mesure où aucun effet dû au Wagon 2 n'est une cause de défaillance du Wagon 3.

Je ne parviens vraiment pas à voir comment le programme arriver à créer ce genre de liens causes/effets qui n'existent pas (et qui se traduisent donc par un ajout de wagon qui n'a pas lieu d'être) ! PEut-être à cause du point que tu soulèves entre les "codes" et les "libellés". Aurais-tu une idée pour que le programme les distingue ... ?

[ClaudeLELOUP]

Bonjour,

où aucun effet dû au Wagon 2 n'est une cause de défaillance du Wagon 3

Quelque chose m'échappe !

Peux-tu prendre un train dans l'échantillon et m'expliquer pourquoi (table à l'appui) l'effet du wagon 2 n'est pas une cause de défaillance du wagon 3.

[michael_g]

Bonjour,

Peux-tu prendre un train dans l'échantillon et m'expliquer pourquoi (table à l'appui) l'effet du wagon 2 n'est pas une cause de défaillance du wagon 3.

L'ensemble des trains commencent par CCS_SS_1 puis CCS_SS_2, ce que j'approuve car la cause "endommagement des composants "bord" de contrôle-commande" entraîne l'effet "perturbation de la signalisation ferroviaire" (ligne 234 : affectant CCS_SS_1) qui entraîne elle-même "mise en danger des usagers", "perturbation de la circulation ferroviaire" et "interruption de la circulation ferroviaire" (respectivement ligne 238, 239 et 240 : affectant CCS_SS_1).



Mais, sauf erreur de ma part, aucun de ces 3 effets n'est une cause parmi au sein des composants PCC_SS ou I_SS_5 ou I_SS_7. Or, le programme poursuit en attachant un de ces 3 composants comme nouveau wagon après CC_SS_2.
Mais,

• le programme a juste lorsqu'il poursuit en attachant CCS_SS_2 à I_SS_6 car "perturbation de la signalisation ferroviaire" entraîne "perturbation de la circulation ferroviaire" (ligne 232 : affectant CCS_SS_1) qui entraîne à son tour "perturbation de la mobilité des usagers" (ligne 124 : affectant I_SS_6), et ça s'arrête là.
• Le programme semble oublier CCS_SS_1 --> CCS_SS_2 --> G_SS qui se forme via la causalité suivante : "perturbation de la signalisation ferroviaire" entraîne "perturbation de la circulation ferroviaire" (ligne 232 : affectant CCS_SS_1) qui entraîne à son tour "perturbation de la mobilité des usagers" (ligne 248 : affectant G_SS).

Du coup, le programme semble "inventer" des liens de causalité et en "oublier" certains.

[ClaudeLELOUP]

Bonjour,

Je me suis basé sur ce que tu proposes dans ton billet 41, mais en basant le raisonnement sur le libellé des causes/effets sans tenir compte des codes Num_compo, à l’image de l’explication que tu donnes dans ton billet 47.
La requête rNiveau1




nous donne les 268 combinaisons différentes Cause/effet.
Dans les requêtes rNiveau2 à rNiveau9, on ajoute une colonne à la rNiveau qui précède :




Cela revient à ajouter à la précédente requête autant de lignes que l’on trouve de derniers effets étant eux-mêmes une cause. Ce qui donne :
Niveau1 : 268
Niveau2 : 716
Niveau3 : 1196
Niveau4 : 1715
Niveau5 : 2019
Niveau6 : 2192
Niveau7 : 2254
Niveau8 : 2262
Niveau9 : 2262
Au plus on progresse dans les niveaux, au moins on ajoute de lignes au précédent, jusqu’à constater qu’on ne progresse plus au-delà du niveau 8.
Dans la requête rResultat, j’ai classé les lignes du niveau 8 dans l’ordre croissant de longueur.

La BdD est ici : http://claudeleloup.developpez.com/&...0v28052014.mdb

[michael_g]

Bonjour,

Super cette nouvelle BdD !
D'un point de vue "métier", le nombre de trains me semble très plausible et surtout le nombre de successions de causes/effets qui plafonnent relativement vite à 8 est vraisemblable.
Je continue de regarder ça de plus près pour voir s'il n'y a pas d'association cause/effet impossible, mais ça me semble extrêmement prometteur.

Du coup, pour revenir au champ Num_compo qui est le plus intéressant pour moi, pourrais-tu faire apparaître pour chaque niveau supplémentaire créé le Num_compo correspondant au libellé des causes/effets qui vient d'être ajouté ? En ajoutant par exemple dans la requête rRésultat après chaque colonne du nouvel effet trouvé le Num_compo dont il est issu.

Encore merci pour ton indispensable aide.

[ClaudeLELOUP]

Du coup, pour revenir au champ Num_compo qui est le plus intéressant pour moi, pourrais-tu faire apparaître pour chaque niveau supplémentaire créé le Num_compo correspondant au libellé des causes/effets qui vient d'être ajouté ? En ajoutant par exemple dans la requête rRésultat après chaque colonne du nouvel effet trouvé le Num_compo dont il est issu.

Oui, mais le problème – encore une fois ! –, c'est qu'un même intitulé a plusieurs Num_compo possibles...



je n'en montre que 2, mais il y en a plus !

[michael_g]

Arg, oui oui exact. Au temps pour moi.

Du coup, comme tu l'avais imaginé dans ton billet 24, il y a bien l'idée de "fusionner" le Num_compo et le libellé (pour les causes comme pour les effets).
Penses-tu alors faire le même travail que dans ton billet 48, mais cette fois ci on aurait dans la requête rResultat les libellés précédés du Num_compo ?
Parce que j'ai peur que ça coince puisque, si les requêtes successives parviennent à se faire, c'est bien parce que les libellés "causes" et "effets" sont rédigés exactement de la même façon. Si l'on fusionne, on obtiendra par exemple des choses comme "CCS_SS_1Perturbation de la signalisation ferroviaire" (effet : ligne 234) et "CCS_SS_2Perturbation de la signalisation ferroviaire" (cause : ligne 238) qui ne seront pas reconnus comme un lien de causalité lors de l'exécution de la requête alors qu'il le devrait.

[ClaudeLELOUP]

J’ai procédé d’une manière analogue en mémorisant à chaque étape les Num_compo et les intitulés : requêtes rNiveau10 à rNiveau100.

À rNiveau90, on atteint 23 523 combinaisons (rNiveau100 n’ajoute plus rien).

Regarde la requête rResultat100, c’est la requête100 dans laquelle j’ai supprimé les libellés et regroupé les lignes identiques. Il reste 4492 lignes différentes, certaines sont incluses dans d’autres. De plus sur une même ligne, on trouve parfois plusieurs fois le même Num_compo.
Si partant de cette requête rResultat100,
- on supprime les doublons de Num_compo,
- on supprime les lignes incluses dans d’autres,
se rapproche-t-on de ton objectif ?

La BdD complétée se trouve ici : http://claudeleloup.developpez.com/&...0v28052014.mdb

[michael_g]

Hello,

Merci pour la BdD. C'est excellent que tu aies pu mémoriser le Num_compo à chaque fois que la requête détecte un lien de causalité.

Donc, une fois ce travail fait, le traitement des données est le suivant d'après moi :

1. Supprimer les libellés pour ne garder que les Num_compo
2. Supprimer les lignes en double
3. Supprimer les les lignes dans lesquelles au moins un Num_compo apparaît + d'1 fois
4. Supprimer les lignes qui sont incluses dans d'autres lignes

Deux petites questions que je me pose alors :

1. Dans l'étape 3 ci-dessus, on est bien d'accord qu'il n'y a pas de souci a carrément supprimer la ligne présentant un doublon de Num_compo au lieu de "couper" cette même ligne à partir du Num_compo en doublon (A --> B --> C --> D --> B --> E devenant A --> B --> C --> D) ? Car toute la partie de la ligne avant le doublon existe bien ailleurs dans une ligne en tant que telle (dans mon exemple : A --> B --> C --> D) ?
2. J'ai pu faire les 3 premières lignes de traitement des données (sur excel) mais pas la 4ème, ne sachant pas le faire sur excel. Saurais-tu faire une requete sur access pour supprimer les lignes incluses dans d'autres ?

Merci !

[ClaudeLELOUP]

Bonjour,

Point 3

Si j'ai la ligne N° 34862 comme ceci,




je me proposais de la remplacer par ceci :



En d'autres mots, je garde les wagons dans l'ordre où ils ont été créés, mais je supprime les doublons au fur et à mesure que je les rencontre en parcourant le train de gauche à droite.

Peux-tu me dire, ce que, selon toi, la ligne 34862 doit devenir ?

Saurais-tu faire une requête sur Access pour supprimer les lignes incluses dans d'autres ?

Je ne suis pas un virtuose du SQL. Par contre, je crois pouvoir y arriver en VBA.

Mon idée

- On part de la requête rResultat100 pour se constituer une table (tResultat) qui contiendra une colonne supplémentaire «AuFinal » ;
- on lit chaque enregistrement et on alimente la colonne « AuFinal » avec les wagons « retenus » (ton point 3).
- on regroupe ensuite tous les enregistrements de tResultat qui sont identiques ;
- on relit les enregistrements un à 1, pour supprimer tous ceux dont « AuFinal » est inclus dans le « AuFinal » d’un autre enregistrement.

[ClaudeLELOUP]

Pour autant que la méthode expliquée au billet précédent te convienne, il y a 663 combinaisons et la plus longue se compose de sept éléments.
La BdD est ici : http://claudeleloup.developpez.com/&...0v28052014.mdb

[michael_g]

En d'autres mots, je garde les wagons dans l'ordre où ils ont été créés, mais je supprime les doublons au fur et à mesure que je les rencontre en parcourant le train de gauche à droite.

C'est ce que j'avais aussi en tête concernant les lignes où l'on avait des doublons de wagons, mais j'ai un autre raisonnement en tête. Si on transforme ces lignes comme tu le proposes, on crée des lignes... qui existent déjà finalement. Dans ton exemple, SMI_1 --> SMI_1 --> I_SS_6 --> MR_SS --> CCS_SS_1 --> CCS_SS_1 --> I_SS_6 devient SMI_1 --> I_SS_6 --> MR_SS --> CCS_SS_1. Or, je pense que cette ligne existe déjà plus loin car la requête l'a crée en tant qu'autre train. Ainsi, en transformant des lignes contenant des wagons en plusieurs exemplaires, on crée finalement un doublon de train. Et comme on cherche par la suite à supprimer les trains en double... il est inutile de s'occuper de ces trains aux wagons en doublons. Qu'en penses-tu ?

Mon idée
- On part de la requête rResultat100 pour se constituer une table (tResultat) qui contiendra une colonne supplémentaire «AuFinal » ;
- on lit chaque enregistrement et on alimente la colonne « AuFinal » avec les wagons « retenus » (ton point 3).
- on regroupe ensuite tous les enregistrements de tResultat qui sont identiques ;
- on relit les enregistrements un à 1, pour supprimer tous ceux dont « AuFinal » est inclus dans le « AuFinal » d’un autre enregistrement.

Ton idée me semble très bonne, rien à redire a priori.

Pour autant que la méthode expliquée au billet précédent te convienne, il y a 663 combinaisons et la plus longue se compose de sept éléments.

Je crois que ton résultat est plus que convenable ! Car, j'ai supprimé les lignes qui sont incluses dans d'autres lignes sur excel de façon "manuelle" (en classant toutes les lignes par ordre alphabétique sur le 1er wagon et sur le 2ème wagon et sur le 3ème... jusqu'au dernier wagon, il était assez facile d'identifier visuellement les lignes qui étaient des "sous-lignes" d'autres) et figure-toi qu'il m'est resté 651 combinaisons dont les plus longues font 7 wagons. Et toi tu me proposes 663 combinaisons en ayant "automatisé" mon point 4. Sachant que mes yeux sont loin d'être infaillibles, il est plus que raisonnable de croire que ton résultat de 663 combinaisons est correct !

[ClaudeLELOUP]

♫ ♫ Alors, on danse ! ♫ ♫

[michael_g]

♫ ♫ Alors, on danse ! ♫ ♫

C'est ça !

Mais juste avant de danser et danser encore :

C'est ce que j'avais aussi en tête concernant les lignes où l'on avait des doublons de wagons, mais j'ai un autre raisonnement en tête. Si on transforme ces lignes comme tu le proposes, on crée des lignes... qui existent déjà finalement. Dans ton exemple, SMI_1 --> SMI_1 --> I_SS_6 --> MR_SS --> CCS_SS_1 --> CCS_SS_1 --> I_SS_6 devient SMI_1 --> I_SS_6 --> MR_SS --> CCS_SS_1. Or, je pense que cette ligne existe déjà plus loin car la requête l'a crée en tant qu'autre train. Ainsi, en transformant des lignes contenant des wagons en plusieurs exemplaires, on crée finalement un doublon de train. Et comme on cherche par la suite à supprimer les trains en double... il est inutile de s'occuper de ces trains aux wagons en doublons. Qu'en penses-tu ?

Quel est ton avis là dessus ?


Je continue à bien vérifier que ta requete "AuFinal" est bien la bonne. Et puis ensuite "il n'y aura plus qu'à" faire une BdD propre qui, à partir d'une table type "AMDEsout" nous sorte la requête "AuFinal".

[ClaudeLELOUP]

La suppression des trains identiques est quasi instantanée.
Ce qui demande du temps, une fois que tous les trains (1728) sont différents, c'est de détecter et éliminer ceux qui sont inclus dans d'autres.

Mais en tout, le temps d'exécution reste raisonnable.

[michael_g]

Bonjour Claude,

Toujours sur les mêmes données, petite aide à te demander quant à leur traitement.

Dans la BdD ci jointe, tu trouveras l’ensemble des trains (tous uniques, pas de trains inclus dans l'autre etc. etc.) dans la Table "TousLesTrains".

Ce que je souhaite, c'est connaître le nombre de liens entre des Num_compo pris deux à deux. Par "lien", j'entends lien de causalité, c'est-à-dire le fait qu'un wagon B soit à la suite d'un wagon A.
J'ai déjà essayé une requête de recherche de doublons, tout simplement. Et ça marche pour trouver les doublons deux à deux parmi les wagons 1 et 2 (requête "Doublons1-2"), puis parmi les wagons 2 et 3 (requête "Doublons2-3"), puis parmi les wagons 3 et 4 (requête "Doublons3-4"), etc.
Mais, je ne sais pas comment faire une requête qui me cumulerait dans une même table l'ensemble des doublons trouvés.

La BdD en question est ici : 03072014BdD-graphes_souterrain.7z