Challenge
A variety of factors are considered when assessing the success of a project. Naming standards are an important but often overlooked component. The application and enforcement of naming standards not only establishes consistency in the repository but provides for a developer-friendly environment. Good naming standards ensure MDM repositories can be easily understood and easily accessed by all developers.
Description
Implementing standard naming conventions facilitates smooth migrations and improves readability for anyone reviewing or carrying out maintenance on Hub objects. This document offers standardized naming conventions for various MDM objects. Whichever convention is adopted, it is important to make the selection very early in the development cycle and communicate the convention to the project team working on the MDM Hub. The policy can be enforced by peer review and at test phases by adding processes to check conventions for testing plans and for testing execution documents.
Building Schema Naming Standards
In MDM, any naming convention should be adopted based on the following limitations:
- Physical name of Base Object, Staging and Landing table should be less than 24 characters
- Physical name of Base Object, Landing columns should be less than 26 characters
- Physical name of Package should be less than 30 characters
Before deciding on any standard, these length limitations should be considered. As a general practice, remove all the vowels except the first character from physical names to make it understandable and maintainable.
For example, Party Address Relationship base object name can be written as C_REL_PRTY_ADDRSS (i.e., removing vowels from Party and Address and abbreviated Relationship to Rel for easier understanding).
Suggested Schema Naming Conventions
Object |
Display Name |
Physical Name |
Base Object |
The display names can be short and simple yet as descriptive as possible. The name should have a meaning to the business users, such as for the data stewards. Where possible, this name should be the full unabbreviated name and in title case. Base objects containing business data should be prefixed with ‘BO’. Example, the party table would be called BO Party. In case of reference data base object (i.e. Lookup Base Object) it can be prefixed with ‘LU’ or ‘LK’. Example: LK Country. For relationship objects, use the name of each entity and then prefixed with ‘REL’. Example: The Party Address Relationship Base Object would be REL Party Address |
The Hub will automatically create a physical name by prefixing the Display Name ‘C_’. Spaces in the display name will be replaced automatically with underscores. If needed to meet the 23 character limitation, first remove non-leading vowels, then the underscores. If there is still an inability to meet the limitation, remove consonants where plausible. Example: BO Party becomes C_BO_PARTY. |
Staging Table |
Stage table can be prefixed as ‘Stg’ followed by source system name to make it distinct from any other object type. Example: ERP source system Party Address Relationship staging table name can be ‘Stg ERP Party Address Rel’ |
The physical name will be prefixed automatically by the Hub with ‘C_’. Spaces in the display name will be replaced automatically with underscores. ‘C_’ should be proceeded by ‘S_’ then by the ERP name/abbreviation. Example: ERP source system Party Address Relationship Staging would be C_S_ERP_PRTY_ADDRSS_REL |
Landing Table |
The landing table can be prefixed as ‘Ldg’. Example: Party Address Relationship landing table name can be ‘Ldg Party Address Rel’ If the landing table structure varies across source systems, then source system can also be added as a part of source system. If the landing table structure is common and contains data from multiple source systems, use ‘ALL’. Example: ERP source system Party Address Relationship landing table can be named as ‘Ldg ERP Party Address Rel’. For a common landing table, use ‘Ldg ALL Party Address Rel’. |
The physical name will be prefixed automatically by the Hub with ‘C_’. Spaces in the display name will be replaced automatically with underscores. ‘C_’ should be proceeded by ‘L_’. The physical name for an ERP specific landing table can be prefixed as ‘C_L_<Source System Abbreviation>_’ (source system name is optional based on solution) The physical name for an ERP nonspecific landing table can be prefixed as ‘C_L_ALL_’ Example: ERP source system Party Address Relationship Landing could be C_L_ERP_PRTY_ADDRSS_REL. For the common landing table could be C_L_ALL_PRTY_ADDRSS_REL. |
Column Name |
The display names should be short and simple yet as descriptive as possible, having a meaning to the business users, such as for the data stewards. Where possible, this name should be the full unabbreviated name and in title case. Also, in case of foreign key columns referenced to ROWID_OBJECT, it should be prefixed as ‘Rowid <Parent BO Name>’. For example: In the Party Address Rel table, the BO Party ID foreign key column can be ‘Rowid Party’. |
In MDM, the physical column name has a limitation of 25 characters, hence it should likely be created as an abbreviation. This abbreviation can be one meaningful to the business or one generated by the developer by removing vowels from the unabbreviated name.
Example: In the Party Address Rel table, the BO Party ID foreign key physical column can be named as ‘ROWID_PARTY’, and Relationship start date column can be named as ‘REL_STRT_DT’. |
Packages and Queries Naming Standards
MDM Queries
Queries are dependent on the base object columns from which they retrieve data. A query can be used in several packages, and the description should be descriptive of the base object. If multiple queries for same base objects need to be created based on different purposes, then it should be grouped into a respective Query group. Associating ‘PUT’ or such kind of text with query name is not recommended since a ‘PUT’ option is associated with packages for queries having ‘Rowid_Object’.
A query name can be prefixed with ‘QRY_’ followed by <BO Name>.
For example, query name for REL Party Address base object can be named as ‘QRY REL Party Address’.
MDM Packages
A package is a public view of one or more underlying tables in Informatica MDM Hub. A package physical name can be prefixed by PKG followed by BO name.
If multiple MDM packages (i.e., PUT and Display packages) are defined for the same base objects or same underlying queries, then it can be suffixed with ‘PUT’ (in case of PUT package only).
For example, display package name for Party Address Rel base object can be named as ‘PKG REL Party Address’ and Physical name can be ‘PKG_REL_PRTY_ADDRSS’.
Hierarchy Configuration Naming Standards
Hierarchy Manager (HM) works with relationship data that defines the relationships, affiliations, and hierarchies among various entities. The naming standards are very important during hierarchy configuration since entity objects, hierarchies and relationship types are visible to business users or data stewards. If the names are not meaningful, it can negatively affect the business.
| Object | Name |
Entity Objects |
Names can be similar to Base Object name: short and simple yet as descriptive as possible, having a meaning to the business users (e.g., Party, Product, etc.) |
Entity Types |
Entity type is a logical classification of one or more entities. The name should be short, simple and meaningful to business entity names (e.g., Organization, Person, etc.) |
Hierarchy |
Hierarchy is a set of relationship types. Relationship types are grouped together for ease of classification and identification. It can be named as logical grouping of the different types of hierarchy (i.e. Customer, Product, etc.). |
Relationship Objects |
A relationship describes the affiliation between two specific entities. The name should hold the combination of two related entities suffixed with ‘Rel’ to designate ‘Relationship’ (e.g., Party Account Rel, Party Party Rel, etc.) |
Relationship Type |
Relationship type should reflect the real-world relationships between entity types. Also, it should support multiple relationship types for each relationship (e.g., Person to Person relationship can be ‘Employs’, ‘Spouse of’ and Party to Product relationship can be ‘owns Product’, ‘prefers Product’, etc.) |
Match-Merge Naming Standards
During match-merge setup, consider the following limitations:
- Physical name of the Match path should be less than 24 characters
- Exact match column name should be less than 27 characters
The naming conventions for match-merge setup are:
Object |
Name |
Match Path |
Match paths are used for configuring match column rules involving related records in either separate tables or in the same table. The display name should be child base object display name. The physical name for match path can be prefixed with ‘C_MT_’ followed by a child base object name (e.g. match path from Party to Party Address Rel display name can be Party Address Rel and physical name can be ‘C_MT_PRTY_ADDRSS_REL’). |
Match Columns |
The exact match column name can be prefixed with ‘Ex_’ followed by purpose of the match column. The Fuzzy match column would be as per the MDM defined field name (e.g., Exact match column for full primary address can be named as ‘Ex_Primary_Address’). |
Match Rule Set |
Match rule set name should be a unique, descriptive and meaningful name based on the rule set purpose (e.g., Initial Data Load match rule set can be named as ‘IDL’, online match rule set name can be named as ‘Online’, etc.). |
C360 Data Model Extension Considerations
If using the out-of-the-box C360 model in an implementation, there are best practices and guidelines for extending the data model to fit solution requirements. These can be found in Chapter 6 (‘Extending the Data Model’) of the current versioning of the C360 Data Dictionary.