Why OBIEE always joins all dimensions to the fact?

We have a fact table, which joins 10 dimensions. I have a report that gets data from the fact and only one dimension. However, when i see the physical sql, i see that OBIEE joins all dimensions to the fact, even if I am not selecting any information fro the dimension. Is there any setting to avoid this? eg Fact1, dim1, dim2, dim3. The report has data from fact1 and dim1, but the actual sql joins fact1 with dim1, dim2 and dim3 even if I am not selecting any information from dim2 and dim3 in the report

We do use star model at physical and logical layer. I wonder what change I need to make to avoid this. The fact should not always join all dimensions.

Similar Messages

I mean that i phone take time to open apps ,contact ,etc why? i close all apps and the problem still?

i mean that i phone take time to open apps ,contact ,etc why? i close all apps and the problem still?

Try a reset by pressing and holding the home and power buttons for 15-20 seconds until the white Apple logo appears.

IPhone always imports all photos in the camera roll

Every time I want to import new photos onto my pc from my iphone, it always wants to import everything in the camera roll, even the old photos. Does renaming/moving pictures on my computer cause this to happen? If not, what's the cause and is there a way to fix this? Thanks for any help!

Any help/input is greatly appreciated

Again, why is Firefox(in all my systems) the only app that "invites", and returns amazon pings?

I use mostly Linux systems, and I can go online with other apps, but when I start using Firefox, my PCs start getting , and returning amazon pings? I hate amazon. I've installed Block Site, but it persist. Some of the Linux firewalls stop it, but some don't. WHY is there no way to block it at the browser??

How do you know that pings are happening? Is there any visible evidence of them? According to my about:config information, I have blocked 85 pings. I was not aware of any attempt at sending any.
I have these settings in my about:config window:
* browser.send_pings = false
* browser.send_pings.max_per_link = 1
* browser.send_pings.require_same_host = true
Not sure if those will help or not, however.

Preference Panes - Install for all users, after the fact?

Is there any way to get an already installed Pref Pane to install for all other users once it has been installed for the main account? I am hoping for a way that doesn't require uninstalling the current Pref Pane and reinstalling, some have settings I don;t wan't to lose for the main account.
PowerMac G4 Dual 1.25, MacBook 1.83 Mac OS X (10.4.7) 2 Gb RAM : 250 Maxtor, 80 & 250 WD int. drives : Mighty Mouse : dual mon.

Thanks for the reply.
The app (Bamboo Dock) has installed in the root applications folder. When I'm logged in as the administrator I can see the proper icon in the apps folder and run it. however, when I log on as my son I can see the app but the icon is the default icon with the A and the pencil on and the app won't run.
I didn't have a choice where to install and the app did not ask me if I wanted to install for all users.
I was wondering if I could run the installer app from the terminal with sudo, then I would be giving the installer app the authority to write the receipt? I don't know if this would work or how to do it if it would.
Stuart

Why not to Join Fatc to fact tables in OBIEE... What is the Logical Reason

Why not to Join Fatc to fact tables in OBIEE... What is the Logical Reason
Thanks in advance
V

Hi Venkat,
I am coming from the basics of a star schema here, so hope it helps
What is a fact?
A fact is something that has all measures which can be aggregated (Units, Dollars, # of Orders) etc with keys to different dimensions.
What is a dimension?
It is the context with which we understand/record/retrieve the measures in the fact. We understand "# of Orders" for a product/By a customer etc.
So joining a dimension and a fact helps to answer the Who/What/When kind of business questions. Ex : Who bought these products? What was the product type? When these products were sold kind of...
Now just imagine tying up fact to another fact. With this kind of model, you can never answer any business question.
I have never tried joining a fact with another fact in OBI (But do not think it will allow it though :) )
Hope I am clear.
Thank you,
Dhar

Logical Facts not all joined to Dimensions in an OBIEE model

We have a few OBIEE logical models where some of the fact rows don't have a corresponding dimension member. Essentially the FKs on the Fact don't have matching PKs in the Dimensions This has come about over time as we've made enhancements to our models and for the most part, people accept it. It causes the obvious issues when an incomplete dimension is added to a query and the fact rows drop out unexpectedly. It also causes problems where Grand Totals, which don't always include the dimension in their query, don't always match the details above.
Is this a common approach? Is there a best practice surrounding this? Is there a list of other likely issues we will encounter?
Thank you,
Jim

typically incremental fact must resolve these holes created ..wherein you have missing DIM keys . Missing keys are really bad issues as far as data integrity is concerned . unless you dont have a join on those columns , one must fix these holes . The report will be off when joined on these entities

Physical query generation: unneeded dimension tables get joined to the fact

Hi there!
The setup is the following:
There is a logical fact table which is joined to 7 logical dimensions, it has 4 table sources which correspond to different time dimension levels (all other dimensions are mapped to Detail level).
Time dimension logical table also has 4 different table sources (for days, months, quarters, and years).
The data source is an Oracle Database 11gR2.
The problem is:
No matter what the logical query is, in the physical query all 7 joins are performed, even if the resulting data is then simply discarded. This results in very bad query performance.
I feel that it is somehow related to the level-based fragmentation (since, for instance, inclusion of time dimension columns in SELECT list (not in WHERE) seems to affect physical queries), but lack sufficient knowledge to solve this problem or put up with it.
My questions are the following:
1) Have you ever encountered such a situation?
2) Can unneeded joins be eliminated?
2.1) If yes, how?
2.2) If not, then why are they needed?
Thanks in advance!

Physical level:
D01-D06 - ordinary physical tables.
D_DATES - all time levels from dates to years, D_MONTHS - time levels from months to years, also D_QUARTERS and D_YEARS.
F_DAILY - fact table joined to all of the D01-D06 and to D_DATES, F_MONTHLY - joined to D01-D06 and D_MONTHS, also F_QUARTERLY and F_YEARLY. All measure columns are the same.
Logical level:
D01-D06 correspond to ordinary logical tables with a single table source. Logical dimensions are created.
D_TIME is a logical time dimension with four levels (dates, months, quarters, and years) and four table sources ( D_DATES, D_MONTHS, D_QUARTERS, and D_YEARS ).
F is a fact table with four logical table sources ( F_DAILY, F_MONTHLY, F_QUARTERLY, and F_YEARLY ) with aggregation content levels set correspondingly.
OBIEE correctly picks physical table sources for different time levels, but generates extremely inefficient SQL (joining all dimension sources in a WITH-subquery, doing ROW_NUMBER over a result set, and then discarding half the columns, which were not needed to start with).

Two Filter on Two dimensions without constraining the fact table

Hi All,
does anybody know how to avoid the fact constraint when creating a report with two filters on different dimensions?
I have a big fact table with more than 10 Million rows. In the starmodel the is the dimension customer and products. I create a filter on the customer atrribute "Status" and choose the value "Active". Now I add the column "Product Type" from the dimension "Product" to the filter section. When I want to choose a value OBIEE executes a select statement within the fact table. So I have to wait very long to select a value. Is there any way to say OBIEE only to select the dimension table without joining the fact table?
Thank you very much in Advance.
Regards,
Stefan

Hi Stefan,
Generally queries on the dimensions (across dimesions also) always go through a fact. In case, you would like the queries not be through fact table, but just the dimension tables right away, you can set up a separate subject area for them.
You can create a separate subject area based on a dummy fact table to get these prompt values.
Please refer to http://gerardnico.com/wiki/dat/obiee/presentation_service/obiee_parameter_prompt_subject_area for more details on this setup.
Hope this helps.
Thank you,
Dhar

Cross join of dimensions

Hi,
For example: two dimension tables and one fact table.
dim1: branch
branch1
branch2
dim2: time
day1
day2
fact: sales
branch1, day2, 100
what I want in answers when using branch and time and sales without any filters:
Branch1, day1, 0
branch1, day 2, 100
Branch 2, day1, 0
Branch 2, day 2, 0
so basically I want to keep all dimensions combinations and related facts or 0 if there is no related facts. How to do it?
I know how to do it for just one dimension. That is to set up the relationship between the dimension and the fact as outer join. But how about two or more dimensions?
In SQL it will be something like dimension 1 cross join dimension 2 then left outer join the fact. How to do it in OBIEE 10 G?

And I have tried set branch - fact and time - fact as outer join. In answers,
1. select time and sales
day1, null
day2, 100
2. select branch and sales
branch1, 100
branch2, null
3. select branch, time , and sales
branch 1, day 2, 100
branch 2, null, null

OBIEE 11g: Non conformed dimension filter

Hi,
I have two fact tables and some confromed and non conformed dimensions between the fact tabels.
The hiearchies being built and proper levels were set for the fact tables. The measures of the fact were set to the total level of the non confromed dimension tables.
The fact also hold some non aggregated columns (baseline columns), all the base line columns where moved to a logical dim table.
The report involves both the fact tables, conformed and non conformed dimension columns.
When we built the report with all these columns the report is showing fine. But when we add the filter with the non conformed dimension the report is throwing some error.
Error Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 14023] None of the fact sources for D01 Date.Date are compatible with the detail filter [D05 Non Confrm Dimension.Code = 'AFS']. (HY000)
The above functionality was working fine with OBIEE 10g and have implemented it many times before.
There is one patch available for this issue but it is available only for windows 32 bit enironment.
Patch details
Patch 14210864: OBIEE 11G: CONFORMING DIMENSION SETTINGS FROM 10G NOT WORKING IN 11G
Can anyone give some suggestion or workaround? I can't do any change in Datamodel.
Thanks,
Vino

Hi Vinod,
In OBIEE 10g, we are running into similar error when we add filter from non conformed dimensions in a report, so can you please share patch download details like where to download or if we have to raise a SR for the Patch 14210864.
Thanks in Advance!!

Relationship between Dimension without linking Fact table

Hi,
My question is like I have five dimensions connected to a fact table through primary - foreign key(Composite Key) relationship. Will this referential integrity help if I want some information between two dimension which are not linked directly and I am not
including any measures from fact table .
Example: Suppose I have customer, Product and Manufacturer Dimensions all linked to a fact table but not linked to each other directly but can I get right result when I want to know what are the manufacturer for each product? or list of
customers using a particular product. Will the referential integrity work ? since they all are related in fact table.
regards
Sanjoy ghosh

Hi Sanjoy -
The answer to your questions depends on your dimensional design and exactly what the fact table represents. Fact tables naturally capture the intersection of the different dimensions. This is true whether you physically implement a
PK - FK relationship in the relational db.
In your case, since customer is involved, sounds like a sales transaction fact. If that's true, you can easily join from customer, through the fact, to the product dimension, to get the list of customers that purchased a particular product.
For the manufacturer for each product, a sales transaction fact will not necessarily answer this question completely. Particularly in the case of products that have no sales for a given period, and thus, don't have any fact records to join from manufacturer
across to product. If you need to solve this question, you have some other options:
- flatten the Manufacturer directly into the Product dimension as attribute of the product (probably the simplest approach and allows you to remove a key from the fact)
- embed the Manufacturer key directly in the Product dimension (if you need the Manufacturer dimension separate for use with other events / facts and more detailed dimensionality - i.e., detailed attributes about the Manufacturer that wouldn't need
to be flattened onto the product)
- build a factless fact that captures the products offered by a given manufacturer at a given point in time (perhaps representing various products catalogs and associated dates. This would allow you to capture rich details about each dimension separately
and use the factless fact to record)
Let me know if that helps.
Brent Greenwood, MS, MCITP, CBIP
// Please mark correct answers and helpful posts //
http://brentgreenwood.blogspot.com

Account Dimension not showing all members in the cube in Analysis Services

Hi,
         In SAP - BPC 5.1 after processing account dimension all the members are created under account dimension in analysis services but the same cannot be found in the data cube. Hence the reports generated through SAP - BPC is not showing all the members.
         The issue looks very strange as we can see the members getting created but the same is not getting populated in the cubes. I am not able to visualize what exacly the issue is? Is it with the application or with the analysis services?
Thanks
Sharath

Your sixth sense is correct, there is definitely support in MSAS and BPC 5.1 for multiple hierarchies in the account dimension.
I'm also referring to parentH1 and parentH2, but perhaps we're still speaking of different things.
In the past, I faced a very similar problem as you, and the root cause was because I had one member, let's call it FancyParent, which, in H1, had children Child1 and Child2.
But in H2 it had children Child1, Child2 and Child3. I forget now if that was how I wanted the setup to be, or if it was a mistake on my part, but either way, MSAS doesn't allow this. The admin consol didn't complain when processing the dimension -- this was in Outlooksoft 5.0; perhaps validation has improved now.
But the cube was completely unworkable. Certain things were calculating correctly, but everything in the account dimension in the area around FancyParent (above and below it, in both hierarchies) was quite unpredictable.
By disabling first one, and then the other, of the two hierarchies, and disabling blocks of accounts, I was eventually able to pinpoint the problem. But it took days to figure out what was the problem. (The account dimension had 2500 members and 4 hierarchies, and it was not a pretty sight.)
A parent must have the same definition of children in all hierarchies. It can't, as another example, have children in H1, and be a base member in H2. Each member can have different parents in the two hierarchies, but must always have the same children in both.
To work around this problem, I had to create two separate accounts NetIncomeH1 and NetIncomeH2 (and PretaxIncomeH1, PretaxIncomH2, etc. all the way down to the point where they branched off), to get the two separate aggregations of the P&L in the two hierarchies. Once I did that, it made sense to me why, but I also swore off on frivolous extra hierarchies ever again.

Querying Levels in Dimensions joined to the Facts

I created a location dimension using the standard levels, i.e., region > subregion > country > state > location_id. I then attached it to a sales fact that had the location_id as the key, but when I tried to query the cube by it's levels the only level I see is the location_id level which is at the state. None of the other levels appear or are queryable when I do something like:
SELECT * FROM vw_SALES_CUBE A, vw_LOCATION_DIM B
WHERE A.LOCATION_DIM = B.DIM_KEY
AND A.LEVEL = 'COUNTRY'
Only one level comes up although in the location_dim all the other levels exist the join does not carry them over. The data for the levels appears in the COUNTRY_LONG_DESCRIP column and not in the LEVEL column.
What am I doing wrong. Are there other objects I need to create like an MV.
jrod

I was thinking that is if I created a cube such as the one described in the thread and that I did a query along the LEVEL_NAME that the cube would fetch the data without the need for me to create say MV's aggregateing the data. For example,
/* The following is a basic query against a fact table */
SELECT T.CALENDAR_YEAR_DSC TIME, SUM(F.SALES) SALES
FROM TIME_DIM T, UNITS_FACT F
WHERE T.CALENDAR_YEAR_DSC IN ('2005', '2006')
AND T.MONTH_ID = F.MONTH_ID
GROUP BY T.CALENDAR_YEAR_DSC;
/* The next query fetches the exact same results from a cube using filters: */
SELECT T.LONG_DESCRIPTION TIME, F.SALES SALES
FROM TIME_CALENDAR_VIEW T,
PRODUCT_PRIMARY_VIEW P,
CUSTOMER_SHIPMENTS_VIEW CU,
CHANNEL_PRIMARY_VIEW CH,
UNITS_CUBE_VIEW F
/* Apply filters to every dimension */
WHERE T.LONG_DESCRIPTION IN ('2005', '2006')
AND P.LEVEL_NAME = 'TOTAL'
AND CU.LEVEL_NAME = 'TOTAL'
AND CH.LEVEL_NAME = 'TOTAL'
/* Join dimension views to cube view */
AND T.DIM_KEY = F.TIME
AND P.DIM_KEY = F.PRODUCT
AND CU.DIM_KEY = F.CUSTOMER
AND CH.DIM_KEY = F.CHANNEL
ORDER BY TIME;
In these two queries I fetch the same grain. So why is it that the cube has not precomputed these factors. What do I need to do this?

Two facts with joins to all dimensions

I have two dimension tables say D1, and D2 and they are joined to two facts F1 and F2. Now I need a report from one column of d1 and other column of d2 how obiee server will perform query by only one fact or two facts if only one fact which fact it will go through.

OBI will select one fact....I think it's based on the order of the facts in the business model.
But, you can set an implicit fact columns in the presentation layer...this gives you the possibility to add implicitly the fact table that must be used when only dimension objects are selected.
Hope this answers your question.
Kr,
A

Why OBIEE always joins all dimensions to the fact?

Similar Messages

Maybe you are looking for