If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Cognos Basics Help

Started by B.C., 25 May 2016 05:17:58 PM

Previous topic - Next topic

B.C.

Hello – First thank you for taking the time to respond and sharing your great knowledge. I'm fairly new to Cognos and I've been tasked with building various cubes that can be used to run ad-hoc reports on. I've completed a decent amount of reading and tutorials, and I'm now trying to better understand some principals that I am still a little confused about and how they relate to my environment. I've learned that there are two modeling methods in which you can create cubes – Relationally Modeled Relational models (RMR) and Dimensionally Modeled Relational models (DMR). My datasource is SQL Server and I've been able to create both RMR and DMR models using this datasource. My datasource is currently in somewhat of a de-normalized relational state. However, I've been thinking of transforming this data into another SQL Server database which is dimensional modeled (i.e. a star schema with facts, measures, dimensions).


So I have a few questions based on this:

1. Am I correct that if I transform my database into a dimensional model, I should then use an RMR model because my data is already dimensionally modeled?

2. Is there a way to build hierarchies with RMR using a dimensionally modeled datasource?

3. Am I really creating a 'cube' when I model something in Framework Manager (FM) and publish it to Cognos Connection?.. or is it just a model (and if so how do I create a cube)?

4. When I model something using DMR I get drop zones for 'Page layers' and 'Context filters'. Is it possible to mimic this capability in RMR models?

MFGF

Quote from: B.C. on 25 May 2016 05:17:58 PM
Hello – First thank you for taking the time to respond and sharing your great knowledge. I'm fairly new to Cognos and I've been tasked with building various cubes that can be used to run ad-hoc reports on. I've completed a decent amount of reading and tutorials, and I'm now trying to better understand some principals that I am still a little confused about and how they relate to my environment. I've learned that there are two modeling methods in which you can create cubes – Relationally Modeled Relational models (RMR) and Dimensionally Modeled Relational models (DMR). My datasource is SQL Server and I've been able to create both RMR and DMR models using this datasource. My datasource is currently in somewhat of a de-normalized relational state. However, I've been thinking of transforming this data into another SQL Server database which is dimensional modeled (i.e. a star schema with facts, measures, dimensions).


So I have a few questions based on this:

1. Am I correct that if I transform my database into a dimensional model, I should then use an RMR model because my data is already dimensionally modeled?

2. Is there a way to build hierarchies with RMR using a dimensionally modeled datasource?

3. Am I really creating a 'cube' when I model something in Framework Manager (FM) and publish it to Cognos Connection?.. or is it just a model (and if so how do I create a cube)?

4. When I model something using DMR I get drop zones for 'Page layers' and 'Context filters'. Is it possible to mimic this capability in RMR models?

Hi,

1. No, sadly it's not that easy. A relational model in Cognos provides query subjects and query items, but doesn't have any concept of hierarchies. The term "dimensionally modelled" really has two different meanings here. In your database, it's a term that indicates your tables are arranged in star or snowflake schemas, and (hopefully) will provide the fastest, easiest foundation for reporting. In your Framework Manager. You can have tables in this form that are used in relational models, and the benefit is simple, efficient queries are generated, plus there's no need to remodel the data structures in Framework Manager to deliver accurate, consistent results. You can use these in situations where drill down/up and slice-and-dice capabilities are not required. In some cases, this is all a business requires. However, if you want your model to look like and behave like an OLAP cube, you need to go a step further in your modelling and create Regular Dimensions and Measure Dimensions. These are the foundations of a DMR model. You define hierarchies to describe the drill-down/up abilities in each dimension, and your measures are grouped in Measure Dimensions. This is the other meaning of "Dimensionally modelled", and it's something different to the meaning we described previously. It's simply indicating that your model looks and behaves like an OLAP cube.

2. As above, no. Relational models don't have any concept of hierarchies you can define. Hierarchies are defined in DMR Regular Dimensions.

3. No. You're creating a metadata model in Cognos that makes your relational data look and behave like it's in an OLAP cube. Under the covers, it's still there in the database tables, though, and is queried directly from these tables using SQL. I like to consider DMR as a "virtual" cube. If you want data in a "real" cube, you'd use the appropriate cube metadata modelling tool to create the cube (eg Transformer for Cognos PowerCubes, Performance Modeler for TM1 cubes, Cube Designer for Dynamic Cubes etc).

4. No. Context filters and page layers are only available for dimensional packages (ie packages based on real OLAP cubes or on DMR which looks and behaves like a cube). You don't get these capabilities with a relational package.

Cheers!

MF.
Meep!

bdbits

An interesting side note, perhaps... As I recall, I think I first heard this at a developer session at an IOD conference. The gist is that when using DMR packages (as I recall, specifically with DQM), under the covers Cognos actually spins up a temporary - virtual if you wish - cube. I imagine this would make it much easier to reuse the code Cognos created for dimensional functions. How/why it behaves in comparison beyond this I do not know. I think the original discussion was discussing performance and cache management, which for large or complicated data sets and models could obviously be a hit at startup.

I am not suggesting an FM package can be a cube - other than dimensionality it most certainly is not. But I find it an interesting tidbit.

B.C.

Wow, I've haven't found anything that states and explains this so straight forward. Thank you both very much. This is extremely helpful!

MFGF

Quote from: bdbits on 26 May 2016 09:49:31 AM
An interesting side note, perhaps... As I recall, I think I first heard this at a developer session at an IOD conference. The gist is that when using DMR packages (as I recall, specifically with DQM), under the covers Cognos actually spins up a temporary - virtual if you wish - cube. I imagine this would make it much easier to reuse the code Cognos created for dimensional functions. How/why it behaves in comparison beyond this I do not know. I think the original discussion was discussing performance and cache management, which for large or complicated data sets and models could obviously be a hit at startup.

I am not suggesting an FM package can be a cube - other than dimensionality it most certainly is not. But I find it an interesting tidbit.

It's not just DMR this is true for. If you create a crosstab report off a plain relational package, a virtual cube is spun up based on the data selected. If you know what you're doing and tread warily, you can use dimensional functions for some things (although you have no specific members or hierarchies/levels to refer to). I'm pretty sure Lynn did just this recently!

Cheers!

MF.
Meep!