Why dimension tables are denormalized?

why dimension tables are denormalized?
Duplicate post
Edited by: Pravender on Jun 17, 2011 12:31 AM

Hi,
As pr my understanding, if you have a normalized structure for say, a cube, mean you have 10 table connected to single central table. So while queying you are trying to read data in a single SELECT on virtually a view of 10 different tables.
While in the present denormalized cube structure, you go for different selects virtually F table -> DIM table -> SID table -> Mastertable -> Text table. One can imagine sort of parallel SELECTs.
So if for small amount of data this denormalized structure may be slow but if you imagine for huge volume, this method is better.

Similar Messages

None of the dimension tables are compatible with the query request

Hi,
i am experiencing the below error while querying columns alone from employee dimension (w_employee_d) in workforce profile SA. There is only one column in my report which is employee number coming from employee dimension. when i query other information like job, region, location etc i am not getting any error. the below error appears only when querying columns from employee dimension. the content tab level for the LTS of employee dimension is set to employee detail.
View Display Error
Odbc driver returned an error (SQLExecDirectW).
Error Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 14077] None of the dimension tables are compatible with the query request Dim - Employee.Employee Number. (HY000)
SQL Issued: SELECT 0 s_0, "Human Resources - Workforce Profile"."Employee Attributes"."Employee Number" s_1 FROM "Human Resources - Workforce Profile" FETCH FIRST 65001 ROWS ONLY.
couldn't able to know the exact reason. Any suggestions would be highly appreciated.
Regards.

hi user582149,
It is difficult to answer you question with such a little amount of details. Could you specify:
- how many facts/dimensions are you using in the query?
- what is the structure of your Business Model?
- which version of OBI are you using?
- what does your log say?
I hope to tell you more having the information above
Cheers

Best practice when FACT and DIMENSION table are the same

Hi,
In my physical model I have some tables that are both fact and dimension table, i.e. in the BMM they are of course separated into Fact and Dim source (2 different units) and it works fine. But I can see that there will be trouble when having more fact tables and I e.g. have a Period dimension pointing to all the different fact tables (different sources).
Seems like the best solution to this is to have an alias of the fact/transaction table and have 2 "copies" of the transaction table (one for fact and one for dimension table) in the physical layer. Only bad thing is that there will then allways be 2 lookups in the same table when fetching data from the dimension and the fact table.
This is not built on a datawarehouse - so the architecture is thereby more complex. Hope this was understandable (trying to make a short story of it).
Any best practice on this? Or other suggestions.

Id recommend creation of a view in the database. if its an oracle DB, materialised views would be a huge performance benefit. you just need to make sure that the MVs are updated when the source is updated.
-Domnic

DMRS_tablename --why these tables are creating

Hi ,
i created a schema and designed the datamodel through the SQL DATA MODELER..after extrating and running the ddl the tables are created perfectly.but many tables in the form of dmrs_tablename are created reduntanly. i dont know why this created.
but im sure these are created after connecting the schema to data modeler tool only.kindly let me know why this are creating, wat are those tables and importance of those tables.
thanks in advance,
Jeevanand.K

Hi Jeevanand,
DMRS_xxx tables are created in "export to reporting schema" functionality. If you don't need reporting repository then go again to "export to reporting schema", select the connection for your schema and you can drop tables using "Drop repository" in maintenance tab.
Philip

Fact tables are resulting in error message

hello experts;
I am trying to create a mock-up report in OBI Answers and somehow Im having a problem with metric columns. When I pick any metric column then I get the: *(No Results: The specified criteria didn’t result in any data)*
I have doubled checked the rpd; the schemas btn the dimension and fact tables looks ok to me. I have tried union with another subject area, I get the same error. Anyone with an idea why fact tables are not collaborating with dimension tables?
will appreciate your help

In case if you are not able to see the logs,
follow this
Saving SET VARIABLE LOGLEVEL=2,DISABLE_CACHE_HIT=1; in a report
Mark correct or helpful if it helps,
Regards,
Veeresh Rayan

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.

How and when does a dimension table gets generated

Hi Gurus,
                 I am new into BI and I will be put into a project within 2 months. I have learned that dimension table contains the sid's of all the charateristics in the dimension table. My conclusions are like
1. Dimension table contains the dim id as the primary key.
2. Dimension table contains sid's of the characteristics.
3. Though sid's in the dimension table are primary keys in thier 'S' table they are not key in the dimension table.
My question is
1. Is there any chance to generate new dim id's for the same combination of sid's because sid's are not part of the key?
2. I got confused when and how does the dimension table gets generated ?
I have searched in the forum and google but still my doubts didnt get clarified. If anyone could throw some light on this topic I would really appreciate it.

HI,
All your conclusions are correct.
Now for your questions the answers are in line:
1. Is there any chance to generate new dim id's for the same combination of sid's because sid's are not part of the key?
    No new dim id's will be generated, dim Id is unique for the same combination of sid's .
2. I got confused when and how does the dimension table gets generated ?
    They get generated when you activate the info provider.
Hope this helps.
thanks,
Rahul

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

Do we have some way to reduce Dimension table size using NLS?

Initially we thought the Cube
archive in NLS would be like:
Replicate Cube in NLS with DAP. DAP creation will create a new structure same like "Star Schema".
While we load data to NLS it deletes from DB.
And hence it reduced size of the DB.
Associated Dimensions will also be replicated in the NLS.
After actually implementation we found :
Fact table size is reducing and DB size with associated E/F fact table is reducing
Dimension tables are still there in DB, and still saving space in DB.
Do we have some other way to reduce Dimension table size using NLS?
As when we are analyzing top 100 tables in SAP BW, we are seeing multiple dimensions are part
of this list.
Thanks,
Jaydip

Hi Jaydip,
Please check below link it might be helpful for you.
http://www.informatik.uni-jena.de/dbis/lehre/ss2011/dbarch/SAP_BW_DB2_NLS_22062011.pdf

Inactive Dimension Tables for Cube

Hi Gurus ,
I am transporting a cube from one system to another and the transport fails becasue the dimension tables are in active in the target system. Now since this system is read only I cannot manually activate it , last resort I even trioed opening the system and activating it and re transported the transport. I get the same error saying that table /BIC/ZXXXXX is inactive.
Can anyone help....please....

hi Sanjeev,
did you change any dimensions in dev ?
like delete some characteristics from existing dimension,
or add new characteristic or move from one to another
dimension ?
if so, you may need to delete production data first,
to avoid this, please change back characteristics to previous dimension, and create a new dimension and add new characteristic to the new create dimension.
another possibility is database problem, try to search oss note for infocube dimension inactive.
hope this helps.

Change dimension tables for an infocube

hello all,
we have an existing cube where a few of the dimension tables are quite big compared to size of fact table. we understand enough about getting the correct dimension table sizes, our question revolves around the existing cube.
meaning, when we make the dimension table changes in dev and transport to val, will the transport be successful with data in the cube (so it will be stored in a format of old dimension table structure)? do we have to dump the cube before transport and then reload after transport successful?
thanks so much!

Hi,
Please check the below link
Re: Cube Transport issue
For remodelling,
http://www.sdn.sap.com/irj/scn/weblogs;jsessionid=(J2EE3417700)ID0196158950DB01648128345571943727End?blog=/pub/wlg/5772
Thanks

Dimension Tables

Hey Guys
How can i check my dimesion tables see the number of recrods or the chars they are storing. Kind of like table structure can i do that for the cube. and If yes anybody has the idea on the transaction code for that.
Thanks

Hi mark,
For every cube Maximum 16 dimension tables can be allocated.In that 16 dimension tables 3 tables are fixed dimensions i.e Datapacket,Time & unit.Remaining 13 dimensions are user can use these dimensions.
To know how many dimension tables are there for each cube,
goto SE11 tcode give /BIC/D"yourcubename"*,it gives you all the dimensions.Userdefined dimension tables are with named as \BIC\D(yourcubename)(1.....13),remaining fixed dimensions will appear as \BIC\D(yourcube name)P[datapacket],\BIC\D(yourcube name)T[time],\BIC\D(yourcube name)U[unit].
Thanks & Regards,
Praveena.

Dimension Table contents are different after cube copy - why?

To all,
I'm doing some work on a cube based on some bad dimensioning in it's original design. We're running BI 3.50 - The original cube is INV_C01 - here is the table contents based upon SAP_INFOCUBE_DESIGNS report -
INV_C01            rows:    243,680    density:              0.0 %
INV_C01            /BIC/DINV_C011      rows:        307    ratio:          0 %
INV_C01            /BIC/DINV_C012      rows:     17,617    ratio:          7 %
INV_C01            /BIC/DINV_C013      rows:         10    ratio:          0 %
INV_C01            /BIC/DINV_C014      rows:          9    ratio:          0 %
INV_C01            /BIC/DINV_C015      rows:         95    ratio:          0 %
INV_C01            /BIC/DINV_C016      rows:         40    ratio:          0 %
INV_C01            /BIC/DINV_C017      rows:          2    ratio:          0 %
INV_C01            /BIC/DINV_C018      rows:      1,737    ratio:          1 %
INV_C01            /BIC/DINV_C019      rows:      7,141    ratio:          3 %
INV_C01            /BIC/DINV_C01A      rows:      1,737    ratio:          1 %
INV_C01            /BIC/DINV_C01B      rows:      1,737    ratio:          1 %
INV_C01            /BIC/DINV_C01P      rows:          2    ratio:          0 %
INV_C01            /BIC/DINV_C01T      rows:         74    ratio:          0 %
INV_C01            /BIC/DINV_C01U      rows:         24    ratio:          0 %
INV_C01            /BIC/EINV_C01       rows:    243,680    ratio:        100 %
INV_C01            /BIC/FINV_C01       rows:          0    ratio:          0 %
The INV_C012 with a 7 % ratio (this is dev, production is much higher) is what I'm working to eliminate - it's too high. I then made a copy of this cube and copied all the data to this copy with no structural changes. I see this now in the copy -
INV_C01_C          rows:    194,720    density:              0.0 %
INV_C01_C          /BIC/DINV_C01_C1    rows:        118    ratio:          0 %
INV_C01_C          /BIC/DINV_C01_C2    rows:      1,755    ratio:          1 %
INV_C01_C          /BIC/DINV_C01_C3    rows:         10    ratio:          0 %
INV_C01_C          /BIC/DINV_C01_C4    rows:          9    ratio:          0 %
INV_C01_C          /BIC/DINV_C01_C5    rows:         95    ratio:          0 %
INV_C01_C          /BIC/DINV_C01_C6    rows:         40    ratio:          0 %
INV_C01_C          /BIC/DINV_C01_C7    rows:          3    ratio:          0 %
INV_C01_C          /BIC/DINV_C01_C8    rows:      1,737    ratio:          1 %
INV_C01_C          /BIC/DINV_C01_C9    rows:      1,737    ratio:          1 %
INV_C01_C          /BIC/DINV_C01_CA    rows:      1,737    ratio:          1 %
INV_C01_C          /BIC/DINV_C01_CB    rows:      1,737    ratio:          1 %
INV_C01_C          /BIC/DINV_C01_CP    rows:          2    ratio:          0 %
INV_C01_C          /BIC/DINV_C01_CT    rows:         73    ratio:          0 %
INV_C01_C          /BIC/DINV_C01_CU    rows:         13    ratio:          0 %
INV_C01_C          /BIC/EINV_C01_C     rows:          0    ratio:          0 %
INV_C01_C          /BIC/FINV_C01_C     rows:    194,720    ratio:        100 %
Note that INV_C01_C2 now only has 1,755 rows, whereas the source cube has 17,617 rows. Why is this? I did a straight copy and the F table has approximately 50k less rows and this table is approx 10 percent of the source.
Any explaination would be appreciated.   Ken

Was data ever deleted from the first cube? Either using selective deletion, or possilbly just the deletion of a Request. Those dim IDs wouldn't be recreated in the cube copy. There is an RSRV test that checks for unused Dim IDs and can delete them if you want.
If you use the option to load packets in parallel, it can lead to multiple Dim IDs being created for the same characteristic combination. There is an RSRV check for duplicate Dim IDs, which can eliminate the duplicate Dim IDs if you tell it to.
One other thin got keep in mind - SAP INFOCUBE_DESIGNS is using data from DB stats to provide the row counts, so if your DB stats for the dim table are not current, you could be seeing row counts that are old.

In BAPI's why the structures are used in table parameters?

Hello sir,
what is BAPI sir? In BAPI's why the structures are used in table parameters? table parameters they are using structures but not using any customized tables ?
regards
rachu.

Hello Rachu
BAPIs provide RFC-enabled interfaces to SAP business objects (e.g. like customer, sales order, purchase order, etc.).
A BAPI does basically the same like you would need to do calling the corresponding transaction (e.g. BAPI_SALESORDER_CREATE -> VA01).
Since they are RFC-enabled they can be called from external systems.
BAPIs represent an external interface for the outside world. Very often you will find within the BAPI that there is a mapping done to the (SAP-)internal structures at the beginning of the coding and vice versa at the end of the coding. Thus, you will (almost) never find any DB table name used as type of a BAPI TABLES parameter.
Regards
Uwe

Why dimension tables are denormalized?

Similar Messages

Maybe you are looking for