Data Warehouses and the Semantic Web - Data Warehouse Systems: Design and Implementation - page 545

ns2:921 a adgeo:Country ; rdfs:label '' England '' @en ;
skos:inScheme ex:geo ; skos:narrower ns1:J .
ns1:J a adgeo:GovernmentO ceRegion ; rdfs:label '' South East '' @en ;
skos:inScheme ex:geo ; skos:narrower ns0:00mc .
ns0:00mc a adgeo:UnitaryAuthority ; rdfs:label '' The Borough of Reading '' @en ;
skos:inScheme ex:geo .
The dimension is denoted ex:Geography , and it is defined as member of the
classes qb:DimensionProperty and qb:CodedProperty . This dimension is asso-
ciated to a concept scheme ex:geo ,amemberoftheclass skos:ConceptScheme ,
using the qb:codeList property. Intuitively, this code list represents the set of
values of the dimension, organized hierarchically using the concept scheme.
The dimension member ns2:921 is defined as the top concept in ex:geo using
the property skos:hasTopConcept . It is also stated that such element is an
instance of the adgeo:Country class, labeled England . Hierarchical relation-
ships between members are stated using the skos:narrower property, from the
most general concepts down to most specific ones, namely, from adgeo:Country
through adgeo:GovernmentO ceRegion to adgeo:UnitaryAuthority .Weremark,
once more, that the hierarchical relationships are given at the instance level.
OLAP Operations over QB
In a multidimensional model, facts represent points in a multidimensional
space, where dimension coordinates are given at the lowest levels of each
participating dimension (we have seen, however, in Chaps. 4 and 5 ,thatwe
may sometimes have facts at different granularities). The QB specification
allows observations at different granularity levels to coexist in a data set,
which makes the OLAP operations dicult to implement. A solution could be
to split the original observations into different data sets, each one containing
observations at the same granularity level, which is not possible, since
aggregation levels are not modeled in QB, as we have already seen. As a
consequence, the QB vocabulary does not provide direct support for OLAP
operations. Moreover, the possibility of implementing OLAP operations over
data represented using QB has some limitations, described next.
The roll-up operation is not supported in QB because of the following.
First, rolling-up requires traversing a dimension hierarchy from a base level
up to a target level. Since dimension levels are not modeled in QB, this
navigation is not supported. Second, the relationship between level members
is modeled from the most general concept down to more specific concepts.
Finally, aggregate functions for each measure are not modeled, and these
functions are needed to implement the roll-up operation. Although in OLAP
tools, each measure is associated with an aggregation function, this is not
addressed in QB. Analogous observations apply to the drill-down operation.
Slicing is not supported in QB due to the fact that aggregate functions for
a given measure are not modeled, and these functions are required to reduce
to a single value the dimension to be dropped, as explained in Chap. 3 .