Forum Discussion
shared dataset - grouping categories
Good afternoon group,
I have a question on how to group categories into different labels using shared datasets.
So I have my "shared dataset 1" published to workspache "shared workspace"
I have a report "Report 1" using the "shared dataset1" published to workspace "Report workspace"
My intend is to create more reports and and use the same "shared dataset 1" and avoid dataset duplication.
Since I'm using a shared dataset I cannot add new columns to my model. However, I need to run a count of records for a column which I have category1, category2, category3, categoryA, categoryB, categoryC and split them two into count for numbers and count for alphas. Is there a way to do this without having to go back to the shared dataset model?
Hey hespinoza ,
there is a very simple answer to your question: No
This is one of the downsides separating the report development from data model development.
Sometimes, the person developing the data model is also responsible for the report design, and this makes it apparent that the separation is at it's best just is a nuisance, because the person has to open the "data" pbix create the column Publix, close the pbix, refresh the "report" pbix, discovering a typo in the column name, opening the data "pbix" ...
Nevertheless, separating the data model from report design into two pbix, and also separating the workspaces has some great advantages, from my pov these are the 2 main advantages:
- the "data pbix" does not care if the pbi dataset is in import mode or directquery mode, it's not important if I switch the underlying database, if the table names and column names are the same, the "report pbix§ will work
- the "data workspace" can be considered as a database, this fact allows users the development (and publishing) of reports with Contributor role assignments inside the "report workspace" by honoring Row Level Security (RLS) applied to the dataset.
From my professional experience, the above aspects are worth the nuisance and I assume that there will be more feature in the future will honor this separation.
Unfortunately, you have to go back to the data model if you need a calculated column.Regards,
Tom
2 Replies
- TomMartens
Super User
Hey hespinoza ,
there is a very simple answer to your question: No
This is one of the downsides separating the report development from data model development.
Sometimes, the person developing the data model is also responsible for the report design, and this makes it apparent that the separation is at it's best just is a nuisance, because the person has to open the "data" pbix create the column Publix, close the pbix, refresh the "report" pbix, discovering a typo in the column name, opening the data "pbix" ...
Nevertheless, separating the data model from report design into two pbix, and also separating the workspaces has some great advantages, from my pov these are the 2 main advantages:
- the "data pbix" does not care if the pbi dataset is in import mode or directquery mode, it's not important if I switch the underlying database, if the table names and column names are the same, the "report pbix§ will work
- the "data workspace" can be considered as a database, this fact allows users the development (and publishing) of reports with Contributor role assignments inside the "report workspace" by honoring Row Level Security (RLS) applied to the dataset.
From my professional experience, the above aspects are worth the nuisance and I assume that there will be more feature in the future will honor this separation.
Unfortunately, you have to go back to the data model if you need a calculated column.Regards,
Tom
deep down I knew the answer and I was hoping I was wrong. it is a nuisance but I think is worth the data separtation to have more control/flexibility to share to other users. Thank you for your response.
