数据仓库工具箱：The Data Warehouse Toolkit

 

《The Data Warehouse Toolkit》(Second Edition)

The Complete Guide to Dimensional Modeling    

Ralph Kimball

Margy Ross

--Different Information Worlds

 One of the most important assets of any organization is its information. This

asset is almost always kept by an organization in two forms: the operational

systems of record and the data warehouse. Crudely speaking, the operational

systems are where the data is put in, and the data warehouse is where we get

the data out.

操作型数据库侧重是把数据放进去哪里，而数据仓库侧重是从哪里获得数据。

--Goals of a Data Warehouse

1 The data warehouse must make an organization’s information easily accessible.

2 The data warehouse must present the organization’s information consistently.

3 The data warehouse must be adaptive and resilient to change.

4 The data warehouse must be a secure bastion that protects our information assets.

5 The data warehouse must be a secure bastion that protects our information

assets.

6 The data warehouse must serve as the foundation for improved decision

making.

7 The business community must accept the data warehouse if it is to be

deemed successful.

--数据仓库的目标：

 1 数据仓库必须使系统性的信息更加容易获取;

 2 数据仓库必须持续不断的呈现系统性的信息；

 3 数据仓库必须对变化具有适应性和弹性；

 4 数据仓库必须是一个保护信息资产的安全壁垒；

 5 数据仓库必须作为改善决策制定的基础；

 6 如果数据仓库被认为很成功，那么它们就必须接受数据仓库。

 

--Components of a Data Warehouse

 1 Operational Source Systems

 The source systems maintain little historical data, and if you have a

good data warehouse, the source systems can be relieved of much of the

responsibility for representing the past.

 操作型数据源系统不应当展示历史数据。

 2 Data Staging Area

 The key architectural requirement for the data staging area is that it is off-limits to

business users and does not provide query and presentation services.

 Unfortunately, some data warehouse

project teams have failed miserably because they focused all their

energy and resources on constructing the normalized structures rather than

allocating time to development of a presentation area that supports improved

business decision making.

不幸的是，一些数据仓库项目团队因为集中他们所有的精力和资源用来构建标准数据结构而不是分配足够的时间

去开发数据展现层用来支持改善决策制定。

 It is acceptable to create a normalized database to support the staging processes;

however, this is not the end goal. The normalized structures must be off-limits to

user queries because they defeat understandability and performance. As soon as a

database supports query and presentation services, it must be considered part of the

data warehouse presentation area. By default, normalized databases are excluded

from the presentation area, which should be strictly dimensionally structured.

 3 Data Presentation

 We typically refer to the presentation area as a series of integrated data marts.

A data mart is a wedge of the overall presentation area pie.

 We have several strong opinions about the presentation area. First of all, we

insist that the data be presented, stored, and accessed in dimensional schemas. 

Our second stake in the ground about presentation area data marts is that they

must contain detailed, atomic data.

首先，我们坚持用多维数据模型展现，存储，访问数据；

其次，数据展现层的数据集市必须包括详细的原子数据。

 Data in the queryable presentation area of the data warehouse must be dimensional,

must be atomic, and must adhere to the data warehouse bus architecture.

 If the presentation area is based on a relational database, then these dimensionally

modeled tables are referred to as star schemas. If the presentation area

is based on multidimensional database or online analytic processing (OLAP)

technology, then the data is stored in cubes.

 4 Data Access Tools

 We use the term tool loosely to refer to the variety of capabilities

that can be provided to business users to leverage the presentation area for

analytic decision making.

 A data access tool can be as simple as an ad hoc query tool or as complex as a

sophisticated data mining or modeling application.

 数据访问工具可以简单到一个广告查询工具，也可以复杂到数据挖掘或建模应用。

Operational Data Store

 Most commonly, an ODS is implemented to deliver operational reporting,

especially when neither the legacy nor more modern on-line transaction processing

(OLTP) systems provide adequate operational reports.

 The ODS as a reporting instance may be a steppingstone

to feed operational data into the warehouse.

 In other cases, ODSs are built to support real-time interactions, especially in customer

relationship management (CRM) applications such as accessing your

travel itinerary on a Web site or your service history when you call into customer

support. 

 

 Fact Table

1 A row in a fact table corresponds to a measurement. A measurement is a row in a

fact table. All the measurements in a fact table must be at the same grain.

2 The most useful facts in a fact table are numeric and additive.

3 We often describe facts as continuously valued mainly as a guide for the

designer to help sort out what is a fact versus a dimension attribute.

4 It is theoretically possible for a measured fact to be textual; however, the condition

arises rarely.The designer should make every effort to put textual measures into dimensions because 

they can be correlated more effectively with the other textual dimension attributes and

will consume much less space. 

5 It is very important that we do not try to fill the fact table with zeros representing

nothing happening because these zeros would overwhelm most of our fact tables.

6 Fact tables express the many-to-many relationships between dimensions in dimensional

models.

Dimension Tables

1 Dimension tables are the entry points into the fact table. Robust dimension attributes

deliver robust analytic slicing and dicing capabilities. The dimensions implement

the user interface to the data warehouse.

2 The best attributes are textual and discrete. Attributes should consist of real

words rather than cryptic abbreviations.

Dimensional Modeling Myths

Myth 1. Dimensional models and data marts are for summary data only.

Myth 2. Dimensional models and data marts are departmental, not enterprise, solutions.

Myth 3. Dimensional models and data marts are not scalable.

Myth 4. Dimensional models and data marts are only appropriate when there is a

predictable usage pattern.

Myth 5. Dimensional models and data marts can’t be integrated and therefore lead

to stovepipe solutions.

Common Pitfalls to Avoid

Pitfall 10. Become overly enamored with technology and data rather than

focusing on the business’s requirements and goals.

Pitfall 9. Fail to embrace or recruit an influential, accessible, and reasonable

management visionary as the business sponsor of the data warehouse.

Pitfall 8. Tackle a galactic multiyear project rather than pursuing more manageable,

while still compelling, iterative development efforts.

Pitfall 7. Allocate energy to construct a normalized data structure, yet run

out of budget before building a viable presentation area based on dimensional

models.

Pitfall 6. Pay more attention to backroom operational performance and ease

of development than to front-room query performance and ease of use.

Pitfall 5. Make the supposedly queryable data in the presentation area overly

complex. Database designers who prefer a more complex presentation

should spend a year supporting business users; they’d develop a much

better appreciation for the need to seek simpler solutions.

Pitfall 4. Populate dimensional models on a standalone basis without regard

to a data architecture that ties them together using shared, conformed

dimensions.

Pitfall 3. Load only summarized data into the presentation area’s dimensional

structures.

Pitfall 2. Presume that the business, its requirements and analytics, and the

underlying data and the supporting technology are static.

Pitfall 1. Neglect to acknowledge that data warehouse success is tied directly

to user acceptance. If the users haven’t accepted the data warehouse as a

foundation for improved decision making, then your efforts have been

exercises in futility.