What We Learn
We learn how to substitute a specific hash value for another in order to combine and standardize the way data is shown and used.
Scenario
The ProjMaster people have added a project to ProjMaster that also exists in ProjMaster Apprentice. Technically, it has no relation to the ProjMaster Apprentice version of it, as it uses a different Project number, but it still means the same project. And even if the Project numbers would match, the two projects still would not match on hash level because of the two sources using different key groups for the Project class.
We want to interpret these two project instances as the same project, since that’s what they are.
We also want to consistently use only one of the two available variants of the Gender codes.
Modeling
No model changes are needed for this, only metadata updates:
| do this… | …and this will happen |
|---|---|
|
For the Project class, set the Key consolidation parameter value to Redirect incoming associations to master instance. |
Project will get a SameAs table. Views referencing the Project view will try to substitute the child hash in the table for the master hash, therefore referencing another hash value in the Project view than what they would otherwise. The Project view will contain all Project rows. |
|
For the Gender class, set the Key consolidation parameter value to Redirect and filter out redundant instances. |
Gender will get a SameAs table. Functionality as above, except the Gender view will hide the rows that exist in the child hash column of the SameAs table. |
Deploy the Changes And Try It Out
Deploy the Project and Gender classes as well as every view that references the Project and Gender views, respectively.
| Script | Source data | Main points of interest |
|---|---|---|
|
Step 1: Go through functionality
|
The same project from ProjMaster as well as ProjMaster Apprentice | Run the script step by step and familiarize yourself with how the SameAs structure works. |
