Dimensions, Measures and Details!

general discussion
1

I’m very new to using these terms to structure data and I’m wondering if folks who have been working with them for awhile or who are at least comfortable with them could talk about how they go about defining these in their projects.

I was prompted to start this thread because I’m having trouble understanding at what point does some element go from being a detail to a dimension.

For example, we do repairs and maintenance on trains. They come in as a project of a particular type with a specific kind of work that needs to be performed. The company wants to know how many workers will be needed to do each phase of the work, what the workload is and how many hours or days a particular task will take.

So I have ‘Project’ as a dimension. There’s a start and a projected end date. There’s a type of locomotive. There are specific tasks. There are many different departments invlved in carrying out these tasks at different, but at scheduled/projected times. So ‘Project’ probably isn’t a single dimension. Would the Locomotive, it’s type, it’s assigned ID in the DB, it’s times of arrival be a dimension? What about the different departemnts that are doing the work? Is that a dimension…say ‘Departments’ which would contain the tasks they perform (say tasktypeID), supervisorID, managerID. Is Task then a Dimension on it’s own?

Part of my confusion is due to the fact that I’ve read a Star Schema consisteing of a single measure or fact usually suffices. As you can see this is pretty far outside my normal work area (I normally do C# development) so any help in getting my head around this or resources you can recommend would be very much appreciated!

VACoder :us: (BOB member since 2014-06-25)

2

My usual rule of thumb is, “Do you want to filter or sort on it?” If yes, it’s a dimension. If no, it’s a detail.

Note that like most rules of thumb, this is very crude, and can lead you astray. But it covers about 80% of your cases.

So, Project would definitely be a dimension (if that is a field and not a table, I was a bit confused by your description). So would start and end times. But if you have Project Number as the primary identifier, you might have Project Name as a detail.

Locomotive Number would definitely be a dimension. Locomotive Type might be a detail, depending on how important it is as a factor. That is, do people often want to know all the Projects being worked for a single Type? Or are they more likely to just want to drill into a particular Locomotive and see what Type it is? The first would be a dimension and the second would be a detail.

Lugh (BOB member since 2009-07-16)

3

I would also suggest that if you want to merge queries using it, it should be a dimension.
Also, details are useful if you wish to merge queries that have an incompatible dimension, as this saves creating it as a detail, in Webi to allow display in the same block.

Mak 1 :uk: (BOB member since 2005-01-06)

4

What is your task in this train maintenance business? Is there an application with a database people put data in and you have to report on it with BO?
Or something else?

HenkK

HenkK :netherlands: (BOB member since 2004-03-02)