updating FM objects

[ry1633]

This might be a simple question, it's just something I wanted to verify.   When I update my FM objects (selecting object,  then under Tools --> Update Object), will I lose an formatting or updates that I had in place.   As in column re-names, concatenations, calculations and the like?    Just wondering, since a user pointed out to me that a view had changed radically - but it might also be that my DBA had also changed the structure of the view object at the db level also. :)

[bdbits]

I do not believe you will lose existing modifications, although a data type change or a column rename are probably going to have some affect.

That said, I would recommend you use a layered approach - a database layer, a business layer referencing the database layer, and a presentation layer for the user. The database layer should be all "select *" queries. The business layer is where you do renames, concatenations, calculations, etc. And the presentation layer is mostly just shortcuts to business layer objects.

If you do it this way, a change to the database might not effect your upper layers at all. Obviously this somewhat depends on the nature of the change, but one of the goals of using layers is to minimize the immediate impact of underlying changes. When something does change in the database layer, you may only need to take a look at the dependent business layer queries. And if a column changes, you can pull the new column into the business layer and maintain the same name and perhaps even data type using an expression. It's comparable to using views in a database to mask underlying changes to physical database structures.

[ry1633]

Conversely is there a way to clear any column adjustments (mostly like upper-lowercase spellings, etc) that I've made, and revert back to how a layout how the columns might have been at the view level itself my dba would have written the view originally?

[bdbits]

You can drop/re-add individual items, or create a new query subject and compare.

[ry1633]

For this project I'm working on, I've tried the layered approach and I'm not sure I like it.  Either that or I'm doing it wrong. :)     For this project we're using all data views and no single tables.  So in the Database Layer I brought in all the views and left them as is, with no relationships drawn and no renames.   In the Business Layer, I started to create new Query Subjects named as my business folks wanted them to,  based on fields in the db layer and started to add in the relationships, renames, concats, and business requirements.

But what I found is that whenever I went to update any/all of the objects in the db layer - I'd then have to do the same update in the business layer.  And if they were any significant changes to the views in the db layer, updatijng would either cause errors in business layer or would outright blow away any changes I had in business altogether.    So I found myself having to do 2 complete sets of updates on basically the same or similar objects in two different layers and I found that frustrating. 

[bdbits]

The relationships should actually be in the database layer. Having a database layer at all, and where you put relationships, can affect performance in both the database and Cognos. I'd recommend perusing chapters 9 and 10 of the FM user guide for details on why. There is also a lot of good info in chapter 8.

Unless you are drastically changing your views (renaming existing columns, changing data types, etc.) it should be hardly any work to propagate a change. In the database layer, select the view(s) then menu item Update Object (assuming select * here). Then go to the dependent query subjects and pull in new items, or update existing items if necessary. (Note that if FM does "lose" a link to the data source query, you can remap it and do not have to rebuild the model query subject from scratch.) At this point you should be able to publish - you're done.

If you are having large-scale changes all the time, I would have to wonder why. Particularly for the business layer, I would think your model should stabilize for existing items over time unless there are substantial changes in the business itself. In fact, one reason for having a database and business layer is to minimize the impact of database changes to the user view.

[bdbits]

(There was no reason to send me a personal message about this.)

Further question about modeling in layers.   Do I create each layer as it's own namespace?

I've been working on a 3 layer model for this project -started one anyway.   I created 3 layers - Database, Business Logic, and Presentation.  For my project I don't think I'll need a dimensional layer.  I created all three layers as new Namespaces and this is how I have them set up right now:

1.  Database Layer - all views that my DBA made. They are all Select * objects.  And I set up the relationships with cardinality

2. Business Logic layer - created new Query Subjects based on business requests for how they wanted the objects named etc - and pulled the contents to fill the from the DB layer.  Have started to add some business logic from my customer's requirements, but haven't finished yet.   Field re-names, concatenations, etc.

3. Presentation Layer - haven't worked a lot in this.   Just have basically made a few shortcuts or alias to the finished objects that I've made in the Business layer

Object names are scoped to the namespace in which they occur and must be unique. So you want separate namespaces to avoid name collisions, e.g. if your dba decides to name a column the same as something you created in your business layer query subjects.

Looks like you are going about things properly.