When an aggregate table is created, the child records are usually summarized into the parent record, based on the key combinations in a relationship table. In any hierarchical relationship, when the parent-child relationship is altered, all tables that hold that relationship or data relevant to it must be updated. Whether these relationships are dynamic or static change how they are aggregated into tables.
When the relationship between parent and child elements change, the relationship is called dynamic. These changes often occur because of organizational restructuring; geographical realignment; or the addition, reclassification, or discontinuation of items or services. For example, a store can decide to reclassify the department to which items belong.
Aggregate tables that contain dynamic relationships must be recalculated every time a change is made. If the tables are large, this process can take time, consume resources, and complicate the batch process. Frequent changes can mean aggregate tables are not optimal for this situation. Consider the frequency of the changes, the table size, and the impact on the batch process, and then balance the disadvantages against the advantages of having an aggregate table.
Also, rolling up an entire hierarchy can avoid many problems with relationship changes. For example, a table contains one value for the sum of all stores. It is not affected by a reorganization within the geography hierarchy.
When elements rarely or never change relationships, they are a part of static relationships. In these cases, maintaining aggregate tables is very easy. For example, time hierarchies are seldom dynamic—days do not migrate into different weeks, and fiscal weeks do not move into different months.