Connection between 2 fact tables

Hello guys!
Suppose the following situation (it's a simplified one, of course):
1) I have a dimension table d_contract with a list of contracts (and some attributes of a contract like its term and type). The primary key is ID_CONTRACT
2) I have a fact table f_payments which contains payments for all contracts. It contains fields: ID_CONTRACT, AMOUNT_PAYMENT, DATE_OF_PAYMENT, ID_SALESROOM (so a measure is AMOUNT_PAYMENT: its default aggregation rule is set to SUM). Each contract can have many payments in different salesrooms.
3) I have a dimension table d_salesroom with a list of all salesrooms (and some attributes of a salesroom like its address) where payments can be installed. The primary key is ID_SALESROOM
4) I have a fact table f_calls which contains all phone calls (in tech support) regarding contracts. It contains fields: ID_CONTRACT, DATE_OF_CALL, DURATION_OF_CALL (so a measure is DURATION_OF_CALL: its default aggregation rule is set to SUM). Many calls for each contract can be done.
Those were physical tables, and logical tables are the same. Connections between tables (physical and logical) are quite obvious: f_payments is connected with d_salesroom and d_contract, f_calls is connected with d_contract only.
Then I want to run the following request (in Answers):
ID_SALESROOM | ID_CONTRACT | SUM(AMOUNT_PAYMENT) | SUM(DURATION_OF_CALL)
That is: for all salesroom I want to see all contracts (which were paid in the salesroom) and for each contract I want to see sum of payments (in the salesroom) and duration of all calls for that contract (not regarding the salesroom). If a contract was paid in more than one salesroom then the duration of calls should be the same for all salesrooms - duration is connected only to a contract, not to a salesroom.
If I write this request in answres, I get zero call duration for all contracts. And in request log I see an expression CAST(NULL as INTEGER) instead of SUM(DURATION_OF_CALL). I suspect this is because d_salesroom isn't in any way connected with f_calls (neither physically nor logically). But what to do if I want a query like the above one to run correctly?
What can I do with the repository to perform queries like that?

Hi AFSK,
d_contract is common dimension b/w two facts so in f_cells LTS add d_contract and f_payments into single source
then your query will generated in the following way
select a.Id_salesroom,b.Id_contract,c.Sum(Amount_payment) ,d.Sum(Duration_of_call) from
d_salesroom a,d_contract b,f_cells c,f_payments d
where a.Id_SalesRoom=d.Id_SalesRoom and a. Id_Contract=d.Id_Contract and a.Id_Contract=c.Id_Contract
group by a.Id_salesroom,b.Id_contract
hope it helps you

Similar Messages

Best way to connect two fact tables when no conformed dimension exists

Can anyone please elaborate how would I connect two fact table without any conformed dimension. Let say FACTA, FACTB. FACTB is related to a dimension "StatusDim". I want to select the count of all FACTA item which are related to FACTB items with
a particular status. I have found the following article but just wondering whether it is the best practise to connect two fact tables directly.
http://bifuture.blogspot.com/2011/11/ssas-selecting-facts-with-reference.html
Thank you

Hi Ahsan,
After read the blog you posted, I think it's a pretty good solution to create a view in the relational database or a named query in the Data Source View containing as the the columns in FACTA and FACTB. Then build a dimension from it, setting the "Null processing"
property (you have to click the "plus" two times for the "Key Columns" property of the attribute in BIDS to access this property) to "UnknownMember". And then use this dimension for the many-to-many relationship. Dimensions from FactA can benefit of the reference
relationship between FactA and FactB and therefore a powerful solution it is.
Regards,
Charlie Liao
If you have any feedback on our support, please click
here.
Charlie Liao
TechNet Community Support

Ratio between Fact table and Dimention table for a Infocube

Hi All,
How can we reduce the Ratio between Fact table and Dimention table for a Infocube below 20%.??
please give suggestions

Hi
Reduce Ratio??
The Ratios are dependent on the Fact Table, and the Dimension table that is modeled for your Cube.
You cannot change ratio individually, but can set the Line Item Dimension , provided you have only one char object is taking much space and bulky with much percentage, based on your requirement. You can always use fine tuning objects.
Please be more specific while posting, to get right help from sdn.
Hope it helps

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

Join between fact table and master data table

Is it posible to join a Cube with a Characteristic? This is exactly what i need:
- In my cube i have date (0CALDAY) and (among others) a characteristic (ZCHAR) and a key figure (ZKEYF).
- I added a key figure (ZKFAT) as an attribute to ZCHAR. So the tables look something like this:
Fact table:
0CALDAY | ZCHAR | ZKEYF
12.10.2006 | CHAR1 | 10
12.10.2006 | CHAR2 | 20
12.10.2006 | CHAR3 | 30
Master data table for ZCHAR:
ZCHAR | ZKFAT
CHAR1 | 1000
CHAR2 | 2000
CHAR3 | 1500
I need to make a query with a table that looks like this:
0CALDAY | ZCHAR | ZKEYF | ZKFAT
12.10.2006 | CHAR1 | 10 | 1000
12.10.2006 | CHAR2 | 20 | 2000
12.10.2006 | CHAR3 | 30 | 1500
Finally, the query should result in something like this:
0CALDAY | ZKEYF | ZKFAT
12.10.2006 | 10 | 1000
12.10.2006 | 20 | 2000
12.10.2006 | 30 | 1500
Adding KFAT to the fact table is not an option, i need to read this information directly from ZCHAR.
I've tried using MultiProviders but didn't get the result i need.
Is there any way to achieve this? Please advice.
Thank you,

Thank you Ram C. i've tried your solution and it may be it, but i'm having one problem:
Since i'm reporting in web, i used the second solution you offered and almost got the desiered result. The problem is that some entries are correct but others ar duplicated! Using same example, my result table looks something like this:
0CALDAY | ZKEYF | Calculated KF (from ZKFAT)
12.10.2006 | 10 | 1000
12.10.2006 | 20 | 4000
12.10.2006 | 30 | 1500
Second row should be 2000, but instead it shows 4000. I added ZCHAR's attribute ZKFAT as a display attribute in order to compare the results. I found that the display attribute is correct (2000) but the Calculated KF still showed duplicated data (4000).
By the way, when i execute the query, i get this warning message:
"Calculated key figure ZRT_C02_2_CKF004 is not defined correctly"
Any ideas why this could be happening?
Thank you for your help.
Message was edited by: Gerardo Gaona

Logical level in Fact tables - best practice

Hi all,
I am currently working on a complex OBIEE project/solution where I am going straight to the production tables, so the fact (and dimension) tables are pretty complex since I am using more sources in the logical tables to increase performance. Anyway, what I am many times struggling with is the Logical Levels (in Content tab) where the level of each dimension is to be set. In a star schema (one-to-many) this is pretty straight forward and easy to set up, but when the Business Model (and physical model) gets more complex I sometimes struggle with the aggregates - to get them work/appear with different dimensions. (Using the menu "More" - "Get levels" does not allways give the best solution......far from). I have some combinations of left- and right outer join as well, making it even more complicated for the BI server.
For instance - I have about 10-12 different dimensions - should all of them allways be connected to each fact table? Either on Detail or Total level. I can see the use of the logical levels when using aggregate fact tables (on quarter, month etc.), but is it better just to skip the logical level setup when no aggregate tables are used? Sometimes it seems like that is the easiest approach...
Does anyone have a best practice concerning this issue? I have googled for this but I haven't found anything good yet. Any ideas/articles are highly appreciated.

Hi User,
For instance - I have about 10-12 different dimensions - should all of them always be connected to each fact table? Either on Detail or Total level.It not necessary to connect to all dimensions completely based on the report that you are creating ,but as a best practice we should maintain all at Detail level only,when you are mentioning any join conditions in physical layer
for example for the sales table if u want to report at ProductDimension.ProductnameLevel then u should use detail level else total level(at Product,employee level)
Get Levels. (Available only for fact tables) Changes aggregation content. If joins do not exist between fact table sources and dimension table sources (for example, if the same physical table is in both sources), the aggregation content determined by the administration tool will not include the aggregation content of this dimension.
Source admin guide(get level definition)
thanks,
Saichand.v

Mapping dimension table to fact table in admin tool 10g

Hi
I have a criteria when it is run uses fact 1 as fact table and gives result, and when I add new column to this criteria an extra dimension(dim1) gets added to query backend and fact 1 changes to fact2.
The problem I am facing over here is both should result same amount for records. but due to new column from dim1 and new fact table fact2the amount varies and inaccruate results have come.
When I have checked the sources for Fact in logical layer i can find these facts(fact1,fact2) where fact 1 is not mapped with dim 1 and fact 2 is mapped with dim1.
Will mapping dim1 to fact1 will solve my problem.. And what would be the steps to add/map dim1 to fact1.
Please suggest.

I just checked back the setting and here are the changed details again.
I have a criteria where when it is run, the backend query is formed with f1 fact table.
And for the same criteria when I add a column c1, the backedn query is formed with f2 fact table and f1 is no more here and one new dimension d1 consisting c1 is getting added.
In both the cases results are different..the expected thing is same results.
Note:
d1 is connected to f2 checked in physical diagram
d1 is not connected to f1 checked in physical diagram.
when I checked the connection between three table in physical diagram. Only d1 and f2 are connected and f1 is not connected to either of table. How to go about this issue.
Please suggest.

F and E Fact Tables

Hi,
What is the difference between F fact table and E fact table?
When we create an Infocube which fact table is generated?
Thanks,
Soujanya

Hi ,
Difference between 'F' fact table & an 'E' Fact table
A cube has 2 fact tables - E and F. When the requests in the cube are not compressed the data exists in the F fact table and when the requests are compressed the data lies in the E fact table.
When the requests are compressed all the request ids are lost (set to NULL) and you would not be able to select/delete the data by request id. The data in the E fact table is compressed and occupies lesser space than F fact table.
When you load a data target, say a cube, the data is stored in the F fact table. If the cube is compressed, the data in the F fact table is transferred to the E fact table.
The F-table uses b-tree indexes the E-Table uses bitmap indexes. Index, Primary Index (The primary index is created automatically when the table is created in the database.). Secondary Index (usually abap tables), Bitmap Index(Bitmap indexes are created by default on each dimension column of a fact table), and B-Tree Index
Bex access the records from F-table or E- Table of InfoCube
Bex access both F and E fact tables. If data exists in both tables, it picks from both.
If the cube is not compressed it takes from F table, if fully compressed it takes from E table, partial compression - both F and E.
Roll-up adds the copy of records from F or E table to the aggregate tables. The records are not moved from F or E.
Also check the below SDN thread.
What is the difference between Fact tables F & E?
Hope the above info is helpful.
Cheers
VA
Edited by: Vishwa Anand on Aug 31, 2010 12:58 PM

Multiple fact tables in Essbase studio schema

Hi all,
Can we pull data from multiple fact tables in the single schema using essbase studio ? Also is it advisable ?
Please advice.
Thanks
Andy

Hi Glenn,
Thanks for the prompt reply.
Do you mean direct joins between fact tables ? or we can have indirect joins through Dimension tables ?
Thanks,
Andy

Reporting that traverses two fact tables

I have searched and am stumped on how to make the work in OBIEE. I can do it with straight SQL on the physical layer, but can't get OBIEE to accept it. I have a customer history fact table that contains several measures and connects to several dimensions. This creates one star. I have a campaign (ad campaign) dim that connects to an Account_Campaign Fact, as one Account may have many campaigns. The Account Dim connects also to the CustHistory fact. When I try and use information from the CustHistoryFact against information in the either the Campaign Dim, or the AccountCampaign fact, I get the following error:"{color:#800000}[nQSError: 14026] Unable to navigate requested expression . . . Please fix the metadata consistency warnings. (HY000){color}"
In the administration tool, everything checks out as consistent, and I have verified that I can get the correct result using SQL on the physical side.
My diagram is roughly
Customer(and other)Dim -< CustHistoryFact >-AcctNbrDim -< AccountCampaignFact >- CampaignDim
Any ideas?

Hi...
From your scenario, there are 2 facts seems CustHistoryFact, AccountCampaignFact.
And dimensions are: Customer(and other)Dim, AcctNbrDim, and CampaignDim
Do one thing, one of good technique to avoid this error is : mention the levels (Hierarchies) in administration tool. i.e. rpd.
For the 2 fact tables, whatever the tables directly connecting to fact tables (or which are having direct joins) need to mention levels in detail level, and for the the dimensions which are not related directly, (or which are not having direct joins to facts) need to mention levels in total level.
I think you might have known about the level mentioning in rpd, go to the particular fact table source in BMP layer, double-click > Content tab, here you find the hierarchies you created, there you need to mention your levels.
For your scenario, For fact CustHistoryFact table source, mention detail level for Customer(and other)Dim and AcctNbrDim
............................................................................, mention total level for CampaignDim
In the same way, for fact AccountCampaignFact table source, mention detail level for CampaignDim and AcctNbrDim
...................................................................................., mention total level for Customer(and other)Dim

Measures values are twice as big compare to corresponding fact table

The version used is SQL Server 2012
We have a CustomerAddressKey in fact tables with many partitions and Regular Dimension Usage between fact table and CustomerAddress dimension. As we do not process all partitions every day sometimes we encounter the issue when users see the old address for
a particular player.
We have played with 2 approaches: Referenced Dimension Usage and modification of CustomerAddress view when only current (latest) address is available.
After we build and process Referenced Dimension Usage version using CustomerAddress as Reference Dimension and Customer as Intermediate dimension and CustomerAddressKey and CurrentCustomerAddressKey.
Everything is OK besides that the measures value for any slice is twice as big as corresponding fact table value.
What did we do wrong?
serguei russky

There are a couple of ways that data can get duplicated in SSAS
One is incorrectly running multiple ProcessAdd operations. ProcessAdd always appends data. So if you run it twice with the same set of rows you end up with duplicate fact rows in your cube. The way to fix this is to run a ProcessFull on the affected partition/s.
The other common thing that can duplicate data is issues with your data and / or schema. The following is just psuedo code, the join conditions should be the same as you've specified in your DSV. If you run these two styles of SQL queries over your raw data
and they return different amounts then you probably have a problem with the way you have populated the data in your reference dimension table.
SELECT SUM( <measure column> )
FROM <fact table>
SELECT SUM( <measure column> )
FROM <fact table>
INNER JOIN <reference dim>
ON ...
INNER JOIN <CustomerAddress dimesion>
ON ...
http://darren.gosbell.com - please mark correct answers

Fact table is GT Dimension table

Hi All
Where can i find the relation between Fact table and dimension table sizes. If i want to check whether my dimension table is greater than fact table then how?
If i can use program " sap_infocube_designs" then when i am trying to execute it it is not working.
regards
Naga

I dont think SAP_INFOCUBE_DESIGNS doesnt give u the size of the fact table rather the density and the row count in the cube.
"density" in SAP_INFOCUBE_DESIGNS
check the answer by pizzaman in this thread detailing the size of the fact tabe
Fact table size of the cube

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.

Concept of FACT Tables

Hello Experts
Can anybody tell me the concept of Fact tables with F fact table & E Fact table.
I searched for this but not cleared for some point.
Thanks in advance
'Neha

Hi,
A cube has 2 fact tables - E and F. When the requests in the cube are not compressed the data exists in the F fact table and
when the requests are compressed the data lies in the E fact table.
Please refer the below thread.
[What is the difference between Fact tables F & E?]
[Re: Regarding E and F fact tale;
Regards
Prasad

Connection between two fact tables.

I have a problem in OBIEE 10.1.3.2:
I have two fact tables A and B. Both tables have three columns - time_id, position_id and valuea (table A), time_id, position_id and valueb (table B). I have dimensions TIME (id, time) and POSITION (id, post). Facts A and B are connected to dimensions and
both queries
select TIME.time, POSITION.post, A.valuea,
select TIME.time, POSITION.post, B.valueb
work properly.
But it is definitely impossible to execute query
select TIME.time, POSITION.post, A.valueA, B.valueB.
[NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table A) does not contain mapping for [B.VALUEB]. (HY000)
Another two fact tables in the same application I can join in any query wihout any problem.
How is it possible?
Thanks for your help
Jiri

How did you joined two Fact tables. Did you use Dimension table between?

Connection between 2 fact tables

Similar Messages

Maybe you are looking for