How can we help?

Search for answers or browse our knowledge base

< All Topics
Print

Pattern and Transposition

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).

(Read: 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 Turnover 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 campaign launch 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
Apples 01/12/2010 2010 1
Apples 01/12/2011 2011 2

If transposition is defined Date;{Price}

Transposed data
Product Year A__Price A_1__Price
Apples 2010 1
Apples 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 transposition table
Pattern Product Date Price
M1 Apples 01/12/2010 1
M1 Apples 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
Apples 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).

Was this article helpful?
0 out Of 5 Stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
How can we improve this article?
How Can We Improve This Article?
Previous Multi-tab
Next Multiple transposition and Anonymisation of items
Table of Contents