What is the best data structure for loading an enterprise Power BI site?

Question

Hi folks, I'd sure appreciate some help here!
I'm a kinda old-fashioned gal and a bit of a traditionalist, building enterprise data warehouses out of Analysis Service hypercubes with a whole raft of MDX for analytics.  Those puppies would sit up and beg when you asked them to deliver up goodies
to SSRS or PowerView.
But Power BI is a whole new game for me.  
Should I be exposing each dimension and fact table in the relational data warehouse as a single Odata feed?  
Should I be running Data Management Gateway and exposing each table in my RDW individually?
Should I be flattening my stars and snowflakes and creating a very wide First Normal Form dataset with everything relating to each fact? 
I guess my real question, folks, is what's the optimum way of exposing data to the Power BI cloud?  
And my subsidiary question is this:  am I right in saying that all the data management, validation, cleansing, and regular ETTL processes are still required
before the data is suitable to expose to Power BI?  
Or, to put it another way, is it not the case that you need to have a clean and properly structured data warehouse
before the data is ready to be massaged and presented by Power BI? 
I'd sure value your thoughts and opinions,
Cheers, Donna
Donna Kelly

Answer 1

Dear All,
My original question was: 
what's the optimum way of exposing data to the Power BI cloud?
Having spent the last month faffing about with Power BI – and reading about many people’s experiences using it – I think I can offer a few preliminary conclusions.
Before I do that, though, let me summarise a few points:
Melissa said “My initial thoughts:  I would expose each dim & fact as a separate OData feed” and went on to say “one of the hardest things . . . is
the data modeling piece . . . I think we should try to expose the data in a way that'll help usability . . . which wouldn't be a wide, flat table ”.
Greg said “data modeling is not a good thing to expose end users to . . . we've had better luck with is building out the data model, and teaching the users
how to combine pre-built elements”
I had commented “. . . end users and data modelling don't mix . . . self-service so
far has been mostly a bust”.
Here at Redwing, we give out a short White Paper on Business Intelligence Reporting.  It goes to clients and anyone else who wants one.  The heart
of the Paper is the Reporting Pyramid, which states:  Business intelligence is all about the creation and delivery of actionable intelligence to the right audience at the right time
For most of the audience, that means Corporate BI: pre-built reports delivered on a schedule.
For most of the remaining audience, that means parameterised, drillable, and sliceable reporting available via the web, running the gamut from the dashboard to the details, available on
demand.
For the relatively few business analysts, that means the ability for business users to create their own semi-customised visual reports when required, to serve
their audiences.
For the very few high-power users, that means the ability to interrogate the data warehouse directly, extract the required data, and construct data mining models, spreadsheets and other
intricate analyses as needed.
On the subject of self-service, the Redwing view says:  Although many vendors want tot sell self-service reporting tools to the enterprise, the facts of the matter are these:
v
80%+ of all enterprise reporting requirement is satisfied by corporate BI . . . if it’s done right.
v Very few staff members have the time, skills, or inclination to learn and employ self-service business intelligence in the course of their activities.
I cannot just expose raw data and tell everyone to get on with it.  That way lies madness!
I think that clean and well-structured data is a prerequisite for delivering business intelligence. 
Assuming that data is properly integrated, historically accurate and non-volatile as well, then I've just described
a data warehouse, which is the physical expression of the dimensional model.
Therefore, exposing the presentation layer of the data warehouse is – in my opinion – the appropriate interface for self-service business intelligence.
Of course, we can choose to expose perspectives as well, which is functionally identical to building and exposing subject data marts.
That way, all calculations, KPIs, definitions, and even field names, and all consistent because they all come from the single source of the truth, and not from spreadmart hell.
So my conclusion is that exposing the presentation layer of the properly modelled data warehouse is – in general - the way to expose data for self-service.
That’s fine for the general case, but what about Power BI?  Well, it’s important to distinguish between new capabilities in Excel, and the ones in Office 365.
I think that to all intents and purposes, we’re talking about exposing data through the Data Management Gateway and reading it via Power Query.
The question boils down to what data structures should go down that pipe. 
According to
Create a Data Source and Enable OData Feed in Power BI Admin Center, the possibilities are tables and views.  I guess I could have repeating data in there, so it could be a flattened structure of the kind Melissa doesn’t like (and neither do I). 
I could expose all the dims and all the facts . . . but that would mean essentially re-building the DW in the PowerPivot DM, and that would be just plain stoopid.  I mean, not a toy system, but a real one with scores of facts and maybe hundreds of dimensions?
Fact is, I cannot for the life of me see what advantages DMG/PQ
has over just telling corporate users to go directly to the Cube Perspective they want, that has already all the right calcs, KPIs, security, analytics, field names . . . and most importantly, is already modelled correctly!
If I’m a real Power User, then I can use PQ on my desktop to pull mashup data from the world, along with all my on-prem data through my exposed Cube presentation layer, and PowerPivot the
heck out of that to produce all the reporting I’d ever want.  It'd be a zillion times faster reading the data directly from the Cube instead of via the DMG, as well (I think Power BI performance sucks, actually).
Of course, your enterprise might not
have a DW, just a heterogeneous mass of dirty unstructured data.  If that’s the case,
choosing Power BI data structures is the least of your problems!  :-)
Cheers, Donna
Donna Kelly