Naming conventions in BI

What naming conventions are for BI (measures and data model attributes)?
I’ve got an answere in the forum link to the topic

Naming conventions should be intuitive to your business and consistent throughout your reports. That way your report consumers will have a clear understanding of their meaning and can benefit from Q&A functionality for example

This is not the answer I expected.
When a data model has hundreds of measures and hundreds of columns, a dozen tables need a single universal approach to naming. You can’t leave this case entirely to the users ’ wishes. Each user, alas, can expect the same thing in different ways. There are industry standards and so on, which simplifies the life of both the developer and standardizes naming in data models if this is not available in companies (in small companies, as a rule, there are no internal standards for naming entities in information applications)

Hi AlexZi,

I share your concern that it seems like there is no good naming “standards” or conventions. But it is what it is - the power to name and customize means everyone can use different conventions.

However, that doesn’t mean there aren’t some bottom-up best practices that are filtering up to the community of users.

See here: https://exceleratorbi.com.au/best-practices-power-pivot-power-query-power-bi/
And here: https://www.accountingweb.co.uk/business/finance-strategy/power-bi-whats-in-a-name

Notice how this is “issue” is really an issue of all human language - there is no one person or organization that dictates what constitutes the rules of a language - it changes and evolves and people start to gravitate towards different conventions and rules (and then those rules get broken!) Hopefully with things like this community and forum we can help the process of some basic standards move along as well.

Cheers,

Chris

2 Likes

Hello-
Chris provided some excellent resources. Adding to his response, here are a couple of other sources that you may want to check out:

There is no right way to solve this “issue”. These are just guidelines to assist. If you work in an organization with multiple Power BI users, you could certainly create a naming strategy for all users in your organization adhere to.

I don’t think this is rocket science.

Use names that make the most sense of the data in the tables.

Customers; Data; Sales; Sales 2020; etc. etc.

I believe as long as you leave the underscore out of the names it’s more readable and easier to understand.

Just my 2 cents.

Guy

I’ve been on both sides of this issue (not with PowerBI, but other data applications). Guidelines are only for guidance, and really only matter to the designers and users of the given reporting environment.

Certainly you want standards within your environment, but your standards are not going to work for every other environment. Probably the better solution to consider is to map your tables to the Common Data Model (and before anyone asks - I have not done this yet, still new to working with dataflows).

Also, if you ever intend to use any of the AI visuals, the more understandable (and less code-like) your names are, the easier it will be for your users to get to the information they want.

like @GuyJohnson said, that’s “just my 2 cents” :slight_smile:

1 Like

In my early Power BI models, I prefaced my table names with “Dim” for lookup/dimension tables and “Fact” for fact tables because I thought it added an additional level of clarity and also because it organized the tables well in the Fields list. However, I stopped doing it mainly because I didn’t see any of the cool kids doing it in their models, and figured there must be an inherent problem with it. I strongly endorse the “do what works best for you and your users” direction of this thread, but I’m wondering whether any of you have strong feelings pro or con about this particular naming approach?

  • Brian
1 Like

My experience was that it was frustrating to have to rename anything that is automatically shown in the visual header (not table names so much, but certainly field names).

In normalizing my naming of field names, it became logical to rename my tables (I had retained the names coming over from my data source for reasons similar to those listed by @BrianJ )

And, when providing a dataset to someone who was less familiar with the original source, it was MUCH easier for that person to build out visuals when Tables, Fields, and Measures all had names that were more ‘business’ and less ‘IT technical’. :slight_smile:
Granted, I no longer have that person to assist with building the report visuals (~sigh~), but I will be sharing the dataset with Accounting eventually, so it’s still important that we agree on the names (since we are combining multiple data sources to build the Accounting solution).

2 Likes

Thanks - that makes a ton of sense.

Granted, I no longer have that person to assist with building the report visuals (~sigh~)

That does sound like heaven. Whenever I present a Power BI report, particularly to those who are not familiar with it, one of the first questions I get is “how long did it take you to do this?”. My answer is usually “XX hours start to finish, not including the time I spent obsessively tweaking visuals…”

  • Brian

Trust me you want to find a way to keep the name as intuitive as possible.

Reasons below

Easier for others to understand
Easier to reference inside measures with intellisense
Only way to make Q&A more natural when asking questions
Prepopulating of titles and axis names
Better continuity for all those who may work on the model

There could be others these are just once I can think of right now.

My other suggestion as well if you feel your model is very large, is to simplify it.

I’ve worked on a number of larger models and have found that if I simplify things and optimise table, columns and measures, then it never really gets out of hand.

Thanks
Sam

2 Likes

Hi @AlexZi, we’ve noticed that no response has been received from you since the 28th of February. We just want to check if you still need further help with this post? In case there won’t be any activity on it in the next few days, we’ll be tagging this post as Solved. You may reopen a new thread when the need arises.