Fact table design horizontal vs vertical

Hi Guys,
I am putting together a list of advantages and disadvatages of horizontal vs vertical fact table orientation.
Vertical:
ID, DimensionKey1, DimensionKey2, Factno (or KPIDimensionKey), Fact
Advantages:
-Easily extendible when new facts are integration
-A lot more rows
-Density
Disadvantages:
-Applications that can only deal with the horizontal format require a few to
transpose the rows into columns (additional computing time)
Horizontal:
ID, DimensionKey1, DimensionKey2, Fact1, Fact2, Fact3, Fact4, Fact5,...
Advantages:
-The most common fact table design
-Possibly faster access
Disadvantages:
-Sparsity
-Not easy to extend

Do you agree or can add something?

Similar Messages

Fact table design advice

Good Morning All,
I'm working on developing a cube that measure's budget and actual cost for a customer that I'm working with. We have serveral dimensions that comes into play:
Organization - this dimension defines the various internal departments at the customer location where each department sets a budget or actual cost for each month.
DateTimePeriod - this dimension defines the transaction date when the budget or actual cost was recorded. This dimension contains year, quarter, month and day columns.
Expense Item - this dimension defines a specific expense item that a budget and actual cost is assigned too such as rent, utility, software licences,etc...
Cost Type - this dimension defines if the cost within the fact table is a budget or actual cost.
Within my fact table I store primary key fields values for each of the dimension table listed above. Included with this table is a cost column that represents the budget or actual cost. The problem that I'm having is....The budget cost and actual cost are seperate
records...For example, I have one record that has the budget cost and then I have another record that has the actual cost....
My feeling is that the budget and cost records should be store on same record instead of seperate records. Also I would like note we're using PerformancePoint to surface the cube data to the client and both the budget and cost needs to drill down to the
month level only for phase 1. I have a feeling that the customer would want in the in future to measure down to the day level...
So my question is....What is a better design:
Keeping the actual and budget costs within a fact table on seperate rows using the Cost Type dimension to identify if the cost is a budget cost or an actual cost or....
Keeping the actual and budget costs within a fact table on the same row and removing the need for a Cost Type dimension......
Please help...
Make sure you mark my reply as the answer if it had solved your request. Brandon M. Hunter MCTS - SharePoint 2010 Configuration

Why? Wouldn't be easier if I make a database change and add the budget and actual cost on the same row??What would be the advantage or disadvantage to your approach???
As per my experience, there could be more than one version of a budget value. Initially we start with budget for an account, and then have the actual for the same account for the same period. If we 100% sure that we get only these two versions (Budget and
Actual) then upto a certain point, two columns implementation is fine. What if the budget is revised, how do you hold it, adding another column? What if you need to maintain a forecast value for same account, same period, create another column for that? Considering
all accounting and budgeting scenario, I still suggest to have multiple rows for all these versions (or scenario, or cost type). Again, refer AdventureWorksDW for seeing this implementation.
Since you are going to build a cube from this, you can easily view accounts recorded like this (which is mostly viewed by business users when analysing accounts). It is an advantage too.
In terms of disadvantages, I see only one disadvantage which is storage cost.
Dinesh Priyankara
http://dinesql.blogspot.com/
Please use Mark as answer (Or Propose as answer) or Vote as helpful if the post is useful.

Multiple granular levels for fact table

My fact table has to incorporate both at Transaction level and Accumulative , my basic design for Transaction level is as follows
CUSTOMER_KEY, LOAN_KEY, TIME_KEY, LOAN_AMT, TOTAL_DUE, LOAN_STATUS, TRANSACTION
9000,1000,1,200,200,Open, Advance
9000,1000,1,200,0,Close, Payment If I aggregate the values then query will take time to execute . How can I provide cumulative information from this fact table? shall i go for one more fact table for Accumulative information ?
Please suggest.
Thanks,
Hesh.

Hi ,
Is it a question of OLAP cube generation using your fact table design ? If not then it is incorrect forum ..If yes , then it should be straighway ur fact and dimension design and no need of another fact table with aggregation because OLAP cube aggregate this which should ideally be tremendous fast
Thanks,
DxP

Fact table enriched with hierachy information

Hi Guys,
I have a fact table design question.
The fact data table (oracle10g) on bottom level RelationshipManager (RM) contains the data columns
for the RM dimension:
FACT TABLE
ID¦RM¦DEPARTMENT¦AGENCY¦REGION¦SALES
1---23--Bronx------------NY---------US-------23232
2---24 ---------------------NY---------US-------87878
3---25-----------------------------------US------ 9999999
This means the fact has been enriched with hierachy information, this is not whats usually done.
Why have I done it? Because the RM is not necessarily always part of a department BUT can also
be directly placed under an agency or a region (agency or region leads).
Have I made the right choice by chosing to enrich the fact table? I could have also build a snow flake
schema by storing hierachy information in a seperate table.
Thanks.

with your problem, it might be best to split the dimension into multiple dimensions or multiple attribute dimensions with default values where you do not have a value for example set up RM with a N0_RM and when you don't have data load it there. If I'm looking at this correctly, the problem it appears you have is you have an inconsistent hierarchy. where the rollups can change. having them in the same dimesion would be problematic. If therewere consistancy then you could add members into a single hierarchy something like
US
--No_State
--NY
-----Bronx
------RM23
------No_RM
but from your example I don't see it. If they are seperate dimensions(not attribute dimensions) then you could load based on date. If they are attribute dimensions, then look at varying attributes

DW FACT table/Structure ??

Hi Everybody,
It is a great forum. Thanks for your replies/suggestions to my earlier posting. I am hitting FACT tables design by several folks over the period of time. It is puzzling me. I like to bounce this table in this forum to get your ideas/thoughts. As per FACT table definition, it need to contain single (instance) of FACT described by multiple dimensions. Here is the FACT structure I found in my situation.
DIM_KEY1 )
DIM_KEY2 )--> Foreign Keys to DIM Table
DIM_KEY2 )
TRANS_ID ----> Degenerate Dims
TRANS_TYP_CD )
TRANS_S_CD )
SRC_TYE_CD ) -----> Type codes derive multiple instances of FACTS from
ADJ_TYP_CD ) single fact table, based on type code combinations
DB_CR_CD )
TRANS_AMT ---> Fact
It looks like multiple fact tables (instances) forced into single fact table, where it fall under single super type/sub type structure of logical data-model. Here are my questions.
1)     Did any one work with such fact tables?
2)     Does it a acceptable design in star schema approach?
3)     What are the impacts in queries/ETL?
Thanks in advance.
RI

Hi,
Not clear with ur explination on the Fact but here are some general tips...
The instance in a fact table is decided by the keys from the DIM table and also the dates (effective and term dates) in case u maintain history.at any point in time (between effective and term date) we should have have only 1 instance live (current record).The type_cd does not matter and should not be used to create or distinctly identify an instance of a fact.
Regards
Bharath

SSAS Tabular - Vertically partitioned Fact Table Relationships

Hi All, I have a very wide (300 column) fact table and hence it is partitioned into 2 fact tables vertically with the common key in both tables for relation (1:1). Both the tables have some measures and degenerate dimensions to be used for analyisis.
How should the data model look like? I am stuck because the bi-directional relationships doesnt seem to be supported and only one direction works when degenerate dimensions are used.
Also, these two fact tables are related to some common dimensions and when i connect all of them together, some of the relationships get deactivated due to circular naure of relationships. Using USERELATIONSHIPS is going to be very timeconsuming considering
the number of measures.
What is the guidance around modelling vertically partitoned fact tables? Do I combine both the tables into one wide table using a View or Query? Any help appreciated.
Thanks, Ashish Singh

Hi Thomas, Unfortunately I do not have any control over the DW design and the client says that they require most of the columns for analysis. I do not want to combine the fact tables into a wider table but stuck with the relationship design in Tabular mode.
1) Bi-directional relationships are not supported. So, if both the fact tables have degenerate dimensions on which the mesaures have to be analyzed, it cannot work because the relationships are unidirectional in tabular mode.
2) Relationships get deactivated. Since both the tables are connected to each other using a KEY column, any attempt to connect both the tables to some common dimension results in INACTIVE relationships which needs either using USERELATIONSHIP or importing
the same table again with a different alias which complicates the model.
3) Inferenced relationships cant be modelled. If Fact1 is connected to a dimension, the measures of Fact2 cannot be analyzed on that dimension even though Fact1 and Fact 2 are connected using a 1:1 relationship.
All these design challenges make me lean towards using a SQL View and joining the 2 Fact tables in the Tabular model so that I could provide the users with the analysis they require using the current DB structure. Is there a different approach to achieve?
Any better ideas would be heplful.
Thanks, Ashish Singh

How to design a fact table to keep track of active dimensions?

I would like to design a classic OLAP facts table using a star scheme. The SQL model of the facts table should be independent of any concrete RDBMS technology and portable between different systems.
The problem is this: users should be able to select subsets of the facts based on conjunctive queries on the dimension values defined for the facts. However, the program that provides the interface for doing this to the user should only present those dimensions where anything is still selectable at all. For example, if a user selected year 2001 and for dimension contract code there is only a single value for all records in the fact table for that year, this dimension should not be shown to the user any more. This should be solved in a generic way. So for n dimensions in total, if the current set of facts is based on constraints from j dimensions, I want to know for which of the remaining n-j dimensions there is still something to select from and only show those.
The obvious way is to make a count(*) query on the distinct foreign keys of each of the dimensions on the fact table, using the same where clause. That means that one would need (n-j) such queries on the whole facts table and that sounds like an awful waste of resources given that the original query for selecting the facts could have done it internally "on the fly".
How can this be achieved in the most performant way? Is there a "classical" way of how to approach this problem? Is there tool support for doing this efficiently?
Any help or pointers to where one could find out more about this would be greatly apreciated - thank you!

>
Did you get the counts for each value of each dimension by doing a separate query with the current "WHERE" clause on each dimension?
>
My method doesn't apply to your use case. I wrote a Java class to create my own bit-mapped indexes on CSV files. So each attribute value was a one million bit binary raw.
I don't know, and don't want to know, what your particular requirements are. But I can show you a basic process that will work for large numbers of rows. Get a simple process working and then explore to see if it will meet your particular needs. Not going to answer questions here about anything but about my example code
1. Assume a single fact table with one primary key column and multiple single-value attribute columns.
2. The table is not subject to DML operations AT ALL - truncate and load if you want apply changes. Meaning it will be useful for research purposes on archived data.
3. The purpose of the table is to select the fact table ROWIDs for records of interest. So the only value selected is a result set of ROWIDs that can then be used to get any of the normal FACt table data and other linked data as needed.
Create the table - insert some records, create a bitmap index on each dimension column and collect the statistics
ALTER TABLE SCOTT.STAR_FACT
DROP PRIMARY KEY CASCADE;
DROP TABLE SCOTT.STAR_FACT CASCADE CONSTRAINTS;
create table star_fact (
    fact_key varchar2(30) DEFAULT 'N/A' not null,
    age      varchar2(30) DEFAULT 'N/A' not null,
    beer    varchar2(30) DEFAULT 'N/A' not null,
    marital_status varchar2(30) DEFAULT 'N/A' not null,
    softdrink varchar2(30) DEFAULT 'N/A' not null,
    state    varchar2(30) DEFAULT 'N/A' not null,
    summer_sport varchar2(30) DEFAULT 'N/A' not null,
    constraint star_fact_pk PRIMARY KEY (fact_key)
INSERT INTO STAR_FACT (FACT_KEY) SELECT ROWNUM FROM ALL_OBJECTS;
create bitmap index age_bitmap on star_fact (age);
create bitmap index beer_bitmap on star_fact (beer);
create bitmap index marital_status_bitmap on star_fact (marital_status);
create bitmap index softdrink_bitmap on star_fact (softdrink);
create bitmap index state_bitmap on star_fact (state);
create bitmap index summer_sport_bitmap on star_fact (summer_sport);
exec DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'STAR_FACT', NULL, CASCADE => TRUE);Now if you run the 'complex' query for the example from my first reply you will get
SQL> set serveroutput on
SQL> set autotrace on explain
SQL> select rowid from star_fact where
2   (state = 'CA') or (state = 'CO')
3 and (age = 'young') and (marital_status = 'divorced')
4 and (((summer_sport = 'baseball') and (softdrink = 'pepsi'))
5 or ((summer_sport = 'golf') and (beer = 'coors')));
no rows selected
Execution Plan
Plan hash value: 1934160231
| Id | Operation                      | Name                  | Rows | Bytes |
|   0 | SELECT STATEMENT               |                       |     1 |    30 |
|   1 | BITMAP CONVERSION TO ROWIDS   |                       |     1 |    30 |
|   2 |   BITMAP OR                    |                       |       |       |
|* 3 |    BITMAP INDEX SINGLE VALUE   | STATE_BITMAP          |       |       |
|   4 |    BITMAP AND                  |                       |       |       |
|* 5 |     BITMAP INDEX SINGLE VALUE | AGE_BITMAP            |       |       |
|* 6 |     BITMAP INDEX SINGLE VALUE | MARITAL_STATUS_BITMAP |       |       |
|* 7 |     BITMAP INDEX SINGLE VALUE | STATE_BITMAP          |       |       |
|   8 |     BITMAP OR                  |                       |       |       |
|   9 |      BITMAP AND                |                       |       |       |
|* 10 |       BITMAP INDEX SINGLE VALUE| SOFTDRINK_BITMAP      |       |       |
|* 11 |       BITMAP INDEX SINGLE VALUE| SUMMER_SPORT_BITMAP   |       |       |
| 12 |      BITMAP AND                |                       |       |       |
|* 13 |       BITMAP INDEX SINGLE VALUE| BEER_BITMAP           |       |       |
|* 14 |       BITMAP INDEX SINGLE VALUE| SUMMER_SPORT_BITMAP   |       |       |
Predicate Information (identified by operation id):
   3 - access("STATE"='CA')
   5 - access("AGE"='young')
   6 - access("MARITAL_STATUS"='divorced')
   7 - access("STATE"='CO')
10 - access("SOFTDRINK"='pepsi')
11 - access("SUMMER_SPORT"='baseball')
13 - access("BEER"='coors')
14 - access("SUMMER_SPORT"='golf')
SQL>As you can see Oracle is combining bitmap indexes on columns in a single table to implement the same AND/OR complex conditions I showed earlier. It doesn't need any other table to do this.
In 11g you can create virtual columns and then index them.
so if you find that the condition 'young' and 'divorced' is used frequently you could create a VIRTUAL 'young_divorced' column and create an index.
alter table star_fact add (young_divorced AS (case
   when (age = 'young' and marital_status = 'divorced') then 'TRUE' else 'N/A' end) VIRTUAL);
create bitmap index young_divorced_ndx on star_fact (young_divorced);
exec DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'STAR_FACT', NULL, CASCADE => TRUE);Now you can query using the name of the virtual column
SQL> select rowid from star_fact where young_divorced = 'TRUE'
2 and (state = 'CA') or (state = 'CO')
3 /
no rows selected
Execution Plan
Plan hash value: 2656088680
| Id | Operation                    | Name               | Rows | Bytes | Cost
|   0 | SELECT STATEMENT             |                    |     1 |    28 |
|   1 | BITMAP CONVERSION TO ROWIDS |                    |       |       |
|   2 |   BITMAP OR                  |                    |       |       |
|* 3 |    BITMAP INDEX SINGLE VALUE | STATE_BITMAP       |       |       |
|   4 |    BITMAP AND                |                    |       |       |
|* 5 |     BITMAP INDEX SINGLE VALUE| STATE_BITMAP       |       |       |
|* 6 |     BITMAP INDEX SINGLE VALUE| YOUNG_DIVORCED_NDX |       |       |
Predicate Information (identified by operation id):
   3 - access("STATE"='CO')
   5 - access("STATE"='CA')
   6 - access("YOUNG_DIVORCED"='TRUE')
SQL>
----------------------------------------------------------------Notice that at line #6 the new index was used. The VIRTUAL column itselfl doesn't create data for the fact table; the definition only exists in the data dictionary.
The YOUNG_DIVORCE_NDX is real and does consume space. The tradeoff is additional space for the index but you make the query easier because you don't have to recreate the complex condition every time.
Oracle can work with the complex condition and combine the indexes so this really only helps the query writer. Your UI should be able to hide the query construction from the user so I would avoid the use of VIRTUAL columns and an additional index until you demonstrate you really need it.
If you provide users with their own RESULT table to store custom query results you could just store the query name and the set of primary keys from the result set. I used ROWIDs in the example but don't use rowid for a real application - use a primary key value that won't change.
So your UI would let users construct complext dimension queries for 'young_sportsters' and get a result set of primary keys for that. They could save the label 'young_sportsters' and the primary keys in their own work table. Then you can let them run queries that use the primary keys to query data from your active data warehouse to get any other data it contains.
>
Did you get the counts for each value of each dimension by doing a separate query with the current "WHERE" clause on each dimension?
>
For an Oracle implementation you need to do a count select for each dimension. I haven't tried it but you might be able to do multiple dimensions in a singe query. One query would look like this>
-- get the dimension counts
SQL> select beer, count(*) from star_fact group by beer;
BEER                             COUNT(*)
N/A                                 56977
Execution Plan
Plan hash value: 1692670403
| Id | Operation                | Name        | Rows | Bytes | Cost (%CPU)| Ti
|   0 | SELECT STATEMENT         |             |     1 |    12 |     3   (0)| 00
|   1 | SORT GROUP BY NOSORT    |             |     1 |    12 |     3   (0)| 00
|   2 |   BITMAP CONVERSION COUNT|             | 56977 |   667K|     3   (0)| 00
|   3 |    BITMAP INDEX FULL SCAN| BEER_BITMAP |       |       |            |
SQL>Notice that Oracle uses only the index to gather the data.

Design patterns for updating a fact table

I have a fact table and about 10 dimensions.
One of these dimensions can be missing values, so the fact table row will link to an UNKNOWN value.
When the correct value is finally entered in the dimension table i want to update any associated fact rows.
Whats the most efficient way of doing this?

I know i have to use a lookup transformation ;-)
I wouldnt be at teh stage of even having a fact table if i didnt know that! I was looking for a design pattern, not the name of a shape!
The solution i went with was to take a hard line on any rows with unknown values. If when importing the data there are unknown values for two of the most important dimensions, those rows are not inserted into the fact table, but instead pushed to an ErrorLog
table.
Users run a report that shows what this table contains and if they really want those rows, they insert the correct dimension values and rerun the import, which will only import any rows not already in the fact table.
This way:
1. all sorting & filtering issues are resolved as there will be no unknown rows for the most important dimensions used in sorting and filtering.
2. we can quickly see any rows with unknown values and figure out whats wrong. its always missing reference data that the client didnt think to give us. a quick insert of the dimension data and import and the rows get imported.
thanks for the replies.

Use of time series functions with horizontally fragmented fact tables

Hi Guys,
in OBIEE 10g it wasn't possible to use time series functions [AGO, TO_DATE] on horizontally fragmented fact tables. This was due to be fixed in 11g.
Has this been fixed? Has somebody used this new functionality? What the the limitations?
Tkx
Emil

Hello,
Can you give us some examples for "horizontally fragmented fact tables", we can tell you whether we can do that or not?
Thanks,

Design of Fact Table

Hello,
I am relatively new to BI and am wondering the pros and cons of a particular design of a fact table and associated dimensions. In the first case below the fact table would have one row with fields T, N, M for which the codes would come from a dimension
(the Tis etc just demonstrate the idea -- would normally be an integer key in place).
In the second case I have two dimensions - one for the Criteria (T,N, or M) and another table for the actual Criteria values. This approach would require numerous rows for each ID - again the fact table would just be populated with keys from the two
dimensions rather than the actual values seen below.
Is either of these just plain wrong or are both valid but one is better than the other?
Thanks kindly for any consideration.

Hello Nimesh,
Thank you for the thoughts. Please see my replied below.
1. Will there be any other/Additional value needs to be added in future? (Except T,M,N)
There will initially be a set of values including T,M,N (more may be added in the future depending on
what new things international cancer research comes up with but for now these are pretty static)
2. What will be value if ID 1234 is not related to N or M?
There a whole bunch of other measurements that are taking in addition to N, M,and N. Typically, one sees a fact table as narrow but long. In this case since there are many different dimensions for staging a cancer the fact table could be 10 columns
wide AND long.
3. What is the relation between (T and Tis) or (N and N3)? Can it linked to One to many?
Tis only one possible value for the measurement T. There could be T1, Tx, T2 etc etc. These are all just types of T measurements. Same for N and M. One can say that if a patient has T of Tis, N of N3 and M of M0 then their cancer
stage is III.
4. If it's Dimension model, you can combine small dimensions into one dimension.
Do you have a specific example of this in mind or I can look at on a website?

Designing a cube with two Fact tables

Hi,
I am new to multi-dimensional modeling. I am trying to define a cube with two fact tables which have many to many relationship. so I came up with following schema:-
I want to design a cube so that I can get the count of "FactOne" items which are related to "FactTwo" items having particular status. So, I want to get the count of "FactOne" where they are related to items in "FactTwo"
which have "Status1". Could anyone please guide me how would I do it?
Thanks

Hi Ahsan,
In your scenario, there are tow fact tables on your Data Source View, and now what you want is that "count of FactOne" which are related to "FactTwo" in a particular status, right?
It seem that you have find a blog that describes how to select facts with reference dimension on you another thread. As per my understanding, you can follow that blog to achieve your requirement.
http://bifuture.blogspot.com/2011/11/ssas-selecting-facts-with-reference.html
Regards,
Charlie Liao
If you have any feedback on our support, please click
here.

TableView horizontal and vertical scrolling is horribly slow

How can I adjust the horizontal and vertical scrolling amount?
I used the Ensemble example prorgam and streched the column so that the horizontal scroll bar is displayed. I then used the right scroll button which then scrolls extremly slow. I've looked at the javadoc on the tableview and I cannot determine how to set the scrolling amount. I can check if the table is scrolling but I would like to set the amount to be a column width at a time when using the left or right arrow.

It probably needs to be actually rendered to the Scene graph before the lookups can be made, so the lookups won't work in the initialize method.
There are a number of reasons I don't like this solution
- I don't like the string binding
- the fact that there are scrollbars that are descendant nodes of the table view is not documented, so (at least in theory) a future release of JavaFX could choose not to use the ScrollBar class (for example by creating its own scrolling implementation). This would break the code you have.
- if you decided to create (or use) an alternative skin for the table view which had other scrollbars in place (again, unlikely but theoretically possible), you'd end up setting the unit and block increments of those scrollbars too. In other words, there's no guarantee these are the actual scrollbars you want.
So, not ideal but at least if it works you have something...

How to create summation column with different measures of fact table

If I have a salary fact table with columns MONTHID | BASIC-SALARY | TRAVEL-ALLOWANCE
and in Deski, I drag all the three columns to form a horizontal table
then is it possible to create a summation column to show total salary?
I don;t want to create a variable because in that case the formula need to be changed everytime there is a new allowance.
regards,
binayak

Hello Binayak,
as you refer to Deski I recommend to post this query to the [BusinessObjects Desktop Intelligence|SAP BusinessObjects Desktop Intelligence; forum.
This forum is dedicated to topics related to the creation and design of Desktop Intelligence documents such as universe connectivity, prompts, charting, formatting, filter, and formulas.It is monitored by qualified technicians and you will get a faster response there.
Also, all Desktop Intelligence queries remain in one place and thus can be easily searched in one place.
Best regards,
Falk

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

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

Fact table design horizontal vs vertical

Similar Messages

Maybe you are looking for