Avoid using unnecessay key variables in multi-table feature construction

Bug de construction de variable pour le multi-table

Contexte

schéma en étoile, construction de variable
comme la clé d'une sous-table (du moins la sous-partie commune à la clé de la table mère) ne peut contenir d'information déjà traitée dans le dictionnaire parent, cette clé n'est pas exploitée pour la construction de variable
exemple: SpliceJunction
- la variable SampleId est utilisé en clé de SpliceJunction
- la variable SampleId est utilisée en clé de la table secondaire SpliceJunctionDNA
- on exploite donc pas cette variable

Bug:

si le champ clé de la table secondaire a un autre nom, cette variable secondaire est alors traitée à tort comme un champ non clé distinct de la clé du dictionnaire parent, et est exploitée pour la construction de variable
exemple:
- SpliceJunction, en renommant SampleId en sampleId dans la table secondaire
- les résultats de modélisation en générant 100 variables sont alors différents à tort

Correction à mettre en place:

ne plus se baser sur le nom de variable commun à la table parent et la table secondaire, mais sur le rôle identique de la variable secondaire en tant que clé commune

KhiopsML / khiops