Changes for page 12 Validation and Transformation Language (VTL)
Last modified by Artur on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -235,16 +235,18 @@ 235 235 * The SDMX Measure is not mapped to VTL as well (it disappears in the VTL Data Structure); 236 236 * An SDMX DataAttribute is mapped in different ways according to its AttributeRelationship: 237 237 ** If, according to the SDMX AttributeRelationship, the values of the DataAttribute do not depend on the values of the MeasureDimension, the SDMX DataAttribute becomes a VTL Attribute having the same name. This happens if the AttributeRelationship is not specified (i.e. the DataAttribute does not depend on any DimensionComponent and therefore is at data set level), or if it refers to a set (or a group) of dimensions which does not include the MeasureDimension; 238 -** Otherwise, if, according to the SDMX AttributeRelationship, the values of the DataAttribute depend on the MeasureDimension, the SDMX DataAttribute is mapped to one VTL Attribute for each possible Code of the SDMX MeasureDimension. By default, the names of the VTL Attributes are obtained by concatenating the name of the SDMX DataAttribute and the names of the correspondent Code of the MeasureDimension separated by underscore. For example, if the SDMX DataAttribute is named DA and the possible Codes of the SDMX MeasureDimension are named C1, C2, …, Cn, then the corresponding VTL Attributes will be named DA_C1, DA_C2, …, DA_Cn (if different names are desired, they can be achieved afterwards by renaming the Attributes through VTL operators). o Like in the Basic mapping, the resulting VTL Attributes are considered as dependent on all the VTL identifiers (i.e. "at data point / observation level"), because VTL does not have the SDMX notion of Attribute Relationship. 238 +** Otherwise, if, according to the SDMX AttributeRelationship, the values of the DataAttribute depend on the MeasureDimension, the SDMX DataAttribute is mapped to one VTL Attribute for each possible Code of the SDMX MeasureDimension. By default, the names of the VTL Attributes are obtained by concatenating the name of the SDMX DataAttribute and the names of the correspondent Code of the MeasureDimension separated by underscore. For example, if the SDMX DataAttribute is named DA and the possible Codes of the SDMX MeasureDimension are named C1, C2, …, Cn, then the corresponding VTL Attributes will be named DA_C1, DA_C2, …, DA_Cn (if different names are desired, they can be achieved afterwards by renaming the Attributes through VTL operators). 239 +** Like in the Basic mapping, the resulting VTL Attributes are considered as dependent on all the VTL identifiers (i.e. "at data point / observation level"), because VTL does not have the SDMX notion of Attribute Relationship. 239 239 240 240 The summary mapping table of the "pivot" mapping from SDMX to VTL for the SDMX data structures that contain a MeasureDimension is the following: 241 241 242 -|**SDMX**|**VTL** 243 -|Dimension|(Simple) Identifier 244 -|TimeDimension|(Time) Identifier 245 -|MeasureDimension & one Measure|One Measure for each Code of the SDMX MeasureDimension 246 -|DataAttribute not depending on the MeasureDimension|Attribute 247 -|DataAttribute depending on the MeasureDimension|((( 243 +(% style="width:739.294px" %) 244 +|(% style="width:335px" %)**SDMX**|(% style="width:400px" %)**VTL** 245 +|(% style="width:335px" %)Dimension|(% style="width:400px" %)(Simple) Identifier 246 +|(% style="width:335px" %)TimeDimension|(% style="width:400px" %)(Time) Identifier 247 +|(% style="width:335px" %)MeasureDimension & one Measure|(% style="width:400px" %)One Measure for each Code of the SDMX MeasureDimension 248 +|(% style="width:335px" %)DataAttribute not depending on the MeasureDimension|(% style="width:400px" %)Attribute 249 +|(% style="width:335px" %)DataAttribute depending on the MeasureDimension|(% style="width:400px" %)((( 248 248 One Attribute for each Code of the 249 249 SDMX MeasureDimension 250 250 ))) ... ... @@ -254,19 +254,14 @@ 254 254 At observation / data point level, calling Cj (j=1, … n) the j^^th^^ Code of the MeasureDimension: 255 255 256 256 * The set of SDMX observations having the same values for all the Dimensions except than the MeasureDimension become one multi-measure VTL Data Point, having one Measure for each Code Cj of the SDMX MeasureDimension; 257 -* The values of the SDMX simple Dimensions, TimeDimension and DataAttributes not depending on the MeasureDimension (these components by definition have always the same values for all the observations of the set above) become the values of the corresponding VTL (simple) 258 - 259 -Identifiers, (time) Identifier and Attributes. 260 - 259 +* The values of the SDMX simple Dimensions, TimeDimension and DataAttributes not depending on the MeasureDimension (these components by definition have always the same values for all the observations of the set above) become the values of the corresponding VTL (simple) Identifiers, (time) Identifier and Attributes. 261 261 * The value of the Measure of the SDMX observation belonging to the set above and having MeasureDimension=Cj becomes the value of the VTL Measure Cj 262 262 * For the SDMX DataAttributes depending on the MeasureDimension, the value of the DataAttribute DA of the SDMX observation belonging to the set above and having MeasureDimension=Cj becomes the value of the VTL Attribute DA_Cj 263 263 264 264 ==== 12.3.3.3 From SDMX DataAttributes to VTL Measures ==== 265 265 266 -* In some cases, it may happen that the DataAttributes of the SDMX DataStructure need to be managed as Measures in VTL. Therefore, a variant of both the methods above consists in transforming all the SDMX DataAttributes in VTL Measures. When DataAttributes are converted to Measures, the two methods above are called Basic_A2M and Pivot_A2M (the suffix "A2M" stands for Attributes to Measures). Obviously, the resulting VTL data structure is, in general, multi-measure and does not contain 265 +* In some cases, it may happen that the DataAttributes of the SDMX DataStructure need to be managed as Measures in VTL. Therefore, a variant of both the methods above consists in transforming all the SDMX DataAttributes in VTL Measures. When DataAttributes are converted to Measures, the two methods above are called Basic_A2M and Pivot_A2M (the suffix "A2M" stands for Attributes to Measures). Obviously, the resulting VTL data structure is, in general, multi-measure and does not contain Attributes. 267 267 268 -Attributes. 269 - 270 270 The Basic_A2M and Pivot_A2M behaves respectively like the Basic and Pivot methods, except that the final VTL components, which according to the Basic and Pivot methods would have had the role of Attribute, assume instead the role of Measure. 271 271 272 272 Proper VTL features allow changing the role of specific attributes even after the SDMX to VTL mapping: they can be useful when only some of the DataAttributes need to be managed as VTL Measures. ... ... @@ -283,11 +283,12 @@ 283 283 284 284 Mapping table: 285 285 286 -|**VTL**|**SDMX** 287 -|(Simple) Identifier|Dimension 288 -|(Time) Identifier|TimeDimension 289 -|Measure|Measure 290 -|Attribute|DataAttribute 283 +(% style="width:470.294px" %) 284 +|(% style="width:262px" %)**VTL**|(% style="width:205px" %)**SDMX** 285 +|(% style="width:262px" %)(Simple) Identifier|(% style="width:205px" %)Dimension 286 +|(% style="width:262px" %)(Time) Identifier|(% style="width:205px" %)TimeDimension 287 +|(% style="width:262px" %)Measure|(% style="width:205px" %)Measure 288 +|(% style="width:262px" %)Attribute|(% style="width:205px" %)DataAttribute 291 291 292 292 If the distinction between simple identifier and time identifier is not maintained in the VTL environment, the classification between Dimension and TimeDimension exists only in SDMX, as declared in the relevant DataStructureDefinition. 293 293 ... ... @@ -315,11 +315,12 @@ 315 315 316 316 The summary mapping table of the **unpivot** mapping method is the following: 317 317 318 -|**VTL**|**SDMX** 319 -|(Simple) Identifier|Dimension 320 -|(Time) Identifier|TimeDimension 321 -|All Measure Components|MeasureDimension (having one Code for each VTL measure component) & one Measure 322 -|Attribute|DataAttribute depending on all SDMX Dimensions including the TimeDimension and except the MeasureDimension 316 +(% style="width:638.294px" %) 317 +|(% style="width:200px" %)**VTL**|(% style="width:435px" %)**SDMX** 318 +|(% style="width:200px" %)(Simple) Identifier|(% style="width:435px" %)Dimension 319 +|(% style="width:200px" %)(Time) Identifier|(% style="width:435px" %)TimeDimension 320 +|(% style="width:200px" %)All Measure Components|(% style="width:435px" %)MeasureDimension (having one Code for each VTL measure component) & one Measure 321 +|(% style="width:200px" %)Attribute|(% style="width:435px" %)DataAttribute depending on all SDMX Dimensions including the TimeDimension and except the MeasureDimension 323 323 324 324 At observation / data point level: 325 325 ... ... @@ -341,12 +341,13 @@ 341 341 342 342 The mapping table is the following: 343 343 344 -|VTL|SDMX 345 -|(Simple) Identifier|Dimension 346 -|(Time) Identifier|TimeDimension 347 -|Some Measures|Measure 348 -|Other Measures|DataAttribute 349 -|Attribute|DataAttribute 343 +(% style="width:467.294px" %) 344 +|(% style="width:214px" %)VTL|(% style="width:250px" %)SDMX 345 +|(% style="width:214px" %)(Simple) Identifier|(% style="width:250px" %)Dimension 346 +|(% style="width:214px" %)(Time) Identifier|(% style="width:250px" %)TimeDimension 347 +|(% style="width:214px" %)Some Measures|(% style="width:250px" %)Measure 348 +|(% style="width:214px" %)Other Measures|(% style="width:250px" %)DataAttribute 349 +|(% style="width:214px" %)Attribute|(% style="width:250px" %)DataAttribute 350 350 351 351 Even in this case, the resulting SDMX definitions must be compliant with the SDMX consistency rules. For example, the SDMX DSD must have the attributeRelationship for the DataAttributes, which does not exist in VTL. 352 352 ... ... @@ -384,11 +384,11 @@ 384 384 385 385 Therefore, the generic name of this kind of VTL datasets would be: 386 386 387 -'DF(1.0.0)/INDICATORvalue.COUNTRYvalue' 387 +> 'DF(1.0.0)/INDICATORvalue.COUNTRYvalue' 388 388 389 389 Where DF(1.0.0) is the Dataflow and //INDICATORvalue// and //COUNTRYvalue //are placeholders for one value of the INDICATOR and COUNTRY dimensions. Instead the specific name of one of these VTL datasets would be: 390 390 391 -‘DF(1.0.0)/POPULATION.USA’ 391 +> ‘DF(1.0.0)/POPULATION.USA’ 392 392 393 393 In particular, this is the VTL dataset that contains all the observations of the Dataflow DF(1.0.0) for which //INDICATOR// = POPULATION and //COUNTRY// = USA. 394 394 ... ... @@ -402,13 +402,11 @@ 402 402 403 403 SDMX Dataflow having INDICATOR=//INDICATORvalue //and COUNTRY=// COUNTRYvalue//. For example, the VTL dataset ‘DF1(1.0.0)/POPULATION.USA’ would contain all the observations of DF1(1.0.0) having INDICATOR = POPULATION and COUNTRY = USA. 404 404 405 -In order to obtain the data structure of these VTL Data Sets from the SDMX one, it is assumed that the SDMX DimensionComponents on which the mapping is based are dropped, i.e. not maintained in the VTL data structure; this is possible because their values are fixed for each one of the invoked VTL Data Sets{{footnote}}If these DimensionComponents would not be dropped, the various VTL Data Sets resulting from this kind of mapping would have non-matching values for the Identifiers corresponding to the mapping Dimensions (e.g. POPULATION and COUNTRY). As a consequence, taking into account that the typical binary VTL operations at dataset level (+, -, *, / and so on) are executed on the observations having matching values for the identifiers, it would not be possible to compose the resulting VTL datasets one another (e.g. it would not be possible to calculate the population ratio between USA and CANADA).{{/footnote}}. After that, the mapping method from SDMX to VTL specified for the Dataflow DF1(1.0.0) is applied (i.e. 405 +In order to obtain the data structure of these VTL Data Sets from the SDMX one, it is assumed that the SDMX DimensionComponents on which the mapping is based are dropped, i.e. not maintained in the VTL data structure; this is possible because their values are fixed for each one of the invoked VTL Data Sets{{footnote}}If these DimensionComponents would not be dropped, the various VTL Data Sets resulting from this kind of mapping would have non-matching values for the Identifiers corresponding to the mapping Dimensions (e.g. POPULATION and COUNTRY). As a consequence, taking into account that the typical binary VTL operations at dataset level (+, -, *, / and so on) are executed on the observations having matching values for the identifiers, it would not be possible to compose the resulting VTL datasets one another (e.g. it would not be possible to calculate the population ratio between USA and CANADA).{{/footnote}}. After that, the mapping method from SDMX to VTL specified for the Dataflow DF1(1.0.0) is applied (i.e. basic, pivot …). 406 406 407 -basic, pivot …). 408 - 409 409 In the example above, for all the datasets of the kind 410 410 411 -‘DF1(1.0.0)///INDICATORvalue//.//COUNTRYvalue//’, the dimensions INDICATOR and COUNTRY would be dropped so that the data structure of all the resulting VTL Data Sets would have the identifier TIME_PERIOD only. 409 +> ‘DF1(1.0.0)///INDICATORvalue//.//COUNTRYvalue//’, the dimensions INDICATOR and COUNTRY would be dropped so that the data structure of all the resulting VTL Data Sets would have the identifier TIME_PERIOD only. 412 412 413 413 It should be noted that the desired VTL Data Sets (i.e. of the kind ‘DF1(1.0.0)/// INDICATORvalue//.//COUNTRYvalue//’) can be obtained also by applying the VTL operator “**sub**” (subspace) to the Dataflow DF1(1.0.0), like in the following VTL expression: 414 414