SIDs are written in a Fact Table?

Hi,
Some experts told me that SIDs are written in a fact table in extended star schema model . I am not able to understand how SIDs can be written in a fact table. As per my understing fact table contains only keyfigure and Dimids ( foreign key).
Please explain.
Thanks.
Asim

Hello!
Basically you are right. Fact table holds only DIM-ID's and key figures. But if you set a dimension to line item (line item flag in cube definition) than no dimension table is created and SID is written directly into the fact table. Therefore a line item dimension can hold only one characteristic.
Hope that helps.
kind regards,
Peter

Similar Messages

Why Negative values are entering in to fact table.

Dear All,
After Data File uploaded. The Fact table is showing Negative values.
Can any body give solution.
And in DataManager->Financial Process>FX Restatament (Is running Succussfully)
But Currency is not getting translated.
Please help.
Thanks,
Satish.

The reason the values are negative may be caused by 2 items. The first is the default method by which BPC store information; BPC is designed to store values based on the natural sign. So, if a Revenue account is positive in the Data File, and the Property "ACCTTYPE" is INC, the value is stored as a negative number. When an expense value is loaded to an account with "EXP", the value is stored as a positive. LEQ are Negative and AST are positive. (CREDITS and DEBITS storage)
BPC then uses tables and measures to report the account based on type correctly in the Excel interface. This is how BPC is designed.
There is also the CREDITPOSITIVE = YES / NO that is part of the Data Transformation instructions, and if this is setup incorrectly, you may store the reverse signs from the data file that is loaded. So this may need to be reviewed as well.
As for the FXTranslation, I assume you have rates in the RATE cube to use in the translation process. You will need to verify that the RATETYPE property is filled in for the accounts you wish to translate? DId you process the FX script logic and the RATE script logic prior to running FX.
Hope this helps.
Edited by: Petar Daniel on Dec 10, 2008 2:20 PM

None of the fact tables are compatible error

Hi All,
I do see this error (none of the compatible fact table) after setting the content level aggregation on the dimension tables and the fact table. This error i get only when i try to pull the calculated item which is based on a attribute in the fact table. I have an attribute like year in the fact table i need to display like 'CY'||'2013' in a calculated logical column and when i pull this into answers i get this error -
1) joins are ok ; only one fact table and 3 dimension tables
2). content level on the fact table are specified at the detail level and also for the dimensions
any suggestions - thanks for your time

can anyone please provide some suggestions -
> i looked at the fact table LTS and specified the logical level for each dimension as the detail
> specified the LTS for each dimension table
> I have a column in my fact table which is calendar year and i want to have a derived column like rep_cal_year with 'CY'||cal_year - so when i pull this derived column in my answers i get the error - none of the fact tables are compatibile with the query;
what could be missign?

"None of the fact tables are compatible with the query request " error

I've got a situation where I have two facts(Fact_1, Fact_2) and three dimensions(dim_1,dim_2,dim_3) in 1 subject area. I've got dimension hierarchies setup for all the dimension tables.
Dim_1 is one to many to Fact_1
Dim_2 is one to many to Fact_2
Dim_3 is one to many to both Fact_1 and Fact_2
I've set up the content levels for the LTS for the Facts so that they are the lowest grain for dimensions they join to and the grand total grain for dimensions they do not join to.
My rpd is consistent. When I run a report using an attribute from Dim_3 and Dim_1 or Dim_3 and Dim_2, the report comes back fine.
But if I try to run a report using all three Dim tables, I get an error and the message "None of the fact tables are compatible with the query request ".
First of all, is it possible to make a report using all three dimensions?
Second, what's the best way to trouble shoot this error? Why are none of the fact tables compatible? I thought as long as the aggregation levels were set to grand total for non-shared dimensions, Answers would be able to create the report properly.
Any advise would be greatly appreciated.
Thanks!
-Joe

OBIEE is looking for a fact that can link ALL the dimensions together. This is also known as the implicit fact ... you don't have a fact that can relate all the dimensions - you have 2 facts that together they can. Perhaps you need to great a single logical fact that has both LTS for your physical facts and try it that way.
Then you'd have Dim1, Dim 2, Dim3 all being able to join to Fact1 (which is made of physical facts 1 & 2).

Star Schema - How to improve the ratio DIM to FACT table

If any one want to repply here
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
thanks

Guidelines how to limit the number of records in dimension tables
1. If an InfoObject has almost as many distinct values as there are entries in the fact table, define the
dimension of the InfoObject as a line item dimension. If defined in this manner, the system will write
the data directly to the fact table (a field with the data element RSSID, which immediately shows the
SID table of the InfoObject, is written in the fact table) instead of creating a dimension table that has
almost as many entries as the fact table.
2. Only group related characteristics into one dimension. 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. If you cannot avoid characteristics with a high granularity and most of your queries do not use these
characteristics, create an aggregate that stores summarized information. Do not use characteristics
with a high granularity in this aggregate.
Please note that the LineItem flag can have negative performance impact on F4 help usage (for which
the setting 'Only Values in InfoProvider' is used (transaction RSD1 &#56256;-> Tab 'Business Explorer')).
5. It is also worthwhile to try the checks in transaction RSRV. Use for example RSRV -> All
Elementary Tests -> Transaction Data -> Entries Not Used in the Dimension of an InfoCube.

Foreign keys in SCD2 dimensions and fact tables in data warehouse

Hello.
I have datawarehouse in snowflake schema. All dimensions are SCD2, the columns are like that:
ID (PK) SID NAME ... START_DATE END_DATE IS_ACTUAL
1 1 XXX 01.01.2000 01.01.2002 0
2 1 YYX 02.01.2002 01.01.2004 1
3 2 SYX 02.01.2002 1
4 3 AYX 02.01.2002 01.01.2004 0
5 3 YYZ 02.01.2004 1
On this table there are relations from other dimension and fact table.
Need I create foreign keys for relation?
And if I do, on what columns? SID (serial ID) is not unique. If I create on ID, I have to get SID and actual row in any query.

>
I have datawarehouse in snowflake schema. All dimensions are SCD2, the columns are like that:
ID (PK) SID NAME ... START_DATE END_DATE IS_ACTUAL
1 1 XXX 01.01.2000 01.01.2002 0
2 1 YYX 02.01.2002 01.01.2004 1
3 2 SYX 02.01.2002 1
4 3 AYX 02.01.2002 01.01.2004 0
5 3 YYZ 02.01.2004 1
On this table there are relations from other dimension and fact table.
Need I create foreign keys for relation?
>
Are you still designing your system? Why did you choose NOT to use a Star schema? Star schema's are simpler and have some performance benefits over snowflakes. Although there may be some data redundancy that is usually not an issue for data warehouse systems since any DML is usually well-managed and normalization is often sacrificed for better performance.
Only YOU can determine what foreign keys you need. Generally you will create foreign keys between any child table and its parent table and those need to be created on a primary key or unique key value.
>
And if I do, on what columns? SID (serial ID) is not unique. If I create on ID, I have to get SID and actual row in any query.
>
I have no idea what that means. There isn't any way to tell from just the DDL for one dimension table that you provided.
It is not clear if you are saying that your fact table will have a direct relationship to the star-flake dimension tables or only link to them through the top-level dimensions.
Some types of snowflakes do nothing more than normalize a dimension table to eliminate redundancy. For those types the dimension table is, in a sense, a 'mini' fact table and the other normalized tables become its children. The fact table only has a relation to the main dimension table; any data needed from the dimensions 'child' tables is obtained by joining them to their 'parent'.
Other snowflake types have the main fact table having relations to one or more of the dimensions 'child' tables. That complicates the maintenance of the fact table since any change to the dimension 'child' table impacts the fact table also. It is not recommended to use that type of snowflake.
See the 'Snowflake Schemas' section of the Data Warehousing Guide
http://docs.oracle.com/cd/B28359_01/server.111/b28313/schemas.htm
>
Snowflake Schemas
The snowflake schema is a more complex data warehouse model than a star schema, and is a type of star schema. It is called a snowflake schema because the diagram of the schema resembles a snowflake.
Snowflake schemas normalize dimensions to eliminate redundancy. That is, the dimension data has been grouped into multiple tables instead of one large table. For example, a product dimension table in a star schema might be normalized into a products table, a product_category table, and a product_manufacturer table in a snowflake schema. While this saves space, it increases the number of dimension tables and requires more foreign key joins. The result is more complex queries and reduced query performance. Figure 19-3 presents a graphical representation of a snowflake schema.

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.

Fact tables in Infocube

How many tables Exact Contain in Info cube?
Please search the forum
Edited by: Pravender on Sep 16, 2011 12:31 AM

Hi Mahesh,
For Basis InfoCubes in SAP BW, there are two fact tables for
including transaction data: The F and the E fact table.
Unlike the E fact table, the F fact table contains the information
about the request from where the transaction data originates
When loading data (when receiving requests), the system writes data
into the F fact table.
During "compression", the system summarizes data from different
requests and writes it to the E fact table.
To ensure good reporting performance, it is important that you only
keep data from a few requests in the F fact table, which means that you
should compress requests as soon as possible.
Also bear in mind that deleting transaction data according to the
request is only possible from the F fact table, as only this table
contains the information regarding which data belongs to which
request.
You should therefore compress a request as soon as you are certain
that the data loaded is correct. When you install BW on an ORACLE database, BITMAP indexes are created on the fact tables to improve the reporting performance of the system
And yes try to search on help.sap, there is plenty of information.
Regards
Sunny

Creating Time Dimension from date columns in fact tables.

I remember watching a demo from a BI Tool a couple years ago, wich I swear was OBIEE, and the presentator stated it was possible to create a Time Dimension in the admin tool, based on a date column in other table.
Can you guys tell me if there's such functionality in OBIEE?
If so, how could I achieve that?!
Thanks in advance!
Marcos

hi,
You are trying to make Fact table as Dim table ???
Fact table has some dim columns??
We can do this by making a fact table as dim table ,create a dim hierarchy on that table
Year level :Extract(year from fact_date_column)
Month and year level:CAST (Extract(month from fact_date_column) As CHAR(5) ) || CAST (Extract(yearfrom fact_date_column) As CHAR(5) )
Like this
But,be careful while doing this make sure that all joins and content levels are good
As per my knowledge this is not a good way,Experts can add some words lets see!!!!!! :-)
thanks,
saichand.v

Unexpected results getting data from two fact tables through conformed dim

Hi all,
We are getting an unexpected behaviour in our OBIEE 10.1.3.3.3. We have this scenario:
We have {color:#0000ff}2 fact tables{color}{color:#000000} called F1 and F2. F1 has one measure, f1m1 and F2 has another one, f2m1.
We have {color:#0000ff}4 conformed dimensions{color}, called D1, D2, D3, Date.
When we are requesting for individual fact tables, we are getting:
date d1 d2 d3 f1m1
dt1 - x - y - z - m1
dt1 - x - y - z' - m2
date d1 d2 d3 f2m1
dt1 - x - y - z - m3
dt1 - x - y - z'' - m4
But, trying to obtain a compare scenario, we are getting
date d1 d2 d3 f1m1 f2m1
dt1 x y z m1 m4
Instead of
date d1 d2 d3 f1m1 f2m1
dt1 x y z m1 m3
Looking at query log, we have catched the reason. That's why BI Server is using to solve this request using ROW_COUNT() to join SAWITH0 and SAWITH1 in SAWITH2 result set. So, the order may not be the same in the results sets in every fact table. More or less, generated query is like:
WITH
SAWITH0 AS
(select ....
from F1),
SAWITH1 AS
(select ...
from F2),
SAWITH2 AS
select from (select ...
ROW_NUMBER() OVER PARTITION (....) c10
from SAWITH0.d1 full outer join SAWITH1.d1 ....) D1
{color:#ff0000}where (D1.c10 = 1){color}
select SAWITH2. ....
from SAWITH2
order by c1..c10
The problems seems to be that BI server is ordering the result sets SAWITH0 and SAWITH1 and getting row number to join this results sets, but this is not getting the correct result.
Any ideas?
TIA
Javier
{color}
Edited by: jirazazábal on Mar 13, 2009 2:46 PM

I have done a logical fact table with two fact table source on it.
The Sql performed against the database was this one.
-------------------- Sending query to database named PRODS_AIX (id: <<153418>>):
WITH
SAWITH0 AS (select sum(T21296.CONSUMERS_SALES_EURO) as c1,
     T21309.DIVISION_CODE as c2
from
     DIVISION T21309,
     C_CONSUMERS_SALES T21296
where ( T21296.DIVISION = T21309.DIMENSION_KEY )
group by T21309.DIVISION_CODE),
SAWITH1 AS (select sum(T21356.ORDER_VALUE) as c1,
     T21309.DIVISION_CODE as c2
from
     DIVISION T21309,
     DWH_SALES_ORDER_OVERVIEW T21356
where ( T21309.DIMENSION_KEY = T21356.DIVISION_KEY )
group by T21309.DIVISION_CODE)
select distinct case when SAWITH0.c2 is not null then SAWITH0.c2 when SAWITH1.c2 is not null then SAWITH1.c2 end as c1,
     SAWITH0.c1 as c2,
     SAWITH1.c1 as c3
from
     SAWITH0 full outer join SAWITH1 On nvl(SAWITH0.c2 , 'q') = nvl(SAWITH1.c2 , 'q') and nvl(SAWITH0.c2 , 'z') = nvl(SAWITH1.c2 , 'z')
order by c1As you can see one select (SAWITH0) for the first fact table C_CONSUMERS_SALES and one select for the second fact table DWH_SALES_ORDER_OVERVIEW (SAWITH1 ) and the two statement are joined with a full outer join.
I ask me why you have the three select (SAWITH0,SAWITH1 and SAWITH2). Can you please paste the complete SQL performed ?
Can you tell us also which SQL is performed if you select only the columns from one fact table and not for the other ?
Regards
Nico
http://gerardnico.com

Dimension Table Attributes giving No Fact Table Exists Error

Hi Experts,
My OBIEE version is 11.1.1.6.10. There is a presentation table which has columns coming from multiple logical tables. I'm dragging 2 columns into the report which are coming from 2 logical tables.
The result is displaying. When I checked the query, a fact table is also coming and results are getting effected because of this.
Could anybody let me know if any idea.

Hi SriramKarthik,
Aj (bi007) already gave you the answer on how you can change the implicit fact table, the one you are seeing in your physical query.
I'm just not sure of what is your question: are you surprised to see a fact table is used in the physical SQL and look for a way to avoid it because, as you say, results are impacted by that implicit fact table? You can't get rid of that table, you can only choose it (the implicit one).
OBIEE must join in a way or another your 2 dimensions, and in your BMM these dimensions are joined by a fact table, that's why you see it in your query.

Result set from two fact tables

Hi,
I have two fact tables, fact1, fact2. These two fact tables share common dimension dimension1.
In RPD I joined dimension1 to fact1, fact2.
In Answers I pulled the columns from fact1, fact2 and dimension1, I am getting ODBC Error, no fact table exists at the requested level..
When I pull the columns from fact1, dimension1 i am getting result.
When I pull the columns from fact2, dimension1 i am getting result.
Please suggest me how to resolve this.
Thanks & regards,
SR

Whether Fact1 and Fact2 are 2 sperate Logical Fact Tables or part of same logical fact tables.
If they are separate logical fact tables then check for the Properties of Logical Table Source - Content Tab and set aggregation level for Dimension 1 hierarchy for respective facts.
Thanks!
Exa-BI

Two FACT Tables, Some Common and Non-Common Dimensions

Hello all, a question i am sure you have faced in the past but still wanted to get your feedback.
I have a few FACT tables and some dimensions that are shared (common dimensions). Rest of the dimensions are related to one or the other FACT tables.
What is the best way to present a view where users can pull information from both the FACT tables?
I am successful in pulling the shared (common) dimensions across BOTH FACT tables having the same grain but this view breaks down when i pull information from one Dimension that has not much to do with the other FACT.
What is the best way to present this? Should this be broken in three subject areas?
Subject Area 1 --> Some Dims --> FACT Table A
Subject Area 2 --> Some Dims --> FACT Table B
AND
Subject Area 3 --> ***Only Common Dims*** --> FACT Table A & FACT Table B?
Your feedback is always appreciated.
Regards,
Edited by: user10679130 on Oct 12, 2009 3:27 PM

Please check the forum first for similar threads/questions.
Joining two fact tables with different dimensions into single logical table
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
This solution keeps both fact tables in the same subject area in the single logical fact table, with common and not-common dimensions.
Regards
Goran
http://108obiee.blogspot.com

What is the fact table content?

a. Key figure for a combination of char value of dimensions are stored in the fact table
b. Both cumulatiove and also key figure for non cumulative values can be contained in fact table
Choose any one
Thanks
Babu

Hi,
Fact table contains the data (key figs) for a certain combination of characteristic values of the dimension tbls to help a business person evaluate their company & make appropriate decisions.
=> a. from the choice you had.
Rgds,
Colum
Was this information helpful to you Babu?
If so, please award points as appropriate.
thanks
Edited by: Colum Cronin on Apr 7, 2010 10:11 AM

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

SIDs are written in a Fact Table?

Similar Messages

Maybe you are looking for