Cognos Analytics continues to make advancements in data preparation and metadata governance. Here are the new features in data modules in version 11.0.5.Linked Data Modules
Data modules are now more reusable and combinable than ever before.
Saved data modules that have been previously created can be used as data sources for other data modules. No need to reinvent the wheel. No need to redefine the same KPI calculations over and over again. Reuse and recycle.
As of version 11.0.5, by default a data module source will be a linked data module
. Changes to a linked data module propagate to all other data modules that reference it. A linked data module is always in sync with all other data modules that depend on it.
If Module A is a source to Module B and new filters are added to tables in Module A, those filters are applied when dashboarding or reporting on those tables in Module B. You will see those filters when you open Module B in the modeling interface.
Tables from linked data modules are differentiated in the modeling interface’s metadata tree and diagram by their color and a chain link icon. In the screenshot below, three of the tables are linked to another data module while the other two tables were imported directly from a data server.
Metadata from linked data modules are read-only inside the data modules that reference them. You can review all the properties of a linked data module, including calculation expressions and filter criteria, but you cannot edit any of these properties unless you break the link
When you click on Break link
, the associated metadata is copied over and can then be edited independently of the data module it was sourced from.
You can of course join linked tables to other tables in your data module.
Linked data modules help you bridge the bimodal BI
gap in that IT can issue a governed, trusted data module that line of business users can combine with their own data while ensuring the most recent changes from IT are always reflected. Linked data modules also help you keep individual data modules smaller and more focused on a particular subject which makes them easier to maintain.Navigation Groups
A navigation group is a collection of non-measure columns that business users might associate for data exploration.
When a data module contains navigation groups, dashboard users can drill down and back to change the focus of their analysis by moving between levels of information. The users can drill down from column to column in the navigation group by either following the order of columns in the navigation group, or by choosing the column to which they want to proceed.
You can create a navigation group with columns that are hierarchically related, such as Year, Quarter, and Month. You can also create a navigation group with columns that are not hierarchically related, such as Product, Year, and City.
Columns from different tables can be added to a navigation group. The same column can be added to multiple navigation groups.
A drill down is a convenient and powerful analytic gesture. A drill down action takes the value you clicked on and uses it as a filter while replacing its column's values with the values from the next column. I often describe a drill down action as "break it out by" or "focus on", e.g., I will focus on Value1 by breaking it out by Column2.
Another example: I will focus on 2016 by breaking it out by Region.
In traditional BI and OLAP technologies, a drill down action required hierarchical data such that you could drill down from Country to City but not from Year to City. Navigation groups are much more flexible and can accommodate drilling down from Year to City if that's how users want to analyze their business.Framework Manager Packages in Data Modules
Now you can use a Framework Manager package as a source to a data module. This enables line of business users to extend IT managed metadata models with their own sources of data. You can combine a package with tables from other data modules and data servers, uploaded files, and data sets
In 11.0.5 only relational, dynamic query mode packages are supported in data modules; dimensionally modeled relational (DMR) and OLAP metadata are not yet supported in data modules.
When you bring a package into a data module, the package is a black box while you are modeling – you cannot import a subset of the package (it’s all or none of the package) and joins within the package are not exposed from the modeling interface’s diagram. It is only when joining a package to a table that the contents of the package appear enabling you to find query items from the package for join keys.
Improvements to Loading Database Schema Metadata
Cognos Analytics automates much of the data preparation process including inferring relationships between tables and assigning intelligent default settings for aggregation and usage properties. Best defaults by default is our motto.
These smarts don’t come from a crystal ball – Cognos Analytics will probe your data servers collecting information like primary and foreign keys, sample data, and statistics such as the approximate number of rows in each table and distinct values in certain columns.
Loading all this metadata doesn’t take long for some database schemas (catalogs), but as you would expect it can take a while for those schemas with many thousands of tables.
With version 11.0.5 this information can be loaded before you are modeling, and you can control what information is loaded. Less information reduces the loading time, but automated data preparation is also reduced.
After defining a connection to a data server, you can load metadata for one or more schemas in the data server. Only schemas that have metadata loaded can be used in data modules.
By going into a schema’s Load options
, you can control what information will be retrieved from which tables. If the schema contains tables that don’t have any analytical value, exclude them so that they won’t distract you when you’re modeling and no time is wasted retrieving their metadata.Related posts: #11.0.5#CognosAnalytics#LearnCognosAnalytics#home#ca-modeller