CDM-Canonical Data Model

What is CDM?

What is CDM?

CDM is the abbreviated form of "Common Data Model" or "Canonical Data Model".

CDM is intended to be a common vocabulary for data at the enterprise level. (How is this different from EDD?)

When do we use CDM?

CDM should be used in the following scenarios:

1. Integrate more than two systems
2. Integrate with in two Systems if more frequent changes in those Systems
3. Entities which are in CDM will reuse in many place in Enterprise level

Where is CDM used?

• CDM mainly used in Integration Layer

Values & Principles

• CDM Should be built rather than COTS
• Try to create only one CDM in EAI level instead of maintaining too many CDM
• Easily understood by all the users not only technical folks
• Review and update more frequently
• Re-usability
• Extensible

Drafting Notes

• CDM a Common Vocabulary for Data in the Enterprise level
• Try to create only one CDM in EAI level instead of maintaining too many CDM.
• CDM Should be built rather than COTS
• Easily understand by all the users not only technical folks
• Review and update more frequently
• Reusability ,Extensionality
• Align with Physical Data model
• Version and naming strategy in place (will update)
• Read by all and updated By One (Central channel to manage).
• Plan for Tool to supports rather than XLS
• Reduced the Integration Resources
• Should not contain any Business Logic /rules
• Mainly achieve the loosely coupling with High Cohesion
• Should be derived from logical data model rather than applications.
• Should be application Independent
• Describe the Business information in Conceptual level
• Align with Data Agreement on Data definition in Enterprise level
• Independent with Technology
• Mainly used to define the Business Entities ,Attributes, association and etc to align with Physical Data
• CDM must be in the followings scenarios
  • Integrate more than two systems
  • Integrate with in two Systems if more frequent changes in those Systems
  • Entities which are in CDM will reuse in many place in Enterprise level
• CDM mainly used in Integration Layer.
• Should be in source control
• Entities are specific to the one system then it should in their XSD itself instead of CDM
• No of Attributes in Entity to be finalize.
• Entities are in CDM not specific to the application/system/project , if those entities are specific to application /System/Project please try to avoid to define those entities into CDM. Entities are in the CDM mainly Used in Enterprise level ie those Entities are reused more than one application
• Collaborate with domain experts, they know the business best and can help you ensure that the model reflects the business.
• Define a limited set of design principles to be used. This will lead to a more consistent and easier to understand model. Clear naming conventions for entities, attributes and relations also helps in this area.
• CDM is intended to be used for integration and therefore should only cover entities that are used on the integration layer
• SOA does not solve complexity automatically, a CDM is one the items that can reduce complexity.

Examples

• CDM should contain only Business Entities and not all the cross cutting entites 

Entities	Good to Use	Try to Avoid
Customer	x
AuditLog		x

Those Cross Cutting Entities may be in Integration Component 

• All Cross Cutting Attributes in one Entity or in one central place rather than capturing too many places in Integration /Service Layer.

 Naming Convention : 

• Entities names should be in noun align with Physical Entities (as much as possible) .
• Should be meaningful name
• Try to avoid the verb in name

Example	Good To Use	Try To Avoid
Customer Product	x
CustomerInfo CustInfo CustomerDetails Cust-Info CustomerReference Cust-Ref-Details		x

• Attributes in the entities should be meaningful and easy to understand
• Please try to avoid the Action in Attribute Name

Example	Good To Use	Try to avoid
Id,Name,TaxAmount,Discount	x
TAmount TAPAmount RefNo DisAmount Command ShowLastNameFlag PayType DCCAmount		x

• Avoid the Redundant in Entity level and try to minimize in Attribute level
• If more than one attributes occur in more than one Entities then move those Attributes in common entities. It’s easy to manage/extend attributes in one place if requires

Ex:

  We define the following Attributes in few Entities

LanguageCode and LanguageDescription

Instead of above , we can move those attributes in Language (new Entity) ..

Language --Entity

Code

Description

Wherever we need those attributes please refer the language entity instead of duplicating those attributes in many places.

Customer and Product requires LanguageCode and LanguageDescription

Advantages:

We can do the changes(Add/Amend) in one place rather than multiple place if any change requires

• Should avoid the numerical values in Attribute and entities names ..

Example	Try To Avoid
Reference1 Id1 CustomerDate1	x

• Entities and Attributes should be used for today , please try to avoid to define any entities and Attributes for future usage.
• Relationship should be define between the entities (if requires)
• Attributes name starts with I* only for Boolean Type data not for any other data format.

Example	Good To Use	Try to avoid
IsSupplimentartCardRequired-Boolean	x
IsSupplimentartCardRequired-String IsDateRequired-Date		x

• LOV be captured in the separate XLS
• Attributes are all same except few in both entities then use Generalization in Entity level

Ex:

 RecurringCustomer and OneTimeCustomer are the different Entities with same attributes except few attributes specific to the respective entities .

 In this case , we are not recommending to create two entities with duplicate detail instead do as follows

 Create the following Entities

Customer – Have all the common attributes

RecurringCustomer and OneTimeCustomer which extends those CustomerEntity with specific attributes

• No of Attributes in Entity should be reasonable , try to decompose those entity if it has more attributes

Ex:

Customer which contains attributes related to Personal,Address,Contact,Purhcase and etc. In this case We can move those attributes in separate entity instead of all in same entity

 Customer –streetname,postalcode,blkname,purchasedate,totalnoOfUnitsPurchased,purchaseDate,PhoneNo,Mobileno and etc

 We can move as follows

Ex: ServiceRelation , We need to analyse before define those entity in CDM . If the ServiceRelation Entity will reuse in any other Application/System then put into CDM otherwise not advisable to define those Entity in CDM.

When to Use CDM

Integration Details	CDM Required	Example
Entities are Common not specific to any Application/System	Y	PricePlan/Dispatch
Domain Specific Entitities	Y	Ex Customer /Product/Sales/Price
Entities/Attributes are specific to application	N	Ex: ServiceRelationId , deliveryName,
To Perform data Enrichment during the Integration	Y	1) Tranferring file between two Systems (System A and System B) , System A send 4 fields and System B requires 6 Fields in this scenrio we will create those Fields in Middleware  2) Tranferring file between two Systems (System A and System B) , System A send 4 fields and System B requires 4 Fields with Some data Transformation. In this scenario Middleware to do the Data Transformation
File Transfer Between two System through Middleware	N
To Perform filtering during Integration	N	System A Sending file with 5 Fields and System B requires only 4 Fields , In this scenrio we will remove those Fields and send to target System
Cross Cutting Entities	N	Should be managed by Middleware
Performance is Key	N
Adhoc Tasks/Reports	N
Computational Data/Entity	N
Entities traversed between only two System	N	Billing , Its only used between two Systems,

Sample CDM (Reference)

http://blog.nomagic.com/wp-content/uploads/2014/03/ProductSpec-ProductOffering-Product-Model.png

http://www.databaseanswers.org/data_models/medical_invoices_and_payments/medical_invoices_and_payments_invoices_and_payments_subject_area.htm