romf object-oriented conceptual multidimensional modeling...

From Object-Oriented Conceptual

Multidimensional Modeling into XML

Sergio Luján-Mora, Enrique Medina, and Juan Trujillo

Departamento de Lenguajes y Sistemas InformáticosUniversidad de Alicante. SPAIN

{slujan,emedina,jtrujillo}@dlsi.ua.es

Abstract. Data warehouses and OLAP applications are based on themultidimensional (MD) modeling. In this context, we have previouslyproposed a conceptual modeling approach, based on the Uni�ed Mod-eling Language (UML), to consider main MD properties at the concep-tual level. In this paper, we present how to store a conceptual modelaccomplished with our approach using the eXtensible Markup Language(XML), a widely used standard for information exchange. To achieve thisgoal, we provide a DTD that allows us to generate valid XML documentsthat comprise all MD modeling properties considered by our approach,facilitating the interchange of information between enterprises. After-wards, we also provide XSLT stylesheets that allow us to automaticallygenerate HTML pages from XML documents, thereby supporting di�er-ent views of the same MD model easily. Finally, our CASE tool givessupport to all theoretical issues presented in the paper.

Keywords: Multidimensional modeling, UML, XML, DTD, Web

1 Introduction

Data warehouses (DW), OLAP applications and multidimensional databases(MDDB), based on the multidimensional (MD) modeling, provide companieswith huge historical information for the decision making process. In the lastyears, there have been some proposals to accomplish the conceptual MD model-ing of these systems [1][2][3,4][5]. Due to space constraints, we refer the reader to[6] for detailed comparison and discussion about these models. In this paper, wewill use the Object-Oriented (OO) conceptual MD modeling approach, basedon the Uni�ed Modeling Language (UML) [7], presented in [3,4] for a properconceptual MD modeling. This proposal considers main relevant MD issues atthe conceptual level such as the many-to-many relationships between facts anddimensions, degenerate dimensions, multiple and alternative path classi�cationhierarchies, and non-strict and complete hierarchies. Furthermore, our approachis supported by a CASE tool that allows us to semi-automatically generate theimplementation of a model into a target commercial OLAP tool such as InformixMetacube or Cognos Powerplay, thereby allowing us to check the validity andsuitability of the proposed approach.

On the other hand, it is widely accepted that software systems should havea proper documentation at a high level of abstraction to facilitate their change,adaptation and extension. The eXtensible Markup Language1 (XML) [8] israpidly being adopted as a speci�c standard syntax for the exchange of semi-structured data [9]. Furthermore, XML is an open neutral platform and vendorindependent meta-language standard, which allows to reduce the cost, complex-ity, and e�ort required in integrating data within enterprises and between enter-prises. One common feature of this semi-structured data is the lack of schema,so the data is describing itself. Therefore, XML documents can have di�erentstructures and can represent heterogeneous kinds of data (biological, statistical,medical, etc.).

Nevertheless, XML documents can be associated to a Document Type De�-nition (DTD) or an XML Schema [10], both of which allow us to describe andconstraint the structure of XML documents. In this way, an XML documentcan be validated against these DTDs or XML Schemas to check its correctness.Moreover, thanks to the use of eXtensible Stylesheet Language Transformations(XSLT) [11], XSLT stylesheets allow users to express their intentions about howXML documents should be presented, so they could be automatically trans-formed into other formats, e.g. HTML documents. An immediate consequence isthat we can de�ne di�erent XSLT stylesheets to provide di�erent visualizationsof the same XML document.

In this paper, we present how to store a conceptual model accomplished withour approach in an XML document. To help this goal, we de�ne the metamodelof our OO conceptual MD modeling approach using a UML class diagram, aswell as the implementation of this metamodel in a DTD. This DTD is usedto automatically validate XML documents that store all the MD properties ofour models in a standard interchange format, so any external application couldbene�t from the expressiveness of our conceptual MD approach. Furthermore,we use XSLT stylesheets and XML documents in a transformation process toobtain HTML pages that can represent di�erent views of the same MD model.

Following these considerations, the remainder of this paper is structured inFig. 1 as follows: Section 2 describes the basis of our OO conceptual MDmodelingapproach, as well as the metamodel de�nition for this approach using UML. Sec-tion 3 presents the DTD created from the metamodel that allows us to validateXML documents that store our models. Then, Section 4 uses XSLT stylesheetsto automatically generate HTML pages from XML documents, thereby allowingus to publish di�erent views of the model in the web. In Section 5 we present ourconclusions and bene�ts of our proposal. Finally, future works that are currentlybeing considered are presented in Section 6.

1 XML is a subset of the Standard Generalized Markup Language (SGML).

Fig. 1. Structure of sections of this paper.

2 Conceptual multidimensional modeling

Several conceptual MD models have been lately presented that provide an easyset of graphical structures to facilitate the task of conceptual MD modeling,as commented previously in the introduction. In this paper, we will use theOO approach based on the UML notation presented in [3,4], as it considersmany relevant MD aspects at the conceptual level. In this section, we will brie�ysummary how our approach represents both the structural and the dynamic partof MD modeling.

2.1 MD modeling with UML

In our approach, main MD modeling structural properties are speci�ed by meansof a UML class diagram in which the information is clearly separated into factsand dimensions.

Dimensions and facts are considered by dimension classes and fact classesrespectively. Then, fact classes are speci�ed as composite classes in shared ag-gregation relationships of n dimension classes. Thanks to the �exibility of sharedaggregation relationships that UML provides, many-to-many relationships be-tween facts and particular dimensions can be considered by indicating the 1..*cardinality on the dimension class role. For example, on the left hand side ofFig. 2, we can see how the fact class Sales has a many-to-many relationship withthe dimension class Product and a one-to-many relationship with the dimensionclass Time.

Fig. 2. Multidimensional modeling using UML.

By default, all measures in the fact class are considered additive. For non-additive measures, additive rules are de�ned as constraints and are also placedin somewhere around the fact class. Furthermore, derived measures can also beexplicitly considered (constraint / ) and their derivation rules are placed betweenbraces in somewhere around the fact class, as can be seen in Fig. 2.

Our approach also allows us to de�ne identifying attributes in the fact class,if convenient, by placing the constraint {OID} next to a measure name. In thisway we can represent degenerate dimensions [12][13], thereby providing otherfact features in addition to the measures for analysis. For example, we couldstore the ticket and line numbers as other ticket features in a fact representingsales tickets, as re�ected in Fig. 2.

With respect to dimensions, every classi�cation hierarchy level is speci�ed bya class (called a base class). An association of classes speci�es the relationshipsbetween two levels of a classi�cation hierarchy. The only prerequisite is thatthese classes must de�ne a Directed Acyclic Graph (DAG) rooted in the dimen-sion class (constraint {dag} placed next to every dimension class). The DAGstructure can represent both alternative path and multiple classi�cation hier-archies. Every classi�cation hierarchy level must have an identifying attribute(constraint {OID}) and a descriptor attribute (constraint {D}). These attributesare necessary for an automatic generation process into commercial OLAP tools,as these tools store this information in their metadata. The multiplicity 1 and1..* de�ned in the target associated class role addresses the concepts of strict-ness and non-strictness. In addition, de�ning the {completeness} constraint inthe target associated class role addresses the completeness of a classi�cation hi-erarchy (see an example on the center of Fig. 2). Our approach considers allclassi�cation hierarchies non-complete by default.

The categorization of dimensions, used to model additional features for anentity's subtypes, is considered by means of generalization-specialization rela-tionships. However, only the dimension class can belong to both a classi�cationand specialization hierarchy at the same time. An example of categorization forthe Product dimension can be observed on the right hand side of Fig. 2.

Regarding the dynamic part, we also provide a UML-compliant class notation(called cube class) to specify initial user requirements. A cube class is structured

Fig. 3. The UML class diagram to represent the metamodel schema.

into three sections: measures, to specify which fact attributes are analyzed; slice,to express constraints in terms of �lters; and dice, to de�ne grouping conditionsof the data. Later, a set of basic OLAP operations (e.g. roll-up, drill-down, slice,etc.) is provided to accomplish the further data analysis phase from these cubeclasses.

Finally, this approach provides a set of modules with adequate transformationrules to export the accomplished conceptual MD model into a commercial OLAPtool, which allows us to check the validity of the proposed approach.

2.2 Metamodel

In this section, we present how to model the metamodel of our OO concep-tual MD models using a UML class diagram. The metamodel schema of ourOO aproach is illustrated in Fig. 3, where the class that represents the generalinformation about any model is allocated in the class goldmodel.

This schema represents the main MD properties of our conceptual modelingapproach. In this way, dimensions and facts are represented using the classesdimclass and factclass, respectively. Then, the association class sharedaggis used to express the shared aggregation relationships between facts and dimen-sions. Notice that many-to-many relationships between facts and dimensions aresupported by assigning the same value �M� to both attributes roleA and roleB

in the class sharedagg.With respect to fact attributes, the class factatt supplies the attribute OID

to indicate the role played by the fact attribute, e.g. identi�er (as a degener-ated dimension) or measure for analysis. Later, the attribute derivationRule

allows us to specify its counterpart for derived measures. Additivity is consid-ered using the association class additivity between the classes factatt anddimclass. The possible combinations of di�erent types of aggregation, i.e. SUM,AVG, MIN, MAX, COUNT, NOT2, are de�ned by giving boolean values to theirequivalent attributes, i.e. isSUM, isAVG, isMIN, isMAX, isCOUNT, isNOT.

On the other hand, dimensions may have one or more hierarchies. The �rstlevel of the hierarchy for both classi�cation and categorization relationships isconsidered as the default hierarchy using the classes asoclevel and catlevel.From these classes, the rest of the hierarchy structure is derived using the classesrelationasoc and relationcat respectively. In order to include dimensionalattributes for each level in the dimension hierarchy, both types of relationshipsare super-typed into the class level, which owns the attributes in an aggregationrelationship with the class dimatt, with the possibility to indicate whether theyare identifying or descriptor attributes by giving values to attributes OID and D

within the given class. Notice that non-strict hierarchies between dimension as-sociations are also supported by assigning the same value �M� to both attributesroleA and roleB in the class relationasoc. Furthermore, completeness is alsosupported by assigning the value `true' to the attribute completeness withinthe class relationasoc.

Regarding the dynamic part, the class cubeclass along with the class sliceallows us to specify �lters in initial user requirements. In addition, groupingconditions are represented by means of the dice aggregation between the classescubeclass and levels.

Every issue considered in the UML class diagram of Fig. 3 that expressesa MD feature at the conceptual level is represented in a DTD element. In thisway, any MD model accomplished by our approach can be stored in an XMLdocument that should be validated against the DTD.

3 XML DTD and XML Document

As said in the introduction, our goal is to provide a common standard format tostore and interchange models accomplished by our OO conceptual approach. Toachieve this goal, this section presents the DTD3 corresponding to the metamodelschema previously de�ned. This DTD allows us to structure XML documentsthat store our MD models together with all the MD expressiveness commentedin Section 2.

3.1 XML DTD

The representation of the DTD as a tree structure is illustrated in Fig. 4 forthe sake of clearness and comprehension. As it can be observed, we denote everynode of the tree with a label. Then, every label has its correspondence with one

2 To represent a non-additive measure.3 The complete de�nition of the DTD has more than 150 lines and it is not completelyshown due to space constraints.

Fig. 4. The DTD represented as a tree structure.

element in the DTD. Following a top-down path in the tree, we clearly identify allthe MD properties supported by our OO conceptual MD model. More precisely,the root of the tree is tagged as golmodel and corresponds to the element

<!ELEMENT GOLDMODEL (FACTCLASSES, DIMCLASSES, CUBECLASSES?)>

while the child nodes of a node represent the subelements of an element in theDTD4. To indicate the multiplicity (cardinality) of the subelements, we use thestandard modi�ers provided by the DTD syntax: ? for 0 or 1, * for 0 or more,and + for 1 or more. Furthermore, we de�ne additional tags (in plural form)in order to group common elements together, so that they can be exploited toprovide optimum and correct comprehension of the model, e.g. tags in plural likefactclasses or dimclasses.

Within this DTD, fact classes labeled factclasses in Fig. 4, may haveno fact attributes to consider fact-less fact tables, as can be observed in themultiplicity (?) for the tag factatts:

<!ELEMENT FACTCLASSES (FACTCLASS+)> <!ATTLIST FACTATT<!ELEMENT FACTCLASS (FACTATTS?, id ID #REQUIRED

METHODS?, SHAREDAGGS?)> name CDATA #REQUIRED<!ATTLIST FACTCLASS atomic %Boolean; "true"

id ID #REQUIRED type CDATA #REQUIREDname CDATA #REQUIRED description CDATA #IMPLIEDcaption CDATA #IMPLIED initial CDATA #IMPLIEDdescription CDATA #IMPLIED derivationRule CDATA #IMPLIEDshowAtts %Boolean; "true" OID %Boolean; "false">showMethods %Boolean; "true" <!ELEMENT SHAREDAGGS (SHAREDAGG+)>

4 The attributes of the elements are not represented in the tree for the sake of sim-plicity.

autoResize %Boolean; "true"> <!ELEMENT SHAREDAGG EMPTY><!ELEMENT FACTATTS (FACTATT+)> <!ATTLIST SHAREDAGG<!ELEMENT FACTATT (ADDITIVITY*)> dimclass IDREF #REQUIRED<!ELEMENT ADDITIVITY EMPTY> name CDATA #IMPLIED<!ATTLIST ADDITIVITY description CDATA #IMPLIED

dimclass IDREF #REQUIRED roleA %Multiplicity; "M"isNOT %Boolean; "false" roleB %Multiplicity; "1">isSUM %Boolean; "false"isMAX %Boolean; "false"isMIN %Boolean; "false"isAVG %Boolean; "false"isCOUNT %Boolean; "false">

In case that fact attributes exist in the fact class, derivation rules can be de�nedfor these attributes by means of derivationRule in order to express calculatedmeasures. Additivity is also supported in terms of the DTD element additivityalong with the information about how a measure is aggregated along a particulardimension. Notice that many-to-many relationships between facts and dimen-sions can also be expressed by assigning the same value �M� to both attributesroleA and roleB in the DTD element sharedagg.

With respect to dimensions, the following fragment of the DTD containselements to express dimensions and classi�cation hierarchies by means of asso-ciation relationships:

<!ELEMENT DIMCLASSES (DIMCLASS+)> <!ELEMENT RELATIONASOCS (RELATIONASOC+)><!ELEMENT DIMCLASS (ASOCLEVELS?, <!ELEMENT RELATIONASOC EMPTY>

CATLEVELS?)> <!ATTLIST RELATIONASOC<!ELEMENT ASOCLEVELS (ASOCLEVEL+)> child IDREF #REQUIRED<!ELEMENT ASOCLEVEL (DIMATTS?, name CDATA #IMPLIED

RELATIONASOCS?, METHODS?)> description CDATA #IMPLIED<!ELEMENT DIMATTS (DIMATT+)> roleA %Multiplicity; "1"<!ELEMENT DIMATT EMPTY> roleB %Multiplicity; "M"<!ATTLIST DIMATT completeness %Boolean; "false">

id ID #REQUIRED <!ATTLIST ASOCLEVELname CDATA #REQUIRED id ID #REQUIREDatomic %Boolean; "true" name CDATA #REQUIREDtype CDATA #REQUIRED description CDATA #IMPLIEDdescription CDATA #IMPLIED showAtts %Boolean; "true"initial CDATA #IMPLIED showMethods %Boolean; "true"derivationRule CDATA #IMPLIED autoResize %Boolean; "true">OID %Boolean; "false"D %Boolean; "false">

Notice that attributes within these elements in the DTD allow us to expressall the MD properties of our model. In this way, non-strictness may be de�nedby assigning the same value �M� to both attributes roleA and roleB in theDTD element relationasoc, along with completeness by means of the DTDattribute completeness. Moreover, identifying and descriptor attributes withindimensions can be de�ned using the DTD attributes OID and D, respectively indimatt.

3.2 XML Document

Once the speci�cation for the DTD is accomplished, XML documents may begenerated by our CASE tool from the OO conceptual models, as re�ected in Fig.5. Therefore, Fig. 6 shows the visualization of an XML document generated byour CASE tool in a popular web browser, i.e. Microsoft Internet Explorer.

Fig. 5. An XML document generated by our CASE Tool.

Fig. 6. An XML document displayed in Microsoft Internet Explorer without XSLT.

Furthermore, this browser brings the possibility to validate an XML docu-ment against our DTD5, so all the MD properties of our models are considered.

4 XSLT and the Web

Another relevant issue of our approach was to provide di�erent views of the MDmodels in the web. However, nowadays only some web browsers support XML.In addition to this inconvenience, XML documents only contain data, so thatno information about presentation aspects is included. To solve this problem,XSL Formatting Objects6 (XSL FO) [14] is a recent technology that allows usto de�ne the presentation for XML documents, although there is no currentbrowser that supports it. As a consequence, we are currently forced to transformXML documents to HTML pages7 in order to publish them in the web.

The best method to accomplish this task is the use of XSLT, as a languagefor transforming XML documents into other XML documents. XSLT stylesheetsdescribe a set of patterns (templates) to match both elements and attributesde�ned in a DTD, in order to apply speci�c transformations for each matchconsidered. Thanks to XSLT, the source document can be �ltered and reorderedin constructing the resulting output. Therefore, our XML documents can betailored to represent di�erent views of the same MD model in two ways: usingone XSLT stylesheet for each view or using only one global stylesheet with aninput parameter to select the desirable view.

As an example, Fig. 7 illustrates the overall transformation process for aMD model composed of two fact classes sharing common dimensions. The MDmodel is stored in an XML document and an XSLT stylesheet is provided togenerate di�erent views of the MD model as di�erent HTML pages. These viewscorrespond to fact class 1 and 2 respectively and they only contain relevantinformation about each fact class in the model, i.e. dimensions in the MD modelnot belonging to a particular fact class are not shown in the corresponding view.

In our work, we have used two di�erent processors: Microsoft XML Core Ser-vices (MSXML) 4.08 (formerly known as the Microsoft XML Parser) and InstantSaxon 6.59. Both of them are full compliance with XSLT 1.0. However, InstantSaxon also allows the use of XSLT 1.110 features, including xsl:script andxsl:document. Therefore, we have considered two approaches: one for version

5 It is necessary to install the add-in Internet Explorer Tools for Validating XML andViewing XSLT Output, available from http://msdn.microsoft.com.

6 XSL FO describes how XML documents will look when displayed or printed.7 Actually, the XML documents are transformed to XHTML 1.0. In addition, we alsouse Cascading Style Sheets (CSS), because it gives us more control over how pagesare displayed.

8 The MSXML 4.0 features are available in Internet Explorer only via scripting. It canbe downloaded from http://msdn.microsoft.com.

9 It is available from http://saxon.sourceforge.net.10 The status of this version is �working draft�. Besides, XSLT 2.0 is in �requirements

working draft�.

Fig. 7. Generating di�erent views in HTML from the same MD model.

1.0 that generates an only HTML page with internal links, and the other forversion 1.1 that has the bene�t of generating a collection of HTML pages withlinks between them (the number of pages depends on the number of fact classesand dimension classes de�ned in the model).

Due to space constraints, it is not possible to include the complete de�nitionof the XSLT stylesheet here. Therefore, we only exhibit some fragments of theXSLT. The �rst example shows the instructions that generate the HTML codeto display information about fact attributes (factatt):

<xsl:template match="FACTATT"><tr bgcolor="#00ffff"><td><xsl:value-of select="@name"/></td><td><xsl:value-of select="@atomic"/></td><td><xsl:value-of select="@type"/></td><td><xsl:value-of select="@description"/></td><td><xsl:value-of select="@initial"/></td><td><xsl:value-of select="@derivationRule"/></td><td><xsl:value-of select="@OID"/></td>

</tr></xsl:template>

Notice that XSLT instructions and HTML tags are intermingled. The XSLTprocessor copies the HTML tags to the transformed document and interpretsany XSLT instruction encountered. Applied to this example, the value of theattributes of the element factatt are inserted in the resulting document inan HTML table; we can notice the attributes commented in Section 2: atomic,derivation rule, OID, and so on.

As above commented, XSLT 1.1 allows to create di�erent HTML outputsand connect them from an only XML document. The following instructions showhow we create the links between the main page, the page that represents the MDmodel, and the pages that correspond to the fact classes:

<xsl:template match="FACTCLASS"><xsl:variable name="url" select="@id"/><tr><td></td><td><a href="{$url}.html"><xsl:value-of select="@name"/></a></td><td><xsl:value-of select="@description"/></td>

</tr><xsl:document href="{$url}.html"><html><head><title>Fact class: <xsl:value-of select="@name"/></title></head><body bgcolor="mintcream">

As we have de�ned the @id attribute of factclass as ID in the DTD, andthus, it has a unique value, we use it as the name of the new documents(<xsl:document href="{$url}.html">) and the target document in the links(<a href="{$url}.html">).

4.1 Exploring the model in a web browser

The resulting HTML pages allow us to navigate through the di�erent views ofthe model in a web browser. All the information about the MD properties of themodel is represented in the HTML pages.

For example, in Fig. 8 we show an example of navigation for one of the views.The �rst page is showed in Fig. 8.1 and contains the general description of themodel: name, creation date, last modi�ed, and the names of the fact classes anddimension classes, which are active links.

Whenever it is possible, there is a link connecting di�erent pieces of informa-tion. For example, if the fact class Sales is selected, the page showed in Fig. 8.2is loaded. This page shows the information about the selected fact class: name,measures, methods, and shared aggregations. In the example, Sales containsthree measures, inventory, num_ticket and qty, and the �rst one is an activelink because it has additivity rules. If the link is selected, a new �oating page isshowed (Fig. 8.3) with the additivity rule.

Finally, Fig. 8.4 shows the de�nition of the dimension class Time: attributes,methods, association levels and categorization levels. In this example, this di-mension class has two association levels: Month and Week, which are again activelinks and allow us to continue exploring the model. This page can be reachedfrom pages in Fig. 8.1, 8.2, and 8.3, because there exists a relationship betweenthem.

5 Conclusions

We have presented how to store MD models accomplished by our OO concep-tual approach, based on UML, in XML documents. In this way, we are able toconsider the main MD properties from a conceptual level such as many-to-manyrelationships between facts and dimensions, additivity, non-strictness and so on.

To validate these XML documents, we have de�ned the metamodel thatcorresponds to our models by means of a DTD. The bene�t of this approach is

8.1 8.2

8.3 8.4

Fig. 8. Model navigation in the web using a browser.

that we make use of standard technology that is increasingly becoming acceptedtogether with the task of MDmodeling by means of our OO conceptual approach.

Furthermore, we provide XSLT stylesheets that allow us to generate di�erentviews on a HTML format of the same MD model. Therefore, management ofdi�erent views for di�erent users could be easily achieved.

6 Future Work

Due to the rapid evolution of the used technology, we are considering to adapt ourproposal to the new emerging standards. In this sense, our intention is to providean XML Schema [10] instead of DTDs to represent our metamodel. XML schemasprovide a means for de�ning the semantics of XML documents, not provided byDTDs. For example, we can de�ne types for the attributes in order to constrainttheir values. Furthermore, some MD properties like completeness, non-strictnessor many-to-many relationships between facts and dimensions could be easilyexpressed in a more natural way by means of minOccurs and maxOccurs clausesprovided by the XML Schema syntax.

With respect to the presentation, XSL FO can be used to specify in deeperdetail the pagination, layout, and styling information that will be applied toXML documents. However, to the best of our knowledge, there are no currenttools that completely provide support for XSL FO.

From the architecture perspective, we run this process using a client/servertechnology, i.e. the XSLT stylesheet is applied to the XML document in theserver and the HTML is returned to the client browser. In the future, when thebrowsers completely support XML and XSLT, the transformation will be ableto be performed in the browser. This approach has the advantage of removingsome of the processing load from the server.

Finally, we are currently studying the CommonWarehouse Metamodel (CWM)[15] as a common framework to easily interchange warehouse metadata betweendistributed heterogenous environments. We have detected some semantics of ourconceptual model that are not supported by the MD submodel of the CWM.Therefore, a future line of research is to extend the CWM for supporting all theexpressiveness of our OO conceptual approach.

References

1. Golfarelli, M., Rizzi, S.: A methodological Framework for Data Warehouse De-sign. In: Proc. of the ACM 1st Intl. Workshop on Data warehousing and OLAP(DOLAP'98), Washington D.C., USA (1998) 3�9

2. Sapia, C., Blaschka, M., Hö�ing, G., Dinter, B.: Extending the E/R Model forthe Multidimensional Paradigm. In: Proc. of the 1st Intl. Workshop on DataWarehouse and Data Mining (DWDM'98). Volume 1552 of LNCS., Springer-Verlag(1998) 105�116

3. Trujillo, J., Gómez, J., Palomar, M.: Modeling the Behavior of OLAP ApplicationsUsing an UML Compilant Approach. In: Proc. of the 1st Intl. Conf. On Advances inInformation Systems (ADVIS'00). Volume 1909 of LNCS., Springer-Verlag (2000)14�23

4. Trujillo, J., Palomar, M., Gómez, J., Song, I.Y.: Designing Data Warehouses withOO Conceptual Models. IEEE Computer, special issue on Data Warehouses 34(2001)

5. Tryfona, N., Busborg, F., Christiansen, J.: starER: A Conceptual Model for DataWarehouse Design. In: Proc. of the ACM 2nd Intl. Workshop on Data warehousingand OLAP (DOLAP'99), Kansas City, Missouri, USA (1999)

6. Abelló, A., Samos, J., Saltor, F.: Bene�ts of an Object-Oriented MultidimensionalData Model. In Dittrich, K., Guerrini, G., Merlo, I., Oliva, M., Rodriguez, E., eds.:Proc. of the Symposium on Objects and Databases in 14th European Conferenceon Object-Oriented Programming (ECOOP'00). Volume 1944 of LNCS., Springer-Verlag (2000) 141�152

7. Object Management Group (OMG): Uni�ed Modeling Language (UML). Internet:http://www.omg.org/cgi-bin/doc?formal/01-09-67 (2001)

8. World Wide Web Consortium (W3C): eXtensible Markup Language (XML) 1.0(SE). Internet: http://www.w3.org/TR/2000/REC-xml-20001006 (2000)

9. Abiteboul, S., Buneman, P., Suciu, D.: Data on the Web: From Relations toSemistructured Data and XML. Kaufman Publishers (2000)

10. World Wide Web Consortium (W3C): XML Schema. Internet:http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/ (2001)

11. World Wide Web Consortium (W3C): XSL Transformations (XSLT) Version 1.0.Internet: http://www.w3.org/TR/1999/REC-xslt-19991116 (1999)

12. Giovinazzo, W.: Object-Oriented Data Warehouse Design. Building a star schema.Prentice-Hall, New Jersey, USA (2000)

13. Kimball, R.: The data warehousing toolkit. 2 edn. John Wiley (1996)14. World Wide Web Consortium (W3C): Extensible Stylesheet Language (XSL) 1.0.

Internet: http://www.w3.org/TR/2001/REC-xsl-20011015/ (2001)15. Object Management Group (OMG): Common Warehouse Metamodel (CWM).

Internet: http://www.omg.org/cgi-bin/doc?ad/2001-02-01 (2000)

romf object-oriented conceptual multidimensional modeling...

Documents