200 Near Identical Data Source Views in SSAS 2012 Cube: How to advise your clients to take a better path?
Hello Experts,
The cube models a sophisticated patient administration system; one would expect complex measures in healthcare.
Documentation: non-existent, Kimball nor Inmon are nowhere to be found, 200+ measure groups confuse the situation, next to no aggregations or partitions, and host of other elements.
Most worrying is that the prior contractor did not write a single line of MDX by employing the following strategy:
Looking forward to the responses!
Kind regards,
JohnAeris
Questions
What issues can creating 200+ views and avoiding MDX - when there are only 2 true fact tables – cause down the line?
How would you convince your client that their current path is not in their best interests?
Background
I’ve inherited an SSAS 2012 development from a previous contractor.The cube models a sophisticated patient administration system; one would expect complex measures in healthcare.
Documentation: non-existent, Kimball nor Inmon are nowhere to be found, 200+ measure groups confuse the situation, next to no aggregations or partitions, and host of other elements.
Most worrying is that the prior contractor did not write a single line of MDX by employing the following strategy:
Create 200+ views based on two fact tables in SQL Server.
Ensure each view contains filters to drive a measure.
Add all 200 views are to the cube as a new data source view, and sum or count a column from said view.
Issue
Despite spending 3 weeks trying to explain the issues to business and technical users with no multidimensional, data warehousing experience, the client believes there is nothing wrong with the current cube. Never had this challenge before!
Have you come across a situation like this before?
Looking forward to the responses!
Kind regards,
JohnAeris
ASKER
Hi Phillip,
Great points! The key challenge at the moment, is that creating a view from a fact table, adding it as as a dsv, then a simple count is seen as much faster than creating writing and testing MDX for instance.
I'm find it difficult to get across that this method will create issues.
Would it work if I created a list of potential pros and cons of the current method vs best practice?
Great points! The key challenge at the moment, is that creating a view from a fact table, adding it as as a dsv, then a simple count is seen as much faster than creating writing and testing MDX for instance.
I'm find it difficult to get across that this method will create issues.
Would it work if I created a list of potential pros and cons of the current method vs best practice?
I agree with you as to whether MDX would be better.
However, if the end users think that the current system works (if it ain't broke, don't fix it), then they will need a pretty good reason to do so. They will not care about "best practice"; they care about:
1. Does it do everything *I* want it to do?
and that's it. Put yourself into their shoes, and try and work with their point of view, and see if you can then make a good case for MDX.
However, if the end users think that the current system works (if it ain't broke, don't fix it), then they will need a pretty good reason to do so. They will not care about "best practice"; they care about:
1. Does it do everything *I* want it to do?
and that's it. Put yourself into their shoes, and try and work with their point of view, and see if you can then make a good case for MDX.
ASKER
Client is currently at pre-launch stage.
In terms of more complex measures requiring MDX (which they will DEFINITELY require in the near future) they don't have a need for it yet.
There is a window of opportunity this week to create a solid foundation by re-jigging the cube and getting ready to play better with calculated measures.
Question: Phillip, what issues do you see with the current 200+ measure groups / views / DSV approach above? Perhaps, if I can list these, it will help make a case?
In terms of more complex measures requiring MDX (which they will DEFINITELY require in the near future) they don't have a need for it yet.
There is a window of opportunity this week to create a solid foundation by re-jigging the cube and getting ready to play better with calculated measures.
Question: Phillip, what issues do you see with the current 200+ measure groups / views / DSV approach above? Perhaps, if I can list these, it will help make a case?
Three key points are:
Maintenance is the key one. What is something changes in the underlying structure of the data?
Adding additional features requires yet more views to be created.
Requiring the IT guy to do it (requiring additional time to do it) as opposed to being able to self-support (and doing it instantly).
Maintenance is the key one. What is something changes in the underlying structure of the data?
Adding additional features requires yet more views to be created.
Requiring the IT guy to do it (requiring additional time to do it) as opposed to being able to self-support (and doing it instantly).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
HI Phillip,
Followed your advice.
Despite multiple conversations and examples and walkthroughs, a simple email showing my way forward vs pitfalls of moving forward with old strategy did the trick. #WhoDaThunkIt?
The eventual decision was to can the project for 6 months, re-prioritise and re-plan then, come at the project again with a fresh approach.
Not an altogether unexpected outcome, but the best way forward in terms of resource management vs quality: client would never have achieved their goal with the current platform.
Thanks for the advice!
Followed your advice.
Despite multiple conversations and examples and walkthroughs, a simple email showing my way forward vs pitfalls of moving forward with old strategy did the trick. #WhoDaThunkIt?
The eventual decision was to can the project for 6 months, re-prioritise and re-plan then, come at the project again with a fresh approach.
Not an altogether unexpected outcome, but the best way forward in terms of resource management vs quality: client would never have achieved their goal with the current platform.
Thanks for the advice!
1. Don't criticise the previous person or his methods.
2. Talk about the advantages to your method (additional features at little cost?)
If the previous person's things break down, because something has changed:
1. Estimate the amount of time it would take to resolve it his way.
2. How much would it take your way (and additional features).
And if that doesn't convience them, then maybe there's nothing wrong with it for the end user.