Download D6.32 - bivee

4.4.1 Introduction
In KPIOnto, KPI definitions are instances of the Indicator ontology class. The other semantic
concepts of relevance are the Dimension class and its sub-classes. These, together with their
concrete instances (i.e., dimension members), represent a standardized, machine-readable
model of the real world from which KPI data originates. Using this model as KPI meta-data, it is
then possible to achieve a unified view of KPIs, regardless of their original source and
structure. For instance, a KPI may be defined in KPIOnto as supporting OrganizationDimension
(see Figure 18), which means that each single KPI value collected by the BIVEE system will have
meta-data attached describing how that value relates with standard BIVEE entities like
Enterprise, Department, ProjectTeam, etc.
Figure 18 - Example of Dimension in KPIOnto
This use of meta-data is an example of semantic annotation. In the RDH context it is
implemented by storing KPI data collected from heterogeneous systems in ad-hoc structures,
which can be easily matched back with concepts of the reference ontology. This responsibility
is on the Data Storage sub-module: RDH-DS.
4.4.2 RDH-DS
The RDH-DS sub-module is a relational database management system (RDBMS) with a specific
schema in which KPI data is stored. This data schema is actually auto-generated by the RDHSync utility (see section 0) using KPIOnto as a blueprint, so that historical KPI data are kept in
normalized form – that is, in a relational format that is highly compatible with the logical
structure modelled by KPIOnto. The main value of data normalization is that application
queries, expressed in KPIOnto terms, can be then translated by the Semantic Data Handler into
equivalent RDH-DS queries (SQL) which will perform very fast.
Basically, KPIOnto classes derived from the Dimension class are translated into domain tables
(see Figure 19), and are populated with records corresponding to concrete instances (see
Figure 20); each Indicator instance becomes a fact table by its own, connected with the
relevant domains (see Figure 21). The resulting schema is described in the RDH-DS Catalogue,
and from there entities can be easily mapped back to KPIOnto concepts (see Figure 22).
The RDH-DS sub-module is a private back-end component, in that its functionality is made
available externally (i.e., to applications which are not integrated into the BIVEE Environment)
only by means of another module: RDH-WS, implementing the RDH web API layer (see section
Page 29 of 76