Skip to Content

Changes for page 1 Introduction

Last modified by Helena on 2025/09/10 11:19
From version 5.2
edited by Artur
on 2025/05/20 14:28
Change comment: Update document after refactoring.
To version 2.2
edited by Helena
on 2025/05/19 23:53
Change comment: Changed document title to [1 Introduction].

Summary

Details

Page properties
Parent
... ... @@ -1,1 +1,0 @@
1 -Methodology.SDMX 2\.1 Standards\. Section 2\. Information model\: UML conceptual design.WebHome
Author
... ... @@ -1,1 +1,1 @@
1 -xwiki:XWiki.arturkryazhev
1 +xwiki:XWiki.helena
Content
... ... @@ -1,6 +1,4 @@
1 -{{box title="**Contents**"}}
2 -{{toc/}}
3 -{{/box}}
1 += {{id name="_Toc370955"/}}1 Introduction =
4 4  
5 5  This document is not normative, but provides a detailed view of the information model on which the normative SDMX specifications are based. Those new to the UML notation or to the concept of Data Structure Definitions may wish to read the appendixes in this document as an introductory exercise.
6 6  
... ... @@ -24,40 +24,37 @@
24 24  
25 25  UML diagramming allows a class to be shown with or without the compartments for one or both of attributes and operations (sometimes called methods). In this document the operations compartment is not shown as there are no operations.
26 26  
27 -[[image:1747688233306-119.png]]
28 -
29 29  **Figure 1 Class with operations suppressed**
30 30  
31 31  In some diagrams for some classes the attribute compartment is suppressed even though there may be some attributes. This is deliberate and is done to aid clarity of the diagram. The method used is:
32 32  
33 33  * The attributes will always be present on the class diagram where the class is defined and its attributes and associations are defined.
34 -* On other diagrams, such as inheritance diagrams, the attributes may be suppressed from the class for clarity.
30 +* On other diagrams, such as inheritance diagrams, the attributes may be suppressed from the class for clarity.//  //
35 35  
36 -[[image:1747688246821-738.png]]
37 -
38 38  **Figure 2 Class with attributes also suppressed**
39 39  
40 40  Note that, in any case, attributes inherited from a super class are not shown in the sub class.
41 41  
42 -The following table structure is used in the definition of the classes, attributes, and associations.
36 +The following table structure is used in the definition of the classes, attributes, and 428 associations.
43 43  
38 +:
39 +
44 44  (((
45 -(% style="width:681.294px" %)
46 -|(% style="width:109px" %)**Class**|(% style="width:248px" %)**Feature**|(% style="width:320px" %)**Description**
47 -|(% style="width:109px" %)ClassName|(% style="width:248px" %) |(% style="width:320px" %)
48 -|(% style="width:109px" %) |(% style="width:248px" %)attributeName|(% style="width:320px" %).
49 -|(% style="width:109px" %) |(% style="width:248px" %)associationName|(% style="width:320px" %)
50 -|(% style="width:109px" %) |(% style="width:248px" %)+roleName|(% style="width:320px" %)
41 +|**Class**|**Feature**|**Description**
42 +|ClassName||
43 +||attributeName|.
44 +||associationName|
45 +||+roleName|
51 51  )))
52 52  
53 53  The content in the “Feature” column comprises or explains one of the following structural features of the class:
54 54  
55 -* Whether it is an abstract class. Abstract classes are shown in //italic Courier// font
56 -* The superclass this class inherits from, if any
57 -* The sub classes of this class, if any
58 -* Attribute – the attributeName is shown in Courier font
59 -* Association – the associationName is shown in Courier font. If the association is derived from the association between super classes then the format is /associationName
60 -* Role – the +roleName is shown in Courier font
50 +* Whether it is an abstract class. Abstract classes are shown in //italic Courier// font//  //
51 +* The superclass this class inherits from, if any//  //
52 +* The sub classes of this class, if any//  //
53 +* Attribute – the attributeName is shown in Courier font// //
54 +* Association – the associationName is shown in Courier font. If the association is derived from the association between super classes then the format is /associationName//  //
55 +* Role – the +roleName is shown in Courier font// //
61 61  
62 62  The Description column provides a short definition or explanation of the Class or Feature. UML class names may be used in the description and if so, they are presented in normal font with spaces between words. For example the class ConceptScheme will be written as Concept Scheme.
63 63  
... ... @@ -79,8 +79,8 @@
79 79  
80 80  In version 1.0 the metamodel supported the requirements for:
81 81  
82 -* Data Structure Definition definition including (domain) category scheme, (metadata) concept scheme, and code list
83 -* Data and related metadata reporting and dissemination
77 +* Data Structure Definition definition including (domain) category scheme, (metadata) concept scheme, and code list//  //
78 +* Data and related metadata reporting and dissemination// //
84 84  
85 85  The SDMX-IM comprises a number of packages. These packages act as convenient compartments for the various sub models in the SDMX-IM. The diagram below shows the sub models of the SDMX-IM that were included in the version 1.0 specification.
86 86  
... ... @@ -90,7 +90,7 @@
90 90  
91 91  ===== {{id name="_Toc370961"/}}1.3.3 Version 2.0/2.1 =====
92 92  
93 -The version 2.0/2.1 model extends the functionality of version 1.0. principally in the area of metadata, but also in various ways to define structures to support data analysis by systems with knowledge of cube type structures such as OLAP^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ systems. The following major constructs have been added at version 2.0/2.1
88 +The version 2.0/2.1 model extends the functionality of version 1.0. principally in the area of metadata, but also in various ways to define structures to support data analysis by systems with knowledge of cube type structures such as OLAP^^[[^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]]^^ systems. The following major constructs have been added at version 2.0/2.1
94 94  
95 95  * Metadata structure definition
96 96  * Metadata set
... ... @@ -103,8 +103,6 @@
103 103  
104 104  Furthermore, the term Data Structure Definition replaces the term Key Family: as both of these terms are used in various communities they are synonymous. The term Data Structure Definition is used in the model and this document.
105 105  
106 -[[image:1747688331526-153.png]]
107 -
108 108  **Figure 4 SDMX Information Model Version 2.0/2.1 package structure**
109 109  
110 110  Additional constructs that are specific to a registry based scenario can be found in the Specification of Registry Interfaces. For information these are shown on the diagram below and comprise:
1747688233306-119.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -9.0 KB
Content
1747688246821-738.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -2.3 KB
Content
1747688331526-153.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -35.7 KB
Content
SDMX_2-1_SECTION_2_InformationModel_2020-07_61e70b68.jpg
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -81.5 KB
Content
SDMX_2-1_SECTION_2_InformationModel_2020-07_e9840a5b.jpg
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -32.3 KB
Content