“But when a data mart is designed when people have not understood the source data, then it is alarming ” yes indeed, but equally so when a “report” (be that PowerPivot or whatever) is generated by people who do not understand the data, this too is alarming.

As per my post, even when data mart designers know the source data, the restricted view exposed by their data marts are often “alarming” as well, either due to lack of business knowledge or designing against a view of the business that is no longer relevant.

And, even if the data mart designers get everything right on the night, the business, and the environment it operates in, continues to change; the models age and eventually fail.

All have costs; ETL being usually the most significant, but bad business decisions made by bad analysis or bad data can be much more expensive. Data prep, be that simply in the mind of the data analyst, or codified in an ETL process, is the constant; which one will be needed is dependant on the circumstances.

Star-schemas are simply a choice of model (a logical CDM, as per Inmon, is another option) generated as a result of an ETL process. For many current BI tools they’re not optional, you most provide a star-schema (or construct an OLAP hypercube) but tools such as PowerPivot (and the likes of Business Objects in the past) do not require one. The ETL process is where the cost lies, if you can do without it you’ll save up-front money, but only if your target data/business analysts are comfortable working with the source raw data.

Tom

But yes, everything does depend on the source system data schema, a bespoke, data-design-close-to-the-business-view dataset will generally be easier to ad-hoc report on, either by SQL or DAX. However, most businesses depend on packaged software for their core operations, and being packages they tend to be highly configurable (mainly through config holding many-to-many relationships); such schemas can be very difficult to phrase reports against. Hence, the likes of SAP offering starter-pack star-schemas as part of their reporting tool set.

Likewise, merging datasets from multiple internal/external systems (some may not even be relational, but API provided or using noSQL datastores) can often require the development of a new data model, again, in such situations a dimensional model may best suit. And even if not, potentially costly ETL will still be part of the equation.

When OLTP data models are understood inside out, when staff have the necessary SQL or programming skills ,and have the time and the budgets, to quickly generate ad-hoc reports (and package them into “pretty artefacts”), then, no extra data models (or BI tools) are required. In such situations, building a star-schema may indeed be largely pointless.

But very few of the world’s businesses are in that exact position. Tools like PowerPivot/DAX are not silver bullets, they are however, still bullets, which when used in the way best suited for a particular situation (some ETL-free, some heavily supported by ETL processes), are a godsend for many.

Tom

Tom

Yes, agree with both points.

But there’s also a significant number of users (and business developers) who understand (or are capable of understanding) OLTP schemas and there are many who today report successfully against such schemas using SQL or SQL generating tools such as Business Objects.

DAX (via the underlying relationship logic) makes the production of sophisticated reports against such models much easier than is the case with SQL. So for these situations a hypercube view of the data can be generated without strict star-schema modelling.

But my (somewhat tongue in cheek) headline was not so much directed at the general use or benefits of dimensional modelling, but its traditional use as the end-product of centralised modelled data warehouses.

Tom

For me, powerpivot breaks ground for the end user because it removes reliance on the modelled data warehouse by providing the ability to combine large information from several sources (something which IT as the custodians of the data warehouse are notoriously slow and expensive for). This could potentially see a changing of the ‘information guard’ as the warehouse lager of information needs rather than the leader.