ISO 5116-2:2021

INTERNATIONAL ISO
STANDARD 5116-2
First edition
2021-07
Improving transparency in
financial and business reporting —
Harmonization topics —
Part 2:
Guidelines for data point modelling
Reference number
©
ISO 2021
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 What is a data model . 3
4.1 General . 3
4.2 The term “model” . 3
4.3 Data-oriented process of modelling . 3
4.4 The conceptual data model as a first step aiming for a database system . 4
4.5 Description of data modelling approaches for supervisory purposes . 4
4.5.1 General. 4
4.5.2 Using the “form centric” modelling approach . 5
4.5.3 Using the “data centric” modelling approach . 6
4.6 Description of dimensional modelling . 8
4.7 The concept of normalization . 9
5 Why use a multidimensional data model .13
5.1 General .13
5.2 Multidimensional data model .13
5.3 Operations that can be carried out on a multidimensional data model .14
6 Why data modelling is essential for collecting supervisory information .16
6.1 General .16
6.2 Objective of Data Point modelling .16
6.3 Main features .18
6.3.1 Increase of knowledge and understanding .18
6.3.2 Improvement of integration of changes.18
6.3.3 Reduction of risk of duplicate information .19
6.3.4 Higher harmonization .22
6.4 Classification of Data Point modelling in the data modelling concept .23
6.5 Area of application .24
6.6 What are the technical constraints .25
7 How do you proceed in creating a Data Point Model .26
7.1 General .26
7.2 Define dictionary elements .27
7.3 Specify hierarchies .28
7.4 Define Data Points .29
7.5 Define normalized tables and ensure quality of Data Point Model .29
7.6 Distribute Data Point Model .31
8 What the future holds for us .31
Bibliography .34
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www. iso. org/d irectives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www. iso. org/p atents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www. iso. org/
iso/f oreword. html.
This document was prepared by the European Committee for Standardization (CEN) (as CWA
XBRL 002) and was adopted with the following modifications by Technical Committee ISO/TC 68,
Financial services, Subcommittee SC 9, Information exchange for financial services.
— minor editorial change to Clause 1;
— Clause 2, Normative references, added;
— minor editorial changes.
A list of all parts in the ISO 5116 series can be found on the ISO website.
This document uses different verbal forms from those listed in the ISO/IEC Directives, Part 2.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www. iso. org/m embers. html.
iv © ISO 2021 – All rights reserved

Introduction
0.1  General
The purpose of this document is to support supervisory experts in the creation of a Data Point Model
(DPM). According to the definition of the European Banking Authority (EBA), a DPM “is a structured
formal representation of the data [.], identifying all the business concepts and its relations, as well as
1)
validation rules, oriented to all kinds of implementers.”
The underlying rules for the creation of such methods were initially introduced by the Eurofiling
Initiative and developed further by the European Insurance and Occupational Pensions Authority
(EIOPA). The main objective of data point modelling, the process of creating a DPM, is as follows: “[it]
should help to produce a better understanding of the legal background to the prudential reporting data
2)
and make data analysis much easier for both the institutions and regulators” .
Further goals are to prevent redundancies, lower maintenance efforts and, in general, to facilitate
working with national extensions on the European agreed-upon data set to facilitate the descriptions
of requirements that are sharable across national legislations. It is a requirement to have all the
information collected by the national supervisory agencies, particularly in Europe, transformed into the
same data structure with the same quality in order to be able to carry out standardized analysis of the
data across Europe. The current implementations are not able to meet these European requirements for
3)
supervision “to achieve higher quality and better comparability of data” . The main reasons for this are
the differences between the data definitions and the data formats of the various national supervisory
agencies, making comparison of reported data virtually impossible.
0.2  Objective
The aim to harmonize the European supervisory reporting is to be able to carry out more comprehensive
analysis and an increase of comparability of data. Since the supervisory agencies are already acquainted
with the representation of regulations specified in laws, this document is going to introduce the reader
to the concept of Data Point modelling methodology, as well as to its main terms and definitions that will
enable you to create Data Point Models that contain “all the relevant technical specifications necessary
for developing an IT reporting format” on your own.
0.3  Target audience
In general, as a banking supervisor you are responsible for communicating with Information
Technology (IT) experts in order to support the transfer of the essence of regulatory reporting to IT
systems. In 2009, the Eurofiling Initiative published the concept of Data Point modelling. Structures
of data represented in supervisory tables, as well as underlying laws and guidelines, were defined in
order to enable the interpretation of the reporting information by IT applications. IT specialists are
responsible for the development of software. However, most of the time they do not have the special
business knowledge needed to gather reporting requirements from various sources, such as legal texts
like Solvency Regulations and National Banking Acts, in order to build a flawless system. Therefore, the
task of creating a DPM is assigned to you.
This document introduces the basic principles deemed necessary in the modelling process. On the basis
of the explanations given in this document, you will be able to provide prerequisites for deriving data
formats on the basis of a DPM, as well as setting up a powerful data warehouse. This implies that the
model is published in a format that is understood by both parties involved in transforming legislation
into a model: business experts and IT specialists. The topics regarding supervisory reporting are kept
short and limited to the content relevant for this document. The idea is to convey the creation of the
Data Point Model to you, as you are a supervisor with analytical capabilities and personal interest in
this topic. No special IT knowledge is expected. The first sections will give you an overview on the
required IT knowledge.
1) EBA (2011a), p.22
2) EBA (2011a), p.30
3) EBA (2011a), p.29
National banking supervisors have a mandate to evaluate the financial situation of financial
institutions in their country. To be able to perform the necessary analytics, financial data is required
from these institutions. The requirements are described in the form of texts and tables of data. To make
a comprehensive model from these texts and tables, a model is being created to enable IT support in
communicating and storing the necessary data. A common problem with the National Supervisory
Authorities (NSAs) is that IT staff has little financial background and financial specialists have little
IT background. This makes data modelling a problematic area, as both specialities are needed. This
document is aimed at providing the tools and knowledge of creating a DPM by the financial specialists.
The result, a model, can be perfected by IT staff later in the process.
vi © ISO 2021 – All rights reserved

INTERNATIONAL STANDARD ISO 5116-2:2021(E)
Improving transparency in financial and business
reporting — Harmonization topics —
Part 2:
Guidelines for data point modelling
1 Scope
This document provides guidelines for data point modelling for supervising experts. The main body
consists of four sections. The interrogative form helps in choosing which section may best answer your
question and lead you to a good understanding of the subject matter.
After this first introductory section and the section containing terms and definitions, the main part
starts to provide basic knowledge about different types of data models and data modelling approaches.
The first and the second sections provide an overview of data models in general, in contrast to the
third section that highlights the necessity of data modelling for supervisory data. This third section
draws on the objectives and background information of the preceding sections. Furthermore, a
paragraph classifies the Data Point Model introduced by the Eurofiling Initiative and elaborated by
EIOPA and EBA, where many new terms related to DPM are introduced. Another paragraph explains
the areas of application for the DPM. The third section concludes with a paragraph introducing a subset
of the technical constrains that need to be considered in the creation process of the DPM. The fourth
section gives step-by-step instructions on how to create a DPM. The paper concludes with remarks on
the progress achieved so far, and provides an outlook on the software that is being developed at the
moment to support you during the creation process.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
NOTE The terms and definitions used in connection with Data Point modelling are inspired by vocabulary
already known through their use in describing multidimensional databases and data warehouses. IT specialists
originally introduced these terms. However, for an understanding and creation of Data Point Models, they are
now established in the language of business specialists as well.
3.1
data point
combination of quantitative and qualitative aspects to describe a reportable information
3.2
default member
specific element of a dimension which is applied when a dimension is not explicitly associated to a Data
Point
3.3
dictionary element
abstract term for all qualitative and quantitative aspects of a multidimensional model
3.4
dimension
data set of one characteristic area which is composed of individual and non-overlapping data elements
used to define “by” conditions which represent the qualitative aspects of a Data Point
Note 1 to entry: Dimensions literally describe the dimensioned element in order to limit the range of interpretation
and thereby qualify the dimensioned element. One dimension either has a definite (i.e. countable) number of
members, which is called an explicit dimension, or an infinite number of members represented as values, that
follow a specific typing pattern, which is known as a typed dimension.
3.5
dimensioned element
element that shows the nature of the data by typing it and holds information about the underlying
structure of the cell that is specified
Note 1 to entry: In IT contexts, a dimensioned element is referred to as metadata.
3.6
domain
category with items that share a common semantic identity
Note 1 to entry: 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.
3.7
domain member
element that is part of a domain
Note 1 to entry: It is also possible to have members that do not belong to a domain; they can refer to a dimension
directly.
Note 2 to entry: Domain members can either be explicitly named or defined by a type.
3.8
enumerable dimension
dimension that specifies a finite number of members
3.9
fact
quantitative aspect of data reported
EXAMPLE An amount, a number, a string of text, a date.
3.10
hierarchy
nesting (setting relationships in a parent–child-like architecture) of dictionary elements
3.11
non-enumerable dimension
dimension that specifies an undefined number of elements by defining syntactic constraints on the
values of the members, i.e. a data type or a specific pattern
3.12
sub-domain
subset of the members of a domain
2 © ISO 2021 – All rights reserved

3.13
taxonomy
description of a valid Data Point Model
3.14
template
graphical representation of a set of supervisory data
4 What is a data model
4.1 General
4)
Data models outline the relationships between data. It is important that the person responsible for
modelling takes the time to capture all relations between data that can be shown in the model. It is
essential that the model is reviewed by third parties involved for errors to be identified in advance.
Furthermore, it helps to get a clearly structured model that can save time and costs later.
4.2 The term “model”
5)
The term model has its origin in the Middle French noun “modelle”. In IT context, a model pictures a
6)
target-oriented system instead of directly intervening in the complex system. Specifically, in terms
of data models, this means a real system, a system from the domain comprising real components that
7)
are tangible and dynamic, which is mapped to a model to reduce complexity. This may help to find a
suitable solution to an existing problem. The model needs to be created as close to reality as possible,
with attention to requirements regarding structure and behaviour. Nevertheless, in order to raise the
comprehensibility, aspects irrelevant for the purpose of modelling may be left out. The importance of
a single aspect, and whether it is worth being specified in the model, depends on the decision of the
domain experts. This strongly depends on the modeller’s understanding, creativity and capability to
associate the object system with the model.
The challenge of data modelling is that a data model “must be simple enough to communicate [it]
to the end user [.] [and] [.] detailed enough for the database design to use it to create the physical
8)
structure“. The same principle applies to message design and its physical representation.
In the following paragraph, the procedure of data-oriented modelling is presented.
4.3 Data-oriented process of modelling
The data-oriented process focuses on describing the static structure of the reporting system, in contrast
to the function-oriented process, which begins with modelling the functions of the reporting system
and adds the data in a later stage.
As data is the focus point of the banking supervisors, the data-oriented process is applied. Additionally,
in the course of time, data [objects] do not change as much as processes do. Functions are not being
taken into account here.
Applying the data-oriented process, data objects are specified first, as well as the attributes that belong
to each data object. The next step is to put the objects in relation to each other. Furthermore, the data
9)
model can imply integrity conditions and define operations that can be carried out on the data.
4) Cf. Gartner (2012)
5) Harper,D.(2013)
6) Cf. Ferstl, O./ Sinz,E. (2013), p. 22
7) Cf. ibidem, p. 20
8) ZaZa Network (2007)
9) Cf. Baeumle-Courth P./Nieland S./Schröder H. (2004), p.56
4.4 The conceptual data model as a first step aiming for a database system
The data-oriented modelling takes place on 3 different levels that are built upon one another.
Figure 1 — Levels of data-oriented modelling
The conceptual data model reflects your reporting requirements. You are in the best position to know
what pieces of information are requested. The conceptual model helps you in the communication
with your IT specialists. This is an important step to avoid unpleasant surprises later when the
model is implemented in the IT department. The model is built regardless of the database system
10)
or data warehouse to be used. Relevant facts of the object system are to be specified without loss
of information. However, you, as the creators of the conceptual model do not need to be technically
skilled because the succeeding steps of data modelling are carried out by IT specialists. They should be
concerned about the technical requirements. It is very important that this first step of preparing the
conceptual data model is carefully elaborated before transferring the information to the IT. This can be
ensured by early reviews, which include all parties concerned.
The logical data model, as well as the physical data model, is prepared by the IT specialists. In essence,
the logical data model immediately follows the conceptual model (see Figure 1). When aimed at a
database approach, in contrast to the conceptual model, it also takes the requirements of the database
11)
or the data warehouse into account. The physical data model, as a final step, describes the actual
12)
implementation into an existing database system.
4.5 Description of data modelling approaches for supervisory purposes
4.5.1 General
This paragraph deals with the methods that are used to disseminate data and identify all of its
appropriate aspects. The two most appropriate methods of expressing regulatory data in a structure to
determine the context of the information will be discussed here.
10) Cf. 1keydata (2013a)
11) Cf. 1keydata (2013b)
12) Cf. 1keydata (2013c)
4 © ISO 2021 – All rights reserved

Both modelling approaches refer to metadata.
Definitions for data and metadata are given below:
Data is “information processed or stored by a computer. This information may be in the form of text
documents, images, audio clips, software programs, or other types of data. Computer data may be
13)
processed by the computer's CPU and is stored in files and folders on the computer's hard disk.”
14)
Metadata “describes data. It provides information about a certain item's content.”
While data is a number like “50”, the metadata adds qualifying information to the number. The
explanation on the “form centric” and the “data centric” modelling approaches will clarify the difference.
4.5.2 Using the “form centric” modelling approach
The “form centric” approach is an ordinary table format with information held in a cell of a predefined
table called a template. Here a template is understood as a graphical representation of a set of
supervisory data. This approach identifies reporting data by their position in the templates. In this case,
each datum is defined by its coordinate in the table that is represented by the combination of columns
and rows of a template. Each coordinate has a code that is based on the row code and the column code.
This means that the data reported on the basis of coordinate codes is meaningless without the context
of the template. In the following example, each cell that represents a data requirement is described by a
code combination of its column and its row of the table Market Risk: Standardised form for position risk
in equities (MKR SA EQU) of the COREP framework. The form represents market risk equity positions
of the institutions that are subject to mandatory reporting. Throughout the whole document, this table
serves as an example to introduce terms and concepts of Data Point modelling to you. The table with
annotations can be found in the appendix in full size in order to deliver better clarity.
15)
Figure 2 — Table MKR SA EQU as an example of a form centric approach
13) TechTerms (2013a)
14) TechTerms (2013b)
15) EBA (2013)
The “form centric” approach is oriented as the visualization of the data. Dependencies between the
codes of the data are only shown in the templates, i.e. by identifying the appropriate headlines or by
the indents of the label rows. A report based on the “form centric” approach, which uses codes for the
identification of data, is not able to incorporate the dependencies visibly.
Figure 3 — Close up of table MKR SA EQU for higher visibility on important aspects
On the basis of the section of sample table MKR SA EQU, shown in Figure 3, the “form centric” approach
is explained. The value reported by the monetary institution in each cell is called a fact. Facts are
classified as data. Let us say that the oval circled cell, defined by the row position r021 and the column
position c010, holds the monetary value “50”. The coordinate code r021c010 in the red circle is the
combination of the row position followed by the column position. Taking the template into account,
we realize the number “50” represents a value for derivatives as a gross position. When we include
additionally the headline above column c010 we can conclude that a long-term position is reported.
Looking at the excerpt, it is not specified to which year this information belongs. Neither do we know
whether “50” represents a value in thousands or millions, nor can we conclude its currency. We can
imagine that it would be really hard for a non-supervisor to correctly classify this information 50. Now,
if you think about the table shown in Figure 3 again, what would that number tell you if you did not have
any headlines labelling the rows and the columns? Obviously, the information would be useless.
In conclusion, we see that the “form centric” approach doesn’t include information about the data
reported, which is assumed to be known (like all figures are in thousands). Moreover, without the
context of the row and column position of the datum, the information content is essentially zero.
4.5.3 Using the “data centric” modelling approach
In the “data centric” approach, data is identified by a set of characteristics. It is considered independently
of its graphical representation by adding information that unambiguously defines the datum. Therefore,
no positional alignment is needed in order to give the datum a specific meaning. Any datum is expressed
in terms of the categories necessary for their identification.
Information available is divided into two groups:
― qualifying information;
16)
― quantifying information .
16) Cf. Sapia, C. / et al (1999)
6 © ISO 2021 – All rights reserved

Qualifying information is represented by attributes to certain categories, while quantifying information
describes the object evaluated.
Figure 4 shows a dimensioned element which holds the information about the main character of the
datum to be reported. A dimensioned element shows the nature of the data. It holds information about
the underlying structure of the cell that is specified. In IT contexts, a dimensioned element is referred
to as metadata. In our example, the dimensioned element specifies the amount type of the datum as
a gross value. The corresponding categories, called dimensions, contain further information on the
datum and therefore increase the quality of the datum to be reported. The dimensioned element, as
well as the dimensions, belongs to the group of qualifying information, i.e. metadata. The number itself,
“50” in our example, is called a fact and represents the quantifying information of the datum.
Figure 4 — Dimensional model for MKR SA EQU
One Data Point is represented by one cell of the table in the “form centric” approach. Going back to the
example above used to explain the “form centric” approach, defining the cell by a combination of row
and column codes (like r021c010), we have got a Data Point specified by a dimensioned element with
its corresponding dimensions indicating the various regions. One possible dimension, for example, that
can be derived looking at the table in Figure 2 is the risk type dimension. Various types of risk are listed
in the rows of this table: “general risk” and “specific risk” are reasonable attributes for the risk type
dimension. To identify the risk types, business knowledge is needed. We cannot rely on the nesting
(tabs) in the table as they might be used differently amongst table creators for presentation purposes.
Each dimensioned element is characterized by a variable number of dimensions. Each dimension is
linked to one attribute, called a member, to characterize the Data Point. The dimensions represent the
“by” conditions. Dimensions literally describe the dimensioned elements in order to limit the range
of interpretation, and thereby qualify a dimensioned element. One dimension either has a definite
(i.e. countable) number of elements, which is called an enumerable dimension, or an unknown list of
17)
members to the regulator, which is called a non enumerable dimension .
Members are attributes that can be assigned to a dimension. As members are often used for various
dimensions, domains are introduced in order to reduce redundancy. Each domain contains semantically
correlated members that can be used throughout the whole of the reporting framework. The dimension
represents the semantic relevance for the specific use on the dimensioned element. All members are
added to at least one domain that can be reused by a variety of dimensions.
17) Cf. Declerck, T./ Hommes, R./ Heinze, K. (2013)
Returning to the difference between metadata and data, the definitions are transferred to the vivid
example of MKR SA EQU. The Data Point identified by the row and column code combination r021c010
in the table format holding a fact “50”can be referred to as data. The metadata is described by the
dimensioned element specifying “50” to be a gross value and the selected domains, one for each applied
dimension.
It should be ensured that each Data Point is defined only once in a reporting framework, regardless
of whether it is included in more than one table. One major benefit is that the information can be
assembled in various ways, based on the preference of the supervisory expert. Therefore, the form of
the tables can be aligned with the previously used “form centric” tables. This results in a minimum
adaptation time for the filers.
4.6 Description of dimensional modelling
Dimensional modelling is the innovative modelling type to create multidimensional data models.
Depending on the conditions, the dimensional model may be “simpler, more expressive, and easier to
18)
understand” than divergent modelling techniques. Dimensional modelling is used by the data centric
approach, introducing dimensions to qualify the information that consists of numeric data, including
values, counts, weights, balances and occurrences. The main information about the datum, i.e. the data
type of the fact, is held in the dimensioned element, which is verified here by the amount type dimension
as it contains crucial information about the Data Point to be specified. Further qualifying information
19)
that is associated with the Data Point is specified by the members of the applied dimensions.
18) Ballard, C./et al (1998), p. 42
19) Cf. Ballard, C./et al (1998), p. 42
8 © ISO 2021 – All rights reserved

Figure 5 — Example of a dimensioned element with corresponding dimensions for the cell
r021c010 marked in MKR SA EQU
20)
The term ‘metrics’ is used as a synonym for ‘dimensioned element’ in other sources. However, for the
rest of this document the term dimensioned element is used. Taken literally, it is the one that is defined
by the application of dimension-member combinations.
4.7 The concept of normalization
As previously stated, redundancy is to be reduced by the use of the Data Point Model. The most popular
approach to achieve this is through the process of normalization. As this is an IT specific proven
concept, it will be introduced to you in this paragraph.
Figure 6 shows what a typical table created by business users looks like. The values are reported in
order to store them in a database and carry out an analysis.
20) Declerck, T./ Hommes, R./ Heinze, K. (2013)
Figure 6 — Table MKR SA EQU created by business users
Examining the table, many questions remain unanswered for the untrained reader. Here is a list of
questions that shall serve as some guidelines:
― Unit of measure: What does “50” mean? Units? Currencies?
― Reporting entity: Are the values of a single country or institution?
― Definition of the used members: What is considered as derivatives?
― .
This set of questions was developed in a very short time. It is obvious that it is important for the
reporting entity and the supervisor to share the same vision. In order to avoid discrepancies in the
interpretation of the figures, the table must be unambiguous.
In order to leave no room for doubt, the questions above need to be answered. The information held in
the figures of this table must be made explicit to all users on both ends of the communication process.
10 © ISO 2021 – All rights reserved

Another way to express the same facts, in order to answer some of the questions raised, is in plain text,
as follows:
The cell r021c010 of MKR SA EQU holds the following information, which is obvious to you as a banking
supervisor:
50,000 € worth of derivatives were held by a certain institution at a certain date.
All the cells in the table are reported by one institution, and each Data Point in that table is to be sent
for one reporting date.
It is obvious in this method of representation that all facts stored in the example table MKR SA EQU are:
― of monetary value;
― in one common currency;
― reported in thousands.
It is still not yet known who reported the figures. Furthermore, there is no definition of the axes´
members. The members that add qualified information about a single value need to be specified in order
to prevent discrepancies in the interpretation of readers. The task now is to check what level of detail is
required for the facts reported, in order to carry out the required analysis at a later stage. On the basis
of this decision, abstract categories are created. It is advised to carry out this task in a team of experts.
For example, if we want to analyse the credit risks taken, it might be important not only to obtain
knowledge about the countries where the risk was taken, but also about the different regions within
the countries because this might reveal a difference in the risk aversion within the various regions
(Figure 7). Therefore, it is not sufficient to name a category “country” and list below all countries.
Referring to the mentioned example, a further breakdown is needed that lists the regions of each
country. For these different levels of detail, a hierarchy can be defined in order to derive aggregated
21)
information about one country, or one continent at a later time. A sample breakdown with selected
continents, countries and regions is shown below.
Figure 7 — Hierarchy of countries to show different levels of detail
21) Santos I, Castro E (2011)
The country category is just an example to make you aware of the level of abstraction you may choose
for the categories identified.
A list of the identified categories of the facts reported in the table above (Figure 6) follows:
― A monetary value: some numeric data type.
― In a currency: closed list of currencies allowed.
― In thousands: closed list of precision types allowed.
― A reporting period or a point in time: A closed list of periods, as all reports are required to cover
predetermined periods.
― If the figure was reported by a single bank, a closed list of all banks that report to the national
supervisor may be a good way to categorize the fact.
― An explanatory document of the axes´ members is needed as a reference, where each member of
each dimension applicable for MKR SA EQU is unambiguously defined.
Each member must be created only once and allocated to one domain. The members must be created in
a consistent manner, and without doubling the same elements under different labels. The domains can
be assigned to dimensions. Suppose that we created the full hierarchy as is visualized in Figure 7. We
could assign a (sub)domain called 'European countries' to a dimension named 'country of market'. In
this domain all the European countries would be listed. Also, there could be another (sub)domain called
'BRIC' containing the countries Brazil, Russia, China and India. This BRIC (sub)domain could be assigned
to two dimensions, the 'country of origin' dimension and the 'country of production' dimension. Last but
not least, we could build another domain called 'all countries' where all the members that are already
assigned to other (sub)domains, as well as remaining countries, are included. This domain can, once
again, be assigned to multiple dimensions. Figure 8 represents this scenario:
Figure 8 — Pool of shared domains
Once domains are created, they can be assigned to a variety of dimensions. That prevents redundancy of
members and defines them uniquely for satisfying the requirements of communication via computers.
This step is called normalization. A technical definition for normalization is as follows:
12 © ISO 2021 – All rights reserved

Normalization is the transfer of a data model to a certain state. The various states are differentiated
by levels of the 'normal form' and achieved by applying them to the data model. The third normal form
is enough to prevent redundancies and inconsistencies. Therefore, the maintenance of stored data is
22)
facilitated by applying the third normal form.
To achieve this, the two main aims are:
23)
― arranging data into logical groups, such that each group describes a small part of the whole ;
24)
― restricting to the level of detail needed .
In order to bring your data model into the third normalized form, you need to group members in
domains and make sure that the domains do not overlap. It must be possible to unambiguously assign
the members to a single domain. Therefore it is important to use meaningful names for members,
domains and dimensions. It is also advised to prepare a handbook where the names are differentiated.
Following these rules, consistency throughout the model can be achieved.
5 Why use a multidimensional data model
5.1 General
25)
The data in the conceptual model can be modelled dimensionally as well as hierarchically . The reason
it is advised to create a multidimensional data model, is that it is closer to the presentation form that
the user is accustomed to, and therefore easier for him to understand.
5.2 Multidimensional data model
The multidimensional data model supports the “data centric” approach with its two groups: qualifying
and quantifying data.
In order to make it clear, we will continue with the example of MKR SA EQU that you are already familiar
with. We simplify the model in Figure 9 to show three categories by displaying it on paper.
22) Cf. Minhorst, A. (2005), p. 49
23) databasedev (2013)
24) Heinze, K. (2013)
25) Collins, J. (2013)
Figure 9 — Multidimensional model
The multidimensional data model visualized by a cube is specified by three categorie
...