Fact table

Hi Experts,
1.I have a question like for better performance should we use two fact tables or one fact table? ( I have two fact tables but let me know if i should use only one fact table by joining the other
Logical table source)
2. I have a detailed report to show with million records what should i do for the better performance.
PS: This report is detailed so there is nothing to Aggregate.( I am using 10.3.4.1 version)
Thanks in Advance.
chak.
Edited by: 884679 on Sep 12, 2011 9:20 AM
Edited by: 884679 on Sep 12, 2011 9:21 AM

As a best practice, create 2 Logical Table in BMM with single LTS pointing to each fact table in physical. Couple of benefits:
- when a measure is used in report, BI server easily identifies relevant Logical Table and LTS and corresponding Physical Table
- when both measures are used then each LTS from individual LT will come into picture
- for future cases you don't need to apply fragmentation to force BI server to pick one of two LTS when single LT with 2 LTS is used
- BI server will give better and optimized query
There are many used cases for this ...So, better go for 2 LT with Single LTS each.
Hope its clear

Similar Messages

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

Content Tab: None of the fact tables are compatible with the query request

Hi All,
**One thing I am not clear yet of all my years with OBIEE is working with the content tab in BMM.**
I have made a rpd the joins in physical layer as shown below:
https://picasaweb.google.com/114804305606242416264/OBIEEError#5663056545119428530
And the BMM layer as:
https://picasaweb.google.com/114804305606242416264/OBIEEError#5663056519553812930
Error I am getting when i run a request from the 3 columns from the selected 3 tables is:
Dim - Comment Code Details
Fact - Complaint
Dim - Service Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14020] None of the fact tables are compatible with the query request Sr Num:[DAggr(Fact - Complaint.Sr Num by [ Dim - Service Details.Sr Cat Type Cd, Dim - Comment Code Details.Cmtcode name] )]. (HY000).
I get no error for consistency.. I read everywhere and I know i need to set the appropriate aggregation levels in the various dims and facts LTS properties to help OBIEE understanding our model, but how to do that.. how do i decide... how should I approach, what should be the aggregation level, what details.
When i click More button i see different options: Copy, Copy From, Get Levels, Check Level, what do these mean.
Aggregation Content, group by - Logical Level or Column which one should i choose and how should I decide.
Can anyone explain the Content Tab in details and from scratch with some example and why we get these errors.... I know many people who are well versed with many other things related to RPD but this. A little efforts of explaining from you guys will really be appreciated.
Thanks in advance,
Dev

Hi Deepak,
Option 1:
My tables in physical layer are joined as below:
D1--> F1 <--D2--> F2 <--D3
Same way i model it in BMM
D1--> F1 <-- D2--> F2 <--D3
Here D1 is non Conformed Dimension for F2 and D3 is non Conformed dim for F1. Later create Dimensional hierarchies, I tried setting up the content levels
I go Sources>content tab of Fact F1 I set
Dimensions----------- Logical level
D1---------------------- D1 Detail
D2---------------------- D2 Detail
D3---------------------- D3 Total
then, I go Sources>content tab of Fact F2 I set
Dimensions----------- Logical level
D1---------------------- D1 Total
D2---------------------- D2 Detail
D3---------------------- D3 Detail
Then, I also go in all the dimensions and set their content levels to Details, but it still gives me errors not sure where I am going wrong in setting the content levels.
I need to know whether the way I have modeled it in BMM is right,
Option 2:
I can combine the two facts in a single Logical Fact or the above design should also work.
(F1&F2)<--D1, D2 , D3 joined separately using complex logical joins.
what will be the content tab details?
Thanks,
Dev

OBIEE 11g - No fact table exists at the requested level of detail

My dimesion tables are snow-flake.
Table1 has Key, ProductName, ProductSize, Table2Key
Table2 has Key, ProductDepartment, Table3Key
Table3 has Key, ProductDivision
I have created 2 hierarchies (in same dimension Product). Note: ProductSize is in Table1.
ProductDivision > ProductDepartment > ProductName (shared level)
ProductSize > ProductName (shared level)
There are 2 fact tables
Fact1 is at ProductName level
Fact2 is at ProductDepartment level
When I create a request with columns as ProductSize and some measure; and filter it on ProductDepartment. The request fails with error "No fact table exists at the requested level of detail", but the request can ideally be answered using fact with ProductName level.
I have properly defined logical level keys in the hierarchies and logical level in the LTS (content tab)
Can anyone point me what I am doing wrong here?

Since both fact tables are at same granular level I would suggest to map each other (Signon_A maping Signon_B) in BMM layer logical fact @source.
Considering them as Fact and with fact extension.
BTW: Did you try by setting implicit fact at subject area properties?
Edited by: Srini VEERAVALLI on Feb 1, 2013 9:04 AM

Join two fact tables

Hi,
I have two fact tables F1 and F2 joined with few dimensions D1.....D9. D1,D2 and D3 are conformed dimensions.
In Physical:
F1>--D1,D2,D3,D4,D5,D6
F2>--D1,D2,D3,D7,D8,D9
In Logical:
F1>--D1,D2,D3,D4,D5,D6
F2>--D1,D2,D3,D7,D8,D9
there are some ports already using above star schemas. now I got new requirements and I need to use measures from both the fact tables and conformed and unconformed dimensions.
I did the following in logical
F1 LTS GENERAL TAB ADDED F2,D1,D2,D3,D7,D8,D9 and in content tab set logical level to unconformed dimensions at total level and for conformed dimensios at details level.
F2 LTS GENERAL TAB ADDED F1,D1,D2,D3,D7,D8,D9 and in content tab set logical level to unconformed dimensions at total level and for conformed dimensios at details level.
but I'm still getting
[nQSError: 14026] Unable to navigate requested expression:
Please fix the metadata consistency warnings. (HY000)
I cheked metadata global consistency and no errors found.
Appreciate your help
Thanks
Jay.
Edited by: Jay on Sep 27, 2011 10:14 AM
Edited by: Jay on Sep 27, 2011 10:15 AM

Let me explain my issue again
In Physical:
F1>--D1,D2,D3,D4,D5,D6
F2>--D1,D7
In Logical: Single logical fact Fact_FY_Ratio has two logical sources
LTS1: F1>--D1,D2,D3,D4,D5,D6
LTS2: F2>--D1,D7
Set the content level for each LTS in Fact_FY_Ratio:
F1 to Detail for D1,D2,D3,D4,D5,D6 and to Total for D7
F2 to Detail for D1,D7 and to Total for D2,D3,D4,D5,D6
In LTS 1 general tab added inner joins with all dimensions F1,D1,D2,D3,D4,D5,D6,D7and F2
In LTS 2 general tab added inner joins with all dimensions F2,D1,D7,D2,D3,D4,D5,D6 and F1
And I also did logical complex join for Fact_FY_Ratio with all logical dimensions D1,D2,D3,D4,D5,D6,D7
I'm able to run query using D1,D2,D3,D4,D5,D7,F1,F2 but when I include D6(time dimension) it is causing problem with F2(witth F1 it is working fine).
query success with:
F1,D1,D2,D3,D4,D5,D6
F2,D1,D7
D1,D2,D3,D4,D5,D7,F1,F2
Query failed with:
F2>--D1,D7 and D6
Please let me know anything wrong with above configuration.
Thanks
Jay...
Edited by: Jay on Oct 3, 2011 7:11 AM

No Message: Write to Fact table.

Hi ALL,
Source: ECC 6
Target: BI 7.3
We are Transferring 2LIS_13_VDITM Datasource---->> 0SD_CO3 Infocube .
After Data Replication ,
1. Data Transferred to PSA .
2. During Transformation Creation Manuel Mapping is performed . Activated .
3. During DTP Creation Only Following Warning Messages Occur , Status s not Transferred to Green .
Data is not coming Cube , No Error Messages. (Totally 29000 Records have to transfer to BI Cube)
Warning Messages are,
1.No Message: Write to Fact table.
2.No Message:Infocube Update Completed .
What is the Problem?

Hi,
Have you set the Industroy sector before uploading the set up tables?
For more information refer the note: 353042
Summary
Symptom
Fields BWGEO, BWGEOO, BWGVP, BWGVO, BWNETWR, BWMNG, etc. of DataSources 2LIS_02_SCL, 2LIS_02_ITM, 2LIS_03_BF, 2LIS_03_UM, 2LIS_40_REVAL are not filled.
This may lead to the following:
The system does not perform any update into an InfoCube (for example: 0RT_C*, 0PUR_C01, 0CP_PURC1 and so on), even though data arrives in BW.
This occurs with the following InfoSources:
2LIS_02_SCL, 2LIS_02_ITM
2LIS_03_BF, 2LIS_03_UM
2LIS_40_REVAL
With some restriction, this symptom also occurs with the following InfoSources if they are used in connection with retail or consumer products. (InfoCube: 0RT_* or 0CP_* ).
2LIS_11_VAITM, 2LIS_12_VCITM, 2LIS_13_VDITM
Other terms
0PROCESSKEY, PROCESSKEY, 0RT_C01, 0RT_C02, 0RT_C03, 0RT_C04, BWBRTWR, BWGEO, BWGEOO, BWGVP, BWGVO, BWNETWR, BWMNG
Reason and Prerequisites
The process key (0PROCESSKEY and 0BWAPPLNM) of the InfoSources has not been filled. As a result, no key figures are updated because of the update routine of the participating InfoCube and along with it no records are inserted into the InfoCube. In each update routine, the system checks the content of the PROCESSKEY. If this field has no contents, then no data is written into the InfoCube because of the IF condition in the update rules.
Solution
So that you can work in the above mentioned InfoSources, you MUST activate the determination of the process key. This is done with the help of Transaction MCB_ which you can find in the OLTP IMG for BW (Transaction SBIW) in your attached R/3 source system.
Here you can choose your industry sector. 'Standard' and 'Consumer products' are for R/3 standard customers, whereas 'Retail' is intended for customers with R/3 Retail only.
You can display the characteristics of the process key (R/3 field BWVORG, BW field 0PROCESSKEY) by using Transaction MCB0.
If you have already set up historical data (for example for testing purposes) by using the setup transactions (Statistical Setup Programs) (for example: Purchasing: Tx OLI3BW, material movements: OLI1BW) into the provided setup tables (for example: MC02M_0SCLSETUP, MC03BF0SETUP), you unfortunately have to delete this data (Tx LBWG). After you have chosen the industry sector by using MCB_, perform the setup again, so that the system fills a valid transaction key for each data record generated. Then load this data into your connected BW by using 'Full update' or 'Initialization of the delta process'. Check, whether the system updates data into the involved InfoCubes now.
If all this is not successful, please see Note 315880, and set the application indicator 'BW' to active using Transaction 'BF11'.
Related notes:
157317 --> You MUST make sure that this note is relevant for you.
352344 -> Process key + reversals in Inventory Management
(Consulting note).
Regards,
Anil Kumar Sharma .P

Fact Table index vs BIA Index

BIA gurus..
Prior to our BIA implementation we had the drop and rebuild index process variants in our process chains.
Now after the BIA implementation we have the BIA index roll-up process variant included in the process chain.
Is it still required to have the drop and rebuilt index process variants during data load ?
Do the infocube fact table indexes ever get hit after the BIA implementation ?
Thanks,
Ajay Pathak.

I think you still need the delete/create Index variants as it not only helps in query performance but also speeds up the load to your cubes.
Documentation in Perfomance tab:
"Indices can be deleted before the load process and after the loading is finished be recreated. This accelerates the data loading. However, simultaneous read processes to a cube are negatively influenced: they slow down dramatically. Therefore, this method should only be used if no read processes take place during the data loading."
More details at:
[http://help.sap.com/saphelp_nw70/helpdata/EN/80/1a6473e07211d2acb80000e829fbfe/frameset.htm]

Load fact table with null dimension keys

Dear All,
We have OWB 10g R2 and ROLAP star schema. In our source system some rows don’t have all attributes populated with values (null value), and this empty attributes are dimension (business) keys in star schema. Is it possible to load fact table with such rows (some dimension keys are null) in the OWB mappings? We use cube operator in mappings.
Thanks And Regards
Miran

The dimension should have a row indicating UNKNOWN, this will have a business key outside of the normal range e.g. -999999.
In the mapping the missing business keys can then be NVL'd to -999999.
Cheers
Si

How do I use Derived Table to dynamically choose fact table

How do I use the Derived Table functionality to dynamically choose a fact table?
I am using BO XI R2 querying against Genesys Datamart kept in Oracle 10g. The datamart contains aggregated fact tables at different levels (no_agg, hour, day, week, etc...) I would like to build my universe so that if the end user chooses a parameter to view reports at daily granularity, then the daily fact table is used; choose hourly granularity, then hourly fact table is used, etc....
I tried using dynamic SQL in Oracle Syntax, but Business Obljects Universe didn't like that type of coding.
The tables look something like this:
O_LOB1_NO_AGG o
inner join V_LOB1_NO_AGG v on o.object_id = v.object_id
inner join T_LOB1_NO_AGG t on v.timekey = t.timekey
Likewise, in the 'hour', 'day', 'week', etc... fact tables, the Primary Key to Foreign Key names and relationships are the same. And the columns in each O_, V_, T_ fact table is the same, or very similar (just aggregated at different levels of time).
I was thinking of going a different route and using aggregate aware; but there are many Lines of Business (20+) and multiple time dimensions (7) and I believe aggregate aware would require me to place all relevant tables in the Universe as separate objects, which would create a large Universe with multiple table objects, and not be maintenance-friendly. I also was going to dynamically choose Line of Business (LOB) in the derived tables, based on the end user choosing a parameter for LOB, but that is out-of-scope for my current question. But that information sort of points you down the train of thought I am travelling. Thanks for any help you can provide!

You can create a derived table containing a union like the following:
select a,b,c from DailyFacts where (@prompt('View'....) = 'Daily' and (<rest of your where conditions here if necessary>)
union
(select a,b,c from MonthlyFacts where (@prompt('View'....) = 'Monthly' and (<rest of your where conditions here if necessary>))
union
(select a,b,c from YearlyFacts where (@prompt('View'....) = 'Yearly' and (<rest of your where conditions here if necessary>))
I assume that you are familiar with the @prompt syntax
Regards,
Stratos

Key Figure units in Fact Table - Error

All -
When a run a report off of a cube, some row display 0 when there are corresponding values in my cube. The report doesn't agree with LISTCUBE. I have ran transaction RSRV on my cube and tested the "Key figure units in fact tables of Infocube" and I get an error saying that 1380 units are missing from fact table.
<b>Diagnosis
In the fact table /BIC/FEU_FRCTS records have been found that contain values other than zero for key figures that have units, but that have no value for the unit of the key figure. Since the value of the unit has to correspond to the value of the key figure, this inidicates an error when the data was loaded. The values of the units have not been loaded into BW correctly. Choose Details to display the incorrect records.</b>
Does anyone know what this error means? How do I solve this problem?
Thanks,
Nyrvole

hi Nyrvole,
as the message said, you have keyfigures with unit but the unit value not filled, click 'detail' as suggested to check which keyfigure(s) involved, that go to rsd2 type in that keyfigure and see which infoobject unit is used, then check transfer/update rules how this unit infoobject mapped, try correct the values and upload again.
there is option 'repair' in rsrv but think in this case it can't fix the error, just try.
hope this helps.

Fact table

Similar Messages

Maybe you are looking for