Loading Table Structure

1. Creation of Loading Table:
• The loading process creates a loading table in the staging area. This table is typically prefixed with C$ to distinguish it from other tables.
2. Loading Table as Execution Unit:
• A loading table represents an execution unit, not a source datastore. There is no direct mapping between the source datastore and the loading table. The execution unit appears in the physical diagram of the mapping editor.
3. Example Cases of Execution Units:
• Case 1: Simple Source Table (CUSTOMER) with Selected Attributes:
• If the source CUSTOMER table has only 2 attributes, such as CUST_NAME and CUST_ID, used in the mapping and joins in the staging area, then the loading table will only contain these two attributes.
• Attributes not needed for the mapping or integration flow will not appear in the loading table.
• Case 2: Filtered Source Table (CUSTOMER) with Unused Attributes:
• If the source CUSTOMER table is filtered on CUST_AGE and CUST_AGE is not used in subsequent transformations or integration, the loading table will not include CUST_AGE.
• The filter is applied at the source data server, and the loading table will only contain the filtered records.
• Case 3: Combined Tables (CUSTOMER and SALES_REPS) in Join:
• If two source tables, CUSTOMER and SALES_REPS, are joined on the source and the resulting execution unit is used in the staging area for transformations, the loading table will contain combined attributes from both CUSTOMER and SALES_REPS.
• The loading table will hold the data that results from the join, as needed for further processing.
• Case 4: Full Source Datastore without Joins:
• If all the attributes of a source datastore are mapped and no join occurs on the source, then the execution unit represents the entire source datastore.
• In this case, the loading table will be an exact image of the source datastore, especially for source technologies that don’t have transformation capabilities (such as flat files).