Modeling independent normalized entities

The third modeling technique is similar to the second, except that the entities are completely independent. This scenario is typically used when there is a logical separation between the entities and there are few commonalities between them, to the point where reusability is not justified.

In this recipe, we will create a new entity called contractor that mirrors the contact entity with some additional attributes.

Getting ready

Similar to the previous recipes, a 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 Contractor in the Display Name field, and Contractors under the Plural Name field, and click on Save:

4. Navigate to Fields on the left-hand side and click on New.
5. Create an attribute called Hourly Rate of type Currency and click on Save and Close:

6. Navigate to Contractor | Forms and open the Main Information form.
7. Add the newly created field to your form by dragging and dropping the attributes from the right-hand window on to the form.
8. Click on the Publish All Customizations button for your solution.

How it works...

The alternative to the previous two modeling patterns is to keep your entities completely separate. This could prove to be an efficient design as it maximizes your instance's diversity. You can create a multitude of entities without overcrowding and without overlapping functionality. Nonetheless, as a best practice, promote reusability where possible. Keep in mind that a Dynamics 365 online instance has a limit on the number of custom entities that can be created. The limit also includes custom entities introduced by deploying third-party solutions. At the time of writing, the limit is 300 custom entities per Dynamics 365 instance. You can check your limit by navigating to Settings | Administration | Resources In Use:

Your new ER diagram is highlighted in the following screenshot:

The advantages of a completely normalized model are:

• No coupling between entities, resulting in cleaner and easier to manage solutions
• Full independent control using security roles for each of the entities
• Positive user experience with clean independent forms
• No need for complex configuration or customization to show and hide irrelevant sections

This model also has some cons, some of which are:

• Search results will appear in different lists
• Cannot combine views with both entities
• Some out-of-the-box entities (contact, account, and activities, among others) have well-defined core structures that could be difficult to recreate (for example, the regarding field on activities).

See also

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