Semarchy xDM naming convention

When designing a logical model, it is necessary to enforce a naming convention to guarantee good readability of the model and a clean implementation.
There are several names and labels used in the objects in Semarchy xDM:

  • Internal names (also called names) are used mainly by the Model designers and are unique in the model. They can only contain alphanumeric characters and underscores, and must start with a letter.

  • Physical names and prefixes are used to create the objects in the database corresponding to the logical objects. These can only contain uppercase characters and underscores.

  • Labels and descriptions are visible to the users (end-users and data stewards) consuming data through the UI. These user-friendly labels and descriptions can be fixed at later stages in the design. They are externalized and can be localized (i.e., translated) within the platform.

The following tips should be used for naming objects:

  • Use meaningful internal names. For example, reference relationships should all be named after the pattern <entity name><relationship verb><entity name>, like CustomerHasAccountManager.

  • Do not try to shorten internal names excessively. They may become meaningless. For example, using CustAccMgr instead of CustomerHasAccountManager is not advised.

  • Use PascalCase for internal names as it enables the use of the auto-fill feature (e.g., ContactBelongsToCustomer, GeocodedAddressType).

  • Define team naming conventions that accelerate object type identification. For example, types and lists of values can be post-fixed with their type such as GeocodedAddressType, GenderLOV.

  • Define user-friendly labels and descriptions. Internal names are for the model designers, while labels and descriptions are mostly defined for end users.

The following table lists a typical naming convention you can adapt to your project.

Object Name pattern Examples

Model

[Model Name]

StoresAndSuppliersMDM, ItemCatalog

Entity

[Entity Name]

Product, Item, Customer

Attribute

[Attribute Name]

IsProductAvailable

Reference

[From Entity]Has[To Entity][Role]

EmployeeHasEmployeeManager

Reference Role To

[Role Name In Singular]

Manager

Reference Role From

[Role Name In Plural]

ManagedEmployees

Complex Type

[ComplexType Name]Type

AddressType

User-Defined Type

[Type Name]Type

SimpleStringType

Publisher (Code)

[CODE]

MDM

Publisher (Name)

[Publisher Name]

MDM Application

Job

[JOB_NAME][JOB_TYPE]

INITIAL_LOAD_FULL, CERTIFY_PRODUCT_SIMPLE

Form

[Form Name or Kind]Form

DefaultForm, ProductAuthoringForm, ProductReviewForm, MediaSimpleForm, ItemsMainAttributesForm

Collection

[Collection Name or Kind]Collection

DefaultCollection, AllAttributesCollection

List Of Values

[LOV Name]LOV

CurrencyLOV, ProductTypesLOV

Business View

[Business View Name]([optional Classification])

Products, ProductsByCategory, EmployeeHierarchy

Transition Name

[Reference Role From]

ManagedEmployees

Stepper

Author[Entity Name]s

AuthorProducts, AuthorCustomers

Stepper Collection Step

[Entity Name]s or [Referencing Role Name]

Products, Customers, RelatedItems

Stepper Form Step

[Entity Name]

Product, Customer, Item

Action Set

[Action Set Name Or Purpose]ActionSet

CustomerActionSet, ProductImportExportActionSet, ProductCreateEditActionSet

Application

[Application Name]

ProductSearch, ProductDesign, ReferenceDataManagement

Folder

[Folder Name]

ProductsManagement

Workflow

[Workflow Name]

CreateOrModifyCustomers, InitiateFullProductCreation, RequestProductLabelChange

Workflow Task

[Task Purpose]

CreateProductBasicInformation, AddTechnicalDetailsForProduct, VerifyProductCreation

Workflow Transition

[Transition Verb/Action]

SendDataForApproval, RejectRequestAndAskForMoreInformation, AcceptAndSendToMarketing