The choice between validating the integrity check in application or in DBMS does
not exist in practice because, usually, the fast procedures for loading massive data
do not support a check of any type. Then, fact tables must be free of primary key and
other heavy constraints; in some cases, it is only useful to declare referential integrity
check merely on behalf of optimizer (with no validate or similar clauses).
Tbs_01 Tbs_02 Tbs_03 Tbs_n
Ix_Tbs_01 Ix_Tbs_02 Ix_Tbs_03 Ix_Tbs_n
Range.Part_02
Ix range Part_02
Hash sub part 01_n
6 Adzic, Fiore, & Sisto
Copyright ?© 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of
Idea Group Inc. is prohibited.
In the NRT context when the loading frequency is high and history is deep, creating
a new partition every cycle implies a total number of partitions which DBMS,
in general, does not support. If volumes are not so high, then it is possible to define
partitions that span many loading cycles (e.g., a partition per day), but in these cases
fast loading techniques cannot be used.
If volumes are high, and hence the use of fast loading is mandatory, then some adhoc
techniques must be ???invented??? (Figure 3).
Our fact table consists of two partitioned tables named ???thin??? and ???fat??? merged by
a view in ???union all.??? The thin table is partitioned in a coherent way with loading
cycle, while the fat one has a lower granularity partitioning.
Pages:
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202