Even at one tenth of one percent of this value, the fact table would still hold
almost four billion records. These are indeed impressive numbers.
Because fact tables are often so large, most organizations estimate the storage
requirements for their relational data warehouse simply by estimating the number
of rows in the fact table, multiplying it by the size of the record, and then adding a
percentage for the indexes. This typically works well, because the dimension tables
are relatively small compared to the fact table, and most warehouse architects tend to
overestimate the number of records in order to build in a cushion. Strategies for backing
up and restoring large fact tables are critical, but are beyond the scope of this book.
42 B u s i n e s s I n t e l l i g e n c e w i t h M i c r o s o f t O f f i c e P e r f o r m a n c e P o i n t S e r v e r 2 0 0 7
A relational warehouse is often called a star schema, simply because of the look
of the schema. In the middle sits a fact table with one or more measures. The fact
table has a join back to each dimension table, which often surround the fact table in
diagrams. The practice of placing the fact table at the center of the schema diagram
is merely tradition, but it helps those familiar with relational warehousing quickly
grasp the structure of the warehouse. In some cases a dimension table is normalized
somewhat, so that a Product dimension is broken into Product, Product Category,
and Product Subcategory tables.
Pages:
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82