From XBRLWiki

CEN Workshop Agreement

Status: Working Group Working Draft

Editing rules

Editorial comments should be highlighted as follows: A comment

Text or rules in discussion (white): Some text

Text or rules already aligned (green): Some text

Text or rules to be deleted (red): Some text

Text to be delivered (blue): Some text

Contents 1 Foreword 2 Introduction 2.1 Objective 2.2 Target Audience 2.3 Relationship to Other Work 3 Scope 4 Normative references 5 Terms and definitions 6 Data Point Meta model 6.1 Structural Perspective 6.1.1 Data Point Model 6.1.2 Public Element 6.1.3 Dictionary Element 6.1.4 Framework 6.1.5 Table 6.1.6 Hierarchy 6.1.7 Taxonomy 6.1.8 Module 6.1.9 Dimension 6.1.10 Domain 6.1.10.1 Enumerable Domain 6.1.10.2 Non-enumerable Domain 6.1.11 Member 6.1.11.1 Defined Member 6.1.11.2 Non-defined Member 6.1.12 Dimensioned Element 6.1.13 Family 6.2 Versioning Perspective 6.2.1 Business Template 6.3 Dimension Validation Perspective 6.3.1 TableCube 6.3.2 Data Point 6.4 Hierarchical Perspective 6.4.1 Hierarchy Relationship 6.4.2 RuleRelationship 6.4.3 PresentationRelationship 6.5 Presentation Perspective 6.5.1 Axis 6.5.2 Row 6.5.3 Column 6.5.4 Sheet 6.5.5 Cell 6.6 Data Point Metamodel Constraints 6.6.1 General constraints 6.6.2 Data warehouse specific constraints

Foreword

Some text

Introduction

Data Point Modeling is a data oriented methodical procedure to create semantic and multidimensional models that reflect the reporting requirements of European supervisors. Reporting requirements are defined by regulations and represented in tables. First Data Point Models were developed in 2009 to describe the data in a redundancy-free, consistent and unambiguous way.

A Data Point Model reflects semantic and multidimensional aspects of data modeling. Semantic models are used to ease the communication between domain experts and IT specialists. Whereas formal models are defined for technical purposes semantic models are defined from a viewpoint of a domain user. They can contain definitions, documentations and explanations. Domain experts decide which objects are relevant and which relations exists between the objects of the model. Semantic models are independent of any physical implementation.

The characteristic of multidimensional models is the division of data in quantitative and qualitative aspects. Parameters that are meas-ured in figures (also known as metrics) are quantitative aspects that often build the basis of data analyses. Qualitative aspects provide a closer description for these parameters. Data objects based on multidimensional models are referred to as facts. Fact attributes are the quantitative aspects of a fact and dimensions are the synonym of the qualitative aspects of a fact.

Data Point Models should enhance the understanding of the data requirements for the reporting entities by providing information to cor-relations that exceed the information given only by table structures. The main challenge in data modeling is the identification of implicit information given in tables and its transformation in an explicit and logical model. As Data Points Models are semantic models they are created by banking specialists who are highly skilled in understanding supervisory reporting frameworks.

The document intends to support the communication between supervisory experts and IT experts by introducing the concept of data point modeling and its underlying terms. Data Point Models remain as semantic models at first technologically-neutral but they are used by IT specialists (1) for generating data formats for the reporting process or (2) for designing multidimensional database structures for the analysis of supervisory data.

This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “MUST” (strong recommendation), “SHOULD” (recommendation) and “MAY” (possibility). Organizations wishing to implement this CWA (CEN Workshop Agreement) would be expected to consider all recommendations where the terms "MUST" and “SHOULD” are used.

Objective

A Data Point Model consists of objects that reflect the supervisory data and its relations among each other that can be communicated and understood by computers. The objects of a data point model described in this document facilitate the ease of understanding of the data structure for technicians and reflects the rules to be met when using a data point model as basis for the generation of a data format or as basis for analysis purposes.

Target Audience

This document is being created to support Information Technology (IT) experts in the transfer of content from regulatory reporting to IT systems. It assumes that the reader has a working knowledge of the XBRL 2.1 and the XBRL Dimensions 1.0 Specifications as Data Point Models are being used as basis for generating XBRL taxonomies. Furthermore basic knowledge about Business Intelligence is assumed to understand the rules to be followed when designing multidimensional database structure for data warehouses.

Relationship to Other Work

Some text

Scope

The Data Point Methodology has been defined for the creation of data point models in the context of European supervisory reporting. Data Point Models are published by an European supervisory authority. To reflect the defined structures in a machine-readable form they can be accompanied by an XBRL taxonomy.

Normative references

Some text

Terms and definitions

There are no formal definitions that are taken from other documents. Comment-04

Data Point Meta model

The data point meta model provides (1) the components for the construction of a formal model that describes sets of data points relevant to European supervisory reporting frameworks, (2) rules on how to combine these components and (3) the meaning (semantic) of the components and relations. Similar to a model construction kit for toys it provides the modelling principles with all characteristics available for use by the modeller. A UML class diagram is used to provide the syntax and semantic to define the meta model for data points by showing the relevant classes and their attributes.

Structural Perspective

Data Point Model

A Data Point Model (DPM) defines structures of data describing the characteristics of the information exchanged in the context of supervisory reporting processes. A DPM consists of a dictionary of business concepts and their properties which are represented in tables. It identifies the content of each data point by its granular components with a semantic meaning and its relation to other data points.

From an IT perspective a DPM can be interpreted by IT applications which enable (1) a generation of data formats for the reporting process or (2) the design of multidimensional database structures for the analysis of supervisory data, i.e., in data warehouses.

References:

meta class	multiplicity	description
Public Element	one or more	References the collection of Public Elements owned by a Data Point Model.

Public Element

A public element is a generalization of a concept of the model. It is identified by a code and consists of an appropriate label. Public elements have two additional attributes giving information about the date of creation and modification. Each public element is owned by an institution or an organization. The owner needs to be made explicit in the data point model. Public elements are abstract and need to be specified by its concrete sub classes like frameworks, tables etc.

References:

meta class	multiplicity	description
Data Point Model	exactly one	References the Data Point Model owning the collection of Public Elements.

Dictionary Element

Dictionary Elements is an abstract class of elements that build the basis of the core concepts of a data point model like dimensioned elements, dimensions, domains and domain members. They are derived from public elements and may define a currency period to support versioning and enable a filtering of obsolete elements by applications. The currency period is defined by two optional attributes validFrom and validTo which should ease the maintenance of elements of the data point model in the course of time.

Comment-06

Superclass: Public Element

Framework

A Framework is a business term common to a group of business users that consists of reporting regulations for a domain specific scope of information.
The information requirements of a Framework are structured through Tables to ease the understanding for the reporting entities that are obliged to submit the information to their supervisor. Business rules to be met by the reporting entities are also defined in the reporting regulations. Some rules are incorporated in the Table design. E.g. the detailed information which is being part of a summation.

A DPM can refer to one or more supervisory Frameworks. Information should be given to which Framework the defined elements of the DPM refer to.

Comment-18

Superclass: Public Element

Table

For presentational purposes data Points can be grouped in tables or in groups of tables. These tables can reflect the structure of the business templates or just individual views on supervisory data based on a specific business context.

A table consists of the combination of one or more axes which from the columns in the x axis or the rows in the y axis. A duplication of tables is indicated by two or more sheets. Axes can be build on basis of a set of dictionary elements that could be already defined in an hierarchy. The combination of the dictionary elements in each axis define a Cartesian product which represent the set of Data Points reflected in a table. Tables are normalized from a dimensional perspective because a dictionary element can only be associated to one axis.

Comment-19

Superclass: Public Element

Hierarchy

Members as well as Dimensioned Elements can be arranged in hierarchies to represent the relationships to one another. In mathematical terms a hierarchy is a rooted tree that provides the information if a member is at top level, below another member or at the same level. Financial information is often split up in different segmental breakdowns which represent dimensions in multidimensional terms. If the members of a dimension share the same level of detail, they could be represented as a flat list. But often the members relate to each other, i.e. in a parent-child relationship, and so they form natural hierarchies. The information about the location of a member in a hierarchy of a dimension improves its understanding. Furthermore, hierarchies can be used to define rules for calculations or aggregations. In the DPM a hierarchy forms are sets of members of an explicit domain arranged in a hierarchical disposition.

Superclass: Public Element

Taxonomy

A Taxonomy combines the components for a version of the DPM for a given period in time. Its currency period is defined by the attributes validFrom and validTo. By creating a relation between Taxonomy and Dictionary Elements, Tables and Hierarchies a set of valid DPM components are being created. Public elements like Table and Hierarchy that have not been modified since the last version of Taxonomy can be reused.

Superclass: Public Element

Module

A Module is a group of TableCubes that carry relevant identical semantics and may serve the reporting process. Modules define sets of business information that should be reported together, i.e. to conduct validation rules that are defined across TableCubes.

Superclass: Public Element

Dimension

A dimension is a data set to one characteristic area which is composed of individual and non-overlapping data elements. In the context of a data point model dimensions are used to group information in a meaningful way. Dimensions are used to define "by" conditions and provide structured information to describe a data point in detail. A dimension can refer to a enumerable domain with a definite number of elements or an innumerable domain where the members are defined by a data type and some additional constraints. Whereas the Dimensioned Element represents the quantitative aspects, the qualitative aspects are described by dimensions. The values given to dimensions are called members.

Superclass: Dictionary Element
Contained elements: Family

References:

meta class	multiplicity	description
Domain	one or more	References the Domain associated with a Dimension.
Family	zero, one or more	References the Family associated with a Dimension.

Domain

A Domain is a classification system to categorize items that share a common semantic identity. A domain provides therefore an unambiguous collection of items in a value range. The items of a domain can have a definite, and therefore countable, number of items, or an infinite number of elements that follow a specific (syntax) pattern.

Comment-14

References:

meta class	multiplicity	description
Dimension	exactly one	References the Dimension associated with a Domain.

Enumerable Domain

An enumerable domain is a subclass of domain that specifies a finite number of members.

Superclass: Dictionary Element, Domain
Contained elements: Member Set

References:

meta class	multiplicity	description
Member Set	exactly one	References the set of members owned by a Enumerable Domain.

Non-enumerable Domain

A non-enumerable domain is a subclass of domain that specifies an undefined number of members in the domain. The non-enumerable domain defines syntactic constraints on the values of the members, i.e. a data type or a specific pattern.

Superclass: Dictionary Element, Domain

Member

A member is the actual value that is given to a dimension. Members are grouped in domains. Members in a domain share certain semantic identity.

Defined Member

A defined member is discrete and countable. A number of these members can be explicitly listed in an enumeration.

Superclass: Dictionary element, Member

Non-defined Member

A non-defined member is defined by syntactic constraints on a possible value, not the value itself.

Superclass: Member

Dimensioned Element

Dimensioned elements represent the nature of the data with a fixed and unchangeable meaning. Dimensioned elements are strongly related to the underlying data type. Mostly they are numeric and quantitatively measurable to be used for calculations and aggregations but they can be also reflect boolean or date values. A dimensioned element is the essential part of a data point that can also refer to zero or more dimensions with its according set of members.

• The attribute dataType establishes the set of possible values of the facts reported according to that metric: monetary information, percentages, dates, texts…
• The attribute periodType defines whether the property / amount to be measured corresponds to a specific moment in time (instant type) or whether its nature requires it to be obtained by taking measures during an interval of time (duration type).

Superclass: Dictionary Element

Family

Families are groups of dimensions relevant for presentation or querying purposes.

Superclass:Dimension Set

Versioning Perspective

A Data Point Model combines the reporting regulations for several specific scopes of information (solvency information, financial information…) summarized in one or more Frameworks. The name of a Framework is stable in time but the business templates referring to a framework change according to amended reporting requirements in the course of time. A taxonomy represents a set of reporting requirements which are enforced by normative or legal acts for a period of time. The currency period starts with the a law becoming effective. In general a new taxonomy version must replace the previous one so the currency period of the old one ends before the new version becomes valid. It is not allowed to have two overlapping taxonomy versions referring to the same reporting period.

A taxonomy consists of Dictionary Elements that are valid for the currency period given by the taxonomy. Dictionary Elements which validTo date ended before the currency period start are not part of the taxonomy. Over the course of time several taxonomy versions exists which may refer to one Framework.

In order to reduce the cost of maintenance, Tables from previously released taxonomies that have not suffered any modification can be referred to from a new taxonomy.

Comment-17

Business Template

A Business Template is a collection of supervisory required data ordered in a representation that is fitting to the business domain and users that need to understand the context and relationships between the required data. These data requirements for supervisory purposes are described in guidelines or legal-normative standards. Often tables are used for the communication between supervisors and reporting entities so the DPM must contain presentational information to reconstruct these tables.

Dimension Validation Perspective

The dimensional validation that takes place on Data Points is hosted by TableCubes. These TableCubes can be grouped into logical groups called Modules. The dimensional validation is formed by a Dimensioned Element combined with at least one Dimension that hosts at least one Member. Each Data Point MUST be represented in one TableCube; there can be no Dimensioned Element that has no Dimensions.

TableCubes may represent multiple Business Templates and vice versa, a single Business Template can be represented in multiple TableCubes, these groups may results in a Module.

Comment-20

TableCube

A TableCube is a set of Data Points with its appropriate Dimensions and Members. A TableCube must be part of at least one Module. A TableCube combines Data Points that share the same dimensionality. The same dimensionality is given when the Data Points have the same number of Dimensions and the Dimensions of each Data Points are equivalent. In comparison to a Table a TableCube does not contain any combination of Dictionary Elements that are not allowed. Non allowed data is often marked as gray cells in viewers on Business Templates.

Data Point

A Data Point is characterized by defining its basic financial meaning and specifying information of breakdowns (hierarchies) in which it is described in different tables or paragraphs of documentation. A Data Point can only have one Dimensioned Element which holds the quantitative aspects about its dataType (e.g. text, number, percentage) and periodType (i.e. instant, duration). The qualitative aspects of a Data Point is described by a (set of) Dimension(s) with each Dimension referring to at least one Member.

Contained elements: Dimension, Dimensioned Element, TableCube

References:

meta class	multiplicity	description
DimensionedElement	exactly one	References the element to be dimensioned by a set of dimensions with their according members.
Dimension	zero or one	References a set of dimensions, each dimension is linked to a domain and one member.

Hierarchical Perspective

Another facility for validation of Data Points (besides dimensional validation) is brought to DPM with the use of hierarchies. But hierarchies can also be used for presentational purposes. Hierarchies therefore have two objectives.

1. is the definition of logical and/or arithmetical relations between Dictionary Elements (Eg. a total comprises of details).
   
2. is to structure Dictionary Elements to increase the comprehensibility of Data Points and their relation to each other.
   

For DPM all Defined Members and Dimensioned Elements MUST be represented in at least one hierarchy.

Enumerable Domains refer to hierarchies to show the relationships between their associated Defined Members. For analysis purposes it is also important to reflect the associations between Dimensions and Hierarchies.

Comment-21

Comment-22

The meta model refers just to the hierarchies but not to the definiton of validation rules in a wider context. Validations rules could be defined by formulas in XBRL or implemented in any other programming language.

Hierarchy Relationship

A hierarchy relationship defines a logical relationship between a pair of Dictionary Elements. One of these Dictionary Elements define the parent and the second one the child element. Both Dictionary Elements are referenced by their codes. A Hierarchy Relationship can be of the type presentation or rule.

RuleRelationship

A RuleRelationship is expressing an mathematical relationship between Dimensioned Elements. RuleRelationships have a sign attribute which identifies the arithmetical relationship between the two nested elements. The list of possible signs in a DPM is not determined. Examples are: + (plus sign) or - (minus sign).

PresentationRelationship

A PresentationRelationship is a Hierarchy for presentational purposes. The order attribute provides information about the ordering of childcodes within the same parentcode. All PresentationRelationships together form a tree structure to be visualized in (e.g.) an Axis of a Table.

Presentation Perspective

Data required by supervisors is described in legal normative acts and mostly reflected in bi-dimensional forms usually referred to as business templates. In most of the cases a business templates is represented by only one table. Sometimes such a convenient match is not possible because there is a high degree of complexity in the template that does not allow grouping the data points in the same view as the predefined template. A split of a business template in different tables is needed from a presentation perspective. A set of tables reflects then the data requirements defined in one business template. The DPM reflects the link between the business templates and the tables that represent their content.

A table consists of a combination of one or more axes. To each axis a set of Dictionary Elements is assigned to. The x-axis defines the columns as horizontal arrangement whereas the y-axis represents a vertical progression of rows in a table. The z-axis can be interpreted as the identifier of a sheet in a series of two-dimensional tables with the same structure. An axis can be also linked to one or more hierarchies build upon Dictionary Elements.

It is possible to assign Header Labels to an axis. They are specific to a table and only used for presentation purposes. One cell in a table is a combination of one column, one row and optional sheets and hires the dimensional combinations of the dictionary elements linked with these axes. A cell can represent a Data Point in the model if it corresponds to data requirements. In the case of the cell is not asked by a supervisor a dimensional validation ensures that the incorrect Data Point is being identified.

Axis

Some explanation.

Row

Some explanation.

Column

Some explanation.

Sheet

Some explanation.

Cell

Some explanation.

Data Point Metamodel Constraints

General constraints

• 1.01   Each Public Element MUST have a code.
  For each Public Element a technical code MUST be defined.

context PublicElement inv: 
    self.code->size() = 1

• 1.02   Each Public Element MUST have at least one label.
  At least one label for a Public Element MUST be given which provides the human readable meaning of this element.

context PublicElement inv: 
    self.label->size() >= 1

• 1.03   All Public Elements belonging to a DPM MUST have unique codes.
  Using a code on more than one Public Element is not allowed.

context PublicElement inv: 
    self.allInstances()->isUnique(p : PublicElement | p.code)

• 1.04   All labels of the set of Public Elements MUST be unique.
  Creating more than one label refering to two different Public Elements is not allowed.

context PublicElement inv: 
    self.allInstances()->isUnique(p : PublicElement | p.label)

• 1.05   Each Dimensioned Element MUST define a data type and a period type.
  Each Dimensioned Element is to be determined by a data type and a period type.

context DimensionedElement inv: 
    self.dataType->size() = 1 
    and self.periodType->size() = 1

• 1.06   Each Defined Member must be referenced by an Enumerable Domain.
  Defined Members need a reference to an Enumerable Domain so that they are able to be used for the definition of data points.

context DataPointModel inv: 
    self.DefinedMember->forAll(m | m.EnumerableDomain->notEmpty())

• 1.07   Each Defined Member MUST be part of a hierarchy.
  In some cases breakdowns represent certain business notion rather than disagregation (e.g. Solo, IFRS consolidation, CRD consolidation). In such case the hierarchy would be just a flat list of members.
• 1.08   Each Enumerable Domain MUST have one default member.
  Some explanation.

context EnumerableDomain inv: 
    self.DefinedMember->select(isDefault = true)->size() = 1 

• 1.09   Each Enumerable Domain MUST refer to one or more hierarchies.
  Some explanation.
• 1.10   There MUST NOT be a doubling of members in different domains.
  Some explanation.
• 1.11   Each Dimension MUST point to one Domain.
  Some explanation.
• 1.12   Each hierarchy MUST have only one root member.
  The root of each hierarchy is an Enumerable Domain. The Defined Members should be attached underneath.
• 1.13   A member MUST be unique in a hierarchy.
  The same member must not be used twice in the same hierarchy.

Data warehouse specific constraints