Remember
that in a star schema the concern with normalization is gone, so adding calculated
data is acceptable. Adding preaggregated data could be accomplished by setting
some dummy values. For example, if the Year was 2007 but the Quarter was 5, the
Month was ???Z??™ and the Day was 99, that record represented the year total for 2007.
If the Year was 2007, the Quarter was 1, the Month was ???Z??™ and the Day was 99, that
record represented the first quarter totals for 2007.
This magic number approach could get messy quickly, so many people opted to
build summary tables. There was a year table, a quarter table, a month table, and
then the ???real??? fact table at the daily grain. This had the advantage of not having
messy codes, but queries had to be much smarter and know when to get different
values from different tables. In addition, if there were monthly totals for each
individual product and customer, even the summary tables could be quite large and
require a significant amount of extra disk space.
This is where cube building engines come in. Cubes are simply a different way
of storing data. Different engines work differently, but the focus here is on SQL
Server Analysis Services, also called just Analysis Services, SSAS, or AS. Analysis
Services does several things when creating a cube. First, it reads the data from
the dimension tables and the fact table. It stores the dimension and fact records
in a binary format, completely independent of the relational database engine.
Pages:
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91