ISO 5116-3:2021

INTERNATIONAL ISO
STANDARD 5116-3
First edition
2021-07
Improving transparency in
financial and business reporting —
Harmonization topics —
Part 3:
Mapping between DPM and MDM
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 Introduction to the Multidimensional Data Model . 1
5 Preconditions on mapping . 2
5.1 Types of Database Management Sytems (DBMSs) . 2
5.2 Fundamental choices . 3
5.3 Fact definitions: presentation vs DPM . 5
5.4 Storing native XBRL facts . 6
5.5 Dimension/defaultMember . 7
5.6 Options . 8
5.7 Versioning. 8
5.8 Changes on fact values. 8
6 Definitions . 8
7 Mapping from Data Point Model to Multidimensional Data Model .9
7.1 General .10
7.2 Framework .11
7.3 Taxonomy .12
7.4 Dimensions .14
7.5 Context .19
7.6 Primary Items .21
7.7 Fact table or Data points .23
7.8 Summary .24
8 Metamodel defined by the EBA (FINREP and COREP) mapped to MDM .26
8.1 General .26
8.2 Creation of the structure and load of the DPM from the EBA in a RDBMS .27
8.3 Loading DPM_ROLAP from DPM_EBA .27
9 Implementation of the DPM in the MDM using the design ROLAP .34
9.1 General .34
9.2 Structure ROLAP .34
9.3 Creation of the infrastructure through MS SQL Server .34
10 DPM of FINREP 2012 in the MDM using the design ROLAP .38
10.1 General .38
10.2 DPM of FINREP 2012 .39
11 DPM of the first prototype of Solvency II in the MDM using the design ROLAP .47
11.1 General .47
11.2 DPM of the prototype .47
Bibliography .51
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/ directives).
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/ patents).
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/ foreword .html.
This document was prepared by the European Committee for Standardization (CEN) (as CWA
XBRL 005) and was adopted with the following modifications by Technical Committee ISO/TC 68,
Financial services, Subcommittee SC 9, Information exchange for financial services.
— 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/ members .html.
iv © ISO 2021 – All rights reserved

Introduction
0.1 General
This document aims to provide an introduction to the topic of creating a conceptual model for storing
multidimensional data which is received as XBRL instances that follow the rules defined by European
taxonomies published by the European Banking Authority (EBA) or by the European Insurance and
Occupational Pensions Authority (EIOPA).
Disclaimer: The Multidimensional Data Model (MDM) presented in this document is intended to be a
starting point for a subsequent modelling process to be adjusted and extended to specific analytical
or transactional needs. It solely refers to the concepts of Data Point Model (DPM) and European XBRL
Taxonomy Architecture (EXTA), which build the basis of European supervisory reporting.
The structure of the data model is based on meta classes, introduced in part 1 and 4 of the CWA1
[26]
document . The data model represents a relational model using Relational Online Analytical
Processing (ROLAP). In this document UML data structures of a DPM are used because its comprehension
will be easier. With the UML class model representing the description of the European filing rules, this
document visualizes the mapping between UML meta classes and their correspondence in the form of
database tables in the MDM.
This document consists of eight sections, save the bibliography. Section one explains working with
a Multidimensional Data Model as a step towards working with the Relational Data Model. Section
two makes a study of the architecture of XBRL, the databases and their aims, requirements and
preconditions in catering for XBRL. Section three defines the conditions used for mapping from DPM to
MDM. Section four is detailing point by point the mapping. Section five shows the metamodel defined by
the European Banking Authority (EBA) through the FINREP (Financial Report) and COREP (Common
Solvency Report) taxonomies and its mapping into MDM. Section six displays the MDM implemented in
a relational database. Sections seven and eight show two implementation examples.
0.2 Objective
The objective of this sample MDM is to provide a starting point into the topic of mapping DPM and XBRL
instance structures into a multidimensional database. Based on an easily comprehensible example,
more complex issues are addressed that would need to be taken into account by defining an MDM for
production use.
0.3 Target audience
This document is aimed at users of European supervisory taxonomies that have the need to store
reporting data based on these data definitions and to retrieve them for analytical or transactional
purposes. Database experts should get detailed information about the specifics to be taken into account
when modelling multidimensional database structures for storing supervisory data based on XBRL.
Therefore, the audience of this document might be financial or economic institutions, agencies or
universities with the intention to provide micro or macro prudential analysis on supervisory data.
0.4 Relationship to other work
The reader of this document is expected to be familiar with the principles of data modelling, having
a thorough understanding of the concept of DPM as well as basic knowledge of XBRL. The reader is
also expected to have knowledge in creating conceptual models for relational and multidimensional
databases.
INTERNATIONAL STANDARD ISO 5116-3:2021(E)
Improving transparency in financial and business
reporting — Harmonization topics —
Part 3:
Mapping between DPM and MDM
1 Scope
This document aims to provide an introduction to the topic of creating a conceptual model for storing
multidimensional data which is received as XBRL instances that follow the rules defined by European
taxonomies published by the European Banking Authority (EBA) or by the European Insurance and
Occupational Pensions Authority (EIOPA).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
No terms and definitions are listed in this document.
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 http:// www .electropedia .org/
NOTE The terms and definitions used in the mapping with Data Point Model are inspired by vocabulary
already known from their use for describing multidimensional databases and Data Warehouses.
4 Introduction to the Multidimensional Data Model
The multidimensional database is primarily used to create OLAP (Online Analytical Process)
applications and their databases using a fact table and set of dimensions. A multidimensional structure
stores multidimensional data, that is to say, cubes. A cell or fact is an intersection consisting of elements
that form the dimension(s) which in turn form a cube. A cell can have zero or more measures, but in this
document only one measure is taken into account.
The Multidimensional Data Model (MDM) is used instead of the Relational Model, because the
European architecture of economic-financial reports is relying on dimensions heavily, which makes
implementation in MDM the logical choice. Moreover, the performance of queries is better in this type
of database.
The goal of this document is to store the Data Point Model in a database, in an efficient, easy way.
5 Preconditions on mapping
5.1 Types of Database Management Sytems (DBMSs)
In this section some types of DBMS's are analysed that appear suitable for storing DPM and XBRL
documents. Only those databases are considered where, in a previous study, it seemed possible to store
the DPM and to extend XML or XBRL documents.
Figure 1 — Different types of DBMS's
The typical solutions are (Figure 1):
― Hierarchical databases;
― Multidimensional databases;
― Relational databases;
― Mixtures, where, normally, the relational database is the base.
Hierarchical databases (e.g. Tamino by Software AG, GT.M, IBM Information Management System (IMS)),
which rely on the hierarchical model, that is to say, databases organized into a tree-like structure. In this
structure, data uses relationships among their leaves. Each leaf on a superior level has 0.* relationship
with leaves on the inferior level. A leaf on an inferior level only has a 0.1 relationship with a leaf on the
superior level.
Multidimensional databases, not being based on relational databases, have the data is stored in an
optimized multi-dimensional storage array, and not in a relational format. However, it is necessary
to organize the information in a cube beforehand. These databases have very fast response times in
queries. Examples of Multidimensional databases are: Essbase, icCube, Infor BI OLAP Server.
In relational databases the information is stored in relational format. But, moreover, in these databases
it is possible to store cubes, but in a relational format, changing their internal structures.
2 © ISO 2021 – All rights reserved

In all these solutions, it is necessary to verify that database transactions are processed reliably. For
this, a database must fulfil ACID (Atomicity, Consistency, Isolation, and Durability) properties. Not all
databases fulfil the ACID requirements, this depends on the vendor. These properties are:
― Atomicity: each transaction is “all or nothing”;
― Consistency: it ensures that any transaction will bring the database from one valid state to another
valid state;
― Isolation: it ensures that the concurrent transactions result in a system state that would be obtained
if transactions were executed serially;
― Durability: once a transaction is committed, it will remain so even in the event of power loss, crashes,
or errors.
― This document will not analyse whether databases carry out the ACID properties. However,
the majority of commercial Relational Database Management Systems (RDBMS) achieve these
properties. These databases are very common in the Information Systems Departments of this
environment. Examples of these RDBMS's, are Oracle, DB2 or MS SQL Server, amongst others.
5.2 Fundamental choices
This section will discuss, if the XBRL document instance is stored directly in the database in part or in
a relational model.
There are two mainstream solutions for storing XBRL instances and their facts into a relational
database system. The question is, when Information Systems (IS) receive a XBRL taxonomy or an
instance document, how these XML documents can be stored with the lowest cost in resources in the
database. As relational databases can only store relational data and XML documents are not relational,
the mapping is not a direct process.
The topic to analyse is:
― Mapping the XBRL instance document to the relational model;
― Storing the XBRL instance document as a blob, or PDF document in the database;
― Storing the XBRL instance as a XML document or as a XBRL document.
Not all XML documents can be mapped into the relational model. However, XBRL instance documents
can be mapped to the relational database, as they show many references. The XBRL specification
contains a very important aspect: validation by formulae. Formulae are based on XPath 2.0 (XML
Path Language), which is based on XML. When the XBRL instance document is transformed into the
relational model, the instance document cannot be validated by formulae anymore. Moreover, as these
validations are based on the XBRL Formulae and Calculation specifications, the mapping to a RDBMS is
[19]
not easy nor immediate . As XBRL validation requires the use of XML enabled tools, this cannot be
done in the RDBMS. There are many validators, both commercial and open source (Openfiling) in XML.
On the other hand, the mapping of instance documents into a relational database is available through
different commercial or open source vendors (Openfiling).
An XBRL instance document can be stored in a relational database as an XML document or in a relational
format. Analysing the queries in both solutions resulted in:
― In XML, these queries use XQuery and XPath.
― The end user has difficulties accessing the language of the queries directly or through tools;
― The query language is very specific. Experts in this language are necessaries;
― The tuning of XML documents is complex.
― Relational Database use standard SQL.
― The end user can obtain the data in an easy way through spread sheets, linked tables or other
tools;
― The query language is a standard, and is part of university IT curricula;
― The performance and tuning of a relational database has been extensively analysed.
― If the XBRL instance document is stored directly in the database (as a blob), the problems are the
same but the RDBMS is an inferior level. Cases are:
― Storing as a photo (Blog or Clog);
― Storing as a XML document.
In the first case the database is only used as a storehouse. In the second case, storing as an XML
document, with functions embedded in the engine of the database. This means that the database
manager has embedded these functions in the engine. Today there are vendors that add the type XML
as Oracle, MS SQL Server or DB2. Depending on the vendors the main features are:
― Generating XML Instances;
― Methods or procedures on the XML data type;
― Queries on XML instances;
― Processing namespaces;
― Indexes;
― Navigation through the document;
― …
XBRL is an extension of XML, but it is not XML, the cost of implementation therefore has to be evaluated,
and the performance of the database must be re-tuned for optimization.
MS SQL Server has also utilities for working with XBRL that is necessary to analyse, in the same way.
Oracle 11g release 2 (as from version 11.2.0.3.0) works with XBRL instance documents Oracle 11g with
XBRL(https:// docs .oracle .com/ cd/ E20212 _01/ doc/ doc .11/ e17070/ intro .htm):
― Manages XBRL content;
― Can create multiple XBRL repositories and project XBRL data relationally or query it in various
ways;
― Operations of aggregated business and financial reports such as extraction, transformation, and
loading (ETL); business intelligence (BI); and online analytical processing (OLAP);
― The validation is outside to the database Out oracle (https:// www .xbrl .org/ xbrl -solutions -oracle).
Both the Microsoft and Oracle solutions have to be evaluated in terms of costs, resources, tuning and
performance in the engine of the database.
In summary; this document is not considering storing the XML document (instance) as a whole, as it
is storing the instance in a native XML database. Only storing the content of the XML document in a
RDBMS is discussed. One can either:
― Store almost native facts and their aspects, or
4 © ISO 2021 – All rights reserved

― Convert the facts and the required aspects into a proprietary set of data before storage.
― For both scenarios all relevant aspects on the facts will need to be determined from the analyst
point of view.
Another consideration for the importance of aspects is to decide if the database will also be the
source to generate (the same or new) XBRL instances (more information on Openfiling). More XBRL-
specific requirements need to be considered to create a valid instance. When the target is to (re)create
instances, special consideration has to be given to any merge processes on fact values. Merged fact
values will cause problems for instance creation unless there is a possibility of an ‘undo’ (split) routine
or a structure more complex in the relational model. This can be created as easily as storing both the
original fact values and the merged value. However, different instances can coexist because, as it is
explained below, each fact is defined in a time period and it belongs to an entity.
Table 1 below shows a summary of the possible advantages and disadvantages of both methods.
Table 1 — Pros and cons of alternatives
Proposals Native store Convert before
store
Quantity of aspects to store (direct from instance) (+)(-) (+)(-)
Quantity of aspects to store (indirect from Discoverable Taxonomy (-) (+)
Set (DTS))
Speed of storage process (+) (-)
Maintenance (mapping table, mapping software) (+) (-)
Analyst queries, degree of difficulty (-) (+)
Analyst queries, speed (-) (+)
Easy handling of new DTS versions (+) (-)
Extensibility towards proprietary XBRL reports (+) (-)
Extensibility towards proprietary non-XBRL reports (-) (+)
5.3 Fact definitions: presentation vs DPM
XBRL Taxonomies created with DPM contain two definitions of individual reportable facts:
― Primaries, dimensions and members have readable labels and optional references to external
documentation;
― Tables, axes headers and table footers have generic (text) labels and indicators pointing towards an
'RC' (row-column) value that identifies a cell in the templates that form the basis of the DPM.
Since there is no guarantee that both definitions will match, a reported fact can rely on either definition.
It depends on whether the reporter used a form, based on the table linkbase, or a mapping based on
the primaries/dimensions/members combinations. From a theoretical point of view the templates are
transformed to DPM and then the DPM into XBRL concepts, i.e. the concepts are leading. This has not
been stated explicitly by EBA. In order to stay independent from EBA modelling it is best to store both
definitions as relevant aspects. The definition texts as such are the only means for a business analyst to
create a query and understand its outcome. Definitions that rely on documentation outside the DTS and
is referred to by XLink references, is only available for concepts, not on the presentation of the table.
Linking this information into the database (and query) is outside the scope of this document. In theory
such external reference pointers could be created on the presentation, EBA has however not used this
feature; it would be used in accordance with XBRL specifications.
When using the instance transformation option, the definitions have to be manually mapped to the
internal definitions. This only needs to be done once. The maintenance task is to check every new
release of the DTS for changes in definitions regardless where they are being used. Every change needs
to be re-evaluated and again manually mapped into the internal definitions. Analyst queries work with
internal definitions, their meaning should be clear to the users. Another point of consideration is that
there is no guarantee that what is dimensionally valid in the DTS will be presented as a cell in any table.
The other way around, what is in a table is always dimensionally valid, is guaranteed. There needs to
be a process to detect such anomalies, either upon loading a new version of the DTS or upon storage
of the facts. There may even be a need for a disclaimer that facts reported without a proper 'cell' in a
table are being disregarded. In this sense the table linkbase is forming a third validation mechanism of
reportable facts (XSD and XDT being the others).
Lastly the introduction by EBA of a new mechanism called 'filing indicators', needs to be thought
through. If instance creation from the database is in order, these XML nodes need to be stored too.
They are used to ease the validation process of the XBRL formulae. The mechanism indicates from
which tables the instance contains facts. Some facts could be placed in multiple tables (e.g. a total in
the total table and in its specification table) and different formulae may need to be executed depending
on its usage. There is no mechanism in place that links the filingIndicator value to anything in the DTS.
Therefore, one could report table 999 that does not exist as long as there are no facts reported against
it. This makes for little use in back office applications; it only needs to be stored when instance creation
is part of the requirements. The table number used stems directly from the templates and the number
is accompanied by explanatory texts in the label that is placed on a presentable table. It is not part of
any structured part of the taxonomy.
5.4 Storing native XBRL facts
Regulators will receive a container file (ZIP) with at least one XBRL instance in it. Depending on internal
processes this container needs to be unzipped first and its content evaluated. Validation of the instance
is not part of this document, a valid instance is assumed. Instances can represent multiple taxonomies;
an assurance statement could be made part of the instance containing the reportable figures. Solutions
to prevent or accommodate this are not part of this document. An instance based on a single taxonomy
is assumed, referring to a taxonomy that is enabling reportable figures only. An instance can contain
Xlink content. This is not discussed in this document. The instance is expected to contain only facts,
units, contexts, one schemaRef and filingIndicators. Table 2 shows different aspects of storing native
XBRL facts.
Table 2 — Different aspects of storing native XBRL facts
Technical part Aspects Comment
Instance file name. Optional hash code. For NSA's (National Supervisory Authori-
ties) working with assurance solutions.
Root node x brli: x brl. Characterset, and optional language,
version and id.
At least one link : s c he maR e f. Contains an URI (Uniform Resource This is considered to be the entrypoint of
Identifier) and a location. the DTS for which this instance is being
reported. XBRL allows multiple schemaRef
nodes, EBA only one. EBA has determined
that the URI represents an absolute loca-
tion (web address) and the location only
the name of the schema file.
Optional multiple link: EBA will not be using these.
linkbaseRef.
At least one find: fIndicators. This contains multiple find: fIndicator. The value is string based and represents a
table.
Optional multiple contexts Each context must have one ID
using x brli: c ont e x t. attribute, one x brli: e nt it y node and
one xbrli: period node. It may contain
many x brli: s e gme nt and x brli: s c e nar io
nodes.
6 © ISO 2021 – All rights reserved

Table 2 (continued)
Technical part Aspects Comment
x brli: e nt it y. Contains an identifier value and its These represent the reporting entity with
Scheme URI value. its unique identifier within the NSA and
the owner of the identifiers (NSA).
xbrli: period. Contains either an instance date or XBRL allows also forever but EBA has pro-
a periodStart and periodEnd date. hibited this use.
x brli: s e gme nt and xbrli: Contain dimensional aspects and/ EBA allows only x brli: s c e nar io to be
scenario container. or proprietary XML schema based used and no proprietary content. The
content. dimensional aspects consist of a set of
dimension and member QNames and/or
a dimension QName with a typed mem-
ber QName AND its value.
Optional multiple x brli: unit. Each unit must have one ID attribute. These are all QNames. Each QName must
It can hold either one measure or a set have a value that goes with it.
of numerator/denominator.
Optional multiple facts. A fact is represented with
a QName (a primary con-
cept in the DTS). It holds
a contextRef and unitRef attribute
(the latter only on numeric typed
concepts). It may hold a decimals,
language, nilable and ID attribute.
For the definition of the fact aspects the following may be of interest: Each concept (primary, dimension,
member) will have at least one label, the standard label. There may be more types of labels to a concept.
A label is defined by its role (the 'type') and the language it is in. Multiple labels of the same language
and role may occur. EBA will provide only the English language and only one occurrence of each role.
The label texts may contain special characters. Within a table in the DTS, any cell defined by a set of
primary, dimension/member combinations may have multiple labels attached to it. These labels are
also represented with a role and language. EBA will again utilize only one occurrence of text in each
role per language, the language being English.
5.5 Dimension/defaultMember
Special attention needs to go to default dimension members. All EBA defined dimensions will have a
default member. Often the definition of this member reads 'Total/Not applicable'. The XBRL specification
describes that any default member that is discovered when starting to discover the DTS from the fact
is eligible for the default member. This applies even if that dimension is not used on the fact and even
when the fact is not dimensional at all. In theory this means that all defaults apply to all facts since a
single entry point will cover the whole of the EBA DTS. With some common sense a limitation can be
applied that default members apply only on the facts reported in a certain table, when that table is using
the parenting dimension. Logic could even go further stating that individual cells can be evaluated
if the default member makes any sense at all. If not, the 'definition' of 'Not applicable' could be read
in which case the dimension and member are not appropriate on the fact at all. In all other cases the
default member applies to the fact and needs to be stored by an alternative (to storing only data from
the instance) process.
Naturally, these default dimension/member combinations must be identified in storage since they are
not allowed in the instance.
The XML schema also allows nodes to be identified carrying a default value. In particular, when typed
dimensions are being used there could be a typed element that carries a default. The EBA DTS does not
use this option.
In the MDM the default member is another normal attribute of dimension. However, it is marked as
attribute by default, because it is only relevant for the mapping process and has no a special meaning in
the MDM.
5.6 Options
XBRL allows for more presentation texts to be added besides primary, dimension, member, table or
axis. These texts could be part of the definition of a fact. Careful evaluation of the taxonomy in an
XBRL enabled tool using both XDT and TLB specifications can reveal these texts. If they are part of
the definition they need to be stored or used for creating the mapping to local data elements. As, for
example, the Linkrole labels, and so on.
5.7 Versioning
When a new version of the DTS is being released, the EBA has chosen to include two special attributes
on every concept: creationDate and modificationDate. Up to the public release DTS of September 18th,
2013, there were no modificationDates present and the creationDate was increased on each new version.
In theory these dates could be the trigger to signal any change in definition of the concept but if the
mechanism is not used other ways to detect changes must be found. Another matter is that there is no
such set of dates on the labels that form the table, which can be equally regarded as representing (a part
of) the definition. For this part of the DTS a detailed 'diff' function needs to be designed. It is clear that
every definition change breaks the trend on any reported fact. Manual intervention on mapping to local
sources must be undertaken.
5.8 Changes on fact values
If the NSA has the authority to change reported fact values, they must be aware that recreating the
original instance may be cumbersome, unless appropriate versioning mechanisms have been put in
place to conserve the original fact values. Special care has to be taken with business rules that have
been defined by the DTS author on such a fact. The change in value may trigger a business rule. These
rules can however only be executed on an instance, not the RDBMS.
6 Definitions
For the purposes of this document, the following terms and definitions applied are shown. The terms
and definitions used in the mapping with Data Point Model are inspired by vocabulary already known
[1] [2] [3] [4] [5]
from their use for describing multidimensional databases and Data Warehouses . In turn,
[27]
the DPM is based in the XBRL Meta-metadata Model . IT specialists originally introduced these
terms. However, for an understanding and creation of Data Point Models they are established in the
language of business specialists as well.
In this section, the set of definitions necessary for mapping the DPM in ROLAP are shown. The majority
[6] [7] [8] [9] [10] [26]
of the definitions are obtained from . When the definition is in the area of CEN WS
[11] [22] [26]
XBRL (http:// www .xbrlwiki .info/ index .php ?title = Main _Page) only the name of the term is
shown.
The terms used directly or indirectly in the mapping of DPM in the MDM are:
― concept;
― data point model;
― dimension;
― domain;
― family;
― framework;
― item;
― (domain) member;
8 © ISO 2021 – All rights reserved

― metric;
― namespace;
― owner;
― perspective;
― public elements;
― tablegroup;
― datapoint;
― datacube;
― module;
― hypercube.
A hypercube is an abstract item declaration in the xbrldt: hypercubeItem substitution group. A hypercube
is an ordered list of dimensions, defined by the set of zero or more dimension declarations linked to
the hypercube by hypercube-dimension relationships in a dimensional relationship set, and ordered
[10]
according to the order of this relationship .
In the DPM a hypercube is reflected in the DataCube. A DataCube is a set of DataPoints with its
appropriate Dimensions and Members.
A hypercube in the MDM is a set of pairs < dimension, attributes of dimension > and calculated attributes
[19]
defining one or more facts .
― taxonomy;
― context.
The context element contains information about the entity being described, the reporting period and
the reporting scenario, all of which are necessary for understanding a business fact captured as an
[6]
XBRL item .
In the MDM, the context is defined as a set of dimension of a fact or group of facts. A context belongs to
an entity or financial institution, for a period, a meaning for the business (segment), and a scenario. The
[9]
scenario shows the specific pairs of dimension and the dimension attribute of business logic .
7 Mapping from Data Point Model to Multidimensional Data Model
Economic-financial information in the global economy in which we find ourselves is increasingly
important. This information has semantic content and must be easy to process, quickly transmittable
and reliable. Since the late 90s some specifications for the transmission of economic information have
emerged. XBRL represents business information, which is multidimensional. Specific to the European
[25]
model is that the logical location for its storage is a Data Warehouse (DW) .
The Multidimensional Data Model (MDM) is a Conceptual Model and the Relational Model as well as the
Data Point Model (DPM) is a Logical Model. The difference is that the Conceptual Model is nearest to
the Universe of the Discourse (UD), nearest to the requirement of business user. The Logical Model is
nearest to the Physical Model, the implementation in XBRL or in a Database.
[17]
This document aims to help to design the Economic-financial information of reports . For this reason,
this set of pages is designed to help users of Information Systems create taxonomies using the DPM and
in parallel, to map to the Relational Model using the MDM through the Relational Online Analytical
Processing (ROLAP) tool.
7.1 General
This section presents the mapping between the DPM and the Relational model through ROLAP. In
this mapping the transformation from XBRL taxonomies is not handled, however its conversion is
[20]
possible. . Moreover, in this transformation no process of validation is established, only the DPM
structure is mapped into the relational model. However, it is expected that the reader of this document
can understand the DPM better when storing the DPM in a RDBMS (Relational Database Management
System) using the MDM.
The aim of this document is to obtain a star model representing the DPM. That is to say, the DPM is
mapped to the MDM in databases. Figure 2 shows the MDM of the DPM.
The constructor FactTable of the figure is equivalent to the set of data points in the DPM. It is a Star
model because BaseDomain (set of primary items), Taxonomy and Context are linked to fact tables in
three dimensions. The dimension Taxonomy is linked with the dimension Framework. The Context is
linked to the dimension Context_Dimension_DimensionAttributes. The last one is Dimension the set of
dimension/attributes of a dimension. And, to the set dimension/attributes of dimensions the dimensions
end DimensionAttributes. It is also possible to add the dimension Family to dimensions but these are not
drawn, not overcomplicating the drawing.
Figure 2 — Star model of the DPM using ROLAP tool
In section six its implementation in a RDBMS is shown, accompanied by a diagram showing this
implementation.
There are various references in the biography that deal with mapping from different sources to a
[12] [13] [15] [21]
relational database, especially from XML and about query in heterogeneous sources.
[14]
In particular the paper by Levi et al. is interesting. Nevertheless, the process of transformation of
[15]
this section is based on Taentzer et al. . This section deals with the different constructors that are
corresponding in the DPM, step by step.
In this section, the process of conversion is analysed. Normally, a first step is to study the DPM element
or elements to transform. Following this approach, the mapping between the DPM elements and the
relational elements are gathered. The transformation process in the figures show the DPM UML graph
on the left are the UML class diagrams and to the right the relational model (ROLAP) from the MDM.
The black arrows between both are UML syntax but they are customized extensions, which are used
to describe the graph transformation. The square between two black arrows contains an abbreviation
10 © ISO 2021 – All rights reserved

which is mapped. In this document the following types of mapping rules between the two graphs are
[15]
distinguished :
― A2C is the automatic transformation between attributes of the DPM and columns of a table;
― MC2T is the automatic transformation between meta class of the DPM and a table;
― NON is the transformation of a comment to the Relational Model.
7.2 Framework
Figure 3 shows the structural perspective of the
...