Should you call it a junk dimension?

Datamarts, cubes, tabular models...they all present a dimensional model to the end user that is intuitive. At least, that should be the case. So no abbrevations in the dimensional model. Business users tend to prefer to see the data in the same way they speak about it. So a product is a product, not a dim_product.

So far, so good. Except what does a business user think when he sees a table called 'Dim_Junk'? 

A junk dimension is a dimension that holds attributes together from various source systems that don't really belong in any single dimension. However, you still like to have them available for analysis. Kimball suggests that you put them all together in a 'junk' - dimension just for that reason.

Back to the question. How shall we name the junk dimension? We can make two distinctions:

  1. the name it has in the underlying table structure
  2. the name it has presented to the end user via views or another abstraction.

It would make sense to call it a junk dimension in 1 so the developer knows exactly what kind of dimension it is. The end user is best of with a more friendly name such as 'rest-dimension' or something else.

However, should we call it a junk dimension in any case? Even if the end users do not know the underlying table structure, would he like to hear developers talk about junk dimensions? Maybe it's time for a different name, even in the table structure.

Principal BI consultant at Rubicon

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

2 Comments

  1. I know the issue. Names like "Other", "Filters", "Attributes" seems a mistake. Trying a meaningful name always end in a column that doesn't fit with the name. Display folders might help.
    The *real* solution would have been a layer to decouple the logical model (shown to end user) from the physical layer (table and column names in the model). The problem is the query engine. The query structure in both MDX and DAX depends on the physical structure. So a decoupling layer should include also an object model to build queries.
    Or metadata should include both physical and logical models, putting all the effort on the client's shoulder.
    I would like this feature, but I know we'll not see it....
    I should start to like "Others"...

    • Jesse Gorter

      Jesse Gorter

      "Others" sounds good. Even if the tables are hidden from the client: what if your development team talks about 'hey: we should look at the ETL for the junk dimension, it's buggy' and the client overhears it? 🙂

Next ArticleConfiguration Manager doesn't work for Tabular