What We Learn
How self-referencing hierarchical structures behave in different situations.
Scenario, Mapping And Modeling
Typically organization units form a hierarchy of sorts, where any unit can have any number of subunits, resulting in a treelike structure where every branch can be of arbitrary depth. In this tutorial the model is expanded with the content of an Organization master system which contains only the organization data. The simulated source system is OrgMaster, hence it will need a new mapping file, 03_Mappings_OrgMaster.csv.
A quick look at the data will reveal that this should happen:
| Source table… | …goes to the Staging Area as… | …and maps to the Class |
|---|---|---|
| DS_DemoData.OrgMaster.ORGANIZATION | OrgMaster.RAW_ORGANIZATION | Organization |
| DS_DemoData.OrgMaster.ORGANIZATIONUNIT | OrgMaster.RAW_ORGANIZATIONUNIT | Organization unit |
Model the new classes as below. Assume Code to be the Business key in both cases. Mark the classes for implementation, export the model and open the export in D♯ Engine.
Points of interest:
- The multiplicity in the Parent unit end is 0..1: an Organisation unit may have a parent unit, or it may not.
- The multiplicity in the other, unnamed, end is 0..*. An Organisation unit may have other units as child units, or it may not have.
- When drawing the self-reference association, please refer to the modelling tool’s documentation on how to draw the association. For example, Visual Paradigm uses a different tool for self-association than an ordinary association between two different classes (creating associations in VP).
- When assigning the role name Parent unit, make sure you name the Association End and not the Association itself.
Map the table structure to the classes and finally refresh D♯ Engine. You should now have the following structure representing these two new classes (select the OrgMaster folder and click Table Structure to view the diagram, then show the columns in each table and click Arrange).:
Note: the diagram draws the two links between lnk_OrganizationUnit and hub_OrganizationUnit on top of each other, but you can verify that the columns containing the hierarchical information are indeed both in the link.
Make a new deployment package for the two new Organization classes and install it.
Run Tutorial Scripts
Run the following tutorial script commands fron the Help -> Tutorials -> Intro Course -> Hierarchy Tutorial menu and inspect the results.
| Script | Source data | Main points of interest |
|---|---|---|
| Step 1: Load Organization Hierarchy | There is only one top-level unit that has a child; 1000.3 has ABCD as child. | The hierarchy is identical to the source. |
| Step 2: Load Organization Changes | ABCD has moved from 1000.3 to 1000.1 There are new 2:nd level units. |
The link containing the 1000.3 / ABCD parent/child information has been hidden using the sat_OrganizationUnit_linkstate table (a D-row has been added). |
| Step 3: Load More Organization Changes | ABCD has moved back to 1000.3 The 2:nd level units 1000.1.1 and 1000.1.2 have been removed. |
The link containing the 1000.3 / ABCD parent/child information has been reinstated (a C-row has been added to rollback the previous D-row). The 1000.1 / ABCD relation has been hidden, but the 1000.1 / 1000.1.1 and 1000.1 / 1000.1.2 relations are still visible for historical purposes (older data may still reference these). |
Note: The relations that were removed from the source that still remain visible in the view can be hidden by setting the State tracking method to Simple and turning on the soft delete functionality for Organization unit before loading the data. This will behave as intended when the data that is loaded is complete (full loads). For incomplete data (incremental loads) other measures need to be taken. This situation is covered in a future tutorial.
