[Rookie] Some clarification on Dimension Table

Hi!
I am preparing for BW certification, and sorry to post this very basic query. On certification notes, I came accross a statement that says - "Dimension table contains link to fact table and SID table".
I think this statement is wrong. Dimension table has DIM-ID & SID-Ids so there is no link to fact table in dimension table.
Please give your comment on this.

hi,
should true/correct, check
http://help.sap.com/bp_biv335/BI_EN/documentation/Multi-dimensional_modeling_EN.doc
page 11
... These dimension tables surround the fact table, which contains the facts (key figures), and are linked to that fact table via unique keys, one per dimension table. Each dimension key uniquely identifies a row in the associated dimension table....
hope this helps.

Similar Messages

Truncate always checked for the some of the dimension tables

Hi,
I found common dimension tables across Finance,Supply Chain and Sales by querying in DAC.
In the task level most of the target tables checked as Truncate For Full Load.
but some of the tables defined as truncate always, why they defined as truncate always is there any specific reason for that.
Truncate Always Dimension Tables List:
W_FSCL_MONTH_D
W_FSCL_QTR_D
W_FSCL_WEEK_D
W_FSCL_YEAR_D
W_HOUR_OF_DAY_D
W_MONTH_D
W_QTR_D
W_TIME_OF_DAY_D
W_WEEK_D
W_YEAR_D
Thanks and Regards,
Partha.

Hi,
If they are defined as truncate always it is because the mapping which loads the table is always filling it with a full set of data not an incremental. If the table wasn't truncated every time then the data would not be correct after an ETL.
You can see from that list that they are all time defined tables which are being truncated. These can be truncated and refilled without worry of breaking data integrity because the ROW_WIDs for these tables are not truly surrogate keys, they hold some meaning. So for instance the row_wid for the row for Jan 1980 in W_MONTH_D is 198001 and it will always have this same ROW_WID after each ETL, meaning the dimensions can be truncated and fully rebuilt without invalidating any joins to it from fact tables.
Regards,
Matt

Identify high volume characteristics in dimension tables

Hi,
We have identified some cubes where dimension table to fact table ratio is more than 20%.
Now further step is to find out characteristics in those dimension tables which we can either make as line item dimension or
move to new dimension.Is there any function module or table which can identify such characteristics for particular cube?
Regards,
Shital

Hi,
LISTSCHEMA won't give you the size of the tables nor the option to analyze the dimensions in detail.
Similarly, SAP_INFOCUBE_DESIGN won't give you the detail of what's inside a dimension. It just gives you the size of the dimension.
The only way(as far as i know) to do it is as i suggested in earlier posts - get your dimension table to your DBA. It will take 2 minutes for them to find out.
Please correct me if I am wrong.
-RMP

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

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

Logical dimension table

Hi All,
I am creating logical columns using two logical dimensions in a separate logical table. Do I need create complex joins for the new logical table, two source logical dimension tables have complex joins created already. Could you anyone provide some clarification on this.
Thanks in advance,
RK

As mma1709 mentioned,
you must be careful with the joins of this new logical table with your fact...
When you check for errors in the administrators,are there any??
if no,at any report with this column you have any problems??
hope i helped....
http://greekoraclebi.blogspot.com/
///////////////////////////////////////

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

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

Should my dimension table be this big

Im in the process of building my first product dimension for a star schema and not sure if im doing this correctly. A brief explanation of our setup
We have products (dresses) made by designers for specific collections each of which has a range of colors and each color can come in many sizes. For our UK market this equates to some 1.9 million
product variants. Flattening the structure out to Product+designer+collection gives about 33,000 records but when you add all the colors and then all the colors sizes it pumps that figure up to 1.9million. My “rolled own” incremental ETL load runs
ok just now, but we are expanding into the US market and our projections indicate that our products variants could multiple 10 fold. Im a bit worried about performance of the ETL just now and in the future.
Is 1.9m records not an awful lot of records to incrementally load (well analyse) for a dimension table nightly as it is never mind what that figure may grow to when we go to US?
I thought of somehow reducing this by using a snowflake but would this not just reduce the number of columns in the dimensions and not the row count?
I then thought of separating the colors and size into their own dimension, but this doesn’t seem right as they are attributes of products and also I would lose the relationship between products, size & color I.e. I would have to go through the
fact table (which ive read is not a good choice.) for any analysis.
Am I correct in thinking these are big numbers for a dimension table? Is it even possible to reduce the number somhow?
Still learning so welcome any help.
Thanks

Hi Plip71,
In my opinion, It is always good to reduce the Dimension Volume as much as possible for better performance.
Is there any Hierarchy in you product Dimension?.. Going for a snowflake for this problem is a bad idea..
Solution 1:
From the details given by, It is good to Split the Colour and Size as seperate dimension. This will reduce the vloume of dimension and increase the column count in the fact(seperate WID has to be maintained in the fact table). but, this will improve the
performance of the cube. before doint this please check the layout requirement from the business.
Solution 2:
Check the distinct count of Item varient used in fact table. If it is very less, they try creating a linear product dimension. i.e, create an view for the product dimension doing a inner join with the fact table. so that only the used Dimension member will
be loaded in the Cube Product Dimension. hence volume is reduced with improvement in performance and stability of the cube.
Thanks in advance, Sorry for the delayed reply ;)
Anand
Please vote as helpful or mark as answer, if it helps Regards, Anand

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.

Consistency Warning: [39008] Logical dimension table ... has a source ...

Hi and many thinks for reading,
I have a problem (which is quite common as I saw, though I could'nt find a solution which resolves my issue yet) with the consistency.
My physical layer looks like this:
Table_A
Table_B
Table_C
Table_D
Table_E
In the Business Model I have just the same tables and the following joins in the Logical Table Diagram:
Table_A -> Table_B
Table_C -> Table_A
Table_D -> Table_A
Table_E -> Table_A
The consistency check is delivering the following two warnings:
Warning
Logical Table Source
Table_A
[39008] Logical dimension table Table_A has a source Table_A that does not join to any fact source.
Warning
Logical Table Source
Table_B
[39008] Logical dimension table Table_B has a source Table_B that does not join to any fact source.
While working in BI answers I manage to retrieve all data from Tables C, D, E. But for tables A and B I can retrieve just the columns which are defined in the join Table_A->Table_B. All other columns deliver the following error:
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_A.Column_X. Please fix the metadata consistency warnings. (HY000)
If i retrieve one Column from Table_A and one from Table_E, I have the following error:
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table Table_E) does not contain mapping for [Table_B.Column_X]. (HY000)
(yes its Table_B not a)
I would like to fix this errors but am not sure where the problem is hidden.
Any help is kindly appreciated.
Evgeny

Hi Goran,
thanks for you help.
I tried to create the BMM in the two way but, it doesn't work out neither way. The Administration tool is recognizing the repository as consistent, thought it has some warnings, but in BI Answers I cant retrieve even a single column from one table.
I am also not sure, how does it work, that you just add TableB to the logical TableA, who would the programm know which rows belong together? I assume one must establish a logical connection between TableA and TableB to make it compatible?
About my tables:
Actually TableA, TableB and TableC are recognized dimensions (white) and TableD and TableE are recognized as facts (yellow) in the Administration tool. Though I dont agree with this assignment. TableA is definitly a fact table (it is also the center of the star schema) while the other tables are the dimension tables. Not sure how the Administration tool is distinguishing between facts and dimensions...
Here are my warnings:
BUSINESS MODEL TAB: (with two logical tables)
[39008] Logical dimension table TableA has a source TableA that does not join to any fact source.
[39008] Logical dimension table TableA has a source TableB that does not join to any fact source.
BUSINESS MODEL TACDE: (with three logical table sources)
[39008] Logical dimension table LT2 has a source TableE that does not join to any fact source.
[39008] Logical dimension table LT2 has a source TableD that does not join to any fact source.
[39008] Logical dimension table LT2 has a source TableC that does not join to any fact source.
And the errors in Answers:
Retrieving ColumnX from TableA in the first model
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: TableA.ColumnX. Please fix the metadata consistency warnings. (HY000)
Retrieving ColumnX from TableA in the second model
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 17001] Oracle Error code: 12170, message: ORA-12170: TNS:Connect timeout occurred at OCI call OCIServerAttach. [nQSError: 17014] Could not connect to Oracle database. (HY000)
Thanks for further help!
Evgeny

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.

Dimension key 16 missing in dimension table /BIC/DZPP_CP1P

Hi all,
I have a problem with an infocube ZPP_CP1. I am not able to delete nor load any data. It was working fine till some time back.
Below is the outcome of running RSRV check on this cube. I tried to run the error correction in RSRV. But n o use
Please help.
Dimension key 16 missing in dimension table /BIC/DZPP_CP1P
Message no. RSRV018
Diagnosis
The dimension key 16 that appears as field KEY_ZPP_CP1P in the fact table, does not appear as a value of the DIMID field in the dimensions table /BIC/DZPP_CP1P.
There are 17580 fact records that use the dimension key 16.
The facts belonging to dimension key 16 are therefore no longer connected to the master data of the characteristic in dimension.
Note that errors that are reported for the package dimension are not serious (They are thus shown as warnings (yellow) and not errors (red). When deleting transaction data requests, it can arise that the associated entries in the package dimension have already been deleted. As a result, the system terminates when deleting what can be a very large number of fact records. At the moment, we are working on a correction which will delete such data which remains after deletion of the request. Under no circumstances must you do this manually. Also note that data for request 0 cannot generally be deleted.
The test investigates whether all the facts are zero. If this is the case, the system is able to remove the inconsistency by deleting these fact records. If the error cannot be removed, the only way to re-establish a consistent status is to reconstruct the InfoCube. It may be possible for SAP to correct the inconsistency, for which you should create an error message.
Procedure
This inconsistency can occur if you use methods other than those found in BW to delete data from the SAP BW tables (for example, maintaining tables manually, using your own coding or database tools).

Hi Ansel,
There has been no changes in the cube. I am getting this problem in my QA server. So I retransported the cube again from Dev to QA. But did not help me..
Any other ideas??
Regards,
Adarsh

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

Resolving loops in a star schema with 5 fact tables and 6 dimension tables

Hello
I have a star schema, ie 5 FACT tables and 7 dimension tables, All fact tables share the same dimension tables, some FACT tables share 3 dimesnsions, while other share 5 dimensions.
I did adopt the best practices, and as recommended in the book, I tried to resolve them using Context, as it is the recommended option to Alias in a star schema setting. The contexts are resolved, but I still have loops. I also cleared the Multiple SQL Statement for each context option, but no luck. I need to get this resoved ASAP

Hi Patil,
It is not clear what exactly is the problem. As a starting point you could set the context up so that it only covers the joins from fact to dimension.
Fact A, joins Dim 1, Dim 2, Dim 3, and Dim 4
Fact B, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 5
Fact C, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 6
Fact D, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 7
Fact E, joins Dim 1, Dim 2, Dim 4 and Dim 6
If each of these are contexts are done and just cover the joins from fact to dim then you should be not get loops.
If you could lay out your joins like above then it may be possible to specify the contexts/aliases that should work.
Regards
Alan

[Rookie] Some clarification on Dimension Table

Similar Messages

Maybe you are looking for