Chapter 4 • The Data Resource 99
- Data models can be developed using proven compo-
nents evolved from cumulative experiences. These data
models are kept up-to-date by the provider as new
kinds of data are recognized in an industry (e.g., RFID).
- Projects take less time and cost less because the
essential components and structures are already
defined and only need to be quickly customized to
the particular situation.
- Because prepackaged data models are developed
from best practices, your data model is easier to
evolve as additional data requirements are identified
for the given situation. You avoid missing important
components because prepackaged data models are
designed using thousands of business questions and
performance indicators.
- Adaptation of a data model from your DBMS vendor
usually means that your data model will easily work
with other applications from this same vendor or
their software partners.
- A prepackaged data model provides a starting point
for asking requirements questions that will help to
surface unspoken requirements.
- Prepackaged data models use structures that promote
holistic and flexible, rather than narrow and rigid,
views of data in an organization, thus promoting
managing data as an organizational resource.
- If multiple companies in the same industry use the
same universal data model as the basis for their orga-
nizational databases, it may be easier to share data for
interorganizational systems (e.g., reservation systems
between rental car and airline firms).
Data modeling methods are neither simple nor
inexpensive to conduct. They require considerable time, orga-
nizational commitment, and the assignment of very knowl-
edgeable managers and data specialists. In order to deal with
these concerns, certain guidelines have been developed:
- ObjectiveThe modeling effort must be justified by
some clear overriding need, such as coordination of
operational data processing, flexibility to access
data, or effectiveness of data systems. The less clear
the goal, the higher the chance for failure.
- ScopeThe coverage for a data model must be care-
fully considered. Generally, the broader the scope,
the more difficult the project is to manage. Scope
choices include corporate-wide, division, areas with
particular high-impact needs, and a particularly
important or willing business function (e.g., sales).
- OutcomeChoices here include a subject area database
definition (e.g., all data about customers), identification
of common data capture systems to be shared by sever-
al departments (replacing current separate databases),
managerial and strategic databases (see Figure 4.3,
which will be referred to several times in this chapter)
and access services to support the information needs of
these levels of management, and a more nebulous
architecture for future databases. The more uncertain
the outcome, the lower the chances for success.
Operational
Transfer and
Integration Systems
Strategic Databases
Managerial
Transaction Data
Capture
Systems
Analysis and Presentation
FIGURE 4.3 The Data Pyramid
