Siebel Data Warehouse Installation and Administration Guide > DAC Quick Start > Tailoring Execution Plans for Your Needs >

Pruning Table Groups in the DAC

A table group is a logical grouping of tables that defines a logical relationship among all the component tables. The table group definition is based on a main table that drives the relationship between itself and the other tables in the group.

A table can be a main table for only one table group. When you design a table group, you associate it with a list of tables that need to be populated whenever the main table participates in an ETL. The tables can be main tables for other table groups; in such cases, when an ETL is run, the DAC server recursively includes all necessary tables. This process in which the tables are recursively populated is called chaining.

You can prune a table group by inactivating one or more of the tables associated with it. When designing an execution plan, inspect the table groups that you are interested in. If there are dimensions in a fact table that you are not interested in populating during the ETL process, inactivate them or remove the table association. This might also require you to modify the workflows and dependencies as well. Use the Preview functionality to figure out if your design is correct at the table group, subject area, and execution plan level.

CAUTION:  If a table is removed from one table group but is still active in others that belong to the execution plan, you will see it appearing in the preview. If the table is not required for the entire ETL, consider inactivating the table. For more information about inactivating tables, see The Chaining Process.

The Chaining Process

When multiple target (data warehouse) tables share the same source table, they must be populated together. For example, the Person Fact table group contains the tables listed in Table 33. The main table for this table group is W_PERSON_F. When W_PERSON_F participates in an ETL, the other tables listed below also participate. W_PERSON_D is the main table for the Person Dimension table group; whenever it participates in an ETL, the other tables that are part of the Person Dimension table group also participate in the ETL.

A similar kind of chaining concept is used for entities that have parent-child relationships. When a parent table participates in an ETL, its child tables also get populated. For example, the Order Dimension and Order Item Fact tables have a parent-child relationship. When the Order Dimension table is part of a table group that participates in an ETL, the Order Item Fact table will also be populated.

Therefore, when pruning the data warehouse, you should start with the table groups of type star and verify that all the related tables are required. If a table is not required and it is a parent table, you need to disable the link between it and the child tables that you do not want to populate. For information about disabling entities, see Disabling DAC Repository Entities.

The chaining process is used for the following reasons:

• To maintain data integrity

  For example, when the Person Fact table group is built, the Person Dimension group is also populated.

• Two or more data warehouse tables can share the same source table

  When multiple data warehouse tables (target tables) share the same source table, they must be populated together. For example, the tables W_PERSON_F and W_PERSON_D have the same main source table, S_CONTACT. Suppose you want to populate the Revenue Fact table group, which has W_REVN_F as its main table and W_PERSON_D as one of the dimension tables. Whenever the Revenue Fact table group is chosen for an ETL execution, W_PERSON_F is also populated because W_PERSON_F is chained to W_PERSON_D.

• To maintain parent-child relationships

  For example, when the Order Dimension table is built, the Order Item Fact table also must be populated, otherwise the data will not be in sync.