I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around entity relationship diagrams.

You can see below that the entity relationship diagrams are mentioned in the perform discover, planning and analysis section of the exam.

Firstly I’d like to bring your attention to the percentage of marks for this section of the exam! Its “just” 5 to 10%. You might want to consider this when deciding how deep to learn each area of the exam. As other sections of the exam could be as large as 25%. Meaning I suggest you should spend your valuable revision time wisely!

Having said that 10% is still a significant portion of the exam so we can’t just ignore the topics in this or any section!!

Secondly, I hope you can see that the topics covered here aren’t necessarily directly testing your knowledge of the Dynamics 365 product. The scope actually goes wider, the purpose seems to be to test your experience of being a functional consultant.

Entity relationship diagrams are a good example of this as they are a commonly used diagram in many types of project well beyond “just” Dynamics 365. A it will be a common design task to define and document your database structure.

What is an Entity Relationship Diagram (ERD)

An Entity Relationship Diagram (or ERD) is a chart that illustrates how entities relate to each other. When thinking about databases this will mean the tables within the database. (The term table and entity are pretty much interchangeable!)

Typically a standard set of symbols will be used to represent entities. Connecting lines between the entities will show how they relate to each other. By this I mean a one to one, one to many or many to many relationship. Sometimes we might also see notes to highlight any mandatory relationships.

The concept of an ERD is certainly not a new one. Peter P Chen is recognised as creating ERDs in the 1970s. You can read more about Peter on Wikipedia here. Although you should be aware that Chen’s notation is just one way to draw an ERD.

Types of ERD

There are multiple ways are drawing an ERD. Including Chen, Bachman, and crows foot notations.

You may also need to consider the level of detail to represent. For example, do you simply want to show the key relationships between entities or do you wish to show all relationships and also all attributes for an entity. Whilst the later maybe more “correct” it could become cumbersome to maintain. Plus developers reading the chart may find it difficult to “see” the core meaning you wished to portray. Therefore the level of complexity should be revised based on the purpose and audience for the diagram. Often it will be logical to only represent the key entities and key relationships.

If we think about Dynamics 365 for a second, I will often just draw any new relationships or custom entities to be added to the CDS data model. But I wouldn’t always try to draw all of the out of the box system entities and their relationships.

Tip:
CDS stands for Common Data Service. CDS is built on the common data model that represents all of the entities used within Dynamics 365. CDS contains many standard entities and relationships to represent accounts, contacts, cases and much more. Hence why I will often only draw the alterations to this model rather then feeling the need to document what is a standard set of entities and relationships.

As mentioned there are multiple types of ERD notation. One being Chen’s original notation. Here we have rectangles to represent entities and diamonds to represent the relationships between the entities. We may optionally wish to name these relationships. For example, contacts associated to an account could be considered employees of the account. Connecting lines would further define which relationships are 1 to 1, 1 to many or many to many.

Admittedly I don’t often see Chen’s notation! In my experience, more commonly a crows foot diagram will be used. The connecting lines on a crows foot diagram give rise to its name … as these clearly show which relationships are 1 to many, many to many etc. (With the “many” option resembling a crows foot.)

The example diagram below does include attributes, the addition of these is optional. You could just draw the key fields between entities or even just the entities.

Why is the ERD important

A very good question is why is the ERD important! Why is ERD often a key design artefact?

I guess because drawn properly it should clearly explain what entities exist and how they are connected. As Dynamics 365 model driven applications are data focused understanding the data relationships is often a major step in the overall solution design.

Drawing the relationships may help highlight any limitations in the design. Assuming you create an ERD before actually starting to build your entities it may prove extremely valuable in spotting design weaknesses / limitations before you start to develop anything.

Personally I have often found a well-drawn ERD to be one of the most important pieces of technical documentation. Mapping out the data is often the first step I’d take in creating any design.

Tools for creating an ERD

There are many tools out there to help you draw an ERD. I certainly won’t attempt to mention them all here! And I don’t expect the MB-210 exam to question us on specific tools. Understanding what as ERD is and why we’d create one (I assume) will be the key requirements for the exam.

In some circumstance you could draw the most simple diagrams directly in PowerPoint or by using Windows Paint. But unless your diagrams are very simple you will probably need a more sophisticated drawing tool.

For me that generally means Microsoft’s Visio.

Below you can see that Visio allows me to create ERDs using various notation types. You may want / need to experiment with which one fits your requirements best. (Although I personally routinely use the crow foot notation!)

Hopefully I have given you a high level description of ERDs and why we need them. This will be important for the MB 200 exam. But more importantly, if you don’t already routinely create entity relationship diagrams I suggest (I your revision) you try to create some for projects you are currently working on. Enjoy.