Conceptual Data Warehouse Design - Data Warehouse Systems: Design and Implementation - page 87

Conventional databases are generally designed at the conceptual level using
some variation of the well-known entity-relationship (ER) model, although
the Unified Modeling Language (UML) is being increasingly used. Conceptual
schemas can be easily translated to the relational model by applying a set of
mapping rules.
Within the database community, it has been acknowledged for several
decades that conceptual models allow better communication between design-
ers and users for the purpose of understanding application requirements. A
conceptual schema is more stable than an implementation-oriented (logical)
schema, which must be changed whenever the target platform changes.
Conceptual models also provide better support for visual user interfaces;
for example, ER models have been very successful with users due to their
intuitiveness.
However, there is no well-established and universally adopted conceptual
model for multidimensional data. Due to this lack of a generic, user-friendly,
and comprehensible conceptual data model, data warehouse design is usually
directly performed at the logical level, based on star and/or snowflake
schemas (which we will study in Chap. 5 ), leading to schemas that are
dicult to understand by a typical user. Providing extensions to the ER
and the UML models for data warehouses is not really a solution to the
problem, since ultimately they represent a reflection and visualization of the
underlying relational technology concepts and, in addition, reveal their own
problems. Therefore, conceptual data warehousing modeling requires a model
that clearly stands on top of the logical level.
In this chapter, we use the MultiDim model, which is powerful enough to
represent at the conceptual level all elements required in data warehouse and
OLAP applications, that is, dimensions, hierarchies, and facts with associated
measures. The graphical notation of the MultiDim model is shown in Fig. 4.1 .
As we can see, the notation resembles the one of the ER model, which we
presented in Chap. 2 . A more detailed description of our notation is given in
Appendix A .
In order to give a general overview of the model, we shall use the example
in Fig. 4.2 , which illustrates the conceptual schema of the Northwind data
warehouse. This figure includes several types of hierarchies, which will be
presented in more detail in the subsequent sections. We next introduce the
main components of the model.
A schema is composed of a set of dimensions and a set of facts.
A dimension is composed of either one level or one or more hierarchies.
A hierarchy is in turn composed of a set of levels (we explain below the
notation for hierarchies). There is no graphical element to represent a
dimension; it is depicted by means of its constituent elements.
A level is analogous to an entity type in the ER model. It describes a set
of real-world concepts that, from the application perspective, have similar
characteristics. For example, Product and Category are some of the levels
in Fig. 4.2 . Instances of a level are called members .AsshowninFig. 4.1 a,