design methodologies

[pikachu]

Are there any good design methodologies when using Framework Manager to model data that would make it easy for end-users to use query studio? I know this is a very open ended question but I am new to ReportNet and I am approaching it in via a trial and error approach i.e. model my data in FM, then use Query Studio/Report Studio to build my reports. When I find things missing or data incorrectly reported, I go back to FM to re-model my data. Its very tedious.

I wonder if the gurus here can share some experiences in modelling using FM. Are there any whitepapers available?

[HenkK]

There is a lot of discussion going on about this subject. I attended courses at Cognos and each Cognos employee has his/her own approach ???. The basics though are:
- Create a Database view where you put your tables and join those tables; don't put this in your package!
- Create a Business view where you put only the tables/columns that the end user needs; put only this piece in your package
- Add some predefined filters in your business view in a separate folder.

Those are the basics ;D, a lot depends on your source database: is it a datawarehouse or a production system etc.

HenkK

[praveennb]

if you have access to cognos support

search for "Guidelines for Modeling Metadata"

or you could find the same file in the folder where you have installed the framework manager
C:\Program Files\cognos\c8\webcontent\documentation\en

the file name is ug_best.pdf


hope this helps.

[Arpitagrawal9]

Hi Pikachu,

There are various design methodologies which can be used while designing the Model to be used in Query Studio.As you know Query Studio is the reporting tool for creating simple queries and reports in Cognos 8.So your model should be Business oriented because users would be well aware of all the business rules


A model should be designed based on business subject areas, and I personally prefer taking an object oriented approach. Therefore, it is often best to divide the model design into different layers.

The First layer is the database layer - All database objects which are related to one another in one fashion or another, properties of query items (attribute, identifier or fact) and relationship between query subjects are maintained in this layer. You may want to use folders (not namespaces) to organize these tables.

The Second layer is the performance layer - This is layer where you may want to combine two database columns or create any calculations. In case of snow flake modeling, you may want to combine two related dimensions. You can also rename columns, add filters, organize, etc.

The Third layer is the business layer - The package is created from this layer. I prefer to create a namespace based on the business requirements here. For example, if I have budget at only product line level then I will have a namespace with four objects - Product Class, Product Line, Actual and Budget in Namespace1. There will be another namespace, Namespace2, with four objects - Product Class, Product Line, Product and Actual. In this way, I do not have to train user not to pull product while putting budget and actual in same list report. I can then use shortcuts in Namespace1 and Namespace2. This helps me when I modify anything in a query subject, this will get replicated into Namespace1 or Namespace2.


Hope this helps,

Regards,
Arpit Agrawal