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

• 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)

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