Difference between revisions of "Reporting Constraints - Structural Metadata Management"

From Fusion Registry Wiki
Jump to navigation Jump to search
(Created page with "Reporting Constraints")
 
Line 1: Line 1:
Reporting Constraints
+
__NOTOC__
 +
[[Category:Structural Metadata]]
 +
== Overview ==
 +
 
 +
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).
 +
 
 +
 
 +
::[[File:Reporting Constraints 1.jpg‎|frameless|500px]]
 +
 
 +
The Codelists which can be constrained are determined from the Constrainable structures that the Reporting Constraint is referencing.
 +
 
 +
A Reporting 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 Reporting 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.
 +
 
 +
 
 +
::[[File:Reporting Constraints 2.jpg‎|frameless|750px]]
 +
 
 +
::<small>''Figure 1 showing the view of the included Cube for a Reporting Constraint''</small>
 +
 
 +
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 Reporting Constraints against the Data Provider it references.
 +
 
 +
The rules defined by Reporting Constraints will be enforced when performing data validation.  The rules are also reflected when viewing a DSD, Dataflow, or Provision Agreement, as shown below.
 +
 
 +
 
 +
::[[File:Reporting Constraints 3.jpg‎|frameless|750px]]
 +
 
 +
::<small>''Figure 2 showing a constrained Reference Area Codelist in the Context of a Data Provider and Dataflow combination (Provision Agreement)''</small>

Revision as of 05:05, 22 November 2019

Overview

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


Reporting Constraints 1.jpg

The Codelists which can be constrained are determined from the Constrainable structures that the Reporting Constraint is referencing.

A Reporting 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 Reporting 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.


Reporting Constraints 2.jpg
Figure 1 showing the view of the included Cube for a Reporting Constraint

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 Reporting Constraints against the Data Provider it references.

The rules defined by Reporting Constraints will be enforced when performing data validation. The rules are also reflected when viewing a DSD, Dataflow, or Provision Agreement, as shown below.


Reporting Constraints 3.jpg
Figure 2 showing a constrained Reference Area Codelist in the Context of a Data Provider and Dataflow combination (Provision Agreement)