Durable Models

8/3/2019 Durable Models

1/21

Proven Practice

IBM Cognos 8 FrameworkManager - Durable Models

Product(s): Framework ManagerArea of Interest: Modeling


2/21

IBM Cognos 8 Framework Manager - Durable Models 2

IBM Cognos Proprietary Information

Copyright

Copyright 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULCis an IBM Company. While every attempt has been made to ensure that theinformation in this document is accurate and complete, some typographical

errors or technical inaccuracies may exist. Cognos does not acceptresponsibility for any kind of loss resulting from the use of informationcontained in this document. This document shows the publication date. Theinformation contained in this document is subject to change without notice.Any improvements or changes to the information contained in this documentwill be documented in subsequent editions. This document containsproprietary information of Cognos. All rights are reserved. No part of thisdocument may be copied, photocopied, reproduced, stored in a retrievalsystem, transmitted in any form or by any means, or translated into anotherlanguage without the prior written consent of Cognos. Cognos and theCognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated)in the United States and/or other countries. IBM and the IBM logo are

trademarks of International Business Machines Corporation in the UnitedStates, or other countries, or both. All other names are trademarks orregistered trademarks of their respective companies. Information aboutCognos products can be found at www.cognos.com

This document is maintained by the Best Practices, Product and Technologyteam. You can send comments, suggestions, and additions [email protected] .


3/21



Contents

1 INTRODUCTION ............................................................................................ 41.1 PURPOSE................................................................................................................ 41.2 MODEL DESIGN........................................................................................................ 41.3 MODELLING FORMULTIPLE LANGUAGES........................................................................ 15


4/21



1 Introduction

1.1 Purpose

There is no guarantee when creating a model that aspects of the underlying

database, or user requirements change and thus affect your model. The goalis to create a model that can survive as many of these changes as possiblewithout impacting the end user and their existing queries. This document willpoint out some concepts which will help you to create models that will be asflexible as possible and help survive changes to the requirements.

1.2 Model Design

The most important aspect of the model which can be done to ensure

durability is to use a layered approach. The term layered approachmeans the use of at least a database (also known as import) layer and abusiness (or presentation) layer.

The concept is that any modifications that are needed to be done to thequery subjects are done to the Business view, this includes security. Changesthat should minimize the impact on existing reports are those done oncalculations, security or descriptions of Query Items. Changes to the actualnaming conventions will impact existing reports and require the author tomodify them.


5/21



Report Prior to Business View Change

Example of the Business View in the FM model changing due to clientrequirements. In this case were changing Order Number to Order No.


6/21



Once this change has been made, the Report built against the Business viewis no longer valid as it has a reference to a Query Item which no longerexists.

Error Opening the report in Report Studio.


7/21



To fix the report simply delete the previous Query Item and add in thealtered Query Item. In this case its a simple resolution however anycalculations or references built off of the old Query Item Order Number willalso have to be changed. Notice that the filter also had to be changed.

The database or import view should be left alone, and where possible importonly what is needed rather than everything in the underlying database.Changes done to the Import view should minimize the impact on the enduser, depending on the type of changes. Issues like changing of databasecolumn names should not impact the business view assuming you thenmodify the Import view query subject to point to the new databasetable/column and then associate the Query Item in the Business view in themodified Query Item from the Import View. In the example below a changeis to be made to the Order Details Table on the database. Order Number isbeing changed to Order No. and as a result the model will need to bechanged.


8/21



Report Prior to Database Change.


9/21



Change Made to Database


10/21



After the change has been made on the database an error will occur in theFM model, to fix the error the Query Subject needs to be updated to reflectthe new information in the database.


11/21



Once the Import View has been changed you will also need to change theBusiness View to include the changed Query Item. Verifying the model inFramework Manager will result in a message like the one below.


12/21




13/21



Once all changes in the model have been made and the package has beenrepublished there should be no impact on the reports created against hepackage assuming the report author used the business view to create theirreports. Changes to Query Item names in the Import View will have noimpact on the reports.


14/21



To simplify things, when changing any part of a model check to see whatreports will be impacted by the change. This can be done using the Findreport dependencies task in Framework Manager.


15/21



1.3 Modelling for Multiple Languages

Another option for building a durable model is to create a model with a baselanguage other than that which you have within your business requirements.For example assume that youre users work in both English and French. Anoption is to create your model and use something other than English orFrench as the design language for the model. English (Zimbabwe) would bean alternative for the design language which you could create the necessarystructure.

Create a new Model using English (Zimbabwe) as the design language.


16/21



You would then add the languages that the users need into the model, forthe above mentioned scenario you would then add English and French intothe model.

A translation is then performed on the project. Assume that you have aquery item called order number in the design language. English users wantthe item to say ORDER NUM and French users want the item to sayORDER NO.


17/21



Your report authors should now create reports in the design language, thenany necessary changes to Query Items done in each of the reportinglanguages can be done without impacting the reports

Report Created with English as the Content Language


18/21



Report Created with English (Zimbabwe) as the Content Language

If the English requirements change once the model is published, then anychanges done to the model will not impact previously created reports thatwere created with English (Zimbabwe) as the Content Language at the timeof creation.


19/21



Change made to the Framework Manger project. Note the Active Languageand the change to the ORDER NUM object.


20/21



Report created with English (Zimbabwe) as content language after thechange to the Order Number object for the English language. The user thatran this report had their Content Language to English at the time ofexecution.


21/21



However if you used English as the design language instead of English(Zimbabwe) then all reports using ORDER NUM would need to be recreated.Attempting to run these reports regardless of the language will result in thefollowing error.

Durable Models

Documents

Transcript of Durable Models