concept of fact and dimension in cognos framwork manager

[inu]

Hi
how can i understand the concept of fact and dimension in IBM COGNOS 10 FRAMEWORK MANAGER. as i m not getting in user guide. as follows

1. what is fact and dimension
2. what is fact table and dimension table
3. how many types of fact and dimension

i m not able to clarify the question, please understand my conception and reply me in a simple way. lots of questions arising in my mind.

Regards
Inam

[blom0344]

The best advice I can give you is to search on 'Ralph Kimball' . Most of the theory about dimensional modelling will be available through this search term. The concept of dimension and facts is not limited to the Cognos domain , it is a general concept.

[RobsWalker68]

Hi Iman,

Agree with Blom, getting an understanding about the Kimball Methodology is the best place to start.  If you go to KimballGroup.com site , go to resources and then Articles and Papers this will have a lot of the information to start you off.

In the meantime if you think of it like this and step back from thinking about the cognos framework for the time being.

Imagine yourself going into a supermarket and buying some milk, rice and chocolate for instance.  You take the products to the checkout whereby the cashier scans the goods and you pay for them and leave. From your transaction the supermarket will hold information about your sale.  It is very likely that the supermarket will have a data warehouse that will hold an aggregation of all sales at all its sites so it can answer questions like which products are most popular at what sites etc.

If you look at what you provided to them:

The fact table will tell them measures so quantity of products sold to you, value of products, maybe Gross Margin, Profit %. It will also include keys like site code, product code, date code, time of day code, employee code etc.  The fact table just represents a certain slice in time i.e. your particular transaction.  You bought x number of products for x amount at a site at a particular time and day, from an employee.

To make this more interesting for reporting purposes they will need to add a context to this and this is where dimension tables come into play.  A Product dimension table won't just hold the product code it will have information such as product name, product type, product line, size.  Similarly the calendar dimension may hold attributes such as day of week, period, year etc.  a Site dimension will hold information about that particular supermarket where you bought the goods like the store manger, type of store, size of store etc.

Now, in the database when you design a star schema you will have a fact table with just its measures (facts) and keys joined to the various dimension tables based on the keys in the fact table.  When reporting you can now construct a report based on any measure and any combination of attributes from the various dimension tables.  If you have this design this is what you import into framework manager.

Hopefully this is a bit clearer.

Cheers

Rob

[Francis aka khayman]

Whoah dude!!!

How did you get in that situation? It seems like you got tossed in the water without knowing how to swim figuratively speaking.

My suggestion is get your hands on some Cognos training materials and lots of coffee. You have a lot of reading to do.

To get you started:

fact - contains the figures usually used for computations (ex sales quantity, sales amount)
dimension - describes the fact (product, location, sales person, when the sales happened, etc)

[MFGF]

Hi Iman,

Agree with Blom, getting an understanding about the Kimball Methodology is the best place to start.  If you go to KimballGroup.com site , go to resources and then Articles and Papers this will have a lot of the information to start you off.

In the meantime if you think of it like this and step back from thinking about the cognos framework for the time being.

Imagine yourself going into a supermarket and buying some milk, rice and chocolate for instance.  You take the products to the checkout whereby the cashier scans the goods and you pay for them and leave. From your transaction the supermarket will hold information about your sale.  It is very likely that the supermarket will have a data warehouse that will hold an aggregation of all sales at all its sites so it can answer questions like which products are most popular at what sites etc.

If you look at what you provided to them:

The fact table will tell them measures so quantity of products sold to you, value of products, maybe Gross Margin, Profit %. It will also include keys like site code, product code, date code, time of day code, employee code etc.  The fact table just represents a certain slice in time i.e. your particular transaction.  You bought x number of products for x amount at a site at a particular time and day, from an employee.

To make this more interesting for reporting purposes they will need to add a context to this and this is where dimension tables come into play.  A Product dimension table won't just hold the product code it will have information such as product name, product type, product line, size.  Similarly the calendar dimension may hold attributes such as day of week, period, year etc.  a Site dimension will hold information about that particular supermarket where you bought the goods like the store manger, type of store, size of store etc.

Now, in the database when you design a star schema you will have a fact table with just its measures (facts) and keys joined to the various dimension tables based on the keys in the fact table.  When reporting you can now construct a report based on any measure and any combination of attributes from the various dimension tables.  If you have this design this is what you import into framework manager.

Hopefully this is a bit clearer.

Cheers

Rob

What a great reply! Have an applause from me! :)

MF.