What is Cognos Datawarehouse

[Daljith]

Why has the question come up is because earlier there was a report schema where all the views were created that were required by cognos reports. The package was using these views for reports.
But now we have been specifically given one database which can be used directly for Cognos. This has been done to increase the performance of the reports. This has direct tables and not the views.
So, how does this make difference for me?
Can someone suggest please?

[MFGF]

Why has the question come up is because earlier there was a report schema where all the views were created that were required by cognos reports. The package was using these views for reports.
But now we have been specifically given one database which can be used directly for Cognos. This has been done to increase the performance of the reports. This has direct tables and not the views.
So, how does this make difference for me?
Can someone suggest please?

Consider this - if you write a report from a model over a normalized data set (spanning lots of tables), the query generated will need to join lots of tables and will be very complex and potentially long-running. Normalized data sets are designed for fast inserts and fast updates, not for mass-retrieval and aggregation of data. This means few indexes and atomic storage of data in many linked tables. Now consider the same query based on tables in a data warehouse. Chances are the number of tables involved is vastly less - perhaps a handful at most, if the tables follow a star schema design. Which is going to be more efficient, a query spanning 5 tables or a query spanning 500 tables? Also consider that a data warehouse has design objectives to provide fast, easy reporting, with as many indexes are are required to make data retrieval fast.

Does that help?

MF.

[iLico]

thank you for your clear explanation.
cheers, iLico

Consider this - if you write a report from a model over a normalized data set (spanning lots of tables), the query generated will need to join lots of tables and will be very complex and potentially long-running. Normalized data sets are designed for fast inserts and fast updates, not for mass-retrieval and aggregation of data. This means few indexes and atomic storage of data in many linked tables. Now consider the same query based on tables in a data warehouse. Chances are the number of tables involved is vastly less - perhaps a handful at most, if the tables follow a star schema design. Which is going to be more efficient, a query spanning 5 tables or a query spanning 500 tables? Also consider that a data warehouse has design objectives to provide fast, easy reporting, with as many indexes are are required to make data retrieval fast.

Does that help?

MF.

[Daljith]

Thanks MF for the answer. The concept is clear to me. One more thing if you can help with it?
Earlier I was just having all the views published from Framework Manager.

In this case, how do I use new tables and their joins for the reports. I mean do I need to bring all the tables in Framework Manager and put all the joins. Or if you can suggest how it would be different from using direct views.

[MFGF]

Thanks MF for the answer. The concept is clear to me. One more thing if you can help with it?
Earlier I was just having all the views published from Framework Manager.

In this case, how do I use new tables and their joins for the reports. I mean do I need to bring all the tables in Framework Manager and put all the joins. Or if you can suggest how it would be different from using direct views.

Best practice modelling in FM is to have at least two tiers in your model:

A "foundation layer" which contains data source query subjects and relationships, and points directly to the tables/views in the database(s)
A "consolidation layer" which contains model query subjects based on query items from the foundation layer query subjects

The consolidation layer is used as the basis of the package contents that get published to the Cognos server, and from which your reports are built. This means that you can replace and update objects in the foundation layer later on, and re-link the consolidation layer items to the new foundation structures without there being any impact on your reports (since they are still based on the same consolidation layer structure).

If you attend the official Framework Manager training, all these concepts are clearly explained, along with lots of other very useful advice and best practice tips, so I'd suggest you try to take that training if you can - it will help you enormously.

Cheers!

MF.