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!
*This post is locked for comments