how many types of layer in framework manager while creating model

[inu]

Hi

I saw one video for creating relational model, where they created one database layer, and one presentation layer, is it necessary to create database layer and presentation layer.
   After that they hid the database layer while creating package, if they had to hide the database layer, then why created it, can you please justify it.
In addition to this, what more layers i can create for creating model. pls describe bro.
how many layers in model??????

Kind Regards
Inam

[RobsWalker68]

Hi Inam,

There is no hard and fast rule on this, although this is the structure I tend to use more often.

I personally have a database layer,  This is just an import of the database tables as is and this layer I leave totally alone.  As I generally only develop with Star Schemas (Facts joined to Dimensions) I don't place joins in this layer or determinants.  Others I'm sure will quite correctly place joins in this layer, especially if they want minimised SQL.

The next layer is the business layer and is an abstraction of the data layer.  I create query subjects based on the database tables, change the column names to something more meaningful for the business and add my joins/determinants here

Lastly, I add a presentation layer that is based on short cuts to the business layer and is what the report writer will see in the package.

If I'm planning to use dimensions through DMR then I will add a dimensional layer, although I rarely do.

Regards


Rob

[bdbits]

We do things very similar to RobsWalker68. This is pretty close to what Cognos recommends - database layer (where joins often are), query layer (sometimes have joins here), one or more presentation layers with shortcuts to query subjects in the query layer, and one or more DMR layers if needed. Using multiple layers like this provides abstraction and insulation from changes to the underlying data.

* The database layer is used as a way to link back to the actual database structures.
* The query layer selects from the database layer, and provides the opportunity to rename to business terms, filters, security, etc. The query layer is where you are translating from database-oriented queries to business-oriented query subjects.
* The presentation layer will be how the user actually sees and uses the query subjects, and gives you the opportunity to arrange things is a user-friendly way. You might even have more than one presentation layer, with a different focus in each.
* A DMR layer is kind of like a specialized presentation layer with a dimensional view. Again, you might have more than one for complex enterprise-wide data warehouses, for example.
* The presentation and DMR layers are what you organize into packages.

Now if something changes at a lower layer, you can adjust your model without impacting user reports, which rely on what was delivered to them via the presentation layers. If you need to make business-oriented changes to say filters, calculations, or names, you have one place to do it (the query layer). And if there are database-level changes, you can adjust them in the database layer and potentially need no other changes in the other layers.

If you've never done this before, it may be difficult to see why you want to do it this way. I think it is safe to say that after you have deployed one and had some maintenance against it, you will see the value in it.

[Francis aka khayman]

they covered the more technical part. i'll limit my answers to the most simple and basic.

how many layers in model??????
-- 3 layers is usually ok.

then why created it, can you please justify it
-- imagine you have 100 sales reports. for some reason the sales column in your table changed. if you have layers, you will need to edit 1 or 2 layers to fix the problem and no need to edit the reports.

1 layer will mean you need to change that layer and probably also change the 100 sales reports you already have.