Thus, this methodology tries to handle
such risk dividing the project into units called ???builds.??? Each cycle of these builds
consists of the following stages: valuation, requirements, design, implementation,
final testing, and distribution. Microsoft methodology proposes eight activities:
four devoted to creating the data warehouse and four to reviewing and maintaining
it, with feedback from the processes. Kimball et al. (1998) propose a ???federated???
architecture, with data marts based on star schemas. All the methods are focused
on the development of the infrastructure for decision support systems, but none of
them handles data quality in a comprehensive fashion.
There are several proposals addressing the design of data warehouses and data
marts. Many of them use some of the techniques we propose in this chapter. However,
these works do not compare with ours because the goals are different: we are
interested in the requirement elicitation process itself, and not in the design process,
which belongs to a later stage. For example, the work by Moody and Kortink (2000)
proposes the use of the entity-relationship model for data warehouse design. With
a different approach, Bonifati, Cattaneo, Ceri, Fuggetta, and Paraboschi (2001)
introduced an interesting requirements-driven design methodology for data marts.
However, they focus on the design stage, and only address functional requirements
in the requirements elicitation phase (they use GQM for this task).
Pages:
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146