Fact table is getting flooded

while loading 0FIAR_C03 its been observed that fact table is getting n times records
eg:
Transfered request: 969
Added Request: 29482
Data modeling as follow:
0FI_AR_4 -> 0FIAR_O03 -> 0FIAR_C03
till ods its fine but after that ......
when I checked fact table I found time dim_id is having multiple values because of that we are getting same set of fact data again and again for same dim_ids
when I checked update rule of cube then I observed 0CALDAY 0CALMONTH and 0CALYEAR are mapped with 0FISCPER using time distribution
so my question here is what is the function of time distribution ???
is that related to my issue???
Edited by: Alok Kashyap on Mar 4, 2009 9:28 AM

Hi Alok,
To answer some questions:
(A) Time Distribution Usage: Review "Time Update" Rule Type on SAP Help Portal (Data ware housing) NW04s version.
Main Point = " All the key figures that can be added are split into correspondingly smaller units of time"
"Time Update:
When performing a time update, automatic time conversion and time distribution are available.
Direct Update: the system automatically performs a time conversion.
Time Conversion:
You can update source time characteristics to target time characteristics using automatic time conversion. This function is not available for DataStore objects, since time characteristics are treated as normal data fields.
Time Distribution:
You can update time characteristics with time distribution. All the key figures that can be added are split into correspondingly smaller units of time. If the source contains a time characteristic (such as 0CALMONTH) that is not as precise as a time characteristic of the target (such as 0CALWEEK), you can combine these characteristics with one another in the rule. The system then performs time distribution in the transformation.
For example, you break down the calendar month 07.2001 into the weeks 26.2001, 27.2001, 28.2001, 29.2001, 30.2001 and 31.2001. Each key figure that can be added receives 1/31 of the original value for week 26.2001, 7/31 for each of weeks 27, 28, 29, and 30, and exactly 2/31 of it for week 31."
(B) Yes, it (time distribution) is "indirectly" adding extra rows into your fact table since " All the key figures that can be added are split into correspondingly smaller units of time" so you are getting more numerous distinct values of different DIM_ID values.
(C) Whether Time Distribution is Causing Extra Rows into the Fact table:
The 0BCT* Std Content of 0FIAR_C03 only contains 0Fiscper (Fiscal Year/Period) and of course 0Fiscvarnt (Fiscal year variant) time characteristics in the cube data model...The underlying infosource 0FI_AR_4 also has only 0Fiscper time characteristic.
So suspect someone at your site has tinkered with the 0BCT* 0FIAR_C03 datamodel to introduce more time characteristics...Please refer to the documentation or project deployment notes at your site since there may have been specific project requirements to do so. The project deliverables and the suspect person may be more the root cause...
Hope this helps.
Thanks and Regards,
Lee

Similar Messages

PL/SQL- Problem in creating a partitioned fact table using select as syntax

Hi All,
I am trying to create a clone(mdccma.fact_pax_bkng_t) of existing fact table (mdccma.fact_pax_bkng) using dynamic pl/sql. However, pl/sql anonymous block errors out with following error:
SQL> Connected.
SQL> SQL> DECLARE
ERROR at line 1:
ORA-00911: invalid character
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1608
ORA-06512: at "SYS.DBMS_SQL", line 33
ORA-06512: at line 50
Here is pl/sql block:
-- CREATING FPB_T
DECLARE
v_owner VARCHAR2(32) := 'MDCCMA';
v_table_original VARCHAR2(32) := 'FACT_PAX_BKNG';
v_table VARCHAR2(32) := 'FACT_PAX_BKNG_T';
v_tblspc VARCHAR2(32) := v_owner||'_DATA';
CURSOR c_parts IS SELECT TABLESPACE_NAME, PARTITION_NAME,HIGH_VALUE, ROW_NUMBER() OVER (ORDER BY PARTITION_NAME) AS ROWNUMBER
FROM USER_TAB_PARTITIONS
WHERE TABLE_NAME = v_table_original
ORDER BY PARTITION_NAME;
v_cmd CLOB := EMPTY_CLOB();
v_cmd3 varchar2(300) := 'CREATE TABLE ' ||v_owner||'.'||v_table||' TABLESPACE '||v_tblspc
||' NOLOGGING PARTITION BY RANGE'||'(' ||'SNAPSHOT_DTM '||')' ||'(';
v_part VARCHAR2(32);
v_tblspc_name VARCHAR2(32);
v_row number;
v_value LONG;
v_tmp varchar2(20000);
v_cur INTEGER;
v_ret NUMBER;
v_sql DBMS_SQL.VARCHAR2S;
v_upperbound NUMBER;
BEGIN
v_cmd := v_cmd3;
OPEN c_parts;
FETCH c_parts INTO v_tblspc_name, v_part,v_value, v_row;
WHILE c_parts%FOUND
LOOP
IF (v_row = 1) THEN
v_tmp := ' PARTITION '||v_part||' VALUES LESS THAN ' ||'('|| v_value||')'||' NOLOGGING TABLESPACE '||v_tblspc_name;
ELSE
v_tmp := ', PARTITION '||v_part||' VALUES LESS THAN ' ||'('|| v_value||')'||' NOLOGGING TABLESPACE '||v_tblspc_name;
END IF;
v_cmd := v_cmd || v_tmp;
-- DBMS_OUTPUT.PUT_LINE(v_cmd);
FETCH c_parts INTO v_tblspc_name, v_part,v_value, v_row;
END LOOP;
-- DBMS_OUTPUT.PUT_LINE('Length:'||DBMS_LOB.GETLENGTH(v_cmd));
v_cmd := v_cmd||')'||' AS SELECT ' || '*'||' FROM ' || v_owner||'.'|| v_table_original ||' WHERE '||'1'||'='||'2'||';';
v_upperbound := CEIL(DBMS_LOB.GETLENGTH(v_cmd)/256);
FOR i IN 1..v_upperbound
LOOP
v_sql(i) := DBMS_LOB.SUBSTR(v_cmd
,256 -- amount
,((i-1)*256)+1 -- offset
END LOOP;
v_cur := DBMS_SQL.OPEN_CURSOR;
DBMS_SQL.PARSE(v_cur, v_sql, 1, v_upperbound, FALSE, DBMS_SQL.NATIVE);
v_ret := DBMS_SQL.EXECUTE(v_cur);
CLOSE c_parts;
DBMS_OUTPUT.PUT_LINE(v_cmd);
-- EXECUTE IMMEDIATE v_cmd ;
END;
The above pl/sql creates a DDL for partitioned fact table(new) based on an existing fact table and get executes through CLOB.
Please look into the issue and let me know any changes or modifications/suggestions that are required to fix the issue. Any help is appreciated.
Thank You,
Sudheer

Think this is your problem:
v_cmd := v_cmd||')'||' AS SELECT ' || '*'||' FROM ' || v_owner||'.'|| v_table_original ||' WHERE '||'1'||'='||'2'||';';Remove the SQL terminator ';' ... dynamic SQL doesn't require it, try this instead:
v_cmd := v_cmd||')'||' AS SELECT ' || '*'||' FROM ' || v_owner||'.'|| v_table_original ||' WHERE '||'1'||'='||'2';Thanks
Paul

Fact tables not loading

Hi guys,
We have installed ODI 11 with OBIA and so far the installation has been done with out any problems.But the problem here is none of the fact tables is getting loaded what would be the root cause for this.
Most of the dimension tables got loaded.By default only 1 fact table got loaded,but there are 50 fact tables in that module(HRMS & finance) but when we execute the process is running but the tables ar not loading.
Its an urgent requirement,i had no clue whats happening.Any ideas guys.
TIA,
Kranthi.
Edited by: Kranthi.K on Apr 28, 2010 3:34 AM

First of all you need to check if all the dimensions got loaded or not?
Because if a crucial dimension like customer or something else, which is being used in all fact loads is not getting loaded then obviously none of your facts will be loaded.
Hope it helps.

BWA Fact Table Index Size

Hi
Can anybody tell me how the BWA decides when a fact table index gets split into multiple parts? We have a number of very large cubes that are indexed and some have a fact table index that consists of one logical index which is made up of multiple physical indexes but other, similar sized cubes, just have one very large physical index for the fact table.
With the one very large physical index we seem to get an overload problem but when they are split into multiple parts we don't.
Thanks
Martin

Hi Martin,
this depends on the reorg config and the attribute of the index. You can manually trigger a splitting of an index via command 'ROUNDROBIN x', x stand for the number of parts which the index will be split to. Therefore you have to go into trexadmin standalone tool -> landscape right click on index -> split/merge index...
If you want an automatically split, you have to setup your reorg settings. Goto trexadmin standalone tool -> tab reorg -> options -> here you can choose the type of algorithm. Have a look into note 1313260 and 1163149.
Do you have a scheduled reorg job?
Regards,
Jens
PS: Every black box can be understood...

Problem querying over two fact tables

The business requirement is that we want to be able to see sales for two different periods of times, over different brands, different Items' years and seasons per periods.
So for the different dimensions I created alias having two tables in the physical layer
for Brands, Shops and Items (tables) [These are the tables where I query for different brand, Item's year and different season]. The Business Model Schema looks like this:
Items-----> SALES <------Brands Items 2-----> SALES 2 <------------Brands 2
^ ^
TIMES TIMES 2 (TIMES JOINED WITH SALES AND TIMES 2 WITH SALES 2)
and VENDORS connected to both SALES & SALES 2 left outer joined
The need is that I need to query over two indepedent periods of time with independed dimensions but for a common dimension (Vendors).
The presentation data simplified looks like this:
Answers
Vendor Sales Qty Sales 2 Qty
1092 234 123
The problem is that when a vendor doesn't exist in one period it doesn't come and in the other although there are sales. So when I query with the same filters (same period of time, Brands, Items' years and seasons) over these two fact tables I get the same sales and correct data. When there are different criteria then I lose data.
The Query fired in the database is the following:
select distinct case when D2.c4 is not null then D2.c4 when D1.c4 is not null then D1.c4 end as c1,
D1.c3 as c4,
D1.c1 as c5,
D1.c2 as c6,
cast(D1.c2 / nullif( D1.c1, 0) * 100 as DOUBLE PRECISION ) as c7,
D2.c3 as c8,
D2.c1 as c9,
D2.c2 as c10,
cast(D2.c2 / nullif( D2.c1, 0) * 100 as DOUBLE PRECISION ) as c11
from
(select sum(T43161.amnt_1) as c1,
sum(T43161.mk_1) as c2,
sum(T43161.qty_1) as c3,
T7120.VE_NAME as c4
from
VE04_TBL T7120,
GE04_COMPANY_TBL T43802,
EI04_TBL T6931,
Salesmcost T43161
where ( T6931.EI_CODE = T43161.ei_code and T6931.VE_CODE = T7120.VE_CODE and T6931.GE_COMPANY_CODE = '1' and T6931.EI_SEASON_CODE = 'Χ' and T6931.EI_YEAR = '2009' and T7120.GE_COMPANY_CODE = '1' and T7120.VE_CODE = T43161.ve_code and T43161.ge_company_code = T43802.GE_COMPANY_CODE and T43802.GE_COMPANY_NAME = '*** Φ. & Κ. ΛΕΜΟΝΗΣ ΑΕΒΕ ****' and T43802.LIST_ITEM_IND = '1' and T43161.trans_date >= ADD_MONTHS(TO_DATE('2010-05-12' , 'YYYY-MM-DD'), -7 * 12 ) and T43161.trans_date between TO_DATE('2009-01-01' , 'YYYY-MM-DD') and TO_DATE('2009-01-31' , 'YYYY-MM-DD') )
group by T7120.VE_NAME
) D1,
(select sum(T44099.amnt_1) as c1,
sum(T44099.mk_1) as c2,
sum(T44099.qty_1) as c3,
T7120.VE_NAME as c4
from
EI04_TBL T44615 /* EI04_TBL 2 */ ,
VE04_TBL T7120,
GE04_COMPANY_TBL T43802,
Salesmcost T44099 /* Salesmcost_2 */
where ( T7120.VE_CODE = T44099.ve_code and T7120.VE_CODE = T44615.VE_CODE and T7120.GE_COMPANY_CODE = '1' and T43802.GE_COMPANY_CODE = T44099.ge_company_code and T43802.GE_COMPANY_NAME = '*** Φ. & Κ. ΛΕΜΟΝΗΣ ΑΕΒΕ ****' and T43802.LIST_ITEM_IND = '1' and T44099.ei_code = T44615.EI_CODE and T44615.GE_COMPANY_CODE = '1' and T44615.EI_SEASON_CODE = 'Χ' and T44615.EI_YEAR = '2008' and T44099.trans_date between TO_DATE('2008-01-01' , 'YYYY-MM-DD') and TO_DATE('2008-01-31' , 'YYYY-MM-DD') )
group by T7120.VE_NAME
) D2
where ( D1.c4 = D2.c4 ) /*<------- I think that this join creates the problem*/
order by c1
Edited by: user1198434 on 12 Μαϊ 2010 5:14 πμ
Edited by: user1198434 on 12 Μαϊ 2010 5:41 πμ

Hi,
go through this
http://obiee101.blogspot.com/search/label/OUTER%20JOIN
I think you are new to the forum. try searching through some of the famous obiee forums. Gurus have already covered most of the issues. few are,
http://obiee101.blogspot.com
http://oraclebizint.wordpress.com/
http://gerardnico.com/weblog/
http://108obiee.blogspot.com/
thanks,
karthick

Joins with multiple fact tables

Hi Experts,
i have one doubt in joins
we have two dimensions D1 and D2,
D1 is having A1 and A2 columns
D2 is having B1 and B2 columns
two facts F1 and F2 these are joined like D1 to F1 D1 to F2 and D2 to F1, D2 to F2
D1----->F1
D1------>F2
D2-------->F1
D2-------->F2
if i selected A1 and B1 in a request from which FACT table will get the data and why can you please explain
please help me
reg,
Jell

Hi All,
I have a similar requirement where I have 4 multiple fact tables and we can't combine all those facts into one single fact table. In that case how can a query work with multiple common and uncommon dimensions and measures from multiple fact tables, if it doesn't work that way - can you please explain how can we expect a query to work with multiple fact tables.
For eg: D1– Dim
D2 – Dim
D3 – Dim
D4 – Dim
F1 –Fact
F2 – Fact
F3 – Fact
D1 -> F1
D2 -> F1,F2
D3 -> F2
D4 -> F1, F3
In this case if we want to query from D1,D2,D3, F1, F2 or D1,D2,D3,D4,F1,F2,F3. Kindly please explain how it can be modeled in BMM or what are the limitations. I have done with two fact tables in past and didn't had issues but this is kind of a vast implementation. Your help is appreciated.

Update DIM data in Fact Table

All -
I have a TSR dimension data (1 of 12 dimensional attributes) in our forecast fact table which gets updated monthly in our source system and we have to reflect this in our BPC system. What is the best method of updating this data in BPC?
1. Can I update the TSR directly in the forecast fact table and reprocess the application to reflect this in the cube?
2. Do I have to negate that entire fact table row with the old TSR and insert a new row with the new TSR and process the cube?
3. Any other method?
Thanks for your help.

You need to explain your requirement a bit more. Why you want to add type or rejection reason in fact table.
In general you should avoid adding textual data in fact.
Fact tables are only supposed to store keys and measures. It can hold textual data in case of degenerate dimension ( i.e if the number of records are same in dimension as well as fact ).
Type or Rejection reason are going to have much less records. You can create a new dimension for them having probably 20 or 30 records.
Disadvantages of adding textual data in fact is, once the fact has millions of records the fact table updates are going to take huge time and also your reports will take long time.
If you have a rejection reason dimension with some 20 records, you can use rejection reason in prompts.
But if the same rejection reason is coming from fact table your prompts performance is going to be very slow since it has to fetch 20 distinct records from millions of records.
Consider these before adding textual data in facts.
Thanks
Edited by: Maqsood Hussain on Dec 5, 2012 9:40 PM

Fact table usage is not appropriate

Hi All,
I am new to OBIEE 11g, we have 4 fact tables(F1, F2, F3, F4) that shares common 5 Dimensions(D1, D2, D3, D4, D5) and they are joined as below
F1-D1, F1-D2, F1-D3, F1-D4, F1-D5
and similarly all other facts(F2, F3, F4) are joined as above
problem is when we run the report with prompts, let say we created two choice list prompts(P1, P2), P1 with D1.Col1 column and filtering prompt values based on D1.Col12 to populate choice list, find SQL below
SELECT "D1"."Col1" FROM "Sales SA" WHERE "D1"."Col2"='North Zone'
based on the above prompt P1 we are restricting the choice list values of prompt P2 by setting Limit values by as P1, when we select a value from prompt P1 and click on P2 prompt it is showing blank i.e. results is NULL.
What I have noticed is, it is joining F4 fact table to get the data, checked the logical and physical queries of P2 prompt
Logical Query :
SELECT "D2"."COL1" saw_0 FROM "Sales AS" WHERE "D1"."COL2" = 'North Zone' ORDER BY saw_0
Physical Query :
select distinct T560319.CO1 as c1
from
D1 T560319 / Dim_D1 */ ,*
D2 T560407 / Dim_D2 */ ,*
F4 T562764 / Fact_F4 */*
where ( T560319.COL1 = T562764.COL1 and T560407.COL3 = T562764.COL2 and T560407.COL2 = 'North Zone')
order by c1
actually it should join the F3 fact table to populate the values of P2 choice list, but is joining F4 fact table
not sure where the problem is, can somebody help in resolving this problem.
Thanks,
Sumanth

Try by setting implesit fact table. You need to choose any fact table column or measure
Subject area-> properties
I'm assuming you have one logical fact table with 4 Logical Table sources

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

Choosing a Fact Table - HELP all you smart people

I have two fact tables (F1 and F2) and three dimensions (D1, D2 and D3)
Each fact table relates to all 3 dimensions.
I create an Answers request that produces a report with three columns
D1.year D2.name F1.number_of_equipments*D3.duration
The BI server could answer this request all using F1 using a single query - but it doesn't - and so gets the 'wrong' answer)
Instead it decides to run two queries using both Fact tables
a) get D1.year, D2.name and D3.duration using F2
b) get D1.year, D2.name and F1.number_of_equipments
c) stitch the two together in the BI Server (using the common Dimensions of D1 and D2)
How do I force/encourage the server go to F1 only?
If I add D3.col3 directly into the request (rather than using it as part of a formula) then Answers writes a single query- but this workaround is difficult to explain to end-users.
Currently on 10.1.3.2 OBIEE and 10.2.0.3 Oracle DB. Have set PERF_PREFER_INTERNAL_STITCH_JOIN to true (to workaround a different problem)

To choose a fact table, OBIEE server :
- check first if only one fact table belongs to the good aggregate content (logical table source property> tab content)
- if it can found two fact tables for the same level of content, it take the sort order of the sources in the logical table property (logical table > tab source, you can modify the sort order)
Cheers
Nico

Unexpected results getting data from two fact tables through conformed dim

Hi all,
We are getting an unexpected behaviour in our OBIEE 10.1.3.3.3. We have this scenario:
We have {color:#0000ff}2 fact tables{color}{color:#000000} called F1 and F2. F1 has one measure, f1m1 and F2 has another one, f2m1.
We have {color:#0000ff}4 conformed dimensions{color}, called D1, D2, D3, Date.
When we are requesting for individual fact tables, we are getting:
date d1 d2 d3 f1m1
dt1 - x - y - z - m1
dt1 - x - y - z' - m2
date d1 d2 d3 f2m1
dt1 - x - y - z - m3
dt1 - x - y - z'' - m4
But, trying to obtain a compare scenario, we are getting
date d1 d2 d3 f1m1 f2m1
dt1 x y z m1 m4
Instead of
date d1 d2 d3 f1m1 f2m1
dt1 x y z m1 m3
Looking at query log, we have catched the reason. That's why BI Server is using to solve this request using ROW_COUNT() to join SAWITH0 and SAWITH1 in SAWITH2 result set. So, the order may not be the same in the results sets in every fact table. More or less, generated query is like:
WITH
SAWITH0 AS
(select ....
from F1),
SAWITH1 AS
(select ...
from F2),
SAWITH2 AS
select from (select ...
ROW_NUMBER() OVER PARTITION (....) c10
from SAWITH0.d1 full outer join SAWITH1.d1 ....) D1
{color:#ff0000}where (D1.c10 = 1){color}
select SAWITH2. ....
from SAWITH2
order by c1..c10
The problems seems to be that BI server is ordering the result sets SAWITH0 and SAWITH1 and getting row number to join this results sets, but this is not getting the correct result.
Any ideas?
TIA
Javier
{color}
Edited by: jirazazábal on Mar 13, 2009 2:46 PM

I have done a logical fact table with two fact table source on it.
The Sql performed against the database was this one.
-------------------- Sending query to database named PRODS_AIX (id: <<153418>>):
WITH
SAWITH0 AS (select sum(T21296.CONSUMERS_SALES_EURO) as c1,
     T21309.DIVISION_CODE as c2
from
     DIVISION T21309,
     C_CONSUMERS_SALES T21296
where ( T21296.DIVISION = T21309.DIMENSION_KEY )
group by T21309.DIVISION_CODE),
SAWITH1 AS (select sum(T21356.ORDER_VALUE) as c1,
     T21309.DIVISION_CODE as c2
from
     DIVISION T21309,
     DWH_SALES_ORDER_OVERVIEW T21356
where ( T21309.DIMENSION_KEY = T21356.DIVISION_KEY )
group by T21309.DIVISION_CODE)
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 nvl(SAWITH0.c2 , 'q') = nvl(SAWITH1.c2 , 'q') and nvl(SAWITH0.c2 , 'z') = nvl(SAWITH1.c2 , 'z')
order by c1As you can see one select (SAWITH0) for the first fact table C_CONSUMERS_SALES and one select for the second fact table DWH_SALES_ORDER_OVERVIEW (SAWITH1 ) and the two statement are joined with a full outer join.
I ask me why you have the three select (SAWITH0,SAWITH1 and SAWITH2). Can you please paste the complete SQL performed ?
Can you tell us also which SQL is performed if you select only the columns from one fact table and not for the other ?
Regards
Nico
http://gerardnico.com

What fact tables get affect in open hub services whether E or F

hi,
what fact tables get affect in open hub services whether E or F when an info provider is accessed.
regards,
-a

Hi Ajay,
Depends whether the cube is compressed or not. If not compressed then F fact table and if fully compressed then E fact table.
Bye
Dinesh

Get the master table value based on multiple fact tables

I have an master table which has to filter data based on multiple fact tables
In the below sample, i need to get the list of MasterTable SId in an single query for fetching data from all the fact tables with an criteria.
Can u let me know the single query to handle the below situation
Select count(1) from dbo.DimMaster where sid in
(Select Master_sid from dbo.factsales where SalesDate < '20141231')
Select count(1) from dbo.DimMaster where sid in
(Select Master_sid from dbo.factPurchase where PurchaseDate < '20141231')
Select count(1) from dbo.DimMaster where sid in
(Select Master_sid from dbo.factSalary where SalaryDate < '20141231')
Select count(1) from dbo.DimMaster where sid in
(Select Master_sid from dbo.factMarket where MarketDate < '20141231')
ShanmugaRaj

Please try below:
SELECT
(SELECT count(1)
FROM dbo.DimMaster
WHERE sid IN (
SELECT Master_sid
FROM dbo.factsales
WHERE SalesDate < '20141231'
)) as C1,
(SELECT count(1)
FROM dbo.DimMaster
WHERE sid IN (
SELECT Master_sid
FROM dbo.factPurchase
WHERE PurchaseDate < '20141231'
)) as C2,
(SELECT count(1)
FROM dbo.DimMaster
WHERE sid IN (
SELECT Master_sid
FROM dbo.factSalary
WHERE SalaryDate < '20141231'
)) as C3 ,
(SELECT count(1)
FROM dbo.DimMaster
WHERE sid IN (
SELECT Master_sid
FROM dbo.factMarket
WHERE MarketDate < '20141231'
)) as C4
-Vaibhav Chaudhari

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

Best way to combine multiple fact tables in single mart

Hi, quick question that I think I know the answer to, just wanted to bounce it off everyone here to make sure I'm on the right track.
I have a HR datamart that contains several different fact tables. Some of the facts are additive across time (i.e. compensation - people get paid on different days, when I look at a month I want to see the total of all pay dates within that month). The other type of fact is more "status over a set of time" - i.e. a record saying that I'm employed in job X with a salary of Y from a given start date to a given end date.
For the "status over time" type facts, if I choose January 2009 (month level) in the time dimension, what I'd really like to see is the fact records that were in place "as of" the last day of the month - i.e. all records where the start date is on or before 1/1/2009, and whose end date is on or after 1/1/2009. Note that my time dimension does go down to the day level (so you could look at a person "as of" the middle of the month, etc. if you're browsing on a day-by-day basis)
I've set up the join between the time dimension and the fact table as a complex join in the physical layer, with a clause like "DIM_DATE.DATE >= FACT.START_DATE AND DIM_DATE.DATE <= FACT.END_DATE". This seems to work perfectly at the day level - I have no problems at all finding the proper records for a person as of any given day.
However, I'm not quite sure how to proceed at the month level. My initial thought is:
a) create a new LTS for the fact table at the month level
b) in the new LTS, add the join to the time dimension
c) in the new LTS, add a where clause similar to LAST_DAY_IND = 'Y' (true for the last day of each month).
Is this the proper way to do this?
Thanks in advance!
Scott

Hi Scott,
I think you're on the right track but I don't think you need the last part. Let me generalize the situation to the following tables
DAILY_FACT (
DAILY_FACT_KEY NUMBER, -- PRIMARY KEY
START_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR START DATE
END_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR END DATE
DAILY_VALUE NUMBER); -- FACT MEASURE
MONTHLY_FACT(
MONTHLY_FACT_KEY NUMBER, -- PRIMARY KEY
MONTH_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION, POPULATED WITH THE KEY TO THE LAST DAY OF THE MONTH
MONTHLY_VALUE NUMBER); -- FACT MEASURE at MONTH LEVEL. DATE_KEY is at END of MONTH
DIM_DATE(
DATE_KEY NUMBER,
DATE_VALUE DATE,
DATE_MONTH VARCHAR2(20),
DATE_YEAR NUMBER(4));
DIM_DATE_END (ALIAS OF DIM_DATE for END_DATE_KEY join)
Step 1)
Make the following three joins in the physical layer:
a. DAILY_FACT.START_DATE_KEY = DIM_DATE.DATE_KEY
b. DAILY_FACT.END_DATE_KEY = DIM_DATE_END.DATE_KEY
C. MONTHLY_FACT.DATE_KEY = DIM_DATE.DATE_KEY
Note: The MONTHLY_FACT DATE_KEY is joined to the same instance of the date dimension as the START_DATE_KEY of the DAILY_FACT table. This is because these are the dates you want to make sure are in the same month.
Step 2)
Create a business model and drag DIM_DATE, DAILY_FACT and DIM_DATE_END into it.
Step 3)
Drag the physical table MONTHLY_FACT into the logical table source of the logical table DAILY_FACT.
Step 4)
Set DAILY_VALUE and MONTHLY_VALUE to be aggregates with a "SUM" aggregation function
Step 5)
Drag all required reporting columns to the Presentation layer.
Step 6)
Create your report using the two different measures from the different fact tables.
Step 7)
Filter the report by the Month that joined to the Start Date/Monthly Date (not the one that joined to the end date).
Step 8)
You're done.
The act of combining the two facts into one logical table allows you to report on them at the same time. The strategy of joining the START_DATE_KEY and the MONTH_DATE_KEY allows you to make sure that the daily measure start date will be in the same month as the monthly fact table.
Hope that helps!
-Joe
Edited by: Joe Bertram on Jan 5, 2010 6:29 PM

Fact table is getting flooded

Similar Messages

Maybe you are looking for