Many to Many relationship in Dimension

Hi,
Some design help needed here, I have a sales territory dimension :-
Territory -> Sales Rep -> Customer
Now my problem is that a Sales Rep can cover > 1 Customer BUT a Customer can also be covered by > 1 Sales Rep.
My fact table has the Customer ID so without this duplication in the dimension all is ok and I can link my sales fact to the territory by Customer ID BUT how do I deal with multiple rows in the dimension for the same Customer ID. I cannot create a natural key dimension and have to use surrogate keys but what effect will this have on my CUBE as my fact table will have the customer ID itself.
Any help appreciated.
Cheers,
Brandon

The solution is to seperate your customer dimension from your sales responsibility dimension.
If your fact currently is:
Customer ID
Day
Amount
You'd need it to be:
Customer ID
SalesRep
Day
Amount
Your new hierarchy for customer would be:
Total -> Customer
Your new hierarchy for sales org would be:
Total -> Territory -> Sales Rep
OR
You'd have to change your customer IDs to also include the sales rep so that your detail level is unique again. However, now if you want to see the customer total, rather than separated by sales rep, you need a second hierarchy on your existing customer dimension.
Customer hierarchy 1
Territory -> Sales Rep -> Customer w/Sales Rep
Customer hierarchy 2
Customer -> Customer w/Sales Rep
Bill

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

How to design many to many relationship in the fact and dimension

There is a problem in my project what is the subject.And i wanna know how to implement in owb.I use the warehouse builder 10. Thanks.

You may design and load whatever db model you want to.
But If you set a unique key, you may find some integrity issues. I wouldn't do a many to many relationship between facts and dimensions. This could cause you lots of headaches when users start to submit queries using this tables. You'll probably face performance issues.
Regards,
Marcos

Many to Many relationship betwee dimension and fact tanle

Hello Gurus,
I have a little question about many to many realtionship between fact and dimension table. The situation is as follows.
Consider there is a fact table F1 and two dimension tables D1 and D2. D1 is joined to F1 with 1 to many relationship. D1 is joined to D2 with again one to many relationship ( Note: D1:D2 = 1:N and D1:F1 = 1:N). I am able to model this by merging D1 and D2 into one dimension table in BMM layer by adding them as logical table sources and creating logical table source join. I have built simple reports and the data returnned is fine. However, I would just like to know what could be the drawbacks of such a model.
We have many other dimesions joined to the fact table and users have access to the answers that means they would could what ever report they feel like. Hence, would just like to know in what cases this model could break which means reports would give wrong data because of a many to many relationship between one of the fact and dimension table.
Thanks in advance.

Hello Copter,
Even I had modeled it by reading this link before. In the situation explained by me dimension D1 is doing the job of table Rules ( as explained in link). The model is fine.
However, my point is to undersatnd in which scenerios this model will break. As already explained, the fact table is joined to various other dimensions, there could be situations in which users select columns from various dimensions and facts randomly.
Hence, which are the scenerios where I might get erroneous counts of meassures. Further, if someone feels this model is correct and would not break in any scenerio then please reply.

Many to many relationships between Fact and Dimension

Hi All,
I have to solve two kind of many to many relationships between Fact and Dimension.
1. Many to Many relationship between Fact and Dimension, using a bridge table, with FKs in fact and dimension to bridge tables PK.
2. Many to Many relationship between Fact and Dimension, using a bridge table, and an intersection table, with FK in fact to bridge table, and 2 FKs in intersection table to Dimension and to bridge table.
I need help on implementing (how the mapping has to look like) them in OWB 9.2.0.2.8.
Thanks,
Aurelian Cojocaru

Aurelian,
Unfortunately, you cannot implement this in the dimensional model. You would have to use relational tables and relationships between those in order to implement your scenario.
Thanks,
Mark.

Many to Many relationship in a Dimension.

Hi all,
To improve the infocube performance , we should not keep the characteristis which is have MANY TO MANY relationship in a one dimension. My question is how to find out which characteristics is having many-many relationship.And which characteristics is having 1 to Many relationship.
Regards,
Asim

Hi Asim,
There are some very obvious ones.E.g product and product group. This is obviously 1-n relationship.But there are also the ones which you can not see easily.For those ones, you can check the data in datasource.Then you can see that these characteristics have 1-1, 1-n or n-m relationship. I don't know any easy way to do so except checking PSA manually.
In fact, if we consider that you are the BW consultant who is modelling, then you must know the meanings and relationships of characteristics.So usually you won't hesitate much while creating the dimensions as you know about the characteristics.You can also ask the users and other R3 consultants when you can not guess the result.
Here is a useful thread for the logic explained by examples:
Regards,
Güneş BÜYÜKTANIR

Modeling a many-to-many relationship in a dimension

Hi, I'm using AWM and I need to create a book dimension which aggregates books about their authors.
My table is: BRIDGE_TABLE_BOOKS(book_key, author_key)
Its data are for example:
Book - Author
1 - 1
1 - 2
2 - 1
3 - 2
4 - 1
4 - 2
5 - 1
because a book can be written by 1 or more authors.
I'd like that AWM could aggregate them through authors as follows:
1
->1
->2
->4
->5
2
->1
->3
->4
is it possibile in AWM?

many-to-many relationships are always represented as fact tables in a dimensional model (Kimball likes the idea of the "bridge" table...but in my opinion a bridge table is nothing more than a 2 dimensional fact table). Doesn't matter whether you're using relational or OLAP, works the same either way.
Simply create a cube dimensioned by book and author. Have a character or boolean measure with Y/N or true/false. Insert tuples where a given book was written by a given author. This is one area where relational is better - don't have to have a dummy measure, just make a "factless fact table" (you can do this in Oracle OLAP also...but it's gotten to the point where Oracle has tried to hide all the complexity of the OLAP language. Unfortunately, that hides a lot of power also...)
What type of reports are you trying to get out?
Thx,
Scott

Many-to-many relationship - show all values

Hi,
I'm building a cube in 2008R2 and have a many-to-many relationship through a bridging table but when displaying the results it is effectively an inner join and I would like to see a full outer join with the unknown rows set to "unknown".
I've managed to achieve this by doing a full outer join in the view that creates my bridging table and having an unknown member in my dimensions but then when I added in a dimension that wasn't directly related to the bridging table the unknown rows
were removed again. I was able to get past this by adding a row to my fact table with all the keys set to unknown and the metrics set to zero.
Whilst this works it really does not seem like an ideal solution, especially as previously empty metrics are now returning a zero.
Is there any way to achieve this in SSAS? Perhaps in the way unknown members are processed?
Thanks,

cccparkhill,
What you did is the only way to achieve what you want.
In cubes you connect Dimensions throw Facts. By definition dimensions are
“How do business people describe the data that
results from the business process?”
and facts are “What are we measuring?”, noting the underlined
we can understand that _normally and usually_ the relation between the dimensions and the facts represent incidents happened in the real world ... the way you approach, think, and deal with dimensions and facts in cubes is different than dealing with tables
in normal relational transnational database.
Personally I do what you did when I want to achieve "Left join"
Please mark this reply as the answer
or vote as helpful, as appropriate, to make it useful for other readers

Many to Many dimension displays all the members regardless of bridge data

Hi,
I have already set up couple of many to many relationships in my cubes and all ran fine.
Now I set up a new many to many relationship as follows:
Fact- sales
Dimension- customer
Dimension- conference
Bridge- (many 2 many)- ConferenceCustomers (many customer can participate in one conference and same customer can participate in couple of conferences).
(I've set the tables, keys and relations in DSV, created the dimensions, added the bridge measure group to the cube, defined new dimension in dimension usage tab using the conference dimension with bridge table to the fact table and regular relation
to the bridge measure group which relates to the customer dimension etc).
When I browse the cube by the new Conference dimension and the customer, for some reason I see all the customers which have a record in the main fact table regardless if they are related to the conference in the bridge or not.
When I add to the browser the count measure of the bridge, only then do I see only the customers which relate to the conference.
What am I missing?
(I was thinking what's the difference between all the other M2M relations I've done so far, I think here not all the customers which participted in a coneference have sales records, but I'm not sure why it should effect this.)
Namnami

Hi Namnami,
Since it working fine now, and you cannot reproduce this issue, I change this thread to discussion type. If you have any update, please feel free to post it.
Regards,
Charlie Liao
TechNet Community Support

Many to many relationships (Again)

Hello,
There was a posting on above subject.
Re: Many to many relationships between Fact and Dimension
They asked to look chapter 3 in the user's guide... <http://download.oracle.com/docs/pdf/B10996_01.pdf>. chapter 3 talks about defining Oracle Data Objects. I could find above subject in chapter 3 .
Here is our situation We are using OWB 9.2.0.2.8. We are in a situation to build ETL from denormalized (relational tables) source to normalized target (relational tables). It is not a data warehouse situation. It could be a reverse of data warehouse. As given below
Supplier >--------------------<Item
becomes Supplier ------<supp_item.>--------------Item after many to many resolution, Where supp_item is interface table.
We were able build Supplier and Item through seprate mapping. I could build supp_item through post mapping process. I look for alternate thought as well.
We are using separate sequence number for Supplier , Item and supp_item. The sequences will be surrogate keys such as Supplier ( Suppseq(PK)), Item (Itemseq (PK)) and supp_item(suppitemseq (PK)) Here is the sample
Supplier
001|S001
002|S002
003|S003
004|S004
Item
001|I001
002|I002
003|I003
Supp_item (Suppseq|ItemSeq)
001|002 --- S001 I002
001003 -----S001 I003
001|004 ----- S001 I 004
002|002 ---- S 002 I002
002|003 ---- S 002 I003
003|001 --- S 003 I 003
003|003 --- S 003 I 003
Did any body face such situation? What is the best way to create a mapping (single map or multiple map with processflow sequence) for this situation?
Let me know the steps exercised in OWB for this situation.
I appreciate your help.
Regards
Ram

Hi Ram,
The easiest way to do this, would be to:
- Load supplier in one mapping and generate the surrogate key.
- Load item another (or the same) mapping and generate the surrogate key.
- Load supplier_item in its own separate mapping, using a key lookup (or join) to (with) the supplier and item tables.
Needless to say, you should create unique keys on the natural key of the supplier and item tables, to enable quick index-based lookups and make sure you get one unique value for every value of the natural key.
Hope this helps,
Mark.

Defining Dimensions, Attribute Hierarchies for a Link Table(Many to Many)

I have 3 Tables in the Database
Table 1: Transactions (Fact Table) - PK(TransactionId)
Table 2: Relationship (Dimension1) - PK(Relationship Id), FK_TransactionId, FK_CompanyId, RelationshipType
Table 3: Companies (Dimension 2) - PK(CompanyId)
Table 2: Relationship table is a link table between Transactions & Companies to facilitate many to many relationship.
I defined Fact and Dimension tables accordingly but having issues defining Dimension & Attributes for Relationship tables
Relationship Dimension:
I have 3 hierarchy groups defined
Hierarchy 1 - Relation -Relationship Type,Relationship Id(PK)
Hierarchy 2 - Transaction - Transaction, Relationship Id(PK)
Hiearchy 3 - Company - CompanyId, Relationship Id(PK)
Defined the attribute relationship in the following way
RelationshipID(PK) ---> CompanyId , RelationshipID(PK) ---> TransactionId, RelationshipID(PK)
---> RelationshipTYpe
I am getting incorrect results when I deploy the cube. Not all the types are being displayed only 4 types are being displayed out of 27 types though there exists Transactions for all the Types.
To fix the incorrect results, I tried to break the Relationship Dimension into 2 dimensions seperating Transaction(Relationship Dim) & Company,Type (Companies Dim). I tried to configure a many
to many Relationship type between my Companies Dim & Fact Table Transaction. But I get the error that says
"Companies Dim many to many dimension in the Tansaction measure group requires that the granularity of the Relationship dimension is lower than that of the Relationship measure group "
Any help regarding how to difine Dimensions & Attribute Hierarchies on a Many to many link table is appreciated.

Hi Jaya,
According to your description, you are experiencing the issue when implement many to many relationship by using a bridge table in your SQL Server Analysis Services project, right?
Generally, a bridge table will have a surrogate key for the dimension and a surrogate key to the fact table or a degenerate dimension based on the fact table. Here are some blogs which describe how to implement many to many relationship using a bridge
table.
http://bifuture.blogspot.com/2011/06/ssaskimball-modeling-nm-relation.html
http://www.sqlchick.com/entries/2012/1/22/data-modeling-tip-when-using-many-to-many-bridge-tables-in-s.html
http://social.technet.microsoft.com/wiki/contents/articles/22202.a-practical-example-of-how-to-handle-simple-many-to-many-relationships-in-power-pivotssas-tabular-models.aspx
Regards,
Charlie Liao
TechNet Community Support

Modeling a Many to Many relationship

How can I modeling a Many to Many relationship between a fact table and a dimensión in Essbase?
For example I have a economic zone dimension and a record in the fact is just related to one country... but a country is related to many economic zone...
Is this posible?
Thanks.

Glenn kibbitzes (sp?) on my answers, so it's payback time. :)
There are a couple of ways to approach this:
1) Shared hierarchies: Create a master hierarchy that contains all of your regions/countries/states/provinces/parishes/principalities. Call this one Total. Create separate, nonconsolidating hierarchies like Atlantic, Pacific, etc., and use Essbase's shared members functionality to get those totals.
2) Put two (or more) attribute dimensions against your Geography dimension and assign the base members (Mexico, Brazil, etc.) to attribute dimensions like Atlantic or Pacific. These would be one member attribute dimensions.
3) Use a UDA to do much the same as #2, but with poorer reporting capabilities.
Regards,
Cameron Lackpour
Edited by: CL on Jul 18, 2009 6:33 PM
Owned by Glenn when he pointed out my mistake with approach #2. Oh, the humiliation. But now it's fixed. Never tangle with an Oracle Ace -- your ego will be handed to you, in a nicely wrapped box, with a pretty bow to make the pain go away.

SSAS - Many to Many Relationship Grain Filters Out Data (Many to One)

I have a simple Many to One example: One Fact Table record has many Dimensional Items. The Example I'm using is One FactEvent record can have multiple EventMembers. These members are always unique so the relationship is really many to one (vs.
many to many). The grain of the Fact is one row for every event. Not all events have members, but I have stubbed those with -1
I tried using a Referenced dimensional relationship, but it threw my total counts off. I decided to make it more complicated by using a
Many to Many relationship, but I had issues once I started slicing the data.
The following are my two very simple tables:
FactEvents:
EventMemberID MemberKey EventMemberKey MemberName MemberGender
1             1         -1             None       N
2             2         E2             Tyler      M
3             3         E2             John       M
4             4         E2             Sue        F
5             5         E5             Tim        M
6             6         E5             Jane       F
7             7         E12            Ashley     F
8             8         E12            Jessica    F
9             9         E12            Kristy     F
10            10        E17            Mike       M
11            11        E17            Josh       M
12            12        E18            Warren     M
13            13        E18            Eric       M
Here is the bridge Table:
EventID EventBK EventName         EventMemberKey EventCount
1       E1      Hockey Game       -1             1
2       E2      Soccer Game       E2             1
3       E3      Baseball Game     -1             1
4       E4      Concert           -1             1
5       E5      Food Festival     E5             1
6       E6      Movie Night       -1             1
7       E7      Data Group Event -1             1
8       E8      City Tour         -1             1
9       E9      Ski Trip          -1             1
10      E10     Camping Trip      -1             1
11      E11     Hiking Trip       -1             1
12      E12     Community Cleanup E12            1
13      E13     Block Party       -1             1
14      E14     Toastmasters      -1             1
15      E15     Train Spotting    -1             1
16      E16     Plane Spotting    -1             1
17      E17     Fishing Trip      E17            1
18      E18     Hunting Trip      E18            1
19      E19     Street Hockey     -1             1
20      E20     Bonspiel          -1             1
You can see many events have no members and some events have multiple members. There is not separate members Dim, just the bridge table. I tried to build view that would work as bridge tables, but it started to feel like overkill.
Here is the SSAS structure:
Cube:
I tried creating a bridge Dim and Measure Group that can be used to join FactEvents with DimMemberEvent:
When I query the database tables directly, I can get the structure I'm looking for:
Gender Count
F            5
M           7
N           15
This represents that although there are 20 events, there were 5 Female and 7 Male participants and 15 events with No participants. When looking at the cube in excel I get:
Gender Count
F            3
M           4
N           15
Grand Total 20
The grand total is correct, however, it looks like it is grouping the events, so if there are multiple Female members at a particular event, they get rolled up. You can see this better if I pull in member name:
It includes all the names with count 1 ie. 5 Females with count 1, but the gender subtotal is 3 (as it is grouping the gender dimension)
The detail member counts are good, but the rolled up M and F counts are stripping out duplicates. Is there a way to model this in SSAS to preserve the detail member counts when the member dimension is used? Is a many to many the best solution?
This is all using SQL Server 2012 Multi-Dimensional Model. Thanks.

Ok, for starters, if it's a one to many relationship, don't set it up as a many to many! Avoid many to many relationships and really anything other than "regular" relationships.
Second, the tables you pasted the data for aren't the tables you are describing them as, based on the dsv screenshot you included. If your post is confusing to the people who are wanting to help you, they will quickly move on.
It seems that you are not clear on how to construct a star schema. I will lay one out for you and hopefully this can help you on your journey.
fact_member_event:
event_id
member_id
member_event_count
dim_member:
member_id
member_key
member_name
member_gender
dim_event:
event_id
event_name
fact_event:
event_id
event_count
Or alternately, you could drop the fact_event fact table and have a calculated member that uses dimEvent.event.event.allmembers.count. It's a little bit of a weird situation that I would want to play with, but I would start with the above.
Also if you post back and show query results, you should make it clear what columns you are displaying. I see "count" in your query above, but nowhere in the star schema do I see "member count"
as a field.. I guess that's event count?
Hope this helps,
Ken

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!

Adding a many-to-many relationship with AMO

Does anyone have an example of adding a many-to-many relationship using AMO that is NOT the AMOAdventureWorks example?
Specifically, I'm trying to do the following:
1. Create the new measure group (cube.MeasureGroups.Add("New MeasureGroup"). This will be the factless measure group that's used to resolve the many-to-many
2. Add a measure to it (something simple, like a Count)
3. Add a regular cube dimension to the measure group linking one side of the many-to-many to a normal dimension
4. Add a regular cube dimension to the measure group linking the other side of the many-to-many to a normal dimension
(3. and 4. above are "RegularMeasureGroupDimension" type)
5. Add a ManyToManyGroupDimension to the measure group. I use the ID of (3) above for its CubeDimensionID
This is where I get stuck. I get an error "Another 'MeasureGroupDimension' object has the 'Requesting BU Lookup' key." (and this is the name of the dimension that I added in step 3).
I could've sworn this worked just the other day! I can easily create these relationships using the GUI, but I just can't seem to get the AMO right to make it happen in code. Has anyone else been successful at this? I've stared a hole into AMOAdventureWorks, and it doesn't help :-(
(BTW: Scripting to XMLA is not an option, because of the restricted environment where cube customization needs to take place)

Dear John Lynn,
Would you be willing to share the sample of your code? I'm having some troubles myself and would find another sample than the AMOAdventureWorks
very helpful.
Thanks in advance.

Many-to-many relationship performance problem

Hi:
I have model that uses a bridge table to solve a many-to-many relationship. Here it is:
dimension 1 -< fact table >-dimension 2-< bridge table >-additional data table
Now, when I drive from the additional data table with a specific value and join to the bridge table and dimension 2, the performance is fine. But, as soon as I add the fact table to the query, the query never returns. I'm in a development environment, so my fact table has 220K records, and the bridge table has 200K records. The dimension 2 and additional data tables have hundreds of records. In other words, it's not much data. I have indexes and referential constraints on all relevant columns.
Can anyone suggest what is happening to cause such a performance hit when I add the fact table to the query?
Thanks for any suggestions!

sybrand_b wrote:
The way you write it yes, but there is one minor detail.
You can have a 0,1 or many relationship: one employee has zero, one or many phone numbers
but you can not have the opposite, as it doesn't make sense.
0, 1 or many phone numbers belong to 1 employee.
It is customary to use 0,1 or m when the relationship is optional.
Sybrand Bakker
Senior Oracle DBAIs this correct now ?
one to many : one employee has 0,1 or multiple phone numbers
many to one : 1 or multiple phone numbers to one employee

Many to Many relationship in Dimension

Similar Messages

Maybe you are looking for