wa_tti_modeling_proven_practices_for_ibm_cognos_framework_manager.doc

8/10/2019 wa_tti_modeling_proven_practices_for_ibm_cognos_framework_manager.doc

1/22

Modeling Proven Practices for IBM Cognos Framework Manager

Event ID: 15447

Chris McPherson: My name is Chris McPherson. I'm the Product Manager forFramework Manager and Metadata in the Cognos platform. I am going to be

speaking to you today about modeling proven practices for IM Cognos Framework

Manager. !ome of the things we are going to talk about today are modeling

metadata for business intelligence" modeling for consistent" predictable results. #e

are going to talk a little bit about maintainable models. #e will talk about purpose

built models to match reporting re$uirements. %hen we are going to move into

some modeling concepts. #e will touch on topics of cardinality" determinants"

granularity and !& generation.

(nd )nally we will talk a little bit about some useful features in Framework Manager

to help you streamline your modeling. #e are going to look at the bulk change

capabilities" Conte*t +*plorer and the Model (dviser.

Modeling for consistent and predictable results , at the end of the day what you

really want to get out of a good Framework management model is consistent and

predictable results. -ou also want good performing $ueries" but the numbers really

need to be correct. !ome of the keys to driving those results you want are

understanding your reporting re$uirements. -ou need to sit down with your reportauthors and make sure that their reporting re$uirements are clear. -ou really need

to have a sense for the sort of business $uestions report authors will be trying to

answer. If you are not clear on what it is that they want" it is unlikely that you will

be able to deliver what they want.

&uestions like what kind of reports will they be writing. o they need relational

packages or dimensionally remodel packages/ 0r do they need both/ #hat

additional re$uirements are there for the application/ o they need security

implemented" and if so" what kind/ Is there a re$uirement for multi1lingual data/%hese things are the easiest to manage when you know about them in advance and

can implement them as you go rather than trying to retro)t them afterwards.


2/22

2now your data. It is important to communicate with your ( and become familiar

with the structure you will be modeling. -ou should have he or she identify the fact

tables" dimensions and which tables connect as both.

3reat purpose speci)c views. 3ive the report authors what they want by organi4ing

it into a logical fashion tailored for their reporting re$uirements.

%he last point to make in this slide is to leverage modeling resources. %here is a

wealth of information available in the FM documentation" the guidelines for

modeling metadata and the proven practices website. %here are a lot of documents

out there that can e*plain and illustrate how to tackle speci)c challenges. Chances

are you are not the )rst person to run into them and there might be an answer

already out there.

uilding maintainable models. uilding a maintainable model is something that I

think is really fundamental. -ou want to build a model that is well organi4ed and it

is easy to navigate. %o that end import only what you need. Importing only the

ob5ects that you need at the start and then gradually adding as you go will make it

easier to navigate and )nd things in your model. (lso" change as little as possible

in the import view because changes at this level are universal in the sense that they

will a6ect all of the upper level ob5ects that might use them as a source.

(fter you import" always verify the relationships and $uery item properties in the

import view. -ou want to ensure that the necessary relationships are present and

that the cardinality is correct for the reporting purposes. -ou should also ensure

that the $uery items are correctly identi)ed as this can a6ect $uery generation.

I recommend creating a business view or a logical view to apply your business rules.

-ou can add your calculations" )lters" et cetera at this level as well as give your

ob5ects names that report authors will understand. !omething else that a business

view does is give you a level of insulation from changes that you might need to

make down the road. 0b5ects at this business level can be retargeted to di6erent

import view sources without impacting the higher level ob5ects.

Create a presentation view to organi4e your ob5ects for the report authors.

Presentation view is the layer that you want the report authors to see in the


3/22

metadata tree in the studios. !o organi4e your ob5ects accordingly so that it is easy

to navigate and understand.

%he last item in this section that I would like to speak about is keeping models to a

manageable si4e. %he larger the model is" the more di7cult that it can be to

navigate. (lso very large models can cause performance issues in Framework

Manager and can make the 8Is sluggish and unresponsive. Certain memory

intensive operations are more fre$uently a6ected but it is a matter of good practice

to keep your models below 9 megabytes in si4e.

Purpose built models. I would recommend avoiding the temptation to build a one1

si4e )ts all model. %he reality is that it will be di7cult to build and maintain a model

that will satisfy all of the reporting re$uirements of all of your lines of business.

( better approach is to build several smaller" more focused models that are really

targeted at a line of business or a set of re$uirements. ikewise" for ad hoc

reporting models that are easy to navigate and almost guide the user are best.

Most people do ad hoc reporting because they want a $uick and simple way to get

out their data. !o we should model and publish packages accordingly.

For professional report authoring" more comple* models and packages may bere$uired. (nd )nally" for analysis you are talking about a dimensionally modeled

package to allow for the drill1up" drill1down e*perience.

;ow we are going to talk a little bit about some modeling concepts in Framework

Manager. First modeling concept I would like to talk about is cardinality and how

Framework Manager uses it. Cardinality is used to identify $uery sub5ects that

behave as dimensions and facts. 0ne to end cardinality implies fact data on the

inside and dimensional data on the one side. %his is also used to help $uery engine

avoid things like double counting and to support loop 5oints.

%he role of cardinality in the conte*t of a $uery is important because cardinality is

used to determine when and where to split the $uery when generating multiple fact

$ueries. If dimensions and facts are incorrectly identi)ed" stitch $ueries can be

created unnecessarily. %his is costly to performance or can result in incorrectly


4/22

formed $ueries which can give incorrect results. &uery sub5ect may behave as a

fact or a dimension depending on the $uery sub5ect included in the $uery.

!o an important recommendation to keep in mind is that you should always review

and verify the imported relationships for their accuracy and cardinality. Check for

multiple relationships" optional cardinality" although sometimes this is necessary for

your business re$uirements. #herever possible use cardinality to clearly de)ne

facts in your data source view.

eterminants , what are they and when do I need them/ eterminants re


5/22

%o try to give a simple e*ample that will e*plain determinants and granularity" let's

return to the time dimension scenario. In this case each uni$ue instance of month

key will repeat once for every day in a month. If you don't tell the $uery engine that

month key re$uires grouping at the month level" sales target will be double counted

for every day of the month" resulting in wildly incorrect sales target numbers.

%o eliminate the potential that double counting will occur" you should set a

determinant at each level of granularity. %o continue the previous e*ample" in this

case you would set a uni$ue determinant on the day key as it is the uni$ue key in

the table and is at the lowest level of granularity. (s such" you would select the

uni$uely identi)ed check bo* and do not check the group by bo*.

For month key you would not select the uni$uely identi)ed bo* because it repeats in

the data" once for every day" and therefore is not uni$ue. -ou would select the

group by determinant for the month key.

%he ne*t topic we are going to touch on is !& generation. -ou can specify how

Framework Manager generates the !& that retrieves data from relational data

sources for data source $uery sub5ects or model $uery sub5ects. %he !&

generation type of a $uery sub5ect can be set to either (s @iew or Minimi4ed. y

default it is set to Minimi4ed. #hen the generation type is set to Minimi4ed" the

generated !& contains only the minimum set of tables and 5oins needed to obtain

values for the selected $uery items. %his is generally desirable because the fewer

tables included in your !& statement" typically the faster your $ueries can be

processed.

#hen generation type is set to (s @iew" Framework Manager generates $ueries that

contain the full !& statement that de)ne the $uery sub5ect. %he !& is treated as

a view. For e*ample" you want the $uery to return the same number of rows each

time that it is run.

!o now let's have a look at a little demo where we can see where the !&

generation settings are con)gured.

!o I select a $uery sub5ect" I right click and select +dit e)nition. From the resulting

dialogue I will select &uery Information. (nd then 0ptions. (nd then )nally the !&


6/22

!etting. -ou will see I have the option to set as Minimi4ed or (s @iew. (s I

mentioned" Minimi4ed is the default setting.

3enerally speaking" because of the performance bene)ts of having fewer tables

referenced in the $ueries" it is recommended to use Minimi4ed !& wherever

possible. Aowever" there are certain settings that will trigger (s @iew !& and will

override the setting" for e*ample" determinants on a model $uery sub5ect"

relationships between model $uery sub5ects and )lters" macros" calculations" et

cetera in your data source $uery sub5ects.

It is important to remember that (s @iew !& is not always bad. In fact it can

sometimes be necessary depending on your re$uirements. (t the end of the day"

our modeling guidelines focus on ensuring consistent" predictable results" so in

some cases tradeo6s need to be made to ensure that.

;ow we are going to spend a few minutes talking about features that can help

streamline the modeling process. First o6 we will talk about ulk Change

capabilities. %his feature allows users to search for $uery items by property and

then make changes in ulk. (s we noted earlier" it is very important that $uery

items be correctly identi)ed in terms of usage as this can a6ect $uery generation.

It is important to review the usage of the $uery items in your data source $uery

sub5ects after import to ensure that they are properly identi)ed. ecause you have

the ability to search for $uery items by property as well as by name" this feature

would be useful in making modi)cations to collections of $uery items when

performing your validation after import.

In this demo" after we have done an import we are going to search for all of the

$uery items identi)ed as fact to ensure that they are correctly identi)ed.

I click the search button and I can now see all of the $uery items that have the

usage of fact. I can see from the list that a number of key )elds have been

incorrectly identi)ed as facts. I want to change the property to ensure that they are

handled as identi)er by the $uery engine. I can simply select all of these columns

and I see them listed in the properties panel below.


7/22

%o make these change I 5ust need to select the usage dropdown and select Identi)er.

0nce I have done that I can pull down on the little arrow to make the change across

all of the columns. I can now go back and e*amine those columns and see that

they have been changed to Identi)er.

%he ne*t feature I would like to talk a little bit about is the Conte*t +*plorer. ;ow

the Conte*t +*plorer is a mechanism that lets you select $uery sub5ect in your

model and then launch a diagram to display the other ob5ect around it. It will show

the selected $uery sub5ect and all of those $uery sub5ects that are related. %his

gives you a means to do some lower level e*ploration of a portion of your model.

In the Conte*t +*plorer itself you have the ability to perform a lot of the same

actions you could do in the regular view. -ou can create new $uery sub5ects" you

can edit e*isting $uery sub5ects" modify e*isting relationships between $uery

sub5ects or add new ones.

%here are also a couple of handy features like the ability to print the diagram you

see or have organi4ed in Conte*t +*plorer. %here is also a screen capture capability

so that you can easily paste an image of the diagram you are using into an email or

other document for sharing and collaborating with team members.

%o launch the Conte*t +*plorer" simply select the $uery sub5ect from the metadata

tree in Framework Manager. From the right click menu you will have the option to

launch Conte*t +*plorer. -ou can see that the result is a diagram that has the

selected ob5ect at the center and all of the related ob5ects laid out on the screen

around it. From here you can edit the relationships" add relationships" modify the

$uery sub5ects as re$uired. -ou also have the option to show all of the related

ob5ects with all of the relationships.

%his might be a little too much information" so the default view might be )ne for

most operations. (s I mentioned you also have the ability to print and from the

right click menu you can take a screen capture that you can easily share with

teammates.

%he last feature I want to talk about is one that was )rst introduced in version B.? of

Framework Manager. (nd that is the Model (dvisor. Model (dvisor is a tool that


8/22

analy4ed your model or a part of your model based on the documented modeling

guidelines and identi)es potential issues that should be e*amined. It will look for

things like ambiguous 5oin paths" potential issues with cardinality and determinants

and so on. For novice modelers" the Model (dvisor can be helpful as an assistive

tool problems that are encountered are documented and there are links to images

to demonstrate the issue encountered as well as links to the documentation whereyou can )nd more detailed information about the problem at hand.

For more e*perienced users" the Model (dvisor can be a good diagnostic tool.

Periodically in the modeling process users can run the Model (dvisor to identify any

potential areas of concern that should be ree*amined. Model (dvisor will check for

potential issues in the following area , cardinality 5oin path determinants setting

and DgovernorE con


9/22

0nce we have con)gured the Model (dvisor we simply click the (naly4e button and

we end up with a useful list of potential issues based on the criteria that we set.

%here are links to the Conte*t +*plorer where you can have a more visual view of

the problem that it is describing. From here you can also take steps to remedy the

potential issue. (nd there are also helpful links to the documentation where you

can drill down into the problem and get some more detailed information along withsome potential paths to resolve.

-ou can also print or save this list and have it on hand as we work through our

modeling issues and have it available to share with other team members.

!o as we saw" the Model (dvisor can be invoked to analy4e your entire model or can

be used on a per ob5ect basis. ike the verify model feature" it is something that

should be used in stages as you build your model. 0ne suggested work


10/22

Aello everybody it is Chris McPherson here. I would be glad to answer whatever

$uestions you have. If you want to submit them by chat what I will do is I will read

out the $uestion and I will give some comments. %here are a lot of people on the

line" so if we donHt get to all of them please donHt hesitate to send me an email and I

can follow up with you oine.

0bviously if the $uestion is something that we need some back and forth or need to

talk about something speci)c then I would probably advise that you 5ust send me an

email and I will follow up with you directly.

!o" one of the )rst $uestions we have got here is when should a $uery sub5ect item

be set as an identi)er and not an attribute/ !o generally speaking the rules

Framework Manager uses for this are if a $uery item is part of a key in a

determinant it generally speaking should be an identi)er. ikewise if it participates

in a relationship it should be an identi)er. (nd if it is a data type date or time it

would be an identi)er.

If it is none of the above and it is not a fact than it would be an attribute. (ttributes

are typically strings.

;e*t $uestion. #hy is it preferred to apply relationships to data sources" $uerysub5ects and model $uery sub5ects/ #ell" generally speaking we recommend

keeping the relationships at the data source level because these are the ob5ects

that are going to be reused. ;ow" having said that" like anything else it really

depends on the reporting re$uirements. (dding relationships to your model $uery

sub5ects can trigger (s @iew behavior and it also re$uires that all relationships to

that model $uery sub5ect would need to be recreated at that level. %he

encapsulated relationships" in other words the relationships between the data

source $uery sub5ects that made up that model $uery sub5ect would be respected

but 5oins to that data source $uery sub5ect would be ignored. !o you would have to

recreate those relationships at your business level to the other model $uery sub5ect

level. Aowever" adding your relationships at the model $uery sub5ect level" at thebusiness level rather can be useful to override relationships if that happens to

match the reporting re$uirements or if you want to generate some speci)c $uery

behavior.


11/22

#e have another $uestion , can you address the situation when the data modeler

and the report developer are the same person/ (re all the levels in the model still

necessary when the report developer understands the database design/

i6erent schools of thought on this. generally speaking we advocate having

multiple levels for a number of reasons to give you a layer of abstraction so that you

can keep your data source view in tact and keep it as close to the structure of your

data source as possible and then give you" have a business view where you can

create some model" $uery sub5ect" do some denormali4ation if that is what you

need to do" add )lter and calculations and so on.

!o it also gives you a level of insulations so that you can retarget these model $uery

sub5ects if you happen to have a change in the data source. !o it gives you that

level of insulation. #e also generally advocate having a presentation view which

can be either model $uery sub5ects or shortcuts to model $uery sub5ects. %hat is"

again" 5ust a rule of thumb" in a scenario where the report developer isn't

necessarily the modeler.

If in a case where one person is doing both roles" then obviously you may be able to

dispense with the middle layer and 5ust have a series of model $uery sub5ects that

then point to the data source and you can publish those directly. %here is no real

technical reason or re$uirement to have that. It is 5ust in terms of organi4ation and

giving you a layer of abstraction" that gives you some insulation against change ,

that is typically why we recommend doing that.

(nother $uestion , why should I not change anything in the database $uery

sub5ects in my import layer. #hat if I need to do this/

#e generally recommend not changing anything in the database $uery sub5ects

because that" if it is simply a select star from table" which is the default when you

do a straight import" it is called the simple $uery sub5ect as far as a $uery engine is

concerned. !o it doesn't need any additional metadata. If you modify that the

$uery engine can sometimes re$uire additional metadata and it won't get it from

the model. !o you can encounter a scenario where it has to go to the data source

to fetch that information. %hat is what we call a metadata callback. In some cases

this is really not that big of a deal. !ome database vendors handle this very well

and it doesn't result in much of a problem. ut in some cases it does. !o there are


12/22

a series of techni$ues you can do to avoid this if you absolutely need to make

modi)cations at the data source level.

(nother reason we generally recommend not doing that is that (s @iew !& can be

triggered" we talked about that a little bit in the presentation. Putting )lters or

calculations in your data source $uery sub5ects can trigger (s @iew behavior. (nd

lastly these" as I mentioned earlier" these data source $uery sub5ects are really

global. %hey are the foundation upon which all of the higher level ob5ects in your

model are created. !o any change you make there is a global change. !o that is

why we generally recommend giving yourself a layer of abstraction and making

changes like that in your business view.

#e have another $uestion , what is the best practice for 5oining tables from

di6erent databases/ #ell" 5oining tables from di6erent databases is something we

support. -ou can have multiple data sources in your Framework Manager model.

%he caveat there really is that you are going to be 5oining that on the report server

in most cases. If you are talking about two di6erent schemas in the same database"

then there could be an opportunity to have the database take on some of that work.

ut if you are talking about let's say doing an import from > and another

database from 0racle or two di6erent 0racle databases" you are talking about

5oining that locally on the report servers. !o there is a performance consideration to

be considered there because you are going to crunching all of that data on the

server before you get your results set.

I have another $uestion , the fairly large model with many nested name spaces and

levels of organi4ation" how can I get an inventory or a list of all the ob5ects in my

model/ #e do have a feature in Framework Manager called the Model eport. It is

available from the tools menu" and what it will do is what you do is you select an

ob5ect or a level of organi4ation in your model" so a name space or you can select it

at the highest level of the pro5ect. (nd what it will do is it will run a report and give

it to you in either an JM or A%M" an inventory with all of the hierarchies" the

organi4ation of the model. !o all of the $uery sub5ects" the $uery items with their

data types and so on for every ob5ect in the pro5ect" if that is what you selected" oron the name space" if that is what you happened to select.

;ow" it is kind of in a" it may not be tailored directly to the format you are looking

for so we do have the option of specifying an J!% )le in the FM.I;I )le. !o if you

wanted a )ltered view or you wanted to control how that report looks you have an


13/22

option of writing an J!% )le and then referencing it in the FM.I;I )le and we will

generate the report in the format that you are looking for.

I have another $uestion , is it possible to copy a few ob5ects like $uery sub5ects"

source table 5oins from one model to another using Framework Manager/ If not" is

there a better way to do it/

-ou do have copy and paste functionality in Framework Manager so you should be

able to simply copy and paste ob5ects over. I would say the best way to do that

would be to do an import from another model. %hrough copying and pasting you

would have to recreate the data source in the new model" so you would have to

make sure that that was there and all of the re$uired ob5ects were there. %he

supported way to do that or the recommended way to do that would be to do a

metadata import and then select the original Framework Manager model as the

source to use when you are doing the import. (nd that should give you the ability

to select what it is you want to import from that model and it will look after taking

the necessary ob5ects for you.

;e*t $uestion" how do governors work when a $uery is going to return more than

the speci)ed limits if the $uery on the terminated/ -es" the way this should

work is you set the governors in Framework Manager and that is at the package

level. !o those governors are set at the package level. %here are di6erent

governors you can set" limit the number of rows and so on. #hat it will do is it will

start to prepare the $uery and e*ecute it and it should 5ust stop the $uery whenever

it reaches the limit that you set. I donHt think it has a way of knowing in advance

how many records it is going to return. !o it will start the $uery and then it should

5ust stop it whenever it gets close to the limit or whenever it reali4es that it is going

to e*ceed the limit.

(nother $uestion , is there a way to maintain versions to the packages like for

models/ %here is versioning for the packages that you publish" that is an option

when you are doing your publish. -ou can select how many versions you want tokeep on the server. %hat can be pretty useful if you are publishing out and you want

to make sure that you donHt break anything in the reports that are accessing the old

version. -ou simply keep a version or two on the server and then it gives you a little

bit of insurance that you are not going to break anything. Aaving said that" the ne*t

time you open one of those reports that access the old package it is going to try and

synch up with the new package" so that is something to keep in mind.


14/22

!o that is available. In terms of being able to sort of archive packages on the

server/ ;o" we donHt have anything right now that would let you say keep three

versions of the package on the server and then write a report and indicate which

version of that package you wanted to write. #hen you author a new report or youopen a report in the studio" it is always going to use the newest version of the

package that is available.

et me go through some more $uestions here. &uestion , #hat is the main use of

minimi4ed !&/ !o generally speaking we advise using minimi4ed !& because it

will reduce the number of columns that you need to return for any given $uery. !o

if you create a model $uery sub5ect and it is using a series of columns from let's say

a product line and product type" if you are only wanting to use one column from

there" using minimi4ed !& will let you 5ust $uery and return that one column. If

you have (s @iew behavior triggered it is going to treat that model $uery sub5ects

(s @iew. !o in other words it is going to retrieve all of those columns that are

included in the model $uery sub5ect even though you only were interested in the

one. !o it is , it is all in the interest of the economy" accessing the fewest number

of ob5ects because that typically will perform more $uickly.

(nother $uestion , is there an easy way to e*port portions of your model out and

then import this work into another model/ %his would be helpful if you want several

smaller models for your reporting instead of one huge model.

%here is a feature that is pretty similar to what the listener is referring to here. #e

do have the option of both merging and branching. !o you can create kind of a

master model and then branch o6 pieces of it into sub models. 3enerally speaking

that is used for trying to model in a multi1modeler environment so you are

designating di6erent people to work on di6erent portions of the model. (nd it gives

you a mechanism to merge those changes back in. ut there really isn't any reason

why you couldn't leverage that functionality 5ust to sort of segment your model into

smaller pieces. %here also is a linking in segmenting which is similar to the merge

and branch in the sense that you can segment out pieces of the model" but it

doesn't have the kind of merge back into the master. In the case of segmenting it is

actually sub1model" if you will. !o changes that are made to the original source are

automatically pushed out , so there is kind of a live link there" whereas in merge

and branch it is kind of a manual process to merge changes back in.


15/22

(nother $uestionKif there are more than one layer in the Framework Manager

model" what is the best practice to create a relationship at the top layer. If we have

a database view" intermediate view and business view , which layer is it preferred t

keep the relationship between the ob5ects/

(s I said" it is really" there is no one universal answer that will be right =L of the

time. ut generally speaking we recommend keeping the relationships" if possible"

at the database layer. For reasons I mentioned earlier" if you have them on model

$uery sub5ects you end up triggering (s @iew behavior and so on" so as I say it is

not =L all the time way to go" but generally speaking as a rule of thumb we

recommend people keep those relationships at the database layer.

Can an individual create items be secured so that some users see them and some

users donHt/

-es" you do have the ability to set ob5ect level security in Framework Manager so

you can assign permissions based on group's enrolls" using the security model that

we have in Cognos Connection. !o it is" if you select your $uery sub5ect" there is a

right click option to specify ob5ect security and that is the interface that you would

use to set that. -ou have access to the name space and you can say that members

of this group or members of this role" I think even down to the user level" can either

have access or not have access to those ob5ects.

(nother $uestion , how to automatically detect changes made on the data source

columns in FM/

!o I think the $uestion really is how do we detect if the underlying data source has

changed. #hat you would do is you would have to" I believe if you clicked the name

space or the database of your name space and did verify model" it should try and

test each one" do a $uick test on each one of those data source $uery sub5ects and

make sure that the pro5ection list still matches the underlying data source. !o you

would see" if there were changes to the data source you would see" either if it was

an additive change you would see an additional column appear in our data source

$uery sub5ect and if it was a case where the name of the column in your table in the

database changed" you would see a broken icon because it wouldn't be able to

resolve that.


16/22

!o" you could do it on a $uery sub5ect by $uery sub5ect level as well because you

5ust verify and it would tell you whether it was still valid or not. ecause the data

source $uery sub5ect is generally speaking a select DstarE from cable" that is how it

5ust returns all of the rows , or e*cuse me , all of the columns.

!imilar functionality for model $uery sub5ects. If you change something in the

$uery item in your data source $uery sub5ect" you can verify model ship" pick that

up as well" or you could do it on a case by case basis by verify $uery sub5ect.

&uestion , does creating a $uery sub5ect using your own !& have any e6ect on the

performance/ #hen you are creating a data source $uery sub5ect you hand type in

the !& , by default when you do your import it will be select star from table. -oucan modify that. -ou have a couple of options here. -ou can do native !& or you

can enforce what we call Pass through !&. Pass through !& is typically used in

cases where there is a speci)c database vendor" speci)c functionality that you want

to leverage and our $uery engine may not be able to resolve it. !o you want to

basically pass it through to the data source without us touching it. !o there are

ways to do that. I think it is double curly braces around the synta* in the $uery

sub5ect de)nition.

It is de)nitely outlined in the , I think it is in the Framework Manager 8ser's 3uide. Iwas 5ust looking at it the other day. !o I think it is the curly braces" double curly

braces on either side of the !& statement. ut de)nitely it is covered in the

Framework Manager 8ser's 3uide" so you can get the synta* from there.

&uestion , when should we consider using M versus a cube/

3ood $uestion. eally a cube is really a static set of data at a moment in time. !o

you build your cube and because it is already pre1built the records are already

there" the aggregation is already done. For reporting purposes generally speaking

are going to be very fast. Aaving said that" because it is static" if you have a

re$uirement to get sort of updated results on a regular basis it may not be the best

approach for you because it does re$uire the maintenance of rebuilding the cube

periodically. !o if it was a case where you needed records" data that is up to date as

of today" that might mean building your cube every day. !o that could be an


17/22

additional maintenance task that you didn't want to take on. In terms of M"

because we are sort of spinning the cube in memory and then $uerying that cube"

the performance is going to be slower than a cube but it is actually accessing the

data warehouse or the data source sort of as you are running it. !o the results that

you are getting" your reports will be as up to date as the reporting data sources are.

!o generally speaking that is one of the main bene)ts of using M or a cube.

%he other thing is" with a cube you are talking about a static )le that is sitting on

the server. !o there are some" depending on the platform you are on there are

some limitations around that f you get into cubes that need to be over > 3igs letHs

say" that could be an issue. !o M has the advantage there as well. %here really

isn't any , you can hit larger data sets than a cube you are not limited to 5ust

having a cube.

0f course" with the performance issue I mentioned earlier with M" we spinning a

cube in memory as you are running your reports. %he larger the data set" generally

speaking you are going to see the reports" the processing time get longer as well.

!o not to say that M has sort of an in)nite limit here.

0kay" how to e*port the metadata such as screen tips for selected name space/

-ou do have the ability to do an e*port of the string properties for $uery items. !o

in other words the names" the screen tips" all of the string type properties that you

would have for di6erent $uery items. eally the way that functionality was

implemented was to ensure that people who want to use multi1lingual models have

the ability to basically e*port those strings so that they can work with them in an

easier interface than having to type in the multi1lingual strings by scrolling across in

that window. !o you can e*port that to I believe it is C!@ that you can open in

+*cel" so you would an +*cel spreadsheet and then you could add in the other

names that you want there. !o you could leverage that ability to get an +*cel

spreadsheet with all of the names and screen tips and descriptions of your $uery

items.

I think that that is de)nitely under one of the menu items so if you select name

space and then went to , I bet it is under tools or actions , you would be able to

e*port that to +*cel.


18/22

#hat information does Model (dvisor display beyond the current messages thrown

out when a Framework Manager model is saved/

#ell" Model (dvisor is going to" depending on the con)guration that you have" you

can con)gure it to look for speci)c things or ignore speci)c things. !o what Model

(dvisor will do is it will apply our best practices rules for things like relationships"

cardinality" usage" things like that. !o if you don't want to see all of that you can

pick speci)c topics that you are interested in and then it will e*port those messages

accordingly. It gives it in a really nice kind of organi4ation because it gives you

diagrams and you can launch out to help directly from there. !o" when you are

doing a save it is going to try and verify the model and 5ust make sure that it is a

valid Framework Manager model" you have a data source connection" things like

that. #hen you are doing Model (dvisor it is actually doing a much more analytical

pass through the model in identifying potential problems.

!omething I mentioned in the slides was not all of these issues have to be

addressed. %hese are 5ust areas that are worth a second look. !o when it alerts you

about something it is a good idea to go and have a look and 5ust make sure that it is

in deed what you intended to do there.

;e*t $uestion , what is the best practice when an upgrade of the model is neededand customer reports need to be updated/

#ell there are really two pieces to that. 3enerally speaking our upgrade work


19/22

should publish it out again. ike any upgrade" you should really do this in a

development environment and then when you are satis)ed that things have

upgraded correctly and they are all at the most recent version then you move it

over to your &( or your 8(% environment and then from there to production.

;e*t $uestion , is there versioning capability in Framework Manager/

%here is in B. and previous versions there is native support for source control. #e

have support for D@isual !ource !afeE and DC@!E in B. and all previous versions of

Framework Manager. Aaving said that" we did issue a deprecation notice in B.

about our native support for those source control systems. !o as of the ne*t ma5or

release of Framework Manager we won't have native support for those source

control vendors.

#e do" however" have a proven practices document" it is on our proven practices

site and it describes how you would leverage any e*isting source control system.

!o whatever you happen to be using" a Microsoft tool or whatever" they should all

work e$ually well using this approach. It identi)es what )les you would need to

check in and check out and how you would do that.

!o as I say" as of the ne*t ma5or release we won't have the native source controlsupport" but we do have a proven practices document. It is available on the website

that you can use as kind of a guideline for integrating with whatever source control

system you are using.

Can you give a brief discussion on settings and governors/

3overnors really" as I mentioned earlier" are set on a package level so they are set

there to sort of give hints to the $uery engine on how to react in certain situations.It is a good idea for a modeler if you are talking about a massive data set" it would

be a good idea to set a $uery governor to limit the number of rows returned. -ou

wouldn't want someone in $uery studio let's say to be able to drag $uery items onto

the canvas and e*ecute a $uery that might return 9 million rows or 9 billion rows

even. !o it is a good practice to set kind of realistic limits. !ome common limits

that I see are limit it to say 9" rows or = million rows at the ma*imum $uery

times is another one. -ou can set the $uery duration so that if a $uery is going to


20/22

run longer than ten minutes" stop. 3enerally speaking those two settings go hand

in hand. If you are going to be returning more than a million rows it is likely going

to take more than = minutes. !o you probably don't want someone doing that. !o

it is a good idea to set $uery governors like that in Framework Manager 5ust to make

your system administrator happy so that he doesn't see a real hit on the server.

Aow can we set drill ups and drill downs/

#ell" in terms of modeling you are talking about analysis now. !o what you are

talking about there would be dimensionally modeled relational source. !o what you

would do is you would do your regular modeling because the foundation of any

dimensionally modeled model is a good relational model. !o the same best

practices would apply. !o do your import" create your model $uery sub5ects"

organi4e your star schema and then in your dimension $uery sub5ects organi4e

levels. 0nce you have your star schema created directly" we do have a nice

automatic way of converting those to regular dimensions. It is from the right click

menu you can select I think" if you 5ust organi4e them in the name space you can

right click the name space and it will convert the dimension $uery sub5ects into

regular dimensions and the fact $uery sub5ect into a measured dimension.

From there you will have to do" you may have to do a little more work making sure

that we got the levels correct. ut with a little bit of tweaking you should be in a

pretty good position to publish out and then your users would be able to do drill ups

and drill downs in a tool like &uery !tudio or (nalysis !tudio.

!o the drill upGdrill down functionality comes for free in the studios once you have

got a dimensionally modeled model.

%here are a couple of $uestions about this presentation and whether or not it is

going to be available. My understanding is there is going to be a thank you email

sent out ne*t week and it should have a link to this presentation so that you can

refer to it. If anyone would like to have a set of the slides" I would be glad to send

that as well. I would have to send it in PF so I don't the movies would comes

across" but as far as the content is concerned" if anyone is interested in getting a

PF copy of the presentation" I would be glad to send that as well. !o you can 5ust

reach out to me directly.


21/22

0ne more $uestion , I have a rather large model and I )nd it takes longer to publish.

#hat is Framework Manager doing that causes this delay/

#hat we are doing when you do a publish is we are going to analy4e the entire

model and make sure that we include all of the ob5ects that you need. !o you can

imagine when you are creating a package and let's say you have your database

view and you have your business view and you have your presentation view" when

you create your package you select your presentation" your name space , it has

let's say ? or $uery sub5ects" that's all you want" or short cuts rather" and that

is what you want to publish at the studios.

!o what we are going to do is make sure that we also include the underlying model$uery sub5ects and the necessary database $uery sub5ects. !o you are not going to

want the report authors to see them and we are not going to show them to them"

but of course the $uery engine needs them in order to generate the $ueries. !o we

need to scan through the model and )gure out what the dependencies are. !o this

shortcut points to this model $uery sub5ect" points to this data source $uery sub5ect.

(nd we will sort of scan through that and unwind the model and )gure out what

ob5ects are needed and we will include them but keep them hidden.

!o the larger the model the more time and resources it takes to scan through themodel to )gure that out. !o you will see if you have a very large model in the > to

? megabyte range you may see publish take several minutes whereas if you are

using a small model" publish could happen. -ou could do a publish in a few seconds.

I think we are going to stop there. %here are a few more $uestions but some of

them are really of the type that I think kind of a back and forth dialogue would be in

order. !o I know there are some $uestions here that I didn't get to and I apologi4e

for that" we are running out of time. !o what I would like to do is 5ust invite anyone

who has a $uestion that we didn't cover" please do send me an email and I would beglad to follow up with you oine and we can hopefully address your $uestion.

!o I would 5ust like to thank everyone for 5oining. I en5oyed answering these

$uestions and hopefully you all found the session worthwhile. (nd as I said" please

do drop me a note by email if there are any $uestions that I did not cover today.


22/22

wa_tti_modeling_proven_practices_for_ibm_cognos_framework_manager.doc

Documents