Building the Data Warehouse

Скачать в pdf «Building the Data Warehouse»

Figure 3.36 shows the first design option, where a snapshot of an entire reference table is taken every six months This approach is quite simple and at first glance appears to make sense. But the approach is logically incomplete. For example, suppose some activity had occurred to the reference table on March 15. Say a new entry—ddw—was added, then on May 10 the entry for ddw was deleted. Taking a snapshot every six months would not capture the activity that transpired from March 15 to May 10.

A second approach is shown in Figure 3.37. At some starting point a snapshot is made of a reference table. Throughout the year, all the activities against the reference table are collected. To determine the status of a given entry to the reference table at a moment in time, the activity is reconstituted against the reference table. In such a manner, logical completeness of the table can be reconstructed for any moment in time. Such a reconstruction, however, is a not a trivial matter; it may represent a very large and complex task.

The two approaches outlined here are opposite in intent. The first approach is simple but logically incomplete. The second approach is very complex but logically complete. Many design alternatives lie between these two extremes. However they are designed and implemented, reference tables need to be managed as a regular part of the data warehouse environment.

Jan 1

AAA — Amber Auto AAT — Allison’s AAZ — AutoZone BAE — Brit Eng

July 1

AAA — Amber Auto AAR — Ark Electric BAE — Brit Eng BAG — Bill’s Garage

Скачать в pdf «Building the Data Warehouse»