Modeling normalized entities with a common parent

Similar to database modeling, the alternative to a denormalized model, is, you guessed it, a normalized model. Normalizing a structure is the action of separating a table into two or more structures. Normalization reduces the number of redundant or unnecessary fields in a form. In the Dynamics 365 context, normalizing will help avoid overcrowding one entity by spreading the attributes across different entities whilst keeping a common parent.

In this recipe, we will carry on using the contact entity and extending its relationships to include additional attributes: student graduation details.

Getting ready

Similar to the previous recipe, System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

How to do it

1. Navigate to Settings | Solutions | Packt.
2. Click on New | Entity.
3. Enter Graduation Details in the Display Name field, and Graduations Details under the Plural Name field.

4. Before saving the new entity, untick all the check boxes on the form:

5. Click on the Save button.
6. Navigate to Fields on the left-hand side and click on New.
7. Create an attribute called Supervisor of type Lookup with a Target Record Type set to user and click on Save and Close.
8. Create another attribute called Post Graduate Start Date of type Date and Time and click on Save and Close.
9. Navigate to Forms and double-click the Quick View Form option.
10. Add the two attributes on your form by dragging and dropping them from the right-hand Field Explorer, then click on Save and Close.
11. Click on Save and Close on the entity as well to go back to your solution.
12. Navigate to Entities | Contacts | N:1 relationships | New Many-to-1 Relationship.
13. Enter Graduation Details in the primary contact field, Display Name: Graduation Details and click on Save and Close.
14. Navigate to the contact's Forms and double-click the Main Information form.
15. Add the newly created field to your form by dragging and dropping the Graduation attribute from the right-hand window on to the form.
16. Click on the Insert tab at the top followed by Quick View Form:

17. Enter the following details in the Quick View Control Properties window:
    • Name: Graduation_Details
    • Label: Graduation Details
    • Lookup Field: Graduation Details
    • Quick View Form: Information

18. Click on OK:

19. Click on Save and Close.
20. Click on the Publish All Customizations button for your solution.

How it works...

Although this recipe is simplified, typical normalized models will contain more than one attribute, as well as more than one entity.

In step 2 to step 11, we created a normalized entity that contains the employee details along with its Quick View. In step 4, we avoided keeping the checkboxes ticked. All the checkboxes with a symbol depict options that cannot be reverted. We can always enable them later if required. As a best practice, if they are not required, don't enable them, otherwise your choice will be irreversible. In step 12 and step 13, we created a relationship between contacts and the newly created entity to provide a navigation path between the parent contact entity and the additional attributes for the specific types (Supervisor and Post Graduate Start Date). In the last steps, step 14 to step 18, we added the lookup as well as the Quick View on the contact form. A Quick View is a simplified sub-view of another record that can be placed on the parent record's form to display the child's subset of attributes in read-only. The red box in the following screenshot highlights the Quick View related to the Graduation Details lookup record:

With this design we can now see the graduate details on the contact form without creating the attributes on the entity itself.

Our ER diagram now looks like this:

The advantages of normalizing your data with a common parent are:

• Lighter multipurpose parent entity
• Security roles can control the normalized entities with the additional attributes

However, the primary field value will still appear on the parent form, even if the user does not have read rights to the child entity. Moreover, field level security can be used to obfuscate the lookup's text.

• Quick Views help display the normalized data on the parent form (read-only)
• Advanced search can still retrieve and filter information from the related entities
• Views can contain data from the related entities (non-sortable)

With quick Views, a user can retrieve data that is two levels deep. Attributes from the related record as well as its 1:N or N:N related lists.

This model also has some cons, which are as follows:

• Degraded user experience as the Quick Views are read-only
• May require some customization to show and hide irrelevant details
• Quick search cannot search attributes across the different normalized entities

See also

• Modeling denormalized entities
• Modeling independent normalized entities
• Using a Business Rule to show and hide attributes
• The Building cumulative security roles recipe of Chapter 7, Security