Skip to Content

Changes for page 10 Constraints

Last modified by Artur on 2025/09/10 11:19
From version 1.7
edited by Helena
on 2025/06/16 12:15
Change comment: There is no comment for this version
To version 1.2
edited by Helena
on 2025/06/16 12:10
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -57,7 +57,7 @@
57 57  |(% style="width:119px" %)**DF_POP**|(% style="width:55px" %)A|(% style="width:103px" %)FR|(% style="width:79px" %)~~|(% style="width:92px" %)~~|(% style="width:93px" %)50|(% style="width:111px" %)2022|(% style="width:101px" %)6
58 58  |(% style="width:119px" %)**DF_POP_SA**|(% style="width:55px" %)A|(% style="width:103px" %)UK|(% style="width:79px" %)M|(% style="width:92px" %)1|(% style="width:93px" %)1.2|(% style="width:111px" %)2022|(% style="width:101px" %)6
59 59  
60 -== 10.4 Reporting Constraints ==
60 +== 10.3 Reporting Constraints ==
61 61  
62 62  A Reporting Constraint is a Maintainable Artefact which restricts the values that can be reported in a dataset or metadata set based on one or more inclusion or exclusion rules. 
63 63  
... ... @@ -66,7 +66,7 @@
66 66  * Data Constraint
67 67  * Metadata Constraint
68 68  
69 -=== 10.4.1 Data Constraint ===
69 +== 10.4 Data Constraint ==
70 70  
71 71  A Data Constraint is used to add additional restrictions to the allowable values reported in a dataset.  Data Constraints can be applied to the follow structures which are collectively known as Constrainable structures:
72 72  
... ... @@ -77,7 +77,7 @@
77 77  
78 78  **Note** regardless of the Constrainable structure, the restricted values relate to  the allowable content for the Component of the DSD to which the constrained object relates. 
79 79  
80 -=== 10.4.2 Metadata Constraint ===
80 +=== 10.4.1 Metadata Constraint ===
81 81  
82 82  A Metadata Constraint is used to add additional restrictions to the allowable values reported in a metadataset.  Metadata Constraints can be applied to the follow structures which are collectively known as Constrainable structures:
83 83  
... ... @@ -88,7 +88,7 @@
88 88  
89 89  **Note** regardless of the Constrainable structure,  the restricted values relate to  the allowable content for the Component of the MSD to which the constrained object relates. 
90 90  
91 -=== 10.4.3 Scope of a Constraint ===
91 +=== 10.4.2 Scope of a Constraint ===
92 92  
93 93  A Constraint is used specify the content of a data or metadata source in terms of the component values or the keys.
94 94  
... ... @@ -124,11 +124,11 @@
124 124  
125 125  In view of the flexibility of constraints attachment, clear rules on their usage are required. These are elaborated below.
126 126  
127 -=== 10.4.4 Multiple Constraints ===
127 +=== 10.4.3 Multiple Constraints ===
128 128  
129 129  There can be many Constraints for any Constrainable Artefact (e.g., DSD), subject to the following restrictions:
130 130  
131 -==== 10.4.4.1 Cube Region ====
131 +**10.4.4.1 Cube Region**
132 132  
133 133  A Constraint can contain multiple Member Selections (e.g., Dimensions).
134 134  
... ... @@ -158,19 +158,17 @@
158 158  
159 159  Data Constraint 1.0.0
160 160  
161 -(% style="width:573.294px" %)
162 -|(% style="width:108px" %)Component|(% style="width:127px" %)Valid Value|(% style="width:150px" %)Valid from|(% style="width:185px" %)Valid to
163 -|(% rowspan="3" style="width:108px" %)COUNTRY|(% style="width:127px" %)UK|(% style="width:150px" %) |(% style="width:185px" %)
164 -|(% style="width:127px" %)FR|(% style="width:150px" %) |(% style="width:185px" %)
165 -|(% style="width:127px" %)DE|(% style="width:150px" %) |(% style="width:185px" %)
161 +|Component|Valid Value|Valid from|Valid to
162 +|(% rowspan="3" %)COUNTRY|UK| |
163 +|FR| |
164 +|DE| |
166 166  
167 167  Data Constraint 1.1.0
168 168  
169 -(% style="width:576.294px" %)
170 -|(% style="width:110px" %)Component|(% style="width:129px" %)Valid Value|(% style="width:145px" %)Valid from|(% style="width:189px" %)Valid to
171 -|(% rowspan="3" style="width:110px" %)COUNTRY|(% style="width:129px" %)UK|(% style="width:145px" %) |(% style="width:189px" %)
172 -|(% style="width:129px" %)FR|(% style="width:145px" %) |(% style="width:189px" %)2012
173 -|(% style="width:129px" %)DE|(% style="width:145px" %) |(% style="width:189px" %)
168 +|Component|Valid Value|Valid from|Valid to
169 +|(% rowspan="3" %)COUNTRY|UK| |
170 +|FR| |2012
171 +|DE| |
174 174  
175 175  When both versions of the Data Constraint are in a system, an observation value reported against COUNTRY FR for time period 2013 would be deemed invalid as the 1.1.0 rule would be applied.
176 176  
... ... @@ -180,9 +180,8 @@
180 180  
181 181  There are three levels of constraint attachment for which these inheritance rules apply:
182 182  
183 -* DSD/MSD – top level
184 -** Dataflow/Metadataflow – second level
185 -*** Provision Agreement – third level
181 +* DSD/MSD – top level o Dataflow/Metadataflow – second level
182 +** Provision Agreement – third level
186 186  
187 187  It is not necessary for a Constraint to be attached to a higher level artefact. e.g., it is valid to have a Constraint for a Provision Agreement where there are no constraints attached the relevant Dataflow or DSD.
188 188  
... ... @@ -216,14 +216,14 @@
216 216  
217 217  The following logic explains how the inheritance mechanism works. Note that this is conceptual logic and actual systems may differ in the way this is implemented.
218 218  
219 -1. Determine all possible keys that are valid at the higher level.
220 -1. These keys are deemed to be inherited by the lower-level constrained object, subject to the Constraints specified at the lower level.
221 -1. Determine all possible keys that are possible using the Constraints specified at the lower level.
222 -1. At the lower level inherit all keys that match with the higher-level Constraint.
223 -1. If there are keys in the lower-level Constraint that are not inherited then the key is invalid (i.e., it is less restrictive).
216 +1.
217 +11. Determine all possible keys that are valid at the higher level.
218 +11. These keys are deemed to be inherited by the lower-level constrained object, subject to the Constraints specified at the lower level.
219 +11. Determine all possible keys that are possible using the Constraints specified at the lower level.
220 +11. At the lower level inherit all keys that match with the higher-level Constraint.
221 +11. If there are keys in the lower-level Constraint that are not inherited then the key is invalid (i.e., it is less restrictive).
222 +111. Constraints Examples
224 224  
225 -=== 10.4.7 Constraints Examples ===
226 -
227 227  ==== 10.4.7.1 Data Constraint and Cascading ====
228 228  
229 229  The following scenario is used.
... ... @@ -237,11 +237,9 @@
237 237  
238 238  In the DSD, common code lists are used and the requirement is to restrict these at various levels to specify the actual code that are valid for the object to which the Constraint is attached.
239 239  
240 -[[image:1750065279010-260.png]]
241 241  
242 242  **Figure 20: Example Scenario for Constraints **Constraints are declared as follows:
243 243  
244 -[[image:1750065319060-899.png]]
245 245  
246 246  **Figure 21: Example Constraints**
247 247  
... ... @@ -282,13 +282,10 @@
282 282  
283 283  DSD Constraint
284 284  
285 -
286 286  Dataflow Constraints
287 287  
288 -
289 289  Provision Agreement Constraint
290 290  
291 -
292 292  **10.4.7.2 Combination of Constraints**
293 293  
294 294  The possible combination of constraining terms are explained in this section, following a few examples.
1750065279010-260.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -60.3 KB
Content
1750065319060-899.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -91.0 KB
Content