No. of columns in a fact table

What is the normal range for the number of columns in a fact table in a typical start schema/datawarehouse?
Couple of 100 columns in each fact table...?
Thank you

Post Author: jsanzone
CA Forum: WebIntelligence Reporting
Suzie,
You can create a new local variable to report (called something like "NVP"), leave it as a "Dimension" and in the formula type:
if([col_a]=0 or [col_b]=0;"NO VALUE PRESENT")
Basically, you are using the "if" function and the syntax is very much like used in excel except you separate the arguments with a semi-colon versus a comma. You start out with "if()" and within the parenthesis is a logic statement followed by when true do this else that (with the "else that" portion optional as shown above). The drawback to using a local variable is that every report you write must be customized with the local variable versus establishing this logic in a "case" statement when building the data mart and thus it becomes resident and usable like any other column of data in your database. In some cases you are forced in using it as a local variable due to variations in the data and the logical outcome is not known until the very end of all computations, and at other times you can get away with embedding the logic at the time of constructing your data mart -- it all depends on how the data is used and sliced and diced. Good luck and write back if you have any further questions.

Similar Messages

How to create unique key column in ROLAP fact table?

Hi all,
Is there a way to create a single column primary key (or unique index) on my ROLAP cube (and fact tables) in OWB? if so, what I should do in my mappings?
Thanks!
- Andrew

Have you all conformed dimensions between the two facts?

Issue with non calculated column in a fact table

Hi All,
With 3 facts(Fact1,Fact2,Fact3) and 2 Confirmed Dimensions my joins work fine in Criteria when I include All calculated columns from facts. If I try to include a non calculated column from Fact1(Which is a number Data type) Columns from Fact2 and Fact3 show Null values. I know it is not recommended to include dimension columns in fact , does OBIEE not support Number type non calculated columns as well? Is there any work around that I can bring in my non calculated column from Fact and still get results for other fact columns.Iam at 11.1.1.7 of OBIEE
Let me know if Iam not clear.
Your help is much Appreciated.
Thanks,
Vineela.

i would like to add 2 fields into my fact tables - LOAD ID (populated by a sequence during each load) and LOAD DATE.
as these fields are not related to any reporting dimensions, it is still possible to add them in OWB ? the fact wizard always ask for a foreign key to a dimension ...
Duncan,
If you want to add non dimensional attributes to a fact by using OWB, you can create additional measures to it and use them as attributes.
Igor

Related column of a fact table - SSAS Tabular

Hi,
I'm developing a SSAS Tabular model using a SQL Server 2012 SP 1 installation.
For a fact table I've created some calculated columns using the DAX RELATED function. These columns not are hidden to client tools. When I deploy the project and I open an Excel workbook in order to connect the SSAS Tabular cube, in the field list I cannot
see the calculated columns by RELATED function.
For me, this in an issue and not a normal behaviour.
Any suggests to me, please? Many thanks

Hi Pscorca,
Generally, if we create a calculated column on SQL Server tabular model database on SSMS, and then go to Model-> Process -> Process All and finish the data processing. Then when we connect the database in EXCEL, the calculated column will appear on
the Excel. In your scenario, you cannot see the calculated columns. It’s strange behavior. However we cannot give you the detail reason for this issue base on the limited information. Please refer to the link below which describe the detail steps about
create a calculated column, then check whether if you missing any step when creating calculated column.
Add Calculated Column and Measures to Tabular Model
If the issue persists, please elaborate your production environment and the steps to create the calculated column, so that we can make further analysis.
Regards,
Charlie Liao
TechNet Community Support

Constructing Calculated Measures in MDX for different measures using same columns in a fact table

Hello,
i have a fact table with 2 columns corresponding to dimensions Dim1, Dim2. In the same table i have 4 other columns Value_Type(int), INT_VALUE(int), FLOAT_VALUE(float), TEXT_VALUE(string). There are a number of measures which are identified by Value_Type and
depending on their nature could be written in one of the 3 columns (INT_VALUE(int), FLOAT_VALUE(float), TEXT_VALUE(string)) Let's say Measure1 with Measure_Type=1 is age, 2 is account balance and 3 is Name for clarity. There could be other measure types that
use these 3 same columns for data. So the sample fact table looks like this
Dim1 Dim2 Measure_Type INT_VALUE FLOAT_VALUE TEXT_VALUE
10 10 1 25
10 10 2 2000,34
10 10 3 John
10 20 1 28
10 20 2 3490,23
10 20 3 Frank
My task is to write an MDX query for each Dim1, Dim2 combination which returns all 3 measures in the same row. The idea is to construct a calculated member for each Measure that returns value from the right field. For example for Measure1 we take INT_VALUE
with measure_type=1. The problem is i don't know how to construct MDX query for these calculated members. Can you please help me?
So my final goal is to write an MDX query that returns all measures in one row for each set of Dim1, Dim2
SELECT [Measure1], [Measure2], [Measure3] ON COLUMNS,
NON EMPTY [Dim1].[Dim1].[Dim1].Members*[Dim2].[Dim2].[Dim2].Members ON ROWS
FROM [Cube]
Dim1 Dim2 Measure1 Measure2 Measure3
10 10 25 2000,34 John
10 20 28 3490,23 Frank

Hi Kosmipt,
I would combine the "INT_VALUE", "FLOAT_VALUE" and "TEXT_VALUE" columns into one with STRING data type for the fact table. And there should be one dimension to store the Measure_Type informations. Then in cube, you can write MDX scope for every one of
"Measure_Type" dimension members. For example,
scope(
            [Measures].[M]
    [DimMType].[MType].&[1]= CINT([Measures].[M]);
end scope;
Once the cube is built by the above way, you can write MDX like something like the following to achieve your purpose.
WITH member [Measures].[Measure1] AS ([DimMType].[MType].&[1],[Measures].[M])
         member [Measures].[Measure2] AS ([DimMType].[MType].&[2],[Measures].[M])
         member [Measures].[Measure3] AS ([DimMType].[MType].&[3],[Measures].[M])
thanks,
Jerry

Multiple Date columns in one fact table

hi ,
I have a fact which related to multi date, like bid date, win date, lost date ,etc...,
I have create dimension like dim_bid_date, dim_win_date,
but if I wan to create a report , the value sum by the month (2012.01-2012.08), I don't know how to do in one report which related multi date.
I think I should have a 'common date', how to do, can anyone explain it in detail. thanks.

2 thinks here, do you want to reports based on bid date,win date, lost date etc?
if yes you need to create those many date logical tables and you need to have in Subject area (something like 'Agreement Details' subject area if you have OOB rpd)
Coming to your report requirement 'sum by the month'; I dont think this is complete report requirement, you need to know month type like bid month or win month or lost month or what!!
if user dont want do report by those mentioned dates then just use just date of type( bid,win etc) with out using day dim;
you might have some date like created date, create report based on that for sum by the month.
Hope this helps, if helps pls mark

Including column from fact table reduces number of rows returned

Hello
I am facing this issue where in a report I select 5 columns from a fact table. Out of these five columns one of the column is "Amount" for which the aggregation rule is defined as Sum in RPD.
When I include these five column and filter results based on some criterion , I get all the rows (three rows) that satisfy the criterion. No I add a sixth column to my report and suddenly I only see one row returned by my report. Addition of this sixth column does not affect the criterion as the criterion is not based on this column. But this sixth column is a calculated column.
I tried different things but because the report was just getting columns from one table (fact) and suddenly inclusion of one column leads to reduction in number of rows , I was unable to find any reason why would that happen.
So I thought that some one in community may know that in what scenario this happens.
Thanks

Are there any repeated values? I'm wondering if what you're seeing is actually suppression of repetition in the results. Edit the analysis, go to the criteria tab, click column properties, go to the Column Format tab, and change the setting for value suppression from 'Suppress" to "Repeat". Repeat for each of your 6 columns and check the outcome.
Otherwise, I would try testing with other calculations and also bring in some columns from dimension tables to see how this affects the result. You should be able to come up with a case-by-case scenario to work out exactly what causes the rows to be suppressed which will get us one step to closer to working out why the rows get suppressed.
Thanks,
George

Users selecting "All Choices" on columns in fact table

We have a dimensionalised data structure in our Oracle DW and the fact table contains 750million rows. I'm finding the users are selecting a column in the fact table to filter on, and selecting the "All Choices" option. This then runs an SQL like:
select distinct(column_name) from column_table
Which kills the DW server.
Does anyone know of a way of stopping this? to only allow the All Choices option on one of the dimension tables?
Oracle 11g
BI 10.1.3.4.1
both on Redhat LINUX
Thanks in advance.

Thanks to all for advice/suggestions. In the end I resolved this ( rather a brute force method ) by hacking adjusting one of the XML message documents, standardviewtemplates.xml, that I'd copied into the customMessages directory.
Its a real shame as it removes that function for all users on every table, but some users keep selecting the "All Choices" option even after being told not to.

Mapping the Fact table to different levels of a dimension

Hi,
I have a fact table which stores the data for 4 levels of the dimensions. The aggregation method was taken care by PL/SQL and the fact table will have the data for all the 4 levels. When im trying to map all the levels to a column in the fact table using the OEM, it is generating the F KEY constraints referncing the columns mapped for the various levels of the dimension.
The problem is that im using a denormalised table for maintaing the values of the dimension. So the columns mapped for the levels(Except for the lowest) can't have the unique key defined on it. The cube is not getting created because of the error in creating the F KEY.
Can u please suggest how to map this fact table.
Thnks,
Manohar Vanama

I am not exactly clear on your schema but I believe you are trying to map tables which are not strict star or snowflake. This means that you cannot use CWM1 (and OEM), unless you change the structure of the tables. You might be able to map the tables with CWM2. The document below will assist you:
Oracle9i OLAP User's Guide
Chapter 4. Designing Your Database for OLAP
Chapter 5. Creating OLAP Catalog Metadata

Issue using one 2 Fact tables with one dimension Table.

Hi,
I have 1 Dimension table X and 2 Fact tables A and B
X is joined to Both A and B for Loan Amount ( with A) and for colleatral amount (with B) when I am selecting the X.Product_Name, A.Loan_Amt, B.Collateral Amount, it is giving an error message
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table EIP Collateral FACT) does not contain mapping for [EIP Reporting FACT.PD ID]. (HY000)
Any clues???
Is there a Inner or Outer join which needs to be created or set in the RPD to get the desired results???

Ok..
I have one table which is Porfolio Details which has Portfolio name, Product Category , Product Name, Product ID, Product sources code.- This is my Dimension table.
I have another 2 set of fact tables : EIP Reporting FACT and EIP Collateral FACT..
These two tables are joined to Portfolio Details table.
EIP Reprting FACT gives portfolio wise Loan Amount
and EIP Collateral FACT gives Portfolio wise Collateral Amount details for same set of customer..
Now, I am selecting Portfolio Name, Product Category, Product Name,SUM( EIP Reporting FACT.LOAN_AMOUNT), SUM(EIP Collaetral FACT.Collateral_Amt) in a report
Now, on selecting these columns I am getting that error message which is related to mapping.
If I take any column from Portfolio details table and any column from EIP Reporting FACT- It works.
If I take any column from Portfolio details table and any column from EIP Colletral FACT- It works.
But if I take any column from portfolio table and columns from both FACT tables it gives mapping error...
Hope I am able to explain the issue in a better way now..
Edited by: help-required on Mar 11, 2010 6:53 PM
Edited by: help-required on Mar 11, 2010 6:53 PM

"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

How to determine the logical Keys of logical fact table in BMM layer?

Hello guys
I'd like to know more about how to know what columns of the logical fact table should be used as key in BMM layer. How OBIEE behaving differently when different keys are selected?
In my situation, I have 1 fact table that physically joins to 20 dimensions in physical layer. Therefore, in physical layer, this fact table has about 20 foreign keys but no primary keys..
In the logical layer, this fact table is logically joined to the same group of dimension tables. So in this case, how do I know what columns in logical fact table I should use as keys?
Please advice
Thanks

thanks for the reply...
The interesting thing I notice is that, when I start using fragmentation with the fact tables in its LTS, if not primary key is defined in the logical fact table, then I will be getting errors:
[nQSError: 10058] A general error has occurred. [nQSError: 14023] None of the fact sources for columns are compatible with the detail filter []. (HY000)
When I create the key by choosing random columns from the fact table as the logical key columns, this error goes way and the correct SQL is generated according to the frag..
Because of such behavior, I'd really like to know how logical key really works in BMM layer.

Multiple fact tables

Hi All,
I am using OBIEE 11g. In my requirement, I have 1 Fact table and 3 Materialized Views of fact table. Now, these 3 MV have same columns as actual fact table 1 barring a couple of additional columns in each of them. Imported these 3 MVs and 1 Fact table in Admin tool. In Physical Layer I joinedmy dimensions to each of the Fact (table and MVs). In BMM I created one Fact table with 4 LTS coming from these fact table and MV. Now, all the dimensions are conformed. Still when bring in a column from each of these facts I am getting incorrect results. e.g. when I find sales from years, the data is correct. As soon as I add another fact column from a different MV/fact table the values from first sales column gets changed.
I have check LTSs and Content levels and do not see any problems.
Does anyone have some similar experience?
Thanks,
D

Hi Dcole,
It should not be a problem,you are going in right direction but i want you to check the joins established in the physical layer once again.
But you mentioned a point above saying all the columns are same as actual fact with MV's.I suppose it is assuming as 1 column only.Can you change the column names..
Go through these links for more info
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
http://www.obinotes.com/2010/08/joins-within-logical-table-sources-in.html
hope helps you.
Cheers,
KK

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

Reg: Fact table and Dimension table in Data Warehousing -

Hi Experts,
I'm not exactly getting the difference between the criteria which decide how to create a Fact table and Dimension table.
This link http://stackoverflow.com/questions/9362854/database-fact-table-and-dimension-table states :
Fact table contains data that can be aggregate.
Measures are aggregated data expressions (e. Sum of costs, Count of calls, ...)
Dimension contains data that is use to generate groups and filters.
This's fine but how does one decide which columns to consider for Fact table and which columns for Dimension table?
Any help is much appreciated.
Pardon me if this's not the correct place for this question. My first question in the new forum.
Thanks and Regards,
Ranit Biswas

ranitB wrote:
But my main doubt was - what is the criteria to differentiate between columns for Fact tables and Dimension tables? How can one decide upon the design?
Columns of a fact table will often be 'scalar' attributes of the 'fact' data item. A dimension table will often be 'compound' attributes of a 'fact'.
Consider employee information. The EMPLOYEE table can be a fact table. It might have scalar attribute columns such as: DATE_HIRED, STATUS, EMPLOYEE_ID, and so on.
Other related information that can't be specified as a single attribute value would often be stored in a 'dimension' table: ADDRESS, PHONE_NUMBER.
Each address requires several columns to define it: ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY. And an employee might have several addresses: WORK_ADDRESS, HOME_ADDRESS. That address info would be stored in a 'dimension' table and only the primary key value of the address record would be stored in the EMPLOYEE 'fact' table.
Same with PHONE_NUMBER. Several columns are required to define a phone number and each employee might have several of them. The dimension tables are used to help 'normalize' the data in the employee 'fact' table.
And that EMPLOYEE table might also be a DIMENSION table for other FACT tables. A DEVELOPER table might have an EMPLOYEE_ID column with a value that points to a 'dimension' row in the EMPLOYEE dimension table.

No. of columns in a fact table

Similar Messages

Maybe you are looking for