MV OF A LARGE FACT-DIM JOIN

If I have dimensions with rollups and a fact table, do I need to do the join of the fact table to the rollup views or the dim views or both in order to get all the columns in these objects?

No, this is another issue. The problem here is that when I look at the views for the dimension and its related hierarchies I do not see how to fetch the data using the LEVEL_NAME column. It's forcing me to include TWO tables in a snowflake configuration to go up the hierarchy. I thought that the cube would resolve this issue when it populated the cube. What am I missing here?

Similar Messages

Select count from large fact tables with bitmap indexes on them

Hi..
I have several large fact tables with bitmap indexes on them, and when I do a select count from these tables, I get a different result than when I do a select count, column one from the table, group by column one. I don't have any null values in these columns. Is there a patch or a one-off that can rectify this.
Thx

You may have corruption in the index if the queries ...
Select /*+ full(t) */ count(*) from my_table t
... and ...
Select /*+ index_combine(t my_index) */ count(*) from my_table t;
... give different results.
Look at metalink for patches, and in the meantime drop-and-recreate the indexes or make them unusable then rebuild them.

OBIApps - 11.1.1.7 Fact table joining to time Dim by default

Hi,
I am trying to pull a column only from the Fact table F1 and not pulling any Dimension columns into the report criteria. But when I run the results and look for the physical SQL, BI is joining the Time dimension table to the Fact table. Does any one know where this is being enforced in the BIAPPS RPD?
Thanks!!

Did you used only fact table for report and it joins with dimensional table at answers ?

Large Fact Tables

I have some transactional tables that are quite large. Anywhere from 1 to 3 million records. I have been doing my best to find information on the best way to deal with these and I am having some trouble. I am a little tight for time and could use a little help from others who have dealt with large datas sets before. What are some of the best ways to deal with this.
I have tried creating database level partitions by date which didn't seem to affect the OBI performance much. If I actually create different physical tables through the ETL process for each year it helps but I would like to avoid needing to create and manage that many different mappings.
Is the best way to do this to use the OBI caching and seed the cache after loading the data? I have even tried a few indexes and not had much luck.
Any help is greatly appreciated and I thank everyone in advance for their time. :)

Presuming Oracle backend database.....(you didnt say)
Partitioning would seem a quick (and expensive $$$$) win, if you partition on date, be sure to use the same date key to perform 'partition pruning' , which is to say give the optimizer a chance to throw away all unrequired partitions before it starts going to disk. When you say 'didnt improve performance much' you need to give a partition wise join for the partitioning to become effective at query time - did you do this ? for example a dashboard prompt with a filter on week / month would help (assuming your week / month time dim column is joined on partition key)
Is your data model a star schema ? Do you have dimension metadata in your database ? I'd be looking at Materialized views and looking for some sort of aggregate rollup query re-write whereby you queries are re-written at run time to the Mview and does not hit your fact table.
As for caching, OBIEE caching is the last resort after you exhaust every other alternative, its not there to speed up queries and you would be hiding the problem, what when a user drills down or needs to run an ad-hoc report that is not cached ?
I would start with understanding Oracle execution plans, review your data model (with the view on speedy data extraction) and look at what Oracle DB gives for data warehousing appliances :
parallelism is your friend!
star transformation,
Mviews (table or Cube based)
OLAP

Common diemsions and more then one fact table join problem

Hi,
I have 5 common dimension and 3 fact table which in the same subject area. When I want to display results from more then one fact table sending database then query more then one and I think BI server join this two different result on OBI server. But I think if obi server sending database query for exp. WITH SAWITH0 .... the results get effective.
+++002002:2ea0000:2ea000f:----2009/03/14 10:12:59
-------------------- SQL Request:
SET VARIABLE QUERY_SRC_CD='Report';SELECT "- Common Dimensions"."Year Month" saw_0, "- Subs. Tariff"."Subscriber Current Tariff Type" saw_1, "- Common Measures".Arpu saw_2, "- Common Measures"."Gross Margin" saw_3, "- Call Out"."Callout Dur" saw_4, "- Case".Case_Info_Num saw_5 FROM "CUSTOMER PROFILING" WHERE ("- Common Dimensions"."Year Month" = 200901) AND ("- Subs. Tariff"."Subscriber Current Tariff Type" = 'PREPAID') ORDER BY saw_0, saw_1
+++002002:2ea0000:2ea000f:----2009/03/14 10:12:59
-------------------- General Query Info:
Repository: Star, Subject Area: CUSTOMER PROFILING REV, Presentation: CUSTOMER PROFILING
+++002002:2ea0000:2ea000f:----2009/03/14 10:13:00
-------------------- Sending query to database named CENTRAVEA (id: <<471777>>):
select T223282.DIM_TIME_MONTH_ID as c1,
T221204.DIM_SUBS_CURRENT_TARIFF_TYPE as c2,
avg(T223490.FACT_CP_ARPU) as c3,
sum(T223490.FACT_CP_GROSS_MARGIN) as c4,
sum(T223490.FACT_CP_CO_DUR) as c5
from
DM.DIM_SUBSCRIBER T221204 /* A_DIM_SUBSCRIBER */ ,
DM.DIM_TIME_MONTH T223282 /* A_DIM_TIME_MONTH */ ,
DM.FACT_CUST_PROFILING_PART3 T223490 /* A_FACT_CUST_PROFILING_PART3 */
where ( T221204.DIM_SUBS_ID = T223490.DIM_SUBS_ID and T221204.DIM_SUBS_CURRENT_TARIFF_TYPE = 'PREPAID' and T223282.DIM_TIME_MONTH_ID = T223490.DIM_TIME_MONTH_ID and T223282.DIM_TIME_MONTH_ID = 200901 and T223490.DIM_TIME_MONTH_ID = 200901 )
group by T221204.DIM_SUBS_CURRENT_TARIFF_TYPE, T223282.DIM_TIME_MONTH_ID
order by c1, c2
+++002002:2ea0000:2ea000f:----2009/03/14 10:13:00
-------------------- Sending query to database named CENTRAVEA (id: <<471881>>):
select T223282.DIM_TIME_MONTH_ID as c1,
T221204.DIM_SUBS_CURRENT_TARIFF_TYPE as c2,
sum(T223294.FACT_CP_CASE_INFO_NO) as c3
from
DM.DIM_SUBSCRIBER T221204 /* A_DIM_SUBSCRIBER */ ,
DM.DIM_TIME_MONTH T223282 /* A_DIM_TIME_MONTH */ ,
DM.FACT_CUST_PROFILING_PART1 T223294 /* A_FACT_CUST_PROFILING_PART1 */
where ( T221204.DIM_SUBS_ID = T223294.DIM_SUBS_ID and T221204.DIM_SUBS_CURRENT_TARIFF_TYPE = 'PREPAID' and T223282.DIM_TIME_MONTH_ID = T223294.DIM_TIME_MONTH_ID and T223282.DIM_TIME_MONTH_ID = 200901 and T223294.DIM_TIME_MONTH_ID = 200901 )
group by T221204.DIM_SUBS_CURRENT_TARIFF_TYPE, T223282.DIM_TIME_MONTH_ID
order by c1, c2
I have another subject area and which defined like this subject area contain two dimension and 5 fact table. If I want to display results on this subject area I can see best sql for my database
My problem is why this two different subject areas create different queries. I think following query is the best for database.
Thanks for your help
+++002002:2ea0000:2ea0015:----2009/03/14 10:30:06
-------------------- SQL Request:
SET VARIABLE QUERY_SRC_CD='Report';SELECT "Dim - Segments"."Marketing Segment" saw_0, "Fact - Campaign Response"."Fact Campaign Award Amount" saw_1, "Fact - Customer Interaction"."Issue Response Cost" saw_2 FROM "AVEA ALL" ORDER BY saw_0
+++002002:2ea0000:2ea0015:----2009/03/14 10:30:06
-------------------- General Query Info:
Repository: Star, Subject Area: AVEA ALL, Presentation: AVEA ALL
+++002002:2ea0000:2ea0015:----2009/03/14 10:30:06
-------------------- Sending query to database named AVEA ALL (id: <<474694>>):
WITH
SAWITH0 AS (select sum(T51461.FACT_CMPGN_AWARD_AMOUNT) as c1,
T49384.DIM_MARKETING_SGMNT_DESC as c2
from
DM.DIM_MARKETING_SEGMENT T49384 /* DIM_BI_MARKETING_SEGMENT */ ,
DM.FACT_CMPGN_RESPONSE T51461 /* FACT_BI_CMPGN_RESPONSE */
where ( T49384.DIM_MARKETING_SGMNT_ID = T51461.DIM_MARKETING_SGMNT_ID )
group by T49384.DIM_MARKETING_SGMNT_DESC),
SAWITH1 AS (select sum(T51503.FACT_CUST_INT_ISSUE_RES_COST) as c1,
T49384.DIM_MARKETING_SGMNT_DESC as c2
from
DM.DIM_MARKETING_SEGMENT T49384 /* DIM_BI_MARKETING_SEGMENT */ ,
DM.FACT_CUST_INTERACTN T51503 /* FACT_BI_CUST_INTERACTN */
where ( T49384.DIM_MARKETING_SGMNT_ID = T51503.DIM_MARKETING_SGMNT_ID )
group by T49384.DIM_MARKETING_SGMNT_DESC)
select distinct case when SAWITH0.c2 is not null then SAWITH0.c2 when SAWITH1.c2 is not null then SAWITH1.c2 end as c1,
SAWITH0.c1 as c2,
SAWITH1.c1 as c3
from
SAWITH0 full outer join SAWITH1 On SAWITH0.c2 = SAWITH1.c2
order by c1

I find solution on Oracle® Business Intelligence Suite Enterprise Edition Release Notes.
If you use a version of Oracle Database 10g Release 2 prior to 10.2.0.3, then you might encounter an issue with a Full Outer Join that causes severe database performance issues and appears to hang the database when the Oracle BI Server sends to the database SQL queries that include WITH clauses.
To work around this issue when using Oracle Database 10g Release 1 or 2, upgrade to Oracle Database 10g Release 2 Patch Set 2 (for 10.2.0.3). For performance reasons, this is the preferred workaround.
To work around this issue without installing Patch Set 2, modify the Database Features table using the Administration Tool. This configuration prevents the Oracle BI Server from sending SQL constructs that expose the issue in an unpatched Oracle Database 10g.
To modify the Database Features table:
In the Administration Tool, open the properties of the Physical Database metadata object.
Navigate to the Features tab.
Ensure the values for the PERF_PREFER_MINIMAL_WITH_USAGE and PERF_PREFER_INTERNAL_STITCH_JOIN entries are selected, that is, set to True.

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

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

Multiple Facts and Join Paths

If you have multiple fact sharing the same dimensions is there a way to force the default Fact join path when pulling in only Dimensions? For instance pulling in Dashboard Prompts and using the Constrain - I pull in a few Dimensions and it obviously has to use the Fact table for the constaint, however, it is not using the one I am utilizing in the report. Thanks!

Yes, this functionality is called "Implicit fact", which means that this fact measure always be used when you run the query.
How to do this:
1) Create a measure on the fact table you want to create the join on.
2) In the presentation layer, go to the subject area and add this measure as the implicit fact.
3) Test it. Go to answers create a "dimension-only" report. Run the report and check the SQL to see whether the fact table is used.
Regards,
Stijn

Multiple fact - outer join

Hi all,
let's say that I created two facts
1) ALL_RELATIONS_FACTS: two dimensions
      d1: START_POINT
      d2: END_POINT
START_POINT END_POINT
1            2
3            4
1            3
A row in this fact means that the relationship exists, not all relationships will be measured
2) ALL_MEASURE_FACTS: three dimensions
      d1: START_POINT
      d2: END_POINT
      d3: DATE
      MEASURE1
      MEASURE2
START_POINT END_POINT DATE       MEASURE1    MEASURE2
1            2          20121023   100         200
3            4          20121023   300         400
A row in fact gives us measures on a certain date for a certain relationship.Now I would like to merge these two facts (with an OUTER JOIN).
START_POINT END_POINT DATE       MEASURE1    MEASURE2
1            2          20121023   100         200
3            4          20121023   300         400
1            3          20121023Could someone point me to a standard solution?
Riccardo

I don't get why you are telling me "ONE" confirmed dimension.
My current BMM is
ALL_RELATIONS_FACTS
    |           |
start_point   end_point
    |           |
    D1         D2
    |           |
start_point   end_point
    |           |
ALL_MEASURE_FACTS -------- DATE

Fact/Dim entries through RSRV

Hi all,
When we analyzing the infocube in RSRV to see percentage of Dimension tables, system is showing 0% for all the dimensions and also for Fact tables.
But data is existing in fact table of infocube and also in dimensions tables, when we see in SE11.we also executed report SAP_INFOCUBE_DESIGNS in SE38, in their also we are not able to find any entry for particular infocube.Please advice on this ASAP.
Regards
Manoj

TCode RSRV retirves info from the InfoCube statistics.
Go to InfoCube - Manage - Performance - and click check statistics
If it is not OK (green) then referesh the statistics and then check in RSRV

Fact/Dim Tables entries analyzing using RSRV

Hi All,
When we analyzing the infocube in RSRV to see percentage of Dimension tables, system is showing 0% for all the dimensions and also for Fact tables.
But data is existing in fact table of infocube and also in dimensions tables, when we see in SE11.we also executed report SAP_INFOCUBE_DESIGNS in SE38, in their also we are not able to find any entry for particular infocube.Please advice on this ASAP.
Thanks & Regards
Manoj

1) transaction se16 -> fact table name, /bic/f[infocube name] and /bic/e[infocube name] or /bi0/f.. and /bi0/e for business content infocube, click 'number of entries'
2) transaction db02 -> 'detail analysis' -> object name = [infocube name]
Hope it Helps
Chetan
@CP..

Star schema without a fact table?

Hi,
I'm preparing my warehouse for using with Discoverer and my question is about the star schema.
- Is a star schema directly associated with data warehouse?
- Can I talk about a star schema if a) I do not have a fact table (no summarized values) and b) if I do not have a dimension of time?
The problem is, I'm thinking of usine Discoverer but should I use it if it's not connected to a data warehouse?
As I told, I'd like to modelized my data "like" a star schema but my "center table" will contain only the foreign key of my dimensions; no time dimensions, no aggregate data in the center table (fact table).
Is there another word for the model I'd like to do?
Thank in advance.

Hi,
Is a star schema directly associated with data warehouse?Not really, a star schema is just one where there is one large fact table joined to many smaller dimension tables using key fields. You usually see this in data warehouses.
Can I talk about a star schema if a) I do not have a fact table (no summarized values) and b) if I do not have a dimension of time?A star schema must have a fact table but it doesn't need contain summarised values or a time dimension.
You can use Discoverer with any Oracle database, it doesn't have to be a data warehouse.
Rod West

RPD: Wrong Fact join when utilizing Level Based Measures (TOTAL Level)

I have 2 Facts and 3 Dimensions (Customer, Customer Emails, Time) being used in the RPD. The Dimensions are all set with TOTAL and DETAIL hierarchies.
Physical Layer:
Fact 1 joined to all 3 Dimensions
Fact 2 joined to all 3 Dimensions
Business Layer:
Fact 1 joined to all 3 Dimensions and Content Level set to DETAIL for all 3 Dimensions
Fact 2 joined to all 3 Dimensions and Content Level set to DETAIL for all 3 Dimensions
Metrics:
Fact 1 Metric: SUM set to TOTAL Level for Customer Emails Dimension
Fact 2 Metric: SUM set to TOTAL Level for Customer Emails Dimension
Issue:
I run a query pulling the metric from Fact 1 along with Dimension columns Email Address and Customer Name (2 Dimension Tables).
2 Physical queries are generated one against Fact 1 to get the Metric total by Customer. The 2nd query to get the Customer and Email Address that hits the Fact 2 table.
Expectation:
I would expect both queries from above to hit the SAME fact table (Fact 1). I understand the 2nd query would NOT contain the metric (Due to it set to TOTAL), but a relationship exists between the Fact 1 table and the Email Dimension, since the metric is pulled from this table I'd expect the Dimension value to be pulled from this table as well.
I look forward to any thoughts.

Merging Customer and Customer Email will not work as a Customer can have multiple Email Addresses and changes the grain of that Dimension (Customer Level).
Implicit fact would make no sense here, since each Fact has different sets of data.
The basic issue here is that we have a Customer Email table that is NOT at the grain of the Fact or even the Customer Dimension. I would have loved to snowflake off the Customer Email from the Customer Dim but then the metrics get inflated when returned and total on.
Hence we built the Email dimensions to join off the Fact and set all the metrics in each Fact (That joins to Customer) to TOTAL. So the metrics do not get inflated, the metrics repeat (Customer request) for each email per Customer.
I hope that clarifies.

Joining two fact tables for subject area

When I tried to use two simple fact tables joined by a dimension, I am getting the “ No fact table exists at the requested level of detail” error in the answer when I try to pull the columns from Fact 1 and Fact 2 tables. I have set the content in both the fact table to lowest granularity of dimension with CUST_ID, RAT_ID, ACT_ID keys. We have one to many relationships between dimension and both the fact tables. Any feedback is highly cherished.
Fact1: keys are: CUST_ID, RAT_ID, ACT_ID, YEAR
Fields are CUST_ID, RAT_ID, ACT_ID, YEAR , Rev1, Transaction Date
Fact2: keys are: CUST_ID, RAT_ID, ACT_ID, YEAR
Fields are CUST_ID, RAT_ID, ACT_ID, YEAR , Rev2, CreationDate
Dimension keys are CUST_ID, RAT_ID, ACT_ID
Thanks,
uday

Hi LC,
We have to add two fact tables F1 AND F2 to an existing bmm. These fact tables have history tables F11 AND F22 and we have to use partition logic for this.How you did partition ? you should be using Fragmentation logic for that any how you will add the F11/F22 tables to F1 and F2 LTS , so when you join F1 & F2 to the common dimension then it should work for the calucluated measures but dont forgot to create hierarchies and specify the content levels for the fact tables
Thanks,
Saichand

MV OF A LARGE FACT-DIM JOIN

Similar Messages

Maybe you are looking for