When designing a data mart it’s a good idea to follow a naming convention. Although this requires some thought in the design stage, it saves significant time when maintaining and enhancing the data mart with new data for analysis. Your current and future users will benefit and be in a position to use the data to deliver superior services to members and other stakeholders. Although there are a few system limitations to dictate the naming conventions you choose, careful consideration should be given to the naming due to the very important human factor. Here are a three tips to get started:Naming data marts dsk

Consider the Audience

There are typically 3 groups who will be using the data mart:
The business end users. These are the people that will never see the data mart, but will instead see the beautiful and accurate data visualizations based on the well-managed information in the data mart.
The power users. These are the people who work with the visual interface. Many of our clients use Tableau to create data visualizations and use a data mart as the data source. To be successful, they should have an understanding of the structure of the data mart and how to translate the data to provide the information needed for the business end users.
The technical team. These are the technical experts that are responsible for building and maintaining the data mart and ensuring its quality.

Each of these groups of should be considered when deciding on what to name fields, but it’s likely the power users will have the most knowledge about both the technical and the business needs and their opinion and buy in are vitally important.

Avoid ambiguity

A field called Order is not clear. Instill clarity by using names that identify if it is the Order ID, the Order Date, etc. If a field has a Yes or No value, it might be helpful to add _YN to suffix the column name. For example, Member YN clearly indicates that this is a Yes/No field and isn’t something like the member’s name.


Data dictionary. A data dictionary is a collection of all the metadata in your data mart and is helpful for the power users and technical team. This dictionary contains an entry for all of your data elements. Some fields you might want to include: the definition, how the field is derived (if it is calculated or is straight from the source database), the name of the data source from which it came, business rules, update frequency, the data type and when it was last updated.

Common Language Dictionary (CLD). A common language dictionary is essential to define in common, business language what each field means to your association.  For example, we have seen many different definitions of a “member” – depending on whether you count them if they are in the grace period, whether they have paid or just completed an application, etc.  A list of common terms to define for associations can be found on one of our previous blogs How to Create a Common Language Dictionary

You will encounter many opinions on naming conventions and on ways to document and communicate the information about the data mart. The time you invest in the design stage can be the difference between success and failure of future projects. It is critical  to think carefully and deliberately about how you are going to name the elements your data mart to benefit your association now and into the future.