Bridge table or factless fact table?

Hello,
I have a model a bit different that I've worked with in OBIEE (10), and I can't make it work. I have 1 fact table and two dimensions, joined this way in the physical layer:
Fact Table >- Dim Person -< Dim Address
The join between Fact Table and Dim Person is 1:N and the join between Person and Address is also 1:N, for example one person can have many addresses.
I have searched in forum, internet, etc. how to model this in the BMM, but I can't find the same model as an example. I have found similar models solved with a bridge table, but the model is a bit different (Fact Table -< Dim Person >- Dim Address), so it won't help.
I have tried many things, but the option that I thought it's more logic, is treating Dim Address as a factless fact table. However, when I choose in a report a fact from the real Fact Table, the person ID and the address, the fact was treated as null. What I expect is that the fact table should be repeated for every address that the person has. So, if the fact is 3 for one person, and the person has 4 addresses, the result should be 4 lines with the value 3 in each of them.
Can I make Dim Address be a factless fact table in the BMM? Should I include the Dim Address in the LTS of a single logical table? Is Dim Person a bridge table??
I hope you can help me with this one, thanks!

I'm not sure how much info you need to show on the reports, but you can try creating 2 separate logic schemas with alias tables.
1) Create alias table for fact and Dim Person and join them
2) Create another alias for fact (Fact1) and Address (always thinking that the perdon ID is also in the Address table) and join them.
Try to make your report between fact1 and address (in this case you can't put detail of the person,but you can make another report showing the persona information using the first schema.
J.

Similar Messages

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

Deploying Factless Fact Tables in 10G

Hello - We are trying to deploy the same factless fact tables we used for OWB 9i to 10G and we are receiving validation errors saying that every cube must have a measure. We do not want to create a null column just to get around something that worked fine in a previous version of the tool, and we have quite a few factless fact tables in our model.
Are there any thoughts on this?
Thanks,
Kristi

Hi,
I already face that kind of fact table, but in the same time, i needed to count the number of intersection between dimensions or sum, so i used a one measure, that always takes 1 as value, that did the trick.
Regards

Calc problem with fact table measure used as part of bridge table model

Hi all,
I'm experiencing problems with the calculation of a fact table measure ever since I've used it as part of a calculation in a bridge table relationship.
In a fact table, PROJECT_FACT, I had a column (PROJECT_COST) whose default aggregate was SUM. Whenever PROJECT_COST was used with any dimension, the proper aggregation was done at the proper levels. But, not any longer. One of the relationships PROJECT_FACT has is with a dimension, called PROJECT.
PROJECT_FACT contains details of employees and each day they worked on a PROJECT_ID. So for a particular day, employee, Joe, might have a PROJECT_COST of $80 for PROJECT_ID 123, on the next day, Joe might have $40 in PROJECT_COST for the same project.
Dimension table, PROJECT, contains details of the project.
A new feature was added to the software - multiple customers can now be charged for a PROJECT, where as before, only one customer was charged.
This percentage charge break-down is in a new table - PROJECT_BRIDGE. PROJECT_BRIDGE has the PROJECT_ID, CUSTOMER_ID, BILL_PCT. BILL_PCT will always add up to 1.
So, the bridge table might look like...
PROJECT_ID CUSTOMER_ID BILL_PCT
123          100     .20
123          200     .30
123          300     .50
456 400 1.00
678 400 1.00
Where for project 123, is a breakdown for multiple customers (.20, .30. .50).
Let's say in PROJECT_FACT, if you were to sum up all PROJECT_COST for PROJECT_ID = 123, you get $1000.
Here are the steps I followed:
- In the Physical layer, PROJECT_FACT has a 1:M with PROJECT_BRIDGE as does PROJECT to PROJECT_BRIDGE (a 1:M).
PROJECT_FACT ===> PROJECT_BRIDGE <=== PROJECT
- In the Logical layer, PROJECT has a 1:M with PROJECT_FACT.
PROJECT ===> PROJECT_FACT
- The fact logical table source is mapped to the bridge table, PROJECT_BRIDGE, so now it has multiple tables it maps to (PROJECT_FACT & PROJECT_BRIDGE). They are set for an INNER join.
- I created a calculation measure, MULT_CUST_COST, using physical columns, that calculates the sum of the PROJECT_COST X the percentage amount in the bridge table. It looks like: SUM(PROJECT_FACT.PROJECT_COST * PROJECT_BRIDGE.BILL_PCT)
- I brought MULT_CUST_COST into the Presentation layer.
We still want the old PROJECT_COST around until it get's phased out, so it's in the Presentation layer as well.
Let's say I had a request with only PROJECT_ID, MULT_CUST_COST (the new calculation), and PROJECT_COST (the original). I'd expect:
PROJECT_ID MULT_CUST_COST PROJECT_COST
123          $1000     $1000
I am getting this for MULT_CUST_COST, however, for PROJECT_COST, it's tripling the value (possibly because there are 3 percent amounts?)...
PROJECT_ID MULT_CUST_COST PROJECT_COST
123          $1000 (correct)      $3000 (incorrect, it's been tripled)
If I were to look at the SQL, it would have:
          SELECT SUM(PROJECT_COST),
SUM(PROJECT_FACT.PROJECT_COST * PROJECT_BRIDGE.BILL_PCT),
               PROJECT_ID
          FROM ...
          GROUP BY PROJECT_ID
PROJECT_COST used to work correctly before modeling a bridge table.
Any ideas on what I did wrong?
Thanks!

Hi
Phew, what a long question!
If I understand correctly I think the problem lies with your old cost measure, or rather combining that with you new one in the same request. If you think about it, your query as explained above will bring back 3 rows from the database which is why your old cost measure is being multiplied. I suspect that if you took it out of the query, your bridge table would be working properly for the new measure alone?
I would consider migrating your historic data into the bridge table model so that you have a single type of query. For the historic data each would have a single row in the bridge with a 1.0 BILL_PCT.
Best of luck,
Paul
http://total-bi.com

"Factless" fact table join warning

We have a physical fact table that only contains keys for a given day in order to track changes to Employment history over time. The compensation "facts" are contained in a dimension that is joined to the factless physical table in the logical layer. I use the factless fact as the table source and inner join it to the dimension to create the logical fact source. This seems to be working fine, but is creating a warning when I check consistency: "There are physical table sources mapped in Logical Table Source [...] that are not used in any column mappings or expressions." Is there a better way to model this in the logical layer that this warning is trying to alert me to?
Thanks!

Thank you,
The error does go away when I insert into the logical fact table the key from the factless physical table. The error is gone whether or not I define the physical column as the Logical fact table key. Will defining it as a logical key change anything?
I am curious as to why it would want me to include a field in the fact table that will never be used in the presentation layer. Is the warning mainly for accidental inclusion of physical tables that aren't used?
Thank you for the response. Nice blog by the way.

Bridge tables only direct connected to fact table?

I have a dimension BOOKS, and I have to model N:N between BOOKS and their authors. I used a bridge table (checked as it in BI Admin) so my join schema is:
FACT TABLE - BOOKS - BRIDGE_BOOK_AUTHOR - AUTHORS
I created a BOOK dimension with 2 levels, author and book, but when I go to Answers and try the query:
SQL Issued: SELECT AUTHORS.AUTHOR saw_0, FACT_TABLE.MEASURE saw_1 FROM SubjectAREA ORDER BY saw_0
I get the error:
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: ARCMUL_AUTORE.AUTORE. Please fix the metadata consistency warnings. (HY000)
In his blog: http://gerardnico.com/wiki/dat/obiee/obiee_bridge_table gerardnico says "I was obligated to made only one logical table of the tables Dimension table 1 and Bridge table by using eht join property of the Logical Table Source because a bridge table in OBIEE must be directly connected to the fact table."
Is it right?
I also tried his trick but it doesn't work...

For me, it's true ;-)
An easiest other way to model a many-to-many is to use the join property of the logical table :
http://gerardnico.com/wiki/dat/obiee/bi_server/obiee_join_in_lts
Cheers
Nico

Partitioning for Fact and Bridge tables

In our data warehouse we have a fact table having 35 million records which keeps monthly snapshot of data. This has been range partitioned on date key for each month end. We have another bridge table having around 50 million records, which is also partitioned the same way. These two tables can be joined on some fields, one of which is date key. When I run a query which uses both of these tables to display data for a month, it uses partitions in fact but does a full scan on bridge table. Partitions of bridge table are not being used at all. This results in very long response time.
Can you suggest me some way to make it work?
Thanks

That's a matter of policy.Does your organisation execute a strict differentiation between ETL developers and DBAs? Then it's probably up to the DBAs to set up the tables, but of course you have to tell them the structures of the tables that they shall create for you.Other organisations allow their ETL developers to create tables "on the fly" in development environments. If this the case for you, then it's up to you. If this is not what you wanted to know, could you please post your question differently so that we can clearly understand what you mean? Regards,Nico

Bridge table between fact/dim table

My requirement is to create a relationship between fact (service request) and dim (timesheet) table.
Many rows of dim table is related to a record in Service request. Hence i created a bridge table to join them.
I imported the bridge table into physical layer. Then created two foreign key between the bridge table, dim/fact tables.
Then pulled the bridge table into the dimension logical table source. Then created a new logical join between the fact and dimension table.
When i want to count the nbr of service request, my query is not hitting the service request fact.
Is there any step missed to create the relationship between the fact and dimension for introduction bridge table.
Pls any one provide the step by step for this process. This is little urgent.
Thanks

Just continue on Marks blog...he put it all together nicely:
http://www.rittmanmead.com/2007/06/19/obiee-data-modeling-tips-1-integrating-1-1-and-1-many-source-tables/
and
http://www.rittmanmead.com/2007/09/16/obiee-dimension-data-modeling-redux/
Cheers,
C.

Factless fact tables????

Hi gurus,
Anybody please tell me about factless fact tables? in what are all the scenarios we can use it? Can we create Infocube without key figures?
Thanks,
Karthik T

Hi Karthik,
Please go through this....
A "factless" fact table is generally one which records instances of
time-bound relationships, rather than capturing transaction amounts. The
example usually given by Kimball is a fact table which records the
instances of students, professors, and classrooms reserved for specific
classes at a college. In this case, the "key figure" is simply a binary
switch indicating the truth of a relationship expressed by the
characteristics in the dimension tables (the "zero", or false, instances
are not stored.)
Look at the delivered BW Headcount / Employee Action cube, 0PA_C01, for a
rough facsimile of the "factless fact table." To implement such a thing in
BW, you still need a key figure -- usually an integer (quantity) holding
the value 1 (at the most granular level of detail,) indicating that a
relationship expressed in the dimension characteristics is true. You can
populate a cube like this by reading information from master data tables in
your update rules, with your datasource driving off your most granular
master data table. Again, see the delivered datasources and update rules
for the 0PA_C01 cube to see how SAP does it.
Assign pts if helpfull
Thanks,
Sujeet

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?

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?

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.

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

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?

Bridge Table check box in OBIEE 10G

Hi,
In BMM layer of OBIEE 10G, we see a Bridge Table check box when we double click on each table.
What is the difference it makes if we check that VS don't check that. Is it mandatory to check it?
There are 2 ways to model many-to-many relationships.
1. Perform Fact-->Bridge and Bridge-->Dimension join in physical layer. In BMM layer, bring Fact and Dimension tables. Do an inner join between Bridge-->Dimension and join the Dimension to the Fact.
Question:- In this case do we need to check the Bridge Table check box on the Dimension table?
2. Perform Fact-->Bridge and Bridge-->Dimension join in physical layer. In BMM layer, bring Fact, Bridge and Dimension tables. Fact-->Bridge and Bridge-->Dimension.
Question:- In this case do we need to check the Bridge Table check box on the Bridge table?
Thanks,
Anilesh

Hi,
My question is -->What is the difference it makes if we check that VS don't check that. Is it mandatory to check it?
And we are following the first approach out of the 2 approaches listed below.
There are 2 ways to model many-to-many relationships.
1. Perform Fact-->Bridge and Bridge-->Dimension join in physical layer. In BMM layer, bring Fact and Dimension tables. Do an inner join between Bridge-->Dimension and join the Dimension to the Fact.
Question:- In this case do we need to check the Bridge Table check box on the Dimension table?
2. Perform Fact-->Bridge and Bridge-->Dimension join in physical layer. In BMM layer, bring Fact, Bridge and Dimension tables. Fact-->Bridge and Bridge-->Dimension.
Question:- In this case do we need to check the Bridge Table check box on the Bridge table?
Thanks,
Anilesh

Bridge table or factless fact table?

Similar Messages

Maybe you are looking for