Contexte

Contraintes sur les clé dans le cas de la création de table

• une table créée peut être associée à un dictionnaire ayant ou non des champs clés
  • par exemple, si l'on construit une Table à partir d'un champs Json, on n'a pas besoin de clé
• par contre, il est interdit de construire une table externe, gérée par un dictionnaire Root
  • en effet, dans ce cas, Root est un indicateur de table externe explicite, ce qui implique un fichier de données dédié

En définitive, un schéma multi-table créé ne peut être Root, mais n'a sinon aucune contrainte sur les clés. Le schéma "natif" issu des variables relations non calculées (Table ou Entity) peut alors impliquer des dictionnaires ayant ou non des clés, à tous les niveau de la hiérarchie.
En fait, un schéma multi-table est spécifié selon sa structure hiérarchique, native ou calculée.
Un même schéma en flocon (ex: Customer-Services-Usages) peut être ainsi alimenté de plusieurs façon différentes:

• depuis trois fichiers, si le schéma est natif et exploite des dictionnaires avec des clés cohérentes
• depuis un seule table, avec un champs json permet de reconstruire le schéma à la volée par une règle de construction de table, impliquant des dictionnaires ayant ou non des clés, cohérentes enre elles ou non

Spécification

Dans la version V10 ou V11 de Khiops, un fichier de dictionnaire qui compile est nécessairement utilisable pour spécifier un mapping multi-tables, avec la liste des fichier nécessaire à l'alimentattion des données

Dans la version avec création de table, les contrôles se font en deux temps

• au moment du chargement du dictionnaire, on vérifie tout ce qui est possible
  • pour un dictionnaire Root, on peut vérifier que le système de clé de son schéma est cohérent
  • pour les schéma non Root, on ne peut pas vérifier a priori la cohérence des clé, car ces dictinnaires peuvent être utilisé en sortie de règles de création de table
  • on mémorise en indicateur interne les dictionnaire qui sont storable, ceux qui sont complètement cohérent vis a vis des clés
• au moment du choix d'un dictionnaire d'analyse
  • dans la liste d'aide, on met en tête les dictionnaires storable, puis une ligne blanche, puis les dictionnaires non storable
    • on les garde tous dans la liste d'aide, pour des raisons didactiques, et pour ne pas "inquiéter" les utilisateurs en cas d'absence de dictionnaires
  • on alimente la liste des fichiers selon le schéma natif du dictionnaire principal, qu'il soit cohérent ou non
    • cela permet ainsi de visualiser la structure native du schéma
    • mais on ne génère pas en temps réel des messages d'erreur complexes, à chaque changement de choix de dictionnaire d'analyse
• au moment du déclenchement d'une action (apprentissage, analyse)
  • on génère des messages d'erreur, les plus didactiques possibles

Context

• Khiops version: V12