On peut vous aider ?
Cherchez des réponses ou parcourez les rubriques de notre documentation
Motif et transposition
{:fr}
Quelques rappels sur les compartiments
Le motif permet de démultiplier verticalement une plage de cellules contiguës.
La transposition permet d’associer des cellules à des croisements de dimensions.
Un même composant ne peut appartenir qu’à un seul motif et/ou à un seul groupe de multi-onglet.
Un même composant peut appartenir à plusieurs transpositions.
Les composants d’un motif ne peuvent appartenir qu’à un groupe de multi-onglet.
Les composants d’une transposition peuvent appartenir à plusieurs motifs différents et à plusieurs groupes de multi-onglets différents.
Concrètement, la transposition, à partir des données de la base client, transforme ces données en basculant certains champs de lignes en colonnes : il y a réduction du nombre de lignes initial et la clé des données avant transposition est souvent différente de la clé après transposition.
La clef après transposition correspond à l’ensemble des champs de la table initiale qui ne sont pas concernés par la transposition (les champs du noyau sont ajoutés à la table conformément aux règles d’assemblage des données).
Assemblage des données lors du lancement de campagne
Exemple simple
Dans cet exemple, la clé du motif est le site.
Pour chaque ligne de motif (donc chacune des données associées à un site), la transposition répartit en colonne les CA de l’année courante et de l’année précédente.
Le site est déjà l’élément démultipliant (i.e. la « clé ») du motif.
Il ne doit pas y être fait référence dans la transposition. C’est l’assemblage des données au moment du lancement de la campagne qui va réaliser l’association des informations liées au site seul (appartenant au motif seul) et des informations liées au site et à la « clé » de la transposition (ici l’axe date implicite pour distinguer l’année courante de l’année précédente).
Motif et transposition
Bien que le motif opère déjà une démultiplication de cellules verticalement, il peut être utile d’associer un motif à une transposition, notamment dans les cas suivants :
– anonymisation de dates : l’anonymisation de dates réalisée dans le cadre de la transposition permet d’obtenir simplement des dates relatives
– présentation de modalités d’une même dimension dans des colonnes du motif (l’anonymisation de dates entre dans ce cas).
– présentation de listes homogènes mais ne pouvant être fondues dans le même motif (à cause de présentations légèrement différentes, de sommations intermédiaires ou de comportements d’ajout/suppressions différents)
Dans ce dernier cas, l’unicité des en-têtes de composants au sein du questionnaire interdit l’utilisation du même en-tête pour deux motifs. La transposition permet alors de particulariser les en-têtes en leur adjoignant une catégorie correspondant à chaque motif (tous les en-têtes sont préfixés par la catégorie du motif par exemple ; Motif1__Produit, Motif1__Prix, Motif2__Produit, Motif2__Prix, …)
L’utilisation d’une transposition au sein d’un multi-onglet ne pose pas de problèmes particuliers, car la clé du multi-onglet est parfaitement identifiée (axe de multi-onglet) et toutes les tables associées à des compartiments contenus dans le multi-onglet doivent donc contenir cette clef.
La clé des données est déterminée par la table de référence pour le motif (cf Assemblage des données). De plus, la transposition effectue une transformation des données et la clef de la table associée à la transposition avant et après transposition est rarement la même : la clef des données est en quelque sorte « consommée » totalement ou partiellement par la transposition (suivant les axes-clefs de la table initiale qui ne sont pas transposés)
Les données transposées dans un motif peuvent ainsi produire trop ou trop peu de lignes
Démarche pour vérifier les données d’une transposition dans un motif
Déterminer le ou les les composants qui serviront de clef pour les données du motif dans le questionnaire.
Déclarer la clé dans le motif pour détecter les problèmes tout de suite lors du lancement et pas seulement à l’intégration.
Si ces composants-clefs n’existent pas, il est nécessaire d’en créer (si des clés naturelles ne peuvent être identifiées, un contrôle reprenant une clé non naturelle pourra être utilisée mais il faudra en mesurer toutes les conséquences, notamment si des lignes peuvent être ajoutées par le correspondant dans le motif)
Vérifier si tout ou partie de ces composants-clefs du motif appartiennent à une transposition.
- Si aucun composant-clef du motif n’appartient à une transposition, tous les champs correspondants (champs clés du motif) devront être présents dans la table associée au sous-compartiment du motif pour la transposition.
Il sera alors préférable de supprimer de la table/vue associée à la transposition tous les champs n’appartenant ni au motif ni à la transposition (ni au multi-onglet s’il en existe un).
Le non respect de ces consignes peut induire (en fonction des données) trop de lignes différentes dans les données approvisionnant le motif ou un approvisionnement en quinconce (ou aucun approvisionnement). Cf exemple ci-dessous.
La vérification des fichiers temporaires générés par GTServer permettra généralement de repérer les champs superflus.
- Si quelques composants-clefs du motif appartiennent à la transposition (mais pas tous les composants-clefs), alors il existe très certainement un problème de conception dans les compartiments ou les clefs ou les données : suivant les règles d’assemblage, les clefs du motif seront déterminés par la table associée au compartiment de plus haut niveau, soit la table associée au motif et elle seule, une clé même partielle ne pourra donc se trouver dans une table du sous-compartiment.
GTAnswerpourra ne pas accepter que l’on choisisse d’associer le motif à une vue/table lors de l’édition d’une action.
- Si tous les composants-clefs du motif appartiennent à la transposition, alors ces composants-clefs ne peuvent correspondre chacun qu’à une même combinatoire d’items d’axes de transposition (hors axes valeur). Il sera nécessaire de produire pour chacun de ces composants-clefs appartenant à la transposition un duplicat de l’axe valeur correspondant dans la table initiale (cette opération est simplement réalisée avec une vue dupliquant les champs-clefs absorbés par la transposition).
De cette façon, la clef avant et après transposition sera préservée.
Le non respect de ces préconisations induit généralement trop peu de lignes pour alimenter le motif (cf exemple ci-dessous). Une erreur 22100 sera générée à l’exécution.
Si aucune ligne n’est produite dans le motif (ou une seule ligne vierge, ou des lignes partiellement vides), s’assurer que les données en entrée de la transposition permettent effectivement de produire les en-têtes pour les composants transposés dans le motif (écriture exacte des items, sans espaces terminaux, …)
- Si deux transpositions existent dans le motif et sont personnalisées, les composants-clefs doivent appartenir en propre au motif et ils doivent être communs à la table associée au motif seul et à chacune des tables associées au motif et à une transposition dans le motif.
Exemples d’utilisations incorrectes de la transposition
Exemple 1 : trop de lignes dans le motif avec une transposition
| Produit | Date | Année | Prix |
|---|---|---|---|
| Chou | 01/12/2010 | 2010 | 1 |
| Chou | 01/12/2011 | 2011 | 2 |
Si la transposition est définie Date ;{Prix}
| Produit | Annee | M0__Prix | Mm1__Prix |
|---|---|---|---|
| Chou | 2010 | 1 | |
| Chou | 2011 | 2 |
Alors que l’on aurait souhaité obtenir une seule ligne avec chacun des deux prix dans deux champs.
Ici, l’année est une information liée à la date, mais l’année n’est pas transposée alors que la date l’est.
Cette situation se produit communément lorsqu’une clef non naturelle (Séquence ou compteur) est produite dans les données de la table pour la transposition
Exemple 2 : trop peu de lignes dans le motif avec une transposition
| Motif | Produit | Date | Prix |
|---|---|---|---|
| M1 | Chou | 01/12/2010 | 1 |
| M1 | Chou | 01/01/2011 | 2 |
Si la transposition est définie Motif ;{Produit ;Date ;Prix} Les données transposées se présentent ainsi
| M1__Produit | M1__Date | M1__Prix |
|---|---|---|
| Chou | 01/01/2011 | 2 |
Ici, on aurait souhaité obtenir deux lignes (une pour chaque date).
GTServer génèrera une erreur dans ce cas en mentionnant le fait que l’on tente d’écrire une valeur différente (« 2 ») de la valeur déjà inscrite (« 1 ») pour la même date (Erreur 22100 lors du lancement de campagne et de l’exécution de la transposition).
Une solution est de produire les axes-clefs (qui sont transposés dans ce cas) en doublon dans la table initiale (de manière à ce que ces axes ne soient pas transposés et donc que la clef ne soit pas consommée par la transposition).{:}{:en}
A few reminders about compartments
The pattern makes it possible to multiply a range of contiguous cells vertically.
Transposition allows cells to be associated with dimensional crossings.
A single component can only belong to one pattern and/or one multi-tab group.
The same component can belong to several transpositions.
The components of a pattern can only belong to one multi-tab group.
The components of a transposition can belong to several different patterns and several different multi-tab groups.
In concrete terms, the transposition, starting from the client database data, transforms this data by switching certain fields from rows to columns: the initial number of rows is reduced and the key of the data before transposition is often different from the key after transposition.
The key after transposition corresponds to the set of fields in the initial table that are not affected by the transposition (the kernel fields are added to the table according to the data assembly rules).
Data assembly at campaign launch
Simple example
In this example, the pattern key is the site.
For each row in the pattern (i.e. each of the data associated with a site), the transposition breaks down the CA of the current year and the previous year into columns.
The site is already the multiplier (i.e. the « key ») of the pattern.
It should not be referred to in the transposition. It is the assembly of the data at the time of the launch of the campaign that will carry out the association of the information linked to the site alone (belonging to the pattern alone) and the information linked to the site and to the « key » of the transposition (here the implicit date axis to distinguish the current year from the previous year).
Pattern and transposition
Although the pattern already multiplies cells vertically, it may be useful to associate a pattern with a transposition, particularly in the following cases
– anonymisation of dates: the anonymisation of dates carried out within the framework of the transposition makes it possible to simply obtain relative dates
– presentation of modalities of the same dimension in columns of the pattern (date anonymisation is included in this case).
– presentation of homogeneous lists that cannot be merged into the same pattern (because of slightly different presentations, intermediate summations or different addition/deletion behaviors)
In this last case, the uniqueness of component headers within the questionnaire prohibits the use of the same header for two patterns. The transposition then makes it possible to particularize the headers by adding a category corresponding to each pattern (all headers are prefixed by the category of the pattern, for example; Pattern1__Product, Pattern1__Price, Pattern2__Product, Pattern2__Price, …)
The use of a transposition within a multi-tab does not pose any particular problems, as the key of the multi-tab is perfectly identified (multi-tab axis) and all tables associated with compartments contained in the multi-tab must therefore contain this key.
The data key is determined by the reference table for the pattern (see Data assembly). Moreover, the transposition performs a transformation of the data and the key of the table associated with the transposition before and after transposition is rarely the same: the key of the data is in a way « consumed » totally or partially by the transposition (depending on the key-axis of the initial table which are not transposed)
The transposed data in a pattern may thus produce too many or too few rows
Procedure for checking the data of a transposition in a pattern
Determine the component(s) that will serve as the key for the pattern data in the questionnaire.
Declare the key in the pattern to detect problems at the start and not only during integration.
If these key-components do not exist, it is necessary to create them (if natural keys cannot be identified, a control using a non-natural key can be used, but all the consequences must be assessed, particularly if rows can be added in the pattern by the correspondent).
Check whether all or part of these key components of the pattern belong to a transposition.
- Suppose none of the pattern’s key components belong to a transposition. In that case, all the corresponding fields (pattern key fields) must be present in the table associated with the pattern’s sub-compartment for the transposition.
Therefore, it is preferable to delete all fields that do not belong to the pattern or the transposition (or to the multi-tab if one exists) from the table/view associated with the transposition.
Failure to comply with these instructions may result (depending on the data) in too many different rows in the data supplying the pattern or in staggered supply (or no supply at all). See the example below.
Checking the temporary files generated by GTServer will generally identify superfluous fields.
- If some of the pattern’s key components belong to the transposition (but not all the key components), then there is most certainly a design problem in the compartments or the keys or the data: according to the assembly rules, the pattern’s keys will be determined by the table associated with the highest-level compartment, i.e., the table associated with the pattern and only that table. GTAnswer may not accept that the pattern be associated with a view/table when editing an action.
- If all the key components of the pattern belong to the transposition, then these key components can only correspond to the same combination of transposition axis items (excluding value axes). It will be necessary to produce a duplicate of the corresponding value axis in the initial table for each of these key-components belonging to the transposition (this operation is simply performed by duplicating the key fields included in the transposition).
In this way, the key before and after transposition will be preserved.
Failure to comply with these recommendations generally results in too few rows to fuel the pattern (see example below). An error 22100 will be generated at runtime.
If no rows are produced in the pattern (or a single blank row, or partially empty rows), make sure that the input data for the transposition can actually be used to produce the headers for the components transposed in the pattern (exact writing of the items, without terminal spaces, etc.)
- If two transpositions exist in the pattern and are customized, the key components must belong to the pattern and they must be common to the table associated with the pattern alone and to each of the tables associated with the pattern and a transposition in the pattern.
Examples of incorrect uses of transposition
Example 1: Too many rows in the pattern with a transposition
Initial data for the transposition table
Product Date Year Price
Cabbage 01/12/2010 2010 1
Cabbage 01/12/2011 2011 2
If transposition is defined Date;{Price}
Transposed data
Product Year M0__Price Mm1__Price
Cabbage 2010 1
Cabbage 2011 2
Whereas one would have liked to have a single row with each of the two prices in two fields.
Here, the year is information linked to the date, but the year is not transposed while the date is.
This situation commonly occurs when an unnatural key (Sequence or Meter) is produced in the table data for transposition
Example 2: Too few rows in the pattern with a transposition
Initial data for the table of the transposition
Pattern Product Date Price
M1 Cabbage 01/12/2010 1
M1 Cabbage 01/01/2011 2
If the transposition is defined Pattern;{Product; Date ; Price} The transposed data will look like this
Transposed data
M1__Product M1__Date M1__Price
Cabbage 01/01/2011 2
Here, we would have liked to obtain two rows (one for each date).
GTServer will generate an error in this case by mentioning the fact that an attempt was made to write a different value (« 2 ») from the value already entered (« 1 ») for the same date (Error 22100 when launching the campaign and executing the transposition).
One solution is to produce duplicate key axis (which are transposed in this case) in the initial table (so that these axis are not transposed and therefore the key is not consumed by the transposition).{:}