Moving Forward with the On Demand Real-time Enterprise

Chapter 3. Architectural considerations 81

Until today many business intelligence environments have been seen as

standalone systems. They have had specific dependencies on various

operational systems being capable of delivering data to the data warehouse in a

timely manor. And, they have typical been used for business areas such as

point-in-time reporting and detailed ad-hoc analytics. They are also batch

oriented systems which are updated on a monthly, weekly or daily basis. The

data warehouse has so far had a highly specialized usage, which is supported by

the creation of data marts or cubes to satisfy specific analytical business needs.

New business demands require the business intelligence environment to be

capable of supporting the more diverse workload of the real-time enterprise. The

data warehouse should be capable of supporting a real-time analytics

environment as well as providing the traditional historic representation of

information. At the same time, it also needs operate in an integrated

environment. Thus the need for a layered data architecture. We represent such

an architecture in Figure 3-2.

Figure 3-2 The layered data architecture

3.1.4 The layered data warehouse architecture

The same need can be applied to data warehousing. A layered data warehouse

architecture can provide a logical view of how an enterprise data repository is

built, and how it enables analytics and other key business applications.

By layering the data warehouse it enables layering in functionality without

requiring the separation of distinct subject areas. It is then based on a scalable

infrastructure that allows for dynamic redistribution of resources and

Data Assets Layer

Performance Layer

Business

Access Layer

Application Neutral Data Model,

near 3rd NF,

EII and EAI

Auxiliary Data Structures, such as MQTs,

Indices, Application Specific Tables

Views providing business access

to application neutral data model

82 Moving Forward with the On Demand Real-time Enterprise

functionality, as well as capacity on demand. They key is to leverage an

enterprise set of data, and build in a performance layer to enable analytics. By

leveraging the deep BI functionality of DB2, OLAP performance can be improved

and data mining operationalized in the performance layer.

In Figure 3-3 we illustrate an architecture, or information pyramid, that many

organizations already have today, at least to some degree. They have different

layers and usages of systems, ranging from operational, through ad hoc

analytics, to high level dashboards providing high level summarized information

for business decision makers.

The various layers in the information pyramid are typically oriented to different

user groups in an organization. This is illustrated, in Figure 3-3, by the various

groups or purposes of the data warehouse environment.

Figure 3-3 The IBM layered data warehouse

We refer to the various layers of the architecture as floors. Each has a different

use, form, currency level, and duration of data retention, to support the various

requirements of the enterprise. We now give a brief description of each of the

floors.

򐂰 Floor 0: Here we find the operational systems, such as point-of-sales, store

operations, channels, inventory, customer management, order systems,

Floor 1

Floor 5

Floor 4

Floor 3

Floor 2

Floor 0

Operational Systems

Duration: 60, 120, 180, etc days

Staging, Detail, Denormalized, Raw Source

Duration: 60, 120, 180, etc days

Near 3

rd

Normal Form, Subject Area,

Code and Reference Tables.

Duration: Years

Summarized Data

Performance and rolled up Data

Duration: Years

Dimensional, Data Mart,

Cubes, Duration: Years

Dashboard

Static reports,

Fixed Periods

Operational

Decision Making

Tactical

Decision Making

Strategic

Decision Making