Modeling denormalized entities

Typically, account and contact entities are the most commonly used entities in a Dynamics CRM implementation. In large implementations, those entities are usually also reused for multiple purposes. To illustrate the modeling pattern, this recipe will leverage the college solution described in the introduction. We shall concentrate on creating contacts that can either be individuals or students. Each type of contact requires a different set of attributes.

The easiest way of modeling a multi-purpose entity is to add all the required attributes for the different types to the same entity.

Getting ready

In order to configure the schema, you will need to have access to a Dynamics 365 instance along with a System Customizer or higher security role . As a best practice, it is always recommended that you implement your configuration within a solution. For the purpose of this book, it is expected that you already have a solution created called Packt with a publisher prefix of packt_.

How to do it

1. Navigate to Settings | Solutions | Packt.
2. Click on Add Existing | Entity and select Contact, as shown in the following screenshot:

 

 

3. Select the necessary assets that support your configuration and add them to your solution, or, for simplicity, select Add All Assets and click on Finish:

4. Click on No, do not include required components.
5. Navigate to Entities | Contacts | Fields.
6. Click on New, and create an attribute called Student Id of type Single Line of Text, and click on Save and New.
7. Create an Option Set attribute called Contact Type that contains two values; Student and Other. Then click on Save and Close.
8. Back in the solution, navigate to Entities | Contact | Forms and click on New | Main Form as per this screenshot:

9. In the newly created form, add the two newly created fields to your form by dragging and dropping the entities from the right-hand window onto the form.
10. Click on the Publish All Customizations button for your solution.

How it works...

Just like database modeling, entities can be normalized or denormalized. Normalizing a structure is the action of separating it into several related tables to reduce redundant data or empty fields. Denormalizing a structure is the opposite: we merge two or more tables together to simplify the structure and improve query performance, whilst adding redundant or empty fields. In this recipe, the entity was denormalized to allow different types of contacts to be surfaced through the same contact entity.

In step 1 to step 4, we added the existing contact entity to the Packt solution. Notice that in step 3, we had the option to either add the necessary assets or add all assets. For this recipe's simplicity, we added all assets. With the recent granular solution enhancements, we can simply add what is required.

Note

It is a best practice to minimize the number of unnecessary attributes and relationships in a solution to avoid conflicts and dependencies.

In step 5 to step 7, we created the attributes, and in step 8 and step 9, we added the attributes to a new contact form. In step 10, we published the configuration we implemented.

Note

To avoid multi-solution dependencies and scenarios where a form is overwritten with an updated version from another solution, best practice dictates that you create a new form for your solution and mark it as default. Unnecessary forms can always be hidden by using Apps as described in Chapter 9, Dynamics 365 Extensions.

Looking at the design of the updated entity, we have now configured the contact entity to fulfill more than one purpose: it is a generic contact as well as a student one.

A simplifiedEntity Relationship (ER) diagram is depicted in the following screenshot:

The advantages of a denormalized model are:

• Views will appear in the same combined list
• A quick and advanced find will include both types and display the results in the same list
• Positive form user experience, driven by the form configuration

The disadvantages of a denormalized model are:

• Security roles cannot easily be made specific to types
• Configuration/customization is required to show/hide irrelevant attributes or to mark them as mandatory or optional
• Records will contain blank fields when not applicable

See also

• Modeling normalized entities with a common parent
• Modeling independent normalized entities
• Using Business Rule to show and hide attributes
• The Dynamics 365 applications recipe of Chapter 9, Dynamics 365 Extensions