On peut vous aider ?
Cherchez des réponses ou parcourez les rubriques de notre documentation
Assemblage des données
Résumé
Lors de l’exécution d’une action de lancement de collecte ou d’une action de lancement de restitution, la création d’un document est réalisée ainsi :
Pour chaque entité définie par la relation d’affectation,
- Le serveur duplique le modèle.
- Un jeu de données comportant, pour l’entité concernée, tous les champs du carnet d’adresses et tous les champs de la relation d’affectation est créé : c’est le noyau.
- Chaque compartiment du document ainsi dupliqué est alimenté par un jeu de données résultant de la jointure entre la source de données du compartiment avec les axes de diffusion.
Les axes de diffusion permettent donc de filtrer les données des compartiments. Dans l’exemple fourni par le schéma ci-dessus, le document de l’entité « Shop 1 » recevra la valeur « 12 » pour le champ « EMPLOYEES » grâce à la jointure sur entre l’axe de diffusion « SHOP » et le champ « SHOP » des données d’alimentation. Si l’axe de diffusion n’avait pas été « SHOP » mais « ID », alors cette jointure n’aurait pas été réalisée et le compartiment aurait reçu la totalité des enregistrements contenus dans les données d’alimentation.
Construction du noyau
Le noyau est la vue rassemblant les données du carnet d’adresse et de la relation d’affectation.
Les données du noyau sont produites à partir d’une jointure interne entre le carnet d’adresses et la relation d’affectation.
La jointure est effectuée sur l’axe de liaison (cet axe doit être commun au carnet d’adresse et à la relation d’affectation).
Tous les champs de la relation d’affectation sont incorporés dans le noyau.
Les champs du carnet d’adresses qui n’existent pas dans la relation d’affectation sont également incorporés dans le noyau : c’est pourquoi il est nécessaire de veiller à n’y inclure que les champs strictement nécessaires afin de ne pas dégrader inutilement les performances.
Les axes de diffusion et l’axe de liaison avec le carnet d’adresses doivent constituer une clé pour les données du noyau.
Production des blocs de données associés à chaque compartiment
Pour chacune des entités-correspondants (chaque ligne du noyau) :
Pour chacune des tables/vues associées à un compartiment dans l’action de lancement de campagne :
Une jointure externe gauche est réalisée entre le noyau et la table/vue du compartiment.
Cette jointure est effectuée sur les axes communs entre la table/vue du compartiment et les axes de distribution.
Tous les champs de la table qui ne sont pas déjà dans le noyau (donc ni dans le carnet d’adresses ni dans la relation d’affectation) sont ajoutés au bloc de données.
Si un champ existe dans le noyau et dans la table du compartiment, le champ de la table sera ignoré. Si le champ de la table n’a pas la même signification que dans le noyau et que l’on souhaite l’exploiter dans le questionnaire, le champ de la table ou celui du noyau devrait être renommé (et éventuellement les composants en conséquence).
Puisqu’une jointure externe est réalisée entre le noyau et la table du compartiment, la limitation de l’envoi des questionnaires à certaines entités ne peut être effectuée sur la table du compartiment, elle doit être effectuée sur la relation d’affectation.
Le fait de restreindre une table du compartiment à certaines entités ne personnalisera pas les données pour ce compartiment, mais le questionnaire sera quand même envoyé.
Si aucun axe parmi les axes de distribution n’existe dans la table/vue du compartiment, un produit cartésien est réalisé entre le noyau et la table/vue du compartiment.
Dans ce dernier cas, si la table/vue du compartiment ne contient aucune donnée, seules les données du noyau sont produites, les axes de la table du compartiment qui ne sont pas déjà dans le noyau sont ajoutés avec une valeur NULL.
Si la table/vue doit subir un tri (configuré dans l’action de lancement), ce tri est effectué sur le bloc de donnée résultat.
Transposition de chaque bloc de données si nécessaire
Chaque bloc de donnée précédemment construit subit une transposition si le compartiment associé fait référence à une transposition.
Les croisements de dimensions exprimés par la transposition qui n’existent pas dans le questionnaire seront simplement ignorés lors de l’alimentation.
Dans le cas de dates anonymisées, cela peut être un avantage indéniable : le critère de sélection des dates qui peut être difficile à exprimer parfois est en fait exprimé dans le questionnaire (seules les dates anonymisées correspondantes seront produites).
Dans le cas d’axes standards non anonymisés, il vaut mieux avoir une maîtrise complète des modalités de chacune des dimensions (les modalités devront probablement évoluer en relation avec le questionnaire)
Assemblage des blocs produits entre eux dans le questionnaire
L’ensemble constitué des blocs de données précédemment construits pour chaque compartiment et pour une entité-correspondant (une ligne du noyau) est maintenant injecté dans le questionnaire Calame.
Pour chaque compartiment démultipliant des cellules/onglets lors de la personnalisation (multi-onglet et motif), un bloc de donnée (bloc de référence) va déterminer l’ensemble des modalités de référence. Les autres blocs seront assemblés avec les blocs de référence identifiés.
C’est la table/vue associé au compartiment de plus haut niveau qui déterminera les items de référence pour la démultiplication lors de la personnalisation.
Par exemple, si une table est associée à la racine du multi-onglet, c’est elle qui va en déterminer les items de référence.
Ceci signifie que même si la table d’un motif ou d’une transposition dans un multi-onglet contient plus de modalités que les modalités de la table associée à la racine du multi-onglet, les modalités supplémentaires seront ignorées.
Si deux compartiments sont en concurrence (parce qu’au même niveau) pour servir de référence au multi-onglet ou au motif, l’ordre alphabétique des noms des compartiments déterminera la référence.
Une fois les tables de référence choisies pour les données des multi-onglets et des motifs, ceux-ci sont démultipliés suivant les données de ces tables de référence :
Les multi-onglets sont démultipliés suivant l’axe de multi-onglet présent dans la table de référence.
Les motifs sont démultipliés suivant autant de lignes que présentes dans la table de référence.
Les blocs de données venant des autres compartiments sont alors ajoutés pour les items-clés du bloc de référence.
Dans le cas du bloc de référence du multi-onglet et d’un bloc associé à un sous-compartiment du multi-onglet, l’assemblage est effectué en utilisant l’axe de multi-onglet
Dans le cas du bloc de référence d’un motif et d’un bloc associé à une transposition dans ce motif, tous les champs communs aux deux blocs de données sont utilisés pour faire une jointure externe gauche (les items-clés sont les items du bloc de référence se trouvant dans tous les axes communs aux deux blocs)
Si deux transpositions se trouvent dans le motif, il est nécessaire qu’existe un composant dans le motif qui ne soit pas transposé pour servir de référence commune aux deux transpositions.
Ce composant peut être alimenté totalement par l’une des deux transpositions (la première par ordre alphabétique si aucun bloc n’est associé au motif).
Si un axe existe dans la table associée au compartiment parent et dans la table associée au compartiment fils, seule la valeur de la table associée au compartiment parent est prise en compte.
Un bloc associé à un multi-onglet doit contenir l’axe de multi-onglet.
Un champ vide (NULL) dans le bloc de donnée sera interprété comme une absence de personnalisation : la donnée déposée dans le questionnaire pour ce champ/composant sera la donnée définie à la conception.
Il est conseillé de ne pas mettre de valeur par défaut pour les composants à la conception du questionnaire. L’exception étant le contrôle non personnalisable contenant une formule, ce contrôle étant construit avec la fonction gtcontrole.