Do all Fact Tables have to be aggregated?

When implimenting aggregations do all the fact tables have to be aggregated to the same levels?

I'm not sure what I have done wrong..
I have a dimension setup with hierarchy sources. (week, month, year)
I have a fact table with aggregate data loaded. - all data is reported.
I have a fact table with base level (week) data only:
The only way I can get data to return is to set the metric (units) logical level.
I then don't get a total number (aggregate number) when pulling month or year.
Anyone who can help with this configuration would be greatly appreciated.

Similar Messages

How many line item dimensions can a fact table have?

Hi,
How many line item dimensions can a fact table have? Is it tht Max of 16 dimensions(13+3) .Does the 16 dimensions include line items dimensions as well .
Pls reply.
Thanks
Praveen

It includes all dimensios, including line item dimensions.
If you have line item dimension, pl note you cant assign any other characteristic to that dimension.
Ravi Thothadri

Fact table have tow column reference the same dim table

In my analytic domain, my fact table have tow column reference the same dim table, but in physical diagram, between two table ,can only have one join, so i create a copy of the dim table, then finish the join in physical. This method can resolve this question, but not so good, Anyone have perfect solution?

user4497169 wrote:
Thanks,
yours method is very very good, I don't know this method before. Where do you get this imfomation?The sample sales RPD has (good) modelling references you can refer to, otherwise think about how you'd write the SQL Statement yourself, you'd need to use an alias to access the same table on seperate joins.

Dimension and Fact table have the same grain

Hi All,
How can we join a dimension and a fact table if they have the same grain ? In my case it is a contract number.
Thanks

Your Impression is right, In terms of Dimensional Modeling. You have to consider this when you are designing your warehouse tables.
But now if you already have these tables in database, OBIEE does not care how many rows a table have, it just need to know what is fact and what is Dimension and it will generate sql queries based on join conditions.

OBIA How to truncate all fact tables automatically before running a full load

With every run data gets appended to the fact tables.How to configure so that with every run data gets deleted before we start the load.
We have OBIA 11g

If you are using DAC for scheduling the ETL jobs, you can list out the fact tables that are being used in your execution plan and set the Refresh dates for those tables as NULL. This action makes the dac execution plan to consider loading the data freshly into the fact tables.
Steps to make Refresh date as NULL in DAC:
To make the refresh dates as NULL for your fact tables in DAC, go to Setup tab -> Physical Data Sources
Now select the connection Datawarehouse(In my case) -> Refresh Dates
Query your fact tables and go to Refresh Date column and click on the calendar Icon
Click on NULL button to make the refresh date as NULL for that particular table and click on ok and save.
In the similar manner do it for all the fact tables you want.
After the above process, once you run the execution plan then data will be loaded freshly.
Regards,
Obul

Join multiple fact tables and dimensions and use all tables in report issue

Hi,
I have a report requirements and need to use multiple fact tables and unconformed dimensions as described below
Fact table: F1,F2,F3
Dimensions tables: D1.....D9
F1:(joined to) D1,D2,D3,D4
F2::(joined to)D1,D2,D5,D6
F3::(joined to)D1,D2,D7,D8
D7::(joined to)D9,D8 (dimension D7 joined to two other dimensions D9 and D8
I'm trying to use columns from almost all the fact and dimension tables but getting "Unable to navigate requested expression. Please fix the metadata consistency warnings."
Repository is consistent and no errors and warnings.
How can I configure the repository to develop reports using all fact tables and dimensions?
Appreciate for your help.
Thanks
Jay.
Edited by: Jay on Feb 9, 2012 4:14 PM

So you want me to convert snowflake schema to star. does it solve my problem? individual star queries are working find but when I query multiple stars together getting inconsistency errors. I removed content tables dim level totals for unconformed dimensions in logical fact LTS and set level for measures at total level for unconformed dimensions. it is still in progress and need to test.
Thanks
Jay.

How to join Dimensions and Fact Tables in OBIEE

Hi All,
I need to create report which need to get the information from two fact tables and 7 dimensions. The granularity is not same in both the fact tables. One fact table is having common keys between all the dimension tables and second fact table have only two dimension keys but with different names. My requirement is to create the report by taking the measures from both the fact tables.
I have created joins between the second fact table and two dimension tables in physical and BMM layer and also set the highest level for all other dimension tables in the LTS of second fact table. when am creating report by taking the measures from both the fact tables, data is not getting for the measure which taken from the second fact table. Please advice me how to get the data for the measure which taken from the second fact table.
Thanks in Advancec !!

You have to use the level-base measure capabilities.
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/level_based_measure_calculations
For all measures of the second fact table with the lowest grain (with two dimension keys), set for all dimension where you don't have any key the logical level to the "All" or "Total".
And UNSET the highest level of the LTS for the second fact table.
Success
Nico

Error VLD-0917 (unknown error) while deploying FACT table

Hi,
I keep getting this error while trying to deploy a FACT table:
VLD-0917: An unknown error occured while generating <fact table name>.
An unknown error occurred while generating <fact table name>. Error details: java.lang.NullPointerException.
Do yo know what can it be? This fact table was linked to a Dimension that I modified (added one more level to its hierarchy). Since I did this change, the fact table cannot be validated.
This happens to all fact tables that use this dimension. I created a new cube with the new definition of the dimension and had no trouble at all. I disassociate the dimension from existing cubes and they validate OK. What could be happening?
I would appreciate any help you could provide.
Regards,
--oswaldo.
[osantos]

Hi,
I realized that I'm getting this error for all fact tables. I cannot deploy any of them. What could be happening? I have a dimension that is linked to all facts which I changed recently: had to redefine its default hierarchy as a value-based one. I don't know if this affected my cubes.
Any idea what might be happening here?
Best Regards,
--oswaldo.
[osantos]

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

Duplicate record with same primary key in Fact table

Hi all,
Can the fact table have duplicate record with same primary key . When i checked a cube i could see records with same primary key combination but the key figure values are different. My cube has 6 dimentions (Including Time,Unit and DP) and 2 key figures. So 6 fields combined to form the composite primary key of the fact table. When i checked the records in se16 i could see duplicate records with same primary key. Ther are no parallel loading happening for the cube.
BW system version is 3.1
Data base is : Oracle 10.2
I am not sure how is this possible.
Regards,
PM

Hi Krish,
I checked the datapacket dimention also. Both the record have same dimention id (141). Except the Keyfigure value there is no other change in the Fact table record. I know this is against the basic DBMS primary key rule. But i have records like this in the cube.
Can this situation arise when same records is there in different data packet of same request.
Thx,
PM
null

Primary key in Fact table

Hi ,
I have a question usually fact table consists of all primary keys from different dimensional tables but i have a requirement like this:
Fact table consists of non-dimensional columns and one primary key Amount_ID(PK) aand this amount_ID is a FK in another table which records day to day transactions. My question is can a fact table have a PK ?
Thanks,
ch

Yes Fact Table can have a Primary key
But in your case it looks like the Other Table which is storing Day to Day transaction should be made FACT , and the one you are calling FACT should be made Dimension..
Well depends again, how you are analysing data and against which attributes
Thanks
Ashish

Adding Dimension field ($) in measures (fact) table in logical layer

Hi,
I have a field (amount) in the dimension table. I would like to add this field in the fact table at the logical layer. Dimension table and fact table had physical joins. Can I add into fact table and still do aggregation on that field based on the other dimensions linked to fact table. I working on Siebel Analytics version 7.8. Any help would be greatly appreciated.
Thanks in advance,
RK

Check here : How to create a measure from data that is stored in a dimension table
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/obiee_measures_dimension
Cheers
Nico

Fact tables with different granularity

We currently have 3 dimensions (Site, Well, Date) and 2 fact tables (GasEngine, GasField), both having granularity of a day.
GasEngine is linked to Site and Date
GasField is linked to Site, Well and Date
We now have a requirement to make the GasEngine fact table have granularity of an hour but keep
GasField at a day.
We therefore must include a new Time dimension, which would only be linked to GasEngine.
Is it ok to have a DW with these two fact tables having different granularity?
And would we therefore require two separate cubes for querying this data?

Hi Rajendra and Visakh16,
Based on your input provided to this thread, I would like to ask a question just to fine-tune my knowledge regarding data modelling. In Darren’s case I guess his date dimension only store dimension records up to day level granularity. Now the requirement
is to make the “GasEngine” fact table to hold data granularity of an hour.
Now based on Rajendra’s input
“Yes, you can have. but why you need new time dimension, I recommend, make GasEngine fact to
hour granularity.”
How Darren could display data for each hour without having a time dimension attached to GasEngine fact table? With the existing date dimension he ONLY can display the aggregated data with the minimum granularity of day level.
Now anyone can modify the date dimension to hold time records which will complicate the date dimension totally. Instead why Darren cannot have a separate time dimension which hold ONLY time related data and have a timekey in GasEngine fact table and relate
those tables using the time key? This way isn’t Darren’s data model become more readable and simplified? As we provide another way of slicing and dicing data by using a time dimension I do not think Darren’s cube becomes a complex STAR schema.
I could be totally wrong therefore for the sake of knowledge for Darren and me I am asking the question from both of you.
Best regards…
Chandima Lakmal Fonseka

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.

Optimize Fact tables in SSAS Tabular Model

Hi,
I have five Fact tables in SSAS Tabular Model and each fact table share same dimensions. It creates some performance issue and also the data model looks very complex is there any simplest way to create simple data model using all fact tables. For Ex...
Please suggest me for this ...
Fact Tables:
Fact_Expense
Fact_Sale
Fact_Revenue
Fact_COA
Fact_COG
Dimensions:
Dim_Region
Dim_Entity
Dim_Product
Dim_DateTime
Dim_Project
Dim_Employee
Dim_Customer

Hi hussain,
Please consider merging the Fact tables based on granularity. Generally, if you have enough RAM there will be no performance issues. Make sure you have double the amount of RAM to cater your processing and operational needs.Try
to optimize the model design by removing unused keys and some high cardinality columns.
Please go through the document in the link:
http://msdn.microsoft.com/en-us/library/dn393915.aspx
Regards,
Venkata Koppula

Do all Fact Tables have to be aggregated?

Similar Messages

Maybe you are looking for