Showing results for 
Search instead for 
Did you mean: 

Similar to physical schemas, before designing your business schemas it is highly recommended to take the time to develop naming conventions if they are not already in place within your organization. Changing column names after the fact will cause issues with dashboards, so it is worth the time up front to design a set of conventions and a method of governance. 

What you should know before reading this article

We recommend that you are familiar with your data sources and these Incorta concepts before exploring this topic further:

These concepts apply to all releases of Incorta for both on-premise and cloud.

A business schema view consists of:

  • a name
  • an optional description
  • zero or more business schema view columns
  • zero or more business schema view formula columns
  • an optionally defined base table

Typically organizations will name the business schemas based on the functional area or domain that is represented by the data instead of the source, as a particular function (e.g. sales) may be pulling data from multiple systems.

A business schema view column has specific properties:

Property Control Description Configuration
Name text box Enter the column’s name; used in the fully qualified name of the column. Valid characters: A-Z, a-z, 0-9, $, _
Name must begin with a letter character
Label text box Enter a user friendly name utf-8 md valid characters, including emoji 


Description text box Enter additional information for the column, observable in the column details of the Analyzer. utf-8 md valid characters, including emoji 


Source Column/Formula* text box The fully qualified name of the source column in a physical schema table. Read-only

*Formula is a property of a Business Schema View Formula Column, and is not relevant to this discussion.

The recommended practice for Business Schema View Columns is to keep the Name identical to the name of source column whenever possible, while using Label to give it a Business Name. In the case of Formula Columns they will typically be identical, although the Name should follow the same standard (underscores, camel case, pascal case, etc.) as your physical schema.

A business name is an English phrase with a specific construction and length that describes a single data object (e.g., table, column name, etc.). Each business name comprises one or more prime words, optional modifying words, and one class word. It cannot exceed 100 characters in length. Systems developers can assist end users in the construction of meaningful business names.
Business names should meet the following guidelines:

  • Singular for nouns and present tense for verbs
  • As meaningful as possible
  • Self-documenting
  • Easily distinguishable

A prime word can be a single word, or a phrase such as Capital Asset. It is the most important modifier of the class word. It identifies the application area, major data category, table, or view, depending on the data object being named. They will often include the major data domains within your organization. Prime words should be identified and recorded for use in categorizing data. Some example prime words are Account, Product and Customer. Occasionally a data object clearly belongs to more than one data category. In such cases, the business name should include multiple prime words. 

Modifying words are used to add important business information to a business name. Thus, the addition of the modifying word "phone" to the business name "customer number" forms "customer phone number". Similarly, addition of the modifying word "last" to the business name "customer name" forms "customer last name". Modifying words can be any word or phrase needed to adequately describe a data object.

Abbreviations are not used in business names with few exceptions. One reason to do so is to limit the length of a business name, and then only if the abbreviation is for a universally known acronym or an abbreviation such as IRS.

Typically naming standards will come from a centralized data governance/data quality team. If your organization does not already have standards in use, this will hopefully provide a starting point to develop them yourself.

If you are feeling overwhelmed by all of this, there are additional resources you can look to, including ISO 11179-5, Information technology – Specification and standardization of data elements, Part 5: Naming and identification principles for data elements, or the Guide on Data Entity Naming Conventions from NIST.

Outside of adhering to validation rules, there is no "right" or "wrong" when designing naming standards as long as they are comprehensive, consistent, clear and communicated. And with a well-designed set of naming conventions, you will be ready to move on to designing your schemas.

Best Practices Index
Best Practices

Just here to browse knowledge? This might help!

Version history
Last update:
‎06-08-2022 03:14 PM
Updated by: