Saturday, 17 June 2017

Putting Multiple Rows into a Single Row

This is a requirement which I face quite often in my current project, with a FMCG MNC where the client asks us to converge multiple rows into a single one. This can be done using various tools, but I am using OBIEE to demonstrate the case.
For understanding, let’s take the example of 'Employees' with different 'Skills' working / have worked in multiple 'Projects' (couldn't think of any better example).

So I have got 5 tables with relationship as below:

Now, I get these tables in the BMM Layer i.e. Business Modeling and Mapping OR Logical Layer, and from there expose them to presentation.

When I select "Employee" Dimension Table and "Project" Dimension Table, it works fine i.e these Employees have worked in various Projects over the time as shown by the below screenshot:

Similarly, when "Employee" Dimension Table and "Skill" Dimension Table are selected that also works fine which means these Employees have different set of Skills as given below:

But when all the three Dimension Tables i.e. "Employee", "Project" and "Skill" are brought together, the relationship is displayed as below:


The problem with above diagram is that, it shows the Employee having all the Skills in all the Projects. As EMPLOYEE_D is the connection between ALLOCATION_F and SKILL_MATRIX_F, so the cardinality between ALLOCATION_F and SKILL_MATRIX_F is N : N and hence the data is displayed as shown in the above screenshot.

As "Skill" is associated with "Employees" only, and the Business Requirement is to put the Skills / Employee into a single cell. But when EMPLOYEE_D and SKILL_D tables are queried on EMPLOYEE_SID and SKILL_DESC, the result is somewhat as given below:

But, there is a function in Oracle i.e. ‘LISTAGG’, which can converts multiple rows into a single row. When the same columns are used in a query using the LISTAGG function, as shown below; the result of the query looks quite similar to the Business Requirement.

Now I will create an Opaque view in the RPD with the same SQL, let’s call it SKILL_VW.


Now I join the newly created view SKILL_VW with ALLOCATION_F Fact Table on EMPLOYEE_SID. See the screenshot below for reference:


The revised Physical Layer looks like:
And when I display EMPLOYEE, PROJECT and SKILL using the view SKILL_VW in the Presentation Layer, the result is:


If you are aware of any alternative approach for meeting this requirement, then please leave your approach as comments below.

2 comments:

  1. Thank you for this post - it was a life-saver.

    ReplyDelete
  2. I feel there is a need to provide some more information about tableau and various other aspects of Power BI.

    Tableau Rest API Connection

    ReplyDelete

Implementing & Testing Row Level Security in Power BI

I have suffered a great deal of pain while implementing and more so while validating Row Level Security in Power BI. Let me try to capture a...