when is drilling through OK?

[Chumpski]

Hi,
I am thinking about building a very simple cube where one of the facts is just a count of tasks associated with a project. Not every project will have a task so I was planning to hold the details of these tasks outside of the cube in a relational table in the data warehouse. I would then control the linkage to this table in the reporting front end so users can drill through and see all the information associated with the task. Is this an acceptable way of doing this?

[ngalemmo]

The concept is ok, but the cube sounds a bit thin. The point of deploying a cube is that the end user would be able to do a sufficient level of analysis within the cube itself. Drill through would only be performed occasionally because the time it takes to do the drill through is, relatively speaking, considerably longer than working within the cube. The way I read your description, drill through would be the norm rather than the exception.

[Chumpski]

Hi,

Thanks for the reply and I agree 100% with what you say the issue here is that conceptually the lowest level of granularity where the measures exist is the project, and a task is purely an attribute of that tasks in that it only need to be there for the user to drill into and view. My issue is that there might be more than one task associated with a project and I am not sure if this can be modelled into a cube, which is why I came up with the drill through method.

[ngalemmo]

Task (and related attributes) would just be another dimension in the cube. The issue would be the number of tasks and resulting size of the cube. In general, cubes handle sparsity fairly well these days, so I would try that first before considering drill through.

[Sponsored content]