Database Reference
In-Depth Information
a convergence. If in the invoice fact we had a
brand city attribute on the product hierarchy, rep-
resenting the city where a brand is manufactured,
there would be no convergence with attribute
(customer) city, since a product manufactured in
a city can obviously be sold to customers of other
cities as well.
that facilitates and disambiguates the exchange of
information. Whenever a demand-driven step is
adopted we recommend the adoption of formal-
isms that are intuitive and readable by non-expert
users in order to facilitate their interaction with
the designers. For this reason we believe that
ad-hoc formalism should be preferred whenever
business-users are involved.
SOLUTIONS AND
RECOMMENDATIONS
FUTURE TRENDS
Requirement analysis and conceptual design are
to a great extent responsible for the success of a
DW project since, during these two phases, the
expressivity of the multidimensional schemata is
completely defined. The paper has shown how
most of the risk factors can be handled by the
adoption of proper methodologies and formal-
isms. In particular, though some basic approaches
to user-requirement analysis are available in the
literature the adoption of a “pure” one is not suf-
ficient to protect from its own weaknesses. On
the other hand, some authors have proposed, and
tested in real projects, mixed techniques proving
that the three basic approaches are not mutually
exclusive but, as evidenced by (List, 2002), are
instead complementary and when used in parallel
may overcome many of the problems. In particular,
we believe that coupling a data-driven step with a
demand-driven one can lead to a design capturing
all the specifications and ensuring a higher level
of longevity as well as acceptance of the users.
Choosing whether the demand-driven step should
actually follow the goal-driven or the user-driven
approach mainly depends on the project pecu-
liarities that include several factors like budget
and time constraints, company environment and
culture, goal of the project, etc.
From the analysis of the methodological steps
the extent to which the two design phases studied
in this paper are related clearly emerges and their
synergy can be exploited at best if the two steps
share a common and well-structured formalism
While the topic of conceptual modelling in
DWing has been widely explored, the subject of
user requirement analysis as well as the relation-
ships between these design steps has been only
partially studied. In particular, while the way
for capturing functional requirements has been
paved, techniques for non-functional requirements
have been just sketched and still not massively
tested in real projects. Thus, we believe that the
effort in this area should be twofold: on the one
hand, a lot of research is still needed to obtain
a comprehensive approach to user requirement
analysis, on the other hand, the effectiveness of
this step can be exploited at best only if it can be
coupled with the conceptual design phase to form
a unique framework.
From the practitioners' point of view, we em-
phasize that the adoption of a structured approach
during user requirements analysis and conceptual
design is still extremely limited in real projects
(Sen & Sinha, 2005), while the need for solutions
that reduce the design efforts and that lower, at the
same time, the failure risk is strongly felt. This gap
is probably due to a lack of commercial design
software for DWs. In fact, though most vendors
of DW technology propose their own CASE solu-
tions (that are very often just wizards capable of
supporting the designer during the most tedious
and repetitive phases of design), the only tools
that currently promise to effectively automate
some phases of design are research prototypes.
In particular, (Golfarelli & Rizzi, 2001; Jensen et
Search WWH ::
Custom Search