• Success
    Manage your Success Plans and Engagements, gain key insights into your implementation journey, and collaborate with your CSMs
    Success
    Accelerate your Purchase to Value engaging with Informatica Architects for Customer Success
  • Communities
    A collaborative platform to connect and grow with like-minded Informaticans across the globe
    Communities
    Connect and collaborate with Informatica experts and champions
    Have a question? Start a Discussion and get immediate answers you are looking for
    Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
  • Knowledge Center
    Troubleshooting documents, product guides, how to videos, best practices, and more
    Knowledge Center
    One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
    Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
    Information library of the latest product documents
    Best practices and use cases from the Implementation team
  • Learn
    Rich resources to help you leverage full capabilities of our products
    Learn
    Role-based training programs for the best ROI
    Get certified on Informatica products. Free, Foundation, or Professional
    Free and unlimited modules based on your expertise level and journey
    Self-guided, intuitive experience platform for outcome-focused product capabilities and use cases
  • Resources
    Library of content to help you leverage the best of Informatica products
    Resources
    Most popular webinars on product architecture, best practices, and more
    Product Availability Matrix statements of Informatica products
    Monthly support newsletter
    Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
    End of Life statements of Informatica products
Last Updated Date Oct 20, 2021 |

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.

Table of Contents

Success

Link Copied to Clipboard