Dynamics CRM Database Structure

Microsoft Dynamics CRM uses metadata driven architecture to provide the flexibility to create custom entities and additional system entity attributes. This structure also makes upgrades and the transportation of customization easier.

Metadata driven architecture (MDDA) is used to abstract function from logic.  Metadata creates a logical self-describing framework for allowing the data to drive application features and functionality. Metadata is commonly found inside of database schemas, XML configuration files, SOAP WSDLS, HTML web pages, rules engines and source code.


The following table lists the objects described by the metadata.

Metadata object Description
Entity An entity is a container for data, similar to a table in a traditional database. Each entity contains a set of attributes. For Microsoft Dynamics 365, there are a set of entities that exist when you first install. Some of these are customizable. In addition, you can create custom entities to contain business data.
Attribute An attribute is a container for a piece of data in an entity. Microsoft Dynamics 365 supports a wide variety of attribute types.
Relationship A relationship defines an association between two entities: one-to-many, many-to-one, many-to-many, and self-referential.
Option Set An option set defines a set of options provided for a picklist. Several picklist attributes may use a global option set so that the options they provide are always the same and can be maintained in one location.
Option An option is one of the values available in an option set. Each option in an option set has a unique integer value and an associated set of localized labels.

Microsoft Dynamics CRM metadata contains the description of system and custom entities, attributes and the relationship between entities for an organization. The MetadataService Web service provides the messages that you can use to read or write the metadata. This Web service can be used to perform the following actions.

Read Actions

  • Retrieve the metadata for system or custom entities.
  • Retrieve the attributes for an entity.
  • Retrieve the metadata for a specific attribute such as the possible state names or the picklist values for an attribute.
  • Retrieve all the entities and determine which entities are custom entities.
  • Determine whether the metadata has changed since a previous retrieve.

Write Actions

  • Create a custom entity.
  • Add or update an attribute for an entity, either system or custom.
  • Create or delete a relationship between two entities.
  • Add or remove an option from a picklist attribute.
  • Write an installation and uninstall program for your custom solution.

In the example below you can see two custom entities; Bank Account and Deposit Box.


Entity 1 Entity 2 Relationship
new_bankaccount activity entities (task, email, appointment, and other activities) 1:N (one-to-many)
new_bankaccount account N:1 (many-to-one)
new_safedepositbox annotation (note) 1:N (one-to-many)
new_safedepositbox new_bankaccount N:1 (many-to-one)
new_safedepositbox account N:1 (many-to-one)

Account <-> Bank Account – this entity represent a bank customer who can have multiple bank accounts hence there is a 1:N relationship

Safe Deposit <-> Bank Account – multiple safe deposits can be related to a single bank account hence a N:1 relationship

Safe Deposit <-> Account – multiple safe deposits can be owned by a single customer i.e Account hence a N:1 relationship

Visual representation of metadata can be very useful, especially when you are trying to describe the relationship between entities in the system. You can use the Metadata Diagram sample code provided for Microsoft Dynamics CRM to generate the entity relationship diagrams.

While deploying Dynamics CRM, we must remember that CRM deployment will contain these Database;

Database Type Database Name Description
Config Database MSCRM_Config This database will contain CRM Server information deployment, such as users and licensing. One config database will be created during the time you  install CRM server. It is important to remem that  each deployment requires its own database instance
Content Database Organization_name_MSCRM This contains the discussed CRM metadata architecture. All configurations are in the metadata.
Reporting Services databases ReportServer and ReportServerTempDB ReportServer and ReportServerTempDB will be the default report databases. Microsoft Dynamics uses SQL Server Reporting Services which must be installed in native mode.

Will be writing another blog about CRM entity model, till then happy CRMing!



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s