Skip to main content

Suggest an Idea

Vote for your favorite Qlik product ideas and add your own suggestions.

Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE

Better Support for Role Playing Dimensions

ShireyJW
Contributor III
Contributor III

Better Support for Role Playing Dimensions

We have a fact table that has multiple references to the same dimension. Compose does a good job in creating only one physical table for the dimension (although it is role playing). It also shows this by appending the Entity name to the dimension attribute when displaying the star schema diagram. What we would like to have is a set of role playing views being generated to support this scenario. We would need each attribute to have a prefix appended to them representing the role for each view of this type.

Tags (1)
3 Comments
Tzachi_Nissim
Employee
Employee

Hi ShireyJW,

Thank you for your idea. Can you please provide more details? Currently if you have several references to the same dimension you get different VID columns to join the dimension with. So we are not clear about the role of the views here.

Regards,

Tzachi

Status changed to: Open - Collecting Feedback
ShireyJW
Contributor III
Contributor III
So I have two references to a Customer Dimension from a Fact Table (one role is Ship To and the other role is Bill To). Compose will generate two OIDs in the Fact table (Ship_to_Customer_OID and Bill_To_Customer_OID). Compose will generate one dimension view (Customer) with a Customer_OID. Since Compose is aware of the role (because it named the fact columns correctly), I would argue it should create the equivalent "role playing" views that match/join to each fact FK columns. In this case, there would be 2 views called Ship_to_Customer and Bill_to_Customer with appropriately named columns (i.e. the view name and the column names all get the role name appended to it). The benefit of this is that consumers of the data mart (PowerBI or SAP Analytics Cloud) modelers would create models that natively join together with matching column names (via automation) as well as the usage of the information becomes much more clear to the audience. For example, if a user shows the Bill_To_Customer_Name and the Ship_To_Customer_Name on the same report, it will be clear which "name" belongs to which role. Today, with the way it works, you will have to references to Customer_Name (which may or may not give you any indication of the role).
TimGarrod
Employee
Employee

This is not planned for Qlik Compose, but is under consideration for Qlik Cloud Data Integration and its data mart automation capabilities.

Status changed to: Closed - Archived