Best Practice - Outer Join between Fact and Dim table

Hi Gurus,
Need some advice on the below scenario
I have an OOTB subject area and we have around 50-60 reports based on it. The related subject area Fact and Dim1 table are having inner join.
Now I have a scenario for one report where outer join has to be implemented between Fact and Dim1. Here I am against changing the OOTB subject area join as the outer join will impact the performance of other 50-60 reports.
Can anyone provide any inputs on what is the best way to handle this scenario?
Thanks

Ok. I tried this:
Driving table : Fact, Left outer join -- didnt work.
Driving table: Dimension D left outer join -- didnt work either
In either the case, I see physical query as D left outer Join on Fact F. and omitting the rows.
And then I tried this -
Driving table: Fact, RIght outer join.
Now, this is giving me error:
Sybase][ODBC Driver]Internal Error. [nQSError: 16001] ODBC error state: 00000 code: 30128 message: [Sybase][ODBC Driver]Data overflow. Increase specified column size or buffer size. [nQSError: 16011] ODBC error occurred while executing SQLExtendedFetch to retrieve the results of a SQL statement. (HY000)
I checked all columns, everything matched with database table type and size.
I am pulling Fact.account number, Dimension.account name, Fact.Measures. I am seeing this error each time I pull Fact.Account number.

Similar Messages

Left outer join on Fact and dimension table.

Hi all, I have a fact F with account number and few measures as columns.
I also have a dimension D with account number, account name columns.
Few account numbers from Fact doesnt exist in Dimension D , but they need to show up in the report though.
How do I left join Fact and Dimension D in RPD?
I have this report where I need to show Account Number, Account name, measures.
If D doesnt have certain account numbers, I need to convert that account number from F as string and show it in the report in account name column.
Can you pls help.

Ok. I tried this:
Driving table : Fact, Left outer join -- didnt work.
Driving table: Dimension D left outer join -- didnt work either
In either the case, I see physical query as D left outer Join on Fact F. and omitting the rows.
And then I tried this -
Driving table: Fact, RIght outer join.
Now, this is giving me error:
Sybase][ODBC Driver]Internal Error. [nQSError: 16001] ODBC error state: 00000 code: 30128 message: [Sybase][ODBC Driver]Data overflow. Increase specified column size or buffer size. [nQSError: 16011] ODBC error occurred while executing SQLExtendedFetch to retrieve the results of a SQL statement. (HY000)
I checked all columns, everything matched with database table type and size.
I am pulling Fact.account number, Dimension.account name, Fact.Measures. I am seeing this error each time I pull Fact.Account number.

To check fact and dim table sizes in RSRV

Hi guys,
i hve access to only RSRV on prod so how do i check the fact and dim table ratios what is the test that i have to use to find....
Thanks,
Your help will be greatly appreciated

Hi,
I guess you can try the following options available in RSRV ->All Elementary texts -> Database ->
Database Statistics for an InfoCube and Its Aggregates
Database Information about InfoProvider Tables
Databank Parameters of *-Schema Tables for InfoCube
Check this help link:
[http://help.sap.com/saphelp_nw04/helpdata/en/92/1d733b73a8f706e10000000a11402f/frameset.htm]
hope this helps U...
Regards,
NR

Join between hz_cust_site_uses_all and pa_agreements_all table

What is the joining condition between hz_cust_site_uses_all and pa_agreements_all table? How hz_cust_site_uses_all and pa_agreements_all table can be joined?

Hi,
What happens if you simply use a DISTINCT clause, something like:
SELECT DISTINCT pa.customer_id ,hcs.cust_acct_site_id
           FROM hz_cust_acct_sites_all hca,
          hz_cust_site_uses_all hcs,pa_agreements_all pa
          WHERE hcs.cust_acct_site_id = hca.cust_acct_site_id
        AND hca.cust_account_id       = pa.customer_id
Thanks &
Best Regards,

Pros and cons of writing quries on fact and dim tables?

Hi,
because of some performance issues i want to write my queries directly on fact and dimension tables instead of InfoProviders. what are pros and cons of doing it so??

I am creating some BeX queries on some cubes and dsos. I am facing some performance issues in these queries while executing. Some one suggested me to write queries directly on data tables ( for example /BIC/abc ) of those cubes and ods. I wanted to know pros and cons of doing it so.

Best practice for migrating between environments and versions?

Hi to all,
we've got a full suite of solutions custom developed in SAP BPC 7.0, SP 7. We'd like to understand if
- there are best practice in order to copy this applications from an environment to another environment (another client)
- there are best practice in case the client has got a newer version of SAP BPC (they should install the 7.5, while we're still stucked with the 7.0).
Thank you very much
Daniele

Hi Daniele
I am not entirely sure, what you are asking, Please could you provide additional information.
Are you looking for best practice recommendations for Governance, for example: Change transports between DEV, QA and PRD in BPC 7.0?
What is the best method? Server Manager backup and restore, etc ?
And
Best Practice recommendations on how to upgrade to a different version of BPC, for example: Upgrading from BPC 7.0 to 7.5 or 10.0 ?
Kind Regards
Daniel

Best Practices for SSO between NWBC and BOBJ CMC

What are the best practices in this scenario:
- NWBC client (using SAP ECC logon credentials)
- BOBJ client (configured using Windows AD credentials)
I would like my users to log into NWBC - but be automatically logged into CMC for running crystal reports inside the NWBC gui.
Thanks
Shane Kelly

yes. we're not using portal. only SAPGUI up till now.
but we've recently configured our DEV server to run NWBC.
Normally my users log into CMC Infoview in a browser - but with NWBC i can bring infoview directly into the UI.
but it asks for a sign=on every time.
i'd like to configure SSO for NWBC to BOBJ infoview somewhow.

Join between SO and AR tables in Oracle Apps 11.0.3

Hello,
I am new to Order Management. Can anyone please suggest join between SO Tables and Receivables tables in Oracle Apps version 11.0.3.
I am working on an Invoicing error during Autoinvoice Import Program and I am doing workaround on this issue. This error comes for specific SO only. The error causes all invoices for a org not be imported into AR. To find out a solution for the same we run Autoinvoice into batches by Sales Order using a process of elimination to determine the offending So transaction. From these offending SO then we determine the customer for these SO's. And then find out if there are any other accounts that have relationships with the offending customer and then turn off that relationship. Then rerun Autoinvoice for that SO. Most of the time SO will be imported successfully. Can anyone please suggest what must be the issue in Autoinvoice Program as I am new this.
Thank You.
Regards,
Meghana

Hi again;
I found this please also check this:
Price List Migration from 11.0.3 to 11.5.10/R12.
Regard
Helios

Join on Fact and Dimension tables

Hallo users,
I'm working on new rebuilding structur and I have this trouble: I need to Join more then one Items on the same dimensional table.
How is the correct way?
Have I to import the same table any time I need to join it, or is it enough a copy of folder?
How many times is possible to import a table on B.A.?
All of them couse I want to make a Complex Folder ....
thanks again
Gianluca

Hi Rod
In fact, most of the time, I take exactly the opposite approach and replicate my time folder over and over and over again, once for each of my main dates. Actually I have one master folder and use CTRL-C | CTRL-V to get my copies. I then create a join from each of my new date folders to a date in my main folders.
If I'm working with AP in Apps and I have a folder called AP Invoice Payments, that folder could have an Invoice Date, a Check Date and a Due Date. I will create three folders, one for each date so that the business area area looks like this:
AP IP Invoice Payments
AP IP Invoice Date
AP IP Due Date
AP IP Check Date
In the original AP IP Invoice Payments folder I will hide all three dates and teach my users to select from the new date folders. Both the Invoice Payments and Master time folders are based on materialized views, with all of the dates being indexed. The Master time folder has a primary key of the calendar date with indexes on the month, quarter and year. With hierarchies built on these indexed items I can drill through my fiscal time from all Due Date for year 2006 down to the quarters in a matter of seconds. I also scrap all Oracle date hierarchies as these never match my fiscal time and throw performance out the window when they point at an index. This is because of the TO_CHAR functions that must be applied.
Without a word of a lie I have clients whose Apps reports now run in less than 10 seconds, whereas the same report took over 2 hours using Oracle's crazy way of handling date hierarchies.
This technique above lies at the heart of all EULs that I build and I always get quick performance. Rod, when you say replicating folders will make the maintenance of your EUL more difficult I counter by saying that's fine by me. So long as the task for the end user is made easier it is perfectly correct to make the Admin's job more difficult. I tell my potential Admins that their job is to make life easier for the end users so if I catch them making their own job easier at the expense of the users I will come down hard on them. That's just not right. My Admins are there to support the end users not make their own lives easy. Unfortunately, too many Admins take the easy way out and don't go the extra mile.
I hope this different approach doesn't cause offence, but I just wanted to explain why I advocate replicating folders.
Best wishes
Michael

Outer join between logical tables

Hello,
This question is likely to be asked many times, but I failed to find the proper thread in the forum.
Assume there are 2 logical tables "Fact" and "Dim".
"Fact" has 1 LTS which consists of physical tables F, FX1, FX2 which are inner joined.
"Dim" has 1 LTS which consists of physical tables D, DX1, DX2 which are inner joined.
F and D tables are also joined together on physical layer.
I define left outer join between "Fact" and "Dim" on logical layer.
I create a request in Answers, querying columns from "Fact" and "Dim" which map to physical tables F and D only.
I expect OBIEE to build SQL query which uses F and D tables only, outer joined.
Instead of that all the physical tables used for logical tables "Fact" and "Dim" are joined together in a form like:
SELECT F.col, D.col
FROM (F inner join FX1 inner join FX2) left outer join (D inner join DX1 inner join DX2)
Is there any way to avoid this behavior or build data model in different way?
Thank you!

Hi Alex,
In BI Applications you never have a null in a facts foreign key to the dimension. Instead there is always a zero row wi record inserted with 'Unspecified' in all the columns. When the fact table is populated in the ETL, if the fact record doesn't have a corresponding dimension record the WID is poulated with zero.
This removes the problems with outer joins and helps considerably with performance.
This could be one practice you take from BI Apps and put into your own ETL's and data model.
Regards
Robin

Delete Fact and Dimension Tables

Hai All,
Small question! When deleting data from info cube, it asks whether to delete just Dimension table or both fact and Dimension tables.
What is the difference between these two?
Thank you.

Hi Visu,
The dimension table will contain the references to char value by way of SID and DIM ids, whereas the fact table will contain the number (of key figures). If you delete just the Fact table, the numbers go away, yet the DIM ids remain intact, so reload is faster. But if you are convinced that this data is not correct either, or you want a clean slate to strat reload again, then delete both Fact and Dim tables. Then when you reload, the DIM ids will be created again.
Hope this helps...

Best practice when FACT and DIMENSION table are the same

Hi,
In my physical model I have some tables that are both fact and dimension table, i.e. in the BMM they are of course separated into Fact and Dim source (2 different units) and it works fine. But I can see that there will be trouble when having more fact tables and I e.g. have a Period dimension pointing to all the different fact tables (different sources).
Seems like the best solution to this is to have an alias of the fact/transaction table and have 2 "copies" of the transaction table (one for fact and one for dimension table) in the physical layer. Only bad thing is that there will then allways be 2 lookups in the same table when fetching data from the dimension and the fact table.
This is not built on a datawarehouse - so the architecture is thereby more complex. Hope this was understandable (trying to make a short story of it).
Any best practice on this? Or other suggestions.

Id recommend creation of a view in the database. if its an oracle DB, materialised views would be a huge performance benefit. you just need to make sure that the MVs are updated when the source is updated.
-Domnic

How can we make an outer join (+) between 2 Queries

in the data model, i have 2 queries
i.e
Q_master and Q_detail
i want to make a data link between
these two queries and
also make an outer join between these
two queries(i.e. to display all the detail
records, whether they have details or not)
please reply is it possible ?
if yes then how?
plz write.
[email protected]
null

Hello,
Left outer join behavior is what you get by default with a link between two queries in Reports.
If you want a full outer join behavior, you'll need to create a third query that selects the detail records that have no corresponding master, and also create an extra layout region to display them in as a default group left or group above won't pick up these extra records.
If you want right outer join behavior, you'll need to put in a summary in the master query that counts the rows in the detail, and then put in a format trigger in the master repeating frame that suppresses printing when there are no detail records. And you'll also need the third query and layout section as in the full outer join case.
Regards,
The Oracle Reports Team --skw

Join multiple facts and dimensions for reporting issue

Hi,
I have a report requirements and need to use multiple fact tables and unconformed dimensions as described below
Fact table: F1,F2,F3
Dimensions tables: D1.....D9
F1:(joined to) D1,D2,D3,D4
F2::(joined to)D1,D2,D5,D6
F3::(joined to)D1,D2,D7,D8
D7::(joined to)D9,D8 (dimension D7 joined to two other dimensions D9 and D8
I'm trying to use columns from almost all the fact and dimension tables but getting "Unable to navigate requested expression. Please fix the metadata consistency warnings."
Repository is consistent and no errors and warnings.
How can I configure the repository to develop reports using all fact tables and dimensions?
Appreciate for your help.
Thanks
Jay.

You can find the same issue in
Logic of queries in OBIEE
or
Connection between 2 fact tables
Follow the link
http://there-n-back-again.blogspot.com/2009/04/oracle-analytics-how-to-report-over-non.html
Put 'All' or 'Total' at levels for dim_xxx for those facts you need in your report from facta and factb
Regards
Nicolae

Join Between W_PERSON_F and W_POSITION_D

Hi,
I want to join W_PERSON_F fact table and W_POSITION_D dimension table. Database: Siebel DB.
Is there any direct join or we want to join through some other table?
Thanks,
Satheesh

As per my knowledge there is no direct join between w_person_f and w_position_d
but you can create an alisa of w_person_d as contact(w_person_d) and join with w_person_f
as below
contact(w_person_d).row_wid = w_person_f.contact_wid
please mark the ans if it is correct.
Thanks

Best Practice - Outer Join between Fact and Dim table

Similar Messages

Maybe you are looking for