Specify Dimension in Framework Manager

[cognoid1]

I'm relative new to Cognos ReportNet (Framework Manager specifically) and looking for advice.Ã,  Why do I need to specify dimension in FM when my data in the DW already had Primary Keys <--> Foreign Keys relationship.

For example, I have a Time Dimension in the DW with PK_DATE_KEY.Ã,  In FM, I have no idea what to put for the attributes/fact when specifying the dimension.

Can someone give me a quick synopsis on this?

thank you.

[BIsrik]

In FM the QS, which has 1:1,0:1 cardinality is treated as dimension and 1:n,0:n is treated as fact tables. U can get more into these by referring a document titled best modelling practices in Frame work manager.

U can download this document from this link..

http://support.cognos.com/phcgi-supported/phcgi?PH_HTML=dlwz001b.html&PH_QKC=dlwz001b&PH_APP=DOCS_LIB&PH_SEARCH=t_product_version_id%3D%3D255*-*-*t_document_type_id%3D%3D4*-*-*t_audience_id%3D%3D0*-*-*t_iso_language_code%3D%3Den*-*-*T_DOCUMENTS_FOUND%3D%3D7&PH_ACTION=LoadResults&PH_LOADID=5&T_PRODUCT_VERSION_ID=255&T_DOCUMENT_TYPE_ID=4&T_AUDIENCE_ID=0&T_ISO_LANGUAGE_CODE=en&T_DOCUMENTS_FOUND=7

Srik

[CoginAustin]

If you have a true DW there is no need to specify anything other then cardinality. There is no need to set levels and what not unless you have no surrogates in your DW

[MFGF]

Hi CoginAustin,

That's not my experience at all with ReportNet.  In the instances where I am reporting from fact tables at different levels of granularity linking to a common set of conformed dimensions, I have always had to specify Dimension Information for each conformed dimension query subject in Framework Manager to get the correct aggregation of facts to happen in my reports.

Sorry - I don't want to appear rude or contradictory - if you have found a way to achieve the correct results without specifying Dimension Information, I'd be very eager to hear about it!

Best regards,

MF.

[CoginAustin]

Fact tables at different level of ganularity? I don't quite understand that statement.

A fact table is joioned to the dimension via a surrogate. That surrogate can be said to be the lowest possible granular level for that dimension. You can roll everything up based on that key by grouping on any column in that dimension.

I have never ran into double counting or any other strange number problems when using this method. I have only run into the problem with an OLTP system(always).


MFGF - Please feel free to say anything you wish. I am glad to hear it all. If I am wrong I am wrong :)

[MFGF]

Hi CoginAustin,

Forgive me - I often start rambling like this!  When I whitter on about fact tables at different levels of granularity, I'm talking about the instance where you have (say) a Sales fact table with sales held at the day level, and an Inventory Levels fact table with stock levels recorded at the month level.  Each uses a surrogate to join to the same conformed Time Dimension - the Sales Fact table uses DaySurrogate, and the Inventory Fact Table uses MonthSurrogate.

If you tried to create a report to show both sales and stock levels of a product (taken therefore from both fact tables), the report would not give you correctly aggregated numbers unless you had identified the hierarchical structure of the conformed time dimension by using the 'Specify Dimension Information' option in Framework Manager.

You can recreate this scenario (mostly) using the sample GOSLDW database shipped with ReportNet if you're feeling bored one day ;-)

As for saying anything I wish - trust me, that would be a bad idea!  The true extent of my senility would then become apparent to all! :-)

Best regards,

MF.