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?

Similar Messages

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.

Multiple fact tables using one measure

Hi Experts,
Multiple fact tables using single measure .For example Measure name is amount . This measure is using 5 fact tables. By using this info , i have to create bmm layer document . In bmm layer documents columns are like logical table name ,column name, logical sourc name . could you please help me out to draft the document ?

Hi ,
My question is five fact tables are there, day level two different fact tables , period and week fact tables are there .
Above all tables are using single measure . how to design these fact tables with measure in bmm layer ?
Please kindly give reply .
Thanks in advance.

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.

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.

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?

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.

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

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

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.

Dimension Table Larger Than Fact Table

Hi,
I need a solution to deal with a situation in my project. The master data for the Business Partner is close to 20 Mil and growing. The overall records in the fact table is only 1.5 to 2 Mil.
I am looking for suggestions that can help me in designing a optimal data model which does not hinder the reporting performance. Reporting with 20 Mil records in Dimension and 10 times less data in the fact table is not common occurance. I guess this is a scenario that the retail Industries would have experinced due to the huge customer base.
P.S: Segregation of the dimension is something that will not help. And its currently a line item dimension. So any thoughts apart from these will be highly appreciative.
Thanks!
Sajan R

Hi Sajan Rajagopal ,
I think u need to just go through the dimensions u had created so trat u can delete unnecessary infoobjects assigned to tat dimension and can build a dimension whcih has only those of master data.
For Ex...for the material master when we checked we had huge amount of data more than ur's so we had made diffenet dimenons for material and batch and then we had tried to load the data for tat dimensions and it was working fine and also data loads also getting loaded fine..
Please check ur dimensions once so tat required ones are defined correctly in the dimensions

Date 01/01/1901 in W_DAY_D when joined to a date wid in a Fact Table

Hi
I noticed when w_day_d joined to a Fact table I am getting a CALENDER date as 10/10/1901. I have checked by joining these tables. When Fact Wid is '0',
Join is getting 01/01/1901 as date.
But I want to avoid this and display a 'NULL' value. How could I conver this date into a 'null' in Answers please.????
Thank you.

Hi,
We are using Dac Build AN 10.1.3.4.1.20090415.0146.
The start date is 01-Jan-1980 and end date 31-dec-2010.
I am interested to change the end date to 31-dec-2020.
For that I have created a custom container.
Design -> Task -> Query on SIL_DayDimension ->Parameters
Click on value, change the end_date to required value.
Save.
Setup -> Physical Datasource
Click on DataWarehouse.
Change W_DAY_D Refresh dates to null.
After running DAC W_DAY_D table is not having any record and end_date is showing as blank in paramter file
So I want to change it to original one that is as it was before.
When I de-clone it, the value for end_date is showing as Custom Format() @MM/DD/YYYY and if I add any value to it the after running dac end_date is showing as blank in paramter file and W_DAY_D table is not having any record.
Any help is greatly appreciated.
Regards,
Bhoomi

Fact Tables without Dimension Tables.

Hi,
I am currently working on a project where a data warehouse is being developed using an application database as the source. Since the application database is already normalised, the tables are being loaded in as they are and the consultant involved is creating
data marts for them. I have asked about why he is not creating separate dimension and fact tables as data marts, and he has told me that he will create a fact table with the dimensions as column names without any dimension tables created as you might expect
as per star/snowflake schema.
Is this right, as I always thought you had to have dimension and fact tables, especially if you want to start using SSAS?
Regards,
W.

create a fact table with the dimensions as column names without any dimension tables created as you might expect as per star/snowflake schema.
This is the trouble with denormalization: where is the stopping point?
If the data warehouse is the source for SSAS OLAP cubes, it is better to go with the usual star schema.
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Multiple fact tables and dimensions

I have two fact tables actual sales and planned sales and 8 dimension tables, using a star schema. I want to query on the two fact tables with two dimensions, product and time. When I create the report in discoverer i bring in the sales from actuals and then the product_desc and month_desc. Then I bring in the measure from the second fact table and a join window pops up asking which join to use. If I choose the join to the time dimension then I get no data for the second fact table and correct data for the first fact table. If I choose the product dimension then I get correct data for the first fact table and grossly incorrect data for the second fact table.
How can I stop this from happening?
Nick

Nick,
I hope you solved your reporting issue and can share the solution with me. I am encountering the same problem. I have used Oracle Warehouse Builder 10Gr2 to design and deploy a pretty simple ROLAP data mart. We are using Discoverer Plus for OLAP as our reporting tool. We have 5 dimension tables using a star schema and have 3 fact tables, when I create the worksheet I bring in our sales measure from our sales item table and then Store_Name from my Stores Dimension and then week-ending from my time dimension, everything looks good at the stage. Then I bring in a measure from our advertising cost table and a join window pops up asking which join to use, if I choose either the Store or the Time dimension I get correct data for the first fact table (sales) and grossly incorrect data for the ad cost from the second fact table (advertsing costs)...... any help would be appreciated
monalisa

Design of Fact Table

Similar Messages

Maybe you are looking for