An Object Oriented Approach to Multidimensional Database Conceptual Modeling (OOMD)

Multidimensional Database Conceptual Modeling (OOMD)

Trujillo, J.*, Palomar, M.**

Grupo de Programación Lógica y Sistemas de Información

*Dpto. Economía Financiera

**Dpto. Lenguajes y Sistemas InformáticosUniversidad de Alicante. E-03071. Alicante. Spain.

Email: * {juan.trujillo@ua.es}, ** {mpalomar@dlsi.ua.es}

Abstract. In the recent past, there has been an increasinginterest in multidimensional databases (MDB) and On-lineAnalytical Processing (OLAP) scenarios. Severalmultidimensional models have been proposed in the lastdays. However, very few works have been focused on thearea of multidimensional database conceptual modeling.Moreover, they are either conceptual extensions to theclassical multidimensional model or translations fromclassical database conceptual models (such as the Entity-Relationship model). Nevertheless, we take the conceptsand basic ideas of the classical multidimensional model(dimensions and facts) to propose a revolutionary approachbased on the Object Oriented (OO) Paradigm to MDBconceptual modeling. Then, the basic elements of ourObject Oriented Multidimensional Model (OOMD) such asdimension classes and fact classes are introduced. We thenpresent cube classes as the basic structure to allow asubsequent analysis of the data stored in the system. Wefairly believe that the utilization of the OO Paradigm willprovide us a general conceptual model to MDB conceptualmodeling in a more flexible, natural and simple way thanthe models proposed until now.

(dimensions) that are considered relevant to the analysis. Wewill introduce a simple example to handle these concepts inthe following section.

Traditional database systems are inappropriate formultidimensional analysis since they are optimized for On-line Transactional Processing (OLTP) in which an enormousnumber of concurrent transactions containing normally fewrecords are involved. Nevertheless, OLAP techniques executefew complex queries involving a huge number of records.Current technology provides both OLAP servers and userfinal tools for the development of MDB. With reference to theOLAP servers we can find either relational systems (ROLAP)or multidimensional systems (MOLAP). A ROLAP system isan extended relational system that maps operations on themultidimensional data to standard relational operations(SQL). On the other hand, the MOLAP systems store andmanipulate data directly in special structures calledmultidimensional arrays.

Modeling Multidimensional Databases (related work)

In both systems, MDB are modeled depending strictly on thecorresponding implementation (ROLAP or MOLAPsystems). Some problems emerge from this form ofproceeding. Firstly, it does not exist a general conceptualmodel (independent of subsequent implementation details) toMDB conceptual modeling and valid for a subsequentimplementation in any system. Secondly, the requirementsposed for a subsequent data analysis need take intoconsideration tedious details of the data physical organizationmore than of its logical aspects (as also argued in [4]). Weconsider that these and other subsequent problems will besolved with the proposal of a general conceptual modelindependent of any subsequent implementation details.Furthermore, we fairly believe that the application of the OOParadigm will provide us a general conceptual model with thetotal independence from physical aspects (as previouslycommented) to MDB conceptual modeling in a more naturaland simple manner than the models proposed until now.The traditional model used for MDB modeling is the known“star model” ([2], [11] and [12]) and its variants(“snowflake”, “fact constellation” and so on), mainly if asubsequent implementation is carried out in a ROLAPsystem. This model consists of two kinds of relational tables,dimensional tables and fact tables. The previous ones containcharacteristics of the factual data and the latter ones containthe factual data itself (whose values are represented in someattributes called measures or fact attributes). Data contained

1 Introduction

Companies can adopt strategic decisions that may supposea competitive advantage with respect to their competitors.In this context, the concept of Data Warehouses (DW)emerges in the decade of the ninety ([11], [12]) as anintegrated data collection of the company oriented todecision making. The success of these DW is not onlydemonstrated by the amount of commercial products thathave been emerging lately ([2], [18], [19]), but also in theproliferation of research projects and topics ([14], [21], [10]and [20]). A more detailed on-line bibliography focused onDW and OLAP technology can be found in [17].

However, the analysis of this historical data (DW) is carriedout through user final tools that are based on OLAPtechnologies [6]. The storage structures (derived from theDW) used by these techniques are known with the name ofhipercubes or multidimensional fact tables. These structuresare suitable for this purpose since they represent in anintuitive way the factual data according to the characteristics

in dimensional tables present different levels of granularity inmost cases, which is not taken into account in the model dueto the fact that it only considers relational tables. We believethat this model is not suitable for MDB conceptual modelingin the sense that it refers to relational tables while the MDBmodeling is being accomplished. However, our OOMDapproach defines abstract objects without any reference totables or their subsequent implementation. Furthermore, wedefine the cube as other collection of abstract objects onwhich a group of operations (defined/permitted on it) arecarried out to allow a subsequent analysis of the datacontained in it. Moreover, a special relation is applied to theseobjects to express the granularity of data in the conceptualmodel.

To our best knowledge, only three works focused on theconceptual design of MDB have been presented until now. In[7], the conceptual design is outlined from the schemesprovided by the ER model of the company OLTP systems.Nevertheless, the nature of DW makes necessary, in mostcases, to include data that is not in the original OLTP systemsand therefore, it does not exist in the ER schemes. Moreover,in this approach, entities and relations of these schemes; i.e. only data is takenfacts and dimensions are defined from theinto account. However, our approach provides a higher levelof abstraction since not only are the data static properties(data itself) considered, but also the dynamic ones (operationsto be applied on data). Furthermore, we can find severalreferences such as [13] that consider the ER modelinappropriate for DW conceptual modeling.

Another proposal ([4]) extends a multidimensional model(MD) proposed in [3] in which a declaratory query languageand the research of its expressiveness were mainly introduced.This extension of the MD defines a schema of MDB as aschema of fact tables to provide a general designmethodology for MDB. This MD considers all the necessaryconcepts for the conceptual design of MDB. However, weconsider that not only does it use the concept of tables in theconceptual design phase, but it is also closed to the classicalrelational model (with the normal extensions to allow thedefinition and subsequent multidimensional data analysis).We fairly believe in a more revolutionary proposal and ahigher level of abstraction in the design phase. According tothis, our OODM considers abstract objects and we do not takeany assumption neither about the logical model to be used norfact tables. Moreover, this higher level of abstraction willallow us to define a dynamic properties will be taken into account. As acube class in which both static andconsequence, we will achieve a more restrictive way on asubsequent data analysis phase.

In [15] we find the first OO approximation for the design ofMDB in the proposed Nested Multidimensional Data Model,which is a conceptual extension to the classicalmultidimensional model to allow us to model complex OLAPscenarios. It introduces the concept of multidimensionalobject to define the multidimensional cube in which a groupof operations are defined on it to permit a subsequent dataanalysis. This cube consists of attributes (for a previous classification of the dimensional and classificationattributesdimensionalconsiders ) to express data features. Our approach onlyrelation (ARR) is defined. We consider that this relation can

dimension attributes on which an attribute roll-upprovide us a higher flexibility in the design phase in the sensethat new ARR’s may be defined at any time without beingnecessary to change the existing ARR’s. Nevertheless, themain contribution of [15] is to demonstrate that cubestructures are nested and therefore, their analysis can besimplified. However, our OOMD introduces for first time inthis field the concept of classes to encapsulate data andoperations to apply on it, which provide us a higher level ofabstraction.

Multidimensional cubes can be seen as different classicviews of databases that users can have. According to [15],we consider that the definition of an abstract entity (abstractobjects) to encapsulate data that the cube contains as wellas the operations permitted on it in the design phase willachieve a clearer design of MDB, higher design flexibilityand a better restriction during the data analysis phase.On the other hand, several multidimensional models (formallogical models) have been proposed. However, they aremainly guided to the study of OLAP query languages. Acommon feature to all of them is that they are guided to aspecific implementation and therefore, they are less suitableto the conceptual design of MDB. In the rest of this section,we will make reference to three multidimensional models thatwe consider the most relevant ones presented until now.In [1], a model based on the notion of the multidimensionalcube (whose first definition was introduced in [8]) and analgebraic query language to allow analysis operations on thiscube are proposed. However, there are aspects that weconsider relevant in the design of MDB as the dimensionattribute classification hierarchy that are considered using aspecial operator in the query language. However, in ourproposal, this relevant element is considered from the firststep in the conceptual design providing the ARR on thedimension attributesis based on the idea of a subsequent mapping to the traditional. Furthermore, the model proposed in [1]model adopting the presumption of a subsequentimplementation in a relational system.

In [9], a logical model for MDB in which the contents areclearly separate of the structural aspects is proposed. Asabove-commented, we find basic elements in the design ofMDB as the aggregation levels of dimensions that are notexplicitly considered. Furthermore, this model is focused onthe development of a query language based on the structurespreviously defined. Finally, we should say that the bestsuccess of this model is its complex mapping to the relationalmodel. On the other hand, in [16] a multidimensional model(MDD) for OLAP techniques is proposed. In this model, aquery language called \"grouping algebra\" based on a basiccomponent called multidimensional cube is developed.In conclusion, no general conceptual model with a high levelof abstraction and independent of any subsequentimplementation, and consequently, suitable for the conceptualdesign of MDB has been proposed until now. However, thecurrent proposals are conceptual extensions to the classicalmultidimensional model, translations from classical databaseconceptual models such as the E-R model or mappings to therelational model.

Paper layoutwhich will be used throughout the paper, to handle all the. In next section, we introduce a simple example,concepts and basic ideas of the classical multidimensionalmodel. In the third section we present the basic definitions ofour proposal, i.e. the notion of classes fact classes and dimensionsection we introduce the concept of with an adequate domain definition. In the fourthentity on which data (objects) and operations permitted on itcube class as an abstract(them) are encapsulate to allow a subsequent data analysis.Finally, in the fifth section we present the conclusions andfuture works that emerge from this first approach.

2throughout an example

The classical multidimensional modelWe wish to design a MDB for a company whose commercialactivity is devoted to the vehicle sales to different stores. Wewish to know details on the vehicle to analyze the Furthermore, we wish to know features of the sold units and which is the sales, concretely we wishand storesales, value.store datelocated, of the its of the sales. Concretely, we wish to know of thevehiclenamedate its year, semestervehicle, country its , area, city and street where it is, monthgroup, date , family and day of the weekand brand and of the.In figure 1 a multidimensional cube is presented to show thegeneral idea of the multidimensional data model. In each cellof the cube, we will be able to store the concrete data of thesales that are studied, i.e. the sold particular data receives the name of units and their characteristics fact values. Thisobserved that the cube has three sides (dimensions), one for(or measures). On the other hand, it can beattributes oreach feature that we wish to analyze, i.e. datevehicle, store andattributes (features) called . Finally, each dimension consists of a number ofeach dimension in more detail (described in the previousdimension attributes that describeparagraph).

A last relevant feature of these cubes is the classificationhierarchy that is defined on the dimensionattributes along eachassembled (classified or aggregated). The oriented arrows in, which permits the values of these attributes to befigure 1 show the attribute classification hierarchy that hasbeen defined along each dimension. This will allow us toaggregate attribute values (them in a larger detail level (roll-up operation) or to analyzeexample, we suppose that all the stores in our database aredrill-down). In our particularlocated in Spain (Spain is divided into four areas, North,South, East and West). Furthermore, we have currentlylocated sales in the cities of Alicante, Valencia and Sevilla.By analyzing the sales with respect to the cities, we canaccomplish a from the roll-upthe result that we have obtained sales in the East areacity attribute to the operation along the area one. Thus, we will obtainstore dimension and(Alicante and Valencia belong to the East area) and in theSouth one (Sevilla belongs to the South area). Thisclassification hierarchy could also be written ascitycrumble those areas to obtain the concrete cities where weÆareaÆcountry. The reverse operation will be tohave sold vehicles. Then, we will accomplish a operation along the attribute to the store dimension and from the drill-downareathe cities in the East area where we have sold vehicles arecity one. Thus, we will obtain the result thatAlicante and Valencia.

country Store area city Vehicle brand family group day, month, semester, year DateFigure 1.

In addition to the operations according to [5] we can roll-up and drill-down,along one or more dimensions) and slice/dice (selection and projectionthe multidimensional view of data). Other authors such aspivoting (re-orienting[1] increase the number of operations to apply on the cube(for example, they propose operations to dimension on a cube).

add and delete a3 Dimension class and fact class

In the real life there are objects that have commoncharacteristics. Following an OO Paradigm we will groupobjects in classes. These classes will encapsulate both staticand dynamic properties of these objects. For example, withreference to stores, their static properties are that all ofthem are located in a concrete specific areacity and that a city belongs to ahierarchy). Dynamic properties are the operations that cancountry and subsequently the store is placed in a (attributes and their attribute classificationbe accomplished on objects to change their characteristics(for example to change the store location). However, weknow that in a context of MDB objects (data) are static inthe sense that once they exist in our system they will notmodify their characteristics (static properties) until they arecarried to an auxiliary store. Therefore, the two first actionsto apply on these objects will be to create and destroy them.Following the nomenclature of the multidimensional modeland applying the OO paradigm, we will firstly distinguishamong will contain dimension classes characteristics of the factual data, while FC will containdimension objects (DC) and fact classes (DO) that provide(FC). DCfact objects We will firstly introduce the necessary definitions to allow(FO). The latter classes will be built from DC.us to define DC and FC (basic elements in our OOMDmodel).

Definition 1 where each element (Let attributes (A) be an n-tuple (a1, a2a specific class, i.e. this tuple characterizes the objects of aa,..., an)i) is a feature that have the objects ofclass.

Definition 2 be taken by an attribute Let vi be the set of values or instances that canData Abstract Type (DAT) of ai ⊆ A following the definition ofNote ai

such as string, real, float, integer and so on with theirthat we will firstly take into account basic DAT’spossible operations.

Definition 3 possible values (instances) to be taken by Let ai ⊆ A an attribute and domain function as where for a given attribute

dom:aavi be the set ofi, we define the

a, it will return a subset of values (i→viivi’ ⊆ vi) for ai

Definition 4 objects (elements) of a particular class, we say that the Let A be a set of attributes being hold by theattributeevery object of that particular class

(KA) is an attribute akeyi ⊆ A that defines univocallyDefinition 5 of Let A be a set of attributes being hold by a set(DA) as a n-tuple (adimension objects (DO), we define dimension attributeswhere the KA of these DO is not included in this tuple.1, a2,..., an) that characterizes these DO,Definition 6 an aattribute roll-up relationLet A’ ⊆ A be a subset of attributes, we define (ARR) as an n-tuple (a1, a2,...,an) where a partial order relation is defined, such thata1≤a2≤...≤an and that given two attributes ai,aj such that aNotea≤ai ≤j, there is not any k such that ai≤akj

(A’), even though the KA is within A’.

that this relation can be applied to any subset of AWe can observe that this relation to allow us to define theattribute classification hierarchy, i.e. rolls up a1Æa2Æ...Æthe second section)

to aaan (a12, a2 rolls up to 3 and so on, as commented inDefinition 7 define the to obtain the attribute values according to the classificationroll-up domain function Let ARR be an attribute roll-up relationasdomroll−up:v, wei,aj→vjhierarchy.

Conversely, we define the drill-down domain function asdomdrill−down:vj,ai→vi

Definition 8 events (operations) to apply on these objects. TheseLet any kind of object be, E is the set ofoperations are any object respectively.

“new” and “delete” to create and destroyDefinition 9 (A, ARR, E), where

We define a dimension class (DC) as a tuple•• A= KA ARR is a possible ∪ DA

• on A’, where A’ E is the set of events allowed on the class objects,⊆ A

attribute roll-up relation definedi.e. “new” and “delete”Example presented in section 2. According to this, we will have threeWe apply these definitions to the exampledimension classesdimension class the previous definitions to only one dimension class (theand , the date dimension classvehicle dimension class. We now apply, storestore classthe rest of the dimension classes.

). The reader can easily apply the definitions toWe will have a E) where,

store dimension class as the tuple (A, ARR,• A= KA •• KA is the ∪ DA, where,

DA=(store_code,

street),

store_name, country, area, city,•• ARR=(E=(newstore_name, city, area, country, delete)

)We will then show some examples of how the and aggregated data, taking into account the different valuesdomdrill-down functions will operate to obtaindomroll-upthat currently exist in the system (see the example insection 2).

domroll−up:alicante,area→East

domroll−up:sevilla,area→Southdomroll−up:East,country→Spain

domroll−up:South,country→Spaindomdrill−down:Spain,area→East,South

domdrill−down:East,city→alicante,valencia

domdrill−down:South,city→sevilla

Note that these functions together with the definition ofARR’s are necessary to express the granularity of data. Thefollowing step is to build the contain fact class the attributes fact class fact objects (FO), from dimension classes. Before(FC), which willor measures definition we define the concept of as follows:

factDefinition 10 fact objects, we define Let A be a set of attributes and FO be a set ofn-tuple (ameasure or fact attributes (FA) as aKA of these FO is not included in this tuple. These are the1, a2,..., an) that characterize these FO, where theemerging characteristics that provide specific information(factual information)

Definition 11 a Let DC1, DC2,...,DCn be n dimension classes,(A, ARR, E), where

fact class (FC) from these n dimension classes is a tuple• A= KA •∪ FA, where,

• • ARR is a possible KA is the FA is the set of key attributefact attributes or measures for FO

• defined on a subset of FA (FA’attribute roll-up relationE is the set of events allowed on FO, i.e. ⊆FA).

and “delete”“new”Examplesales fact class Following the same example, we will obtain theclasses as the tuple (A, ARR, E) where:

from the vehicle, store and date dimension• A= KA •• • ∪ FA, where,ARR=(),

KA= FA=(sales_number, valuesales_code

),If ARR is an empty relation we will not apply thefunctions domroll-up and domdrill-down on • class attributesE=(new, delete (FA).fact)

4 Cube classes

Once we have defined the different object classes that wewill have in our system, we proceed to the definition of thecube classes (CC) to permit a subsequent data analysis. The

CC can be considered as the classical cube and the objectsbelonging to the CC as the data contained in the cube onwhich the analysis operations will be applied.

Concerning the CC, their definitions are always based on afact classdimension classes, and therefore, they will contain data fromclasses reference to the operations permitted on the objects of theand one fact class . This means that we need to build this basic CC. Withn-dimensionCCoperations that can create or destroy an object of the class our approach is twofold. On the one hand, we have the(different analysis on the data contained in the CC.

\"new\"/\"delete\"). On the other hand, those that permitDefinition 12 and FC be a Let DC1, DC2,...,DCn be n we define a where

cube classfact class built from these n dimension classes,dimension classes (CC) as a tuple (DC,FC,A,C,E,CE),• DC is the set of dimension classes • used for constructing the FC is the fact class from which the cube class hasfact class

that have been• been built

A = KA •• KA is the set of ∪ CFA ∪ CDA where,

CFA is a subset of FAkey attributes of the FC.Note. By defining both • CDA is a subset of the DA from DCi

from the FCattributes dimension attributes and fact

following format: class_name.attribute_name towhile constructing the CC, we use theallow us to know which object classes every• C is a condition n-tuple (aattribute belongs to.

where values that must fulfill each attribute a are dimension attributes and 1=v1, a2=vv2,..., an=vn)iai the set ofNotethe objects that will integrate this CC.

i to select. If ai=aj with vi ≠ vj both kinds of different• objects will be selected.

E is the set of operations allowed on the objects of• the CC, i.e. CE is the set of events (operations) permitted on“new” and “delete”.

the cube class, i.e. operations that are applied tothe set of all the class. These operations according to [1] and [5]cube objects contained in thewill allow the subsequent analysis of the datacontained in the cube achieving an intuitivenavigation on the cube class.Example previous section, we will show an example of a CCFollowing the class definition provided in theconstruction. We wish to analyze the wherestore the group_ofsold vehicle numberbrand_country is “Spain” _vehiclegrouped is “four wheels” and the by the vehicle familyspecification, we will construct the following and by the store area and name. According to this andcube class.A CC on the C, E, CE), where

sales fact class will be the tuple (DC, FC, A,• DC = store dimension class, vehicle dimension•• class

FC = A = KA sales fact class

• KA = ∪sales_code

CFA ∪ CDA where,•• CFA=(CDA=(sales.number)

vehicle.brandvehicle.group, vehicle.family,

• C=(store.name)

, store.country, store.area,•store.countryvehicle.group=\"Spain\")=\"four wheel vehicles\

• E=(CE will be the operations commented in thenew, delete).

previous definitionIn Table 1., we show in a more intuitive way (the classicalmultidimensional view of data) the result of the previousexample bold letters, whereas the result of C (objectsCC construction. The condition C is printed incontained/selected in this CC) is printed in normal font. Onthe other hand, the attributes shown in this figure are CFAand CDA, i.e. the KA’s are not shown. Finally, the name ofthis cube class (sales) is printed in cursive.

SalesVehicle.group=”4 wheel vehicles”trucksCarsManBMWOPELRenaultStore.eastSala10202352country=Court20302574SpainsouthVals10153024Court41211827Table 1.5 Conclusions and future work

We have presented a first revolutionary OO approach toMDB conceptual modeling. We have firstly defined the twobasic elements of our OOMD, i.e. fact classesdimension classes anddimension and fact classes. We have then defined the operations allowed on it, which will allow us to accomplish) to encapsulate both data andcube class (froma subsequent data analysis. From our point of view, the starmodel only considers relational tables and therefore, basicelements of MDB’s such as the classification hierarchy onattributes along dimensions cannot be expressed. Ourapproach, however, provides mechanisms (ARR anddomain functions) to achieve this issue.

This revolutionary approach provides a higher level ofabstraction (encapsulates both data and operations in onestructure) than the models proposed until now as well as amore restrictive way to a subsequent analysis of the datacontained in the cube. Unlike other models which are eitherextensions to the classical multidimensional model ormappings from the classical database conceptual models(such as the ER model), our OOMD is an independent andrevolutionary approach since it does take into considerationneither any of these assumptions nor any subsequentimplementation.

We are currently extending the to allow us to accomplish a subsequent data analysis ascube class set of operationswell as being able to construct a being able to build a cube from others. We are alsocube class hierarchy, i.e.extending the cube class from n cube class fact classes definition to allow us to define theinstead of only one. On the

other hand, we wish to provide a rich conceptual model andits graphical user interface to facilitate the definition of ourOOMD structures (to make the model more intuitive) aswell as to provide an easy set of point-and-click operationsto accomplish a subsequent data analysis. By finishingthese and other extensions that are currently being carriedout, we wish to extend this conceptual model to a formallogical model. In conclusion, we fairly believe that this firstOOMD approach is a solid basis for solving the MDBconceptual modeling problems derived from the lack of aformal and independent general conceptual model. Ourattempt is to provide a more intuitive and completeconceptual model than the “star model” providing thenecessary mechanisms to consider all relevant aspects ofMDB’s.

Acknowledgements

We want to thank Dr. J. Samos and the anonymousreviewers of the DOLAP workshop (CIKM’98) for theirdetailed comments, which helped us improve this paper

6 References

[1]

Agrawal, R., Gupta, A., Sarawagi, S., “ModelingMultidimensional Databases”. In 13th Intl. Conf.On Data Engineering, (ICDE’97), pages 232-243,Birmingham, U.K., April. 1997.

[2]Archer Decision Sciences. “Star Schema 101“.http://www.netmar.com/~nraden/

[3]

Cabibbo, L., Torlone, R., “QueryingMultidimensional databases”. In 6th Int. Workshopon Database Programming Languages. (DBPL’97),1997.

[4]

Cabibbo, L., Torlone, R., “A Logical Approach toMultidimensional Databases”. Lecture Notes inComputer Science, number 1377 in proc. of the 6thInt. Conf. On Extending Database Technology,(EDBT’98), pages 183-197. Valencia, March.1998[5]Chaudhuri, S, Dayal, U., “An Overview of DataWarehousing and OLAP technology”. ACMSigmod Record vol. 26 (1), March 1997

[6]

Codd, E.F.,Codd, S.B., Salley C.T., “ProvidingOLAP (On-Line Analytical Processing) to UserAnalyst: An IT Mandate”. Available from ArborSoftware’s web site

[7]

Golfarelli, M., Maio, D., Rizzi, S. “ConceptualDesign of Data Warehouses from E/R Schemes”. Inthe 31st Hawaii conference on System Sciences,1998.

[8]

Gray, J., Bosworth, A., Layman, A., Pirahesh, H.“Data Cube: A Relational Aggregation OperatorGeneralizing Group-by, Cross-Tab and SubTotals”. Data Mining and Knowledge DiscoveryJournal, Vol. 1 No 1, 1997.

[9]

Gyssens, M., Lakshmanan, L. “A Foundation forMulti-Dimensional Databases”. In the 33rd Intl.Conf. On Very Large Database Conference(VLDB’97). Pages 106-115. 1997

[10]

Hammer, J., Garcia-Molina, H., Widom, J., Labio,W.J. and Zhuge, Y. “The Standford DataWarehousing Project”. IEEE Data EngineeringBulleting, Special issue on Materialized Views andData Warehousing Project. June 1995

[11]Inmon, W. H., “Building the Data Warehouse”.John Wiley, 1992

[12]Kimball, R. “The data warehousing toolkit”. JohnWiley, 1996

[13]Kimball, R., “A Dimensional Modelling Manifesto”http://www.dbmsmag.com

[14]

Labio,W. L., Zhuge, Y., Wiener, J.L., Gupta, H.,Garcia-Molina, H., Widom, J., “The WHIPSPrototype for Data Warehouse Creation andMaintenance”. ACM Sigmod Record in Intl. Conf.on Management of Data (CIKM’97). Arizona. May1997

[15]

Lehner, W., “Modelling Large Scale OLAPScenarios”. Lecture Notes in Computer Science,number 1377 in proc. of the 6th Int. Conf. OnExtending Database Technology, (EDBT’98),pages 153-167. Valencia, Spain. March, 1998.

[16]

Li, C., Wang, X., “A Data Model for SupportingOn-Line Analytical Processing”. In Intl. Conf. onInformation and Knowledge Management,(CIKM’96), pages 81-88. Nov., 1996[17]Mendelzon, A., “A Research-OrientedBibliography (in progress)”.

[18]Redbrick Systems. “Star Schemas and Star JoinTechnology”. White paper. August 1996

[19]

Space Consultancy. Data Warehousing- RodinOverview. “What is data warehousing and Why dowe need it ?”.

[20]

Widom, J., “Research Problems in DataWarehousing”. In the 4th Intl. Conf. On Informationand knowledge Management (CIKM’95), Nov.1995

[21]

Wiener, J.L., Gupta, H., Labio, W.J., Zhuge, Y.,Garcia-Molina, H., and Widom, J. “A SystemPrototype for Warehouse View Maintenance.” Inthe Workshop on Materialized Views: Techniquesand Applications, pages 26-33, Montreal, Canada,June, 1996