![]() 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. If you've never done this before, it may be difficult to see why you want to do it this way. 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 need to make business-oriented changes to say filters, calculations, or names, you have one place to do it (the query layer). 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. Semantic Layers The purpose of a semantic layer is to create a business representation of corporate data. * The presentation and DMR layers are what you organize into packages. Again, you might have more than one for complex enterprise-wide data warehouses, for example. * A DMR layer is kind of like a specialized presentation layer with a dimensional view. You might even have more than one presentation layer, with a different focus in each. These business information rules can be as simple as renaming the columns in the imported tables to give them more intuitive names, or setting specific formatting for the imported. * 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. The Framework Manager modeler can make the job of the report author easier by incorporating business information rules into the model. The query layer is where you are translating from database-oriented queries to business-oriented query subjects. * The query layer selects from the database layer, and provides the opportunity to rename to business terms, filters, security, etc. * The database layer is used as a way to link back to the actual database structures. is there a way to configure it so that the tabs are name by the product members instead Are you on version 10.2.2 If so you can try this. each tab is automatically named page 1 and page 2. Using multiple layers like this provides abstraction and insulation from changes to the underlying data. when drag 2 products into page layers and run the report in excel, each product is put in a separate tab. 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. Disparate data sources hinder connectivity and components built on a security framework that requires duplication across different layers increases. We do things very similar to RobsWalker68.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |