Database Reference
In-Depth Information
contribute to the future data warehouse architec-
ture practices to solve the new challenges. The
chapter also addresses challenges and research
directions on several emerging data warehousing
topics, such as real time data warehousing, data
privacy, and warehousing semi-structured and
unstructured data.
The rest of the chapter is organized as follows.
Section 2 describes data warehouse architecture
practices and related research works. Section 3
explores the emerging architecture trends and
describes the challenges that these trends bring to
different research explorations. Section 4 summa-
rizes the chapter and points our future directions
of data warehouse architecture.
frameworks. We proceed to define the basic
building blocks of data warehouse architecture
and describe an example architecture prototype.
We will then introduce a few industry practices
based on the prototype architecture.
Building Blocks of data
Warehouse Architecture
There are quite a few different definitions of
what is a data warehouse, such as in Inmon and
Kimball's topics (Inmon, 2005; Kimball & Ross,
2002). In a broad sense, the data warehouse can be
seen as an organization's electronically stored data
and is designed to facilitate business intelligence
processes such as reporting and data analysis. To
discover the basic elements in data warehouse
architectures, we begin with a brief introduction
of three major data warehouse architecture pat-
terns that have been used in different industry in
the past decades.
Figure 1 depicts the component-perspective
of a typical type of data warehouse architecture.
The figure describes a pattern where different
operational systems are connected to different data
marts which are then used by ad hoc queries or
reporting applications. These operational systems
are normally understood as systems that capture
the transactions of a line of business and they
should be thought of as outside the data warehouse.
A data mart is a relatively small repository that
contains a subset of the organization data. Data
marts are normally created to serve requirements
from specific business areas.
In this “point-to-point integration” architec-
ture, end users normally access data in the data
marts for certain analytical or reporting purposes.
This architecture pattern allows different data
marts to be directly connected to required source
of data and thus enable the “fast time-to-market”
requirements from the business side. However,
the amount of connections between operational
systems and data marts are becoming overwhelm-
ing over time. It is impossible to achieve a unified
dAtA WArehouSe
ArchItecture PrActIceS
IT system architecture is the conceptual design
that describes the structure and behavior of the
system. Likely, data warehouse architecture pres-
ents a formal description of the system, which is
organized in a way that supports reasoning about
its structural properties. Normally, data warehouse
architecture includes definitions of basic building
blocks of and describes how these building blocks
are constructed, connected and interrelated to
implement the overall data warehouse.
Similar to the different types of blueprints that
are made in building architecture, data warehouse
architecture is normally organized into different
perspectives (or, views) to describe the architecture
from the perspective of specific set of stakeholders
and their concerns. For instance, a component-
perspective describes the basic components and
layers of the architecture and how they form the
data warehouse system.
There are quite a few frameworks (Zachman,
1987; Kruchten, 1995) to define IT system archi-
tecture. However, we proceed to describe the data
warehouse architecture in an easy-understanding
way rather than following any of the existing
Search WWH ::




Custom Search