AD ALTA
JOURNAL OF INTERDISCIPLINARY RESEARCH
4. Results and Discussion
4.1 The Proposed Business Intelligence Data Warehouse Tool
based on the Business Continuity Points – Granularity and
Hierarchies
The concept of “granularity” in business intelligence data
warehouse theory appears as a “solving problem technique in
which a complex problem is subdivided into smaller components
or granules to facilitate information processing” (Yao, 2019).
Furthermore, information granularity in all the categories of
applications, acts as an element that elevates aggregate models to
higher abstraction levels and enables quantification of different
results in individual levels in order to ensure enhanced
knowledge-based and data-oriented decision support (Pedrycz et
al., 2014). In a data warehouse schema, the granularities are
illustrated via the hierarchy schema where the predetermined
level of detail according to which the dimensional data should be
analysed is represented (Fig.3). The Business Continuity Points
approach includes the following dimensions:
D1: Business Operation Level – the organizational operations for
which the recovery complexity data should be stored in order to
implement the proactive criticality ranking are classified
according to the following hierarchy levels: business function,
business process, activity and task. The task level is the lowest
level of detail (granularity) for which recovery data will be
analyzed.
Fig. 3. Dimensions and hierarchical schema of the BCPTs
business intelligence data warehouse model (speedy criticality
ranking). Source: (Source: own work).
D2: Business_Entity Type- The specific dimension is utilized for
defining the type of business entity, which might be a functional
area, a division, a sub-division, a sector, or a department. The
smallest unit size indicates the data granularity regarding the
business units involved in the recovery process of an individual
function.
D3: Impact Value Levels- this dimension refers to the recovery
time effort (RTE) value based on the classification RTO and
MAO values proposed by (Gibson, 2010). Furthermore,
information regarding the corresponding impact value levels is
included (IVL types). According to the
specific classification,
the lowest level of detail is IVL 4.
D4: Recovery_Scenario- The dimension includes the list of
possible recovery scenarios. The proposed scenarios regarding
the recovery procedure are categorized as simple, average and
complex (Podaras et al., 2016). During the speedy classification
of a business function, the scenario type can be determined by
the system, after the input of the data regarding the involved
Actors and Business Processes has been terminated (Podaras,
2018).
Facts and measures: the facts entity includes the calculated
values of the recovery parameters. The fact include measurement
regarding the total weight recovery complexity parameters
namely the UHW, UAPW, UBFW and UBFRP values after
considering the input parameters (attributes) regarding the
number of simple, average and complex actors (both human and
application level types) which participate in the execution of the
business operation, as well as the number of the involved simple,
average and complex business activities.
4.1.1 Conceptual Schema
The core elements of the classical conceptual data warehouse
schema include the dimensions as well as the single facts in the
form of entities. The highest level conceptual schema does not
include the attributes of each dimension that indicates the
hierarchies as well as the data granularity. Nevertheless, a further
detailed conceptual schema can provide information regarding
all the included attributes as well as the primary key (PK) and
foreign key (FK) semantics for both the dimensions and the
facts. The high –level (Fig. 4), as well as the detailed (Fig. 5)
conceptual models for the proposed BCPTs data warehouse, are
currently illustrated.
Fig. 4. The high-level conceptual BCPTs data warehouse model
(speedy criticality ranking) (Source: own work)
Fig. 5. The detailed conceptual BCPTs DW schema.
(Source: own work).
4.1.2 Physical schema and Web-Based System Architecture
Based on the above illustrated conceptual data warehouse
schema, a corresponding physical data model has been
developed. The physical model includes information about the
data types of each attribute as well as the length of each data
type (Fig. 6). The model was developed in MySQL (Welling &
Thomson, 2017). The developed physical data warehouse is
used as the back end repository where the business continuity
data shall be stored via a simple and user-friendly web
application. The application is developed in PHP programming
language (Welling & Thomson, 2017). The proposed BCPTs
application interface is utilized for the recovery complexity
computations. Moreover, the connection of the API and the data
warehouse is supported by HTML 5.0 and CSS technology
(Brown et al., 2014).
- 360 -