>>When you create and deploy a dashboard, by default PBI creates an in-memory compressed dataset. So users are interacting with the in-memory dataset, not with the data in SQL Server. You can define refreshes for the data, which would point back to SQL Server (possibly through a data gateway)
>>
>>You "can" set up what's called DirectQuery.....where the dashboard queries back to the sql server (or other data source) every time. However, that's not "normally" the usage pattern. More often than now, users interact with a PBI data model (for best performance), with the idea that data will be refreshed on some periodic schedule.
>
>Thanks, I understand the general line of BI is with read only data for analysis and decision making process. There will always be a time, however, that someone will ask for something to be updated. Generally, a process prepares the data into the platform. There would be pivot tables. If someone would like to add a status for example, I guess the best is to update the status from the source application itself. But, let's assume the soure application does not have it but the ETL phase does require it. I guess it would just be a matter of dealing with read only data from that point.
>

There also can be hybrid implementations if data preparation steps involved are too time consuming for total data pool. For instance a monthly time series analysis might
calculate current partial monthly data
read already calculated monthly pool data
calculate time series data back from current start position - which might be needed every time, since drop of terminal value is not distributed even or current events will create different factors if trying to estimate base values of empirical data.

You might consider this a "logical horizontal ETL table partitioning schema" if the updated data store is NOT partioned that way, only queries translate specific month ;-)