Framework Package Question

[UcfMike]

I have a Framework Project with a Data Source view and then multiple business views and packages based off those business views. If I change a relationship in the data source view, do I have to republish the packages for the changes to be recognized in Report Studio?

 

[almeids]

Yes, I believe so.

 

[blom0344]

You have probably noticed that the SQL for database objects reads like :

Select * from [connection]..object

For a changed database view definition it is doubtful that the complete view definition would be stored in the framework xml.
My guess is that the changes should be apparent without republishing the package..

Ties Blom

 

[UcfMike]

But does the xml store the path definitions for the business view model query subjects. If it stores those explicitly, then maybe republishing in necessary.

I'm always impressed with you insight Blom.

Thanks,

Michael

 

[blom0344]

Yes, the definition of model query subjects is stored in the XML. However, the definition of a databaseview is stored in the source database. In my perception Cognos will read a databaseview very much like it will read a database table.

Ties Blom

 

[almeids]

Sorry if I misunderstood, your question didn't sound like it was about database views to me. I thought you were referring to relationships between query subjects in the data source/physical layer of your project.
But...my answer would have been the same. I don't use views, but if you add columns to a table, you need to update any "select *" query subjects and republish packages, so why would it be any different with database views?

 

[blom0344]

The difference is in the structure of the view. If additional columns are added, then you will need to update, but if the columns stay the same and the underlying view-SQL is changed, then I guess that should not matter to Cognos.

Ties Blom

 

[almeids]

Agreed.
But I'm still not sure that UcfMike was talking about database views at all!

 

[blom0344]

'Data source view' reads to me like a database view imported into the framework?

Ties Blom

 

[UcfMike]

My data source view is my database view.

I've imported every table from the database into FM. I've placed the tables into a folder. I then created a Datasource View namespace, which I'm populating with tables from the tables in the folder. I create my relationships for the data source view from those.

I then create Business Views from the Datasource View.

Since I'm building the data source view piece by piece, I want to make sure I don't have to republish my packages which are based off the Business Views.

I'm afraid that maybe confusing.

 

[almeids]

UcfMike - When Ties refers to a database view, he is talking about a view created in the database itself with a "CREATE VIEW" sql statement, which doesn't necessarily have anything to do with Cognos. He is correct that a change in the definition of the view does not require republication as long as the columns of the view do not change.
Ties - Michael is, I believe, referring to a database layer/namespace in his project, as opposed to the Business layer/namespace where things are made pretty for the users. If he changes relationships there he will need to republish any affected packages since ReportNet only reads the published package metadata at runtime, not the FM project metadata.

 

[UcfMike]

I think that answers my question almeids, I apologize for the confusion in my lingo.

I am referring to a database namespace and then a business view name space.

That is somewhat frustrating, and somewhat makes me wonder if what is taught in the Cognos FM class is truly the best solution.

 

[almeids]

Folks who really get into modelling swear by FM and from everything I've read the 2-layer approach seems to be pretty standard. It could be worse - Cognos used to have 3 layers in their Architect product!
But don't feel like you have to follow Cognos' approach to the letter, tailor it to your environment. We don't have a business layer, for example, since our user community doesn't write their own reports or use QS. This depends on how understandable your table and column names are of course. We also don't knock ourselves out with cardinality (pause for collective gasp from the serious modelling community) - pretty much everything we model is 1:1 and the sql that comes out is fine. Since we run the back end too and tend to build tables to the app rather than the other way around things stay pretty clean and simple in FM.

 

[blom0344]

I'll second Almeids on his last post. In real life the official Cognos approach seems to work best with the ideally modelled database demo that they pack with the product. However in many cases 2-layers are more than enough.
However if you need to take into account that multi-fact,multigrain queries should be taken care of, then it will only work with the 'official' strategy.
The real weak spot seems to be the determinants. You should really stay away from using these if your model excludes multi-fact queries. They do more harm than good is my experience..

Ties Blom

 

[UcfMike]

We're working with a relational system, and we've stayed away from dimensions and determinants. Since the database is full of many to many relationships, left outer joins, and possible loops, we're essentially using our Business Views to control the "flow" of the sql. Similar to the way you would controld the flow of the sql in Impromptu with aliases. So far the system is working well, though there are often hoops to jump through in Cognos, but I'm not sure why they exist.

Thanks for everyones help with this post.