Вы находитесь на странице: 1из 2

IBM Cognos Framework Manager model database layer

The physical, or database, layer contains a database query subject for every table
in the physical data model.
The database layer also contains alias shortcuts, which behave as if they were a
copy of the original object with completely
independent behavior.

>>The alias shortcuts are provided for two situations:

>To eliminate ambiguity for an entity that may be involved in multiple
relationships, including the following items:
location and location (resource)
>material_type and material_type (profile_variable)
>resource_type and resource_type (profile_variable)
>production_batch and production_batch (related)

**** your relationship joins in the database layer

>>To enable you to query multiple copies of the same table in different roles,
including the group_dim_1 to 5 values

If a database entity includes the language_id or tenant_id attributes,

the database query subject includes a parameterized filter for each that selects
only one tenant or language.
Language is based on the used locale settings. Localization is implemented for the
FM model as well. Users can select the language of their choice from the Active
Language drop down menu and change the model language.
The database layer contains all of the entity relationships. The central entities
are largely modeled in star or snowflake schemas,
shown in the following diagrams. These parameters must be set after master data has
been loaded or reloaded
and before publishing the package.
If these parameters are not set correctly, no data will be returned in the reports.

To change the values, simply open the parameter map, double click on the value for
each parameter and type over it.

A parameter map for language supports the localization of report data.

Language codes for English (EN), Simplified Chinese (SC), Traditional Chinese (TC),
French (FR),
Japanese (JP), and Portuguese (Brazil)(PT) are configured in the parameter map.
Typically the central fact has cardinality 1,N and related objects are 1,1,
in order to eliminate the need for relationships outside of the database layer.
All joins are modeled as inner joins on the understanding that the data integration
populates a default value for all references in the absence of a valid value.

1) DB Layer: Only import the tables, NO relationships between the tables are
defined.No joins, just show us the tables that

Two layer Approach:

Level 1 (Administration/ Database)

All tables, views, stored procedures and relationships between

them are located here. In addition, determinants are defined at
this level. We use the object names just as they appear in the
database. We have also created some special query subjects here
that apply sequence numbers to our date table. This allows us
to create rolling date filters in the presentation layer.

Level 2 (Presentation/ Reporting Layer)

Here we create shortcuts back to the objects in Level 1 and group

the objects into logical groupings based on the way that the
report writers (in our case business users) think about them.
All references in this layer are shortcuts back to level 1.
This is critical because any name changes/ namespace changes
here will cause reports to go invalid in the Studios.

We handle the Star Schema arrangement in the database because we

want the database to be doing most all of the work. In fact, we
have local processing turned off in our governors setting
because the performance is so bad when Cognos does it.