We offer Power BI consulting services using our Power BI Flexi Team and in this article we will describe our table naming conventions standards that our team members should adhere to. If you a website visitor (not part of our team) please note that we will use quite a specific way to name tables and feel free to adjust it to your liking.
When we work with Power BI solutions our best practice standards are to use dimensional modelling and hide any tables that are not either a fact table or a dimension (unless needed).
Historically developers would use technical names with prefix for a table for instance FactSales or DimDate, DimEmployee, however for Power BI we will use friendly names so we will include spaces and don’t use fact or dim prefix for each table.
Our standard is to use singular names for dimensions that describe it for instance Employee, however we do include the work Info as suffix to each table so here are a few examples:
- Employee Info
- Location Info
- Invoice Info
For dimension date table, we use Reporting Date to indicate it’s a main reporting table.
The reason we use Info at the end is first of all to indicate it’s a dimension table, but do it in friendly name way, and secondly most importantly is to avoid a conflict in table names which is fairly common in Power BI solutions. For instance Invoice table can be both a fact table and a dimension, and our standards are two separate it and call a dimension Invoice Info, and for the fact table we use Invoice Measures.
As explain in the previous example for fact table we give a meaningful business process name for instance Invoice, Sales, Payment and we add a suffix measures for example:
- Sales Measures
- Invoice Measures
- Payment Measures
By adding Info and Measures I can do a search for these rather unique names and also avoid conflict in names in fact and dimension tables.
Take care
Emil