We can look at Role Playing Dimensions from two angles.

  1. Technical point of view, it is just another fancy name to a database view or table that is used multiple times within the data warehouse.
  2. Modelling perspective, it gives multiple unique identities to same objects based on the usage context.

The key differentiation is that a single dimension tables is used multiple times within a single fact table.

  • Date / Time: Consider the scenario of sales order analysis. If one has to determine the time taken for shipment to reach the customer, it is the difference between Order Date and Received Date. The time dimension is common, but assumes two distinct identities during modelling.
  • Geography: In area of logistics management, let us say that packages need to be tracked from source and destination. The location codes used will be common for source, destination and any intermediate shipping points. Each transit point is referred to a single common dimension table.
  • Employee: In procurement decisions, typically there are two roles associated in a transaction. One employee creates the purchase order whereas another employee approves the same. In this case employee dimension plays multiple roles. In case of high value transactions, there could be multiple levels of approval.

Role playing and dimension conformity may look similar at high level, but there is a subtle difference. A role playing dimension is referred within the context of a single data mart whereas conformed dimensions cover entire data warehouse.

There are still lots of open questions regarding the clear line of separation between Conformed Dimensions and Role Playing Dimensions.

NOTE: In SAP BW, Reference Characteristic based info objects enable the same master data to be referred with different names e.g. CUSTOMER & DEBITOR, but essentially the base data is same irrespective of whichever object.