Max no of characteristics in a fact table???

hi guys...
can u please tell whether the max charcteristics(248) that can be accomadated, is it per dimension or in the entire fact table...
please share your views..
regards,
sagar

Dear Sagar,
Dim Table:
1 is for DIM ID
Max 248 Chars in Dimension Table.
6 are reserved for SAP
Fact Table:
233 Key Figs
16Keys to Dimensions ( DIM IDs)
6 fields are reserved for SAP.
Regards,
Ram.

Similar Messages

No Message: Write to Fact table.

Hi ALL,
Source: ECC 6
Target: BI 7.3
We are Transferring 2LIS_13_VDITM Datasource---->> 0SD_CO3 Infocube .
After Data Replication ,
1. Data Transferred to PSA .
2. During Transformation Creation Manuel Mapping is performed . Activated .
3. During DTP Creation Only Following Warning Messages Occur , Status s not Transferred to Green .
Data is not coming Cube , No Error Messages. (Totally 29000 Records have to transfer to BI Cube)
Warning Messages are,
1.No Message: Write to Fact table.
2.No Message:Infocube Update Completed .
What is the Problem?

Hi,
Have you set the Industroy sector before uploading the set up tables?
For more information refer the note: 353042
Summary
Symptom
Fields BWGEO, BWGEOO, BWGVP, BWGVO, BWNETWR, BWMNG, etc. of DataSources 2LIS_02_SCL, 2LIS_02_ITM, 2LIS_03_BF, 2LIS_03_UM, 2LIS_40_REVAL are not filled.
This may lead to the following:
The system does not perform any update into an InfoCube (for example: 0RT_C*, 0PUR_C01, 0CP_PURC1 and so on), even though data arrives in BW.
This occurs with the following InfoSources:
2LIS_02_SCL, 2LIS_02_ITM
2LIS_03_BF, 2LIS_03_UM
2LIS_40_REVAL
With some restriction, this symptom also occurs with the following InfoSources if they are used in connection with retail or consumer products. (InfoCube: 0RT_* or 0CP_* ).
2LIS_11_VAITM, 2LIS_12_VCITM, 2LIS_13_VDITM
Other terms
0PROCESSKEY, PROCESSKEY, 0RT_C01, 0RT_C02, 0RT_C03, 0RT_C04, BWBRTWR, BWGEO, BWGEOO, BWGVP, BWGVO, BWNETWR, BWMNG
Reason and Prerequisites
The process key (0PROCESSKEY and 0BWAPPLNM) of the InfoSources has not been filled. As a result, no key figures are updated because of the update routine of the participating InfoCube and along with it no records are inserted into the InfoCube. In each update routine, the system checks the content of the PROCESSKEY. If this field has no contents, then no data is written into the InfoCube because of the IF condition in the update rules.
Solution
So that you can work in the above mentioned InfoSources, you MUST activate the determination of the process key. This is done with the help of Transaction MCB_ which you can find in the OLTP IMG for BW (Transaction SBIW) in your attached R/3 source system.
Here you can choose your industry sector. 'Standard' and 'Consumer products' are for R/3 standard customers, whereas 'Retail' is intended for customers with R/3 Retail only.
You can display the characteristics of the process key (R/3 field BWVORG, BW field 0PROCESSKEY) by using Transaction MCB0.
If you have already set up historical data (for example for testing purposes) by using the setup transactions (Statistical Setup Programs) (for example: Purchasing: Tx OLI3BW, material movements: OLI1BW) into the provided setup tables (for example: MC02M_0SCLSETUP, MC03BF0SETUP), you unfortunately have to delete this data (Tx LBWG). After you have chosen the industry sector by using MCB_, perform the setup again, so that the system fills a valid transaction key for each data record generated. Then load this data into your connected BW by using 'Full update' or 'Initialization of the delta process'. Check, whether the system updates data into the involved InfoCubes now.
If all this is not successful, please see Note 315880, and set the application indicator 'BW' to active using Transaction 'BF11'.
Related notes:
157317 --> You MUST make sure that this note is relevant for you.
352344 -> Process key + reversals in Inventory Management
(Consulting note).
Regards,
Anil Kumar Sharma .P

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.

What is correct way to join a start/end date driven dimension to a fact table in data foundation?

I have a bad universe or a data design issue.
Several versions of hierarchies reporting store entities in reporting Fact measures.
Example of date driven Hierarchy Dimension:   ORG_KEY
                                                                            START_DATE
                                                                            END_DATE
                                                                            STORE_NUMBER
                                                                            ORG_HIERARCHY
                                                                            CURR_FLG   (Y/N)
Fact table :                                                         ORG_KEY
                                                                             CALENDAR_KEY
                                                                             TRANS_DATE
                                                                             $amount
Calendar Dimension:                                            CALENDAR_KEY
                                                                              DAY_DATE
                                                                               FY_WEEK          (201452)
                                                                                FY_PERIOD      (201412)
                                                                                FY_QUARTER   (201401)
                                                                                 FISCAL_YEAR    (2014)
Users WISH:
Wish for store number and org hierarchy to pull as of the last day of each pull without prompt.    The Store(ORG_KEY) as in the fact table; but the ORG_HIERARCHY and other attributes as of the last day they pull.
Daily (Would be Calendar.Day_Date in Filter) ,
Week to date (would be Max Calendar.Day_Date for (201452) FY_WEEK as entered,
Month to date,
Year to date,
AdHoc queries.
My problem is I see how they could manually pull this in Webi.   I have tried everything I know to join to no avail. I have not gotten @Prompts to work in joins, derived tables, etc. in the data foundation. Wonder what is difference between parameter in Data foundation vs. filter in buisness layer.    None of them worked.
Please help!   ANY ideas would be appreciated.   .

{Note that abbrevations in brackets are just for short form further down the answer}
Join Store Dim (SD) to Transaction Fact (TF) on ORG_KEY=ORG_KEY with 1 to Many cardinality
Create an alias of Calendar Dim and call it Transaction Date (TD)
Join TD to TF on TD.CALENDAR_KEY=TF.CALENDAR_KEY with 1 to Many cardinality
Create a predefined condition in your universe called "Return Yesterday's Transactions" as:
TD.DAY_DATE = trunc(sysdate-1) <-- That assumes Oracle database; use whatever is correct for yesterday for your RDBMS
The above predefined condition when added to your data query will return only yesterday's transactions.
However, if you want to return all the different types of sales, you would need an object for each one. To do that, you'd use a case statement. Again, using Oracle syntax, an example of MTD would be:
SUM(CASE WHEN trunc(TD.DAY_DATE,'yyyymm') = trunc(sysdate,'yyyymm') THEN TF.amount END)
If you have any more questions about how this approach would work please shout.
As an alternative, you could create a time hierarchy and add scope of analysis to your report for it and enable drilling at report level.

Why is the FactAdditionalInternationalProductDescription a fact table in the AdventureworksDW2008R2 database?

Was wondering why this table is a fact table in the AdventureworksDW2008r2 database? It has no measures that I can tell.
Here is the schema for the table....
[ProductKey] [int] NOT NULL,
[CultureName] [nvarchar](50) NOT NULL,
[ProductDescription] [nvarchar](max) NOT NULL

Yes, I think it should be a dimension also.
The dimDate table has translation for month, dyas, etc in other languages. They don't put those translations in a fact table. Also, fact tables have measures, you can not perform math on those columns except maybe count...
The only thing I could think of is maybe it is some sort of intermidiate table... like if you have a many to many and need a one to many for SSAS, but still trying to wrap my head around some of these concepts.
I have just been studying this stuff for about a year or so, so wasn't sure. Studying for 70-463 hope to get MCSE someday too.
Mike

Multiple fact tables, aggregation and model problems

Hi,
I am developing a OLAP Application with 2 dimensions (product,location) and a few measures (sales_qty, sales_value, sale_price, cost_price, promotion_price, average_market_price, etc). I also have a BiBean Crosstab to explore the data.
I'm having the following problems:
- The measures are in different fact tables.
When using cwm2_olap_table_map.Map_FactTbl_Measure, I can only map the measures from the first fact table, the others return "Exact fetch returns more than the request number of rows".
- The 'price_' measures shouldn't aggregate to higher levels of the dimension hierarchies. I have changed the default aggregation plan, but in the crosstab data is still shown in the higher levels. Is there any way to show N/A in levels that I don't want to aggregate?
- How can I add a calculated field that is the result of a complex set of business rules (with IF/THEN/ELSE statements and calls to existing oracle functions) and precalculate it during batch?
Thanks,
Ricardo

Keith, thanks for the quick answer!
Some questions regarding your comments:
1) The measures are in different fact tables
- My application will show all the measures in the same report. My question is, will performance be affected by creating separate cubes or creating one cube? I believe that if I don't use an AW, it shouldn't, but I will have an AW. Performance is the main reason why I'm using Oracle OLAP. I need fast access to measures in different fact tables in one report. Those measures will be used in complex calculated fields, and probably in 'what if' analysis.
2) When using cwm2_olap_table_map.Map_FactTbl_Measure, I can only map the measures from the first fact table, the others return "Exact fetch returns more than the request number of rows".
Here is the complete script I am using to create the cube:
execute cwm2_olap_cube.Create_Cube('OLAP','CUBE_REL_3','CUBE_REL_3','MY_CUBE','MY_CUBE');
execute cwm2_olap_cube.add_dimension_to_cube('OLAP', 'CUBE_REL_3','OLAP', 'DIM_STORE');
execute cwm2_olap_cube.add_dimension_to_cube('OLAP', 'CUBE_REL_3','OLAP', 'DIM_ITEM');
-- MEASURES - FACT TABLE 1 (F_SALES)
execute cwm2_olap_measure.create_measure('OLAP', 'CUBE_REL_3','SALES_MARGIN', 'Sales Margin','Sales Margin', 'Sales Margin');
execute cwm2_olap_measure.create_measure('OLAP', 'CUBE_REL_3','SALES_QTY','Sales Quantity','Sales Quantity','Sales Quantity');
execute cwm2_olap_measure.create_measure('OLAP', 'CUBE_REL_3','SALES_VALUE', 'Sales Value','Sales Value', 'Sales Value');
-- MEASURES - FACT TABLE 2 (F_PVP_MIN_MAX)
execute cwm2_olap_measure.create_measure('OLAP', 'CUBE_REL_3','PVP_MIN','pvp min','pvp min','pvp min');
execute cwm2_olap_measure.create_measure('OLAP', 'CUBE_REL_3','PVP_MAX', 'pvp max','pvp max', 'pvp max');
-- FACT TABLE 1 MAPPINGS
execute cwm2_olap_table_map.Map_FactTbl_LevelKey('OLAP','CUBE_REL_3','OLAP','f_sales','LOWESTLEVEL','DIM:OLAP.DIM_STORE/HIER:STORE/LVL:L0/COL:COD_STORE;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER1/LVL:L0/COL:COD_ITEM;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER2/LVL:L0/COL:COD_ITEM;');
execute cwm2_olap_table_map.Map_FactTbl_Measure('OLAP', 'CUBE_REL_3','SALES_MARGIN','OLAP','f_sales','SALES_MARGIN', 'DIM:OLAP.DIM_STORE/HIER:STORE/LVL:L0/COL:COD_STORE;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER1/LVL:L0/COL:COD_ITEM;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER2/LVL:L0/COL:COD_ITEM;');
execute cwm2_olap_table_map.Map_FactTbl_Measure('OLAP', 'CUBE_REL_3','SALES_QTY', 'OLAP', 'f_sales', 'SALES_QTY','DIM:OLAP.DIM_STORE/HIER:STORE/LVL:L0/COL:COD_STORE;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER1/LVL:L0/COL:COD_ITEM;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER2/LVL:L0/COL:COD_ITEM;');
execute cwm2_olap_table_map.Map_FactTbl_Measure('OLAP', 'CUBE_REL_3','SALES_VALUE', 'OLAP', 'f_sales', 'SALES_VALUE','DIM:OLAP.DIM_STORE/HIER:STORE/LVL:L0/COL:COD_STORE;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER1/LVL:L0/COL:COD_ITEM;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER2/LVL:L0/COL:COD_ITEM;');
-- FACT TABLE 2 MAPPINGS
execute cwm2_olap_table_map.Map_FactTbl_LevelKey('OLAP','CUBE_REL_3','OLAP','f_pvp_min_max','LOWESTLEVEL','DIM:OLAP.DIM_STORE/HIER:STORE_HIER1/LVL:L1/COL:COD_STORE;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER1/LVL:L4/COL:COD_ITEM;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER2/LVL:L4/COL:COD_ITEM;');
execute cwm2_olap_table_map.Map_FactTbl_Measure('OLAP', 'CUBE_REL_3','PVP_MIN','OLAP','f_pvp_min_max','PVP_MIN', 'DIM:OLAP.DIM_STORE/HIER:STORE_HIER1/LVL:L1/COL:COD_STORE;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER1/LVL:L4/COL:COD_ITEM;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER2/LVL:L4/COL:COD_ITEM;');
execute cwm2_olap_table_map.Map_FactTbl_Measure('OLAP', 'CUBE_REL_3','PVP_MAX', 'OLAP', 'f_pvp_min_max', 'PVP_MAX','DIM:OLAP.DIM_STORE/HIER:STORE_HIER1/LVL:L1/COL:COD_STORE;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER1/LVL:L4/COL:COD_ITEM;DIM:OLAP.DIM_ITEM/HIER:ITEM_HIER2/LVL:L4/COL:COD_ITEM;');
-- CUBE VALIDATE
execute CWM2_OLAP_VALIDATE.Validate_Cube('OLAP','CUBE_REL_3');
The error is in the cwm2_olap_table_map.Map_FactTbl_Measure command for the first measure of the second fact table. Am I doing something wrong?
Regarding issues 3) and 4), I will follow your sugestions. I'll get back to you on this later.
Once again, thanks for the help, it is being most helpful.
Ricardo Sá

Count of id's inside FACT TABLE

hi,
I will like to calculate the count of particular id inside a FACT table.
How to get this done in AWSM or Discoverer For OLAP.
Thanks, Prasad

There is a tech note in the May 05 OLAP Newsletter that explains how to do this:
http://www.oracle.com/technology/products/bi/olap/oracleorpnewsletter_may05.htm
However, there is a bug/"enhancement opportunity" with the aggregation engine which means the wrong results can be returned. To resolve this you need to run some additional DML after you have created the measure to force the aggregation engine to respect the order of the dimensions set within the Rules tab. The order of the dimensions in this tab is important as it controls when the MAX() vs SUM() aggregation methods are applied.
On the variable that supports the logical formula assign the following property by issuing the following statement:
cns YOUR_VARIABLE_NAME
PROPERTY '$AGGREGATE_FORCEORDER'
and on the logical formula update the definition by also adding a FORCEORDER statement. For example a modified formula would look as follows:
consider EXPENSE_PRT_TOPFRML
eq aggregate(this_aw!EXPENSE_PRT_TOPVAR using this_aw!OBJ311101508 FORCEORDER)
compile EXPENSE_PRT_TOPFRML
upd
commit
Obviously, if you delete the cube and rebuild it from an XML template or redefine it manually you will have to reapply these changes again.
Hope this helps
Keith Laker
Oracle EMEA Consulting
BI Blog: http://oraclebi.blogspot.com/
DM Blog: http://oracledmt.blogspot.com/
BI on Oracle: http://www.oracle.com/bi/
BI on OTN: http://www.oracle.com/technology/products/bi/
BI Samples: http://www.oracle.com/technology/products/bi/samples/

How can we know that size of dimension is more than fact table?

how can we know that size of dimension is more than fact table?
this was the question asked for me in interview

Hi Reddy,
This is common way finding the size of cube or dimensions or KF.
Each keyfiure occupies 10 Bytes of memory
Each Char occupies 6 Bytes of memory
So in an Infocube the maximum number of fields are 256 out of which 233 keyfigure, 16 Dimesions and 6 special char.
So The maximum capacity of a cube
= 233(Key figure)10 + 16(Characteristics)6 + 6(Sp.Char)*6
In general InfoCube size should not exceed 100 GB of data
Hope it answer your question.
Regards,
Varun

Performance - DIM and FACT tables

Experts,
I have performance issues where my DIM tables are bigger than the FACT tables by 50 %.
Can any one please let me know what should be done in order to solve this issue
I have already done below steps
1)Kept the small dimensions together
2)kept the line item dimensions wherever needed
3)Grouped related characteristics into one dimension only
4)Removed high cardinality dimensions
pls help
thanks in advance

Often, not much thought is given to the dissemination of characteristics to dimensions. Dimension tables, however, have a huge impact on InfoCube performance. The star schema design works best when the database can assume minimal records in the dimension tables and larger volumes in the fact table.
Rationale : -
Each dimension should be of approximately equal size and that the file size of each dimension should not make up more than 10 percent of the associated fact table. The dimensions must also support growth.
You should make every attempt to split up the most dynamic characteristics so they do not exist in the same dimension. This ensures that the system does not create too many entries in a dimension table.
Example : Order data is loaded into BW with the dynamic characteristics customer and material. If these InfoObjects were to be placed together in the same dimension, it poses a problem for the system because a new dimension record would be created each time the combination of customer or material changed. This would make the dimension very large in relation to the fact table.
When one dimension grows very large in relation to the fact table, it makes it difficult for the database optimizer to choose an efficient path to the data, because the guideline of each dimension having less than 10 percent of the fact tables records has been violated. This condition of having a large volume of data growth in a dimension is known as degenerative dimension.
In the data modeling phase, it is very important to determine if a dimension table will be degenerated, and then explicitly set it as a line item dimension
The best way to fix a degenerative dimension is to move the offending characteristics to different dimensions
Line-item dimensions arise in nearly every case where the granularity of the fact table represents an actual working document like an order number, invoice number, sequence number.. This can only be accomplished if no data is in the InfoCube. If data is present, however, a dump and reload is required. This underscores the point that the data modeling decisions need to be well thought out during the initial implementation to avoid a dump and reload of data.
Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes
This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.
Recommendation: -
Try to limit the number of records in the dimension tables. Use the following guidelines:
1. If an InfoObject has almost as many distinct values as there are entries in the fact tables, the dimension this InfoObject belongs to should be defined as a line item dimension. If the dimension is defined in this manner, the system will write the data directly to the fact table instead of creating a dimension table that has almost as many entries as the fact table.
On the other hand, if there are several dimension tables with very few entries (for example, less than 10), these smaller dimensions should be combined into one dimension.
2. Group related characteristics into one dimension only. Unrelated characteristics can use too much disk space and cause performance problems (for example, 10,000 customers and 10,000 materials may result in 100,000,000 records).
3. Avoid characteristics with a high granularity, that is, many distinct entries compared with the number of entries in the fact table.
4. Remove all "High-Cardinality" indicators from the InfoCube definition,generally, a dimension has a high cardinality if the number of dimension entries is 20% (or more) of the number of fact table entries. When in doubt, do not set a dimension with high cardinality
5.Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.
Hope it Helps
Chetan
@CP..

Fact table is getting flooded

while loading 0FIAR_C03 its been observed that fact table is getting n times records
eg:
Transfered request: 969
Added Request: 29482
Data modeling as follow:
0FI_AR_4 -> 0FIAR_O03 -> 0FIAR_C03
till ods its fine but after that ......
when I checked fact table I found time dim_id is having multiple values because of that we are getting same set of fact data again and again for same dim_ids
when I checked update rule of cube then I observed 0CALDAY 0CALMONTH and 0CALYEAR are mapped with 0FISCPER using time distribution
so my question here is what is the function of time distribution ???
is that related to my issue???
Edited by: Alok Kashyap on Mar 4, 2009 9:28 AM

Hi Alok,
To answer some questions:
(A) Time Distribution Usage: Review "Time Update" Rule Type on SAP Help Portal (Data ware housing) NW04s version.
Main Point = " All the key figures that can be added are split into correspondingly smaller units of time"
"Time Update:
When performing a time update, automatic time conversion and time distribution are available.
Direct Update: the system automatically performs a time conversion.
Time Conversion:
You can update source time characteristics to target time characteristics using automatic time conversion. This function is not available for DataStore objects, since time characteristics are treated as normal data fields.
Time Distribution:
You can update time characteristics with time distribution. All the key figures that can be added are split into correspondingly smaller units of time. If the source contains a time characteristic (such as 0CALMONTH) that is not as precise as a time characteristic of the target (such as 0CALWEEK), you can combine these characteristics with one another in the rule. The system then performs time distribution in the transformation.
For example, you break down the calendar month 07.2001 into the weeks 26.2001, 27.2001, 28.2001, 29.2001, 30.2001 and 31.2001. Each key figure that can be added receives 1/31 of the original value for week 26.2001, 7/31 for each of weeks 27, 28, 29, and 30, and exactly 2/31 of it for week 31."
(B) Yes, it (time distribution) is "indirectly" adding extra rows into your fact table since " All the key figures that can be added are split into correspondingly smaller units of time" so you are getting more numerous distinct values of different DIM_ID values.
(C) Whether Time Distribution is Causing Extra Rows into the Fact table:
The 0BCT* Std Content of 0FIAR_C03 only contains 0Fiscper (Fiscal Year/Period) and of course 0Fiscvarnt (Fiscal year variant) time characteristics in the cube data model...The underlying infosource 0FI_AR_4 also has only 0Fiscper time characteristic.
So suspect someone at your site has tinkered with the 0BCT* 0FIAR_C03 datamodel to introduce more time characteristics...Please refer to the documentation or project deployment notes at your site since there may have been specific project requirements to do so. The project deliverables and the suspect person may be more the root cause...
Hope this helps.
Thanks and Regards,
Lee

Fact table contains how many no. of Dim. ids and Key figures?

Fact table contains how many no. of Dim. ids and Key figures?

Max 233 KeyFigures,Max of (16dimensions*)248 DIM Ids?
dim table doesnt contain Charateristics,but Primaray keys of DIM Ids + SIDs where as Fact table contain corresponding Foreign Keys and keyFiures
Message was edited by: Murali

Populate Fact Table

Hi all,
Can you please assist, am currently working a dataware housing project. I need to produce a report but due to the fact that the data I need to use is not available in the existing data
warehouse I need to add the additional tables to do so, and also ensure that the additional table will provide thourough details for future reporting.
The scope of the additional details on the datawarehouse, is to ensure at the end of the day I have a report that is going to show details of attendance.'
There is already dimensions namely([dimSite- with information site, name and locations], [dimMember with member details, [dimNonMember with guest details], [dimReaccess with details of who accessed
without a ticket and the reason the were allowed in], and dimDate with date details, )
now all this dimensions are already added to the data warehouse, all I need to do is to load the data to the fact.
The fact has the following fields
[ReAccesKey],[SiteKey],[DateKey],[MemberKey], [NonMemberKey][TotalAccess] ,[AvgAccess] ,[MemberAccess] ,[NonMemberAcces][MemberVisitorsAccess],[MemberOverrides],[NonMemberOverrides],[AccessPastWeek],[AccessPast10Days],[AccessPast30Days],[AccessPast60Days],[AccessPast90DaysUP])
May you please assist me as to how to go about in loading data to the fact table using TSQL, I would gladly appreciate that.
Kind Regards

You can create a SSIS package for that.
It will have a data flow task as the main step
Inside that you'll have a OLEDB source which will connect to your source server where fact data is present. You can write a query as per your logic to extract the data.
Following OLEDB source you'll have a set of Lookup tasks to lookup the Site,Member, etc details against each of dimensional tables and get the keya corresponding to that.
Then you will have a oledb destination where you will select table to which you want to dump the data ie fact table. If it doesnt exist you can create it from within the package itself and map the columns
There will also be a incremental logic implemented inside package to make sure you take only the new data each time. FOr this purpose you will have a sql task to get maximum date value captured in the fact table prior to data flow task and store it inside
a variable. Then inside your source query you will use this date as reference and take all data which have a date value > this max value in your source.
In case your table can have modifications then you also need to have a intermediate step to load to staging table inside data flow task instead of actual table and then have a further logic to delete all records from fact which matched the incoming
source rows based on your primary key. Then you'll have the final step to insert all data from stage to your actual fact table.
So your final package will have below steps
1. Execute sql task - to get max date from the destination ad store it in a variable (@[user::MaxDate])
2. data flow task
a. OLEDB Source - connect to source
uses a query like
SELECT columns...
FROM table1
WHERE AuditDateField > ?
and map parameter to @MaxDate variable created above
b. Lookup tasks to lookup to each of dimensions and get keys based on reference values
c. OLEDB destination - dump data to fact table (if no further modifications at source) or stage table (in case of modifications)
3. Execute SQL task * - Delete all records from fact matching records in stage table based on key fields and do a final insert into fact with all data from stage
3 is required only if modifications are involved
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Fact Table Limitations

Hello Gurus,
Can you please tell me why fact table has total column limitation as 256 and why a dimension table has 16 characteristics limitation?
And in Oracle or in DB2 limits are more than this then what is the advantage of using SAP BW/BI?
Thank you in advance
Lili

Hi..
The size of a block depends on the PAGESIZE and the EXTENTSIZE of the tablespace. The standard PAGESIZE of the fact-table tablespace with the assigned data class DFACT is 16K. Up to Release SAP BW 3.5, the default EXTENTSIZE value was 16. As of Release SAP NetWeaver 2004s the new default EXTENTSIZE value is 2.
With an EXTENTSIZE of 2 and a PAGESIZE of 16K the memory area is calculated as 2 x 16K = 32K, this is reserved for each block.
The width of a data record depends on the number of dimensions and the number of key figures in the InfoCube. A dimension key field uses 4 bytes and a decimal key figure uses 9 bytes. If, for example an InfoCube has 3 standard dimensions, 7 customer dimensions and 30 decimal key figures, a data record needs 10 x 4 bytes + 30 x 9 bytes = 310 bytes. In a 32K block, 32768 bytes / 310 bytes could write 105 data records
Hopes this helps..

Improve Performance of Dimension and Fact table

Hi All,
Can any one explain me the steps how to improve performance of Dimension and Fact table.
Thanks in advace....
redd

Hi!
There is much to be said about performance in general, but I will try to answer your specific question regarding fact and dimension tables.
First of all try to compress as many requests as possible in the fact table and do that regularily.
Partition your compressed fact table physically based on for example 0CALMONTH. In the infocube maintenance, in the Extras menu, choose partitioning.
Partition your cube logically into several smaller cubes based on for example 0CALYEAR. Combine the cubes with a multiprovider.
Use constants on infocube level (Extras->Structure Specific Infoobject properties) and/or restrictions on specific cubes in your multiprovider queries if needed.
Create aggregates of subsets of your characteristics based on your query design. Use the debug option in RSRT to investigate which objects you need to include.
To investigate the size of the dimension tables, first use the test in transaction RSRV (Database Information about InfoProvider Tables). It will tell you the relative sizes of your dimensions in comparison to your fact table. Then go to transaction DB02 and conduct a detailed analysis on the large dimension tables. You can choose "table columns" in the detailed analysis screen to see the number of distinct values in each column (characteristic). You also need to understand the "business logic" behind these objects. The ones that have low cardinality, that is relate to each other shoule be located together. With this information at hand you can understand which objects contribute the most to the size of the dimension and separate the dimension.
Use line item dimension where applicable, but use the "high cardinality" option with extreme care.
Generate database statistics regularily using process chains or (if you use Oracle) schedule BRCONNECT runs using transaction DB13.
Good luck!
Kind Regards
Andreas

Dimension table is larger than the fact table

Hi Community,
How can we explain the phenomenon when a dimension table has MORE records in it than the fact table ? What are the conditions that would cause this to occur ?
Thank you !
Keith

Thanks, Bhanu,
I am wondering specifically how to explain the output from program SAP_INFOCUBE_DESIGNS when the dimension table is shown to have a fact table ratio that is greater than 100%
I believe that SAP_INFOCUBE_DESIGNS already takes into consideration both the E and also the F-fact table when calculating the ratio. So in this case, we could not explain it by your first suggestion (after compression - but looking at only the F table).
In the case where selective deletions have been performed, how can we correct the situation ? For example, how could we clean out the records in the dimension tables which no longer have any facts in the fact table ? (I think the BW system should do this automatically as a part of the selective deletion, don't you agree ?).
Also, is there any other explanation for how the dimension table could arrive at greater than 100% the size of the fact table(s) ?
For example, lets say that (theoretically) we placed many very dynamic characteristics together into the same dimension.. which we know you should not do. Would it be possible for the combination of these very many dynamic characteristics to cause so many DIM IDs that the dimension table overtakes the record count of the fact table ? Is this situation then made worse by compression if the number of fact table records is reduced thanks to removal of the request ID ?

Max no of characteristics in a fact table???

Similar Messages

Maybe you are looking for