Calculation of Dim To Fact Ratio

Hi All,
I was trying to calculate manually the ratio of Dim To Fact but i got stuck.
For example after running the report SAP_INFOCUBE_DESIGNS i got below row in red color :-
Zxxxxxx1 /BIC/DZxxxxxx1A rows: 8,182 ratio: 77 %
So can you tell me now how can i maually caluculate the ratio or how the system has calculated it as 77% ?
Regards,
Anjali Singh

Dear All,
Thanks a lot for all your valuable replies.
Finally i got answer to my question.
My question was that how the ratio is been calculated or if we see the output of report SAP_INFOCUBE_DESINGS then how can we manually calculate the Dim To Fact ratio?
For example the o/p is somthing like this :-
ZXXXXXXX     rows:     2,339,233     density:          0          %
ZXXXXXXX     /BIC/DZXXXXXXX3          rows:     182,750          ratio:     8     %
ZXXXXXXX     /BIC/ZXXXXXXX5          rows:     311,010          ratio:     13     %
Now the Dim To Fact Ratio here is (182,750 / 2,339,233 ) * 100 = 8%
Regards,
Anjali Singh

Similar Messages

Where to see dim and fact table names for a cube.

Hello Experts,
Where to see dim and fact table names for a cube.

Do a wild character search with the cube name (with '*' on both sides of the cube name) in transaction code SE11 or LISTSCHEMA...
For Eg : Cube Name is ZFIN_C111
Goto transaction code SE11
Tables - ZFIN_C111 & then F4 would give you all the associated tables for the InfoCube.

Manual calculation of 'Buffer Cache hit ratio'

Using: Oracle 10.2.0.1.0, Redhat 4, 64bit.
Manual calculation of ‘Buffer Cache hit ratio’ is very off from what it shown in statspack.
Statspack shows:
Instance Efficiency Percentages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %: 100.00       Redo NoWait %:   99.97
            Buffer Hit   %:   99.18    In-memory Sort %: 100.00
            Library Hit   %:   90.43        Soft Parse %:   52.56
         Execute to Parse %:   80.14         Latch Hit %:   99.98
Parse CPU to Parse Elapsd %:   96.21     % Non-Parse CPU:   56.89
Manual calculation (Got this formula from Sybex PT book, page 275):
SQL> select name, 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
from v$buffer_pool_statistics;
NAME                 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
DEFAULT                                                      .700247215Any idea, why using v$buffer_pool_statistics gives wrong results?
Thanks regards,

SYS@oradocms11> select (P1.value + P2.value - P3.value)/(P1.value + P2.value)*100
2 from v$sysstat P1, v$sysstat P2, v$sysstat P3
3 where P1.name = 'db block gets'
4 and P2.name = 'consistent gets'
5 and P3.name = 'physical reads';
(P1.VALUE+P2.VALUE-P3.VALUE)/(P1.VALUE+P2.VALUE)*100
99.6977839
SYS@oradocms11> select name, 1 - (PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS)) from v$buffer_pool_statistics
NAME 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
DEFAULT .997009542
In my case, both are giving almost same result.

Star Schema - How to improve the ratio DIM to FACT table

If any one want to repply here
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
thanks

Guidelines how to limit the number of records in dimension tables
1. If an InfoObject has almost as many distinct values as there are entries in the fact table, define the
dimension of the InfoObject as a line item dimension. If defined in this manner, the system will write
the data directly to the fact table (a field with the data element RSSID, which immediately shows the
SID table of the InfoObject, is written in the fact table) instead of creating a dimension table that has
almost as many entries as the fact table.
2. Only group related characteristics into one dimension. 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. If you cannot avoid characteristics with a high granularity and most of your queries do not use these
characteristics, create an aggregate that stores summarized information. Do not use characteristics
with a high granularity in this aggregate.
Please note that the LineItem flag can have negative performance impact on F4 help usage (for which
the setting 'Only Values in InfoProvider' is used (transaction RSD1 &#56256;-> Tab 'Business Explorer')).
5. It is also worthwhile to try the checks in transaction RSRV. Use for example RSRV -> All
Elementary Tests -> Transaction Data -> Entries Not Used in the Dimension of an InfoCube.

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

Issue with non calculated column in a fact table

Hi All,
With 3 facts(Fact1,Fact2,Fact3) and 2 Confirmed Dimensions my joins work fine in Criteria when I include All calculated columns from facts. If I try to include a non calculated column from Fact1(Which is a number Data type) Columns from Fact2 and Fact3 show Null values. I know it is not recommended to include dimension columns in fact , does OBIEE not support Number type non calculated columns as well? Is there any work around that I can bring in my non calculated column from Fact and still get results for other fact columns.Iam at 11.1.1.7 of OBIEE
Let me know if Iam not clear.
Your help is much Appreciated.
Thanks,
Vineela.

i would like to add 2 fields into my fact tables - LOAD ID (populated by a sequence during each load) and LOAD DATE.
as these fields are not related to any reporting dimensions, it is still possible to add them in OWB ? the fact wizard always ask for a foreign key to a dimension ...
Duncan,
If you want to add non dimensional attributes to a fact by using OWB, you can create additional measures to it and use them as attributes.
Igor

Dim and Fact Key sync and Clean up

Hello all,
We have some really bizarre thing going on in our DW environment, same ETL jobs is running twice and because of extremely bad design with no constraints at all, we have lots of duplicate records getting inserted.
So the actual row count in DIM table should be 3 mill, but because of these multiple runs the count is like 9 mill rows. I'll illustrate this with an example.
This is the Dimension table, column (HEADER_ITEM ,LINE_ITEM) is the NATURAL_KEY, while DIM_SK is the PK, as you can see the table has three occurrence of NATURAL_KEY with increasing PK, but some time it may have same PK too, as there is no actual PK constraint on this table.
CREATE TABLE SABEGH_DIM
DIM_SK DECIMAL(10),
HEADER_ITEM VARCHAR2(10),
LINE_ITEM VARCHAR2(10)
INSERT INTO SABEGH_DIM VALUES (1,'A','X');
INSERT INTO SABEGH_DIM VALUES (2,'A','X');
INSERT INTO SABEGH_DIM VALUES (3,'A','X');
INSERT INTO SABEGH_DIM VALUES (4,'B','Y');
INSERT INTO SABEGH_DIM VALUES (5,'B','Y');
INSERT INTO SABEGH_DIM VALUES (6,'B','Y');
INSERT INTO SABEGH_DIM VALUES (11,'C','Z');
INSERT INTO SABEGH_DIM VALUES (11,'C','Z');
INSERT INTO SABEGH_DIM VALUES (11,'C','Z');
And then there is a FACT table too, which is one-to-one with this DIM.
CREATE TABLE SABEGH_FACT
FACT_SK DECIMAL(10),
COL1 VARCHAR2(10),
COL2 VARCHAR2(10),
COL3 VARChAR2(10)
INSERT INTO SABEGH_FACT VALUES (1,'RAIN','DIDI', 'FF');
INSERT INTO SABEGH_FACT VALUES (3,'RAIN','DIDI', 'FF');
INSERT INTO SABEGH_FACT VALUES (5,'CNG','ZION','TEST');
INSERT INTO SABEGH_FACT VALUES (11,'CNG','ZION','TEST');
What I would like to do some clean up, on both these tables.
SABEGH_DIM :
1. Preserve the Maximum Key within the group of same NATURAL_KEY in DIM table, if there are dups, load only one record. So my SABEGH_DIM table finally should have these values:
3......A.....X
6......B.....Y
11....C.... .Z
SABEGH_FACT:
Since this FACT table, may still refer the old PK from the DIM, we need to change the PK appropriately, so that it ties up with the DIM correctly. SABEGH_FACT should contain now this data set, which is the final results.
i replaced old keys with new PK from the Dim, and if after this operation there are dups in FACT, load only one occurrence.
3.......RAIN........     DIDI.........FF
6.......CNG........     ZION........TEST
11.....CNG........     ZION........TEST
These table are really huge, so it would be nice to have some fast query, I can add INDEXES, CONSTRAINTS; if it helps to speed up the process. Also, I would like to have a cross-reference table, which as both old keys and new keys, there are other FACT tables, which are still referring the OLD PK from this DIM table, so I have to update that FACT table key as well,
DIM_PK.......HEADER_ITEM.......LINE_ITEM.......MAX_DIM_PK
1......A.....     X.....3
2.....     A.....     X.....3
3.....     A.....     X.....3
4.....     B.....     Y.....6
5.....     B.....     Y.....6
6.....     B.....     Y.....6
11.....C.....     Z.....11
11....     C.....     Z.....11
11.....C.....     Z.....11
So, I'll use this Cross-Reference table to update KEY in other FACT table.
Thanks a lot!
Sabegh

What I would like to do some clean up, on both these tables.Please proceed to do so.

Data Modeling:Criteria to add a logical column to a DIM or FACT table

Hi,
Scenario:
Physical Layer:
- Table_T has following columns: COL_A, COL_B, COL_C
- COL_C is a measure. COL_A and COL_B refer to dimensions.
- COL_A is primary key of Table_A, COL_B is primary key of Table_B
BMM Layer:
1- Dimension table: DIM_A(TABLE_A), Fact table: contains COL_A, COL_B, COL_C
2- Dimension tables: DIM_A(TABLE_A), DIM_B(TABLE_B), Fact table: contains COL_A, COL_B, COL_C
Additional Information:
We can model the BMM layer using the above-mentioned approaches, but either of the two will have some advantages over the other to model COL_B. Some of the advantages of (2) as highlighted by the OBIEE team:
a). Drill down capability will be supported for COL_B,
b). Useful in scenarios where multiple facts need to refer to TABLE_B.
Concern:
We agree with the above technical comments but if someone can provide us with more insight on both the approaches and how an end user can benefit from either approach, it will help us a lot.
We basically need to understand what are the implications if we leave something as just an attribute on the fact and do not model it as a dimension.
Thank you,
Abhishek
P.S. The OBI Server Admin guide does provide us with useful information on the implementation aspect, but we need more information from the end user's perspective.

Very similar to the question below. In pure terms your FACT table should contain no Dimension attributes, Facts tables should contain measures.
Where you have a Physical table that contains a mixture of aggregates and non-aggregate Dimension Attributes then you should split them out in the logical layer into 2 Logical Tables one for the Fact one for the Dimension.
From an end user perspective (certainly the ones I have coached) it is easy for them to understand the the Measures are all in one place, and then if they need to slice and dice then they select the appropriate attributes from the Dimension folders.

10 dim 1 fact data level restrict

All,
I have 10 dimension tables and 1 fact table.
and my Country Dimension table like below data
Name,Country
A UK
B US
C MY
D SG
My requirment is When user "A" logged in,he wants to view only UK country values simillarlly other user data.
How will restrict each dimenstion table.
Thanks

hi,
this can be achieved by implementing row level security. you can define permissions for a particular group in the rpd so that when the user logs in, he only sees the data according to his role/access level. for more details see these urls
http://mithil-tech.blogspot.com/2010/07/obiee-session-variables-and-row-level.html
http://www.rittmanmead.com/2007/05/obiee-and-row-level-security/
assign points if found helpful.

Calculating count from two fact tables

Hi Guys,
My requirement,
i have two fact table F1, F2 connected with a D1 dimension table, all table connected with a id column
F1 ---------D1------------F2
n 1 1 n
i want to find out the distinct count from Fact F1 where the value also present in F2( ie. F1.id= F2.id condition).
this measure usefull through out my project so i want create a logical column, how to create it.
I tried this way:
i Created two fact table in to one fact table by adding logical source, and created a logical column from existing logical source where F1.id=D1.id and D1.id=F2.Id but it is wrong
Can any suggestion for solve my problem.
Thanks in advance!!!

Hi,
You can create an opaque view in physical layer and wrire a sql like
Select f1.id,count(*) from f1,f2 where f1.id=f2.id group by f1.id.Join this through id with dimesnion and add this fact table in LTS of your fact and use count(*) in report.
Regards,
Sandeep

Determine the size of Dim and Fact table

Hi,
Please some one tell me how do calculate the size of diminsion and fact table
Please explain me step by step.
Thanks

hi
We have two other ways also
Try RSRV test: Elementary > dataBase > DataBase Info about InfoProvide Tables
and You can check out in DB02 tcode Detail Analasys...
Thanks
Khaja

Referencing two fact keys from one dimension using Dim.Key = Fact.Key1 OR Fact.Key2 possible ?

Hi all
I need your help for an approach to the following problem. Lets say that i have the following dataset
AccountMonth
ActivityMonth
Amount
201307
201301
2.500
201307
201304
600
201307
201305
900
201307
201306
4.000
201307
201307
500.000
201308
201305
500
201308
201307
400
201308
201306
300
201308
201308
400.000
201309
201307
300
201309
201302
500
201309
201309
100.000
201310
201305
400
201310
201309
50.000
201310
201310
200.000
In my cube i want the user to select the Accountmonth from one time dimension, but i want some logic to also apply for the ActivityMonth. For one measure if I for example select 201307 i'll get this amount
AccountMonth
ActivityMonth
Amount
201307
201301
2.500
201307
201304
600
201307
201305
900
201307
201306
4.000
201307
201307
500.000
This is easy - Accountmonth dimension is related to AccountMonth column in the fact table. Now i also need another measure, where the month selected needs to be meet for both accounting and activity month. This is also easy, as i can just reference both
columns in the fact table. Result in this case is then only one row:
AccountMonth
ActivityMonth
Amount
201307
201307
500.000
Now the tricky part comes when I start to select more months, because the amount i need is where month combinations are shared, so if i for example choose 201307, 201308 and 201309 i don't just want
AccountMonth
ActivityMonth
Amount
201307
201307
500.000
201308
201308
400.000
201309
201309
100.000
I actually want the amount from which the months is in either accounting or activity, like this
AccountMonth
ActivityMonth
Amount
201307
201307
500.000
201308
201307
400
201308
201308
400.000
201309
201307
300
201309
201309
100.000
I know how to solve it either by having two time dimensions or using MDX, but user should only have to select from one time dimension. So far, solving it using Non-empty/existing in MDX is not performing fast enough. Feedback will be appreaciated if you
have an idea of how to solve this.

So far, solving it using Non-empty/existing in MDX is not performing fast enough. Feedback will be appreaciated if you have an idea of how to solve this.
here are some links about performance tuning
http://www.mssqltips.com/sqlservertip/2565/ssas--best-practices-and-performance-optimization--part-1-of-4/
http://technet.microsoft.com/en-us/library/cc966527.aspx

Fact table to Dimension table ratio in RSRV

Hi all,
I want to analyze how best the modeling is done, because I came to know that line item dimensions are not being used/designed at all, so want to know the ratio between fact to dim table. I read in some documentation that we can find that information in transaction rsrv. I tried in both 'All Elementary tests" and "All Combined tests", but I really didn't get how to find/analyze the data to find the percentage. Please let me know.
thanks,
Sabrina.

Hi Bhanu,
What I am seeing is this. It shows % of dim table to Infocube. Should i assume this as dim table:fact table as 165:100 resp. Infocube here means fact table I guess right?
@5B\QInformation@ Table /BIC/DZNETO_IC7 has 1633060 entries. Size corresponds to 165% of the InfoCube 14:30:35
By any chance do you know what is the ideal percentage.
thanks,
Sabrina.

Problem Facing while analyzing Dim/Fact Table % using RSRV

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

Hi,
Check whethere the statistics for the cube is run. If not refresh the stats ans then chk in RSRV or in SAP_INFOCUBE_DESIGNS you will get the ratio betwene ur dim and fact table
Hope it helps.
Regards,
Malar B

Size of dimention table fact table ratio question..

Hey Guys !!!
I have very basic question regarding the ratio of size of dimention table and fact table..
its mentioned that the ratio of dim table / fact table sizes should not be greater than 1:20 for performance reasons .. thats OK..
now lets say if i have fact table with customer dim_id ,some other dimention ids , and revenue (KF) .. with 1 million records ..
so ideally my customer dimention table should not have more than 200,000 recods (.ie 200,000 different customers ).
doesnt this put limitation on number of customers in a cube ?
if so, how do we handle this ?
please correct me if i am wrong in interpreting the concept of dimension table.
thanks in advance
swapnil

Hi ASRao ,
thanks for replying ...
you said exactlly what i know ..
sorry i didnt put my question in correct prespective ...
whay i meant was...
lets say , i need to have more than specified (1:20 ) number records in dimension table ,it will definately hamper my reporting performance ...
so, is there any solution to handle this kind of problem ?
like how would i maintain my efficiency of reporting in this case ?
thanks in advance

Calculation of Dim To Fact Ratio

Similar Messages

Maybe you are looking for