What We Learn

Deploying new content that extends the model, but does not add elements to existing objects. How yellow Role classes are converted to standalone links, how state tracking works for previously loaded data that does not exist in the source anymore, as well as how soft deletion can be implemented in the view layer.

Modeling and mapping

Look at the structure and content of the ProjMaster.PROJECT, ProjMaster.PERSON_PROJECT and ProjMaster.PROJECT_ROLE tables in DS_DemoData.

You will come to the conclusion that the following steps need to be taken:

Model the three new classes using the newly mapped class and property names, like below. Re-use the existing Person class. Set the Implement value to True for the new classes. The new classes should have the following structure in your modeling tool:

Next decide on the keys: from the source data you can draw the conclusion that Project number is most likely the Business key for Project, and Code would appear to be the Business key for Person’s role in project. Project membership, however, is worthy of a discussion.

Project membership represents a typical Participation pattern: something participates in some activity in a specific role during a specific period of time. It would make sense that the natural key in this case consists of the combination of the referenced classes as well as the Start date attribute, since a person could be in the same role in the same project during different times, or in different roles at the same time. It is technically possible that, even though the key feels logically sound, that some of the key values could change (for example, if someone corrects an error in the role or the start date). A change like this makes a hash key representing the same real world incident to “change”, leaving us with two instances describing the same incident, but with slightly different details. To catch this, set State tracking method to Simple for the Project membership class and, in D# Engine, set the Soft Delete parameter value to true after deployment. This can be done when we know we will always load the complete set of data representing the class. So in this case, we will always load all Project membership data, and we want to track when a previously loaded membership disappears for whatever reason. Note that soft deletion requires the state tracking to be active, but state tracking does not necessitate that you activate the soft deletion.

To finalize the latest additions:

Export the model to your working directory and open the model export file with D♯ Engine, or just refresh D♯ Engine, if you have it open.

Open the existing ProjMaster mappings file and add the source columns to the mapping rows, and complete them with PK and FK info and the appropriate Class and Property names. Save the file. Refresh D♯ Engine.

In the Conceptual Model pane, locate the subfolder containing the ProjMaster classes, select it and click the Table Structure command to get the ER diagram for this particular portion of the Raw Vault. Open the tables so that their columns are showing and click Arrange. Verify that your Raw Vault looks like below before proceeding with the installation. Click the image to enlarge.

Deploy the changes

In the Conceptual Model pane, make a selection that contains the three new classes and deploy like in the previous tutorial. After deployment, select the Project membership class from the Conceptual Model hierarchy, and set its Soft Delete parameter to true. By toggling the Soft Delete parameter on and off, the corresponding view will react immediately by hiding or showing rows that are marked as deleted.

Run Tutorial Scripts

Run each of the tutorial script commands fron the Help -> Tutorials -> Intro Course -> Project Tutorial menu, and inspect the results.

Next tutorial