SEKE 2012 Proceedings - Knowledge Systems Institute

Gray et al. [2] present the problems of the standard SQL
group by operator and defines the data cube operator, which
generalizes histogram, cross-tabulation, roll-up, drill down,
and sub-total constructs. An N-dimensional cube is a set
of points, which are the aggregate of a particular set of
attribute values. And given that computing multidimensional
aggregates is the performance bottleneck for OLAP,
Agarwal et al. [3] proposed faster algorithms for computing
sets of group bys, specially the cube operator. Extending
sort-based and hash-based grouping methods with optimizations
like using pre-computed group by for computing
others group-by.
Harinarayan et al. [4] investigated the issue of which
cells from the data cube to materialize when working with
large data cubes. They used a lattice framework to express
dependencies among views, and a greedy algorithm
to determine a good set of these views to be materialized,
based on the tradeoffs between the space used and the average
time to answer a query on a proposed benchmarking
database.
The standard method for optimizing OLAP queries execution
is often precomputing some of the queries into subcubes,
and then to build indexes on theses summary tables.
Grupta et al. [5] were pioneers in proposing automation of
the selection of summary tables and its indexes with nearoptimal
algorithms. Going further, and using a logical reconstruction
of multidimensional schema design, multidimensional
forms were proposed by [6] to ensure summarizability
within the whole application schema, achieving
sparsity reduction of the underlying data cube and reasoning
about the quality of conceptual data warehouse schema.
The application of production rules in OLAP systems
have not been deeply explored, with only a few recent papers
being published. Vasilecas et al. [7] proposes a backward
chaining approach to transform production rules into
executable MDX instructions 1 , representing rules in XML
format and automating decisions and decision support according
to the internal and external influences. Prat et al. [8]
argue that multidimensional models poorly represent aggregation
knowledge, and propose production rules to better
represent this knowledge of how aggregation may be performed
on a given data cube based on the additive nature
(non-, semi-, fully-additive) of the attributes involved, and
minimizing the risk of introducing errors during aggregation,
since this errors may accumulate consequently leading
into awful analysis.
3. Foundations
The proposed method relies on using production rules to
replace query languages, anticipating the summarization of
1 MDX is a standard query language for OLAP.
data into a dimensional structure, providing a subset of all
OLAP features. OLAP was created as a database processing
solution to solve issues not tackled by relational database
systems. Production rules are a way to represent knowledge
about reasoning on data. In this section, we present
a general introduction to these two foundational concepts,
before discussing our solution.
3.1. OLAP
OLAP applications help analysts and executives to gain
insight into the performance of an enterprise through fast
access to a wide variety of data, organized to reflect the
multidimensional nature of the information [9]. However,
this type of analysis can not be done directly from operational
databases [1], given that they are prepared only for
on-line transactional process. Performing OLAP operations
requires detaching data from database, transforming, integrating
and loading it into a multidimensional one.
Multidimensional databases are used in data warehousing
to support OLAP operations and separate structural aspects
and contents. Relational database technology is better
suited for transaction management and ad hoc querying
[10]. Data warehouses maintain data from operational
databases, transformed and integrated accordingly to the
demands of analysts. The data is usually organized into
a relational model of multidimensional data, called a star
schema [11], shown in Figure 1, where tables are separated
into dimension tables, which contains identifying information
about the dimensions themselves, and a fact table, that
correlates dimension and information of interest.
Dimension Table
Dimension Table
Dimension Table
Fact Table
Dimension Table
Dimension Table
Figure 1. In the star schema dimension tables
contains identifying information about the dimensions
itself and the fact table correlates
them and informations of interest to analysts
The conversion of data from a relational database into a
multidimensional schema is not an easy task, and the procedure
normally has to be assisted by an expert in business
modeling. Some organizations opt for data marts instead,
713