Using the Model Advisor

While creating your framework model, the Model Advisor can be used to verify whether your model follows the current best practice in modeling and also helps to identify those areas of the model that you need to examine and change.

The Model Advisor is not a replacement for an experienced modeler and it should be seen only as a diagnostic tool to assist and improve the model design.

You can run the Model Advisor against the whole model or a subset of the model, and you may also choose which tests should be run against your model.

TIP

Before using the Model Advisor you should verify the model and fix any errors.

If you are analyzing a newly created model, consider the following points:

• Analyze any newly imported objects, especially their relationships and determinants
• As you import additional database objects and add new relationships and determinants to your model, use the Model Advisor to analyze each change for potential issues
• Before you publish your model for the first time, use the Model Advisor to check all the objects that will be included in your package

If you are analyzing an existing model or a new model that is not yet complete, use the Model Advisor as a tool to validate your modeling practices.

TIP

Model Advisor is intended for use only with relationally based metadata models.

Do not run the Model Advisor against your entire model especially if your model is very large; instead apply it to specific views one at a time.

How to use the Model Advisor

The Model Advisor is simple to use with the following steps:

1. Select the object to analyze within the model—this would usually be one of the namespaces within the model or a folder within the model.
2. From the Menu bar, select Tools | Run Model Advisor.

3. TIP

4. You can also right-click on one or more objects and then select Run Model Advisorfrom the pop-up menu.
5. If you selected a namespace and the selected namespace contains additional namespaces or folders, you will see a warning. Click on the Yes button to continue.
6. In the Options tab, select the items to analyse (an overview of the main options follows this section):

7. TIP

8. It is usually better to leave all options selected until you are more familiar with the analysis results.
9. 
10. Click on the Analyze button at the lower right corner of screen to start the analysis.
11. When the analysis has been completed, the results will be shown in the Model Advisor tab as follows:
12. 

You should review the analysis results carefully since not all items flagged by the Model Advisor indicate a serious problem. Some items may be ignored since they are only warnings about potential problems, while others require fixing so that they do not cause any problems during reporting. The context of any issue flagged by the Model Advisor is important as it helps in determining if the issue indicated needs to be fixed or can be safely ignored.

FACTS IDENTIFIED BY CARDINALITY

This test looks for query subjects that only have the many (n) cardinality at the end of any relationship in which they are involved. Query subjects with this cardinality will be treated as facts when generating queries, so it is important to ensure that they are correctly identified.

These types of errors may be safely ignored. Sometimes it is necessary to resolve these errors and this can be achieved by setting the cardinality to one (1) instead of many. The only time this needs to be done, however, is when the query subject contains numeric items that have been identified as facts, since they will automatically be included into aggregate functions when used for reporting.

Query subjects that can behave as facts or dimensions

This test looks for query subjects that have many (n) cardinality in relationships to some query subjects and zero or one (0,1) cardinality in relationships to other query subjects. This mixed cardinality means that the query subject can act as both a fact and a dimension depending on other query subjects in the query being generated. If the query subject acts as a fact, it will be included and if it acts as a dimension, it may be skipped, if no items in the query subject are included in the report query.

These types of errors need to be resolved, and this is usually achieved by replacing the cardinalities between the query subject and other query subjects so they are consistent.

Query subjects with multiple relationships

This test looks for query subjects that have multiple relationships between two objects.

If your model has multiple relationships with no distinguishing criteria to choose from, the reporting tools will use the relationship that comes first alphabetically. If you need to create a query that uses a different relationship, you will always have a problem. These types of errors need to be corrected.

To correct the problem associated with multiple relationships, you need to create aliases for the concerned tables and create joins between the original table and the alias tables. For more information on this subject see Chapter 4, Modeling Relational Data.

Query subjects that join to themselves

This test looks for reflexive and recursive relationships. Framework Manager will import reflexive relationships but does not use them when executing queries. The usual method for resolving this situation is to transform the data to a flat structure with a fixed number of columns before importing into Framework Manager. For more information on this subject see Chapter 4, Modeling Relational Data.

Determinants that conflict with relationships

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 are generated correctly.

The Model Advisor flags occurrences where the keys of a relationship do not match the keys of a group by determinant.

Problems with determinants need to be resolved to prevent problems with incorrect aggregation in reports.

For more details on determinants see Chapter 4, Modeling Relational Data.

Factors that will override the Minimized SQL setting

This test looks out for various factors that override the SQL Generation type setting of Minimized. This usually happens when you have modified data source query subjects, relationships between model query subjects, or determinants for 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.

This is an informational message and does not need to be corrected.

Embedded calculations that use the calculated aggregation type

This test detects where you have set the Regular Aggregate property to "calculated" for embedded calculations.

The calculated aggregation type is supported only for the standalone calculations and calculations that are embedded within measure dimensions. This is an informational message rather than an error and does not need to be corrected.

Query subjects that can cause a metadata caching conflict

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 imported from the data source; however this metadata may might not be used when generating a report query if the imported SQL has been modified.

This is an informational message and does not need to be corrected.

People who finished this also enjoyed: