Introduction
This module describes the data modeling strategy in Microsoft Dynamics 365 and Microsoft Dataverse and then explains how the data model workshop will help verify that a complete data model exists before configuration starts. The following sections provide you with a basic overview of data modeling best practices and how they relate to a Dynamics 365 project.
Data modeling overview
A data model is a visual model that shows how data flows through your system and how different entities relate to each other. Data models define the relationship types between tables and abstract a database to a straightforward visual representation.
Data modeling has multiple types and standards, including Unified Modeling Language (UML), IDEF1X, and others. Specific data model standards are beyond the scope of this module, but data models for Dynamics 365 data structures generally fall into two general categories: logical and physical.
Logical data models
Logical data models are high-level diagrams that show the way that data flows through the system. These data models are frequently put together at the beginning of the project during discovery and before all columns have been defined. Generally, the logical data model diagram uses the business names of the tables, not the schema/database name.
Physical data models
Physical data models are lower level than logical data models. They generally include column-level detail and more precisely designed relationships. The physical data model is created when the high-level logical design is translated to physical tables. A common type of physical data model is an entity relationship diagram (ERD).
Data modeling best practices
Data modeling is a science, and data modeling professionals and established standards exist for data modeling. To be effective with Dynamics 365 data modeling, you don't have to be a professional data modeler or use special tools. Popular tools like Microsoft Visio can be used to quickly create a basic ERD that visualizes the relationships and flow of data between tables. This topic examines some general best practices for data modeling for Dynamics 365 deployments.
Best practices to follow are:
Data models should be updated continuously during a deployment. Typically, a data model is designed at the beginning of a project, but it's important that updates don't stop at that point. As you go through the deployment, new columns and tables will be added. Therefore, you need to capture these new columns and tables in the data model to make it a living data model. Recommend to customers that they continue to update the data model as they enhance the system.
Community tools that are available with the XrmToolBox help make it easier for you to quickly generate ERDs of your Dynamics 365 and Dataverse configuration. These tools include the UML Generator and Entity Relationship Diagram (ERD) Generator. After you complete configuration updates, generate an up-to-date ERD.
Don't include every table. Some core tables, such as activities, notes, and users (record owners), are related to nearly every table in Dynamics 365. If you include every relationship with these tables in your data model, the result will be unreadable. A best practice is to only include the primary tables that are used in the configuration in your data model diagram and only include custom relationships with the user and activity tables to maximize readability.
Data models should include tables outside of Dataverse. If you are integrating with other systems by using Dataverse data connectors or virtual tables, or if data flows outside of Dataverse by using an integration, this data should also be represented in your data model diagram.
Start simple with the standard tables, and then add custom table relationships to your data model.
User experience should influence your data model. Occasionally, it's easy to over-normalize your data; however, in the process, you can make the application more cumbersome to use.
Start with what you need now but design the data model in a way that will support what you plan to do in the future. For example, if you know that you'll eventually need to store more details about sales territories, using a text field for territory now will make it more difficult to implement than if you use the territory entity relationship. Plan ahead for what is coming.
Data model workshop
The data model workshop should be limited to about one hour, and it is often conducted as part of a Microsoft Teams meeting if everyone isn't together on site. Attendees should include key stakeholders from the customer and partner teams. Typically, solution architects, functional leads, and technical leads are mandatory. This workshop should take place while you still have time and opportunity to make course corrections if needed.
The next units will describe the recommended topics to be covered when you conduct the data model workshop.