InfoSphere Information Governance Dashboard model

The IBM® InfoSphere® Information Governance Dashboard model organizes query subjects into the logical components of the metadata model for InfoSphere Information Governance Dashboard.

InfoSphere Information Governance Dashboard reports are based on a Cognos Framework Manager model that represents metadata of interest for reporting in the form of facts and dimensions. The Cognos BI engine translates report queries that are based on these facts and dimensions into the relational format that is required to access the SQL views. The Cognos Framework Manager model of InfoSphere Information Governance Dashboard consists of two layers:

The physical layer that represents the SQL views
The dimensional layer that defines facts and dimensions for use by reports

Note: Certain names or elements might be different from those that are shown in the following images, depending on what version of IBM InfoSphere Information Server you are using.

InfoSphere Information Governance Dashboard model opened in Framework Manager

Physical layer

The physical layer represents the SQL views and lookup tables of the metadata repository. The layer contains folders corresponding to the schemas of the SQL views plus three more folders that represent configuration tables, lookup tables, and derived objects. The query subjects that are defined on this layer have no relationships between them. Relationships are modeled on the dimensional layer.

The query subjects are organized in a folder structure that represents the following components of the InfoSphere Information Server metadata model.

Common Metadata: The Common Metadata section of the InfoSphere Information Governance Dashboard contains a subset of common metadata that includes database metadata that is imported by bridges or connectors. This metadata describes hosts, databases, schemas, tables, views, stored procedures, and columns. The model also contains metadata on notes, users, and stewardship assignments.
Business Glossary: The Business Glossary section of the model includes metadata that is created in IBM InfoSphere Information Governance Catalog: categories, terms, labels, information governance policies, and information governance rules. The section also includes a query subject that links information governance rules to the data rules that implement them.
Information Analyzer: The Information Analyzer section of the model includes metadata that is created in InfoSphere Information Analyzer: projects, data rules, data rule sets, data rule definitions, data rule set definitions. The section also contains query subjects that are necessary to linking analysis objects to other objects.
Exception Management: The Exception Management section of the model includes metadata that is used for managing exceptions, including exception sets and IT assets. The query subjects in this section can be used only if the exception management components are installed.

The physical layer contains the following additional folders:

Configuration Tables folder: The Configuration Tables folder contains query subjects that represent the two configuration tables MSG_LIB and SETUP_PARAMETER.
Lookup Tables folder: The Lookup Tables folder provides access to reference data that maps internal codes to meaningful English words.
Derived Physical Objects folder: The Derived Physical Objects folder defines query subjects that enable a convenient access to objects that are not directly represented by SQL views. Examples of these objects include database objects that can have a governs relationship to terms (ImplementedDataResource) and information governance policies and their child information governance policies within the information governance policy hierarchy (IGPOLICYTREE8).

The following graphic illustrates a fragment from the physical layer. Notice that there are no relationships between query subjects.

Physical layer of Information Governance Dashboard model open in Framework Manager

Dimensional layer

Though the dimensional layer does not offer a dimensional model in the strictest sense, it provides query subjects that are arranged as star or snowflake schema to support the creation of reports that are based on facts and dimensions.

Query subjects on the dimensional layer are shortcuts that point to query subjects of the physical layer. If a query subject plays only a single role in one dimension of the dimensional layer, then it is defined as a reference (Treat As property). If a query subject plays multiple roles, then it is defined as an alias, which enables the use of relationships that are specific to a certain use of the query subject. Most query subjects are modeled as references. The query subject AssociatedDQMetric in the folder DQMetricSet_Fact is an example of an alias because it is based on the same underlying physical query subject IAMETRIC as the query subject DQMetric in the same folder. If both query subjects would be defined as shortcuts of type reference, no metric would ever have an associated metric since the reference shortcut forces both query subjects to refer to the same object but a metric cannot be associated with itself.

Relationships between query subjects are modeled on the dimensional layer. Query subjects are grouped into folders according to the kind of information they contribute to the model. Folders that end with _Fact contain facts and dimensional query subjects that represent dimensions that are closely related to this fact and do not usually apply to facts other the one defined in the same folder. Examples of such folders are DQRuleFact and DQMetricFact. Folders ending with _Dim contain dimensional query subjects that represent dimensions that can be applied to different facts. Dimensions of this type are commonly referred to as shared dimensions. Examples of folders that represent shared dimensions are DBAttribute_to_Host_Dim and Terms_to_Categories_Dim. The dimensional layer has three more folders that contain filters, calculations, and linkages.

Filters and calculations serve as macros that represent commonly used criteria. The following list contains examples of filters:

DQRuleRunIsLatestRun: The DQRuleRunIsLatestRun filter restricts the facts that are displayed in a data quality list or chart to the latest run of a data rule.
FullPolicyToDQRuleLinkageNDQRuleSets: The FullPolicyToDQRuleLinkageNDQRuleSets filter restricts the facts that are displayed in a data quality chart or list to data rules that are linked with information governance policies that are based on relationships at the information governance rule level.
DQRulePercentPassedMissedTarget: The DQRulePercentPassedMissedTarget filter restricts the facts that are displayed in a data quality chart or list to execution results where the percent passed is below the local (if defined) or global upper threshold.

The following list contains examples of calculations:

DQStatusIndicator: The DQStatusIndicator calculation derives a status indicator R, Y, or G that represents the result status of a data rule run.
Message: The Message calculation returns a message from the MSG_LIB table for a particular message ID or an error message if no such message is present.

The Linkage folder defines relationships between query subjects where different implementations are possible depending on how the glossary is defined. An example is the linkage between database objects that are represented by the shared dimension DBAttribute_to_Host_Dim and glossary objects that are represented either by the Terms_to_Categories_Dim dimension (for terms and categories) or by the IGRules_to_Policies_Dim dimension (for information governance rules or information governance policies). This linkage is defined in a dedicated folder because there are multiple ways in which objects from these dimensions can be linked. This linkage can be changed by creating and deleting objects in the linkage folder without impacting fact or rule definitions. To keep the model simple and avoid ambiguity, the following linkages are predefined:

The IGRules_to_Policies_Dim dimension is linked to the DBAttribute_to_Host_Dim dimension based on the binding relationship between data rules and database attributes
The Terms_to_Categories_Dim dimension is linked to the DBAttribute_to_Host_Dim dimension based on the assigned assets relationship between terms and database objects

The Linkage folder contains an example of an alternative linkage in the folder IGRule_to_DBEntity_via_Governs, which links the IGRules_to_Policies_Dim dimension to the DBAttribute_to_Host_Dim dimension based on the governs relationship between information governance rules and database objects. This linkage just serves illustrative purposes. It is not fully implemented to prevent errors when you run query subjects that relate information from these two dimensions. Such errors would be caused by the ambiguity that is introduced if there are two different paths between the involved objects. The query subject IGRule_to_GovernedAsset_Bridge is connected to the IGRule that represents the information governance rule, but the query subject GovernedDataResource is not connected to any object of the DBAttribute_to_Host_Dim dimension. To enable this linkage, you must make this additional connection. If the governs relationship is used for this kind of linkage, then you have two options to avoid introducing ambiguities to the model:

Disable the linkage in the DQRule_to_DBAttribute_via_Binding folder by deleting the folder or one of its underlying relationships.
Create a copy of the DBAttribute_to_Host_Dim folder, rename all query subjects, and then change their shortcut type (property TreatAs) from Reference to Alias. The renaming can be avoided when you use a name space instead of a folder. Create the missing link from the GovernedDataResource subject to the corresponding object in this new dimension.

Although the second option might seem promising, it has a major disadvantage. This disadvantage is that for any query subject that queries objects of the database object dimension, a decision must be made as to which of the two is to be used depending on the relationship of interest. If the binding relationship is of interest, use query subjects from the original folder. If the governs relationship is of interest, use query subjects from its copy. If there is no strong reason for having both links in place, the first option is usually the preferred way because it avoids this artificial distinction and ensures that there is only one way to get from a query subject on the data quality dimension to a query subject on the database object dimension. It is useful to decide early in a metadata reporting project as to which of the two linkage types to use.

The following graphic illustrates a fragment from the dimensional layer with query subjects in a snowflake layout.

A fragment from the dimensional layer with query subjects in snowflake layout.

Relationships between query subjects in different folders do not show up on the diagram views for these folders. They are visible on the diagram for the complete dimensional layer. However, because this diagram is rather complex it might be difficult to locate them. Another way to find these relationships is by dragging the corresponding query subjects into the upper region of the Dependencies tab in the tools view.

Five data sources in the Framework Manager model correspond to the five schemas of the metadata SQL views. The interface type for these connections is D2. It might need to be changed to the interface for the database type at issue if the model is extended with more complex query subjects that depend on database-specific constructs.