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

Similar Messages

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 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 - 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 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.

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 issue

Guys,
How do we deal with the situation where we have many to many relationship between 2 different characteristics?
Thanks,
RG

Hi,
I assume you are talking about data modeling.
When you are required to decide how to model two Char with many to many relations
1. If you keep them in Same Dimension table the size of the dimension table will be more.
lets say 100 Customers & 100 Materials
Now if you keep them in same dimension..
lets say C1 will have combination of M1 till M100.similarly for other customers
So Total rows in dimension table will be 100x 100 = 10000!!!
It will again be of comparable size to fact table and not recommended.
2.You always try to define them in different dimensions
Now ,You try keeping them in diffrent dimension..in this case Customer dimension will have only 100 rows & Mateial dimension will have only 100 Rows.very small when compared to fact table size.
Hope this helps
Sriman

Problem with 1-to-many relationship between entity beans

Hi All!
I have two tables TMP_GROUP and TMP_EMPLOYEE with following fields:
TMP_GROUP: ID, CAPTION, COMMENT, STATUS.
TMP_EMPLOYEE: ID, LOGIN, GROUP_ID.
For this tables i create two entity beans GROUP and EMPLOYEE respectively.
The relationship looks like this
descriptor ejb.xml:
<ejb-relation>
            <description>description</description>
            <ejb-relation-name>employeesOfGroup</ejb-relation-name>
            <ejb-relationship-role>
                <ejb-relationship-role-name>com.mypackage.GroupBean</ejb-relationship-role-name>
                <multiplicity>One</multiplicity>
                <relationship-role-source>
                    <ejb-name>GroupBean</ejb-name>
                </relationship-role-source>
                <cmr-field>
                    <cmr-field-name>employees</cmr-field-name>
                    <cmr-field-type>java.util.Collection</cmr-field-type>
                </cmr-field>
            </ejb-relationship-role>
            <ejb-relationship-role>
                <ejb-relationship-role-name>com.mypackage.EmployeeBean</ejb-relationship-role-name>
                <multiplicity>Many</multiplicity>
                <relationship-role-source>
                    <ejb-name>EmployeeBean</ejb-name>
                </relationship-role-source>
            </ejb-relationship-role>
        </ejb-relation>
descriptor persistent.xml:
<table-relation>
               <table-relationship-role
                    key-type="PrimaryKey">
                    <ejb-name>GroupBean</ejb-name>
                    <cmr-field>employees</cmr-field>
               </table-relationship-role>
               <table-relationship-role
                    key-type="NoKey">
                    <ejb-name>EmployeeBean</ejb-name>
                    <fk-column>
                         <column-name>GROUP_ID</column-name>
                         <pk-field-name>ejb_pk</pk-field-name>
                    </fk-column>
               </table-relationship-role>
          </table-relation>
Now i implement business method:
public Long addEmployee(String login, long groupId) {
          Long result;
          try {
               EmployeeLocal employee = employeeHome.create(login);
               GroupLocal group =
                    groupHome.findByPrimaryKey(new Long(groupId));
               Collection employees = group.getEmployees();
               employees.add(employee);
               result = (Long) employee.getPrimaryKey();
          } catch (CreateException ex) {
               result = new Long(0);
          } catch (FinderException ex) {
               result = new Long(0);
          return result;
When i call this method from web service, the following exception is raised:
com.sap.engine.services.ejb.exceptions.BaseTransactionRolledbackLocalException: Exception in method com.mypackage.GroupLocalHomeImpl0.findByPrimaryKey(java.lang.Object).
P.S.
1) I have transaction attribute set to "Required" for all methods of all beans
2) I have unique index for each table:
TMP_GROUP_I1: CAPTION
TMP_EMPLOYEE_I1: LOGIN (however i think GROUP_ID must be added here too)
3) I tried many:many relationship with this tables and it works fine
4) I try another implementation of addEmployee method with
EmployeeLocal employee = employeeHome.create(login, groupId);
without using GroupLocal cmr-field and GroupLocalHome findByPrimaryKey method, the result is same error.
Can somebody help me with this problem?
Thanks in advance.
Best regards, Abramov Andrey.

gimbal2 wrote:
1: The @JoinColumn on the listOfDepartments collection in Company is wrong. It should be something like this for a bidirectional relationship:
@OneToMany(mappedBy="company") // company is the matching property name in Department
private List <Department> listOfDepartment = new ArrayList<Department>();Note that I removed the fetch configuration; onetomany is fetched lazy by design. Saves some clutter eh.
2: use a Set in stead of a List (hibernate doesn't like lists much in entities and will break when you create slightly more complex entity relations)
3: don't just slap cascades on collections, especially of type ALL. Do it with care. In the many years I've been using JPA I've only had to cascade deletes in very specific situations, maybe once or twice. I never needed any of the other cascade types, they just invite sloppy code if you ask me. When working with persistence you should apply a little precision.I made all changes as you mentioned but still compID in department table shows null value...

Many to Many relationship in a Dimension.

Similar Messages

Maybe you are looking for