Dynamic fact table choice

Hi Experts,
Is there any way to model the following in obiee:
I have multiple fact tables:
Fact_ABC
Fact_BCD
Fact_DEF
and depending on the value that the user selects on the dimension table (dim_types) the BI server has to pick the corresponding the fact table.
If the users selects the value ABC from the dimension the fact that should be used is Fact_ABC and the same for the other values.
Any idea??
Regards

hi,
Ok,we can do this using fragmentation as our friends said
http://obieetalk.com/fragmentation-obiee
Can I ask what's the reason of that question? is it performance related?Not sure,its based on the data that u have and tables that ur using ,because if u observe the query it is firing while using fragmentation in above example you will came to know about.That's why i asked no.of tables
thanks,
Saichand.v

Similar Messages

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

Users selecting "All Choices" on columns in fact table

We have a dimensionalised data structure in our Oracle DW and the fact table contains 750million rows. I'm finding the users are selecting a column in the fact table to filter on, and selecting the "All Choices" option. This then runs an SQL like:
select distinct(column_name) from column_table
Which kills the DW server.
Does anyone know of a way of stopping this? to only allow the All Choices option on one of the dimension tables?
Oracle 11g
BI 10.1.3.4.1
both on Redhat LINUX
Thanks in advance.

Thanks to all for advice/suggestions. In the end I resolved this ( rather a brute force method ) by hacking adjusting one of the XML message documents, standardviewtemplates.xml, that I'd copied into the customMessages directory.
Its a real shame as it removes that function for all users on every table, but some users keep selecting the "All Choices" option even after being told not to.

Dynamic Bands on Fact Table measure

I'm trying to create income bands on my fact table, not sure how to go about it or if its possible.
I have a fact table that consists of
Date, TranType, AdvKey, AdvGrpKey, Amount
Each Adviser belongs to an AdvGrp.
I want to be able to group on AdvKey or AdvGrpKey and have the summed amounts (income) allocated to income bands.
So when I group on Adviser, they will be assigned an income band, ie 0-10k, 10-50k, 50-100k, same applies when the grouping is changed to the Group Level.
The facttable has about 2 million rows.
The income is how much is generated from the advisers and adviser group, so this will change over time.
Can this be done and can it be done dynamically.
I can't think of any way to do it with a dimension, as there is no way to link back to the fact table.
Any ideas on how to solve this would be much appreciated.
Thanks
Jon

Hi Richard,
Thanks for taking the time to respond to my query.
I'm struggling to work out what your query is doing, and how to use it.
So I took your query and replaced bits of it with my data, however the output is not as expected.
While I try to work out what is going on, I'm hoping you happen to read this first, and might be so kind as to throw me a few pointers.
I tweaked my fact table to only have AdvKey now. The parent child relationship is in the DimIFADetails now, which is the Advisor Group level and the Adviser level. The query below is looking at the Advisor Group level.
with
member measures.NewAmount as Measures.Amount * -1
member measures.WTH as (MyGroups.item(Measures.r),Measures.MyRange)
member measures.MyRange as
cstr(round(Measures.NewAmount/10000,0)*10000)+"-"+cstr(round(Measures.NewAmount/1000+1,0)*10000-1)
set MyGroups as
Order(nonempty([Dim IFA Details].[Parent Key].[Adviser Group], Measures.NewAmount)
,Measures.MyRange, BASC)
member measures.r as rank([Dim IFA Details].[Parent Key], MyGroups)
member measures.RangeTot as iif((MyGroups.item(Measures.r-2),Measures.MyRange) = Measures.MyRange ,
Measures.NewAmount +(Measures.RangeTot,MyGroups.item(Measures.r-2)),
Measures.NewAmount)
member Measures.RangeTotal as
iif((MyGroups.item(Measures.r),Measures.MyRange)=Measures.MyRange,
null,Measures.RangeTot)
select {Measures.MyRange,Measures.RangeTotal
, measures.newamount, measures.r, measures.WTH
} on 0,
nonempty(MyGroups,Measures.RangeTotal) on 1
from
[Income and Emails Cube]
My Amount field is negative and shouldnt be so I added a new measure to deal with it now.
Below are the results I am getting
New amount is the summed amount of my adviser groups, the value I wish to put in bands.
The new amount falls in the correct MyRange, so thats good.
But its generating too many MyRange values ie the first six rows and fall into the first MyRange.
Not sure what is going on with RangeTotal.
I put up the other columns hoping it might shed some light, but at this point, I'm a little lost.
I want to be able to switch between showing Advisers and Adviser Groups, and display the bands.
I'm hoping you might hand hold me through this.
Regards
Jon

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 table enriched with hierachy information

Hi Guys,
I have a fact table design question.
The fact data table (oracle10g) on bottom level RelationshipManager (RM) contains the data columns
for the RM dimension:
FACT TABLE
ID¦RM¦DEPARTMENT¦AGENCY¦REGION¦SALES
1---23--Bronx------------NY---------US-------23232
2---24 ---------------------NY---------US-------87878
3---25-----------------------------------US------ 9999999
This means the fact has been enriched with hierachy information, this is not whats usually done.
Why have I done it? Because the RM is not necessarily always part of a department BUT can also
be directly placed under an agency or a region (agency or region leads).
Have I made the right choice by chosing to enrich the fact table? I could have also build a snow flake
schema by storing hierachy information in a seperate table.
Thanks.

with your problem, it might be best to split the dimension into multiple dimensions or multiple attribute dimensions with default values where you do not have a value for example set up RM with a N0_RM and when you don't have data load it there. If I'm looking at this correctly, the problem it appears you have is you have an inconsistent hierarchy. where the rollups can change. having them in the same dimesion would be problematic. If therewere consistancy then you could add members into a single hierarchy something like
US
--No_State
--NY
-----Bronx
------RM23
------No_RM
but from your example I don't see it. If they are seperate dimensions(not attribute dimensions) then you could load based on date. If they are attribute dimensions, then look at varying attributes

Dimension values without data in a fact table

I have an ODS system and a Data warehouse system
I have a Sales fact table in the ODS system and I have these fields:
SALES
ID_CUSTOMER (PK),
ID_MODEL (PK),
ID_TIME (PK),
SALES,
QUANT_ART,
COST
Then in some records in the fields ID_Time or ID_Model or ID_Customer I donât have values (NULL) because in the transactional systems these record donât have values (NULL).
The users want to generate aggregate reports with the Sales table...
The question is:
I have to put a âdummyâ value in the dimensions Customer, Model and Time (for example â0â) and put this value in the fact table if the dimensions fields have NULL values????
Or I have to leave the NULL values?
What is the best choice? Why?

There's often some specific reason why these values don't exist, such as the record being a manual adjustment to sales (for example a journal voucher). In these cases it can be helpful to have a flag column to indicate this, so that when a user comes across a bunch of sales with a Store Name of "Unknown" or "Not Applicable" they can also look at the reason for this unusual entry.

[nQSError: 14025] No fact table exists at the requested level of detail:

Hi All,
I am using OBIEE 11.1.1.6.8.
I have below senario...My fact table contains 3 LTS(yearly, Monthly, Weekly) and TimeDim contains3 LTSs(yearly, Monthly, Weekly)
Fact-Weekly joins with (D1,D2,D3) & TimeDimWeekly
Fact-Monthly joins with (D1,D2,D3) & TimeDimMonthly
Fact-Yearly joins with (D1,D2,D3) & TimeDimYearly
I hv also set the Fact source content to appropriate level of TimeDIM and details level of other Dimensions.
when i build a report using only year_code or month_code_or week_code as filter the query is going to appropriate physical sources
ie. if i take week_code as filter then the query firing to FactWeek, TimeDimWeekly & other Dimensions
if i take Month_code as filter then the query firing to FactMonthk, TimeDimMonthly & other Dimensions
Problem is when I use dynamic filter its is giving [nQSError: 14025] No fact table exists at the requested level of detail: error.
My filter is something like this using presentation variable pvTime (filter is prompted)
case '@{pvTime}'
when 'Weekly' Then "Calendar"."Week - WYYYY"
when 'Monthly' Then "Calendar"."Month - MONYYYY"
when 'Yearly' Then "Calendar"."Year ID" end
Please help me if I missed any step
Thanks
Smita

Its a guess but try the below.. As you are using the CASE statement in your filter, use it in the below way.
Store the value that is prompted into a presentation Variable
YOUR WAY
case '@{pvTime}'
when 'Weekly' Then "Calendar"."Week - WYYYY"
when 'Monthly' Then "Calendar"."Month - MONYYYY"
when 'Yearly' Then "Calendar"."Year ID" end
SUGGESTED WAY
(case '@{pvTime}'='Weekly' and "Calendar"."Week - WYYYY" = '@{new PV}' THEN 1
when '@{pvTime}'='Monthly' and "Calendar"."Month - MONYYYY" = '@{new PV}' THEN 1
when '@{pvTime}'='Yearly' and "Calendar"."Year ID" = '@{new PV}' THEN 1 ELSE 0 END) =1
This might correct the way your are using your CASE statement in Filters..

Problem: two fact tables and one conformed dimension

Hi everyone!
I need to solve this situation:
I have two fact tables, let's say F1 and F2, that are both linked to D1, my conformed dimension
I just need to select fields from D1 but I know that, when querying, OBIEE links it to a fact table anyway..how does it choose the fact table? That is, if I only want fields from D1, does the system queries also from F1 or F2? Is it a random choice?
Is there a way to "force" this choice, telling the system for example to choose only from F1?
Is there a workaround to solve this situation? Remember, I only need fields from D1.
Thanks!!

The solution of your problem is "Implict Fact Column"
Go to presentation layer and double click on your subject area. then you will see Implict fact column option. click on set. give corresponding fact column there( in your case give F1 fact column)
references: http://oracle-bi.siebelunleashed.com/articles/implicit-fact-column/
Thanks
GSR
Edited by: GSR on Mar 20, 2012 3:22 PM

What is the fact table content?

a. Key figure for a combination of char value of dimensions are stored in the fact table
b. Both cumulatiove and also key figure for non cumulative values can be contained in fact table
Choose any one
Thanks
Babu

Hi,
Fact table contains the data (key figs) for a certain combination of characteristic values of the dimension tbls to help a business person evaluate their company & make appropriate decisions.
=> a. from the choice you had.
Rgds,
Colum
Was this information helpful to you Babu?
If so, please award points as appropriate.
thanks
Edited by: Colum Cronin on Apr 7, 2010 10:11 AM

Setting a Filter on a dynamically created Table

Hi All,
I am currently working on a Database to automatize some process. Quick explanation:
The User can import a CSV (Text) File via a DialogBox, which gets imported into a Table. After this, the content has to be filtered, setting conditions on 4 different rows. The new Table gets exported into a new CSV (It has to be CSV, since it later gets imported
into SAP)
I am having some trouble with filters though:
How can I set a Filter on a dynamically created Table (using VBA)?
Best case would be to save the filter into my Import spec, but Access doesn't seem to have this option (?)
Can somebody help?
Thanks in advance
Regards
Alex

Thanks for the fast reply! Sorry, I am not really proficient at Access. How do I do a query on a dynamically created Table? Do I have to save the Table into a Variable. Or what's the way to import it?
Hi Alex,
I never use the Import functionality, nor DoCmd.TransferText.
To import data from a csv-file I made my own Import functionality. In fact it is just reading an external file, line by line, and each line field by field using the field separator. In my opinion that is far more versatile than the standard functionality.
But you can use the standard functionality of Access to import a csv-file into a table.
Having the data in a table, you can generate the appropriate query for the output in a VBA procedure:
sql_string = "SELECT Field1, Field2, ... FROM MyTable WHERE Field1 = ... AND Field2 = ... ORDER BY Field3"
and make a recordset of it:
Set cur_set = CurrentDb(sql_string)
The output csv-file is then filled by opening a file for Write, loop through all the records, concatenate for each record all the wanted fields using the field separator, and write the result line to the csv-file.
Most important is to understand this process. After that it should be possible to build it. And if you have further questions, just ask.
Imb.

HOW CAN I HAVE DUMMY FACT TABLES IN ONE UNION REPORT

Hello developers,
So, I am trying to have a report from 4 different subject areas. Each of these have transaction numbers under Fact-table. B’se these fact tables are under different subject area I can’t have them in one report, (fact table has to be a one to many relationship and not otherwise). How do I make sure I end up with a transaction number from atleast 1 subject area and ignore the other ones or avoid the error
Also in addition, I have to have the last 4 digits of the credit card number which is located in only one of those 4 subject area. How do I make sure its included with my final report eventhough its not in other subject areas? Please please help I am still new in this business
thanks in advance
Chuck

You got two choices:
A. Use OBIEE:
1) Create a OBIEE logical SQL like
SELECT A.s0 field1, C.s2 field2, A.s1 Measure1, B.s1 Measure2, C.s1 Measure3
FROM
(Select "Txn Attributes"."Transaction Number" s0, Measure.Measure1 s1 FROM "Subject Area 1") A,
(Select "Txn Attributes"."Transaction Number" s0, Measure.Measure2 s1 FROM "Subject Area 2") B,
(Select "Txn Attributes"."Transaction Number" s0, Credit."Last 4 digits" s2, Measure.Measure3 s1 FROM "Subject Area 3")
WHERE A.s0 = B.s0
AND B.s0 = C.s0
2) Test this SQL from "Issue SQL" section in answers.
3) Once tested, open a new analysis, go to Advanced tab and put this tested logical SQL in the SQL section and apply it. If you come back to criteria tab, you will see 5 fields are created for you.
This is technically feasible. Pulling this off is hard and this is a maintenance nightmare.
Since you are self-proclaimed newbie, I would suggest you take the alternative: fixing it through ETL. Create a new fact and write an ETL job to load this fact from other facts and dimensions. Then model it in RPD. This is more work but if you mess something up in the process of implementing first option, you may need to apply nearly same effort to fix that. Choice is yours.

Performance - DIM and FACT tables

Experts,
I have performance issues where my DIM tables are bigger than the FACT tables by 50 %.
Can any one please let me know what should be done in order to solve this issue
I have already done below steps
1)Kept the small dimensions together
2)kept the line item dimensions wherever needed
3)Grouped related characteristics into one dimension only
4)Removed high cardinality dimensions
pls help
thanks in advance

Often, not much thought is given to the dissemination of characteristics to dimensions. Dimension tables, however, have a huge impact on InfoCube performance. The star schema design works best when the database can assume minimal records in the dimension tables and larger volumes in the fact table.
Rationale : -
Each dimension should be of approximately equal size and that the file size of each dimension should not make up more than 10 percent of the associated fact table. The dimensions must also support growth.
You should make every attempt to split up the most dynamic characteristics so they do not exist in the same dimension. This ensures that the system does not create too many entries in a dimension table.
Example : Order data is loaded into BW with the dynamic characteristics customer and material. If these InfoObjects were to be placed together in the same dimension, it poses a problem for the system because a new dimension record would be created each time the combination of customer or material changed. This would make the dimension very large in relation to the fact table.
When one dimension grows very large in relation to the fact table, it makes it difficult for the database optimizer to choose an efficient path to the data, because the guideline of each dimension having less than 10 percent of the fact tables records has been violated. This condition of having a large volume of data growth in a dimension is known as degenerative dimension.
In the data modeling phase, it is very important to determine if a dimension table will be degenerated, and then explicitly set it as a line item dimension
The best way to fix a degenerative dimension is to move the offending characteristics to different dimensions
Line-item dimensions arise in nearly every case where the granularity of the fact table represents an actual working document like an order number, invoice number, sequence number.. This can only be accomplished if no data is in the InfoCube. If data is present, however, a dump and reload is required. This underscores the point that the data modeling decisions need to be well thought out during the initial implementation to avoid a dump and reload of data.
Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes
This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.
Recommendation: -
Try to limit the number of records in the dimension tables. Use the following guidelines:
1. If an InfoObject has almost as many distinct values as there are entries in the fact tables, the dimension this InfoObject belongs to should be defined as a line item dimension. If the dimension is defined in this manner, the system will write the data directly to the fact table instead of creating a dimension table that has almost as many entries as the fact table.
On the other hand, if there are several dimension tables with very few entries (for example, less than 10), these smaller dimensions should be combined into one dimension.
2. Group related characteristics into one dimension only. Unrelated characteristics can use too much disk space and cause performance problems (for example, 10,000 customers and 10,000 materials may result in 100,000,000 records).
3. Avoid characteristics with a high granularity, that is, many distinct entries compared with the number of entries in the fact table.
4. Remove all "High-Cardinality" indicators from the InfoCube definition,generally, a dimension has a high cardinality if the number of dimension entries is 20% (or more) of the number of fact table entries. When in doubt, do not set a dimension with high cardinality
5.Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.
Hope it Helps
Chetan
@CP..

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

Dimension table is larger than the fact table

Hi Community,
How can we explain the phenomenon when a dimension table has MORE records in it than the fact table ? What are the conditions that would cause this to occur ?
Thank you !
Keith

Thanks, Bhanu,
I am wondering specifically how to explain the output from program SAP_INFOCUBE_DESIGNS when the dimension table is shown to have a fact table ratio that is greater than 100%
I believe that SAP_INFOCUBE_DESIGNS already takes into consideration both the E and also the F-fact table when calculating the ratio. So in this case, we could not explain it by your first suggestion (after compression - but looking at only the F table).
In the case where selective deletions have been performed, how can we correct the situation ? For example, how could we clean out the records in the dimension tables which no longer have any facts in the fact table ? (I think the BW system should do this automatically as a part of the selective deletion, don't you agree ?).
Also, is there any other explanation for how the dimension table could arrive at greater than 100% the size of the fact table(s) ?
For example, lets say that (theoretically) we placed many very dynamic characteristics together into the same dimension.. which we know you should not do. Would it be possible for the combination of these very many dynamic characteristics to cause so many DIM IDs that the dimension table overtakes the record count of the fact table ? Is this situation then made worse by compression if the number of fact table records is reduced thanks to removal of the request ID ?

Dynamic fact table choice

Similar Messages

Maybe you are looking for