Best practice for a "widget" dimension

[20 Ton Squirrel]

Time for a question from an Absolute Rookie™! I want to build a cube for data entry on widgets. Each widget has specific properties, those properties are: display size (from 1" to 120"), resolution (x by y, probably 30 elements), technology (TFT, OLED, CRT, etc…), and category (tv, smartphone, mobile pc, etc…).

Which scenario makes more sense:

• Each property is a dimension. You will never see certain combinations such as a 100" 4K CRT, so rules referencing a control cube could restrict entry to existing definitions. Disadvantage might be that it is difficult to make summaries that cross multiple dimensions.
• Each property is an attribute on a single dimension. A more direct approach to defining elements BUT the end user would not be able to easily see these attributes lined up and filter on a specific property. Also, the server is not configured for multiple hierarchies so I can't experiment with that.

I assume scenario #1 would be best but I've heard whispers of complexity and bloat and such. Any thoughts? Prayers?

[lotsaram]

If your requirement is that users do manual data input then there's a 3rd and better option. Store the properties as attributes on the product or SKU dimension and make the data entry cube flat with respect to all the extra attribute dimensionality. Even with rules to prohibit data entry against invalid combinations, as a user needing to select the correct combination of dinensions / display type / category / brand / etc. will be tedious and error prone. You are much better to use a flat data entry cube and then post-process the data to a multi-dimensional analysis cube with TurboIntegrator on demand (the process would be very quick so there wouldn't be any delay when peoply want to analyse the data against the dimensions).

These days I would actually recommend using alternate hierarchies on the product dimension for this purpose versus separate dimensions, but you say that's not possible (are you still on v10.2?). However using separate dimensions is also perfectly fine, as long as there aren't too many of them. I have seen folks get carried away with attribute driven dimensions and have an analysis cube with 50 odd dimensions that no one can use.

[Wim Gielis]

Indeed, make a simple (input) cube and have a TI process sitting behind a button, to populate a second (reporting) cube . Use picklists where needed, you can make them dependent on each other and "guide" the user to less and less combinations to pick from.

[20 Ton Squirrel]

Thank you both for the advice! I had not considered how the dimension count would detriment the user experience. Most of the end-users are techno-phobic and opposed to moving into TM1, I must be very cautious in my development for user acceptance.

I'm on 11.7.00002.1 so it should be capable of hierarchies but there apparently is an option that isn't set in the configuration. When I am in PAW trying to create a new hierarchy it spits an error "New hierarchy creation is disabled"

The server admin is out on personal leave for the next two weeks. I have server-side access so I could stop/start/modify aspects of the server but I'm a newb-nugget on TM1, I don't want to break anything. Do you know if this is difficult to enable?

[20 Ton Squirrel]

ALSO!

Let's say I make the cube flat-ish by just having product, time period, and measure fields. For the product, how do you typically handle naming conventions for the element?

I'm loading historical data in from relational database exports, ongoing production for the data will be manual inputs by analysts through PAW or PAX.

There are in actuality about 18 fields that act as descriptors for a unique product descriptor. Size, resolution, technology, category, panel shape, panel form, substrate material, etc...

Do you just concatenate everything into a single descriptor? For example: Automobile Monitor; Heads-up Display; TFT LCD; LTPS; 2.6"; 800 x480; LED-Edge; Standard Shape; Notched Form

Or something else?

I saw someone else's work where they made the dimension use a generated GUID as the element name and put the long description in an alias attribute. Since an alias has to be unique that seems like double the effort, but I'm curious if this was a common practice.

[Wim Gielis]

Thank you both for the advice! I had not considered how the dimension count would detriment the user experience. Most of the end-users are techno-phobic and opposed to moving into TM1, I must be very cautious in my development for user acceptance.

I'm on 11.7.00002.1 so it should be capable of hierarchies but there apparently is an option that isn't set in the configuration. When I am in PAW trying to create a new hierarchy it spits an error "New hierarchy creation is disabled"

The server admin is out on personal leave for the next two weeks. I have server-side access so I could stop/start/modify aspects of the server but I'm a newb-nugget on TM1, I don't want to break anything. Do you know if this is difficult to enable?

It's not difficult. Did you use google on: "New hierarchy creation is disabled" ? But be sure to know what you are doing...

05.png (34.57 KiB) Viewed 2069 times

[20 Ton Squirrel]

WOO! After scouring around for a bit I found where the config file was and added the line. After a restart of the server I was able to create a new hierarchy in PAW!

Now to start practicing and learning.

Thanks very much for the guidance, Wim. I like your website, too. I'll be learning MDX and I'll need all the help I can get, your content looks very informative.

[Wim Gielis]

Thanks very much for the guidance, Wim. I like your website, too. I'll be learning MDX and I'll need all the help I can get, your content looks very informative.

You’re welcome !