As a general guide try to keep the database layer as close to the design of the underlying database as possible this is why it is called the ‘Database Layer’ ) Joins, cardinality and determinants should be set at the database level but other than these no further modelling work should be done at the database layer. The same applies to filters and calculations avoid adding these to database layer query subjects. Always try to use unmodified SQL for query definitions in this layer as modifying the SQL disables framework meta-data caching capabilities forcing Cognos to validate the query subject at run time which reduces the efficiency of the end report. The database layer contains data source query subjects based directly on the objects found in the underlying database. Packages, data source connections and parameter maps fall outside of the modelling layers. The layers build upon one another, with the database layer being the foundation of the model. Each layer has a distinct function and set of activities. This will help ensure the model you create is durable.įramework Model development should use four specific layers (Database, Modelling, Presentation and Dimensional). With the design and active languages set you should set the project property ‘Use design language for Reference ID’ to true. You should ensure throughout the design of your model that the design language is never used as the active language by default Framework manager sets the design language to the active language and therefore this must be changed before proceeding.
It is suggested that ‘English (Zimbabwe)’ is used as the design language for Framework models unless this language is required elsewhere within the model. A design language should be a language which is not required within your environment. To achieve this in either a single of multi-language model it is important that at the very start of the modelling process you decide and set a design language. When designing a framework model you want to be sure the model you develop will withstand future changes and development without impacting existing reports which have been built upon it or requiring changes to defined calculations and filters. It describes the IBM recommended four layer approach, detailing the purpose and reason for each of the four layers and then moves on to discuss the use of data sources and avoidance of stitch queries. For this blog I am going to focus on the best practices, organisation and overall methodology of Framework model development.
0 kommentar(er)
