Question on Dimension Table

When we delete a request on a InfoCube, the information not necessary on the Dimension Table does not canceled. For example if we delete all the data about year 2003 on a InfoCube, the information about 2003 continuous to alive on time dimension table.
Do you know if exists a program or some method to delete the information from the Dimension Table not used on FACTTABLE?
Best regards,
Nicola Commari

Nicola,
Navigate to transaction RSRV, there exists a test which you can run
"Entries not Used in the Dimension of a cube" which will help you repair the issue you are currently experiencing.
Hope this helps.
Cheers,
Scott

Similar Messages

Static and small dimension table should I use lookup

Hi Gurus,
I am creating interface to load my fact table.
Generally for different codes to replace with surrogate keys I use dimension table for look-up in interface.
but I have question if dimension table is very small and has only static values like
Sur_key, Code, Description.
1, C, Create
2 , R, Redeem
in such case if in interface for fact table, I just write expression "if source_table.column=C then 1 else 2".
Please advice if this is better way or not.
Thanks in advance.

I agree - it is much better practice to use lookups to populate surrogate keys. Using hard-coded values in code requires the developer to always remember that dependency on dimensional data and can cause unexpected results down the line if the keys are updated or are inconsistent across environments.

Dimension table design Data modeling question

Hi Experts,
Sorry if I am putting my question in a wrong forum and please suggest an appropriate forum.
need your opinion on the existing design of our 10 years old datawarehouse.
There is one dimension table with structure like following
Dimension Table
Dimension Key Number (THIS IS NOT A PRIMARY KEY)
Natural key (from source) Number
source name character
current record indicator char(1)
form_date date
to_date date
many other columns, which if change a new current record is created and previous is marked as H-historical
Data is stored in the dimension table like this
Dimension_key Natural key Source Name current record ind from_date to_date
1 10001 Source1 H 1-jan-2005 31-may-2005
1 10001 Source1 H 1-jun-20005 12-dec-2011
1 10001 Source1 C 13-dec-2011 NULL
2 20002 Source1 H 1-jun-20001 12-dec-2011
2 20002 Source1 C 13-dec-2011 NULL
The problem I see in this design is that there is no surrogate key, if any attribute is changed the new record is inserted by first taking the dimension key based on the (natural_key,source_name,current_record_ind).
Shouldn't it be stored like following based on the data-warehousing principals.
Dimension_key Natural key Source Name current record ind from_date to_date
1 10001 Source1 H 1-jan-2005 31-may-2005
2 10001 Source1 H 1-jun-20005 12-dec-2011
3 10001 Source1 C 13-dec-2011 NULL
4 20002 Source1 H 1-jun-20001 12-dec-2011
5 20002 Source1 C 13-dec-2011 NULL
Please let me know the pros and cons of the current design.

And what if you have both the features something like this :
Lineno Dimension_key Natural key Source Name current record ind    from_date         to_date
     1              1       10001     Source1                  H   1-jan-2005     31-may-2005
     2              1       10001     Source1                  H 1-jun-20005     12-dec-2011
     3              1       10001     Source1                  C 13-dec-2011            NULLI mean just add a new column and populate it with required order by clause. Because what i guess, that in the second example you just added a new column which is something like a line number.
Regards
Girish Sharma

In Answers am seeing "Folder is Empty" for Logical Fact and Dimension Table

Hi All,
Am working on OBIEE Answers, on of sudden when i clicked on Logical Fact table it showed me as "folder is empty". I restarted all the services and then tried still showing same for Logical Fact and Dimension tables but am able to see all my reports in Shared Folders. I restarted the machine too but no change. Please help me out to resolve this issue.
Thanks in Advance.
Regards,
Rajkumar.

First of all, follow the forum etiquette :
http://forums.oracle.com/forums/ann.jspa?annID=939
React or mark as anwser the post that the user gave.
And for your question, you must check the log for a possible corrupt catalog :
OracleBIData_Home\web\log\sawlog0.log

Help on Setting logical Levels in Fact tables and on Dimension tables

Hi all
Can any body provide any blogs or any king of material on what exactly is levelling .
Like after creating the Dimensional hierarchies we need to set the logical levels for the LTS of fact tabels ri8 .So what is the difference between setting logical levels to fact tabels and also Setting levelling on Dimension tables .
Any kind of help is appreciated
Thanks
Xavier.
Edited by: Xavier on Aug 4, 2011 10:50 AM

I have read these blogs ,but what my question is
Setting the logical levels in LTS of Fact tables i understood .
But we can also set the logical levels for dimensions also ri8 .I didn't understand why do we set the logical levels for dimensions .Is there any reason why we go with the levelling at dimensions
Thanks
Xavier
Edited by: Xavier on Aug 4, 2011 2:03 PM
Edited by: Xavier on Aug 4, 2011 2:32 PM

Multiple columns from the same dimension table as row labels performing slowly

(Working with SSAS tabular)
I'm trying to figure out what the approach should be for the following scenario:
Lets say we have a Customer table. The table has columns such as account number, department number, name, salesperson, account manager, number of customers, delivery route, etc
A user of the model could want to see any permutation of that information as the row labels. How should that be handled?
What we've been doing so far is that the user adds each column they want into the "ROWS" section in Excel. This works fine with smaller tables (for example, "Department" table with a "Department Code" and "Department Name",
but on large tables this quickly chokes. I understand why this is happening, I just haven't found a better way to accomplish the same thing.
I can add a calculated column to the model through VS, but obviously this is unsupportable and unscalable when each person needs their own permutations of the data. Can something similar be done in Excel?
This question seems to be what I need:
http://social.msdn.microsoft.com/Forums/en-US/97d1157a-1402-4227-b96a-79524401ddcd/mdx-query-performance-when-selecting-multiple-attributes-from-same-dimension?forum=sqlanalysisservices
However I can't find any information on how to add those properties (is it a multidimensional-only thing?)

Thanks for the help. Sorry but i'm a self-taught developer, and i may be missing some basics :)
Anyway i've done what you suggested but i get this error:
[nQSError: 15011]The dimension table source Dimension Services.DM_D_SERVIZI_SRV has an aggregate content specification that specifies the level Product. But the source mapping contains column COD_PRODUCT with a functional dependency association on a more detailed level .
where:
- DM_D_SERVIZI_SRV is the physical alias for the Service Dimension (and the name of the LTS too)
- COD_PRODUCT is the leaf of the hierarchy, the physical primary key, but it hasnt to be included in the hierarchy
Do i have to add another level with the primary key and hide it to the users?
I tried to solve this going to the logical tables source properties, on the tab contents, setting "logical level" to null for the hierarchy, but i don't know if this is correct.
Thanks

What is '#Distinct values' in Index on dimension table

Gurus!
I have loaded my BW Quality system (master data and transaction data) with almost equivalent volume as in Production.
I am comparing the sizes of dimension and fact tables of one of the cubes in Quality and PROD.
I am taking one of the dimension tables into consideration here.
Quality:
/BIC/DCUBENAME2 Volume of records: 4,286,259
Index /BIC/ECUBENAME~050 on the E fact table /BIC/ECUBENAME for this dimension key KEY_CUBENAME2 shows #Distinct values as 4,286,259
Prod:
/BIC/DCUBENAME2 Volume of records: 5,817,463
Index /BIC/ECUBENAME~050 on the E fact table /BIC/ECUBENAME for this dimension key KEY_CUBENAME2 shows #Distinct values as 937,844
I would want to know why the distinct value is different from the dimension table count in PROD
I am getting this information from the SQL execution plan, if I click on the /BIC/ECUBENAME table in the code. This screen gives me all details about the fact table volumes, indexes etc..
The index and statistics on the cube is up to date.
Quality:
E fact table:
Table   /BIC/ECUBENAME
Last statistics date                  03.11.2008
Analyze Method               9,767,732 Rows
Number of rows                         9,767,732
Number of blocks allocated         136,596
Number of empty blocks              0
Average space                            0
Chain count                                0
Average row length                      95
Partitioned                                  YES
NONUNIQUE Index   /BIC/ECUBENAME~P:
Column Name                     #Distinct
KEY_CUBENAMEP                                  1
KEY_CUBENAMET                                  7
KEY_CUBENAMEU                                  1
KEY_CUBENAME1                            148,647
KEY_CUBENAME2                          4,286,259
KEY_CUBENAME3                                  6
KEY_CUBENAME4                                322
KEY_CUBENAME5                          1,891,706
KEY_CUBENAME6                            254,668
KEY_CUBENAME7                                  5
KEY_CUBENAME8                              9,430
KEY_CUBENAME9                                122
KEY_CUBENAMEA                                 10
KEY_CUBENAMEB                                  6
KEY_CUBENAMEC                              1,224
KEY_CUBENAMED                                328
Prod:
Table   /BIC/ECUBENAME
Last statistics date                  13.11.2008
Analyze Method                      1,379,086 Rows
Number of rows                       13,790,860
Number of blocks allocated       187,880
Number of empty blocks            0
Average space                          0
Chain count                              0
Average row length                    92
Partitioned                               YES
NONUNIQUE Index /BIC/ECUBENAME~P:
Column Name                     #Distinct
KEY_CUBENAMEP                                  1
KEY_CUBENAMET                                 10
KEY_CUBENAMEU                                  1
KEY_CUBENAME1                            123,319
KEY_CUBENAME2                            937,844
KEY_CUBENAME3                                  6
KEY_CUBENAME4                                363
KEY_CUBENAME5                            691,303
KEY_CUBENAME6                            226,470
KEY_CUBENAME7                                  5
KEY_CUBENAME8                              8,835
KEY_CUBENAME9                                124
KEY_CUBENAMEA                                 14
KEY_CUBENAMEB                                  6
KEY_CUBENAMEC                                295
KEY_CUBENAMED                                381

Arun,
The cube in QA and PROD are compressed. Index building and statistics are also up to date.
But I am not sure what other jobs are run by BASIS as far as this cube in production is concerned.
Is there any other Tcode/ Func Mod etc which can give information about the #distinct values of this Index or dimension table?
One basic question, As the DIM key is the primary key in the dimension table, there cant be duplicates.
So, how would the index on Ftable on this dimension table show #distinct values less than the entries in that dimension table?
Should the entries in dimension table not exactly match with the #Distinct entries shown in
Index /BIC/ECUBENAME~P on this DIM KEY?

[39008] Logical dimension table has a source that does not join to any fact

Dear reader,
After deleting a fact table from my physical layer and deleting it from my business model I'm getting an error: [39008] Logical dimension table TABLE X has a source TABLE X that does not join to any fact source. I do have an other fact table in the same physical model and in the same business model wich is joined to TABLE X both in the physical and business model.
I cannot figure out why I'm getting this error, even after deleting all joins and rebuilding the joins I'm getting this error. When I look into the "Joins Manager" these joins both in physical as well as logical model do exist, but with consistency check it warns me about [39008] blabla. When I ignore the warning and go to answers and try to show TABLE X (not fact, but dim) it gives me the following 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: 14026] Unable to navigate requested expression: TABLE X.column X Please fix the metadata consistency warnings. (HY000)
SQL Issued: SELECT TABLE X.column X saw_0 FROM subject area ORDER BY saw_0
There is one *"special"* thing about this join. It is a complex join in the physical layer, because I need to do a between on dates and a smaller or equal than current date like this example dim.date between fact.date_begin and fact.date_end and dim.date <= current_date. In the business model I've got another complex join
Any help is kindly appreciated!

Hi,
Have you specified the Content level of the Fact table and mapped it with the dimension in question? Ideally this should be done by default since one of the main features of the Oracle BI is its ability to determine which source to use and specifying content level is one of the main ways to achieve this.
Another quick thing that you might try is creating a dimension (hierarchy) in case it is not already present. I had a similar issue few days back and the warning was miraculously gone by doing this.
Regards

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

Delete Fact and Dimension Tables

Hai All,
Small question! When deleting data from info cube, it asks whether to delete just Dimension table or both fact and Dimension tables.
What is the difference between these two?
Thank you.

Hi Visu,
The dimension table will contain the references to char value by way of SID and DIM ids, whereas the fact table will contain the number (of key figures). If you delete just the Fact table, the numbers go away, yet the DIM ids remain intact, so reload is faster. But if you are convinced that this data is not correct either, or you want a clean slate to strat reload again, then delete both Fact and Dim tables. Then when you reload, the DIM ids will be created again.
Hope this helps...

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.

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

[39008] Logical dimension table X has a source

Hi
I have a Fact table with some dimensions. If I add a detail table to that Fact table I get:
[39008] Logical dimension table X has a source
Y that does not join to any fact
source.
For each dimension that I had.
Is this possible to model?. To have a fact that have details. I want to create pivot tables with the fact table, and some tables for the fact/detail relationship.
Regards,
Néstor Boscán

Hi..
Sorry to say this, i didn't understand your question properly..
But as per i understood,
your logical table is mixed of measures as well as dimension columns...
In this case, need to concentrate on rpd, business model development...
Need to divide the table into fact as well as dimension table in BMM...
All measures corresponding to table will located in fact table and remaining all dimensions will be in dimension table...
This is the best way of developing rpd..
Thanks & Regards
Kishore Guggilla

Urgent-Issue in the Dimension tables

Hi Experts,
Question1:
I have a flat file load to a cube.this flat file has 1.5 mil records.One of the dimension created has a 2 dates(original date & current date) assigned.
When i look at dimension table for # entries is 30million.And when i look at the table i see the sids as 0,0 ( for 2 dates) and dim id's being creted.
When i did a search on the dimension table with current date & original date as not equal to 0.I see only 76,000 records.
Question 2:
we have an ODS which loads to the cube.In the process chain we have program that deletes the data in ods which does not match some conditions and then loads it tot he cube.
My question is,since we are not deleting contents from the cube and reloading it from the ODS(Full update).Will i not be seeing same records coming in with Full update which get agrregated in the cube.
Ex: i have a record in ODS.
A   X Z 100 1000
After full update to the cube,the cube would have
A   X Z 100 1000
When i run the process chain and data is dleeted from ODS on some condition and i still have hte same record in ODS and when this loads into cube wont this be aggregated with the previous record.
A X   Z 200 2000
Would appreciate,if anyone could explain if i am missing anything.

Hello,
If you can't see the SID means you have not loaded the master data, that why there is no reference to the SID table and the values are 0.
InfoCube by default will have aggregated values, when there are duplicate records on the Keyfigures will be aggregated.
For example I have a Material Dimension and Customer Dimension
In the fact table, it will be like this
DIM1     DIM2    KF1   KF2
Mat001 Cust1 100    10
Mat001 Cust2 200    5
for this there will be 1 entry in Material DIM table for Mat001 and 2 entries for Customer DIM table for Customer Cust1 and Cust2.
Material Dimension
DIM ID    SID
1             Mat001 (Here it will be SID from Material Master)
Customer Dimension
1             Cust1 (Here it will be SID from Customer Master)
2             Cust2 (Here it will be SID from Customer Master)
Note : DIM ID is the combination of one or more SID in the dimension table.
So the exact fact table will look like
MATDIM    CUSDIM       AMT      QTY
1               1                  100        10
1               2                  200        5
If you load the data again with same characteristics values then the key figure will be aggregated
Example if you load
Mat001 Cust2 25 5
then the fact table will not have a new entry instead the it will aggregates and looks like (bolded one)
MATDIM    CUSDIM       AMT      QTY
1               1                  100        10
1               2                  220        10
Hope its clear
thanks
Chandran

Question on Dimension Table

Similar Messages

Maybe you are looking for