DATA WAREHOUSE DESIGN

ICDE 2001 Tutorial

Stefano Rizzi, Matteo Golfarelli

DEIS - University of Bologna, Italy

Motivation
Building a data warehouse for an enterprise is a huge and complex
task, which requires an accurate planning aimed at devising
satisfactory answers to organizational and architectural questions.
Despite the pushing demand for working solutions coming from
enterprises and the wide offer of advanced technologies from
producers, few attempts towards devising a specific methodology for
data warehouse design have been made. On the other hand, the
statistic reports related to DW project failures state that a major
cause lies in the absence of a global view of the design process: in
other terms, in the absence of a design methodology.

Summary
Ë Introduction to Data Warehousing
Ë Conceptual design of Data Warehouses
Ë Workload-based logical design for ROLAP
Ë Indexes for physical design

2
 Introduction
to Data Warehousing

Stefano Rizzi

Information Systems: profile and role

Ë Information systems are rooted in the relationship

between information, decision and control.

Ë An IS should collect and classify the information, by

means of integrated and suitable procedures, in
order to produce in time and at the right levels the
synthesis to be used to support the decisional
process, as well as to administrate and globally
control the enterprise activity.

4
 Information as a resource
Ë Information is an increasing value resource,
required from managers to schedule and monitor
effectively the enterprise activities.
Ë Information is the first matter which is transformed
by information systems like unfinished products are
transformed by manufacturing systems.

Manufacturing
system Finished product

Information
Information
system

Value of information
Ë Information is an enterprise resource like capital, first
matters, plants and people; thus, it has a cost.
Ë Hence, understanding the value of information is
important.

Value Strategic directions

Reports

Selected information
Primary information sources
Amount

6
 Different kinds of information systems
Senior
ESS ic
t eg managers
ra
St
MIS en
t
Middle
DSS g em
a managers
an
M
OAS d ge Knowledge and
le
KWS w data workers
no
K
TPS onal Operational
managers
i
r at
pe
O
Sales and Manufacturing Finance Accounting Human
marketing resources

The “Data Warehouse” phenomenon

Ë Usual complaints:
We have tons of data but we cannot access
them!
How can people playing the same role
produce substantially different results?
We want to slice and dice data in any
possible way!
Show me only what is important!
Everyone knows some data are incorrect...

(R. Kimball, The Data Warehouse Toolkit)

8
 Data Warehousing
Ì A collection of technologies and tools supporting the
knowledge worker (executive, manager, analyst) in
analysing data aimed at decision making and at
improving the knowledge assets of the enterprise.

Data Warehouse
At the core of the architecture of modern information systems,
it is a data repository:
ÁOriented to subjects
ÁIntegrated and consistent
ÁRepresenting temporal evolution
ÁNon volatile

The data warehouse is regularly refreshed, permanently growing,

logically centralised and easily accessed by users, essentially read-only

Data Warehouse
Operational data (relational, legacy) External data

ETL tools

Summary
data
Warehouse

Access
What-If
analysis
Reporting
Analysis tools tools
(OLAP)
Data mining
10
 Data Marts
Data Warehouse

Replication and broadcasting

Data mart
Marketing Geographical Client Supplier
Finance regions management management

11

Subject vs Process patient

region

charge consumption

reservations

Medical
reports

admissions

Emphasis on applications
Emphasis on subjects

12
 Integration and consistency
External
data
Schema Integration
Extraction DW
Transformation
Cleaning
Validation
Filtering
Loading
DB

wrappers mediators
Text files
loaders
13

Temporal evolution
OLTP
DW

Current values Snapshot

Restricted historical Rich historical content,

content, Time is included in keys,
Often time is not included Snapshots cannot be
in keys, updated
Data are updated

14
 Non-volatility
OLTP update
DW

load acce
ss

insert delete Huge data volumes:

from 20 GBs to some TBs
in a few years

Ë In a DW, no advanced techniques for transaction management

are required (differently from OLTP systems)
Ë Key issues are the query throughput and the resilience

15

DW vs. OLTP
• 90% ad hoc queries • 90% predefined
transactions
• Mostly read access • Read/write access
• Hundreds users • Thousands users
• Denormalised • Normalised
• Supports historical • Does not support historical
versions versions
• Optimised for accesses • Optimised for accesses
involving most involving a small database
database fraction
• Based on summary • Based on elemental data
data

16
 ROLAP (Relational OLAP)
Ë Intermediate level server between a relational back- end server
and the front-end client
Ë Specialised middleware
Ë Generation of SQL multi-statements for the back-end server
Ë Query scheduling

MOLAP (Multidimensional OLAP)

OLAP)
Ë Direct support of multi-dimensional views
Ë Special data structures (e.g., multi-dimensional arrays)
Ë Compression techniques
Ë Intelligent disk/memory caching
Ë Pre-computation
Ë Complex analysis
17

The technological progress

knowledge
Pattern
Warehousing

Data
Mining
Refinement

OLAP

Data
Source:
Warehousing Information
Statistics & Discovery
data reporting

1970 1980 1990 2000

18
 The Data Warehouse Market
4500
RDBMS
4000
Source: Shilakes, Tylman -
3500 OLAP Enterprise Information Portals
3000

2500
2000
400
1500 Data Marts
350
ETL
1000
300 Data Quality
500
250 Metadata
0
1998 1999 2000 2001 2002 200

150

100

50

0
1998 1999 2000 2001 2002

19

The DW life-cycle

Objective definition and Clearly determine the scopes,

planning define the borders, estimate
dimensions, choose the approach to
design, evaluate the benefits

Infrastructure design Choose the technologies and the

tools, analyse the architectural
solutions, solve the management
problems

Design and implementation

of applications Add iteratively new data marts
and applications to the warehouse

20
 Bibliography
Ë R. Barquin, S. Edelstein. Planning and Designing the Data Warehouse. Prentice Hall
(1996).
Ë S. Chaudhuri, U. Dayal. An overview of data warehousing and OLAP technology.
SIGMOD Record 26,1 (1997).
Ë G. Colliat. OLAP, relational and multidimensional database systems. SIGMOD Record
25, 3 (1996).
Ë M. Demarest. The politics of data warehousing.
Http://www.hevanet.com/demarest/marc/dwpol.html
Ë U.M. Fayyad, G. Piatetsky-Shapiro, P. Smyth. Data mining and knowledge discovery
in databases: an overview. Comm. of the ACM 39, 11 (1996).
Ë W.H. Inmon. Building the data warehouse. John Wiley & Sons (1996).
Ë S. Kelly. Data Warehousing in Action. John Wiley & Sons (1997).
Ë R. Kimball. The data warehouse toolkit. John Wiley & Sons (1996).
Ë R. Kimball, L. Reeves, M. Ross, W. Thornthwaite. The data Warehouse Lifecycle
Toolkit. John Wiley & Sons (1998).
Ë C. Shilakes, J. Tylman. Enterprise Information Portals.
Http://www.sagemaker.com/company/downloads/eip/indepth.pdf
Ë P. Vassiliadis. Gulliver inthe land of data warehousing: practical experiences and
observations of a researcher. Proc. DMDW’2000 (2000).
Ë J. Widom. Research Problems in Data Warehousing. Proc. CIKM (1995).

21

Conceptual modelling
for Data Warehousing
Stefano Rizzi

22
 Why a new conceptual model?
Ë While it is universally recognised that a DW leans on a
multidimensional model, there is no agreement on the
approach to conceptual modelling.
Ë On the other hand, an accurate conceptual design is
the necessary foundation for building a “good”
information system.
Ë The Entity/Relationship model is widespread in the
enterprises, but….

"Entity relation data models [...] cannot be understood

by users and they cannot be navigated usefully by DBMS
software. Entity relation models cannot be used as the
basis for enterprise data warehouses.” (Kimball, 96)

23

The multidimensional data model

model
Number of Coke
cans sold at Sales
BIGSTORES in
London on 10/10/99
Store

ime
T
Product
Number of Fanta
Number of Pepsi cans globally sold
cans sold at all
BIGSTORES on
10/10/99

24
 Basic terminology
Ë Fact (cube, target). It is a focus of interest for the decision-
making process; typically, it models an event occurring in the
enterprise world (sales, shipments, purchases). It is essential for
a fact to have some dynamic aspects, i.e., to evolve somehow
across time.
Ë Measures (attributes, variables, metrics, properties). They are
continuously valued (typically numerical) attributes which describe
a fact from different points of view. For instance, each sale is
measured by its revenue.
Ë Dimensions. They are discrete attributes which determine the
minimum granularity adopted to represent facts. Typical
dimensions for the sale fact are product, store and date.
Ë Hierarchies (dimensions). They contain dimension
attributes (levels, parameters) connected in a tree-like
structure by many-to-one relationships (functional dependencies).

25

DW modelling in the literature

Golfarelli et al. 98
Gyssens, Lakshmanan 97

Hüsemann et al. 00
Vassiliadis 98 Agrawal et al. 95

Sapia et al. 98
Cabibbo, Torlone 98
Datta, Thomas 97

Tryfona et al. 99
Franconi, Sattler 99 Li, Wang 96

26
 DW modelling in the literature

Golfarelli et al. 98
CONCEPTUAL Gyssens, Lakshmanan 97

Hüsemann et al. 00
Vassiliadis 98 Agrawal et al. 95

Sapia et al. 98
Cabibbo, Torlone 98
Datta, Thomas 97

Tryfona et al. 99
Franconi, Sattler 99 Li, Wang 96

LOGICAL
27

DW modelling in the literature

Golfarelli et al. 98
FORMAL Gyssens, Lakshmanan 97

Hüsemann et al. 00
Vassiliadis 98 Agrawal et al. 95

Sapia et al. 98
Cabibbo, Torlone 98
Datta, Thomas 97

Tryfona et al. 99
Franconi, Sattler 99 Li, Wang 96

GRAPHICAL
GRAPHICAL
28
 DW modelling in the literature

Golfarelli et al. 98
ALGEBRA Gyssens, Lakshmanan 97

Hüsemann et al. 00
Vassiliadis 98 Agrawal et al. 95

Sapia et al. 98
Cabibbo, Torlone 98
Datta, Thomas 97

Tryfona et al. 99
Franconi, Sattler 99 Li, Wang 96

29

DW modelling in the literature

Golfarelli et al. 98
Gyssens, Lakshmanan 97

Hüsemann et al. 00
Vassiliadis 98 Agrawal et al. 95

Sapia et al. 98
Cabibbo, Torlone 98
Datta, Thomas 97

Tryfona et al. 99 DESIGN

Franconi, Sattler 99 Li, Wang 96

30
 Conceptual models
Ë Sapia, Blaschka, Höfling, Dinter (1998)

dimension level

roll-up relationship
attribute

fact relationship

31

Conceptual models (2)

Ë Franconi, Sattler (1999)
property
target
dimension level

aggregated entity

32
 Conceptual models (3)
Ë Hüsemann, Lechtenbörger, Vossen (2000)
fact optional

dimension

dimension
level property attribute
measure

optional property attribute

aggregation path
33

The Dimensional Fact Model

The Dimensional Fact Model
Model (DFM) is a graphical
conceptual model for DWs, aimed to:
Á Effectively support conceptual design;
Á Provide an environment where user queries can be formulated
intuitively;
Á Enable communication between the designer and the final user
in order to refine requirement specification;
Á Supply a stable platform for logical design;
Á Provide an expressive and non-ambiguous documentation.

The DFM is independent of the target logical model

(multidimensional or relational)

34
 The Dimensional Fact Model (2)
Ë Three levels of conceptual documentation are provided:
Á Fact scheme: represents a fact of interest and the associated
measures, dimensions and hierarchies.
Á Data Mart scheme: summarizes the fact schemes which
constitute each data mart and emphasize the feasible
connections between them.
Á Data Warehouse scheme: shows the different data marts
emphasizing their overlaps, the different profiles of the users
accessing them, and the operational sources which feed
them.
Ë Each documentation level is integrated by glossaries
which explain the names adopted within the schemes,
define a connection between the DW data and the
operational sources, express data volumes.

Ë Data mart schemes are associated to the workload

specification.
35

Fact schemes
hierarchy
dimension
marketing department attribute
group category
type brand city
fact
brand
dimension product
day of week sales manager
holiday sale district
SALE store
year quarter month date qty sold store county state
revenue city
week unit price
no. of customers
measure

A fact expresses a many-to-many relationship between its dimensions

36
 Fact schemes (2)
Á A non-dimension attribute contains additional information
about a dimension attribute, and is typically connected to
it by a one-to-one relationship.
manager
It cannot be used manager
for aggregation. marketing
group
department
category
Á Some links between type brand city
attributes can product
brand
diet
be optional. day of week sales manager
holiday sale district
SALE store
year quarter month date qty sold store county state
revenue city
week address
unit price phone
no. of customers
non-dimension
attribute
promotion optionality
begin date
end date price reduction
ad type
cost
37

Fact schemes (3)

manager V.A.T.
Á Convergence
department
Á Cross-dimension attributes
Á Additivity, marketing
group category
non-additivity, brand city
type
non-aggregability
non-aggregability brand
Á Overlap cross-dimension
product
diet attribute
sale district
week SALE
year quarter month
qty sold store store county
revenue
unit price store city store state
fiscal fiscal fiscal fiscal date
year quarter month week no. of customers phone

day of week address

promotion
ad type begin date convergence
price reduction
end date

38
 The SHIPMENTS fact scheme

FACT SCHEME: SHIPMENT TO STORES

department

marketing category
group

type brand city

brand
product

week warehouse
year quarter month SHIPMENT warehouse state
TO STORES
warehouse
qty shipped city store state
fiscal fiscal fiscal fiscal date shipping cost store
year quarter month week
store city
day of week
mode
type
carrier

39

The INVENTORY fact scheme

FACT SCHEME: INVENTORY

department

marketing category
group
units per pallet
type brand city
package type
package size brand
weight product

week warehouse
year quarter month INVENTORY warehouse nation
date
warehouse
fiscal fiscal fiscal fiscal city
year quarter month week level
day of week AVG,
MIN

40
 The “supply chain”
component component from factory component

date factory date to factory date factory

PRODUCTION OF COMPONENT COMPONENT
COMPONENTS DELIVERY INVENTORY

product product package product warehouse

type
date factory date factory date factory
SHIPMENT TO
MANUFACTURING PACKAGING WAREHOUSE

mode

product product warehouse product promotion

date warehouse date store date store

WAREHOUSE SHIPMENT TO SALES
INVENTORY STORES

mode

41

Glossaries
ATTRIBUTE GLOSSARY: SHIPMENT TO STORES
name description domain card. query
product products 5000 select prodName,brandName,
brand brands 800 cityName,…
brand city Where brands are manufactured cities 50 from PRODUCTS P,BRANDS B,
type (pasta, soft drink, …) pr. types 200 CITIES C,…
where P.brandId =
category (food, clothing, music,…) pr. categories 10
B.brandId
department Deps. managing categories deps. 5 and B.cityId = C.cityId
marketing group Responsible for product types groups 20 and . . . . . . . . . . .
stores stores 100 select storeName,cityName,
store city cities 80 stateName from STORES
store state states 5 S,CITIES C
where S.cityId = C.cityId
.................... .................... ................. ......... . . . . . . . . . . . . .

MEASURE GLOSSARY: SHIPMENT TO STORES (sparsity = 0.01)

name description type query
qty shipped Quantity of each product being INTEGER select SUM(PS.qty)
shipped from PRODUCTS P,SHIP S,PRODSHIP
PS,…
where P.prodId = PS.prodId
and PS.shipId = S.shipId
and . . . . . . . . . . . . .
group by P.prodId,S.date, . . .
shipping cost Cost of the shipment MONEY . . . . . . . . . . . . .

refresh frequency: 1 per week; refresh technique: periodic complete

42
 Data mart schemes
Ë The data mart scheme is used to summarize the fact
schemes which constitute the data mart and to show
drill-across connections between them.
Ë It is a graph whose nodes are elemental and
overlapped fact schemes; the arcs are directed to
each overlapped scheme from its component
schemes, which in turn may be overlapped.
DATA MART SCHEME: SUPPLY CHAIN

PRODUCTION OF PRODUCTION COMPONENT DELIVERY AND COMPONENT

COMPONENTS AND DELIVERY DELIVERY INVENTORY INVENTORY

MANUFACTURING
MANUFACTURING AND PACKAGING PACKAGING

WAREHOUSE DISTRIBUTION SHIPMENT TO PRODUCT

INVENTORY CYCLE WAREHOUSE CYCLE

SHIPMENT TO SHIPMENT AND

STORES SALE SALE

43

The workload
Ë In principle, the workload for a data mart is dynamic
and unpredictable.
Ë In some commercial tools, the actual workload is
monitored while the DW is operating and the logical
and physical schemes are dynamically tuned.

Ë We claim that a core workload can, and should, be

determined a priori:
Á The user typically knows in advance which kind of data
analysis (s)he will carry out more often for decisional or
statistical purposes;
Á A substantial amount of queries are aimed at extracting
summary data to fill standard reports.

44
 The workload (2)

FACT SCHEME: SHIPMENT TO STORES

department

marketing category
group

type brand city

brand
product

week warehouse
year quarter month SHIPMENT warehouse state
TO STORES
warehouse
qty shipped city store state
fiscal fiscal fiscal fiscal date shipping cost store
year quarter month week
store city
day of week
mode
type
carrier

45

Data warehouse schemes

Ë At the highest abstraction level, the data warehouse
scheme shows the different data marts emphasizing
the fact schemes duplicated on two or more of them,
the different profiles of the users accessing them, and
the operational sources which feed them.
personnel
manager personnel
database
data mart
SALES
incentives
PERSONNEL
user
administrative
buyer manager
fact scheme
SUPPLY RENOVATION
CHAIN
operational db

SALES DEMAND file transfer

CHAIN purchases

orders restoration manual input

product works
database sale
claims executive

46
 Conceptual design
of Data Warehouses

Stefano Rizzi

47

Designing the DW
² Within a successful approach to DW design, top-down
and bottom-up strategies should be mixed.

Á When planning a DW, a bottom-up approach should be

followed.

Á One data mart at a time is identified and prototyped.

Á Each data mart is designed in a top-down fashion by

building a conceptual scheme for each fact of interest.

48
 Data Mart prototyping
Prototype first the data mart which:
Ë plays the most strategic role for the enterprise;
Ë can convince the final users of the potential benefits;
Ë leans on available and consistent data sources.

DM2 DM4

DM1

DM3
DM5

Source 3 Source 1 Source 2

49

Reference architecture

DW

Problem of designing
the reconciled data
Reconciled data (integration of
heterogeneous sources)

heterogeneous operational dbs

50
 Methodological framework
db administrator
analysis of the
operational db
requirement
specification designer
conceptual
design
workload
refinement
logical
final user design
physical
DWs are based on a pre-existing design
information system
51

Methodological framework (2)

E/R Conceptual Logical Physical

Scheme Scheme Scheme Scheme
Relational
Scheme
chiave negozio negozio città regione indirizzo resp.vendite
N1 …. …. …. …… ………
N2

chiavetempo chiave negozio chiave_prodotto quantvenduta incasso num_clienti

T1 N1 P1 10 1000000 2
T1 N1 P2 8 1200000 8
T1 N2 P5 15 1500000 5
… ….. …… …….

CONCEPTUAL LOGICAL PHYSICAL

DESIGN DESIGN DESIGN
Facts
Workload Target
Preliminary Target Workload
workload logical DBMS
model

52
 Conceptual design of the data mart
Ë Design is based on the documentation of the
underlying operational information system:
Á E/R schemes
Á Relational schemes

Golfarelli, Maio, Rizzi 98; Cabibbo, Torlone 98;

Moody, Kortink 00; Hüsemann, Lechtenbörger, Vossen 00

Ë Steps:
Á Find facts
Á For each fact:
• Navigate functional dependencies
• Drop useless attributes
• Define dimensions and measures
53

Finding facts

Á Within an E/R scheme, a fact is represented by either an

entity F or an n-ary relationship between entities E1...En
Á Within a relational scheme, a fact is represented by a
relation F.

The entities and relationships representing frequently

updated archives are good candidates to define facts;
those representing nearly-static archives are not.

54
Navigating functional dependencies
dependencies

Á Build a tree in which each vertex corresponds to an

attribute of the scheme;
Á The root corresponds to the identifier (key) of F;
Á For each vertex v, the corresponding attribute
functionally determines all the attributes corresponding
to the descendants of v.

55

Example (from the E/R scheme):

marketing manager department manager district no. state

group
MARKETING SALE
DEPARTM. in STATE
GROUP DISTRICT (1,1) (1,N)
(1,N) (1,N) (1,N)
type for category for county of
(1,1) (1,1) (1,N) (1,1)

TYPE of CATEGORY of COUNTY

(1,1) (1,N)
(1,1)
(0,N) (1,N)
unit sales
diet of date manager of
price
(0,1) (1,1) (1,1)
size (0,N) (1,N) PURCHASE (1,1) (0,N) (1,1) (1,N)
PRODUCT sale in STORE in CITY
TICKET
weight (1,N) qty
warehouse from product ticket number store address phone city
(1,N)
(1,N) (1,1) (1,N) (1,1)
address of BRAND produced
in
WAREHOUSE

brand

56
 Example (from the E/R scheme):

city
state county sales
qty date manager
brand size
diet address
weight phone
dept.
sale city county state
manager category
type product ticket store
manager district no
mark. grp. number district no+state
unit price

57

Dropping useless attributes

Ë Some attributes in the tree may be uninteresting for
the DW. In order to drop useless levels of detail, it is
possible to apply the following operators:
Á Pruning:
Pruning delete a vertex and its subtree.
Á Grafting:
Grafting delete a vertex and move its subtree. It is
useful when an attribute is not interesting but the
attributes it determines must be preserved.
sales sales
date manager manager
address address
sales
date manager
ticket store city state address store
number
date
ticket store
number

58
 Defining dimensions
Ë The choice of dimensions determines the fact
granularity.
granularity
Ë Dimensions must be chosen among the root children
in the attribute tree.
Ë Time should always be a dimension.

city
sales
qty manager
brand
diet address
weight phone
dept.
sale city county state
manager category
type product store
manager
mark. grp. date district no+state
unit price

59

Defining measures
Ë Measures must be chosen among the children of the root.
Ë Typically, measures are computed either by counting the
number of instances of F, or by summing (averaging, …)
expressions which involve numerical attributes.
Ë An attribute cannot be both a measure and a dimension.
Ë A fact may have no measures.

city
sales
qty manager
brand
diet address
weight phone
dept.
sale city county state
manager category
type product store
manager
mark. grp. date district no+state
unit price

60
 Granularity
Ë Defining the granularity of data is a primary issue in
determining performance. Granularity depends on the
queries users are interested in, and represents a
trade-off between query response time and detail of
information to be stored.
Á It may be worth adopting a finer granularity than that
required by users, provided that this does not slow down
the system too much.
Á Constrained by the maximum time frame for loading.
Ë Choosing granularity includes defining the refresh
interval.
Á Issues to be considered:
• Availability of operational data
• Workload characteristics
• The total time period to be analysed
61

WAND
a CASE tool for data warehouse design

Ë A design methodology is almost useless, if no CASE tool to

support it is provided.
Á Acquire the relational db scheme via ODBC
Á Carry out conceptual design
Á Define the workload
Á Calculate data volume
Á Carry out logical design
Á Create the documentation (including loading/feeding queries)

62
 Bibliography (1)
Ë K. Aberer, K. Hemm. A methodology for building a data warehouse in
a scientific environment. Proc. 1st Int. Conf. on Cooperative Inf.
Systems, Brussels (1996).
Ë R. Agrawal, A. Gupta, S. Sarawagi Modeling multidimensional
databases. IBM Research Report, IBM Almaden Research Center
(1995).
Ë M. Blaschka et al. Finding your way through multidimensional data
models. Proc. DEXA’98 (1998).
Ë L. Cabibbo, R. Torlone. A logical approach to multidimensional
databases. EDBT 98 (1998).
Ë A. Datta, H. Thomas. A conceptual model and algebra for on-line
analytical processing in data warehouses. Proc. WITS’97 (1997).
Ë E. Franconi, U. Sattler. A data warehouse conceptual model for
multidimensional aggregation. Proc. DMDW’99 (1999).
Ë M. Golfarelli , D. Maio, S. Rizzi The Dimensional Fact Model: a
conceptual model for data warehouses. Int. Jour. of Cooperative Inf.
Systems 7, 2&3 (1998).
Ë M. Golfarelli, S. Rizzi. Designing the data warehouse: key steps and
crucial issues. Jour. of Computer Science and Information
Management 2, 3 (1999).

63

Bibliography (2)
Ë M. Gyssens, L.V.S. Lakshmanan. A foundation for multi-dimensional
databases. Proc. 23rd VLDB, Athens, Greece (1997).
Ë B. Hüsemann , J. Lechtenbörger, G. Vossen. Conceptual data
warehouse design. Proc. DMDW’00 (2000).
Ë R. Kimball. The data warehouse toolkit. John Wiley & Sons (1996).
Ë D. Moody, M. Kortink. From enterprise models to dimensional models:
a methodology for data warehouse and data mart design. Proc.
DMDW’00 (2000).
Ë T. Bach Pedersen, C. Jensen. Multidimensional data modelling for
complex data. Proc. 15th ICDE, Sydney (1999).
Ë C. Sapia et al. Extending the E/R model for the multidimensional
paradigm. Proc. ER’98 (1998).
Ë N. Tryfona, F. Busborg, J. Christiansen. starER: A Conceptual Model
for Data Warehouse Design. Proc. DOLAP’99 (1999).
Ë P. Vassiliadis. Modeling multidimensional databases, cubes and cube
operations. Proc. 10th SSDBM Conf., Capri, Italy (1998).

64