I've been in this field for more than a decade and I couldn't agree more. The tools, and even the underlying theory is stuck in the past, and every project I work on is hampered by the technology not meeting the expectations of (business) users who demand a much more intuitive way of working - because that's what the experience every day on consumer devices.
There are issues though with getting consistent and accurate measures that are not easily solved by just looking at the data - albeit at a very high level of detail) for example when customers move or change details, it's easy to lose track of where you should be reporting the facts. And depending on the volume of data it's not going to be a long term solution to recalculate everything every day - which is the mistake a lot of companies make when trying to cope with this.
The problem is in your question. The Cube. This is a construct that assumes that the underlying data is typed allowing it to be re-arranged into facts, characteristics and attributes, and unless you have the foresight to think of your db like this before you build your web app, it's hard going to squeeze it into the dimensional model.
In fact I'd go as far as saying that the dimensional model is no longer a suitable model for dealing with event based data generation, and that may be why you ask the question.
It's one of my personal goals to solve this, I have some thoughts but it's not quite my priority at the moment, but I'd love to hear what others have to say on this.
There are issues though with getting consistent and accurate measures that are not easily solved by just looking at the data - albeit at a very high level of detail) for example when customers move or change details, it's easy to lose track of where you should be reporting the facts. And depending on the volume of data it's not going to be a long term solution to recalculate everything every day - which is the mistake a lot of companies make when trying to cope with this.
The problem is in your question. The Cube. This is a construct that assumes that the underlying data is typed allowing it to be re-arranged into facts, characteristics and attributes, and unless you have the foresight to think of your db like this before you build your web app, it's hard going to squeeze it into the dimensional model.
In fact I'd go as far as saying that the dimensional model is no longer a suitable model for dealing with event based data generation, and that may be why you ask the question.
It's one of my personal goals to solve this, I have some thoughts but it's not quite my priority at the moment, but I'd love to hear what others have to say on this.