Understanding Fact Tables

Hi,
I am new to OBIEE, I have created several dimensions but am a little confused with fact tables and measures. I have a fact table already populated in the database containing dimension keys per each dimension, 3 measures. There are some additional columns(agreement_code, agreement_type, schedule_number). These additional columns do not link to the dimensions. Do these columns have to be included in the fact table inside the OBIEE BM layer or could they be removed. My question is does the fact table have to contain only measures or can there be other non-aggregated columns.
Thanks

Hi
If I'm right, your 3 additionnal columns are attributs but they're in your fact table ?
If so, they are "degenerated dimensions".
If the end-user needs them, you will have to put them somewhere.
You will create a new logical table based on the your physical fact table, but for dimension purpose.
Actually, you will have :
- 1 logical fact table, based on the physical fact table, and contains measures
- 1 logical dim table, based on the same physical fact table, and logically linked to the logical fact table. It contains your 3 attributes.
You can see a deeper explanation here, in my last post :
Table as fact and dimension
Note : you can also put the 3 columns in the logical fact table, it will works, but it's not the "propest" (not sure about this word... sorry, my english is not very good) method.

Similar Messages

Example of Fact table dataloading

Hi Experts
I'm looking to get an example of data loading in fact table that will help me to understand fact table concept . Really appreciate if someone provide my mentioned stuff. Thanks
Regards
Muz

Thanks for the link and its really useful and specific but as suggested I need to work with dimension as well so if somebody send me link for data loading dimension and then use these dimension to load data in fact then I really appreciate it.
Hi Muzokh,
You can download very good ETL package samples as well as the DW database tables definition script from the Tools and Utilities of the book - The Microsoft Data Warehouse Toolkit 2nd Edition written by Kimball:
http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/books/microsoft-data-warehouse-dw-toolkit/
The samples of Chapter 7 should be useful for you.
Regards,
Mike Yin
TechNet Community Support

Parent member values in Fact tables

Hello,
I want to understand something, as far as I know, we can only send data to base level members, right ?
Then how come we find rows of data that have parent member values in the Fact tables ? (assuming we do not play manually with the database of course), I thought that this can be due to an import with the data manager, can this be right ?

nilanjan chatterjee wrote:
Hi,
>
> The data for the parent members should be available in the SQL tables.
> For example, 2011.TOTAL is parent member. You should not have any data for this member in your database. If it is there, it might have come somehow (may be an import). But this is not right. You might want to remove these records. But be sure that you dont delete the records for the base level members.
>
> Hope this helps.
I guess you meant should not, right ?

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

Content Tab: None of the fact tables are compatible with the query request

Hi All,
**One thing I am not clear yet of all my years with OBIEE is working with the content tab in BMM.**
I have made a rpd the joins in physical layer as shown below:
https://picasaweb.google.com/114804305606242416264/OBIEEError#5663056545119428530
And the BMM layer as:
https://picasaweb.google.com/114804305606242416264/OBIEEError#5663056519553812930
Error I am getting when i run a request from the 3 columns from the selected 3 tables is:
Dim - Comment Code Details
Fact - Complaint
Dim - Service Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14020] None of the fact tables are compatible with the query request Sr Num:[DAggr(Fact - Complaint.Sr Num by [ Dim - Service Details.Sr Cat Type Cd, Dim - Comment Code Details.Cmtcode name] )]. (HY000).
I get no error for consistency.. I read everywhere and I know i need to set the appropriate aggregation levels in the various dims and facts LTS properties to help OBIEE understanding our model, but how to do that.. how do i decide... how should I approach, what should be the aggregation level, what details.
When i click More button i see different options: Copy, Copy From, Get Levels, Check Level, what do these mean.
Aggregation Content, group by - Logical Level or Column which one should i choose and how should I decide.
Can anyone explain the Content Tab in details and from scratch with some example and why we get these errors.... I know many people who are well versed with many other things related to RPD but this. A little efforts of explaining from you guys will really be appreciated.
Thanks in advance,
Dev

Hi Deepak,
Option 1:
My tables in physical layer are joined as below:
D1--> F1 <--D2--> F2 <--D3
Same way i model it in BMM
D1--> F1 <-- D2--> F2 <--D3
Here D1 is non Conformed Dimension for F2 and D3 is non Conformed dim for F1. Later create Dimensional hierarchies, I tried setting up the content levels
I go Sources>content tab of Fact F1 I set
Dimensions----------- Logical level
D1---------------------- D1 Detail
D2---------------------- D2 Detail
D3---------------------- D3 Total
then, I go Sources>content tab of Fact F2 I set
Dimensions----------- Logical level
D1---------------------- D1 Total
D2---------------------- D2 Detail
D3---------------------- D3 Detail
Then, I also go in all the dimensions and set their content levels to Details, but it still gives me errors not sure where I am going wrong in setting the content levels.
I need to know whether the way I have modeled it in BMM is right,
Option 2:
I can combine the two facts in a single Logical Fact or the above design should also work.
(F1&F2)<--D1, D2 , D3 joined separately using complex logical joins.
what will be the content tab details?
Thanks,
Dev

Fact table with datetime measure showing #value error while browsing the cube

Hi All,
I have a cube with a fact table having datetime measure.
when I browse the cube, I am able to see the data for all measures except for the measure with the datetime as datatype.
Thanks in advance.

Hi jarugulalaks,
Actually this forum is to discuss:
Visual Studio WPF/SL Designer, Visual Studio Guidance Automation Toolkit, Developer Documentation and Help System, and Visual Studio Editor.
To make this issue clearly, would you mind letting us know more information about this issue? Whether it is the VS IDE issue? Which language are you using? Which kind of app are you developing? Maybe you could share us a screen shot about it.
But like this case posted by you here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/bc2d30b8-a60d-4f0f-a273-b7cf0f5aaed5/value-error-for-datetime-measure-in-ssas?forum=visualstudiogeneral#bc2d30b8-a60d-4f0f-a273-b7cf0f5aaed5
If it is the SSAS issue, please post this issue to the SSAS forum for dedicated support.
Best Regards,
Jack
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

"Select" Physical table as LTS for a Fact table

Hi,
I am very new to OBIEE, still in the learning phase.
Scenario 1:
I have a "Select" Physical table which is joined (inner join) to a Fact table in the Physical layer. I have other dimensions joined to this fact table.
In BMM, I created a logical table for the fact table with 2 Logical Table Sources (the fact table & the select physical table). No errors in the consistency check.
When I create an analysis with columns from the fact table and the select table, I don't see any data for the select table column.
Scenario 2:
In this scenario, I created an inner join between "Select" physical table and a Dimension table instead of the Fact table.
In BMM, I created a logical table for the dimension table with 2 Logical Table Sources (the dimension table & the select physical table). No errors in the consistency check.
When I create an analysis with columns from the dimension table and the select table, I see data for all the columns.
What am I missing here? Why is it not working in first scenario?
Any help is greatly appreciated.
Thanks,
SP

Hi,
If I understand your description correctly, then your materialized view skips some dimensions (infrequent ones). However, when you reference these skipped dimensions in filters, the queries are hitting the materialized view and failing as these values do not exist. In this case, you could resolve it as follows
1. Create dimensional hierarchies for all dimensions.
2. In the fact table's logical sources set the content tabs properly. (Yes, I think this is it).
When you skipped some dimensions, the grain of the new fact source (the materialized view in this case) is changed. For example:
Say a fact is available with the keys for Product, Customer, Promotion dimensions. The grain for this is Product * Customer * Promotion
Say another fact is available with the keys for Product, Customer. The grain for this is Product * Customer (In fact, I would say it is Product * Customer * Promotion Total).
So in the second case, the grain of the table is changed. So setting appropriate content levels for these sources would automatically switch the sources.
So, I request you to try these settings and let me know if it works.
Thank you,
Dhar

Issue with Multiple LTS for a fact table and filters

Hello,
I am facing an issue with obiee 10g.
In my model, I have a huge FACT table F1 (partitioned and indexed). The average response time for the queries, which targeted it, was ~30-60 seconds, which was not really convincing our end user.
So, we decided to create a materialized view, which removes some dimensions that are not used by default, but might be used if the end user adds some filters. I added the Materialized view in the Physical Layer and in the corresponding Logical Table Source.
I then tried to see if it works, but I was a bit surprised by the result. Indeed,
-> If the report does not reference a truncated dimension, it targets the materialized view. -> Perfect
-> If the report does reference a truncated dimension in the columns, it targets the Fact Table. -> Perfect
-> If the report does reference a truncated dimension in the Filters, it targets the materialized view. For this reason, the filter is never resolved and no join on the dimension table is applied, whereas it exists in logical SQL generated. -> Ko.
A suggestion could be to add the filters into the columns, but I am not satisfied by this response because it will never use the materialized view in that case.
An other suggestion could be to use query rewrite, but I 'd like to have the full control on the generation of the queries.
Does someone know if the filters are not evaluated to determine which LTS to use? How can I force this evaluation?
Regards,

Hi,
If I understand your description correctly, then your materialized view skips some dimensions (infrequent ones). However, when you reference these skipped dimensions in filters, the queries are hitting the materialized view and failing as these values do not exist. In this case, you could resolve it as follows
1. Create dimensional hierarchies for all dimensions.
2. In the fact table's logical sources set the content tabs properly. (Yes, I think this is it).
When you skipped some dimensions, the grain of the new fact source (the materialized view in this case) is changed. For example:
Say a fact is available with the keys for Product, Customer, Promotion dimensions. The grain for this is Product * Customer * Promotion
Say another fact is available with the keys for Product, Customer. The grain for this is Product * Customer (In fact, I would say it is Product * Customer * Promotion Total).
So in the second case, the grain of the table is changed. So setting appropriate content levels for these sources would automatically switch the sources.
So, I request you to try these settings and let me know if it works.
Thank you,
Dhar

Fact Tables

Hi!
I needed help on understanding how data is tored in the FACT Tables.
I am currently facing an issue after running SPRUNCONVERSION. The stored procedure generates 4 records in the FACT tables and thereby eliminates any converted values. For eg, If an liability account 1111001 is loaded with a value -5000 at LC; Local Currency, Running SPRUNCONVERSION say wthe the Translation rate of 2, generates 4 records in the FACTWB Tables:
-10000 in USD,
10000 in USD,
-10000 in USD and another +10000 in USD at the same account and at the same crossings.
This in effect shows no converted data in USD and shows a 0 value.
Any guidance to understand how these records are generated and stored will be of great help.
Regards,
Pankti Shroff

Hi
when you save an application Outlooksoft Admin rebuilds the cube or application in Analysis Services and recreates the following SQL items on the applications wb, fac2, and fact table.
1. Dependencies
2. Indexes
3. Contraints
4. Stored procedures
The source field of the applications wb, fac2, and fact tables is used for optimization purposes only. The 'updating source field' step can vary in time depending on the record count and the default value of the source field. This process will take more time when performing a full optimization because we are querying the wb, fac2, and fact tables.
Hope this helps...
Regards
SN...

How to set db schema in fact tables

Hi!
I have one mapping with one table(table1) pointing to one fact table (fact1).
This fact table has two dimensions located in two different schemas. I already deployed those dimensions and tables and its ok.
My problem is: when I open the mapping editor and ask to generate the mapping to create the package to populate the fact table,
I can see why I can not deploy it (PL/SQL: ORA-00942: table or view does not exist).
My query is: SELECT (fields) FROM schema.table1, table2 ,table3 WHERE....
I cant set the schema property from my table (table1), but I cant´t do the same with the table2 and table3 (both tables related to dimensions). i don´t have this option!
I don´t understand why this happen because both dimensions are ok. They are in two different modules and the locations are ok too.
I understand that the mapping needs the dimension keys to populated the fact table, but I really don´t know how to set this schema property. If i can´t do that,
i don´t know how to "fix" this problem. If a can´t set this schema property, how can I deploy this mapping whitout this???!!!!
I´m using the 10.2 version.
Thanks o lot!!!!!!!!!!!

This is what really happens in my example.
Look the "Generation Results" :
SELECT
/*+ ORDERED NO_MERGE("INGRP1") */
"TEMP_TABLE"."Value1" "Value1",
"TEMP_TABLE"."Value2" "Value2",
"DIMENSION1"."ID" "ID",
"DIMENSION2"."ID" "ID"
FROM
"SCHEMA"."TEMP_TABLE" "TEMP_TABLE", -> I CANT SET THIS schema
"DIMENSION1" "DIMENSION1", -> i can´t do the same here
"DIMENSION2" "DIMENSION2" -> i can´t do the same here
WHERE
( "DIMENSION1"."DIMENSION_KEY" = "DIMENSION1"."ID" ) AND
( "DIMENSION1"."ID" IS NOT NULL ) AND
( "DIMENSION2"."DIMENSION_KEY" = "DIMENSION2"."ID" ) AND
( "DIMENSION2"."ID" IS NOT NULL ) AND
( "DIMENSION1"."key" = "TEMP_TABLE"."key" ) AND
( "DIMENSION2"."key" = "TEMP_TABLE"."key" )
I already tried to use 3 DB-Modules but I have the same problem. :o(
I don´t know what to do!!!!!!!

Fact table showing incorrect quantity measure

Hi,
I have a scenario where i have a fact table with multiple rows and two quantity fields. My source system holds sales by "package" which can contain any number of components. The grain of my invoice table is component level. See
structure below:
PACKAGE1
- Component1 - each package contains 2 of these
- Component2 - each package contains 1 of these
So if i am reporting a sale of PACKAGE1, for a quantity of 2 - component1 had a total sales quantity of 4 and component2 has a total sales quantity of 2. However the package was only sold 2 of, but because of the sum aggregation, i see a total quantity
sold for PACKAGE1 of 6, but it should only show 2 at that level. I have looked at semi-additive measures but am unsure of how this would work in this scenario, or which option would work best for me here.
My fact table has 2 rows, each of which reference the component as one dimension and the package as another dimension.
As a workaround, I have created a calculation to divide the quantity by the number of package components (so it would show a 1 for each of the component lines in my fact table), but then the sales quantities of the components reported are incorrect.
What is the best approach for this?
Thanks in advance,
Dom

Hi Dominic,
Thank you for your question.
I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated.
Thank you for your understanding and support.
Thanks,
Simon Hou
TechNet Community Support

Data Modeling:Criteria to add a logical column to a DIM or FACT table

Hi,
Scenario:
Physical Layer:
- Table_T has following columns: COL_A, COL_B, COL_C
- COL_C is a measure. COL_A and COL_B refer to dimensions.
- COL_A is primary key of Table_A, COL_B is primary key of Table_B
BMM Layer:
1- Dimension table: DIM_A(TABLE_A), Fact table: contains COL_A, COL_B, COL_C
2- Dimension tables: DIM_A(TABLE_A), DIM_B(TABLE_B), Fact table: contains COL_A, COL_B, COL_C
Additional Information:
We can model the BMM layer using the above-mentioned approaches, but either of the two will have some advantages over the other to model COL_B. Some of the advantages of (2) as highlighted by the OBIEE team:
a). Drill down capability will be supported for COL_B,
b). Useful in scenarios where multiple facts need to refer to TABLE_B.
Concern:
We agree with the above technical comments but if someone can provide us with more insight on both the approaches and how an end user can benefit from either approach, it will help us a lot.
We basically need to understand what are the implications if we leave something as just an attribute on the fact and do not model it as a dimension.
Thank you,
Abhishek
P.S. The OBI Server Admin guide does provide us with useful information on the implementation aspect, but we need more information from the end user's perspective.

Very similar to the question below. In pure terms your FACT table should contain no Dimension attributes, Facts tables should contain measures.
Where you have a Physical table that contains a mixture of aggregates and non-aggregate Dimension Attributes then you should split them out in the logical layer into 2 Logical Tables one for the Fact one for the Dimension.
From an end user perspective (certainly the ones I have coached) it is easy for them to understand the the Measures are all in one place, and then if they need to slice and dice then they select the appropriate attributes from the Dimension folders.

How to update a fact table when a dimension table is reloaded

We have implemented BI Apps 796. Insertion into W_EMPLOYEE_D table which stores all the employee information had stopped one year back as some company security policy restricted the informatica worklfows to pick up the data. (PER_ALL_PEOPLE_F was a HRMS table and it contained sensitive information line SSN and salary, was inaccessible to the user which informatica uses and the SDE mapping used to return 0 rows).
Now we have the approval to see those rows and the dimension table is loaded with some 100 new employees who joined in last one year.
The ROW_WID of W_EMPLOYEE_D is referenced in lot of fact tables and for all those missing employees the WID in the fact table is 0.
Now that we have all employees, how to make the FACT table point to the correct WID and not store 0. Has anyone faced this problem before?? Writing an update statement will be a tedious task as there are so many fact tables that join to w_employee_d. Also our company uses Sales, Procurement, Finance modules of OB Apps (which constitutes atleast 20 fact tables)
Any guidance is appreciated. Thanks in advance

Hello Kostis,
thank you for your answer. I don't fully understand you. Can you show me short example, please? I create alias table for time dimension on Physical Layer - original table is TimeDayDim and I create aliases TimeDayDim1, TimeDayDim2, TimeDayDim3, TimeDayDim4. Then I create foreign key Fact.Time1 -> TimeDayDim1, Fact.Time2 -> TimeDayDim2, Fact.Time3 -> TimeDayDim3, Fact.Time4 -> TimeDayDim4. And what now? Must I create these table api Bussines Model and create new time dimensions at bussiness model????
I need in Answers ONE Time dimension. I think I must split my fact table to four tables ... (time1, place1 ...) (time2, place2 ...) (time3 place3...) (time4 place4...) then link those tables to Time dimension (but I dont know where I can split those tables - on Physical Layer or on Bussines Layer).
I suppose that I will have in Answers one time dimension and four facts tables and I will be able to query them. (for example: Time.Days, Fact1.Place1, Fact3.Speed, Fact4.Count Criteria: Time.Year = 2008)
Best Regards Vlada

ROWNUM is indexed in the Fact table - How to optimize performace with this?

Hi,
I have a scenario where there is an index on the Rownum.
The main Fact table is partitioned based on the job number (Daily and monthly). As there can be multiple entries for a single jobID, the primary key is made up of the Job ID and the Rownum
This fact table in turn is joined with another fact table based on this job number and rownum. This second fact table is also partitioned on job ID.
I have few reference tables that are joined with the first fact table with btree index.
Though in a normal DW scenario we should use bitmap, here we can't do that as lot of other applications are accessing data (DML queries) where bitmap will be slow. So I am using STAR_TRANSFORMATION hint to use the normal index as bitmap index.
Till here it is fine. Problem is when I simply do a count for a specific partition from a reference table and a fact table, it is using all required indexes as bitmap with very low cost. But also it is using ROWNUM index that is of very very high cost.
I am relatively new to Oracle tuning. I am not able to understand what it is exactly doing. Could you please suggest if I can get rid of this ROWNUM to make my query performance faster? This index can not be dropped. Is there a way in the hint I can instruct not to use this primary key index?
Or Even by using is there a way that the performance will be faster?
I will highly appreciate any help in this regard.
Regards
...

Just sending the portion having info on the partition and Primary index as the entire script is too big.
CREATE TABLE FACT_TABLE
JOBID VARCHAR2(10 BYTE) DEFAULT '00000000' NOT NULL,
RECID VARCHAR2(18 BYTE) DEFAULT '000000000000000000' NOT NULL,
REP_DATE VARCHAR2(8 BYTE) DEFAULT '00000000' NOT NULL,
LOCATION VARCHAR2(4 BYTE) DEFAULT ' ' NOT NULL,
FUNCTION VARCHAR2(6 BYTE) DEFAULT ' ' NOT NULL,
AMT.....................................................................................
TABLESPACE PSAPPOD
PCTUSED 0
PCTFREE 10
INITRANS 11
MAXTRANS 255
STORAGE (
INITIAL 32248K
LOGGING
PARTITION BY RANGE (JOBID)
PARTITION FACT_TABLE_1110500 VALUES LESS THAN ('01110600')
LOGGING
NOCOMPRESS
TABLESPACE PSAPFACTTABLED
PCTFREE 10
INITRANS 11
MAXTRANS 255
STORAGE (
INITIAL 32248K
MINEXTENTS 1
MAXEXTENTS 2147483645
BUFFER_POOL DEFAULT
PARTITION FACT_TABLE_1191800 VALUES LESS THAN ('0119190000')
LOGGING
NOCOMPRESS
TABLESPACE PSAPFACTTABLED
PCTFREE 10
INITRANS 11
MAXTRANS 255
CREATE UNIQUE INDEX "FACT_TABLE~0" ON FACT_TABLE
(JOBID, RECID)
TABLESPACE PSAPFACT_TABLEI
INITRANS 2
MAXTRANS 255
LOCAL (
PARTITION FACT_TABLE_11105
LOGGING
NOCOMPRESS
TABLESPACE PSAPFACT_TABLEI
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64K
MINEXTENTS 1
MAXEXTENTS 2147483645
BUFFER_POOL DEFAULT
......................................................

How do you handle update and delete rules for fact tables?

I have a fact table with a composite key of 5 columns. Two of the columns are FKs to the date dimension. I was setting the delete/update rules for the FK relationship in SSMS and it had a problem with me creating cascade action on the FKs that connected
to the date dimension.
What is the proper way to set up FK relationships in fact tables with SSMS when you have composite keys as most fact tables do?

Yeah I understand all that. What I'm trying to do is to protect my database from RI violations that occur by production support people blowing away stuff in a dimension table but forgetting to blow away related records in the fact table. I want those fact
records deleted automatically so we don't have orphan records which was a real issue at a previous engagement. Production support is usually just people that know SQL and some relational modeling. It's not too likely they will understand the details of dimensional
modeling enough such that they would know that they had to blow away the fact record first.
My problem is I have a FK to a role playing dimension (the date dimension in this case). So basically I have to columns in the fact table that have a FK relationship to the PK of the date dimension. When I create both relationships SSMS and try to have both
of them cascade delete SSMS has an issue with it.
The error I get is:
Unable to create relationship '[relationship name]'
Introducing Foreign Key constraint '[constraint name]' on table '[table name]' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other foreign key constraints.
I can go ahead and put no action and the table will save fine. The question now becomes how does the cascade delete actually work. Can I just set one part of the key to cascade delete?
Actually I just realized that this is an even bigger design issue. What DOES happen to a fact record when one of it's dimensions gets deleted and I've got full RI set up on the table?
Or am I totally thinking about this wrong. Do you set up cascade deletes in a dimensional model? Is there a way to prevent deletes from the dimension table if there are related fact records?

Understanding Fact Tables

Similar Messages

Maybe you are looking for