constraints and multidimensional databases - Semantic Scholar
CONSTRAINTS AND MULTIDIMENSIONAL DATABASES F. Ghozzi, F. Ravat, O. Teste, G. Zurfluh IRIT/SIG - Université Paul Sabatier, 118 Route de Narbonne, 31062 Toulouse cedex 04, France E-mail: {ghozzi, ravat, teste, zurfluh}@irit.fr
Keywords:
Multidimensional database, constellation schema, intra-dimension constraints, inter-dimension constraints.
Abstract:
The model we define organises data in a constellation of facts and dimensions with multiple hierarchies. In order to insure data consistence and reliable data manipulation, we extend this constellation model by intraand inter-dimension constraints. The intra-dimension constraints allow the definition of exclusions and inclusions between hierarchies of a same dimension. The inter-dimension constraints are related to hierarchies of different dimensions. Also, we study effects of these constraints on multidimensional operations. We depict integration of these constraints within GEDOOH prototype.
1
INTRODUCTION
In order to improve decision-making process, decision support systems and OLAP (On-Line Analytic Processing) systems (Codd, 1993) are built from sources such as operational databases. These information systems are often based on multidimensional databases (MDB). MDB are emerging as a key technology for enterprises that wish to improve data analysis and decision supports (Kimball, 1996). They are modelled “multidimensionaly” (Vassiliadis, Sellis, 1999) for improving analyses and decision making processes. Nevertheless, the confidence in a MDB lies in its capacity to supply relevant information. A multidimensional model integrating constraints must provide an accurate model of the organisation activities and it allows valid data restitution (Hurtado et al., 2002). This paper deals with constraint-based multidimensional modelling.
1.1 The Problem The scientific community has studied several MDB models. The multidimensional modelling (Kimball, 1996) (Vassiliadis, Sellis, 1999) represents data as points in multidimensional space. Data are viewed as several subjects of analyse (facts) associated to axis of analyse (dimensions). Each dimension contains one or several viewpoints of analyse (hierarchies) representing data granularities. For example, sale amounts could be
analysed according to time, stores and customers. Along store dimension, a hierarchy could group individual stores into cities, which are grouped into states or regions, which are grouped into countries. MDB are manipulated through data cubes (Gray et al., 1996), cubes with n-dimensions (Gyssen et al., 1997) and/or cubes integrating explicitly multiple hierarchies (Agrawal et al., 1995) (Li et al., 1996) (Lehner, 1998) (Vassiliadis, Sellis, 1999) (Mendelzon et al., 2000). These approaches do not integrates some inconsistencies between hierarchies (Hurtado et al., 2002). For example, geographic hierarchy which groups cities into departments, regions and countries is consistent for French cities whereas this hierarchy is irrelevant regarding to US geography. (Kimball, 1996) refers this problem where incompatible hierarchies such as French geography and US geography are modelled in a single heterogeneous dimension. Several solutions have been introduced. (Lehner, 1998) proposes transforming dimensions into dimensional normal form. (Pedersen, Jensen, 1999) provides class dimensions, which are transformed into homogeneous dimensions by adding null information. (Hurtado et al., 2002) provides dimension constraints to reduce hierarchy inconsistencies. This approach introduces frozen dimensions, which are minimal homogeneous dimensions representing the structures that are implicitly combined in an heterogeneous dimension. Some problems are not take into account in this approach. For example, we consider the analyse of sale amounts according to products and stores. If a French taxonomy is defined along product
dimension, it seems to be inconsistent to analyse sale amounts of these products according to US stores, which are grouped into the US geography.
1.2 Contributions and paper outline This paper defines a constellation data model integrating constraints. Each dimension supports multiple instantiations; e.g. each instance of a dimension belongs to one or more hierarchies. The main contribution of the model is the integration of intra-dimension constraints as well as interdimension constraints. The intra-dimension constraints allow the definition of exclusions and inclusions between hierarchies of a same dimension. The inter-dimension constraints are related to hierarchies of different dimensions. The paper is composed of the following three sections. Section 2 defines a constellation model where dimensions support multiple instantiations as well as multiple hierarchies. Section 3 specifies intra-dimension constraints and inter-dimension constraints. We show the effect of these constraints during multidimensional manipulations. Section 4 presents a prototype named GEDOOH.
2. CONSTELLATION WITH MULTIPLE INSTANTIATIONS 2.1 Constellation A constellation extends star schemas, which are commonly used in the multidimensional context (Kimball, 1996). It regroups several subjects of analyse (facts), which are studied according to several axis of analyse (dimensions) possibly shared between facts. Users manipulate facts according to shared dimensions, facilitating comparisons. Definition. A constellation denoted C is defined by (NC, FC, DC, StarC, ConsC) - NC is a name of constellation, - FC={F1, F2,…, Fp} is a set of facts, - DC={D1, D2,…, Dq} is a set of dimensions, - StarC:FC→2DC is a function which associates facts and dimensions, - ConsC is a set of constraints.
2.2 Dimensions A dimension reflects information according to which measures will be analysed. A dimension is
composed of parameters, which are organised through one or several hierarchies; the dimensions may be shop, product, date,… Definition. A dimension denoted D is defined by (ND, PD, HD, ID) - ND is a name of dimension, - PD={a1, a2,…, au} is a set of parameters, - HD={hD1, hD2,…, hDv} is a set of hierarchies, - ID={ID1, ID2,…} is a set of dimension instances. A dimension instance is defined by a tuple [a1:v1, a2:v2,…, au:vu] such as ∀k∈[1..u], ak∈PD ∧ vk is a value. Note that PD contains two distinguished parameters All and Id such that dom(All)={all} and dom(Id)∈OID (set of identifiers). The attribute All defines the upper granularity of hierarchies and the attribute Id defines the lower granularity. Note that for every hierarchy hDj∈HD, hDj=.
2.3 Hierarchies The parameters are organised according to hierarchies. Within a dimension, values of different parameters represent several data granularities according to which measures could be analysed. Definition. A hierarchy denoted hDi is an acyclic path starting at Id and finishing at All. It is defined by (Nh, Paramh, Supplh, Condh) - Nh is a name of hierarchy, - Paramh: P→P (P⊆ PD) is a function which describes granularities (each attribute of the hierarchy defines a granularity), - Supplh: P→2PD-P is a function which associates additional attributes of the granularities, - Condh is a boolean expression defining a condition. Each dimension instance satisfying the condition belongs to the hierarchy.
2.4 Facts A fact reflects information that have to be analysed; for example, a fact data is sale amount occurring in shops. Definition. A fact denoted F is defined by (NF, F F M ,J ) - NF is a name of fact, - MF={a1, a2,…, aw} is a set of measures, - JF={JF1, JF2,…} is a set of fact instances. A fact instance is defined by a tuple [a1:v1, a2:v2,…, aw:vw] where ∀k∈[1..w], (ak∈MF ∧ vk is a value) ∨ (ak∈PStar(F) ∧ vk∈OID). We note PStar(F) identifiers of the dimensions, which are associated to F.
2.5 Motivating example
composed of two facts named ‘SALE’ and ‘PURCHASE’ and four dimensions named ‘SHOP’, ‘DATE’, ‘PRODUCT’ and ‘STOCK’. Sale fact is associated to shop, product and date dimensions whereas purchase fact is associated to product, date and stock dimensions. Note that date and product dimensions are shared dimensions.
The case we study is taken from commercial domain and it concerns shop channels. This MDB permits to analyse sales and purchases related to various commercial shops. Using specific notations (Golfarelli et al., 1998), figure 1 depicts an example of MDB through a constellation schema. It is
All fact
french_class
shop_name commercial_zone country All
state region
Id
SHOP
Shop
department
type
prod_desc
SALE city
category
IdProduct
additional attribute
PRODUCT
sale_amount quantity tax_amount
dimension
measures
warehouse_desc state
PURCHASE DATE
quantity price
IdDate day month year
hierarchy
STOCK
city zone IdStock department
country All region
parameters
month_desc
All
Figure 1: Example of constellation schema (Golfarelli et al., 1998).
In the following we depict the constellation according to the formal definitions. Sale fact is defined by the following tuple (‘SALE’, {sale_amount, quantity, tax_amount, IdSHOP, IdDATE, IdPRODUCT}, {JSALE1, JSALE2,…}) where - JSALE1=[sale_amount: 200.00, quantity: 5, tax_amount: 57.00, IdSHOP: oid1, IdDATE: oid2, IdPRODUCT: oid3], - JSALE2=[sale_amount: 300.00, quantity: 6, tax_amount: 78.00, IdSHOP: oid4, IdDATE: oid2, IdPRODUCT: oid5]. Shop dimension is defined by the tuple (‘SHOP’, {IdSHOP, shop_name, city, department, region, state, commercial_zone, country, All}, {h_fr_geo, h_us_geo, SHOP
SHOP
SHOP
h_zone}, {I 1, I 2, I 3,…}) where - ISHOP1=[IdSHOP: oid2, shop_name: ‘ventout’,
city: ‘Toulouse’, department: 31, region: ‘M-P.’, state: null, commercial_zone: ‘SO’, country: ‘France’, All: ‘all’], - ISHOP2=[IdSHOP: oid4, shop_name: ‘Adidas Store’, city: ‘Dallas’, department: null, region: null, state: ‘Texas’, commercial_zone: ‘S’, country: ‘USA’, All: ‘all’], - ISHOP3=[IdSHOP: oid5, shop_name: ‘H&M vente’, city: ‘Toulouse’, department: 31, region: ‘M-P.’, state: null, commercial_zone: ‘SO’, country: ‘France’, All: ‘all’]. Along shop dimension there are three hierarchies defined as follows.
-
h_fr_geo=(‘geo française’, Paramh_fr_geo, h_fr_geo Suppl , dom(country)∈{‘France’}). h_us_geo=(‘American geo’, Paramh_us_geo, h_us_geo , dom(country)∈{‘USA’}). Suppl h_zone=(‘zone geo’, Paramh_zone, Supplh_zone,
dom(commercial_zone)∈{'S', 'E', 'O', 'N', 'C', 'SO', 'SE', 'NO', 'NE'}). The definition of Paramh_fr_geo function is: - Paramh_fr_geo(IdSHOP)=city, - Paramh_fr_geo(city)=department, - Paramh_fr_geo(department)=region, - Paramh_fr_geo(region)=country, - Paramh_fr_geo(country)=All. Supplh_fr_geo function definition is: - Supplh_fr_geo(IdSHOP)={store_name}. The definition of Paramh_us_geo function is: - Paramh_us_geo(IdSHOP)=city, - Paramh_us_geo(city)=state, - Paramh_us_geo(state)=country, - Paramh_us_geo(country)=All. Supplh_us_geo function definition is: - Supplh_us_geo(IdSHOP)={store_name}. The definition of Paramh_zone function is: - Paramh_zone(IdSHOP)=city, - Paramh_zone(city)=commercial_zone, - Paramh_zone(zone)=country, - Paramh_zone(country)=All. The definition of Supplh_zone function is: - Supplh_zone(IdSHOP)={store_name}.
The multiple instantiation property of our model allows set specification of dimension instances associated to each hierarchy: - {ISHOP1, ISHOP3}∈h_fr_geo, - {ISHOP2}∈h_us_geo, and - {ISHOP1, ISHOP2, ISHOP3}∈h_zone.
3. CONSTRAINTS The approach we present in this paper deals with constraints which maintain data relevance. They influence upon populating processes, data management and data manipulation of OLAP databases. These constraints intend to reply to needs which have still not been answered satisfactorily by classical models. First we need to express interactions between hierarchies (perspective of analyse) in a same dimension (axe of analyse). For example, instances related to a hierarchy describing French geography, cannot be described by a hierarchy, which defines American geography. We take into account this problem through intra-dimension constraints. Another need concerns the association of fact instances to dimension instances. In current models all fact instances are associated to all dimension instances whereas some associations may be inconsistent. For example, we consider sale amounts, which are analysed according to products and stores. If a French taxonomy is defined along product dimension, it seems to be inconsistent to analyse sale amounts of these products according to stores belonging to US geographic hierarchy. We take into account this problem through interdimension constraints.
3.1 Intra-dimension constraints
Definition. An inclusion constraint of h1 hierarchy (h1∈HD) in h2 (h2∈HD) means that all dimension instances of h1 belong to h2. h1⊙h2 iff ∀I∈condh1, I∈condh2. Example. We consider shop dimension. Several intra-dimension constraints are defined. - h_us_geo⊗h_fr_geo specifies that dimension instances of h_us_geo do not belong to h_fr_geo and reciprocally ({ISHOP1, SHOP SHOP I 3}∈h_fr_geo, {I 2}∈h_us_geo). - h_us_geo⊙h_zone specifies that all dimension instances of h_us_geo belong to h_zone ({ISHOP2}∈h_us_geo, {ISHOP1, ISHOP2, SHOP I 3}∈h_zone). - h_fr_geo⊙h_zone specifies that all dimension instances of h_fr_geo belong to h_zone ({ISHOP1, ISHOP3}∈h_fr_geo, {ISHOP1, SHOP SHOP I 2, I 3}∈h_zone). h_fr_geo IShop1 X
IShop2 X
X
h_zone Figure 2: Instances of shop dimension and their hierarchies.
1.1.2 OLAP manipulations under intradimension constraints The intra-dimension constraints have effect on multidimensional operations such as rotate, roll-up and drill-down operations. Rotation of hierarchies. The rotation between h1 hierarchy and h2 hierarchy (where h1⊗h2) involves displaying data changes. For example, if we rotate a hierarchy h_us_geo to h_fr_geo, the dimension instances are related to the French stores (❷) and not the US stores.
3.1.1 Definition Intra-dimension constraints focus on hierarchies in same dimensions. These constraints influence dimension instances in MDB. Definition. An exclusion constraint between two hierarchies denoted h1 and h2 of D means that dimension instances of D, which belong to h1, do not belong to h2 (and vice versa). h1⊗h2 iff ∀I∈ID, ∀I'∈ID, if I∈condh1 ∧ I'∈condh2 then I≠I'.
h_us_geo
IShop3
❶ {ISTORE } ❶ {ISTORE2 2}STORE ➋ {ISTORE STORE 1, I, ISTORE 3} } ➋ {I ➌ {ISTORE ,1ISTORE2,3ISTORE STORE 3} } ➌ {ISTORE1 1, ISTORE 2, I 3 Rotate Rotate
state IdSTORE
➌
❶
country
city ➋
department
➋
➌
All
region
Figure 3: Example of hierarchy rotation with an exclusion constraint.
Also, the rotation between a hierarchy h1 and a hierarchy h2 (where h1⊙h2) involves an addition of dimension instances belonging to h2. For example, if we rotate a hierarchy h_fr_geo to h_zone, it is possible to display all dimension instances of h_zone
(❸) or to maintain the analyse by displaying only dimension instances of h_fr_geo (❷). ❶ {ISTORE 2} } ❶ {ISTORE 2 STORE ➋➋ {I{ISTORE STORE 1, ,I ISTORE 3} 1 STORE 3}STORE , ➌➌ {I{ISTORE STORE 1 ,I ISTORE 2, ,I ISTORE 3}} 2 3 Rotate 1 Rotate
zone ➌
.
city
❶ state
IdSTORE ➋ department
.
country All region
Figure 4: Example of hierarchy rotation with an inclusion constraint.
Example. First, the analyse uses the French geography; e.g. the displayed instances along Shop dimension are {ISHOP1, ISHOP3}. After a hierarchy rotation between h_fr_geo and h_zone, the system can maintain the analyse using {ISHOP1, ISHOP3} (see figure 6) or initiate a new analyse using { ISHOP1, SHOP SHOP I 2, I 3} (see figure 5).
Update operations. Also, the intra-dimension constraints have effect on MDB update operations. Table 1 presents these effects. Table 1: Effects of MDB update operations under intradimension constraints.
Operation Constraint Effect h1⊗h2 ID is rejected if ID both belongs to h1 and h2 Insert or (ID∈condh1 ∧ ID∈condh2) update a h1⊙h2 ID is rejected if ID dimension belongs to h1 and not instance ID belongs to h2 (ID∈condh1 ∧ ID∉condh2) Delete a _ h1⊗h2 dimension _ h1⊙h2 instance ID
1.2 Inter-dimension constraints
h_fr_geo
h_us_geo IShop1 Shop X I 3 IShop2 X X h_zone Figure 5: Initialising a new analyse. h_fr_geo
h_us_geo IShop1 X IShop3 IShop2 X X h_zone Figure 6: Maintaining the analyse.
Roll-up/Drill-down. The roll-up/drill-down operations from a parameter, which is shared between several hierarchies, to a specific parameter of a hierarchy (associated to an exclusion or an inclusion constraint) involve possible data deletion. For example, if we roll-up from city to department, displaying instances move because only dimension instances belonging to h_fr_geo are took into account (set ❸ becomes set ❷). In a same way, the roll-up/drill-down operations from a specific parameter to a shared parameter involve an addition of dimension instances.
❶ IdSTORE ➌ ➌
❶ {ISTORE 2} } ❶ {ISTORE 2 STORE ➋ {ISTORE STORE 1, ,I ISTORE 3} ➋ {I 1 STORE 3}STORE ➌ {ISTORE , 1 ,I ISTORE 2, ,I ISTORE 3 }} ➌ {ISTORE 2 3 Rotate 1 Rotate
state
➌
city ➋ department
country All
➋ region
Figure 7: Example of roll-up with an exclusion constraint.
1.2.1 Definition Inter-dimension constraints are related to hierarchies of distinct dimensions, which are associated to a same fact. These constraints influence fact instances in MDB. Definition. An exclusion constraint between h1 hierarchy (h1∈HD1) and h2 hierarchy (h2∈HD2) means that fact instance cannot be associated simultaneously to the dimension instances of h1 and the dimension instances of h2. h1⊗h2 iff ∀J∈IF, ∀I∈condh1, if starD1(idD1, J) = dom(idD1, I) then ¬(∃ I'∈condh2, starD2(idD2, J) = dom(idD2, I’)). Definition. An inclusion constraint of h1 hierarchy (h1∈HD1) in h2 (h2∈HD2) means that the set of fact instances manipulated through h1 is a subset of fact instances manipulated through h2. h1⊙h2 iff ∀J∈IF, ∀I∈condh1, if starD1(idD1, J) = dom(idD1, I) then ∃ I'∈condh2, starD2(idD2, J) = dom(idD2, I’)). The function dom(a, I) gives a value v representing the value of the attribute a for the instance I. The function starD(a, J) gives the value of the attribute a (for the dimension instance which is associated to the fact instance J). Example. We consider shop and product dimensions. We define a French taxonomy (h_fr_prod) and a US taxonomy (h_us_prod) along product dimension. Several inter-dimensions constraints are defined. - h_us_prod⊗h_fr_geo,
-
h_fr_prod⊗h_us_geo, h_us_prod⊙h_zone, h_fr_prod⊙h_zone. PRODUCT dimension
SHOP dimension
h_us_prod
h_fr_geo X
IShop1
IProduct1 IProduct2 X X
IShop3 X
Product 4 XI
h_us_geo
h_fr_prod IProduct3 IProduct5 X X
IShop2 X h_zone
JSale1 JSale2 ... SALE fact
Figure 8: Instances of dimensions and Sale fact.
dimensions, the analyse can be maintained (the analyse focuses on the French sales according to stores located in France and the French product taxonomy) or new data related to h_zone hierarchy can be added (analyse is extended to all sales). Roll-up/Drill-down. The roll-up/drill-down operations involve deletion or addition of fact instances. To maintain a same analyse, fact instances can be also maintained. Update operations. Also, the intra-dimension constraints have effect on MDB update operations. Table 2 presents these effects. Table 2: Effects of MDB update operations under interdimension constraints.
Operation 1.1.2 OLAP manipulations under interdimension constraints The inter-dimension constraints have effect on dimension and fact rotations as well as roll-up and drill-down operations. Rotation of facts. When we rotate facts associated to a shared dimension along which hierarchies with exclusion or inclusion constraints are defined, the displaying instances can be maintained or refreshed.
All french_class
type Id
Product
PRODUCT
.
shop_name country All region
state zone
Delete a fact instance JF
h1⊙h2
_
4. GEDOOH EXTENSIONS
category
prod_desc
Insert or update a fact instance JF
Constraint Effects h1⊗h2 JF is rejected if JF is both associated to ID1 (ID1∈condh1) and ID2 (ID2∈condh2). h1⊙h2 JF is rejected if JF is associated to ID1 D1 (I ∈condh1) and not associated to ID2 D2 (I ∈condh2) _ h1⊗h2
SALE sale_amount quantity tax_amount
In order to validate the constraint-based model we present in this paper, we have implemented a prototype, called GEDOOH, which is a MDB generator tool. It is dedicated to help administrators for defining and generating constellations within a R-OLAP database management system.
city
INTERFACE
SHOP IdShop department
Figure 9: Example of an inclusion inter-dimension constraint.
Rotation of dimensions. The rotation between a dimension along which h1 hierarchy is defined and a dimension along which h2 hierarchy is defined (a constraint is defined between h1 and h2), involves to maintain the analyse by displaying only the dimension instances of h1 or to make a new analyse by displaying all the dimension instances of h2. For example in figure 5, we consider the analyse of sale amounts of products regarding to the French taxonomy (IdPRODUCT, french_class, All). If we make a dimension rotation between product and shop
GENERATOR
create
populate
refresh
GEDOOH Metadata Repository
ORACLE 9i
MDB1
Source
MDB2
Figure 10: Architecture of GEDOOH.
The architecture of GEDOOH is based on three main components: a graphical interface, a generator and a metadata repository.
The interface allows administrators to define graphically constellation schemata of MDB. GEDOOH is based on extended UML notations for displaying source schemata and it uses specific notations (Golfarelli et al., 1998) for displaying MDB schemata. The administrator defines a data warehouse from a UML diagram of sources. constraint scope
constraint type
Figure 11: Dialog box for defining an exclusion intradimension constraint.
In the MDB definition process, the administrator defines intra- and/or inter-dimension constraints. These definitions are made through a dialog box
where the administrator chooses constraint types and constraint scopes. The system validates these constraints by indicating possibly conflicts between the constraint definitions. For example, it is forbidden to create an exclusion constraint and an inclusion constraint between the two same hierarchies. The generator component produces automatically SQL and PLS/SQL scripts for creating, populating and refreshing a R-OLAP database according to graphical definitions. Each database (sources, MDB,…), each process (populate, refresh,…) is described by the metadata repository. Moreover, the constraint definitions are stored in the metadata repository. The schema of the metadata repository is described at figure 12. We depict the diagram of the metadata repository using UML notations. This diagram integrates the model concepts such as facts, dimensions, hierarchies as well as the intra- and inter-dimension constraints. MDB generation is based on this repository. GEDOOH is implemented in Java (jdk 1.4.1) on top of a relational database management system (Oracle9i Database Release 2) and it is operational. Its source code represents approximately 10000 lines of Java code.
Constellation ConsC
NameC
FC
Constraint NameC TypeC
DC 1..*
1..* Fact
Star
NameF 1..* 1..*
0..*
Dimension NameD
1..*
PD
1..*
MF
AssoIntra
1..*
Measure NameP DomP AgregP
NameP DomP Suppl
1..*
1..*
0..* 1..* 1..*
2..*
0..*
Inter-Dim
HD
Parameter 1..*
Intra-Dim
1..*
1..* Hierarchy Param
NameH CondH
Level
Figure 12: Schema of the metadata repository.
1..*
AssoInter
5. CONCLUSION In order to insure data consistence and reliable data manipulation, we have presented a constraintbased data model in the MDB context. In order to facilitate correlations between various subjects of analyse, the model we propose integrates a constellation of facts and dimensions. Along each dimension, various hierarchies are possibly defined. This model supports multiple instantiations of dimensions; e.g. each dimension instance belongs to one or more hierarchies. The main contribution is the definition of intradimension constraints as well as inter-dimension constraints. The intra-dimension constraints allow the definition of exclusions and inclusions between hierarchies of a same dimension whereas the interdimension constraints are related to hierarchies of different dimensions. In order to validate the constraint-based model we present in this paper, we described a MDB generator prototype, called GEDOOH. Our ongoing works focus on the definition of new constraints. In the future we plan to provide an extended multidimensional algebra where OLAP operators will be extended to support our constraintbased model.
REFERENCES (Agrawal et al., 1995) R. Agrawal, A. Gupta, S. Sarawagi, « Modeling Multidimensional Databases », Research Report, IBM Almaden Research Center, San Jose (California), 1995. Parus dans les actes de ICDE'97. (Codd, 1993) E.F. Codd, « Providing OLAP (on-line analytical processing) to user-analysts : an IT mandate », Technical Report, E.F. Codd and Associates, 1993. (Golfarelli et al., 1998) M. Golfarelli, D. Maio, S. Rizzi, « Conceptual design of data warehouses from E/R schemes », 31st Hawaii International Conference on System Sciences, 1998. (Gray et al., 1996) J. Gray, A. Bosworth, A. Layman, and H. Pirahesh, « Data cube: a relational aggregation operator generalizing group-by, cross-tabs and subtotals », Int'l Conf. on Data Engineering, 1996. (Gyssen et al., 1997) Gyssen M., Lakshmanan L.V.S., « A Foundation for Multi-Dimensional Databases », 23rd International Conference on Very Large Data Bases VLDB'97, Athène (Grèce), 25-29 August 1997.
(Hurtado et al., 2002) C. Hurtado, A. Mendelzon, « OLAP Dimension Constraints », PODS 2002, Madison, June 2002. (Kimball, 1996) Kimball R., The data warehouse toolkit, John Wiley and Sons, 1996. (Lehner, 1998) W. Lehner, « Modeling Large Scale OLAP Scenarios », 6th International Conference on Extending Database Technology (EDBT'98), Valence (Espagne), 23-27 March 1998. (Li et al., 1996) Li C., Wang X. S., « A Data Model for Supporting On-Line Analytical Processing », 5th International Conference on Information and Knowledge Management - ACM CIKM'96, November 1996. (Mendelzon et al., 2000) Alberto Mendelzon and Alejandro Vaisman, « Temporal Queries in OLAP », VLDB 2000, Caire (Egypte), Septembre 2000. (Pedersen, Jensen, 1999) Torben Bach Pedersen and Christian S. Jensen, « Multidimensional Data Modeling for Complex Data », ICDE' 99, 1999. (Vassiliadis, Sellis, 1999) P. Vassiliadis, T. Sellis, « A Survey on Logical Models for OLAP Databases », SIGMOD Record 28(4): 64-69, 1999.
Keywords:
Multidimensional database, constellation schema, intra-dimension constraints, inter-dimension constraints.
Abstract:
The model we define organises data in a constellation of facts and dimensions with multiple hierarchies. In order to insure data consistence and reliable data manipulation, we extend this constellation model by intraand inter-dimension constraints. The intra-dimension constraints allow the definition of exclusions and inclusions between hierarchies of a same dimension. The inter-dimension constraints are related to hierarchies of different dimensions. Also, we study effects of these constraints on multidimensional operations. We depict integration of these constraints within GEDOOH prototype.
1
INTRODUCTION
In order to improve decision-making process, decision support systems and OLAP (On-Line Analytic Processing) systems (Codd, 1993) are built from sources such as operational databases. These information systems are often based on multidimensional databases (MDB). MDB are emerging as a key technology for enterprises that wish to improve data analysis and decision supports (Kimball, 1996). They are modelled “multidimensionaly” (Vassiliadis, Sellis, 1999) for improving analyses and decision making processes. Nevertheless, the confidence in a MDB lies in its capacity to supply relevant information. A multidimensional model integrating constraints must provide an accurate model of the organisation activities and it allows valid data restitution (Hurtado et al., 2002). This paper deals with constraint-based multidimensional modelling.
1.1 The Problem The scientific community has studied several MDB models. The multidimensional modelling (Kimball, 1996) (Vassiliadis, Sellis, 1999) represents data as points in multidimensional space. Data are viewed as several subjects of analyse (facts) associated to axis of analyse (dimensions). Each dimension contains one or several viewpoints of analyse (hierarchies) representing data granularities. For example, sale amounts could be
analysed according to time, stores and customers. Along store dimension, a hierarchy could group individual stores into cities, which are grouped into states or regions, which are grouped into countries. MDB are manipulated through data cubes (Gray et al., 1996), cubes with n-dimensions (Gyssen et al., 1997) and/or cubes integrating explicitly multiple hierarchies (Agrawal et al., 1995) (Li et al., 1996) (Lehner, 1998) (Vassiliadis, Sellis, 1999) (Mendelzon et al., 2000). These approaches do not integrates some inconsistencies between hierarchies (Hurtado et al., 2002). For example, geographic hierarchy which groups cities into departments, regions and countries is consistent for French cities whereas this hierarchy is irrelevant regarding to US geography. (Kimball, 1996) refers this problem where incompatible hierarchies such as French geography and US geography are modelled in a single heterogeneous dimension. Several solutions have been introduced. (Lehner, 1998) proposes transforming dimensions into dimensional normal form. (Pedersen, Jensen, 1999) provides class dimensions, which are transformed into homogeneous dimensions by adding null information. (Hurtado et al., 2002) provides dimension constraints to reduce hierarchy inconsistencies. This approach introduces frozen dimensions, which are minimal homogeneous dimensions representing the structures that are implicitly combined in an heterogeneous dimension. Some problems are not take into account in this approach. For example, we consider the analyse of sale amounts according to products and stores. If a French taxonomy is defined along product
dimension, it seems to be inconsistent to analyse sale amounts of these products according to US stores, which are grouped into the US geography.
1.2 Contributions and paper outline This paper defines a constellation data model integrating constraints. Each dimension supports multiple instantiations; e.g. each instance of a dimension belongs to one or more hierarchies. The main contribution of the model is the integration of intra-dimension constraints as well as interdimension constraints. The intra-dimension constraints allow the definition of exclusions and inclusions between hierarchies of a same dimension. The inter-dimension constraints are related to hierarchies of different dimensions. The paper is composed of the following three sections. Section 2 defines a constellation model where dimensions support multiple instantiations as well as multiple hierarchies. Section 3 specifies intra-dimension constraints and inter-dimension constraints. We show the effect of these constraints during multidimensional manipulations. Section 4 presents a prototype named GEDOOH.
2. CONSTELLATION WITH MULTIPLE INSTANTIATIONS 2.1 Constellation A constellation extends star schemas, which are commonly used in the multidimensional context (Kimball, 1996). It regroups several subjects of analyse (facts), which are studied according to several axis of analyse (dimensions) possibly shared between facts. Users manipulate facts according to shared dimensions, facilitating comparisons. Definition. A constellation denoted C is defined by (NC, FC, DC, StarC, ConsC) - NC is a name of constellation, - FC={F1, F2,…, Fp} is a set of facts, - DC={D1, D2,…, Dq} is a set of dimensions, - StarC:FC→2DC is a function which associates facts and dimensions, - ConsC is a set of constraints.
2.2 Dimensions A dimension reflects information according to which measures will be analysed. A dimension is
composed of parameters, which are organised through one or several hierarchies; the dimensions may be shop, product, date,… Definition. A dimension denoted D is defined by (ND, PD, HD, ID) - ND is a name of dimension, - PD={a1, a2,…, au} is a set of parameters, - HD={hD1, hD2,…, hDv} is a set of hierarchies, - ID={ID1, ID2,…} is a set of dimension instances. A dimension instance is defined by a tuple [a1:v1, a2:v2,…, au:vu] such as ∀k∈[1..u], ak∈PD ∧ vk is a value. Note that PD contains two distinguished parameters All and Id such that dom(All)={all} and dom(Id)∈OID (set of identifiers). The attribute All defines the upper granularity of hierarchies and the attribute Id defines the lower granularity. Note that for every hierarchy hDj∈HD, hDj=.
2.3 Hierarchies The parameters are organised according to hierarchies. Within a dimension, values of different parameters represent several data granularities according to which measures could be analysed. Definition. A hierarchy denoted hDi is an acyclic path starting at Id and finishing at All. It is defined by (Nh, Paramh, Supplh, Condh) - Nh is a name of hierarchy, - Paramh: P→P (P⊆ PD) is a function which describes granularities (each attribute of the hierarchy defines a granularity), - Supplh: P→2PD-P is a function which associates additional attributes of the granularities, - Condh is a boolean expression defining a condition. Each dimension instance satisfying the condition belongs to the hierarchy.
2.4 Facts A fact reflects information that have to be analysed; for example, a fact data is sale amount occurring in shops. Definition. A fact denoted F is defined by (NF, F F M ,J ) - NF is a name of fact, - MF={a1, a2,…, aw} is a set of measures, - JF={JF1, JF2,…} is a set of fact instances. A fact instance is defined by a tuple [a1:v1, a2:v2,…, aw:vw] where ∀k∈[1..w], (ak∈MF ∧ vk is a value) ∨ (ak∈PStar(F) ∧ vk∈OID). We note PStar(F) identifiers of the dimensions, which are associated to F.
2.5 Motivating example
composed of two facts named ‘SALE’ and ‘PURCHASE’ and four dimensions named ‘SHOP’, ‘DATE’, ‘PRODUCT’ and ‘STOCK’. Sale fact is associated to shop, product and date dimensions whereas purchase fact is associated to product, date and stock dimensions. Note that date and product dimensions are shared dimensions.
The case we study is taken from commercial domain and it concerns shop channels. This MDB permits to analyse sales and purchases related to various commercial shops. Using specific notations (Golfarelli et al., 1998), figure 1 depicts an example of MDB through a constellation schema. It is
All fact
french_class
shop_name commercial_zone country All
state region
Id
SHOP
Shop
department
type
prod_desc
SALE city
category
IdProduct
additional attribute
PRODUCT
sale_amount quantity tax_amount
dimension
measures
warehouse_desc state
PURCHASE DATE
quantity price
IdDate day month year
hierarchy
STOCK
city zone IdStock department
country All region
parameters
month_desc
All
Figure 1: Example of constellation schema (Golfarelli et al., 1998).
In the following we depict the constellation according to the formal definitions. Sale fact is defined by the following tuple (‘SALE’, {sale_amount, quantity, tax_amount, IdSHOP, IdDATE, IdPRODUCT}, {JSALE1, JSALE2,…}) where - JSALE1=[sale_amount: 200.00, quantity: 5, tax_amount: 57.00, IdSHOP: oid1, IdDATE: oid2, IdPRODUCT: oid3], - JSALE2=[sale_amount: 300.00, quantity: 6, tax_amount: 78.00, IdSHOP: oid4, IdDATE: oid2, IdPRODUCT: oid5]. Shop dimension is defined by the tuple (‘SHOP’, {IdSHOP, shop_name, city, department, region, state, commercial_zone, country, All}, {h_fr_geo, h_us_geo, SHOP
SHOP
SHOP
h_zone}, {I 1, I 2, I 3,…}) where - ISHOP1=[IdSHOP: oid2, shop_name: ‘ventout’,
city: ‘Toulouse’, department: 31, region: ‘M-P.’, state: null, commercial_zone: ‘SO’, country: ‘France’, All: ‘all’], - ISHOP2=[IdSHOP: oid4, shop_name: ‘Adidas Store’, city: ‘Dallas’, department: null, region: null, state: ‘Texas’, commercial_zone: ‘S’, country: ‘USA’, All: ‘all’], - ISHOP3=[IdSHOP: oid5, shop_name: ‘H&M vente’, city: ‘Toulouse’, department: 31, region: ‘M-P.’, state: null, commercial_zone: ‘SO’, country: ‘France’, All: ‘all’]. Along shop dimension there are three hierarchies defined as follows.
-
h_fr_geo=(‘geo française’, Paramh_fr_geo, h_fr_geo Suppl , dom(country)∈{‘France’}). h_us_geo=(‘American geo’, Paramh_us_geo, h_us_geo , dom(country)∈{‘USA’}). Suppl h_zone=(‘zone geo’, Paramh_zone, Supplh_zone,
dom(commercial_zone)∈{'S', 'E', 'O', 'N', 'C', 'SO', 'SE', 'NO', 'NE'}). The definition of Paramh_fr_geo function is: - Paramh_fr_geo(IdSHOP)=city, - Paramh_fr_geo(city)=department, - Paramh_fr_geo(department)=region, - Paramh_fr_geo(region)=country, - Paramh_fr_geo(country)=All. Supplh_fr_geo function definition is: - Supplh_fr_geo(IdSHOP)={store_name}. The definition of Paramh_us_geo function is: - Paramh_us_geo(IdSHOP)=city, - Paramh_us_geo(city)=state, - Paramh_us_geo(state)=country, - Paramh_us_geo(country)=All. Supplh_us_geo function definition is: - Supplh_us_geo(IdSHOP)={store_name}. The definition of Paramh_zone function is: - Paramh_zone(IdSHOP)=city, - Paramh_zone(city)=commercial_zone, - Paramh_zone(zone)=country, - Paramh_zone(country)=All. The definition of Supplh_zone function is: - Supplh_zone(IdSHOP)={store_name}.
The multiple instantiation property of our model allows set specification of dimension instances associated to each hierarchy: - {ISHOP1, ISHOP3}∈h_fr_geo, - {ISHOP2}∈h_us_geo, and - {ISHOP1, ISHOP2, ISHOP3}∈h_zone.
3. CONSTRAINTS The approach we present in this paper deals with constraints which maintain data relevance. They influence upon populating processes, data management and data manipulation of OLAP databases. These constraints intend to reply to needs which have still not been answered satisfactorily by classical models. First we need to express interactions between hierarchies (perspective of analyse) in a same dimension (axe of analyse). For example, instances related to a hierarchy describing French geography, cannot be described by a hierarchy, which defines American geography. We take into account this problem through intra-dimension constraints. Another need concerns the association of fact instances to dimension instances. In current models all fact instances are associated to all dimension instances whereas some associations may be inconsistent. For example, we consider sale amounts, which are analysed according to products and stores. If a French taxonomy is defined along product dimension, it seems to be inconsistent to analyse sale amounts of these products according to stores belonging to US geographic hierarchy. We take into account this problem through interdimension constraints.
3.1 Intra-dimension constraints
Definition. An inclusion constraint of h1 hierarchy (h1∈HD) in h2 (h2∈HD) means that all dimension instances of h1 belong to h2. h1⊙h2 iff ∀I∈condh1, I∈condh2. Example. We consider shop dimension. Several intra-dimension constraints are defined. - h_us_geo⊗h_fr_geo specifies that dimension instances of h_us_geo do not belong to h_fr_geo and reciprocally ({ISHOP1, SHOP SHOP I 3}∈h_fr_geo, {I 2}∈h_us_geo). - h_us_geo⊙h_zone specifies that all dimension instances of h_us_geo belong to h_zone ({ISHOP2}∈h_us_geo, {ISHOP1, ISHOP2, SHOP I 3}∈h_zone). - h_fr_geo⊙h_zone specifies that all dimension instances of h_fr_geo belong to h_zone ({ISHOP1, ISHOP3}∈h_fr_geo, {ISHOP1, SHOP SHOP I 2, I 3}∈h_zone). h_fr_geo IShop1 X
IShop2 X
X
h_zone Figure 2: Instances of shop dimension and their hierarchies.
1.1.2 OLAP manipulations under intradimension constraints The intra-dimension constraints have effect on multidimensional operations such as rotate, roll-up and drill-down operations. Rotation of hierarchies. The rotation between h1 hierarchy and h2 hierarchy (where h1⊗h2) involves displaying data changes. For example, if we rotate a hierarchy h_us_geo to h_fr_geo, the dimension instances are related to the French stores (❷) and not the US stores.
3.1.1 Definition Intra-dimension constraints focus on hierarchies in same dimensions. These constraints influence dimension instances in MDB. Definition. An exclusion constraint between two hierarchies denoted h1 and h2 of D means that dimension instances of D, which belong to h1, do not belong to h2 (and vice versa). h1⊗h2 iff ∀I∈ID, ∀I'∈ID, if I∈condh1 ∧ I'∈condh2 then I≠I'.
h_us_geo
IShop3
❶ {ISTORE } ❶ {ISTORE2 2}STORE ➋ {ISTORE STORE 1, I, ISTORE 3} } ➋ {I ➌ {ISTORE ,1ISTORE2,3ISTORE STORE 3} } ➌ {ISTORE1 1, ISTORE 2, I 3 Rotate Rotate
state IdSTORE
➌
❶
country
city ➋
department
➋
➌
All
region
Figure 3: Example of hierarchy rotation with an exclusion constraint.
Also, the rotation between a hierarchy h1 and a hierarchy h2 (where h1⊙h2) involves an addition of dimension instances belonging to h2. For example, if we rotate a hierarchy h_fr_geo to h_zone, it is possible to display all dimension instances of h_zone
(❸) or to maintain the analyse by displaying only dimension instances of h_fr_geo (❷). ❶ {ISTORE 2} } ❶ {ISTORE 2 STORE ➋➋ {I{ISTORE STORE 1, ,I ISTORE 3} 1 STORE 3}STORE , ➌➌ {I{ISTORE STORE 1 ,I ISTORE 2, ,I ISTORE 3}} 2 3 Rotate 1 Rotate
zone ➌
.
city
❶ state
IdSTORE ➋ department
.
country All region
Figure 4: Example of hierarchy rotation with an inclusion constraint.
Example. First, the analyse uses the French geography; e.g. the displayed instances along Shop dimension are {ISHOP1, ISHOP3}. After a hierarchy rotation between h_fr_geo and h_zone, the system can maintain the analyse using {ISHOP1, ISHOP3} (see figure 6) or initiate a new analyse using { ISHOP1, SHOP SHOP I 2, I 3} (see figure 5).
Update operations. Also, the intra-dimension constraints have effect on MDB update operations. Table 1 presents these effects. Table 1: Effects of MDB update operations under intradimension constraints.
Operation Constraint Effect h1⊗h2 ID is rejected if ID both belongs to h1 and h2 Insert or (ID∈condh1 ∧ ID∈condh2) update a h1⊙h2 ID is rejected if ID dimension belongs to h1 and not instance ID belongs to h2 (ID∈condh1 ∧ ID∉condh2) Delete a _ h1⊗h2 dimension _ h1⊙h2 instance ID
1.2 Inter-dimension constraints
h_fr_geo
h_us_geo IShop1 Shop X I 3 IShop2 X X h_zone Figure 5: Initialising a new analyse. h_fr_geo
h_us_geo IShop1 X IShop3 IShop2 X X h_zone Figure 6: Maintaining the analyse.
Roll-up/Drill-down. The roll-up/drill-down operations from a parameter, which is shared between several hierarchies, to a specific parameter of a hierarchy (associated to an exclusion or an inclusion constraint) involve possible data deletion. For example, if we roll-up from city to department, displaying instances move because only dimension instances belonging to h_fr_geo are took into account (set ❸ becomes set ❷). In a same way, the roll-up/drill-down operations from a specific parameter to a shared parameter involve an addition of dimension instances.
❶ IdSTORE ➌ ➌
❶ {ISTORE 2} } ❶ {ISTORE 2 STORE ➋ {ISTORE STORE 1, ,I ISTORE 3} ➋ {I 1 STORE 3}STORE ➌ {ISTORE , 1 ,I ISTORE 2, ,I ISTORE 3 }} ➌ {ISTORE 2 3 Rotate 1 Rotate
state
➌
city ➋ department
country All
➋ region
Figure 7: Example of roll-up with an exclusion constraint.
1.2.1 Definition Inter-dimension constraints are related to hierarchies of distinct dimensions, which are associated to a same fact. These constraints influence fact instances in MDB. Definition. An exclusion constraint between h1 hierarchy (h1∈HD1) and h2 hierarchy (h2∈HD2) means that fact instance cannot be associated simultaneously to the dimension instances of h1 and the dimension instances of h2. h1⊗h2 iff ∀J∈IF, ∀I∈condh1, if starD1(idD1, J) = dom(idD1, I) then ¬(∃ I'∈condh2, starD2(idD2, J) = dom(idD2, I’)). Definition. An inclusion constraint of h1 hierarchy (h1∈HD1) in h2 (h2∈HD2) means that the set of fact instances manipulated through h1 is a subset of fact instances manipulated through h2. h1⊙h2 iff ∀J∈IF, ∀I∈condh1, if starD1(idD1, J) = dom(idD1, I) then ∃ I'∈condh2, starD2(idD2, J) = dom(idD2, I’)). The function dom(a, I) gives a value v representing the value of the attribute a for the instance I. The function starD(a, J) gives the value of the attribute a (for the dimension instance which is associated to the fact instance J). Example. We consider shop and product dimensions. We define a French taxonomy (h_fr_prod) and a US taxonomy (h_us_prod) along product dimension. Several inter-dimensions constraints are defined. - h_us_prod⊗h_fr_geo,
-
h_fr_prod⊗h_us_geo, h_us_prod⊙h_zone, h_fr_prod⊙h_zone. PRODUCT dimension
SHOP dimension
h_us_prod
h_fr_geo X
IShop1
IProduct1 IProduct2 X X
IShop3 X
Product 4 XI
h_us_geo
h_fr_prod IProduct3 IProduct5 X X
IShop2 X h_zone
JSale1 JSale2 ... SALE fact
Figure 8: Instances of dimensions and Sale fact.
dimensions, the analyse can be maintained (the analyse focuses on the French sales according to stores located in France and the French product taxonomy) or new data related to h_zone hierarchy can be added (analyse is extended to all sales). Roll-up/Drill-down. The roll-up/drill-down operations involve deletion or addition of fact instances. To maintain a same analyse, fact instances can be also maintained. Update operations. Also, the intra-dimension constraints have effect on MDB update operations. Table 2 presents these effects. Table 2: Effects of MDB update operations under interdimension constraints.
Operation 1.1.2 OLAP manipulations under interdimension constraints The inter-dimension constraints have effect on dimension and fact rotations as well as roll-up and drill-down operations. Rotation of facts. When we rotate facts associated to a shared dimension along which hierarchies with exclusion or inclusion constraints are defined, the displaying instances can be maintained or refreshed.
All french_class
type Id
Product
PRODUCT
.
shop_name country All region
state zone
Delete a fact instance JF
h1⊙h2
_
4. GEDOOH EXTENSIONS
category
prod_desc
Insert or update a fact instance JF
Constraint Effects h1⊗h2 JF is rejected if JF is both associated to ID1 (ID1∈condh1) and ID2 (ID2∈condh2). h1⊙h2 JF is rejected if JF is associated to ID1 D1 (I ∈condh1) and not associated to ID2 D2 (I ∈condh2) _ h1⊗h2
SALE sale_amount quantity tax_amount
In order to validate the constraint-based model we present in this paper, we have implemented a prototype, called GEDOOH, which is a MDB generator tool. It is dedicated to help administrators for defining and generating constellations within a R-OLAP database management system.
city
INTERFACE
SHOP IdShop department
Figure 9: Example of an inclusion inter-dimension constraint.
Rotation of dimensions. The rotation between a dimension along which h1 hierarchy is defined and a dimension along which h2 hierarchy is defined (a constraint is defined between h1 and h2), involves to maintain the analyse by displaying only the dimension instances of h1 or to make a new analyse by displaying all the dimension instances of h2. For example in figure 5, we consider the analyse of sale amounts of products regarding to the French taxonomy (IdPRODUCT, french_class, All). If we make a dimension rotation between product and shop
GENERATOR
create
populate
refresh
GEDOOH Metadata Repository
ORACLE 9i
MDB1
Source
MDB2
Figure 10: Architecture of GEDOOH.
The architecture of GEDOOH is based on three main components: a graphical interface, a generator and a metadata repository.
The interface allows administrators to define graphically constellation schemata of MDB. GEDOOH is based on extended UML notations for displaying source schemata and it uses specific notations (Golfarelli et al., 1998) for displaying MDB schemata. The administrator defines a data warehouse from a UML diagram of sources. constraint scope
constraint type
Figure 11: Dialog box for defining an exclusion intradimension constraint.
In the MDB definition process, the administrator defines intra- and/or inter-dimension constraints. These definitions are made through a dialog box
where the administrator chooses constraint types and constraint scopes. The system validates these constraints by indicating possibly conflicts between the constraint definitions. For example, it is forbidden to create an exclusion constraint and an inclusion constraint between the two same hierarchies. The generator component produces automatically SQL and PLS/SQL scripts for creating, populating and refreshing a R-OLAP database according to graphical definitions. Each database (sources, MDB,…), each process (populate, refresh,…) is described by the metadata repository. Moreover, the constraint definitions are stored in the metadata repository. The schema of the metadata repository is described at figure 12. We depict the diagram of the metadata repository using UML notations. This diagram integrates the model concepts such as facts, dimensions, hierarchies as well as the intra- and inter-dimension constraints. MDB generation is based on this repository. GEDOOH is implemented in Java (jdk 1.4.1) on top of a relational database management system (Oracle9i Database Release 2) and it is operational. Its source code represents approximately 10000 lines of Java code.
Constellation ConsC
NameC
FC
Constraint NameC TypeC
DC 1..*
1..* Fact
Star
NameF 1..* 1..*
0..*
Dimension NameD
1..*
PD
1..*
MF
AssoIntra
1..*
Measure NameP DomP AgregP
NameP DomP Suppl
1..*
1..*
0..* 1..* 1..*
2..*
0..*
Inter-Dim
HD
Parameter 1..*
Intra-Dim
1..*
1..* Hierarchy Param
NameH CondH
Level
Figure 12: Schema of the metadata repository.
1..*
AssoInter
5. CONCLUSION In order to insure data consistence and reliable data manipulation, we have presented a constraintbased data model in the MDB context. In order to facilitate correlations between various subjects of analyse, the model we propose integrates a constellation of facts and dimensions. Along each dimension, various hierarchies are possibly defined. This model supports multiple instantiations of dimensions; e.g. each dimension instance belongs to one or more hierarchies. The main contribution is the definition of intradimension constraints as well as inter-dimension constraints. The intra-dimension constraints allow the definition of exclusions and inclusions between hierarchies of a same dimension whereas the interdimension constraints are related to hierarchies of different dimensions. In order to validate the constraint-based model we present in this paper, we described a MDB generator prototype, called GEDOOH. Our ongoing works focus on the definition of new constraints. In the future we plan to provide an extended multidimensional algebra where OLAP operators will be extended to support our constraintbased model.
REFERENCES (Agrawal et al., 1995) R. Agrawal, A. Gupta, S. Sarawagi, « Modeling Multidimensional Databases », Research Report, IBM Almaden Research Center, San Jose (California), 1995. Parus dans les actes de ICDE'97. (Codd, 1993) E.F. Codd, « Providing OLAP (on-line analytical processing) to user-analysts : an IT mandate », Technical Report, E.F. Codd and Associates, 1993. (Golfarelli et al., 1998) M. Golfarelli, D. Maio, S. Rizzi, « Conceptual design of data warehouses from E/R schemes », 31st Hawaii International Conference on System Sciences, 1998. (Gray et al., 1996) J. Gray, A. Bosworth, A. Layman, and H. Pirahesh, « Data cube: a relational aggregation operator generalizing group-by, cross-tabs and subtotals », Int'l Conf. on Data Engineering, 1996. (Gyssen et al., 1997) Gyssen M., Lakshmanan L.V.S., « A Foundation for Multi-Dimensional Databases », 23rd International Conference on Very Large Data Bases VLDB'97, Athène (Grèce), 25-29 August 1997.
(Hurtado et al., 2002) C. Hurtado, A. Mendelzon, « OLAP Dimension Constraints », PODS 2002, Madison, June 2002. (Kimball, 1996) Kimball R., The data warehouse toolkit, John Wiley and Sons, 1996. (Lehner, 1998) W. Lehner, « Modeling Large Scale OLAP Scenarios », 6th International Conference on Extending Database Technology (EDBT'98), Valence (Espagne), 23-27 March 1998. (Li et al., 1996) Li C., Wang X. S., « A Data Model for Supporting On-Line Analytical Processing », 5th International Conference on Information and Knowledge Management - ACM CIKM'96, November 1996. (Mendelzon et al., 2000) Alberto Mendelzon and Alejandro Vaisman, « Temporal Queries in OLAP », VLDB 2000, Caire (Egypte), Septembre 2000. (Pedersen, Jensen, 1999) Torben Bach Pedersen and Christian S. Jensen, « Multidimensional Data Modeling for Complex Data », ICDE' 99, 1999. (Vassiliadis, Sellis, 1999) P. Vassiliadis, T. Sellis, « A Survey on Logical Models for OLAP Databases », SIGMOD Record 28(4): 64-69, 1999.
