Heuristic Optimization of OLAP Queries inMultidimensionally Hierarchically Clustered

Databases*

Dimitri TheodoratosDepartment of Computer ScienceNew Jersey Institute of Technology

University Heights, Newark, NJ 07102, USA

dth @cis.njit.edu

ABSTRACTOn-Line Analytical Processing (OLAP) is a technologythat encompasses applications requiring a multidimen-sional and hierarchical view of data. OLAP applica-tions often require fast response time to complex group-ing/aggregation queries on enormous quantities of data.Commercial relational database management systemsuse mainly multiple one-dimensional indexes to processOLAP queries that restrict multiple dimensions. How-ever, in many cases, multidimensional access methodsoutperform one-dimensional indexing methods.

We present an architecture for multidimensional data-bases that are clustered with respect to multiple hi-erarchical dimensions. It is based on the star schemaand is called CSB star. Then, we focus on heuristi-cally optimizing OLAP queries over this schema usingmultidimensional access methods. Users can still formu-late their queries over a traditional star schema, whichare then rewritten by the query processor over the CSBstar. We exploit the different clustering features of theCSB star to efficiently process a class of typical OLAPqueries. We detect special cases where the constructionof an evaluation plan can be simplified and we discussimprovements of our technique.

1. INTRODUCTIONDecision support applications increasingly rely on On-

Line Analytical Processing (OLAP) to analyze businessrelated information. OLAP is a technology that encom-

Aris TsoisDept. of Electrical and Computer Engineering

National Technical University of AthensZographou 157 73, Athens, Greece

atsois@dblab.ece.ntua.gr

passes applications requiring a multidimensional view ofdata. In such a view of data there is a set of measuresthat are the metrics of interest. The measures containnumeric data. Each of them is uniquely determinedby a set of different and often independent dimensions.Dimensions have associated with them hierarchies thatspecify different aggregation levels of data and hencedifferent granularities of viewing data. Many relationalOLAP systems use the star schema [12] to representthe multidimensional data model. A multidimensionaldatabase organized as a star consists of a fact table anda table for each dimension. A dimension table comprisesattributes for each (aggregation) level of the dimensionand other (descriptive) attributes that characterize thedifferent levels of the dimension. The fact table storesattributes for each numeric measure and foreign key at-tributes to the attribute of the finest granularity levelof each dimension.

OLAP applications often require fast response timeto complex grouping/aggregation queries on enormousquantities of data. Common techniques to improve queryperformance are materializing views, and making exten-sive use of clustering and indexing methods. In multidi-mensional databases these techniques have to be adaptedin order to account for the multiple dimensions. Mate-rializing views is an efficient technique when the way tocompute a query using the materialized views is known.However, the general problem of answering and optimiz-ing grouping/aggregation queries using multiple mate-rialized views [4, 3, 201 is complex. Another difficulty ofthe view materializing technique is the optimal selectionof views to materialize [ll, 191. View selection becomeseven more complex when the query pattern is not knownin advance [13]. Lastly, this technique incurs importantadditional space requirements and intricate algorithmsfor incrementally maintaining the materialized views [9].

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.DOLAP’OI, November 9,2001, Atlanta, Georgia. USA.Copyright 2001 ACM I-58113-437-l/01/001 I . ..$5.00.

Commercial relational database management systemsuse mainly multiple one-dimensional indexes, like com-pound indexes and bitmap indexes, to process OLAPqueries that restrict multiple dimensions. The searchkey in compound indexes is a concatenation of multi-ple attributes (where the order of attributes matter).Therefore, they are useful for processing only some ofthe queries that restrict these attributes. Selecting views

*Research supported by the European Commission un-der the IST Program project EDITH: European De-velopment of Indexing Techniques for Databases withMultidimensional Hierarchies

48

and compound indexes for materialization for a givenquery set pattern is a difficult task [IO] and dependson the specific query set pattern. Bitmap indexes (andtheir variants) [16] are very popular because of theircompactness and support of star joins. Nevertheless,in many cases, multidimensional access methods (e.g.,R-tree) outperform bit-mapped indexing methods [lg].

Contribution In this paper we focus on heuristicallyoptimizing OLAP queries in databases that are clus-tered with respect to multiple hierarchical dimensionsusing multidimensional access methods. The main con-tributions are the following:

We present a multidimensional database architecturebased on the star model (called CSB star). The di-mension tables are organized using one-dimensionalhierarchical clustering and encoding techniques, whilethe fact table is organized using a multidimensionalaccess method.We show how OLAP queries can be easily expressedby the users over a traditional star schema. The CSBstar schema is intended to be a storage option only.The query processor rewrites user queries over theCSB star schema.We exploit the clustering features of the CSB starschema to efficiently process a class of typical OLAPqueries. The expensive star-join operations neededin a traditional star schema can be essentially imple-mented as mult,idimensional range restrictions on thefact table and range restrictions on the dimension ta-bles. Supplementary joins are implemented as mergejoin operations on sorted tables. Grouping operationsare performed on partially sorted relations.In this context we detect special cases where joins offact table tuples with tuples from the dimensions canbe avoided, and the grouping of the tuples can beperformed only once before all join operations.

This work is done in the context of the European ISTproject “EDITH”. In this project we use a multidimen-sional access method integrated into the kernel of adatabase management system [ 171.

Outline The next section reviews related work. Section3 introduces the basic concepts of multidimensional hi-erarchical clustering adopted here. In Section 4, thearchitecture of the multidimensional database is pre-sented. Section 5 describes the class of queries consid-ered, introduces a number of physical operators, andshows how queries in this class can be heuristically op-timized by exploiting the clustering scheme of the mul-tidimensional database architecture. Section 7 containsconcluding remarks and directions for further work.

2. RELATED WORKConventional query optimizers exploit the knowledge

about the group-by clause in a query only by includingthe grouping columns in the list of interesting ordersduring join enumeration. The group-by operation canbe pushed past one or more joins. This early groupingmay reduce the query processing cost by reducing theamount of data participating in the joins. Necessary andsufficient conditions for deciding when this transforma-tion is valid are provided in [22]. A generalization of the

early grouping transformation, the coalescing groupingtransformations allow us (a) to perform early group-bybut require additional group-by subsequently that co-alesces multiple groups and (b) to deal with the caSewhere not all the aggregating columns are present inthe node of the query evaluation plan where an earlygroup-by operator is placed [2]. Different other cases ofearly grouping and aggregation are studied and catcgo-rized in [23], along with their reverse transformations oflazy grouping and aggregation. These latter transfor-mations postpone the application of a grouping opera-tion until after a join, and may reduce the number ofinput rows to the group-by, if the join is selective. Bothdirections of transformation are considered during queryoptimization. Transformations as well as optimizationalgorithms for queries with aggregate views and queriescontaining aggregate nested subqueries are presented in[3]. The proposed pull-up transformation (the equiva-lent of lazy grouping and aggregation) makes it possi-ble to reorder relations that belong to different queryblocks so that these relations can be joined before thegroup-by operators are applied. The generalized projec-tion operator, an extension of the duplicate eliminatingprojection operator, captures the semantics of group-by,aggregation, duplicate-eliminating projection and dupli-cate preserving-projection in a common unif,ying frame-work [8]. In this framework query rewriting rules areable to push aggregation operators past selection condi-tions (and vice-versa). The pull-up transformation doesnot apply in the evaluation plans that we consider herebecause the join operations do not reduce the numberof tuples of the joining tables. In contrast, a coalesc-ing grouping transformation can be very efficiently ex-ploited: an early grouping can be pushed past all joins.It is worth noting that this is due to the architecture ofthe CSB star schema that uses hierarchical clusteringand encoding techniques, and does not apply to a tra-ditional star join schema. Related works dealing withmultidimensional access methods and multidimensionalhierarchical clustering arc cited in the next section.

3. MULTIDIMENSIONAL HIERARCHI-CAL CLUSTERING

We present in this section the basic concepts of multi-dimensional hierarchical clustering and range query pro-cessing adopted in the paper.

Multidimensional clustering and the UB-tree. Atuple of a relation in a relational database can be viewedas a point in a multidimensional space where the dimen-sions are determined by the attributes of the tuple. Inthis context, the processing of queries can be supportedby multidimensional access methods [6]. OLAP queriesoften impose restrictions on multiple attributes (dimen-sions). Multidimensional access methods are used tocluster data with respect to multiple dimensions. Multi-dimen.sional clustering can substantially speed up queriesthat restrict multiple dimensions. The main problem inthe design of multidimensional access methods is thatthere exists no total ordering among the points in themultidimensional space that preserves spatial proxim-ity. One wa,y to heuristically deal with this problem is

4 9

to discover a total order that preserves spatial proximityto some extent. This total order is called space-fillingcurve. Then, a one-dimensional access method can beused in combination with the space-filling curve to im-prove the access of the points in the space. Such asolution to the problem is provided by the U&tree [l].

Range queries on UB-trees and the Tetris algo-rithm. A query that restricts all attributes (dimen-sions) to an interval is called range query. The multidi-mensional interval determined by the one-dimensionalintervals is called query box. In order to answer a rangequery, [I] presents an algorithm for UB-trees that fetchesfrom the disk only those regions (pages) that properlyintersect the query box. The Tetris algorithm [15] is ageneralization of the multidimensional range query algo-rithm that efficiently combines sort operations with theevaluation of multi-attribute restrictions. The Tetris al-gorithm takes as input an attribute of a relation and aquery box determined by the restrictions of a query onthe relation, and returns the tuples of the relation sat-isfying the restrictions, ordered on the input attribute.Compared to the access methods of commercial systemsfor queries in the TPC-D benchmark [21], the Tetris al-gorithm shows significant speedups, important tempo-rary storage requirement reduction for the sorting pro-cess, and multiple times faster production of the firstresults of a sort operation [15].

Dimension hierarchies. A dimension hierarchy Dof depth Ic is a l ist L”, , L’ of k: names which arecalled &men&on or hierarchy levels. With every levelL in D, a non-empty finite set of values dam(L) is as-sociated through the function dom such that dom(L”) f~dom(L,j) = 0, i # j. In each dimension, we additionallyassume an auxiliary level L”+’ whose domain containsthe single value all. For every two levels Li, Lif’ , i E[l, k], a function parent from dom(Li) onto dom(Li+‘)is defined. For every two levels Li+’ , Li, i E [I, k],a function children from dom(L;+‘) to the power setof dom(L”) is defined: children(v) is the set of values‘u’ in dom(Li) such that pare,nt(w’) = w. Clear ly , i f‘u,u’ E dom(Li), i > 1, and w # w’, children(w) # 0, andchiZdren(w)nchildren(w’) = 0. A value in dom(Li), i >1, represents a set of values in dom(Li) through thefunction children. Level L’ (the lowest level in the hi-erarchy of dimension D) corresponds to the smallest(finest) granularity of viewing data. Level L”+’ (thetop level in the hierarchy of dimension D) correspondsto the largest granularity of viewing data. A dimensionhierarchy defines a hierarchy tree: the nodes of the treearc the values in l-l,“=‘,’ dom(L”), while the edges are de-termined by the parent function. The leaf nodes of thetree are the values in dom(Ll). The root node is theunique value of dom(L’“+l). The path of a node (value)7~’ E dom(Li), i E [l,k], is defined to be the concate-nation of the nodes nlC, nk-‘, , a2 on the path in ahierarchy tree from the root node to ni.

Hierarchy clustering and encoding. OLAP queriesimpose restrictions on different levels of the dimensionhierarchies. Hierarchy clustering and encoding [24, 141in combination with multidimensional access methodscan be used to speed up these queries and to optimize

the storage usage.In order to take into account dimension hierarchies

in the clustering of data, instead of the values 11 of thelowest level of a dimension, their path p in the hierarchytree of the dimension is considered. The concatenatedvalues can be shortened using the following encodingschema which is quite similar to that of [14]. Let w bea value in the domain of level Li, i E 11, ICI. Let alsow’ be the parent of w in the hierarchy tree, V be thecardinality of chiZdren(w’), and <Q be the “less than”comparison operator of the query language. We definea one-to-one function S : chiZdren(w’) + [0, V - 11 suchthat : for every U,U’ E chiZdre,n(v’), u < Q ,u’ impliesS(u) < S(u’). S(w) is called the surrogate of w. Notethat if <Q is not defined in the query language for thevalues in dom(Li), S is simply defined as a one-to-onefunction from childTen onto [0, V - 11.

Let w be a value in Ufzl dom(L”). Then, the com-pound surrogate o,f w, C(w), is the path of w where theconcatenated values are replaced by their surrogates.One way to compactly store compound surrogates is asfixed length strings of bits: for each level Li, i E [l, k],in the hierarchy, the maximum surrogate z is definedas maz{V ] V is the cardinality of children(w) ando E dom(L”-l)}. Then, at least [log,x] b i ts are re-served in the binary representation of the compoundsurrogate for the surrogates of level Li. The total num-ber of bits reserved for a level Li is called spread of Li.

4. THE CSB STAR SCHEMAWe present in this section the architecture of our mul-

tidimensional database. The schema of the multidimen-sional database is a star with one fact table F and di-mension tables D1 , , D,.

The dimension tables. The schema of a dimensiontable Di corresponding to a dimension hierarchy Di ofdepth lci consists of:(4

(b)

(cl

A set Hi of hierarchy attributes {Hi’, H,“, . , Hzki}that correspond one-to-one to the ti levels of thedimension hierarchy; H,’ corresponds to the lowestlevel in the hierarchy and H7h” to the highest.A set F; of feature attributes that provide descrip-tive characterizations of the different levels of thedimension. A feature attribute F,” characterizes thehierarchy attribute H,“. Feature attributes are op-tional in the schema of a dimension table.A compound surrogate attribute C;.

If t is a tuple in,table D+ t[Hj] E dom(Hj), j E [l, /?<I,and parent(t[Hi]) = t[Hi+‘], j E [I, k; - I]. t[C;] is thecompound surrogate of t[Hi].

By the definition of the compound surrogate of avalue, it is clear that a point restriction on a hierar-chy attribute of a dimension table can be expressed asa single range restriction on the compound attribute ofthis dimension table.

The compound surrogate attribute C; is the primarykey of the dimension table Di. By the definition of adimension hierarchy, H,’ is also a key of table Di, andthe following functional dependencies bctwcen hierar-chy attributes hold on D; : Hi -+ H,3+‘, j E [l,k; -

50

11. Furthermore, the following functional dependenciesbetween hierarchy and features attributes hold on D;:Hi -+ F:, i E [l,lci], where F%T is a feature attributecharacterizing the hierarchy attribute Hi.

We associate with a dimension table a primary in-dex Pi on Ci, and a secondary (compound) index 1i onH,+<, , H,!, Ci. Index 1, is important for computingranges of values on Ci from point or range restrictionson the different hierarchy attributes of Di.

Since the tuples of D; are clustered on C;, range re-strictions on C; can be computed efficiently. This clus-tering provides also a grouping of the tuples of the di-mension table with respect to any hierarchy attribute.This property is particularly useful for evaluating group-ing/aggregation queries as those that are extensivelyused in OLAP applications.

The fact table. The schema of the fact table F con-sists of:(a) The compound surrogate attributes Cl, , C,, one

for each dimension table D;, i E [l, n].(15) A set of measure attributes M = {MI,. , Ms}.The set of attributes Cl,. , C, is the primary key ofF. Each Ci in F is a foreign key and refers to attributeC, of the dimension table Di. In general, a fact tablecontains a huge number of tuples. In a traditional starschema, the lower level hierarchy attributes are storedas foreign keys in the fact table. Instead, by storingthe compound surrogate attributes as foreign keys inthe fact table, we importantly reduce its size. Table Fis organized as a UB-tree on the attributes Cl,. , C,.The schema of our multidimensional database is calledCompound Surrogate Based star schema (CSB star forshort).

User View. The clustering scheme of the CSB starschema is intended to be a storage option only, withoutaffecting the formulation of queries by the user. Userqueries are easily formulated on a simple star schema(called user star schema) as this is defined by the viewFT for the fact table, and the views DTI, . , DT, forthe n dimension tables:

CREATE VIEW FT ASS E L E C T H;,...,H,I,MFROM F, DI, , D,WHERE F.Cl = D,.Cl, . . . . F.C, = D,,.C,

CREATE VIEW DT, ASS E L E C T Hi,FiFROM Di

Clearly, the views FT and DTl, . , DT, form a typ-ical star schema. User queries formulated on the userschema are rewritten by the query processor over the ta-bles F and Dl, . , D, by replacing the views by theirview definitions. In the following we consider queriesthat are rewritten over the CSB star schema.

5. OPTIMIZING OLAP QUERIESWe show in this section how to heuristically optimize

OLAP queries by exploiting the clustering scheme andthe access methods of the multidimensional databasearchitecture.

5.1 The class of queries consideredWe consider OLAP queries of the form shown below.

Typical cases of OLAP operations can be expressed bythis SQL query.

S E L E C T X, AFROM F, DI, . . . . DnWHERE cJ AND cH AND cFGROUP BY GHAVING 2ORDER BY 0

X is a set of hierarchy and/or feature attributes (calledprojected grouping attributes). A is a set of aggregatedmeasures (aggregate functions on measure attributes).Using the catergorization of aggregate functions intro-duced in [7], we focus on distributive SQL aggregatefunctions: min, max, sum, count. G is a set of hi-erarchy and/or feature attributes (called grouping ad-tributes). cJ is a conjunction of equi-joining conditionson the compound surrogates. cH is a conjunction ofcomparisons involving exclusively hierarchy attributes.cF is a conjunction of comparisons involving exclusivelyfeature attributes; c” is a conjunction of comparisonsinvolving exclusively aggregated measures from A. 0is a list of attributes from X U A. The joining condi-tions are of the form F.Ci = Di.Ci. The comparisonsinvolving an attribute A are of the form A 0 c where 0is one of the comparison operators <, 5, =, 2, >, andc is a constant value.

We assume that at least one hierarchy attribute fromeach dimension is involved in a comparison in the WHEREclause of the query. We also assume that if comparisonsof the form Ri B c, where B E {<, 5, 2, >) appear inthe WHERE clause of a query, then the parent functionof the dimension hierarchy Di is mon.otone. A parentfunction is monotone if for every w, Y’ E dom(H~), j =1,. . , Ic;, if v 5 w’ then parent(w) 5 parent( Thisassumption guarantees that a range restriction on a hi-erarchy attribute of a dimension table can be expressedas a single range restriction on the compound surrogateof the table. In this section we consider queries whosehierarchy and feature attribute restrictions can be ex-pressed as a multidimensional range restriction on thecompound surrogate attributes of all the dimensions ta-bles (i.e., a single query box).

5.2 Physical operatorsIn order to construct an OLAP query evaluation plan,

we use a number of physical operators that are presentedbelow. Some of them are the traditional relational op-erators and the others are specific to the organizationof the multidimensional database.

By abuse of notation, we view a compound surro-gate attribute C; as a composite attribute consisting ofsurrogate attributes Sk;, , St. If t is a tuple in thedimension table Di, t[S’i],j E [l, .&I, is the binary rep-resentation of the surrogate of t[Hj] (t[Si] = S(t[Hj])).t[S:] is part of t[Ci] and its length in bits is equal to thespread of attribute Hi.

We denote by Px the projection with duplicate reten-tion operator on the set of attributes X, and by IIx the

set-theoretic projection operator (SELECT DISTINCT) onX. cc denotes the selection operator with selection con-dition c. S[Y] denotes the sorting operator on the listof attributes Y. WY denotes the natural join operatoron the list of attributes Y. The natural join operatoris applied on tables that are sorted on the list of at-tributes Y and is implemented as merge join. rx,~denotes the generalized projection operator [8] (group-ing/aggregation operator), where X is a set of groupingattributes and A is a set of aggregate functions on mea-sure attributes.

The T&is operator, denoted T[[Zl, ~11,. , [Zn, u,.]; C;],i E [l, n], can be applied to the fact table and representsthe Tetris algorithm. [Zj, uJ], j E [l, n], is a range of val-ues for the compound surrogate attribute C,i, and Ci isthe compound surrogate attribute on which the result-ing table is ordered (refer to Section 3). The schema ofthe resulting table is that of the fact table.

The Range operator, denoted R[cr ; B] can be appliedto the compound index 1; of a dimension table Di. c?is a condition of the type described in Subsection 5.1,and involves hierarchy attributes of dimension table Di.B is a boolean variable that takes values ‘1’ and ‘0’.R[cH; 0] on 1, returns a range of values [I;, ui] on C;such that restricting C, of Di in this range is equivalentto applying the restrict ion C: to D;. R[cP; I] on 1 %returns, besides [Z;,u;], a table T. The schema of T isH,““,... , H,! , C,i and its content is the set of tuples t overH;“,... , H,‘, C,i in 1, such that 1 ; 2 t[Ci] < 1~i.

5.3 Construction of the evaluation planWe show now how to optimize OLAP queries of the

type presented in Subsection 5.1. Our approach is heuris-tic and is not based on a specific cost model. For easeof presentation we use an example query that is generalenough to encompass different optimization cases, andwe show how our technique can be applied to producean evaluation plan.

EXAMPLE 5.1. We consider the following query de-fined over a four dimensional schema.

S E L E C T Ff, Hi, Hz, F;, s u m ( M )FROM F, DI, Dz, Ds, D4WHERE F.C1 = Dl.Cl AND F.Cz = Dz.Ca AND

F.Cz = D3.c~ AND F.C4 = D4.C4 ANDcf AND c;’ AND c3” AND cf AND cc

GROUP BY F;?, Hi, Hi, F:HAVING c”ORDER BY Hi, H; 0

A query evaluation plan for this query that takes ad-vantage of our multidimensional database architectureis shown in Figure 1. The expensive star-join operationsrequired in a traditional star schema are here essentiallyimplemented by a multidimensional range restriction onthe fact table [14]. The presence of the compound sur-rogate attributes in the fact table allows for an earlygrouping and aggregation operation. This operation isfacilitated by the fact that the selected fact table tuplesare retrieved sorted on a compound surrogate attribute.The evaluation plan comprises two kinds of nodes: op-eration nodes representing operations, and data nodes

representing input data, and intermediate and final re-sults. An operation node is depicted by a small circleand is labeled by the operation(s) it represents. Someoperations may be pipelined in which case the corre-sponding temporary results are not actually stored onthe disk. The fact table and the dimension tables are de-picted by bigger circles, the compound indexes by rect-angles, and the ranges of computed compound surrogateattribute values by triangles. Before discussing, in thefollowing, the different steps of the evaluation plan, weprovide some definitions.

DEFINITION 5.1. A (hierarchy or feature) attribute iscalled restricted attribute if it is involved in a selectioncondition (c” or c”) in the query.

An attribute is called imported attribute if it is a pro-jected grouping hierarchy attribute or a grouping fea-ture attribute in the query. A dimension containingimported attributes is called joini,ng dimesnsion. 0

An imported attribute needs to be added to selected facttable tuples. A grouping hierarchy attribute that is notprojected in the query need not be added to the facttable tuples since the compound surrogate attributescan be used for performing the grouping operation. Foreach joining dimension, a join operation is needed inorder to add the imported attributes of the dimensionto selected fact table tuples.

DEFINITION 5.2. A joining dimension D; is called can-didate East joining dimension if one of the following twoconditions hold:

(a) The first attribute in the list of sorting attributesin the query (the list 0 of attributes in the ORDERBY clause of the query) is a hierarchy attribute ofDi.

(b) The first attribute in the list of sorting attributesin the query is not a hierarchy attribute (or there isno such a list), there is a grouping feature attributein the query, and there is a grouping hierarchy at-tribute of Di in the query. 0

Selecting the dimension involved in the last join oper-ation to be a candidate last joining dimension simplifythe final grouping and sorting operations.

Computing ranges of compound surrogate valuesThe first step in the construction of the query evaluationplan is the application of the Range operator n[cy; B]to the compound index 1, of each dimension. R[cF; B]computes the lower and the upper bound of the rangeof values [Zi,2~;] of the compound surrogate using thecomparisons in c? and the compound index 1,. Therange [Z;,u,] is always provided as input to the Tetrisoperator. It can also be used for a selection operationon the dimension table Di. If only hierarchy (and nofeature) attributes from a dimension arc involved in aquery, then their values can be obtained directly fromthe compound index 1,) without accessing the dimensiontable Di. In this case the parameter J3 of R[cy ; B] is setto ‘1’. In general the application of the range operatorfollows the rules below:

(a) If there is no imported attribute or restricted fea-ture attribute of the dimension in the query then

52

(b)

(cl

B is set to ‘0’ and the computed range is used onlyby the Tetris operator.If the imported attributes of the dimension are onlyhierarchy attributes and there is no restricted fea-ture attribute of the dimension in the query then13 is set to ‘1’. The computed range is providedto the Tetris algorithm only, while the set of tu-ples retrieved from 1, are used in a subsequent joinoperation.If the imported attributes of the dimension includea feature attribute or there is a restricted featureattribute of the dimension in the query then B isset to ‘0’. The computed range is provided both tothe Tetris algorithm and to a selection operationon the corresponding dimension table.

Restricting the dimension tables If the importedattributes of the dimension include a feature attributeor there is a restricted feature attribute of the dimen-sion in the query, the dimension table needs to be ac-cessed. The primary index on the compound surrogateattribute C; of the dimension is used to retrieve the tu-ples of the dimension table that fall within the rangeof values computed by the range operator. Those ofthese tuples that satisfy the condition $ are retainedprojected over an appropriate set of attributes. If thiscomputation returns an empty set of tuples, the wholeprocessing of the query is ended since the answer is anempty set. Otherwise, the computed tuples are subse-quently joined with tuples derived from the fact table.The set S of attributes of Di to be projected are deter-mined as follows:(a) S includes all the imported attributes of D;, and(b) Prom the surrogate attributes Sf’, , S,’ of the

compound surrogate Ci, S includes the surrogateattributes S,“;, , Si, where j is the minimal levelof the imported attributes of D;.

If the minimal level j is high enough in the dimension hi-erarchy this duplicate elimination projection is expectedto significantly reduce the number of selected tuples.

It is important to note that the tuples from the di-mension table are retrieved sorted on the compound sur-rogate attribute C;. Since Ci is the concatenation of thesurrogate attributes Sf;, . , S!, these tuples are alsosorted with respect to the list of surrogate attributesSfi,. , S’s, As a consequence, the elimination of du-plicates required for the projection operation can be per-formed without extra cost. Furthermore, the sort orderof the output tuplcs can be exploited in a subsequentmerge join operation with tuples derived from the facttable.

Multidimensional range selection and sorting TheTctris operator takes the ranges of values on the com-pound surrogate attribute computed in the first step,and retrieves from the fact table the qualifying tuplessorted on a compound surrogate attribute Cf. In gen-eral, the choice of the sorting attribute Ci does not affectthe performance of the Tetris operator. We assume thatthe cache memory requirements of the Tetris algorithmarc satisfied by the available main memory [15]. Thesorting attribute Ci for the Tetris algorithm is chosenfrom a dimension according to the following rules:

(a) Ci is chosen from a joining dimension that is not acandidate last joining dimension.

(b) If C; cannot be chosen by the rule (a), it is chosenfrom a joining dimension.

(c) If Ci cannot be chosen by rules (a) or (b), it is cho-sen from a dimension that has a hierarchy attributeinvolved as a grouping attribute in the query.

(d) If C; cannot be chosen by the previous rules, it ischosen arbitrarily.

Processing of the selected fact table tuples Thepresence of the compound surrogate attributes Cl,. , C,in the fact table, allows for an early grouping and aggre-gation of the fact table tuples resulting by the Tetris al-gorithm [5]. This operation can be performed efficientlydue to the fact that the tuples resulting by the Tetrisoperation are already sorted (and thus grouped) withrespect to one compound surrogate attribute Ci, i E[l, n]. The set of attributes on which the grouping is per-formed comprises the surrogate attributes Sk’, , S’lfrom each dimension D; that contains a grouping at-tribute in the query. j is the minimal level of the (hi-erarchy and feature) grouping attributes of Di in thequery. Usually, in OLAP applications, a fact table con-tains a huge number of tuples which are grouped to pro-duce a small number of aggregated results. Therefore,this early grouping operation is expected to drasticallyreduce the number of fact table tuples at an early stageof their processing.

If there is no grouping feature attribute in the querythen the final grouping and aggregation operation thatwill be presented in the next step is not needed. Thereason is that the compound surrogate attributes havealready be used instead, for grouping on hierarchy at-tributes. In this case the selection operation on theaggregated measures (~,a) can follow immediately af-ter the early grouping operation to further reduce thenumber of aggregated fact table tuples that are left tobe processed.

If there is at least one joining dimension, one of themhas provided its compound surrogate attribute as a sort-ing attribute to the Tetris operator. In this case, theaggregated tuples are equi-joined on the common at-tributes with the selected tuples of this dimension. Sinceboth sets of tuples are sorted on their common attributes,a merge join algorithm can be efficiently applied. Eachaggregated tuple joins with exactly one tuple from thedimension table. This operation does not alter the num-ber of tuples resulting by the grouping/aggregation op-eration. It does add to these tuples the imported at-tributes of the joining dimension. Grouping hierarchyattributes of the dimension table that are not projectedgrouping attributes in the query are not needed sincethe fact, table tuples have already been grouped usingthe surrogate attributes.

A similar operation is performed on the resulting tu-ples for each other joining dimension. This operationhas to be preceded by a sort operation with respect tothe joining attributes, and by a project operation thateliminates the attributes not needed in subsequent op-erations. The sort operation has to be performed onlyon the tuples resulting from the fact table since the di-

5 3

mension tuples are already sorted with respect to thejoining attributes. The order of the join operations doesnot significantly matter. The only rule that has to berespected is to choose a candidate last joining dimensionfor the final join operation. This way the sort order ofthe resulting tuples can be exploited in the subsequentoperations.

Final grouping/aggregation and sorting In the laststep of the evaluation plan the tuples resulting by thelast join operation are grouped and aggregated. Theaggregated tuples that satisfy the condition cA on ag-gregated measures are retained projected over the at-tributes required in the output. As mentioned previ-ousl,y, these operations can be avoided when there is nogrouping feature attribute in the query. If the outputtuples are required sorted, a final sorting operation isalso performed. These operations exploit the sort orderof the tuples resulting from the previous step.

6. CONCLUSIONOLAP applications view data structured in multiple

hierarchically organized dimensions. Complex group-ing/aggregation queries for OLAP applications processenormous quantities of data and require fast responsetime. Recent research suggests that multidimensionalaccess methods outperform one-dimensional indexingtechniques.

We have presented the CSB star, an architecture fora multidimensional database that is based on the starschema. This architecture uses one-dimensional hier-archical clustering and encoding techniques to organizethe dimension tables and multidimensional access meth-ods to organize the fact table. Users can express theirqueries over a traditional star schema, which are thenrewritten by the query processor over a CSB star schema.We have shown how the features of this schema allowthe heuristic optimization of a class of typical OLAPqueries: expensive star-join operations are essentiallyreduced to multidimensional and one-dimensional rangerestrictions, supplementary joins are implemented asmerge join operation on sorted tables, and grouping op-erations are performed on partially sorted data. Wehave detected special cases where supplementary joinsare avoided, and a grouping operation can be pushedpast all join operations.

An interesting extension of the present work concernsconsidering a larger class of queries. In particular relax-ing a number of the restrictions adopted here can resultin queries that determine multiple query boxes on thecompound surrogate attributes. Our results apply tothis case too by considering the different query boxesseparately. However, a cost based optimization tech-nique that considers different groupings of these queryboxes is expected to provide further improvements.

7.PI

PI

REFERENCESR. Bayer. The Universal B-Tree for MultidimensionalIndexing: General Concepts. In Proc. of the Intl. Con,f.on World- Wide Computing and its Applications,Springer, LNCS 1274, pages 98-112, 1997.S. Chaudhuri and K. Shim. Including Group-By inQuery Optimization. In Proc. of the 20th Intl. Conf.on Very Large Data Bases, pages 354.-366, 1994.

[31

[41

[51

PI

[71

Nl

PI

1101

PII

[I21

[I31

P41

P51

WI

P71

PI

PI

PO1

WI

PI

[231

P41

S. Chaudhuri and K. Shim. Optimizing Queries withAggregate Views. In Proc. of the 5th I&l. Conf. onExtending Database Technology, pages 167-1.82, 1996.S. Dar, H. V. Jagadish, A. Y. Levy, and D. Srivastava.Answering SQL Queries with Aggregation using Views.In Proc. of the 22nd Intl. Conf. on Very Large DataBases, pages 318-329, 1996.K. Elhardt. EDITH query processing. Technicalreport, Transaction Software, Jan 2001.V. Gaede and 0. Giinther. Mult,idimensional AccessMethods. ACM Computing Surveys, 30(2), 1997.J. Gray, A. Bosworth, A. Layman, and 1-I. Pirahesh.Data Cube: A Relational Aggregation OperatorGeneralizing Group-By, Cross-Tab, and Sub-Totals. InProc. of the 12th ICDE, 1996.A. Gupta, V. Harinarayan, and D. Quass.Aggregate-Query Processing in Data WarehousingEnvironments. In Proc. of the Zlst Intl. Conf. on VeryLarge Data Bases, pages 358-369, 1995.A. Gupta and I. S. Mumick. Maintenance ofmaterialized views: Problems, techniques andapplications. Data Engineermg, 18(2):3-18, 1995.H. Gupta, V. Harinarayan, A. Rajaraman, and .J. D.Ullman. Index Selection for OLAP. In Proc. of the 13thIntl. Conf. on Data Engmeering, pages 20%il9, 1997.V. Harinarayan, A. Rajaraman, and J. D. 1Jllman.Implementing Data Cubes Efficientlv. In Proc. of theACM SIGMSD Intl. Co@., 1996. ”R. Kimball. The Data Warehouse Toolkit. John Wiley& Sons, 1996.Y. Kotidis and N. Roussopoulos. DvnaMat: ADynamic View Management System for DataWarehouses. In Proc. of the ACM SIGMOD I&l.Conf. on Management if Data, pages 371-382, 1999.V. Markl, F. Ramsak, and R. Bayer. Improving OLAPPerformance by Multidimensional HierarchicalClustering. In Proc. of the Intl. Database Engineeyingand Applicat%ons Symposium, pages 165-177, 1999.V. Markl, M. Zirkel, and R. Bayer. ProcessingOperations with Restrictions in RDBMS withoutExternal Sorting: The Tetris Algorithm. In Proc. ofthe 15th Intl. Conf. on Data Engineering, pages562~571, 1999.P. O’Neil and D. Quass. Improved Query Performancewith Variant Indexes. In Proc. of the ACM SIGMODI&l. Conf., pages 38-49, 1997.F. Ramsak, V. Markl, R. Fenk, M. Zirkel, K. Elhardt,and R. Bayer. Intergating the UH-Tree into aDatabase System Kernel. In Proc. of the 26st I&l.Conf. on Very Large Data Bases, pages 263.-272, 2000.S. Sarawagi. Indexing OLAP Dat,a. Data Engmeering,20(1):36-43, 1997.U. Theodoratos and T. Sellis. Data WarehouseConfiguration. In Proc. of the 23rd Intl. Conf. on VeryLarge Data Bases, pages 126-135, 1997.D. Theodoratos and T. Sellis. Answering Queries onCubes Using Other Cubes. In Proc. of the I&l.Conference on Scientific and Statistical Databases,pages 109-122, 2000.TPC benchmark D. Technical report, TransactionProcessing Performance council, 1997.W. Yan and P.-A. Larson. Performing Group-Bybefore Join. In Proc. of the 10th Intl. Conf. on DataEngineering, pages 89-100, 1994.W. Yan and P.-A. Larson. Eager Aggregation andLazy Aggregation. In Proc. of th,e 21st Intl. Conf. onVery Large Data Bases, pages 1 -13, 3995.C. Zou, B. Salzberg, and R. Ladin. Back to the future:Dynamic hierarchical clustering. In Proc. of the 14thIntl. Conf. on Data Engineering, pages 578-587, 1998.

5 4

. . . . . .:: ::: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

D411 Dl I2 D2 13

Figure 1: A query evaluation plan

55