Forum Discussion
design approach for Queries
I think you've got the right idea in your last paragraph. If you want to slice the fact table by date or product then having these as separate tables is better. The Date dimension doesn't have to be imported - it can easily be created in powerbi.
There's lots of flexibility in powerbi so if a report designer is skilled in SQL and wants to manipulate data from a sql db (which might be designed in a highly relational format) to build a dimensional model, it's possible. Of course, the data might already exist in a warehouse so it might not require re-engineering. Other factors would be : Does the data require cleaning in Power Query? Are there sufficient skills in M or DAX ? Is there the required level of access to the db?
Writing the SQL to push the query processing to the SQL db would probably be a less flexible approach.
I think you've got the right idea in your last paragraph. If you want to slice the fact table by date or product then having these as separate tables is better. The Date dimension doesn't have to be imported - it can easily be created in powerbi.
There's lots of flexibility in powerbi so if a report designer is skilled in SQL and wants to manipulate data from a sql db (which might be designed in a highly relational format) to build a dimensional model, it's possible. Of course, the data might already exist in a warehouse so it might not require re-engineering. Other factors would be : Does the data require cleaning in Power Query? Are there sufficient skills in M or DAX ? Is there the required level of access to the db?
Writing the SQL to push the query processing to the SQL db would probably be a less flexible approach.
Thanks.