Databases Reference
In-Depth Information
same question of multiple departments, the answers provided by these independent
data marts were often different, thus calling into question the validity of all of the marts.
Many departments also encountered ongoing difficulty in managing these multiple data
marts and in maintaining extractions from operational sources (which were often du‐
plicated across multiple departments).
As architects took another look at their solutions, they began to realize that it was very
important to have a consistent view of the detailed data at an enterprise data warehouse
level. They also saw that data marts could solve business problems and provide return
on investment in an incremental fashion. Today, most successful implementers simul‐
taneously grow dependent data marts one business solution at a time while growing the
enterprise warehouse server in an incremental fashion.
The currently accepted definition of a data mart is simply a subject- or application-
specific data warehouse, usually implemented within a department. Typically, these data
marts are built to solve specific business needs and may include a large number of
summary tables. Data marts were initially thought of as being small, since not all the
detail data for a department or data from other departments need be loaded in the mart.
However, some marts get quite large as they incorporate data from outside sources
(sometimes purchased) that isn't relevant in other parts of the business.
In some organizations, data marts are deployed to meet specific project goals with
models optimized for performance for that particular project. Such data marts are re‐
tired when the project is completed and the hardware is reused for other projects. As
the analysis requirements for a business change, the topology of any particular data
warehouse is subject to evolution over time, so developers must be aware of this pos‐
sibility.
Increasing focus on cost savings, manageability, and compliance are leading many to
reexamine the wisdom of having a large number of physically separate data marts. As
a result, consolidation of marts into the enterprise warehouse is a common trend. More
recent versions of Oracle enable effective management of different user communities,
helping to make such consolidation possible.
The Operational Data Store and Enterprise Warehouse
The
operational data store
(ODS) concept also grew in popularity in the 1990s. The
ODS may best be described as a distribution center for current data. Like the OLTP
servers, the schema is highly normalized and the data is recent. The ODS serves as a
consolidation point for reporting and can give the business one location for viewing
current data that crosses divisions or departments. The popularity of the ODS grew in
part as a result of companies in the midst of acquisitions and mergers. These organi‐
zations often face mixed-application environments. The ODS can act as a staging lo‐
cation that can be used as the source for further transformations into a data warehouse
or into data marts.
