ORE: An Iterative Approach to the Design andEvolution of Multi-Dimensional Schemas

Petar JovanovicUniversitat Politècnica deCatalunya, BarcelonaTech

Barcelona, Spainpetar@essi.upc.edu

Oscar RomeroUniversitat Politècnica deCatalunya, BarcelonaTech

Barcelona, Spainoromero@essi.upc.edu

Alkis SimitsisHP Labs

Palo Alto, CA, USAalkis@hp.com

Alberto AbellóUniversitat Politècnica deCatalunya, BarcelonaTech

Barcelona, Spainaabello@essi.upc.edu

ABSTRACTDesigning a data warehouse (DW) highly depends on the in-formation requirements of its business users. However, tai-loring a DW design that satisfies all business requirementsis not an easy task. In addition, complex and evolving busi-ness environments result in a continuous emergence of newor changed business needs. Furthermore, for building a cor-rect multidimensional (MD) schema for a DW, the designershould deal with the semantics and heterogeneity of the un-derlying data sources. To cope with such an inevitable com-plexity, both at the beginning of the design process and whena potential evolution event occurs, in this paper we presenta semi-automatic method, named ORE, for constructing theMD schema in an iterative fashion based on the informationrequirements. In our approach, we consider each require-ment separately and incrementally build the unified MDschema satisfying the entire set of requirements.

Categories and Subject DescriptorsH.2.7 [Database Management]: Database Administra-tion—Data warehouse and repository

KeywordsData Warehouse, Multi-Dimensional Design, ETL Design

1. INTRODUCTIONData warehousing ecosystems have been widely recognized

to successfully support strategic decision making in com-plex business environments. One of their most importantgoals is to capture the relevant organization data providedthrough different sources and in various formats and to en-able analytical processing of this data. The most commondesign approach suggests building a centralized decision sup-port repository (like a DW) which gathers the organization’sdata and which, due to its analytical tasks, follows a multi-dimensional (MD) design. The MD design is distinguished

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.DOLAP’12, November 2, 2012, Maui, Hawaii, USA.Copyright 2012 ACM 978-1-4503-1721-4/12/11 ...$10.00.

by the fact/dimension dichotomy, where facts represent thesubjects of analysis and dimensions show different perspec-tives from which the subjects can be analyzed. Furthermore,the design of the extract-transform-load (ETL) processes re-sponsible for managing the data flow from the sources to-wards the DW constructs, must also be considered.

Complex business plans and dynamic, evolving enterpriseenvironments often result in a continuous flow of new infor-mation requirements that may further require new analyt-ical perspectives or new data to be analyzed. Due to thedynamic nature of the DW ecosystem, building the com-plete DW design at once is not practical. Also, assumingthat all information and business requirements are availablefrom the beginning and remain intact is not realistic either.At the same time, for constructing a DW design –i.e., its MDschema– the heterogeneity and relations among the existingdata sources need to be considered as well.

The complexity of the monolithic approach for building aDW satisfying all information requirements, has also beenlargely characterized in the literature as a stumbling stoneduring the DW projects (e.g., see [9]). As a solution to thisproblem, the Data Warehouse Bus Architecture has beenproposed as a step-by-step approach for building a DW [9].This approach starts from individual data marts (DM) de-fined over single data sources and continues exploring thecommon dimensional structures, which these DMs may pos-sibly share. To facilitate this process, a matrix as the oneshown in Table 1 is used, which relates information require-ments to facts of the selected DMs and dimensions impliedby each DM. Such a matrix is used for detecting how thedimensions are shared among different facts and based onthat, for combining different DMs into the DW dimensionalmodel. However, such design guidelines assume a tremen-dous manual effort from the DW architect and hence, theystill encounter the problem of burdensome and time-lastingprocess of translating the end-user’s information require-ments into the appropriate MD schema design.

In our work, we follow a different approach to DW designwith the goal of automating the process of building the MDschema of a DW by incrementally integrating the informa-tion requirements into a unified MD schema design.

In practice, information and business requirements maycome from different business users and may span variousdata sources. For each requirement, a data sources’ subsetmay be identified and translated into the valid multidimen-sional context that corresponds to the analytical need of sucha requirement. Various approaches have both manually andautomatically tackled the issue of producing an MD design

1

Table 1: The DW Bus Architecture for IR1-IR5

Cust

om

er

Supplier

Nati

on

Reg

ion

Ord

ers

Part

Part

supp

Lin

eite

mdim

ship. qty.(IR1)√ √ √ √ √

profit(IR2)√ √ √

revenue(IR3)√ √ √ √ √

avil. stock val.(IR4)√ √ √

ship. prior.(IR5)√ √ √

from data sources, taking into account the end-user require-ments. Our method is generic and does not depend on theapproach used to accomplish such task.

In a previous effort, we have worked on automating thetranslation of a single information requirement into the ap-propriate MD interpretation of a subset of the sources [16](i.e., interpreting sources’ concepts as either factual or di-mensional). In addition, such MD interpretations undergothe process of MD validation to ensure the satisfaction ofthe MD integrity constraints, like those discussed in [10].However, such MD interpretations as is cannot serve as asingle, unified MD schema.

In this paper, we start from such MD interpretations of in-dividual requirements and present an iterative method thatconsolidates the various MD interpretations (that resemblethe rows of Table 1) into a single, unified MD schema designthat satisfies the entire set of information requirements.

Our method, ORE, is useful for the early stages of a DWproject, where we need to create an MD schema design fromscratch, but it can also serve during the entire DW lifecycleto accommodate potential evolution events. (As we discusslater on, in the presence of a new or changed requirement,our method does not require creating an MD design fromscratch, rather it can automatically absorb the change andfix an existing MD schema.) In both cases, ORE processesthe MD interpretations of the sources for a single informa-tion requirement and aims at producing the complete MDschema satisfying all the requirements so far, while also en-abling the minimal MD design by fusing the adjacent factsand dimensions and hiding irrelevant concepts. To achievebetter integration into existing MD structures (facts anddimensional hierarchies), ORE benefits from the semanticsand relations of data sources as these are captured by an ap-propriate ontology; e.g., synonyms, functional dependencies,taxonomies, and so on.

Outline. The rest of the paper is structured as follows.Section 2 presents an abstract overview of our approachthrough an example case based on the TPC-H schema [1].Section 3 formally presents our method for integrating newor changed information requirements into an MD schema de-sign. Finally, Section 4 and Section 5 discuss related workand conclude the paper, respectively.

2. OVERVIEW OF OUR APPROACHIn this section, we first describe an example case and then,

we present an overview of our iterative approach to createan MD design from a set of MD interpretations each one cor-responding to a single information or business requirement.

Figure 1: TPC-H Schema

2.1 Example and BackgroundOur example scenario is based on the TPC-H schema [1],

an abstraction of which is illustrated in Figure 1. For thesake of the example, let us assume a set of five informa-tion requirements related to the TPC-H schema. We firstdiscuss how we translate these requirements into appropri-ate MD interpretations (a task which is the focus of a pre-vious work [18]) and then, we discuss how we consolidatethese individual MD interpretations into a single, unifiedMD schema (a task which is the focus of this paper). Ourexample information requirements are as follows:

• IR1: The total quantity of the parts shipped fromSpanish suppliers to French customers.

• IR2: For each nation, the profit for all supplied parts,shipped after 01/01/2011.

• IR3: The total revenue of the parts supplied from EastEurope.

• IR4: For German suppliers, the total available stockvalue of supplied parts.

• IR5: Shipping priority and total potential revenue ofthe parts ordered before certain date and shipped aftercertain date to a customer of a given segment.

In addition to the information requirements, we use a do-main ontology that corresponds to the TPC-H data stores.There are several methods for creating such an ontology(e.g., see [20]) and thus, due to space considerations, wedo not elaborate on this topic in this paper. Having suchan ontology at hand, we benefit from the ontology featuresduring the integration process.

Starting from the given set of information requirementsand data sources, we may map these to a domain ontologyfor obtaining the corresponding MD interpretations of theserequirements [16]. Figure 2 illustrates the MD interpreta-tions for each example requirements IR1, ..., IR5.

These interpretations include exactly the subset of sourceconcepts labeled with the appropriate MD roles (i.e., fac-tual, dimensional) to fetch the required data. This meansthat besides the concepts explicitly related to a requirement,an interpretation may also include concepts relating to thesources (intermediate concepts) in order to correctly fetchthe data needed. Therefore, for example, even though IR1does not explicitly require data for customer’s orders, thecorresponding MD interpretation of the sources for IR1 (seeFigure 2) does include the Orders concept, since this is theonly way to relate the Lineitem instances with their corre-sponding Customers.

Taking into account the analytical nature of the given in-formation requirements, which typically include one or moreconcepts to be analyzed –facts (e.g., revenue, profit)– con-sidering different perspectives –dimensions (e.g., Supplier,

2

(IR1) (IR2)

(IR3) (IR4)

(IR5)Figure 2: Single MD interpretations for IR1-IR5

Customer, Nation)– a given interpretation may be labeledwith the corresponding MD information (i.e., source con-cepts may be either factual or dimensional). For each re-quirement, we obtain the valid MD-like structure that sat-isfy the analytical needs of this requirement. Nevertheless,these resulting MD interpretations cannot be considered yetas the final MD schemas, since they may contain unnecessaryand/or ambivalent knowledge (e.g., intermediate concepts).

We distinguish two kinds of MD concepts, namely dimen-sional (L) and factual (F) concepts; graphically these arerepresented as white and gray rectangles, respectively. Aconcept may contain MD attributes (measures and descrip-tors), which are identified in the domain ontology from theinput requirements. A concept may have two MD roles (fac-tual and dimensional), which in turn are shown in the MDinterpretation of a requirement.

In terms of our example, in the IR2 requirement (see Fig-ure 2), the attributes l_quantity, l_discount, and l_ex-

tendedprice are identified as measures, while the attributel_shipdate is identified as dimension. Hence, a new di-mensional concept Lineitem_dim is created and added tothe final MD interpretation for IR2. Furthermore, dimen-sion attribute (l_shipdate) is relocated from Lineitem intoLineitem_dim concept and Lineitem may then be taggedwith a factual MD role.

2.2 ProblemStarting from a set of input requirements and data sources,

we create a set of MD interpretations, one for each require-ment. The problem at hand is to identify the common MDknowledge among these interpretations and incrementallyintegrate them, in order to obtain a single MD schema sat-isfying all information requirements.

Example. Figure 2 shows the MD interpretations corre-sponding to the example requirements IR1, ..., IR5. Havingas inputs these MD interpretations, we first integrate thoseobtained for IR1 and IR2 and generate an MD schema sat-isfying both IR1 and IR2 (see Figure 3). Then, iteratively

Figure 3: MD schema satisfying IR1&IR2

Figure 4: MD schema satisfying IR1-IR5

we integrate the remaining MD interpretations. Finally, weproduce an MD schema satisfying all input requirements, asshown in Figure 4. 2

2.3 Our Solution, OREThis section presents the core components of our method

for Ontology-based data warehouse REquirement evolutionand integration (ORE), which are the inputs to our systemand the processing stages of ORE.

2.3.1 InputsData sources. To boost the integration of the new in-

formation requirements into the final MD schema design,we capture the semantics (e.g., concepts, properties) of theavailable data sources in terms of an OWL ontology. Theuse of an ontology allows us to automatically infer relationssuch as synonyms, functional dependencies, taxonomies, etc.among the concepts. Such ontology features provide moresemantically meaningful integration of new information re-quirements. If an ontology capturing the concepts and prop-erties of the data sources is not available, we create it asdescribed in the literature (e.g., [20]).

Multidimensional interpretations (MDI). The in-formation requirements posed throughout the organization(similar to the example ones presented in Section 2.1) arevalidated against the available internal or external sources.The source subset satisfying the given requirements is inter-preted with the identified MD knowledge (e.g., as in [16]).Hence, we consider as inputs the MD interpretations satisfy-ing the given set of information requirements (see Figure 2).A single information requirement may be mapped to differ-ent MD interpretations due to possible ambivalence of theMD knowledge of the source concepts obtained from thisrequirement (e.g., intermediate concepts).

For example, for the IR1 requirement (see Figure 2) the in-termediate concepts Orders and Partsupp may have two dif-ferent MD roles (factual and dimensional) and thus, for IR1there are four different MD interpretations, since all combi-nations of the MD roles for Orders and Partsupp are valid.

3

Figure 5: General overview of approach

2.3.2 StagesAn abstract schematic flow of our approach is depicted in

Figure 5. Our iterative integration method semi-automatica-lly integrates new information requirements and producesthe MD schema satisfying the requirements so far. At thesame time, the set of operations that illustrates such inte-gration step is identified (i.e., integration operations) andfurther weighted to assist designer’s choice. The needed in-tegration operations are shown in Table 2. (Table 2 alsocontains weights accompanying the integration operations;we discuss this further in Section 3.1.)

Our method, ORE, comprises four stages, namely match-ing facts, matching dimensions, complementing the MD de-sign, and integration (see Figure 6). The first three stagesgradually match different MD concepts and explore new de-sign alternatives. The last stage considers these matchingsand designer’s feedback to generate the final MD schemathat accommodates a new or changed information require-ment. Here, we give a high-level description of these stagesand in the next section, we formally present our method.

In all stages, we keep and maintain a structure, namelytraceability metadata (TM), for systematically tracing ev-erything we know about the MD design integrated so far,like candidate improvements and alternatives. With TM , weavoid overloading the produced MD schema itself. For ex-ample, this structure keeps the information about all alter-native MD interpretations for a single information require-ment, while only one is chosen to be included in the finalMD schema. Iteratively, the traceability metadata growswith the integration of each requirement and, along withthe user feedback, it provides the basis for obtaining thefinal MD schema.

Stage 1: Matching facts. We first search for differ-ent possibilities of how to incorporate an information re-quirement (i.e., its MD interpretation) to TM . The match-ing between factual concepts is considered –i.e., the systemsearches the fact(s) of TM producing an equivalent set ofpoints in the MD space– as the one in the given MD inter-pretation. Different possibilities to match the factual con-cepts results with the appropriate sets of integration opera-tions. The costs of these integration possibilities are furtherweighted and the prioritized list is proposed to the user, whois expected to choose the one most suitable to her needs.Stage 2: Matching dimensions. After matching the

factual concepts of the new MD interpretation and TM ,we then conform the dimensions implied by the matchedconcepts. Different matchings between levels are considered(i.e., “=”, “1 - 1”, “1 - *” and “* - 1”) and thus, the dif-ferent valid conformation possibilities are obtained. Witheach possibility, a different set of integration operations forconforming these dimensions is considered and weighted.

The designer decides on what the next integration action(s)should be.

Stage 3: Complementing the MD Design. We fur-ther explore the domain ontology and search for new ana-lytical perspectives. Different options may be identified toextend the current schema with new MD concepts (i.e., lev-els, descriptors, and measures). The designer is then askedto (dis)approve the integration of the discovered conceptsinto the final MD schema.

Stage 4: Integration. The MD schema is finally ob-tained in two phases of this stage. First, possible group-ings of the adjacent concepts containing the equivalent MDknowledge is identified to minimize the MD design. Boththe matchings identified through the previous stages anduser feedback are considered, in order to incorporate newrequirements into the final MD schema and possibly extendit with the MD knowledge discovered in the ontology andapproved by the user. Furthermore, the final MD schema isproduced by folding the knowledge and collapsing groupedconcepts from previously upgraded TM , to capture only theminimal information relevant to the user. Nevertheless, thecomplete TM is still preserved in the background to assistsfurther integration steps (e.g., to handle evolution of require-ments).

3. THE ORE APPROACHIn this section, we formally present ORE, our approach to

integration of MD interpretations for individual informationrequirements. After we formalize the problem, we formallydescribe each stage of ORE.

3.1 Notation and FormalizationEach input information requirement (IR) results into one

or more MD interpretations (MDI) of the sources. Alongwith that, for each requirement the choices made by the userduring the integration of that requirement are stored in anordered list γ, containing the selected ontological relation-ships. Formally:

IR = {MDIi|i = 1, ..., n1} ∪ γThe iterative integration method starts from a current MD

schema (it can be null at the beginning), whose details arecaptured in TM . At any given moment, TM contains the setof schemas satisfying IRs so far. Without loss of generality,for the sake of presentation, let us assume that these arestar schemas (e.g., snowflakes could also be generated). Asingle star schema (S) is obtained by integrating one or moreinformation requirements. Formally:

S = {IRi|i = 1, ..., n2}The traceability metadata are formally defined as:

TM = {Si|i = 1, ..., n3}TM is also used for handling evolving requirements. When

a requirement changes, we update TM (i.e., TMnew=TMold-IRold + IRnew) and generate a new MD schema, taking intoaccount previously registered user feedback as stored into γ.

In each iteration, our method semi-automatically identi-fies a set of integration operations necessary to incorporatethe new IR into the current MD schema obtained from TM .The complete set of integration operations is given in Ta-ble 2. Each operation comes with a weight representing thesignificance of the operation. These weights are used for pri-oritizing the alternative matching options before presenting

4

Figure 6: ORE : iterative integration method

Table 2: Integration operations

Operation name WeightinsertLevel 0,21insertFact 0,31insertRollUpRelation 0,27renameConcept 0insertDimDescriptor 0,04insertFactMeasure 0,36MergeLevels 0,04×(]insertDimDescriptor)MergeFacts 0,36×(]insertFactMeasure)

them to the designer (see also Section 3.3). The weightsrefer to the correlation between DW quality factors (e.g.,the structural complexity, understandability, analizability,maintainability, etc.) and different structural characteris-tics (e.g., number of dimensions, number of facts, numberof dimensional/factual attributes, number of functional de-pendencies, etc.), according to [19]. However, note that thechoice of their values is orthogonal to our approach.

3.2 Pre-processingWhile matching the different concepts or exploring new

analytical perspectives, we take into account the character-istics and relationships among the concepts captured by thedomain ontology. This allows a more effective integrationof the heterogeneous hierarchies and factual concepts by ex-ploiting different ontology features, e.g., taxonomies, many-to-one (i.e., “* - 1”), one-to-many (i.e., “1 - *”), and one-to-one or synonym (i.e., “1 - 1”) relationships. Note, that wedo not explore many-to-many (“* - *”) relationships becausesuch associations violate MD integrity constraints and thus,they cannot be considered for MD design [10]. To automatethe search for different relationships among the concepts wetake advantage of the ontology inference engine. At the sametime, the transitive closure of the different relationships (“1- 1”, “1 - *” or “* - 1”) in the ontology is considered. As ithas been shown in the past, it is feasible to automate thesearch of such closures for discovering functional dependen-cies in the ontology [17]. To enhance the performance of ouriterative method, we consider pre-computing the transitiveclosure of functional dependencies for the concepts currentlypresent in the TM and the ones coming with new MDI.

3.3 Matching factsORE starts from the MDIs obtained for a given infor-

mation requirement and it explores TM to find the existingstar schema(s) Si∈TM with the matching facts. To matchtwo facts, the condition that these facts should produce anequivalent set of points in the MD space must be satisfied.This condition is formally defined as follows:

Figure 7: Matching the MD Interpretation for IR2

(C1): The fact Fmdi∈MDI matches the fact Fsi∈Si iffthere is a bijective function f such that for each point xmdi

in the MD space arranged by the dimensions {d1,d2,..,dn}implied by Fmdi, there is one and only one point ysi in theMD space arranged by the dimensions {d′1,d′2,..,d′m} impliedby Fsi, such that f(xmdi)=ysi.

Our method tests whether C1 is satisfied (i.e., that Fmdi

matches Fsi) by means of identifying that at least one of thetwo following properties between Fmdi and Fsi holds:

(P1) Fmdi is related to Fsi by means of “1 - 1” correspon-dence (i.e., synonyms or equal factual concepts).

(P2) For each dimension di (d′i) of Fmdi (Fsi) there is thedimension d′j (dj) of Fsi (Fmdi), such that di and d′j (d′i anddj) are related by means of “1 - 1” relationship or di (d′i) isrelated to Fsi (Fmdi) by means of “1 - *” relationship.

Example (P1). Figures 7 and 8 show how the matchingschema in TM is identified for MDIs produced for informa-tion requirements IR2 and IR5, respectively, by means ofidentified “1 - 1” correspondence of their facts Lineitem. 2

Example (P2). Figure 9 shows an example inspired byTPC-H. A new PartMarket fact is introduced, which as-sesses the convenience of releasing a specific Part in a spe-cific market (i.e., Nation). Even though we may find no “1- 1” correspondence between PartMarket and the Supplier-PartSupplier fact, their MD spaces do coincide as they arearranged by the same dimensions: Nation and Part. 2

For each Fsi∈Si matched with Fmdi∈MDI, the merge-Facts(Fsi, Fmdi) operation is identified with its correspond-ing weight (see Table 2). If an equality between the givenfacts is not identified, the renameConcept(Fsi, Fmdi) is alsoadded. If for Fmdi our method does not identify a validmatching in TM , the insertFact(Fmdi) operation is consid-ered. All integration possibilities are listed with their corre-sponding weights and user feedback is required to continue.

5

Figure 8: Matching the MD Interpretation for IR5

Figure 9: Matching facts (P2)

3.4 Matching dimensionsFor each pair of matching facts (i.e., Fmdi, Fsi) identified

in the previous stage and chosen by the user, ORE contin-ues by conforming their dimensions. To this end, ORE inthis stage identifies possible matchings of the dimensionalconcepts of MDI inside the corresponding star schema Si

of TM (i.e., Fsi∈Si).Since a single dimension di consists of a partially ordered

set of individual levels, with single bottom (i.e., atomic) leveland with “to-one” relationships among the levels, each di-mension may be seen as a directed acyclic graph (DAG),where the vertices of the graph are individual levels and thedirected edges between them “→” are “to-one” relationships.Note that we assume the graph is guaranteed to be acyclicin a preliminar validation step of the requirement, since theloops would violate the MD integrity constraints [10].

To match each pair of levels, we consider the minimumpath of a valid MD relation (=, “1-1”, “1-*”or“*-1”) betweenthem, i.e., the path relating two level concepts of differentdimensions in the ontology and not including any other levelof these dimensions.

Example. In Figure 7, while we identify “* - 1” match-ings from Lineitem_dim to Orders and Nation, we do notconsider the one from Lineitem_dim to Customer since itgoes over Orders. 2

For each dimension of MDI we search for a compatibledimension in Si; i.e., the dimension with atomic levels re-lated with some kind of valid MD relation (=, “1-1”, “1-*”or “*-1”). For these two dimensions we search for possiblematchings among their individual levels. The problem maybe seen as a graph matching problem. Next, we present thedimension-matching, DM algorithm, which solves the prob-lem in our context. The algorithm, for two dimensions com-ing from MDI and Si, represented with their correspondingDAGs (i.e., Dmdi and Dsi), searches for the set of operations

(intOps) that are necessary to be applied over Si inside TMto appropriately integrate the new information requirement(i.e., its corresponding MDI).

Considering the topological order of the nodes in Dmdi

and Dsi, the algorithm recursively explores the paths inDmdi and Dsi starting from their atomic levels. In eachrecursive call, the matching between two levels and theirremaining hierarchies is considered. If there is no relationbetween two levels, DM stops searching for matchings intheir hierarchies. In doing so, DM discards unrelated partsof the dimensions and thus, prunes the search space.

Otherwise, following the topological order (Step 2c), DMkeeps searching for different possibilities to relate the lev-els and collects the corresponding operations along the way.In each recursive call, we consider the next two levels fromthe topological orders of Dmdi and Dsi, curLevelDmdi andcurLevelDsi, respectively (Step 2). If we can infer the fullmatch between curLevelDmdi and curLevelDsi (Step 2a),i.e., equality or synonyms, we consider the mergeLevels op-eration to be applied. Additionally, in the case of synonyms,our method potentially considers the renameConcept oper-ation over the curLevelDmdi (Step 2(a)ii).

Example. Figure 8 shows an integration possibility forthe Orders dimension, in the case of integrating IR5 intoTM satisfying IR1-IR4. A full matching (i.e., equality) isthen found for both Orders and Customer levels of the corre-sponding Dmdi. Thus, the mergeLevels operations are pro-posed for both Orders and Customer levels and they respec-tively involve insertDimDescriptor operations for transfer-ing o_shippriority and c_mktsegment level attributes. 2

For “1 - *” or “* - 1” relationships, we consider inserting anew level into the star Si (i.e., insertLevel operation). Addi-tionally, for “1 - *” or “* - 1” relationships (Steps 2(b)ii and2(b)iii), we consider inserting a roll-up relation, i.e., func-tional dependency, (i.e., insertRollUpRelation operation).

Example. In Figure 7, for all “* - 1” or “1 - *” match-ings found, insertion of a roll-up relation is proposed; e.g.,insertRollUpRelation(Lineitem_dim, Orders). 2

Furthermore, we continue matching the dimensions byconsidering different combinations of the remaining hierar-chies starting from the current levels (i.e., curLevelDmdi

and curLevelDsi) (Step 2d).Similarly to the previous stage, we may identify different

possibilities to conform the dimensions between MDI andSi, and therefore, these possibilities are weighted based onthe set of integration operations they imply and proposed tothe user. User feedback is then expected to determine howto conform the given dimensions.

3.5 Complementing the MD designThis stage considers the possible integration of the new

MDI in TM , identified in the previous stages, and furtherexplores the ontology to complement the future MD designwith new analytically interesting concepts. By exploringthe functional dependencies (“to-one” relationships) in theontology, new levels for the previously conformed dimensionsmay be identified. Furthermore, different datatype propertiesin the ontology may also be identified either as measures ofthe existing facts or descriptive attributes of the levels. Wedistinguish two cases:

• If the property has numerical datatype (e.g., integer,double), we consider using it as a measure iff the do-main concept of the property is identified as a fact.

6

Algorithm: DM

inputs: Dmdi, curLevelDmdi, Dsi, curLevelDsi, output: intOps

1. intOps := ∅;2. If related(curLevelDmdi, curLevelDsi) then

(a) If curLevelDmdi fully matches curLevelDsi then

i. intOps := add(intOps, mergeLevels(curLevelDmdi,curLevelDsi) );ii. If multiplicity(curLevelDmdi,curLevelDsi) = “1 - 1” then

intOps := add(intOps,renameConcept(curLevelDsi,curLevelDmdi));

(b) else

i. intOps := add(intOps, insertLevel(curLevelDmdi));ii. If multiplicity(curLevelDmdi,curLevelDsi) = “1 - *” then

intOps := add(intOps, insertRollUpRelation(curLevelDsi,curLevelDmdi));iii. If multiplicity(curLevelDmdi,curLevelDsi) = “* - 1” then

intOps := add(intOps, insertRollUpRelation(curLevelDmdi,curLevelDsi));

(c) levelsDmdi := getTopOrderLevels(Dmdi, curLevelDmdi); levelsDsi := getTopOrderLevels(Dsi, curLevelDsi);(d) Foreach pair(nextLevelDmdi from getNext(levelsDmdi), nextLevelDsi from getNext(levelsDsi)) do

i. intOps := add(intOps, DM(Dmdi, nextLevelDmdi, Dsi, nextLevelDsi));

3. return intOps;

• Otherwise, in the case that the domain concept of aproperty is identified as a level, our method suggestsusing the property as a new descriptor.

Different possibilities for enriching the current design arepresented to the designer as different integration operations(i.e., insertLevel, insertFactMeasure, insertDimDescriptor).The designer may decide how to complement the MD design.

Example. For the Orders dimension in Figure 8, we ex-plore the ontology and propose concept Region as a newtop level of the given dimension. Also, we propose differ-ent descriptors for the levels Ordes, Customer, Nation, andRegion; e.g., o_orderstatus, c_phone, and so on. 2

3.6 IntegrationHaving identified the matching of concepts and the op-

tions for complementing the MD design in the previous sta-ges, in this stage, ORE produces the final MD schema in atwo-phase process.

(I) Partitioning. The first phase starts from the MDschemas obtained in TM, so far. Each MD schema as itcan be represented with a directed acyclic graph (DAG) isfurther partitioned into different groups of concepts (sub-graphs), so that all concepts of one group:

1. Produce a connected subgraph and

2. Have the same MD interpretation (i.e., all concepts areeither factual of dimensional).

Each of these subgraphs of concepts further gives rise toa fact or a dimension of the final star schema.

(II) Folding. Starting from these partitions we obtainthe final star schema (or any other schema like a snowflakeschema). Inside each subgraph captured by a single par-tition, we consider only the concepts currently required bythe user, either provided with the requirement at hand ordiscovered when complementing the MD design in the on-tology (i.e., Stage 3). The concepts considered inside eachpartition are then collapsed to produce an element (i.e., factor dimension) of the final MD schema.

In these two phases, first, we relax the final schema fromknowledge currently irrelevant to the designer’s choices andthen, we conform the schema to well-known DW quality fac-tors (e.g., the structural complexity, understandability, anal-izability, maintainability, and others as discussed in [19]).

For example, collapsing the adjacent levels simplifies thecorresponding dimensions and lowers the number of roll-uprelationships, which has a significant influence in the overallstructural complexity of the schema.

While concepts with currently no interest to the designermay be hidden from the final MD schema design, TM stillpreserves all this knowledge for using it in future integra-tion steps. Furthermore, as TM contains the knowledgefrom data sources that answers the given set of informationrequirements, we can benefit from it for producing the ap-propriate data flow design (e.g., ETL flow) to manage thetransfer of the data from the sources to the produced targetMD schema. We consider this as a possible future work.

4. RELATED WORKAs we discussed in Section 1, following a monolithic ap-

proach for building a DW is considered problematic andthus, manual guidelines were given to overcome this issue(e.g., DW Bus Architecture [9]). Apart from traditionalDW designing approaches, e.g., [6, 7, 11], various works havestudied the problem of adjusting the DW systems to changesof the business environments. For dealing with such an issue,different directions have been followed.

Schema Evolution. The approaches that fall into thiscategory, e.g., [3, 15, 23], have as main goal to maintain theup-to-dateness of the existing DW models when a change oc-curs. While almost all of them propose a set of evolution op-erators (e.g., for adding/deletion of dimensions/levels/factsor their instances), some (e.g., [15]) also study the influenceof different evolution changes on the quality metrics of theDW (e.g., consistency and completeness). Similar problemshave been studied for ETL flows too (e.g., [14]).

Schema Versioning. Beside dealing with the changesby upgrading the existing schema, schema versioning ap-proaches have also focused on keeping the trace of thesechanges by separately maintaining different versions of theschema (e.g., [2, 4, 5]). Some of them (e.g., [2]) in additionto the versions resulting from real world changes, they alsostore and maintain the alternative versions which can simu-late various operational/business scenarios and propose newanalytical perspectives. Another work deals with the prob-lem of cross-version querying and introduces the concept ofaugmented schema, which keep track of change actions to

7

enable answering the queries spanning the validity of differ-ent versions [5].

One contribution of these works is the formal definition ofspecific alternation operators, which can be applied when anevolution change occurs. However, these works do not studyhow the information requirements actually affect such evo-lution changes. In this sense, our work complements themand starting from a given set of information requirements,it aims to automatically derive the changes of the currentschema necessary to be applied for satisfying these new re-quirements.

Incremental DW Design and DW Schema Integra-tion. There are works that have studied the problem ofincremental DW design; e.g., [13, 21]. For example, a pre-vious work considers the DW as a set of materialized viewsover the source relations and introduces a state space searchalgorithm for maintaining this set (i.e., view maintenance)to answer new queries [21]. Since a pure relational approachhas been followed, it uses equivalence transformation rulesto enhance the integration of new queries into the existingview set. That makes this approach not easily applicable tothe current heterogeneous environments. In fact, as it hasbeen become clear in the last decade, DW are more complexthan just a set of materialized views, especially when theETL flows come into play. On the schema integration side,there are works that use ontologies, to bridge the seman-tic gap among heterogeneous data (e.g., [20]). To deal withthe integration of heterogeneous DW schemas, another workproposes two approaches: loosely and tightly coupled [22].But, this work assumes that a structural matching amongschemas exists and proposes the d-chase procedure (inspiredby the chase procedure) for the chase of dimensional in-stances to ensure the consistency of the given matching.

Overall, the importance of information requirements intothe DW design process has been generally overlooked. Anexception is the work in [12] that starts from OLAP re-quirements expressed in sheet-style tables and later trans-lates them to single star schemas. However, the integrationproposed is based solely on union operations applied to thefacts and dimension hierarchies. Moreover, this work doesnot consider the heterogeneity and complex relations thatmay exist in such structures.

5. CONCLUSIONSOur research aims at providing an end-to-end, require-

ment-driven solution for designing MD schemata and ETLflows for the DW ecosystem. In the past, we presented oursystem called GEM, which translates information and busi-ness requirements into MD interpretations of these require-ments and also, produces a set of necessary ETL operationsfor managing the data flow from the sources and answeringthe given requirements [18]. GEM produces separate ETLand MD designs per requirement. In a recent work, we haveshown how to integrate those individual ETL designs to asingle ETL model [8]. In this paper, we have extended GEMto support the production of a single, unified MD schemathat fulfills all input requirements. We have discussed thechallenges and have presented an iterative method for con-solidating MD interpretations, through an example case.

There are many interesting future directions. A prominentone is to explore the functionality achieved and technologyproduced in this work, for fine-tune the data flow design(e.g., ETL).

6. ACKNOWLEDGEMENTSThis work has been partly supported by the Spanish Mini-

sterio de Ciencia e Innovacion under project TIN2011-24747.

7. REFERENCES[1] TPC-H, http://www.tpc.org/tpch/[2] Bebel, B., Eder, J., Koncilia, C., Morzy, T., Wrembel, R.:

Creation and management of versions in multiversion datawarehouse. In: SAC. pp. 717–723 (2004)

[3] Blaschka, M., Sapia, C., Hofling, G.: On schema evolutionin multidimensional databases. In: DaWaK. pp. 153–164(1999)

[4] Body, M., Miquel, M., Bedard, Y., Tchounikine, A.: Amultidimensional and multiversion structure for OLAPapplications. In: DOLAP. pp. 1–6 (2002)

[5] Golfarelli, M., Lechtenborger, J., Rizzi, S., Vossen, G.:Schema versioning in data warehouses: Enablingcross-version querying via schema augmentation. DataKnowl. Eng. 59(2), 435–459 (2006)

[6] Golfarelli, M., Maio, D., Rizzi, S.: The dimensional factmodel: A conceptual model for data warehouses. Int. J.Cooperative Inf. Syst. 7(2-3), 215–247 (1998)

[7] Husemann, B., Lechtenborger, J., Vossen, G.: Conceptualdata warehouse modeling. In: DMDW. p. 6 (2000)

[8] Jovanovic, P., Romero, O., Simitsis, A., Abello, A.:Integrating ETL processes from information requirements.In: DaWaK. pp. 65–80 (2012)

[9] Kimball, R., Reeves, L., Thornthwaite, W., Ross, M.: TheData Warehouse Lifecycle Toolkit. J. Wiley & Sons (1998)

[10] Mazon, J.N., Lechtenborger, J., Trujillo, J.: A survey onsummarizability issues in multidimensional modeling. DataKnowl. Eng. 68(12), 1452–1469 (2009)

[11] Mazon, J.N., Trujillo, J.: An MDA approach for thedevelopment of data warehouses. Decision Support Systems45(1), 41–58 (2008)

[12] Nabli, A., Feki, J., Gargouri, F.: Automatic construction ofmultidimensional schema from OLAP requirements. In:AICCSA. p. 28 (2005)

[13] Naggar, P., Pontieri, L., Pupo, M., Terracina, G., Virardi,E.: A model and a toolkit for supporting incremental datawarehouse construction. In: DEXA. pp. 123–132 (2002)

[14] Papastefanatos, G., Vassiliadis, P., Simitsis, A., Vassiliou,Y.: Policy-regulated management of ETL evolution. J.Data Semantics 13, 147–177 (2009)

[15] Quix, C.: Repository support for data warehouse evolution.In: DMDW. p. 4 (1999)

[16] Romero, O., Abello, A.: Automatic Validation ofRequirements to Support Multidimensional Design. DataKnowl. Eng. 69(9), 917–942 (2010)

[17] Romero, O., Calvanese, D., Abello, A., Rodriguez-Muro,M.: Discovering functional dependencies formultidimensional design. In: DOLAP. pp. 1–8 (2009)

[18] Romero, O., Simitsis, A., Abello, A.: GEM:Requirement-driven generation of ETL andmultidimensional conceptual designs. In: DaWaK. pp.80–95 (2011)

[19] Serrano, M.A., Calero, C., Piattini, M.: An experimentalreplication with data warehouse metrics. IJDWM 1(4),1–21 (2005)

[20] Skoutas, D., Simitsis, A.: Ontology-based conceptual designof ETL processes for both structured and semi-structureddata. Int. J. Semantic Web Inf. Syst. 3(4), 1–24 (2007)

[21] Theodoratos, D., Sellis, T.K.: Incremental design of a datawarehouse. J. Intell. Inf. Syst. 15(1), 7–27 (2000)

[22] Torlone, R.: Two approaches to the integration ofheterogeneous data warehouses. Distributed and ParallelDatabases 23(1), 69–97 (2008)

[23] Vaisman, A.A., Mendelzon, A.O., Ruaro, W., Cymerman,S.G.: Supporting dimension updates in an OLAP server.Inf. Syst. 29(2), 165–185 (2004)

8