Bridge table to Role Playing Dimension

Hi,
Fact Sales table has role playing Customer dimension table related to it. For each role it had a relationship in the DSV. One on CustomerA the other on CustomerB.
Now I have a trip dimension which should have a many to many relationship to the customers table. So I set a bridge table relating trip to customer.
But when I slice by trip it only displays the sales that have CustomerA in the trip.
I want it to display the sales that have CustomerB in the trip.
How can I affect that?
Thank you
Namnami

When you create a M2M relationship, you specify 2 dimensions and one intermediate measure Group.
Even if the bridge table is loaded once in the DSV (even if you can just duplicate it to simplify its naming), you define two measure groups for the bridge table, one connected to Customer A and Trip A, and the other to Customer B and Trip B. Then, you define
M2M relationship between Trip A and Customer A using bridgeA as intermediate, and do the same for B.
Again, please, since M2M require understanding how it works internally, I suggest you to read the White paper I mentioned, because you have all the information there that will allow you to design the model you need. I think it's not a discussion that is
easy to complete in a forum thread, because M2M involves many side consequences in calculation (e.g. what happen to unrelated dimensions involved in calculation?).
Marco Russo (Blog,
Twitter,
LinkedIn) - sqlbi.com:
Articles, Videos,
Tools, Consultancy,
Training
Format with DAX Formatter and design with
DAX Patterns. Learn
Power Pivot and SSAS Tabular.

Similar Messages

Many to many relationship does not work on certain role played dimension

Hi,
I have a cube with role playing Account dimension, used once as “Account” and once as “Other Account” dimension.
I’ve added Trip dimension related to the account dimension by a bridge table AccountTrip
making a many to many relationship (many accounts can be in one trip and one account can go to many trips).
When I added the bridge measure group to the cube, I saw in the dimension usage tab that the relationship between the bridge and the Account dimension was done automatically.
I added the trip dimension with regular relationship to the bridge measure group and many to many relationship to the main fact table using the bridge group.
All compiled fine and gave correct results. Then I noticed that when slicing the fact table by the Other account dimension I get correct results,
but when I add the Trip dimension I get the results as if I was slicing by the Account dimension, not by the “Other account” dimension.
I checked the cube and noticed I did not set the relationship between the bridge to the “Other Account” dimension (role playing). I set it now (regular relationship, same as the account dimension), but still getting the same results.
Conclusion- when slicing by the new Trip (M2M) dimension and the “Other Account”
(role played) dimension I get the results of the “Account” dimension, not those of the “Other Account” dimension.
I checked the relationships of the “Other Account” dimension in the cube but it looks correctly set (to the external account of the main fact table and to account of the bridge table).
(Just to note I have two other bridges on the cube which are not related and don’t look like they need to be related, plus two other measure groups of the main fact table used for distinct count which are related appropriately).
What else should be done???
I would greatly appreciate your help!
Thanks
Namnami

The update server is down; try this temporary workaround
App Store>Purchased>Select "All"
Note: Look out for apps that have the word "Update"
http://i1224.photobucket.com/albums/ee374/Diavonex/9c256282736869f322d4b3071bbb2 a82_zps51a6f546.jpg

Distinct count of role-played dimension attribute

Needed distinct count of AccountGroup attribute of AccountB dimension which is a role played dimension of Account.
Added measure distinct count of the dimension attribute (AccountGroup). In dimension usage added the main fact table as intermediate for other dimensions with many2many relationships.
The two role played Account dimensions must be related to the new AccountFact table with fact relationship.
But then how will I be able to count distinct attribute of
certain Account dimension (out of the two role played dimensions)???
Namnami

Thanks for the links, they are useful. But still they do not explain how to manage a distinct count of
certain role played dimension attribute.
I gave up on this and added that dimension attribute to the fact table so now I do a regular distinct count on a cube fact measure.
Thanks
Namnami

OBI EE 10g: Bridge tables and Based on Dimensions Aggregation

hi experts,
i am working on OBI EE 10 g (10.1.3.4)
The BM&M layer consist of:
1) Logical fact table "Sale_Indicators"
Fields: SALE_ID (PK, FK),
D1_ID (FK),
D2_ID (FK),
Indicator1 (measure, level of granularity: SALE_ID),
Indicator2 (measure, level of granularity: SALE_ID),
Indicator3 (measure, level of granularity: SALE_ID)
2) Logical dimension table
"Sales" (PK: SALE_ID),
"D1" (PK: D1_ID),
"D2" (PK: D2_ID),
"Customers" (PK: SALE_ID, CUST_ID) - bridge table!
"Products" (PK: SALE_ID, PROD_ID) - bridge table!
3) Dimensions: SalesDim, D1Dim, D2Dim, CustomersDim, ProductsDim
If fact table is joined with bridge table, the number of rows in fact table is multiplied, for example:
D1_ID | SALE_ID | CUST_ID | Indicator1
777 | 1 | 14 | 10
777 | 1 | 17 | 10
777 | 2 | 15 | 12
888 | 3 | 16 | 20
888 | 3 | 17 | 20
888 | 4 | 19 | 30
I need to get report:
D1_ID | Indicator1 (SUM)
777 | 22
888 | 50
and with filter by customer, for example (CUST_ID = 17):
D1_ID | Indicator1 (SUM)
777 | 10
888 | 20
i am trying to use "based on dimension" aggregation, for example (Indicator1):
Dimension Formula
CustomersDim MIN
ProductsDim MIN
Others SUM
The generated physical SQL performs joining EVERY dimension to the fact table, even though they are not included in the final result set.
Is there any way to tweak logical or physical model in order to eliminate excessive joins?
Thanks in advance!
Edited by: 859688 on 31.10.2011 4:04
Edited by: 859688 on 31.10.2011 4:06
Edited by: 859688 on 31.10.2011 4:08

I found this text on the help, but I didn't understand, because when I check the "based on dimensions" check box, I can choose aggregation rules for each dimension, not only the time dimension.
Also, I found in the help menu:
"In the Aggregation tab, select the Based on dimensions check box.
The Browse dialog box automatically opens.
In the Browse dialog box, click New, select a dimension over which you want to aggregate, and then click OK.
In the Aggregation tab, from the Formula drop-down list, select a rule."
I did the same steps suggested by the text above, but it didn't work.

Automated Duplication for Role Playing Dimensions

Im wondering if there is way to automate (short cut method) to duplicate the entire Dimension.
Simply copying and pasting or Duplicating will not create the Hierarchies.
For Example:
I have Fact_Transaction (with columns Trx_Id, Trx_Date, Create_Date, Update_Date, Invoice_Date, Amount)
I have a date dimension joined to this fact in physical layer on the Trx_Date.
Problem:
Now if I get a requirement to show the other dates 2 as dimension,
I need to create alias for the same time dim and manually create the dimensions and hierarchies in the BMM layer.
Is there any much better way we can do this using some scripts (xudml, /commands, ..etc)
Thanks
Kaushik

Hi,
I think you have to create it manually...

How to create a role-playing Date dimension?

I have created a date dimension Date_Dim with three levels DayL, MonthL, YearL and one hierarchy YearL-Monthy-DayL. In the fact table, I need to refer to two date dimension: Start_Date and End_Date. For the Start_Date, we can refer it to the created physical date dimension Date_Dim. For the End_date, Ralph Kimball recommended to use a role-playing dimension. That is, create a view End_Date_Vw from the dimension table Date_Dim. My question is how to create it in OWB? Should we need to define the levels and hierarchies for the view in order to leverage the query-rewrite power? How to do that? Any advice or information is appreciated.
Lushu

Balaji,
You can refer to the same dimension more than once in the design of a cube (fact table). In a star schema implementation, you just end up with multiple foreign keys to the same times dimension (table). Once you integrate with a reporting tool, you refer to the same dimension using different names. Warehouse Builder supports this in the integration with Oracle Discoverer. The user's guide tells you how to do this (see http://download-west.oracle.com/docs/html/B12146_01/integrating.htm#sthref3659).
Thanks,
Mark.

Difference between Conformed dimnesion and Role play dimesion

hi,
I am not able to understand difference between Conformed dimension and Role play dimension.. Can anyone please explain the diff between both with real time example.
I am confused with Date Dimension.
Here i encountered, Cube dimension and Database dimension,what is that actually.
Thanks

Hi DevBi,
According to your description, you want to know the difference between database dimension and cube dimension. Right?
A database dimension is a collection of related objects, called attributes, which can be used to provide information about fact data in one or more cubes. What we created in BIDS is database dimension. For example, typical attributes in a product dimension
might be product name, product category, product line, product size, and product price. These objects are bound to one or more columns in one or more tables in a data source view.
Cube dimension is an instance of a database dimension in a cube is called a cube dimension and relates to one or more measure groups in the cube. A database dimension can be used multiple times in a cube. Those referenced and renamed for purpose database dimension
is role-playing dimension. For example, a fact table can have multiple time-related facts, and a separate cube dimension can be defined to assist in analyzing each time-related fact. However, only one time-related database dimension needs to exist, which
also means that only one time-related relational database table needs to exist to support multiple cube dimensions based on time.
Reference:
Role-playing Dimensions
If you have any question, please feel free to ask.
Simon Hou
TechNet Community Support

How to define an aggregation rule for a dimension based on bridge table?

Hello,
I need a solution for aggregating data correctly when using a dimension based on a set of dimensione tables containing a bridge table. Please find below a description of my business case and the OBIEE model which I’ve created thus far.
Business Case
The company involved wants to report on the number of support cases, the different types of actions that were taken and the people involved in those actions. One support case will undergo a number of actions (called ‘handelingen’) until it is closed. For each action at least one person is involved performing a specific role, but there can also be multiple persons involved with 1 action, each performing a different role for that action. This is the N : N part of the model.
The problem that I face is visible in the two pictures below:
http://i84.photobucket.com/albums/k24/The_Dutchman_2006/OBIEE/sample.png
As long as I don’t include anything from the Dimension Meelezer in my report, I get the correct number of handelingen (7). When I include the person (called ‘Meelezer’), the measuere per action is multiplied by the number of persons/roles involved with that action.
When I changed the Aggregation rule in the report column #Handelingen to ‘Server Complex Aggregate’ I do get the correct endtotal:
http://i84.photobucket.com/albums/k24/The_Dutchman_2006/OBIEE/sample2.png
I believe it should be possible to define in the repository a different aggregation rule for individual dimensions, but I’ve not been able to achieve this.
Explained below is what I have created in my Physical and Business Model & Mapping layers:
The Physical Model is built like this:
(This is just a small part of a much larger physical model, but I’ve only included the most relevant tables)
http://i84.photobucket.com/albums/k24/The_Dutchman_2006/OBIEE/PhysicalDiagram-1.png
The Fact table (ALS Feit Zaakverloop) contains FK’s for the action (FK_HANDELING, joined to ALS Dim Handeling), the date the action took place (FK_DATUM_ZAAKVERLOOP, joined to ALS Dim Datum Zaakverloop) and the uniqe group of people involved (FK_MEELEZERS, joined to ALS Groep Meelezers) and a measure column (SUM_HANDELINGEN) populated with the value ‘1’ for each row.
The Bridge table (ALS Brug Meelezer/Reden Meelezen) contains three FK’s: FK_GR_MEELEZERS (joined to ALS Groep Meelezers), FK_MEELEZER (joined to ALS Dim Functionaris) and FK_REDEN_MEELEZEN (joined to ALS Dim Reden Meelezen).
The Business Model
In the business model, the four physical tables for the N:N relation have been combined into one logical dimension table.
http://i84.photobucket.com/albums/k24/The_Dutchman_2006/OBIEE/BusinessModel-1.png
DIM Meelezer contains one LTS in which the four physical tables have been combined:
http://i84.photobucket.com/albums/k24/The_Dutchman_2006/OBIEE/LTS1.png
And all the required locical columns have been created:
http://i84.photobucket.com/albums/k24/The_Dutchman_2006/OBIEE/LTS2.png
DIM Meelezer has also been identified as a bridge table and a Business Key has been defined on a combination of the FK’s in the bridge table and business codes of the two dimension tables.
http://i84.photobucket.com/albums/k24/The_Dutchman_2006/OBIEE/BMDIM.png
Next a hierachy was created for Dim Meelezer:
http://i84.photobucket.com/albums/k24/The_Dutchman_2006/OBIEE/Hier.png
In Feit Zaakverloop, a measurement called ‘# Handelingen’ was created using SUM_HANDELINGEN, with an aggregation rule of SUM.
In the LTS of both the DIM Meelezer and Feit Zaakverloop, the Logical Content Levels have both been set to: LVL Detail – Meelezer.
Please provide suggestions that will NOT require changes to the physical datamodel as they would require too much time to achieve (or at leats would not be ready before my deadline.
Thanks!
Edited by: The_Dutchman on Dec 13, 2011 11:43 AM

Hmm, no replies yet...
Am I in 'uncharted territory' with this issue?

Distinct Count Measure on Dimension table via Bridge table.

Hi Team,
I have Dim_Devices Table, which is linked to other dimension like Dim_User and Dim_City.
All these table has many to many relationship defined in bridge table i.e. B_Devices_User_City using referential keys.
I want to derive measure such as
Select Count(Dim_Devices[Device_Id])
where Dim_Devices.Validity_End_Date is null
Note : Device_Id and Validity_End_Date are present in Same Dim_Devices Dimension Table.
Could you please help me to define cube structure and how to create such measure out of dim_table.

Hi Charlie,
Now, I have define DistinctCount Agreegation on Dim_Devices table which will use reference Relationship on B_Devices_User_City. My Count is correct.
But, I came across one more issue, i.e. From Processed and deployed cube, I am trying to create off-line Cube/or Global Cube (I have given syntax below) which is for limited set of dimensions and measures, I found that It shows me error due
to such relationship.
Does it mean that, For Global Cube, Can't we use DistinctCount/Count agreegation?
CREATE
GLOBAL CUBE [Device OLAP_Cube_1_3]
Storage
'C:\Exportcube.cub'
FROM [Device DATA CUBE]
-- Measures
-- Cube

OBIEE Conformed dimension with Bridge Table

Hi,
I have an issue and tried all the links from Mark and Gerad regarding bridge tables. But probably this is a bit different.
I have to extend the OOB data model for OBIA - where the relationship between group account and gl account dimensions are 1 to many. In my case its many to many and hence bridge table.As this is not a standard customization, so posting this thread here.
Although its out of the box, a short description of the scenario.
Account Dimension levels -
total --->Group account---->Gl account
The logical table has two LTS - GL account and Group account forming a conformed dimension using column mapping.
Earlier(OOB) there was no join the physical layer between these tables ,as I had to use the Bridge table , so I joined these two with the bridge table in physical layer.
But the problem is, if I try to use standard technique to include the bridge table into the LTS of the group account table (i.e. Group account---->bridge<-------Gl account),
there is a problem of over counting ,as the group account level is also connected to summary fact tables - the query will include the bridge table and hence over count.
So my requirement is this -
When only Group account is selected it will hit the summary fact tables (content level is already set in OOB), but it shouldn't use the bridge table - so no overcount.
If we drill from Group account level or when Both Group account and Gl account is selected, it would use the bridge table and hit the detail fact table (content level is already set in OOB).
I am using OBIA 7963 with OBIEE11g.
This is the model - Summary facts <-------Group account ------>Bridge<-------Gl account-------->Detail Facts
Please help.
Regards,
Krish
Edited by: Krish on Aug 7, 2011 9:48 AM
Edited by: Krish on Aug 7, 2011 9:50 AM

Anybody please any i/p?

Ignoring role playing relationship

As is the case in most cubes, I have a role playing Date dimension. The dimensions are [Date Created] and [Date Snapshot]. [Date Created] is snowflaked off the Ticket dimension using the DateCreatedKey. [Date Snapshot] is related to my
fact table using the DateSnapshotKey (the day the snapshot of the fact was taken).
With this schema, I can find the number of tickets that were created in January 2014.
SELECT
[Number of Tickets] ON COLUMNS,
[Date Created].[Month Year].&[201401] ON ROWS
FROM
[MyCube]
I can also find the number of tickets that were in an Open status in January 2014
SELECT
[Number of Tickets] ON COLUMNS,
[Date Snapshot].[Month Year].&[201401] ON ROWS
FROM
(SELECT [Ticket Status].[Ticket Status].&[1]
ON COLUMNS FROM [MyCube])
Now what I need to do is the get the number of open tickets in January 2014 (regardless of when they were created) and divide that by the number of new tickets in January 2014. Here's what I tried
WITH
MEMBER OpenTickets AS
([Number of Tickets]
, [Date Snapshot].[Month Year].&[201401])
SELECT
{[Number of Tickets], OpenTickets]}
ON COLUMNS,
[Date Created].[Month Year].&[201401] ON ROWS
FROM
[MyCube]
However, what I get is the number of tickets created in January 2014 and the number of open tickets that were also created in January 2014. All other open tickets are ignored. How do I break that connection between dates so that the open tickets
doesn't look at the date created?
Stephanie

In ssas, you can use the Dimension Usage tab in Cube Designer to view and edit the dimension relationships between cube dimensions and measure groups in the cube. If you break that connection between dates, you can to to the Dimension Usage
tab to set it.
http://msdn.microsoft.com/en-us/library/ms183558.aspx

Many to Many relationship - Bridge Table

This post may be more appropriate for a data modeling discussion group, but thought I would post here because it will ultimately be modeled/used in OBIEE.
Can someone help me understand what the point/use is for a Bridge table when managing a many to many relationship between a fact table and a dimension? I have read a hundred different ways to handle this situation with the brige table method being the overwhelming approved approach .. but I don't see what a bridge table specifically buys you (Im sure Im missing something though).
For example .. If I have:
EVENT_FACT
EFkey
CRDimKey
Famount
CUSTOMER_ROLE_DIM
CRDimKey
Customer Name
Role
So a customer can hold multiple roles and therefore 1 event fact record could link to multiple CUSTOMER ROLE records and 1 customer role record will most likely link to multiple EVENT_FACT records.
As I understand the bridge approach would put a bridge table CUSTOMER_ROLE_EVENT_BRIDGE in place like follows:
CUSTOMER_ROLE_EVENT_BRIDGE
EFkey
CRDimkey
WeightFactor
With this approach you now have the following setup:
EVENT_FACT one-to-many CUSTOMER_ROLE_EVENT_BRIDGE
CUSTOMER_ROLE_DIM many-to-many CUSTOMER_ROLE_EVENT_BRIDGE
Doesn't a many to many relationship still exist from the dimension to the bridge table? Since all we did was join the dimension to the fact table to create the bridge table I dont see how the many to many from dimension to bridge doesnt exist?
It seems somewhat inneficient to join the dimension to the bridge ahead of time to create this table and place the weight factor on it. Why not just compute the weight factor of the dimension and place that as a field on the dimension itself and use it when joined to the fact table?
Thanks for the help and insight!!
k
Edited by: user_K on May 19, 2010 4:34 PM

I'm developing a CS degree project with 2 professors, Matteo Golfarelli and Stefano Rizzi, who have developed the Dimensional Fact Model for data warehouses and wrote many books about it.
They followed the Kimball theory about N:N and used its bridge table concept, so when I said them that in OBIEE there is this definition they were very happy.
But they stopped this happiness when I said that bridge tables only connect fact tables to dimension tables, and to create N:N between levels at higher aggregation we should use logical joins as you said in your blog. I need to extract metadata concepts from UDML exportation language, and about N:N I can do it only with bridge table analysis, I can't extract and identify a N:N level relationship from a multiple join schema as in your blog... this is the limit of your solution for our project, only this!
PS: sorry for my english, I'm italian!
thanks for the replies!

Bridge Table between two fact tables

Hello everybody,
From what I have read on the BI Administration tool help and on this forum, bridge tables are used to define many-to-many relations between dimension sand fact tables. Is it possible to have a bridge table defining a many-to-many relation between two fact tables?
Here is my senario:
1. We have a fact table called fact_Orders describing orders for some products.
2. We have a fact table called fact_Sales describing sales og these products.
3. We have a table describing the transformation from order lines to sales lines which is a many-to-many relation, because it is possible to transform an order in more than two steps.
I was thinking of connecting the two fact tables with a bridge table.
If bridge tables are inappropriate for this case, what could be a better model for my senario?
Thanks for your time.

Hi,
Well a conformed dimension is a bridge table between two facts, so not sure why you need anything else. If there is a one to many from D1 to F1 and a one to many from D1 to F2 then effectively there is a many to many join from F1 to F2 through the D1 dimension.
Sounds to me like all you need is an order dimension table, rows in the orders fact table will join to this dimension and so will rows in the sales fact table. You can then do calculations like number of sales per order, total sales revenue per order, # of order items per order etc etc.
Regards,
Matt

Alternative of Bridge table in data Modelling.

Hello Gurus,
while doing the data modeling, we found one place where we have Many to Many joins between One Fact and 3 Dim.
where in Dim., we mostly have only one attribute/ Dim, which relates Many to Many with Fact.
so as in obiee we have to build the bridge table to take care of the issue.
is there any alternative method of data modeling that can eliminate the Bridge table itself?
I was thinking to add the dim attribute in fact itself. though it's with diff grain it should work??

If you really have a many-to-many relationship from fact to dimension, which attribute value (which of the many) would you put on the fact?
What is the issue you are having with a bridge table?

Bridge Tables

Hi,
I am having a little trouble using bridge tables. For testing I created an n-n relation. When I just make joins it shows the link table like fact table but queries work okay. When I check the bridge table check box, it identifies the correct fact and dimension tables, but I get a consistecy warning since one of the dimension tables does not join to any fact table and also querires don't work.
So how exactly should I use the bridge table, and also why do I need it?

Hi,
Find the link below which might help you.
http://www.biblogs.com/2008/08/28/the-mystery-of-obiee-bridge-tables/
Regards,
Som

Bridge table to Role Playing Dimension

Similar Messages

Maybe you are looking for