Design of a cube/s when users want to slice two sparse dims

[BigG]

Hi, I have a request to build what could be an ugly cube with Month x Year x Version x Measures ($) and include a company Employee list (1500 people and expanding) x Position list (1500 and expanding - essentially a one to one map to Employee with a couple exceptions). Hence if I report in the now and look at only the current version and current reporting month I will have a nice view (with supress zeros) of person and position. And if I want to report over time or across archived versions I will see relationships (based onthe actual data) change over the months and years, again with zero supressed. But, Cube is pretty empty all round and sparse, so not nicest for self service.

I can work with the above, but wonder if its the best approach... my other suggestions:
1) create a Position list that is not specifically one to one to employee (eg. the Positions are generic so group them), but apparently not possible as HR system position is a free text area so not grouped.
2) create cube with Employee list only and load the Position as a string measure field in cube (but they want to slice/ select and navigate through a position dim, not review data). Might work if we can filter select and slice on the text measure
3) Do same above but substitute Employee list with Position
4) give the users 3 and 4 cubes above as options

So, any contributions on alternates or similar experiences would be greatly appreciated... or I will run with one of the above

cheers in advance

[rmackenzie]

I think that the cube with both Employee and Position is fine. I agree that slicing views from this cube could be a struggle in some situations but you can manage this by paying more attention than average to usage of predefined subsets and views that will simplify user interaction by helping them get where they want to be in the cube quickly and efficiently.

[BigG]

Thanks for the reply, ran with the two dims and seeing what the users think