Dimension tables and BPS performance

Hi gurus!
I have read a few guides about BPS performance here in SDN but haven't found any guidelines how to implement transactional infocubes in an effective way when it comes to performance.
Should I configure the dimensions so that all variable characteristics in layout selections and characteristics in key columns of layouts are in a same dimension? I suppose this would decrease the number of sql joins in running a layout, but then again would increase the size of a dimension table. Which is more important in achieving a good performance in general?
Thankful for experienced advice
Sari Kolsi

The foremost thing you need to consider is how best you can make the dataset to be minimum. The data to be read and processed should be very less and your cofiguration should aim at this.
Some of the other aspects you may consider:
1. Use variables.
2. Partition the packages so that data to be processed is less.
3. Keep the data in the transactional cube only to the extent you need. Data that the users dont need for planning or reporting should be stored in some other cube.
4. Try to use standard functions for plannbing.
5. Optimise your fox and ABAP code.
Ravi Thothadri

Similar Messages

Number of Entries in Dimension Tables and Fact Tables

Hi all,
is there an easy way to check
- the number of entries in the dimension tables
- the number of entries in the fact table?
Thanks a lot
Alex

Hi Alex,
If u want to see the content of Dimension table and Fact table for a infocube then just right click on a particular info cube then select manage . Select coneten tab there , form there u can either select Fact table to see the fact table conten or Infocube content to see the Dimensiontable content.
Regards..

Dimension table and fact table exists data physically

Hi experts,
can anyone plz tell me weather dimension table and fact table exists data physically or not/

Hi..Sudheer
SAPu2019s BW is based on "Enhanced Star schema" or "Info Cubes" database design.This database design has a central database table, known as u2018Fact Tableu2019 which is surrounded by associated dimension tables.
Fact table is surrounded by dimensional tables. Fact table is usually very large, that means it contains
millions to billions of records.
These dimension tables doesn't contain data it contain references to the pointer tables that point to the master data tables which in turn contain Master data objects such as customer, material and destination country stored in BW as Info objects. An InfoObjects can contain single field definitions such as transaction data or complex Customer Master Data that hold attributes, hierarchy and customer texts that are stored in their own tables.
SID is surrogate ID generated by the system. The SID tables are created when we create a master data IO. In SAP BW star schema, the distinction is made between two self contained areas: Infocube & master data tables/SID tables.
The master data doesn't reside in the satr schema but resides in separate tables which are shared across all the star schemas in SAP BW. A numer ID is generated which connects the dimension tables of the infocube to that of the master data tables.
The dimension tables contain the dim ID and SID of a particular IO. Using this SID the attributes and texts of an master data Io is accessed.
The SID table is connected to the associated master data tables via teh char key.
Fact table(Transaction data,DIM ID)<>Dimention Table(SID and Dim ID)<->Masterdata table(SID,IO)
Thanks,
Abha

Trying to use 2 different Dimension tables and make a hierarchy on some columns which are split into these dimensions .. how do I do that

Trying to use 2 different Dimension tables and make a hierarchy on some columns which are split into these dimensions .. how do I do that

If you need to make a hierarchy in an Attribute view you need to have all relevant fields/columns in the same Dimension table..

Regarding Dimension Table and Fact table

Hello,
I am having basic doubts regarding the star schema.
Let me explain first regarding star schema.
Fact table containes Key fiigures and Dim IDs,Ok,
These DIm ids will be connected to my dimension tables.The Dimension table contains Characterstics and these Dim ids ,Ok.
Then My basic doubt
1.How does DIm id will be linked to SID tables
2.If I have not maintained any master data or text or Heirachies then SID tables will it be generated or not?
3.If it is generated I think there is use of This SID now..as we have not maintained Master data.
4.I am haing 18 characterstic which are no way related to each other in that scnerio how does Dimensions have to identified.?or we need to inclued whole chracterstics in one dimensions or we need to create seprate dimesnions for each of them..?(max is 13 dimensions)
5.If Dimension table contains dim ids and characterstics then where does the values for characterstics will be stored...?
( for ex..sales rep is characterstics for this we will be giving values some names where does these values will be stored..)

hi Vasu,
e.g we have infocube with
- dimension 'location' -> characteristic 'sales rep', 'country'
- dimension 'partner'.
fact table
dim-id('sales person') dim-id('partner') revenue
1001                   9001              500
1002                   9002              300
1003                   9004              200
dimenstion table 'location'
dim-id sid-id(sales rep) sid-id(country)
1001    3001              5001
1002    3004              5004
1003    3005              5001
'sales rep' sid table
sid   sales rep
3001 abc
3004 pqr
3005 xyz
'country' sid table
5001      country1
5004      country2
so from the link dim-id and sid, we get
"sales rep report"
sales-rep   revenue
abc        500
pqr        300
xyz        200
"country report"
country    revenue
country1   700
country2   300
hope it's clear.

No of columns in a table and SQL performance

How does the table size effects sql performance?
I am comparing 2 tables , with same number of rows(54 million rows) ,
table1(columns a,b,c,d,e,f..) has 40 columns
table2 (columns (a,b,c,d)
SQL uses columns a,b.
SQL using table2 runs in 1 sec.
SQL using table1 runs in 30 min.
Can any one please let me know how the table size , number of columns in table efects the performance of SQL's?
Thanks
jeevan.

user600431 wrote:
This is a general question. I just want to compare table with more columns and table with less columns with same number of rows .
I am finding that table with less columns is good in performance , than the table with more columns.
Assuming there are no row chains , will there be any difference in performance with the number of columns in a table.Jeevan,
the question is not how many columns your table has, but how large your table segment is. If your query runs a full table scan it has to read through the whole table segment, so in that case the size of the table matters.
A table having more columns potentially has a larger row size than a table with less columns but this is not a general rule. Think of large columns, e.g. varchar2 columns, think of blank (NULL) columns and you can easily end up with a table consisting of a single column taking up more space per row than a table with 200 columns consisting only of varchar2(1) columns.
Check the DBA/ALL/USER_SEGMENTS view to determine the size of your two table segments. If you gather statistics on the tables then the dictionary will contain information about the average row size.
If your query is using indexes then the size of the table won't affect the query performance significantly in many cases.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Dimension Table and Fact Tables

Hi,
Is there any way to see the Dimension Table contents and Fact Table Contents.
For eg:- I should be able to see the DIM ID and the SID's of a Dimension.

Well you can see them in SE11, by giving the table name.
Go to list schema and give the cube name. It will display all the table for that cube. Give the table name in SE11 or SE16 and see the content there.

Regarding Internal table and access performance

hey guys.
In my report , Somehow i reduced the query performance time by selecting minimum key fields and moved the selected records to internal table.
Now from this internal table i am restricting the loop
as per my requirements using where statements.(believing that internal table retrieval is more faster than database acces(using query)).
But still my performance goes down.
Could you pls suggest me how to reduce the execution time
in abap programming.
I used below commands.
Read using binary search.
loop ...where statement.
perform statements.
collect staements.
delete itab.(delete duplicates staements too)
sort itab(sorting).
For each above statements do we have any faster way to retrieval records.
If i see my bottle neck at se30.it shows
ABAP programming to 70 percent
database access to 20 percent
R3 system as 10percent.
now how to reduce this abap process.
could you pls reply.
ambichan.
ambichan.

Hello Ambichan,
It is difficult to suggest the improvements without looking at the actual code that you are running. However, I can give you some general information.
1. READ using the BINARY SEARCH addition.
This is indeed a good way of doing a READ. But have you made sure that the internal table is <i>sorted by the required fields</i> before you use this statement ?
2. LOOP...WHERE statement.
This is also a good way to avoid looping through unnecessary entries. But further improvement can certainly be achieved if you use FIELD-SYMBOLS.
LOOP AT ITAB INTO <FIELD_SYMBOL_OF_THE_SAME_LINE-TYPE_AS_ITAB>.
ENDLOOP.
3. PERFORM statements.
A perform statement can not be optimized. what matters is the code that you write inside the FORM (or a subroutine).
4. COLLECT statements.
I trust you have used the COLLECT statement to simplify the logic. Let that be as it is. The code is more readable and elegant.
The COLLECT statement is somewhat performance intensive. It takes more time with a normal internal table (STANDARD). See if you can use an internal table of type SORTED. Even better, you can use a HASHED internal table.
5. DELETE itab.(delete duplicates staements too)
If you are making sure that you are deleting several entries based on a condition, then this should be okay. You cannot avoid using the DELETE statement if your functionality requires you to do so.
Also, before deleting the DUPLICATES, ensure that the internal table is sorted.
6. SORT statement.
It depends on how many entries there are in the internal table. If you are using most of the above points on the same internal table, then it is better that you define your internal table to be of type SORTED. That way, inserting entries will take a little more time (to ensure that the table is always sorted), but alll the other operations are going to be much faster.
Get back to me if you need further assistance.
Regards,
<a href="https://www.sdn.sap.com:443http://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.sdn.businesscard.sdnbusinesscard?u=zwcc%2fwm4ups%3d">anand Mandalika</a>.

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.

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.

Facts and Dimension tables.

We have around 6 facts tables and 10 dimensions tables. The ER diagram shows the fact tables are joined. Now how do I arrange these tables in order to form a star schema? Any suggestions?

You should make Joins (foreign keys) between fact tables and dimensions tables on Physical Layer of Administration Tool. The cardinality should be 1 to N, being 1 in table dimension and N in the fact table.
Right click on one element of physical layer, and select 'physical diagram' -> 'Object(s) and all joins'. Then appears all tables. To define foreign keys, select icon 'new foreign keys', first select dimension table and second click over fact table to make a cardinality 1:N.
Good luck,
Regards.
Edited by: Hammett81 on Jul 21, 2010 11:14 PM
Edited by: Hammett81 on Jul 21, 2010 11:22 PM

Dimension table sharing

Hi, Gurus,
If two(or more) cubes have some same dimensions, how are they sharing the dimension tables like SAP says? I think they can't because they have different dimension table names even they have the same infoobjects in it.
Am I right? this is a performance issue.

Hi Kunlun,
In my mind I don't know cubes can share dimension tables.
For example, even if you have two cubes with the same structure, they will have own dimension tables and fact tables.
When you first time activate a cube named CUBENAME, the system will automatically generate the following tables:
Dimension table:
/BIC/DCUBENAMEXX
Fact table:
/BIC/FCUBENAME
So for different cubes, the dimension tables' names are different.
For the performance aspect, sharing dimension will save disk space but will not benefit the query performance. You can image if system shares dimension for one big cube and one small cube, the query execution time on the small cube will be longer.
Regards,
Frank

How to Create a Dimension Table in OBIEE11g

Hello,
Chapter 9, page 221(if pdf) of the Build Repository manual of OBIEE 11g explains following.
Creating Dimensions in Level-Based Hierarchies
After creating a dimension, each dimension can be associated with attributes
(columns) from one or more logical dimension tables and level-based measures from
logical fact tables. After you associate logical columns with a dimension level, the
tables in which these columns exist appear in the Tables tab of the Dimension dialog.
To create a dimension with a level-based hierarchy:
1. In the Business Model and Mapping layer of the Administration Tool, right-click a
business model and select New Object > Logical Dimension > Dimension with
Level-Based Hierarchy.
Note that this option is only available when there is at least one dimension table
that has no dimension associated with it.I am still learning OBIEE, and I can not see the dimension menu item as per point 1 becuse i do not have dimension table associated with it. All I have done at this point is to create logical tables based on few physical tables in physical layer.
How do I create Dimension Tables? using BI Admin tool?
Thanks,R

Hi Rich,
If you are new to Oracle BI, you would better start with the Oracle Learning Library; http://apex.oracle.com/pls/apex/f?p=9830:41:0::NO:RIR:IR_PRODUCT,IR_PRODUCT_SUITE,IR_PRODUCT_COMPONENT,IR_RELEASE,IR_TYPE,IRC_ROWFILTER,IR_FUNCTIONAL_CATEGORY:,BI,,,,,
You create dimensions based on your logical tables. In a plain star-schema you would have one logical fact table and at least one or more logical dimension tabes attached (joined) to the fact table. Just follow the documentation and you would be good to go.
Good Luck,
Daan Bakboord
http://obibb.wordpress.com

Dimension Table populating data

Hi
I am in the process of creating a data mart with a star schema.
The star schema has been defined with the fact and dimension tables and the primary and foreign keys.
I have written the script for one of the dimensions and would like to know when the job runs on a daily basis should the job truncate the table every day and rebuild the dimension table or should it only add new records to the table. If it should add only
new records to the table how do is this done?
I assume that the fact table job is run once a day and only new data is added to it?
Thanks

It will depend on the volume of your dimensions. In most of our projects, we do not truncate, we update only updated rows based on a fingerprint (to make the comparison faster than column by column), and insert for new rows (SCD1). For SCD2 we apply
similar approach for updates and inserts, and expirations in batch (one UPDATE for all applicable rows at the end of the package/ETL).
If your dimension is very large, you can consider truncating all data or deleting only affected modified rows (based on nosiness key) to later reload those, but you have to be carefully maintaining the same surrogate keys reference by your
existing facts.
HTH,
Please, mark this post as Answer if this helps you to solve your question/problem.
Alan Koo | "Microsoft Business Intelligence and more..."
http://www.alankoo.com

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.

Dimension tables and BPS performance

Similar Messages

Maybe you are looking for