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.

Similar Messages

Sizeof fact table and dimension table

Hi Experts ,
Can you tell me how to measure the size of dimension table and fact tables and how to find the ratio of size of dimension table to the size of fact table.
Thanks in advance,
Thanks and Regards
Ram Kommineni

Hi,
The ratio of size of fact table to dimension table is ideally should be 10:1. That means the size of the dimension tables should be 10% of the size of the fact table. This serves better in terms of performance.
Whenever you load any cube, you can easily find out the number of records in fact table (E and F table) and the dimension tables. Based on that statistics you can determine the ratio of size in fact and dimension tables.
Hope this info helps you.
Regards,
Yogesh.

Fact Table and Dimension Tables

Hi Experts, I'm creating custom InfoCubes for data coming from non-SAP source systems. I have two InfoCubes. Tha data is coming from like 10 tables. I have 10 DataSources created fo this and the data will be consolidated in Standard DSO before it will flow into 2 InfoCubes.
Now client wants to know before how much data will be there in InfoCubes in Fact table nad Dimension tables in both the InfoCubes. I have the total size of all the 10 tables from the sources given to me by the DBA. I wan not sure how I can convert that info for Fact table and Dimension table as I have not yet created these Infocubes.
Please help me with this on how I should address this.

hi,
The exact data will be hard to give however you can reach at a round figure in your case.
You are consolidating the data from the tables that means that there is relation between the tables. Arrive at a rough figure based on the relation and the activity you are performing while consolidating the data of the tables.
For example, let us say we want to combine data for sales order and deliveries in a DSO.
Let Sales order has 1000 records and Delivery has 2000 records. Both the tables have a common link (Sales Order).In DSO you are combining the data that means the data will be at the most granular level consist of Delivery data, so the maximum no of records which the consolidated DSO can have is 2000.
regards,
Arvind.

Reg: Fact table and Dimension table in Data Warehousing -

Hi Experts,
I'm not exactly getting the difference between the criteria which decide how to create a Fact table and Dimension table.
This link http://stackoverflow.com/questions/9362854/database-fact-table-and-dimension-table states :
Fact table contains data that can be aggregate.
Measures are aggregated data expressions (e. Sum of costs, Count of calls, ...)
Dimension contains data that is use to generate groups and filters.
This's fine but how does one decide which columns to consider for Fact table and which columns for Dimension table?
Any help is much appreciated.
Pardon me if this's not the correct place for this question. My first question in the new forum.
Thanks and Regards,
Ranit Biswas

ranitB wrote:
But my main doubt was - what is the criteria to differentiate between columns for Fact tables and Dimension tables? How can one decide upon the design?
Columns of a fact table will often be 'scalar' attributes of the 'fact' data item. A dimension table will often be 'compound' attributes of a 'fact'.
Consider employee information. The EMPLOYEE table can be a fact table. It might have scalar attribute columns such as: DATE_HIRED, STATUS, EMPLOYEE_ID, and so on.
Other related information that can't be specified as a single attribute value would often be stored in a 'dimension' table: ADDRESS, PHONE_NUMBER.
Each address requires several columns to define it: ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY. And an employee might have several addresses: WORK_ADDRESS, HOME_ADDRESS. That address info would be stored in a 'dimension' table and only the primary key value of the address record would be stored in the EMPLOYEE 'fact' table.
Same with PHONE_NUMBER. Several columns are required to define a phone number and each employee might have several of them. The dimension tables are used to help 'normalize' the data in the employee 'fact' table.
And that EMPLOYEE table might also be a DIMENSION table for other FACT tables. A DEVELOPER table might have an EMPLOYEE_ID column with a value that points to a 'dimension' row in the EMPLOYEE dimension table.

Fact table and dimension table

what is the difference b/w fact table and dimension table

A fact table contains numeric values and also contain composite key(i.e collection of foreign key) e.g.. sales and profit. Typically has two types of columns: those that contain facts and those that are foreign keys to dimension tables.
Dimension tables, also known as lookup or reference tables, contain the relatively static data in the warehouse. It contains character values E.g Customer_name,Customer_city.
Dimension tables store the information you normally use to contain queries. Dimension tables are usually textual and descriptive and you can use them as the row headers of the result set.
Rachna

To find the size of the fact table and dimension table

Hi experts,
Can anyone plz tell me if i want to find size of the fact table and size of the dimension table to find cardinality and line item do we first build statistics then find size by transaction DB02 or any other method we have?
Thanks in advance

Hi ,
Please go to Tcode DB02 >Space>Table and Indexes.Give your table name or pattern (like /BIC/F* for gettinf all the Fact tables)
.This will give you sizes of all the table.
Also if you want to get list like TOP 30 Fact tables and Dimension Table.Please use TCode ST14, this will give a desired output with all the required details.
-Vikram

Where can we see Fact Table And Dimension Table in DataWarehouse Workbench?

Hai Experts
where can we see Fact Table And Dimension Table in DataWarehouse Workbench?
Best Regards
nvnkmr12

Hi
Refer the link below and you will get a comprehensive explanation of how data is stored and modeled in BI. If explains fact table, dimension table, SID table, P and Q , X and Y tables.
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/6ce7b0a4-0b01-0010-52ac-a6e813c35a84
Cheers
Umesh

Two fact and one dimension table

Hi folks
i am new to this field ( 3 months ), my TL has given me one task i have to finish it up today itself, Can anyone one give me some idea how to implement
req. The req is
1. there are 2 fact and one dimension table is there, i have to create reports on Quaterly and monthly basis by using one dimension table.
Can any one tell me what all are the steps in need to follow
2.What is standalone and integrated systems?
Regards
Reddy

Hi
If u r having mapping keys for quarter level n monthly level then create a Alias for the dimension table.Use the original dim table for quarter level mapping and the alias dim for monthly level.
Thanks
Don

Missing most detailed table for dimension tables

Hi ,
I am getting this following error
Business Model Core:
[nQSError: 15003] Missing most detailed table for dimension tables: [Dim - Customer,Dim - Account Hierarchy,Dim - Account Region Hierarchy,Fact - Fins - Period Days Count].
[nQSError: 15001] Could not load navigation space for subject area Core.
I got this error when I tried to configure # of Elapsed Days and # of Cumulative Elapsed Days by following way-
1. Using the Administration Tool, open OracleBIAnalyticsApps.rpd.
Configuration Steps for Controlling Your Data Set
Configuring Oracle Financial Analytics 5-51
The OracleBIAnalyticsApps.rpd file is located at:
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_
obisn\repository
2. In the Business Model and Mapping layer, go the logical table Fact - Fins - Period
Days Count.
3. Under Sources, select the Fact_W_DAY_D_PSFT logical table source.
4. Clear the Disabled option in the General tab and click OK.
5. Open the other two logical table sources, Fact_W_DAY_D_ORA and Fact_W_
DAY_D_PSFT, and select the Disabled option.
6. Add the "Fact - Fins - Period Days Count" and "Dim - Company" logical tables to
the Business Model Diagram. To do so, right-click the objects and select Business
Model Diagram, Selected Tables Only.
7. In the Business Model Diagram, create a new logical join from "Dim - Company"
to "Fact - Fins - Period Days Count." The direction of the foreign key should be
from the "Dim - Company" logical table to the "Fact - Fins - Period Days Count"
table. For example, on a (0,1):N cardinality join, "Dim - Company" will be on the
(0/1) side and "Fact - Fins - Period Days Count" will be on the N side.
8. Under the Fact - Fins - Period Days Count logical table, open the "# of Elapsed
Days" and "# of Cumulative Elapsed Days" metrics, one at a time.
9. Go to the Levels tab. For the Company dimension, the Logical Level is set to All.
Click the X button to remove it. Repeat until the Company dimension does not
have a Logical Level setting.
10. Make sure to check Global Consistency to ensure there are no errors, and then
save the RPD file.
Please help me to resolve.
Thanks,
Soumitro

Could you let me know how you resolved this. I am facing the same.

"Missing most detailed table for dimension tables" eror when I run the Global Consistency check

ERRORS:
Business Model DAC Measures:
[nQSError: 15003] Missing most detailed table for dimension tables: [D_DETAILS,D_EXECUTION_PLAN,D_TASK].
[nQSError: 15001] Could not load navigation space for subject area DAC Measures.
I am also attaching my Business Model layer for easy understanding. I have a fact table and several Dimension table. I got this error only after creating the following hierarchies:
Execution Plan -> Tasks -> Details
Start Date Time Hierarchy
End Date Time Hierarchy
Is there a solution for this problem? Thanks in advance!

Yes ! My Task Hierarchy has 3 dimension tables that form a hierarchy :Execution Plan -> Tasks -> Detail
All the 3 levels in the hierarchy are 3 different dimension tables.

Oracle Data Compression on SID tables and Dimension Tables

Hello Community,
We have had great success with Oracle compression on ODS tables that are no longer loaded.
We'd now like to move on to other types of BW tables that are very large.
OSS Note 701235 provides answers to questions concerning the possible use of Oracle compression together with SAP BW.
But the Note does not give suggestions for (or against) Oracle compression on SID tables or Dimension tables.
I believe both table types would exhibit the same behaviour : mostly inserts of new SID IDs and new DIM IDs, but few updates to existing SID or Dimension records. If this is true, then both are good candidates for oracle compression.
Do you also agree that this is the typical behaviour for SID tables and dimension tables ? And that these types of tables are good candidates for Oracle compression in a large BW system ?
Thanks kindly!
Keith Helfrich

Hi all,
Although this is an old thread I stumbled on during my own investigations I can provide some answers to your questions.
Table candidates for compression are found by these criteria
       - Table size big enough?
       - Long lifetime of object planned ?
      - No or only rare structural changes for the table   ?
      - u201EUpdateu201C rate low : is your data mostly kind of u201Cread onlyu201D ?
--               for the wideley used rolling window partition techniques of
                  tables in BW this is not a problem: mostly INSERTu2019s in the
                 current partition not affecting other partitions
BW tables that can benefit from compression (see SAP notes 105047,701235)
       - PSA tables with data that must be saved for a longer time
       - ODS change log (no Updates of old data, only Inserts of new data)
       - u201Ehistoricalu201C cubes wich get no changes in table structure anymore
Limitations
         - normal Insert or Update statements are stored ALWAYS in uncompressed
                format and must be compressed separately ( <= Oracle10g )
         - Slight CPU overhead of compression, butu2026
         --      CPU consumption is more than compensated by doing less I/O as
               for Bulk loads or parallel processing
         --      SAP BW transformations took a significant amount of CPU for
                   overall load-time into cubes caused by the application server not
                   the database
          - Table must have not more than 255 fields
          - Adding columns with an initial value or dropping columns require
               uncompression of the complete table (strongest limitation)
Consider all this above and you can decide that tables that going through UPDATE's are
not good candidates for compression or tables that can change it's structure (like
Fact- or DIM tables) .
Now, my questions to you:
Wich Oracle version do you use?
Wich tool do you use for Oracle compression?
BRspace (can you give an example ?)
ALTER ... MOVE COMPRESS
bye
yk

[nQSError: 15003] Missing most detailed table for dimension tables:

Hi,
I am new to BI. I created fresh respository from the scratch.
When run the consistency check I get the following messages.
[nQSError: 15001] Could not load navigation space for subject area SALES.
[nQSError: 15003] Missing most detailed table for dimension tables: [Products,Customers].
Can anyone help me on this.
Thank you
subra.

Got rid of the problem by deleting and recreating the dimension tables.
Subra.

Multiple Fact Tables and Dimension Tables

I have been having some problems trying to model the data from Oracle E-Business Suite maintenance. I will try to give the best description of how the data is held in the tables. The structure is such that a work order can have multiple operations and an operation can have multiple resources as well. I believe the problem comes in the fact that an operation doesn't necessarily need to have a resource. I could not attach an image so I have written out an example below. I am not saying this is right or that it works, but just to give you an idea of what I am thinking. The full dimension would be Organization -> WorkOrder -> Operation -> Resource. Now, the fact tables all hold factual data for the three different levels, with the facts being at each corresponding level. This causes an obvious problem in combining the tables into one large fact table through the ETL process.
Can anyone tell me if they think this can be done? Am I way off? I am sure that there is a solution as there always is but I have been killing myself trying to figure this one out. I currently have the entire solution in different Business Models. I would like however to be able to compare facts from multiple areas such as the Work Order level and the Resource level.
Any help is greatly appreciated. I realize that the solution may also require additional work on the ETL side so I am open to any and all suggestions.
Thank you in advance for anyones time. :)
Dimension Tables
WorkOrder_D
Operation_D
Resource_D
Organization_D
Fact Tables
WorkOrder_F
Operation_F
Resource_F
Joins
WorkOrder_D -> Operation_D
Operation_D -> Resource_D
WorkOrder_D -> WorkOrder_F
Operation_D -> Operation_F
Resource_D -> Resource_F
Organization_D -> WorkOrder_D
Organization_D -> Operation_D
Organization_D -> Resource_D

Hi,
Currently the dimension table is taken as a simple logical table in rpd as it does not have have any levels or hierarchy.
Its a flat dimension. Can you guide me how can I implement a flat dimension in OBIEE? Because this dimension is taken as simple logical table
I am not able to set appropriate level for fac tables. This dimension does not appear in the list of dimensions.

Fact Tables without Dimension Tables.

Hi,
I am currently working on a project where a data warehouse is being developed using an application database as the source. Since the application database is already normalised, the tables are being loaded in as they are and the consultant involved is creating
data marts for them. I have asked about why he is not creating separate dimension and fact tables as data marts, and he has told me that he will create a fact table with the dimensions as column names without any dimension tables created as you might expect
as per star/snowflake schema.
Is this right, as I always thought you had to have dimension and fact tables, especially if you want to start using SSAS?
Regards,
W.

create a fact table with the dimensions as column names without any dimension tables created as you might expect as per star/snowflake schema.
This is the trouble with denormalization: where is the stopping point?
If the data warehouse is the source for SSAS OLAP cubes, it is better to go with the usual star schema.
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

How to resolve many fact tables and Dimensions tables

Hi,
The scenario is we have many facts and dimension tables. Based on some conditions one measure from one fact will be divided by another fact measure. I have encoutered with many errors like " Unable to navigate .... " ? How to resolve these errors and reduce many to few ? ( I assume creating logical tables, but is there any other alternatives ? )
thanks
Suresh

Suresh,
I assume that you know how to create a single logical fact from n-physical facts, ie only if the fact tables are related. Then join all the conformed dimensions to this single Logical table using a join in the Business Model layer. Remember to set the mappings in the LTS. All if you have any hierarchies please set the aggregation level for those.
- Red

Problem with populating a fact table from dimension tables

my aim is there are 5 dimensional tables that are created
Student->s_id primary key,upn(unique pupil no),name
Grade->g_id primary key,grade,exam_level,values
Subject->sb_id primary key,subjectid,subname
School->sc_id primary key,schoolno,school_name
year->y_id primary key,year(like 2008)
s_id,g_id,sb_id,sc_id,y_id are sequences
select * from student;
S_ID UPN FNAME COMMONNAME GENDER DOB
==============================
9062 1027 MELISSA ANNE       f 13-OCT-81
9000 rows selected
select * from grade;
      G_ID GRADE      E_LEVEL         VALUE
        73 A          a                 120
        74 B          a                 100
        75 C          a                  80
        76 D          a                  60
        77 E          a                  40
        78 F          a                  20
        79 U          a                   0
        80 X          a                   0
18 rows selectedThese are basically the dimensional views
Now according to the specification given, need to create a fact table as facts_table which contains all the dim tables primary keys as foreign keys in it.
The problem is when i say,I am going to consider a smaller example than the actual no of dimension tables 5 lets say there are 2 dim tables student,grade with s_id,g_id as p key.
create materialized view facts_table(s_id,g_id)
as
select s.s_id,g.g_id
from   (select distinct s_id from student)s
,         (select distinct g_id from grade)gThis results in massive duplication as there is no join between the two tables.But basically there are no common things between the two tables to join,how to solve it?
Consider it when i do it for 5 tables the amount of duplication being involved, thats why there is not enough tablespace.
I was hoping if there is no other way then create a fact table with just one column initially
create materialized view facts_table(s_id)
as
select s_id
from student;then
alter materialized view facts_table add column g_id number;Then populate this g_id column by fetching all the g_id values from the grade table using some sort of loop even though we should not use pl/sql i dont know if this works?
Any suggestions.

Basically your quite right to say that without any logical common columns between the dimension tables it will produce results that every student studied every sibject and got every grade and its very rubbish,
I am confused at to whether the dimension tables can contain duplicated columns i.e column like upn(unique pupil no) i will also copy in another table so that when writing queries a join can be placed. i dont know whether thats right
These are the required queries from the star schema
Design a conformed star schema which will support the following queries:
a. For each year give the actual number of students entered for at A-level in the whole country / in each LEA / in each school.
b. For each A-level subject, and for each year, give the percentage of students who gained each grade.
c. For the most recent 3 years, show the 5 most popular A-level subjects in that year over the whole country (measure popularity as the number of entries for that subject as a percentage of the total number of exam entries).
I written the queries earlier based on dimesnion tables which were highly duplicated they were like
student
=======
upn
school
school
======
school(this column substr gives lea,school and the whole is country)
id(id of school)
student_group
=============
upn(unique pupil no)
gid(group id)
grade
year_col
========
year
sid(subject id)
gid(group id)
exam_level
id(school id)
grades_list
===========
exam_level
grade
value
subject
========
sid
subject
compulsory
These were the dimension table si created earlier and as you can see many columns are duplicated in other tables like upn and this structure effectively gets the data out of the schema as there are common column upon which we can link
But a collegue suggested that these dimension tables are wrong and they should not be this way and should not contain dupliated columns.
select      distinct count(s.upn) as st_count
,     y.year
,     c.sn
from      student_info s
,     student_group sg
,     year_col y
,     subject sb
,     grades_list g
,     country c
where      s.upn=sg.upn
and     sb.sid=y.sid
and     sg.gid=y.gid
and     c.id=y.id
and     c.id=s.school
and      y.exam_lev=g.exam_level
and      g.exam_level='a'
group by y.year,c.sn
order by y.year;This is the code for the 1st query
I am confused now which structure is right.Are my earlier dimension tables which i am describing here or the new dimension tables which i explained above are right.
If what i am describing now is right i mean the dimension tables and the columns are allright then i just need to create a fact table with foreign keys of all the dimension tables.

Fact table to Dimension table ratio in RSRV

Similar Messages

Maybe you are looking for