SEKE 2012 Proceedings - Knowledge Systems Institute

egories such as food, personal care, beverages, etc., and all
sales of these products have a location and a price associated.
In this context, a manager wants to know the sum of all
sales of food and beverage in the cities of Rio de Janeiro and
Sao Paulo, grouped by date. With a traditional approach,
this query must be performed over an OLAP cube where
the dimensions are category, city and date. In our system,
this whole operation can be replaced by the production rule
shown in Figure 3.
1 - production rule "Sales of food and beverages for Rio and São Paulo"
2 - when
3 - City(name == "Rio de Janeiro" or name == "São Paulo")
4 - Product(category == "food" or category == "beverage")
5 - Sale($price = price)
6 - do
7 - update_cube($price, $timestamp, $this)
Figure 3. A simple production rule for a sales
management system
In this figure, the rule are expressed in pseudocode. Line
one identify the rule to represent the cube where all measures
are stored. Lines two to five define the set of conditions
(LHS of rule) that filter only desired data to be included
into the particular cube. Specifically, line three filters
data allowing only two cities (Rio de Janeiro and Sao
Paulo), also defining city as a dimension. Line four filters
only products from categories food and beverage, also
defining the category dimension. Line five is used to temporarily
store the price of the sale into a variable ($price)
that will be used to increment data into the cube. Lines six
and seven define the set of actions (RHS of rule) where the
measures are updated using auxiliary functions (these functions
are generalized and can be used for any domain). In
line seven, the sum of prices is updated using a function
called update cube, a timestamp (the $timestamp variable)
and a reference to current rule (the $this variable).
The timestamp is used to explicitly associate the computed
measure with the time dimension, and the two
other dimensions, city and category, are defined implicitly
through the set of conditions.
Considering that this rule has filtered some data from
sales registries, computed measures are persisted as shown
in table 1.
In table 1, each rule represents a cube, the timestamp
represents the time dimension and the measure column represents
all business measures computed by the production
rules. In the sales management example, the measure column
contains the sum of prices of all sales of food and beverage
sold in the cities of Rio de Janeiro and Sao Paulo in a
specific date.
In Figure 4 a generic representation of the OLAP cube
generated for the sales management example is shown. In
this figure, all sales of food and beverage are presented as
Id Rule Measure Timestamp
1 sales example 10 2012-06-10
2 other rule 01 20 2012-06-11
3 sales example 37 2012-06-12
4 other rule 02 25 2012-06-13
Table 1. Each rule identifies a particular cube.
The timestamp represents the time dimension
and the other ones are inferred from the
LHS of the rule
one single measure because of the manner in which the
rule’s LHS was written, applying a disjunction on the product
category: measures will be updated when category is
”food” or ”beverage”. It was applied in the same manner
to cities of Rio de Janeiro and Sao Paulo, according to the
rule’s LHS shown in line three of Figure 3. Timestamp and
measures are stored together as shown in 1.
Rio de Janeiro
or Sao Paulo
Timestamp
T1
T2
T3
Food or Beverage
Figure 4. Generic representation of the OLAP
cube generated for the sales management example
4.1. Run-time engine architecture
To support our approach of dynamically building OLAP
cubes by applying production rules to enterprise data, we
developed a runtime architecture that is comprised of five
modules: connector, adapter, engine, knowledge base and
database.
The connector is integrated into the enterprise system,
and is responsible for collecting relevant data as events, that
will be passed to the adapter. The later, for instance, splits
all events into smaller unities, called facts, to be confronted
with the rules stored in the knowledge base. The engine
itself is responsible for matching the production rules with
the facts generated by the adapter. All measures computed
715