In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   On Demand  |   Home  |

Custom Path Methodology (Preferred)
To avoid the pitfalls of changing our existing baseline tables at customer sites, it would be much simpler if the custom requirements could be met without ever touching the existing infrastructure. This is nearly a possibility! The approach to resolve this issue is to create a custom path for the custom work that has its own separate objects and is integrated into the baseline fact/dim by a custom procedure that updates the custom columns in the dim/fact table. This task is run after the regular tasks for populating/updating that table is completed.
Integration Points
The customized objects are integrated with the baseline objects using update procedures. If this option is chosen, any time a patch impacts the baseline objects then add the custom column back into the DWD but not the actual database. If cubes are used and the new customization desires them, the additional customization should be added as new attributes to the existing OLAP dimension.
Note: The grain of the update procedure should be the same as the core dimension table.
Processing Flow

DWD Processing Architecture with Customized Objects and Update Procedure for a Dimension

DWD Processing Architecture with Customized Objects and Update Procedure for a Fact (not History or Rollup)

DWD Processing Architecture with Customized Objects and Update Procedure for a Fact (History)
Pros and Cons
Any existing reports would continue to work as the dimension only has additional fields added.
Separation of baseline and customizations tables and stored procedures is maintained throughout the processing, making upgrades much easier.
There is a fairly low risk of data loss with this method of integration because the core dimension and fact tables only have extra columns added to them by the customizations that the stored procedure populates. If there is a patch or upgrade, restore the columns in the Designer, and readd the custom column update procedure to any jobs it may have been lost from.
This method of customization requires you to add custom columns directly to the dim/fact table. After an application upgrade or patch, reapply custom columns need in the DWD so they are still visible to end users.
Performance time-wise could be impacted by having this parallel path and by running a separate procedure to update dim or fact tables that their normal insert/update processes populates.
There is more up-front work in creating the parallel table path, instead of just adding columns to existing infrastructure.