.You can analyze the metadata in a model by using the Model Advisor, which is an automated tool that applies rules based on current modeling guidelines and identifies areas of the model that you need to examine. To assist you in understanding the nature of the highlighted issue as well as some possible actions, you are provided with links to the appropriate sections of the documentation. The Model Advisor is not a replacement for a knowledgeable modeler; it provides new modelers with an assistive tool and more experienced modelers with a diagnostic tool.
You can select one or more tests to run against the selected
model or subset of a model. We recommend that you verify the model
and fix errors before analyzing the model .
If you are analyzing a new model, we recommend the following workflow:
Analyze newly-imported objects, especially their relationships and determinants.
Use the issues that are identified to resolve potential query generation issues.
As you build additional views, use the Model Advisor to analyze each one for potential issues.
Before publishing the model, use the Model Advisor on objects that will be published.
If you are analyzing an older, established model or a model that is not yet complete, use the Model Advisor to validate modeling practices. The workflow is similar to that used for new models: start at the database view and work up.
This test looks for query subjects that have only the many (n) cardinality on the ends of the relationship in which they are involved. Query subjects with this cardinality are treated as facts when generating queries so it is important to ensure that they are correctly identified.
This test looks for query subjects that have a combination of the many (n) and one or zero (1,0) cardinality. Mixed cardinality means that the behavior of a query subject can change depending on the other query subjects used in a query. This can lead to unpredictable queries in some cases. If the query subject is evaluated as a fact, it will be included in the query path. If it is evaluated as a dimension, it may be skipped if it is not directly referenced in the query. In the interests of ensuring predictable behavior, it is recommended. that you resolve these scenarios.
Mixed cardinality can indicate a query subject that is part of a snowflaked dimension or master-detail relationship. In the case of intermediate tables in snowflaked dimensions, there is no issue to resolve. Problems may arise in situations where there are multiple query paths available; these cases should be highlighted by the test for query subjects with multiple relationships.
This test looks for query subjects that have either many relationships between two objects or a loop join that does not represent the star schema join pattern.
Multiple relationships between two query subjects is often associated with role-playing dimensions. With role-playing dimensions, you create aliases that enable each role to have a different join and different independent behavior. Multiple join paths that are indicative of loop joins (except for star schemas) may lead to problems of incorrectly split queries. This impacts the predictability of query generation for your users.
If Cognos 8 has multiple relationships with no distinguishing criteria to choose from, it uses the relationship that comes first alphabetically. If you need to create a query that uses a different relationship, you always have a problem. As well, if you want to use filters on criteria that are specific to the role defined by the relationships and those filters are mutually exclusive, then no data is shown in the report. For information about role-playing dimensions and an example, see Role-Playing Dimensions.
Note: When cardinality clearly identifies facts and dimensions, Cognos 8 can automatically resolve loop joins that are caused by star schema data when you have multiple fact tables joined to a common set of dimension tables. The Model Advisor ignores star schema join patterns because they do not qualify as problematic joins.
This test looks for reflexive and recursive relationships. These relationships imply two or more levels of granularity. Framework Manager imports reflexive relationships but does not use them when executing queries. Reflexive relationships, also called self-joins, are shown in the model for the purpose of representation only.
Most often a query subject that joins to itself indicates a parent-child relationship. Data sets that have parent-child relationships can be of definite or indefinite depth. The only way to know which you are dealing with is to understand the data and the business concept represented.
Whether you have a problem when you encounter a parent-child relationship depends on how you intend to use the data in your application. There may be cases where only one level of the relationship is necessary, and this is a fairly simple scenario to model. If you know the data to be fully populated for each level and to have a definite number of levels, you can also choose a modeling-only solution. However, for cases where there is a significant amount of data, the data is not fully populated at each level (ragged or unbalanced hierarchy) or the number of levels in the data could change over time or both, it is recommended that you transform the data to a flat structure with a fixed number of columns before modeling in Framework Manager.
This test looks for determinants that conflict with the relationship defined for the query subject. Determinants are used to ensure that the aggregation in reports is correct and that queries generate correctly.
Determinants reflect granularity by representing subsets or groups of data in a query subject and are used to ensure correct aggregation of this repeated data. Determinants are most closely related to the concept of keys and indexes in the data source and are imported based on unique key and index information in the data source. We recommend that you always review the determinants that are imported and, if necessary, modify them or create additional ones. By modifying determinants, you can override the index and key information in your data source, replacing it with information that is better aligned with your reporting and analysis needs. By adding determinants, you can represent groups of repeated data that are relevant for your application.
The Model Advisor checks query subjects with determinants and flags the ones that meet one of the following criteria:
the relationship references all query items in the determinant and the determinant uniquely identifies a row but the cardinality of the relationship is not 1:1 or 0:1
the relationship does not reference all query items in the determinant and the determinant uniquely identifies a row but the cardinality of the relationship is not 1:n or 0:n
This test looks for various factors that override the SQL Generation type setting of Minimized, such as modified data source query subjects, relationships between model query subjects, or determinants for model query subjects.
When you use minimized SQL, the generated SQL contains only the minimal set of tables and joins needed to obtain values for the selected query items.
To see an example of what minimized SQL means, here are four query subjects, Product Line, Product Type, Product, and Product Multilingual that join to each other.
They can be combined in a model query subject.
For example, if you test the Products (model) query subject as a whole, you see that four tables are referenced in the from clause of the query.
If you test only Product Name, you see that the resulting query uses only Product Multilingual, which is the table that was required. This is the effect of minimized SQL.
This test detects where you have set the Regular Aggregate property to calculated for a measure in a measure dimension. The calculated aggregation type is only supported for stand-alone calculations at this time and does not yield expected results if it is embedded in a measure dimension.
This test looks for factors that override cached metadata, such as data source query subjects whose SQL has been modified or query subjects that contain calculations or filters.
Framework Manager stores the metadata that is imported from the data source. However depending on the governor settings and certain actions you take in the model, this metadata might not be used when preparing a query. If you select the Allow enhanced model portability at run time governor, Framework Manager always queries the data source for information about the metadata before preparing a query. If you have not selected the Allow enhanced model portability at run time governor, Framework Manager accesses the metadata that has been stored in the model instead of querying the data source. There are exceptions and the main cases are:
Any modification of the SQL in a data source query subject. This includes the use of macros.
Adding a calculation or filter to a data source query subject.
Note: The metadata queries generated by Cognos 8 are well supported by most relational database management system vendors and should not have a noticeable impact on most reporting applications.
The Model Advisor is only intended for use with relationally-based metadata models. We do not recommend running the Model Advisor against an entire model; instead apply it to specific views one at a time to ensure that the feedback is being taken in context. For example, if an issue in an import view has not been addressed, the issue might be resolved by modeling that is done in an intermediate view.
For large models or namespaces, the Model Advisor might not return results immediately.
Because the Model Advisor is not data sensitive, you must know the data and model the metadata appropriately for your business intelligence needs. Not all items flagged by the Model Advisor are indicative of a problem. The context of each issue raised by the Model Advisor is important.
Click one or more objects to analyze.
Select query subjects, dimensions, hierarchies, calculation, query items, or shortcuts to analyze objects that will appear on a specific report to test the report before it is created.
Select a folder or namespace to analyze all its objects. If an object references an object in another folder or namespace, the referenced object is also analyzed.
Select a package before publishing it to ensure it follows the recommended guidelines for modeling.
From the Tools menu, click Run Model Advisor.
Tip: You can also right-click one or more objects and then click Run Model Advisor.
In the Options tab, select the criteria that you want to use in the analysis.
Click Analyze.
In the Model Advisor tab, review the issues that are identified.
There is a description of each issue, a link to more information about each issue, and a list of objects that are impacted by the issue.
To understand whether there is a problem with an object,
click the context explorer button 
in the Action column
of the report.
The Context Explorer shows the objects that the selected object is connected to. You can selected a related object and see which objects it is connected to.
