ROW_WID in fact tables.

Hi,
I notice that there are some fact tables with ROW_WID column. Some of the fact tables do not have this column. What is the purpose of having the ROW_WID in fact tables? Does anyone have an idea?
I am using OBIA 7.9.5.
Thanks.
Manoj.

Hi Christian,
The query
SELECT table_name
FROM user_tables
WHERE table_name LIKE '%_F'
MINUS
SELECT table_name
FROM user_tab_columns
WHERE table_name IN (SELECT table_name
FROM user_tables
WHERE table_name LIKE '%_F')
AND column_name = 'ROW_WID';
returned the following tables.
W_ACCT_BUDGET_F
W_ACD_EVENT_F
W_AP_BALANCE_F
W_AP_XACT_F
W_AR_BALANCE_F
W_AR_XACT_F
W_BOM_ITEM_F
W_CNTCT_CNTR_BNCHMRK_TGT_F
W_CNTCT_CNTR_PERF_F
W_CUSTOMER_COST_LINE_F
W_CUSTOMER_STATUS_HIST_F
W_EMPLOYEE_DAILY_SNP_F
W_EMPLOYEE_EVENT_F
W_EMPLOYEE_MONTHLY_SNP_F
W_EXPENSE_F
W_GL_BALANCE_F
W_GL_COGS_F
W_GL_OTHER_F
W_GL_REVN_F
W_INVENTORY_DAILY_BAL_F
W_INVENTORY_MONTHLY_BAL_F
W_IVR_NAV_HIST_F
W_PRODUCT_COST_LINE_F
W_PRODUCT_XACT_F
W_PURCH_COST_F
W_PURCH_CYCLE_LINE_F
W_PURCH_ORDER_F
W_PURCH_RCPT_F
W_PURCH_RQSTN_LINE_F
W_PURCH_RQSTN_STATUS_F
W_PURCH_SCHEDULE_LINE_F
W_REP_ACTIVITY_F
W_RQSTN_LINE_COST_F
W_SALES_BACKLOG_HISTORY_F
W_SALES_BACKLOG_LINE_F
W_SALES_BOOKING_LINE_F
W_SALES_CYCLE_LINE_F
W_SALES_INVOICE_LINE_F
W_SALES_PICK_LINE_F
W_TAX_XACT_F
Regards,
Manoj.

Similar Messages

About Fact Tables and Image Tables

Not sure, if this is correct forum for Oracle BI 10.x EE, but still
I couldn't find another forum, quickly, hence posting here.
Pardon me.
Here is the main Q's
I need little help.
Our company is implementing Oracle BI 10.x. We don't have much experience in Siebel Analytics/OBI.
We have few fact tables e.g. W_XXXX_F, which we need/wish to extend. We are not sure about which methodology we should implement. When we talked with few SA experts they mentioned we need to extend based on ROW_WID. Well, this column doesn't exists anymore in many fact tables, so currently we are thinking of creating ROW_WID on this F table manually and then create WC_XXXX_FX and take these two tables in physical layer of RPD.
Additially, we need to create few Informatica mappings, again SA experts pointed out to use Image tables. Our data source is Oracle Applications, I don't have much idea about Image tables, but clearly there is not S_ETL_I_IMGAGe or so tables in Oracle Apps
Please guide us as how to proceed on these two issues.
Rajat

Not sure, if this is correct forum for Oracle BI 10.x EE, but still
I couldn't find another forum, quickly, hence posting here.
Pardon me.
Here is the main Q's
I need little help.
Our company is implementing Oracle BI 10.x. We don't have much experience in Siebel Analytics/OBI.
We have few fact tables e.g. W_XXXX_F, which we need/wish to extend. We are not sure about which methodology we should implement. When we talked with few SA experts they mentioned we need to extend based on ROW_WID. Well, this column doesn't exists anymore in many fact tables, so currently we are thinking of creating ROW_WID on this F table manually and then create WC_XXXX_FX and take these two tables in physical layer of RPD.
Additially, we need to create few Informatica mappings, again SA experts pointed out to use Image tables. Our data source is Oracle Applications, I don't have much idea about Image tables, but clearly there is not S_ETL_I_IMGAGe or so tables in Oracle Apps
Please guide us as how to proceed on these two issues.
Rajat

Re Joining two fact tables.

Hi Experts,
We have a requirement for a report to display columns from two different fact table.
We have a Order Table W_ORDER_D dimension table,a Order item table W_ORDERITEM_F fact table & a INVOICE table W_INVOICE_F fact table.
The requirent is that Order attribute information such as Order Id & order number is coming from the W_ORDER_D dimension table,The Quantity requested is coming from the W_ORDERITEM_F fact table & the Quantity Invoiced is coming from the W_INVOICE_F fact table.
When we display such a report the report is displaying the OrderID,ORDERNUM,Quantity Invoiced,but the Quantity requested is coming as blank.
and the following query is getting fired at the back end.
select distinct T536200.QTY as c1,
T31759.INTEGRATION_ID as c2,
T31759.ORDER_NUM as c3
from
W_ORDER_D T31759 / Dim_W_ORDER_D */ ,*
W_INVOICE_F T536200 / Fact_W_INVOICE_F */*
where ( T31759.ROW_WID = T536200.ORDER_WID and (T31759.ORDER_NUM in ('1-10016611', '1-10017512', '1-10019361')) ) )
if you go through the query it is not picking the W_ORDERITEM_F fact table,but there are joins dified in the RPD between the W_ORDER_D & W_ORDERITEM_F table & the W_ORDER_D & W_INVOICE_F TABLE.
Kindly suggest on the same.
Thanks & Regards,

Hi Goran,
Thanks for your response I've already set the Order Logical Level to Order Detail.
Actually we have imported a new table in the repository W_INVOICE_F & defined the relationships between Various dimensions.One of the Dim is Order.
My Question is that if Order is the common dimension between both the fact table W_ORDERITEM_F & W_INVOICE_F,then the Answers Result should display columns from both the Fact table based on the Concept of confirmed dimension..right??
Please let me know if any other setting is required to define a dimension as confirmed dimension??
We are using the Core business model
Thanks & Regards,

How to update a fact table when a dimension table is reloaded

We have implemented BI Apps 796. Insertion into W_EMPLOYEE_D table which stores all the employee information had stopped one year back as some company security policy restricted the informatica worklfows to pick up the data. (PER_ALL_PEOPLE_F was a HRMS table and it contained sensitive information line SSN and salary, was inaccessible to the user which informatica uses and the SDE mapping used to return 0 rows).
Now we have the approval to see those rows and the dimension table is loaded with some 100 new employees who joined in last one year.
The ROW_WID of W_EMPLOYEE_D is referenced in lot of fact tables and for all those missing employees the WID in the fact table is 0.
Now that we have all employees, how to make the FACT table point to the correct WID and not store 0. Has anyone faced this problem before?? Writing an update statement will be a tedious task as there are so many fact tables that join to w_employee_d. Also our company uses Sales, Procurement, Finance modules of OB Apps (which constitutes atleast 20 fact tables)
Any guidance is appreciated. Thanks in advance

Hello Kostis,
thank you for your answer. I don't fully understand you. Can you show me short example, please? I create alias table for time dimension on Physical Layer - original table is TimeDayDim and I create aliases TimeDayDim1, TimeDayDim2, TimeDayDim3, TimeDayDim4. Then I create foreign key Fact.Time1 -> TimeDayDim1, Fact.Time2 -> TimeDayDim2, Fact.Time3 -> TimeDayDim3, Fact.Time4 -> TimeDayDim4. And what now? Must I create these table api Bussines Model and create new time dimensions at bussiness model????
I need in Answers ONE Time dimension. I think I must split my fact table to four tables ... (time1, place1 ...) (time2, place2 ...) (time3 place3...) (time4 place4...) then link those tables to Time dimension (but I dont know where I can split those tables - on Physical Layer or on Bussines Layer).
I suppose that I will have in Answers one time dimension and four facts tables and I will be able to query them. (for example: Time.Days, Fact1.Place1, Fact3.Speed, Fact4.Count Criteria: Time.Year = 2008)
Best Regards Vlada

Self join with fact table in Obie 10G

I am a newbie to obiee.I have a development requirement as follows-
I need to find supervisors designation with the existing star RPD design. explanation is below
                                                    DIM_Designation(Desig_Wid)
                                                  |(Row_wid)
                                                  |
DIM_EMPLOYEE--------WORKER_FACT------------DIM_Supervisor
(Row_Wid)-----------------(Employee_Wid)
                                  (Supervisor_Wid)------------(Row_Wid)
3 dimension is joined to fact to get employee, his supervisor and designation of employee. now i want to get the supervisor's designation? how is it possible? already employee and supervisor dimension is same W_employee_d table joined with fact as alias DIM_EMPLOYEE and DIM_SUPERVISOR. how to do self join with fact to get supervisor's designation. i do not have any supervisor_desig_wid in fact table. any help is deeply appreciated.

Yes,Duplicate the fact table create a primary key on the newly fact table alias dimension table.So you can ur data modelling as usual.

Partitioning Fact Tables -- experiences, notes, documentation

I have gone through section 3.8 of the OBIA Installation and Configuration Guide -- "Partitioning Guidelines for Large Fact Tables".
Frankly, I find that documentation inadequate and using a poor example.
I am looking at partitioning W_GL_BALANCE_F . In this table, BALANCE_DT_WID seems to be a Partitioning Key. With 24 months data and only Month-End balances I have only 24 distinct keys. Therefore, this would be a LIST PARTITIONING Key.
I can and have rebuilt the table as a partitioned table. And am proceeding with the DAC changes as per the documentation. However, I am looking for real world implementations, documentations, notes, experiences.
Hemant K Chitale

Thanks.
Information like BUs, Companies, Ledgers etc from the source Financials systems are Dimensions when extracted. So they go into W_INT_ORG_D and W_LEDGER_D (for example) and the ROW_WIDs generated for the ORG_NAME and LEDGER_NAME is the join key to the Fact table (W_GL_BALANCE_F). So these might be partition keys but we'd have to identify the generated values (ROW_IDs becoming COMPANY_ORG_WID and LEDGER_WID) before defining the partition keys. That can be done only after the data is loaded ?.
How did you partition by BU ?
Hemant K Chitale

OOTB Fact table contains Employee detailed Dates

Hi Experts,
we Have 4 date columns (pos_entry_dt, grade_entry_dt etc) in HR Fact out of Box fact table(W_WRKFC_EVT_MONTH_F_SNAPSHOT) which are not populated into presentation layer or BMM Layer and is not linked with day dimension. but the dates are needed when users want detailed level reports. as i know, we can not populate dates directly because BI Server assumes them as facts. i tried to created a separate table with only four columns and achieve this...but it will not work as duplicates will come into picture.
what will be the best way to populate this into Presentation layer
is it okay to populate them from Fact table itself? or its good to create as separate dimension
Thanks
Kumar

Hi Turri
thank you
I Can not create a join with day dimension because there is no key from fact table that can explicitly make a join with Day dimension to get this column from DAY Dimension table. its all out of box and if i have to create a key its a lot customization
for example:
I have
event_month_wid and job_entry_dt in fact table
200704     22-DEC-00
200705     22-DEC-00
200710     22-DEC-00
200711     22-DEC-00
200805     22-DEC-00
200806     22-DEC-00
200807     22-DEC-00
200810     01-OCT-08
200811     01-OCT-08
200812     01-OCT-08
200901     01-OCT-08
200902     01-OCT-08
200907     01-OCT-08
and in Day dimension table
ROW_WID CALENDER DATE
20090720     20-JUL-09
20090719     19-JUL-09
20090718     18-JUL-09
20090717     17-JUL-09
20090716     16-JUL-09
20090715     15-JUL-09
20090714     14-JUL-09
if i make join between them, i will get different dates
Please suggest any ideas?
Thank you
Kumar

"AP Transactions" Subject Area hitting incorrect Fact table

Hi Gurus,
Requirement/Background:
We have done some customization to "Financials - AP Transactions" subject area i.e. adding 3 new W_DAY_D aliases in physical layer and few custom columns in W_AP_XACT_F.
I did not create any new BMM tables for new W_DAY_D aliases, just added these new tables in LTS (Fact_W_AP_XACT_F) under "Dim - AP Transaction Details", and put all the custom columns under same Logical table i.e."Dim - AP Transaction Details" mapping correctly to W_DAY_D and W_AP_XACT_F.
Problem Statement :
Whenever I add "Purchase Invoice Number" to the query, it hits incorrect fact table i.e.W_AP_AGING_INVOICE_A and gives incorrect results.
Expected Query : (if I select GL Account Number, Purchase Invoice Number & AP Amount)
select sum(T333486.AP_LOC_AMT * -1) as c1,
               sum(T333486.AP_DOC_AMT * T333486.GLOBAL1_EXCHANGE_RATE * -1) as c2,
               T333486.PURCH_INVOICE_NUM as c3,
               T334337.GL_ACCOUNT_NUM as c4
          from
               W_AP_XACT_F T333486 /* Fact_W_AP_XACT_F */ ,
               W_GL_ACCOUNT_D T334337 /* Dim_W_GL_ACCOUNT_D */
          where ( T333486.GL_ACCOUNT_WID = T334337.ROW_WID and T333486.PURCH_INVOICE_NUM = '1161/13 CH' and T333486.DELETE_FLG = 'N' )
          group by T333486.PURCH_INVOICE_NUM, T334337.GL_ACCOUNT_NUM
Current Query it is firing :
select sum(T333486.AP_LOC_AMT * -1) as c1,
               sum(T333486.AP_DOC_AMT * T333486.GLOBAL1_EXCHANGE_RATE * -1) as c2,
               T348360.PURCH_INVOICE_NUM as c3,
               T334337.GL_ACCOUNT_NUM as c4
          from
               W_AP_XACT_F T333486 /* Fact_W_AP_XACT_F */ ,
               W_GL_ACCOUNT_D T334337 /* Dim_W_GL_ACCOUNT_D */ ,
               W_SUPPLIER_ACCOUNT_D T336997 /* Dim_W_SUPPLIER_ACCOUNT_D */ ,
               W_STATUS_D T338711 /* Dim_W_STATUS_D_Generic */ ,
               W_XACT_TYPE_D T338741 /* Dim_W_XACT_TYPE_D_Financials */ ,
               W_DAY_D T344857 /* Dim_W_DAY_D_Payment_Due_Date */ ,
               W_DAY_D T348434 /* Dim_W_DAY_D_Purchase Invoice Date */ ,
               W_DAY_D T351452 /* Dim_W_DAY_D_Purchase Invoice Cleared_Date */ ,
               W_PAYMENT_METHOD_D T394960 /* Dim_W_PAYMENT_METHOD_D_AP */ ,
               W_XACT_SOURCE_D T394984 /* Dim_W_XACT_SOURCE_D */ ,
               W_AP_AGING_INVOICE_A T348360 /* Fact_W_AP_AGING_INVOICE_A */
          where ( T333486.GL_ACCOUNT_WID = T334337.ROW_WID and T333486.SPLR_ACCT_WID = T336997.ROW_WID and T333486.DOC_TYPE_WID = T338741.ROW_WID and T333486.DOC_STATUS_WID = T338711.ROW_WID and T333486.INVOICED_ON_DT_WID = T348434.ROW_WID and T333486.PAY_METHOD_WID = T394960.ROW_WID and T333486.CLEARED_ON_DT_WID = T351452.ROW_WID and T333486.PAYMENT_DUE_DT_WID = T344857.ROW_WID and T333486.SOURCE_WID = T394984.ROW_WID and T333486.DELETE_FLG = 'N' and T344857.ROW_WID = T348360.PAYMENT_DUE_DT_WID and T336997.ROW_WID = T348360.SPLR_ACCT_WID and T338711.ROW_WID = T348360.DOC_STATUS_WID and T338741.ROW_WID = T348360.DOC_TYPE_WID and T348360.PURCH_INVOICE_NUM = '1161/13 CH' and T348360.PAYMENT_METHOD_WID = T394960.ROW_WID and T348360.INVOICED_ON_DT_WID = T348434.ROW_WID and T348360.CLEARED_ON_DT_WID = T351452.ROW_WID and T348360.SOURCE_WID = T394984.ROW_WID )
          group by T334337.GL_ACCOUNT_NUM, T348360.PURCH_INVOICE_NUM
"Purchase Invoice Number" is out-of-box present under "Dim - AP Transaction Details" and it is mapped to 4 tables including W_AP_XACT_F & W_AP_AGING_INVOICE_A. It is also set at Detail level in AP Transactions dimension hierarchy.
Additionally, implicit fact column has also been set. So why it is not hitting W_AP_XACT_F ???
Thanks in advance.
Regards,
Ravi Desai

You said that the Logical table Date- dim has 2 LTS (Date_dim, Event_closed_date_dim ).
How you defined this, is it something like
1) Drag table Date_dim
2) Select the column Row_wid of Event_closed_date_dim from Physical layer and drop on Row_wid of Logical tabl Date_dim
With this logical column Row_wid 2 sources. In this case you see 1 logical join between logical table day(with 2 LTS) and fact
If you followed this way should not have any issues.
Joins like:
PL-: Date_dim--->Fact<-- Event_closed_date_dim
BMM: Date->Fact
If you have any doubts, just create a new rpd with these table objects
Check your configuration.

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

Parent member values in Fact tables

Hello,
I want to understand something, as far as I know, we can only send data to base level members, right ?
Then how come we find rows of data that have parent member values in the Fact tables ? (assuming we do not play manually with the database of course), I thought that this can be due to an import with the data manager, can this be right ?

nilanjan chatterjee wrote:
Hi,
>
> The data for the parent members should be available in the SQL tables.
> For example, 2011.TOTAL is parent member. You should not have any data for this member in your database. If it is there, it might have come somehow (may be an import). But this is not right. You might want to remove these records. But be sure that you dont delete the records for the base level members.
>
> Hope this helps.
I guess you meant should not, right ?

Null key in fact tables

Hi all,
I have one role play dimension with some null key in fact table, I liked know if it's a good practice?
thanks

Depends on what you actually mean..
When one dimension column contains NULL in your fact table, then it's normally a bad practice. Create a entry in your dimension table to represent this state.
The problem is that NULL is a state, which means does missing or inapplicable information. This means that the row in the fact table is semantically meaningless. Cause your fact table is no longer additive over this dimension.

Help on Setting logical Levels in Fact tables and on Dimension tables

Hi all
Can any body provide any blogs or any king of material on what exactly is levelling .
Like after creating the Dimensional hierarchies we need to set the logical levels for the LTS of fact tabels ri8 .So what is the difference between setting logical levels to fact tabels and also Setting levelling on Dimension tables .
Any kind of help is appreciated
Thanks
Xavier.
Edited by: Xavier on Aug 4, 2011 10:50 AM

I have read these blogs ,but what my question is
Setting the logical levels in LTS of Fact tables i understood .
But we can also set the logical levels for dimensions also ri8 .I didn't understand why do we set the logical levels for dimensions .Is there any reason why we go with the levelling at dimensions
Thanks
Xavier
Edited by: Xavier on Aug 4, 2011 2:03 PM
Edited by: Xavier on Aug 4, 2011 2:32 PM

Logical level for logical fact table sources

it is clear that for fact aggregates, we should use the Content tab of the Logical Table Source dialog to assign the correct logical level to each dimension.
question is : is it mandatory to assign even for non-aggregates fact tables the logical level for each dimension (which normally should be set to the most detailed level of each dimension) ? is it any known issue if "logical levels"in content tab are not set ?
the reason I'm asking this is a strange bug I have (I'm not going to discuss it here) and then only workaround seems to be NOT setting the logical levels (on content tab) for logical fact table sources.
thank you !

If levels are not set: By default levels are considered as lowest level
It should not matter if you set or not
Generally we set for facts explicitly when we are using Aggregate tables.
Your current issue might be a case by case; I would suggest to check implicit fact, any table mapped to the source to force a join etc
Mark if helps
Let me know how it helps
Edited by: Srini VEERAVALLI on Feb 5, 2013 8:33 AM
Any updates on this?+_
Edited by: Srini VEERAVALLI on Feb 14, 2013 9:09 AM

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

Content tab for a fact table

Hi
Please , help me in knowing the use of content tab for a fact table in the repository in OBIEE.
Thanks.

if you have multiple LTS then you should set the content level approprately otherwise you can get errors during consistency checks.not able to find any link which talks only about content level.see these links and let us know if you have any doubts
http://kr.forums.oracle.com/forums/thread.jspa?threadID=604637
Content tab is also handy when you are using aggregate tables.
Regards,
Sandeep

ROW_WID in fact tables.

Similar Messages

Maybe you are looking for