Difference between revisions of "Content Constraints"
(→Overview) |
|||
| Line 23: | Line 23: | ||
See this article [https://fmrwiki.sdmxcloud.org/All_Structures_-_FMR for more information on authoring and maintaining structures.] | See this article [https://fmrwiki.sdmxcloud.org/All_Structures_-_FMR for more information on authoring and maintaining structures.] | ||
| − | |||
| − | From the Data menu, select the Reporting Constraints page and use the maintenance button to create a | + | From the Data menu, select the Reporting Constraints page and use the maintenance button to create either a Series Constraint or a Cube Region Constraint. [[File :cogs.PNG|40px]]<br> |
| − | = | + | =Wizard - Cube Region Constraint= |
| − | |||
| − | ==Step 2== | + | ==Step 1 - High Level Details== |
| + | |||
| + | The steps in a Constraint Wizard includes step 1 which provides the generic, high level details about the Constraint. See this article [https://fmrwiki.sdmxcloud.org/All_Structures_-_FMR for more information on authoring and maintaining structures.] | ||
| + | |||
| + | ==Step 2 - Attachment== | ||
The second step is used to define what Structures are being constrained and of the constrained structures, which Components will be included in the Constraints. Only Components which reference a Codelist are included in the available list. If the Constrained structure is a Data Provider, the list of Components will be derived from all the Dataflows the Data Provider has a Provision Agreement for. | The second step is used to define what Structures are being constrained and of the constrained structures, which Components will be included in the Constraints. Only Components which reference a Codelist are included in the available list. If the Constrained structure is a Data Provider, the list of Components will be derived from all the Dataflows the Data Provider has a Provision Agreement for. | ||
| Line 36: | Line 38: | ||
[[File:CONST3.PNG|800px]]<br> | [[File:CONST3.PNG|800px]]<br> | ||
| − | ==Steps 3 and 4== | + | ==Steps 3 and 4 - Included and Excluded Values== |
The third and fourth steps are to define the included and excluded values respectively. A Component can only be defined to contain included codes or excluded Codes not both. | The third and fourth steps are to define the included and excluded values respectively. A Component can only be defined to contain included codes or excluded Codes not both. | ||
[[File:CONST4.PNG|1000px]]<br> | [[File:CONST4.PNG|1000px]]<br> | ||
Revision as of 04:34, 24 September 2020
Contents
Overview
Content Constraints or Reporting Constraints are used to further restrict the allowable content of a Codelist in the context of a DSD, Dataflow, Provision Agreement, or Data Provider. Collectively these are termed as Constrainable Structures. The restrictions imposed by Reporting Constraints are taken into account when validating a dataset reported by a Data Provider. A Reporting Constraint defines restrictions against Dimensions and Attributes of a DSD which take allowable content from an enumerated list (e.g. Codelist).
The Codelists which can be constrained are determined from the Constrainable structures that the Reporting Constraint is referencing.
A Content Constraint can impose a rule on any of the available Codelists to remove any number of allowable Codes, therefore reducing the universe of the enumerated list. A Codelist is constrained by either defining which Codes in the Codelist are included (remain valid) or which codes are excluded (are not valid). An included or excluded Code may also be marked as cascade, which means any Codes which are children of that Code also inherit the rule of inclusion or exclusion.
When viewing a Content Constraint, the Included Cube shows which Codes remain valid for any of the Constrained Components. The excluded Cube shows which Codes are no longer valid.
A Constrainable Structure, such as a Provision Agreement will inherit any Reporting Constraints which are attached to lower level structures that it references. For example the Provision Agreement will inherit any Reporting Constraints against the Dataflow it uses, and the DSD that the Dataflow uses. It will also inherit any Content Constraints against the Data Provider it references.
The rules defined by Content Constraints will be enforced when performing data validation. The rules are also reflected when viewing a DSD, Dataflow, or Provision Agreement, as shown below.
See this article for more information on authoring and maintaining structures.
From the Data menu, select the Reporting Constraints page and use the maintenance button to create either a Series Constraint or a Cube Region Constraint. 
Wizard - Cube Region Constraint
Step 1 - High Level Details
The steps in a Constraint Wizard includes step 1 which provides the generic, high level details about the Constraint. See this article for more information on authoring and maintaining structures.
Step 2 - Attachment
The second step is used to define what Structures are being constrained and of the constrained structures, which Components will be included in the Constraints. Only Components which reference a Codelist are included in the available list. If the Constrained structure is a Data Provider, the list of Components will be derived from all the Dataflows the Data Provider has a Provision Agreement for.
Steps 3 and 4 - Included and Excluded Values
The third and fourth steps are to define the included and excluded values respectively. A Component can only be defined to contain included codes or excluded Codes not both.
