IBM Cognos Framework Manager: Design Metadata Models ...

www.exitcerti�ed.com

IBM Cognos Framework Manager: DesignMetadata Models (v11.1.x) (B6252G)

Presented To Kari Hurst

Course: B6252GClass ID: 155662Dates: 2021/03/08-2021/03/11

Kari [email protected]

TCW Adobe Connect

Course Code: B6252G ERC 1.0

Course Guide

IBM Cognos Framework Manager: Design Metadata Models (V11.1.x)

Name: Kari Hurst Email: [email protected] TCW Adobe Connect 2021/03/08

IBM Cognos Framework Manager : Des ign Metadata Models (v11.1.x)

© Copyright IBM Corp. 2003, 2019 2 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

January 2019 NOTICES

This information was developed for products and services offered in the USA.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing IBM Corporation North Castle Drive, MD-NC119 Armonk, NY 10504-1785 United States of America

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

TRADEMARKS

IBM, the IBM logo, ibm.com, and Cognos are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.

Adobe, and the Adobe logo, are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

© Copyright International Business Machines Corporation 2019.

This document may not be reproduced in whole or in part without the prior written permission of IBM.

US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

ACCESSIBILITY Accessibility features assist users who have a disability, such as restricted mobility or limited vision, to use information technology content successfully. Many IBM products include accessibility features for navigating the user interface, and for authoring reports so that they're accessible for yourself or others. Please consult the product documentation for an overview of accessible product features. Online product documentation can be accessed at the IBM Knowledge Center (http://www.ibm.com/support/knowledgecenter/).




Course information Course overview This offering provides participants with introductory to advanced knowledge of metadata modeling concepts, and how to model metadata for predictable reporting and analysis results using IBM Cognos Framework Manager. Participants will learn the full scope of the metadata modeling process, from initial project creation, to publishing of metadata to the web, enabling end users to easily author reports and analyze data.

Intended audience Data Modelers

Course prerequisites Participants should have: • Knowledge of common industry-standard data structures and design • Experience with SQL • Experience gathering requirements and analyzing data • IBM Cognos Analytics: Author Reports Fundamentals (v11.1.x) (recommended)

Course outline • Introduction to IBM Cognos Framework Manager • Model for predictable results in IBM Cognos Framework Manager • Model for presentation in IBM Cognos Framework Manager • Advanced capabilities in IBM Cognos Framework Manager • Extended capabilities in IBM Cognos Framework Manager




Additional training resources Visit the IBM Skills Gateway (http://www.ibm.com/training/) for details on: • Instructor-led training in a classroom or online • Self-paced training that fits your needs and schedule • Comprehensive curricula, skills validation with the IBM Open Badge program, and

learning journeys that help you identify the courses that are right for you • For other resources that will enhance your success, bookmark the IBM Analytics

Skills Gateway (https://www-03.ibm.com/services/learning/ites.wss/zz-en?pageType=page&c=C067650S63836C42)




Activity: Setting up the training environment Before performing the activities in this course, ensure that all of the necessary products have started. You only need to perform these tasks once, when you first use the training environment, or if you ever restart the operating system in the training environment. If you have closed the training environment and launched it again, it is a best practice to review the status of the services before continuing with the activities.

Ensure all necessary services are running. • From the desktop of the training environment, click Start, and then click

Services . • Scroll through the services to ensure the following have a status of Running:

• Apache Directory Server - default • DB2 -DB2COPY 1 - DB2 • DB2DAS - DB2DAS00 • IBM Cognos • Lotus Domino Server (CProgramFilesx86IBMLotusDominodata) • World Wide Web Publishing Service

• If any of these services are not running, right-click the service, and then click Start. • If the Apache Directory Server or DB2 -DB2COPY 1 - DB2 service have

stopped, you must to stop the IBM Cognos service, start the stopped service(s), and then start the IBM Cognos service once the previously stopped service(s) has (have) started successfully.

• Note that it may take 15 minutes or more for the IBM Cognos service to start. If you receive a message saying this service did not start in a timely fashion, then on the

Services toolbar, periodically click Refresh until the status of the service changes from Starting to Running. Important: The Apache Directory Server service must start before the IBM Cognos service, otherwise you may receive an authentication error saying you are already logged into all available namespaces. To resolve this issue if it arises, stop the IBM Cognos Service, start the Apache Directory Server service, and then start the IBM Cognos Service again. Make sure you stop and then start the IBM Cognos service rather than using Restart.

• It is mandatory to use Internet Explorer as the Web browser for all activities in this course.




Model data and identify related data Define the role of a metadata model in Cognos Analytics An IBM Cognos model provides a business presentation view of an organization’s data sources. Models let users to analyze and report on their data sources. A metadata model is different from a typical data model in that it can hide the structural complexity of your underlying data sources. By creating a metadata model, you have more control over how your data is presented to end users. You can also choose which data to display to your end users and how it will be organized. The overall goal of modeling the metadata is to create a model that provides predictable results and an easy-to-use view of the metadata for authors and analysts. Your underlying data sources may be very diverse. For example, you may have operational or reporting data in one or more relational databases. You may also have legacy data in various other file formats. You may even have online analytical processing (OLAP) sources that include cubes (such as Cognos PowerCubes), as well as other sources such as SAP BW. Data modelers have three main goals: • Accuracy: Reports must contain accurate data. • Usability: Packages produced from a model must be understandable by report

authors and other users. • Performance: Report data, should be retrievable in a reasonable amount of time. As a modeler, accuracy is your first priority. You must determine whether usability or performance is the next highest priority for your authors and users.

Identify data model types and data structures Most data that you will model will be structured data. This means that the source data is stored in physical and logical structures, such as tables, views, cubes, and so on. The structure of the data may be dependent upon the usage of the data as well as the data source itself. In IBM Cognos Analytics, you can work with both relational and dimensional data sources. A relational model has a basic metadata structure that resembles tables and columns in a database. Relational models can have either an operational (normalized) or reporting structure (star-schema). You can use Framework Manager to transform metadata from an operational data source into a model that optimizes it for reporting. Related to relational models are what are known as Dimensionally Modeled Relational (DMR) models. They are built from relational data sources, but are modeled with a dimensional structure (like OLAP) consisting of dimensions, hierarchies, and measures.




Using Framework Manager, you can add dimensional metadata to model objects, which enables drill-through capabilities in Cognos Analytics. OLAP models point to dimensional data sources, such as IBM Cognos PowerCubes, which are built using their own modeling tools, such as Transformer. Relational data entities, known as values, are different from OLAP and DMR data entities, which are referred to as members. When you create a report using a dimensional model, you work with the member. Each member has certain properties such as a member key and member caption. Report authors and consumers see the member caption. Each member is defined and identified by its member unique name (MUN), which describes its position in the dimensional structure. There are basically two types of relational models: operational and reporting.

The example diagram presents an operational database model with the data in normalized form on the left, and a reporting database model in a star schema on the right. Operational databases are used to track day-to-day business operations, hence the name operational. They are usually normalized or part of an enterprise resource planning (ERP) vendor package. Reporting databases are typically a copy of the operational data that are structured to make reporting faster and easier. They are usually dimensional, taking the form of a star schema design. In general, it is recommended that you create a logical model that conforms to star schema concepts. This is a requirement for IBM Cognos Analytics - Reporting and has also proved to be an effective way to organize data for your users.




Understand the relative merits of each model type Operational databases are designed to maximize accuracy and minimize redundancy. They are optimized for writing and updating data, rather than reading and reporting on data. They often need multiple joins to produce accurate queries, which impacts the speed of queries in a negative way. Operational systems are designed with one goal in mind: to get data into the database quickly. These databases are normalized to reduce redundancy. Having little to no redundancy ensures that there is data integrity and that database triggers function properly, so that the right data is captured. Reporting databases, on the other hand, are structured such that transactional data is stored in a fact table. Reference data is stored in separate dimension tables. These are the two basic components of what is known as a star schema. They are joined together only as necessary to produce the reporting data. Because a star schema database contains fewer tables than a fully normalized database, query performance is much faster. Typically, a query against a star schema database focuses on one central fact table and makes integrity checks against the related dimension tables. If the query is to retrieve information about a specific subject area only, such as all the products that belong to a particular product line, then the query will be even faster. In a virtual star schema, you collapse the relationships between tables in order to form dimensions.




The example diagram presents the same two models as the previous diagram, with the relationships of the operational model collapsing to form the star schema of the reporting model. Extract, Transform, and Load (ETL) tools can be used to create a star schema data warehouse, or you may use a metadata modeling tool to emulate a star schema structure by generating the appropriate SQL at report design time. The second option will not improve performance, but will yield predictable results. Framework Manager cannot create a warehouse, but it can emulate a star schema structure by collapsing query subjects to simplify the view and generate the appropriate SQL at run time. Operational data is normalized so that it can be stored more efficiently as shown in the following example.

This example presents three normalized tables that represent three hierarchical levels before they are collapsed into a star schema dimension. Products roll up into product types, and product types roll up into product lines. The Product Line table has two rows that indicate two lines of products sold by the company. The Product Type table contains four rows to indicate the four types of products that fall under the previous two product lines (two types per product line). The Product table contains the greatest level of detail. It contains six rows to represent the six products that fall under the four product types. Reporting data is de-normalized, as shown in the following example.




This example shows a de-normalized dimension table created from the three normalized tables shown previously. The tables have now been collapsed into a star schema dimension. The Product Line table forms the first two columns of the new dimension table (PL# and PL_Desc), the Product Type table forms the next two columns (PT# and PT_Desc), and the Product table forms the last two columns (Prod# and Prod_Desc). The main characteristic of this table is its redundancy. Note that each product line (Classic Tents and Moose Boots) is repeated, once for each product that the product line contains. The same applies for product type. This type of table is unsuitable for a normalized system, but is ideal for a reporting and querying structure. As stated previously, facts and dimensions are the two basic components of a star schema. Fact tables are the focal point of the star schema, and typically contain the most rows. There are typically no descriptive attributes in a fact table. Instead, there are foreign keys that relate to the dimension tables, which contain descriptive attributes. Facts in a fact table are also known as metrics, measures, or key performance indicators. There are cases where you may encounter factless fact tables, in which only foreign keys are found. For example, in the case of a library, you may have a fact table that only contains a book key, a customer key, and a day key, which records which books were checked out by which customer and when. Dimension tables provide the descriptive information for the star schema. Dimension tables may be conformed, meaning that they apply to multiple fact tables across the business. Conformed dimensions prevent islands of information by providing context to multiple potential queries.




Examine relationships and cardinality Relationships specify how data in one table is linked to data in another table. They are implied in the physical data, but modelers explicitly declare relationships. Modelers formulate the reality of the business by configuring relationships. A relationship states a connection or an operational business rule, such as: • a sales representative sells a product • an employee is assigned to a department Relationships work in both directions. You often have to examine both directions to fully understand the relationship. For example: • a branch is composed of employees • an employee may work directly for a branch A star schema may have a number of issues, depending on the data and how it is structured. The star schema structure facilitates reporting efficiency, but different data and relationships within the star schema may present some modeling and reporting difficulties that require various modeling work-arounds, some of which you will study in the pages to come. A few potential issues that can develop when using a star schema include: • Data is only as current as the last data load, it is not live data. • Structural issues:

• The distinct count problem, for instance, counting the exact number of products

• Very large dimension tables which may slow down reporting run times • Snowflakes, when you break out the very large dimension tables into smaller

tables through a normalization process, the resulting tables are called snowflakes

• Fact issues: • Different levels of granularity (detail) in fact tables, for example, some facts

may be at a month level, others at a day level Cardinality indicates the number of instances of an entity in relation to another entity.




The example diagram shows the relationship cardinality indicators for the three types of relationships: one-to-one, one-to-many, and many-to-many. One-to-one relationships occur when one unique row in a table relates to exactly one row in another table. In the cardinality example provided, each employee can only have one security number. One security number can only be associated with one employee. A one-to-many relationship might occur, as in the example, when an order is taken and an Order Header table is populated with data such as date, customer name, and sales staff name. This table is related to an Order Details table that contains data about individual items sold in that one order, such as order detail code, product number, and quantity. Therefore a relationship exists between Order Header and Order Details, whereby each Order Header must contain one or many Order Details, and each Order Detail must appear on one and only one Order Header. Many-to-many relationships occur when many unique rows in a table relate to many rows in another table. The example shows that many suppliers may provide a single part. However, a single supplier may provide many parts. In addition to the instances of cardinality, there are two possible types of cardinality: optional and mandatory. Specify an optional relationship (minimum cardinality of 0) when you want the query to retain the information on the other side of the relationship in the absence of a match. An optional relationship generates an outer join, which results in a null value when there is no data for one table that matches a row of data in another table. Make sure that you only define optional relationships when required, as generating outer joins can negatively affect performance.




Mandatory cardinality is indicated as follows by the 1..n notation:

This example shows an example of mandatory cardinality and how it is indicated by using relationship indicators. The 1..n notation on the Product table means that there will be at least one Product record for every Order record. In this mandatory relationship, a row of data, a product record, must exist, in order for a row of data in another table, an order, to exist. In other words, as in the example, you cannot have an order without a product. Optional cardinality is indicated as follows by the 0..n notation:

This example shows an example of optional cardinality and how it is indicated by using relationship indicators. In the example, the 0..n on the Sales table indicates that there can be 0 or more records for each Sales Rep record. So, it is possible to have a Sales Rep that has no sales to their credit. However, you cannot have a Sale record that does not have a Sales Rep connected to it. In this optional relationship in the example, a row of data, a sale, does not have to exist in order for a row of data in another table, a sales rep, to exist.

Identify different data traps There are four basic data traps that are defined in the upcoming paragraphs. A data trap does not always indicate that there is a problem, only that an area or scenario created in the model is worth inspection, and possible refinement. Be careful of these four data traps. • Chasm trap (many-to-many relationship) • Transitive relationship trap (more than one path between two tables)




• Fan trap (multiple one-to-many relationships that fan out from a single table) • Connection trap (an optional path through different entities) These are data modeling traps, not metadata modeling traps, so you cannot use Framework Manager to fix them in the data source. However it is useful to know of them so that you can make metadata model designs which can handle them and generate the appropriate SQL at run time to provide predictable results. You will examine characteristics of each of these traps in the upcoming pages. A chasm trap is a many-to-many relationship where more than one row in a table is related to more than one row in another table. The structure cannot record and maintain data (it lets the information fall into a chasm). This structure is not necessarily incorrect when designing at a high level, it just does not show all the necessary details. Notice in the many-to-many below. It shows that a single supplier may provide many parts, and many suppliers may provide a single part. If each supplier can potentially supply every single part, how do you report on the suppliers that provide specific parts? This is typically resolved with a bridge table that records the details of the relationship between the two tables. A transitive relationship trap exists if there is more than one join path between two tables. This relationship trap resembles a wheel shape.

The example shows the circular logic of a relationship trap. An Order table is the hierarchical parent of an Order Detail table. Adjoined to both of those tables is a Customer table. It presents the quandary of what is the best path to link a customer to an order? Is it by way of the Customer-to-Order relationship, or by way of the Customer-to-Order Detail relationship?




This kind of trap may make it difficult to write queries that retrieve the appropriate data, because it may not be clear which table columns must be included in the query. Going through either path produces some sort of result, but which path is the correct or more efficient one for your specific query? Fan traps, also known as parallel relationships, involve multiple one-to-many relationships that fan out from a single table, implying that the two other tables have no connection to each other.

The example shows a fan trap or parallel relationship with a Division table related to a Branch table such that one division may have many branches. The Division table is also related to an Employee table such that one Division may have many Employees. The modeler should examine fan traps to determine whether a crucial relationship is missing. For example in the diagram, Branch may actually have a direct relationship to Employee. The final data trap you will examine is the connection trap. The connection trap suggests that there may be an optional path through different entities. For example, in the following graphic, what is the relationship between Branch and Employee? If an employee does not work for a branch, do they work for a division?




The example shows a connection trap whereby there is a serial relationship from left to right with a Division table being related to a Branch table, which is related to an Employee table. However, there is also a relationship directly between the leftmost Division table and the rightmost Employee table indicating that the middle entity may be bypassed for some records. The relationship in the sample infers that there may be a direct relationship between the Employee and Division tables. An employee may be able to work directly for a division, instead of working for a branch within a division. For example, the employee may work from a home office. The problem with this trap is that there must be a reliable path through all truly related entities.

Examine OLAP data structures Remember from the previous pages the discussion of OLAP. OLAP is an alternative data access strategy to modeling metadata for Relational models The OLAP structure consists of the following elements: • Dimensions - contain members, which are structured into hierarchies and levels • Hierarchies - provide context to the level structures they contain • Levels - provide structure for the members of a hierarchy • Members - data entities that provide context to cell values • Attributes - provide additional information about members • Cells - are intersection points containing values (measures) for various members

from different dimensions (also referred to as tuples) Tools that can be used to build an OLAP data structure include SAP BW and Cognos PowerPlay Transformer. The reporting traps just discussed should already have been modeled out in this kind of structure. The data represents a snap shot in time and must be periodically updated. Related to OLAP, is MOLAP and ROLAP, which are defined as follows: • Multidimensional OLAP (MOLAP)

• Transforms data into cubes that are optimized for analytic queries • Creates multiple copies of the cube, and the ETL process can be lengthy

• Relational OLAP (ROLAP) • Operates on top of a relational datasource in which data is modeled as star

schemas • Pre-computed summaries provide faster query results




ROLAP is optimized to work with large data sets. It uses aggregate tables to improve the speed at which large queries are executed. You can design a ROLAP cube by using the IBM Cognos Dynamic Cube Designer, which is outside the scope of this course. Remember when you derive a data access strategy, the methods that you use to access your data for reporting purposes will be determined by your needs and by the structure and content of the data itself. What are acceptable performance times for your reports? If the information is required quickly (within seconds), consider using cubes. A cube might be best to analyze data sets that are not prohibitively large However, if the data set is extremely large, cubes may not be the solution and you may want to consider using a data mart or warehouse with pre-aggregated tables. Consider creating a star schema to improve performance over an operational system. However, if you require live data, you may have no choice but to go directly against your operational system. Remember that reporting directly against a normalized operational system may yield poor performance and may slow down the writing of data to the database. Planning and scope should be given a great deal of attention before embarking on a business intelligence project.




Define requirements and modeling strategies Examine key modeling recommendations Listed here are ten key modeling recommendations that apply to both operational and dimensional (star schema) data sources. If proper design has been implemented, then dimensional data will usually require much less modeling in the Framework Manager environment. • Define reporting requirements and data access strategies. This will help you to find

the correct data and define a data access strategy. Based on available data sources, data volumes, and environmental factors such as network speed, hardware processing power, and so on, an appropriate data access strategy should be planned and implemented to ensure acceptable response times to report requests.

• Import only required reporting objects in manageable chunks in a phased approach and alter data source query subjects as little as possible. Leaving data source query subjects as simple all-inclusive select statements reduces future maintenance. For example, when a table has a new column added to it, simply update the data source query subject that references it in Framework Manager and the new column will appear as a new query item.

• Verify that relationships reflect those in the data source and that the query item properties are set correctly. For relationships, notice the following items. • cases where a dimension query subject relates to a fact query subject on

different keys • cases where there are multiple valid relationships between query subjects • dimension query subjects that belong to multiple hierarchies

• Model in freehand to identify modeling challenges and how query subjects are used (which query subjects are treated as facts, dimensions, or both). Identifying these issues on paper can provide a clear modeling plan.

• Use model query subjects to control query generation and usage and to consolidate metadata. You should use simplified, abstracted model query subjects to resolve modeling challenges. • Create aliases where required to control query paths. • Modeling as a virtual star schema to control SQL generation (what is a fact?

what is a dimension?). • Remove descriptive (dimensional) attributes from fact tables.




• Consolidate related information into one model query subject for a cleaner presentation (for example, placing all product related query items in one model query subject).

• Customize metadata for runtime. • Use parameter maps and session parameters to handle dynamic column or

row retrieval. • Use prompt values and query macros to add mandatory user prompts and

security filters. • Specify determinant information where required to enable accurate aggregation in

cases where a level of granularity has repeating keys, your data contains BLOBs, or you want to avoid the distinct clause on unique values when grouping or enhance performance for regular dimensions.

• Resolve any relationship ambiguities, such as multiple joins between two query subjects, by deleting surplus joins and by creating role-playing dimensions.

• Create regular and measure dimensions if authors need to perform OLAP-style queries on relational data.

• Create the business view as a set of star schema groupings. Use those groupings to build logical business groupings in the business view and to indicate conformed dimensions based on naming conventions.

These recommendations are designed to be a guideline. Modelers must do what is appropriate for their situation. These recommendations cannot account for every modeling need, and therefore, modelers will always need to decide when to use some or all of these recommendations, and when to model outside of the paradigm presented here.

Define reporting requirements As a modeler, you must identify the business-intelligence related problems to be solved. Problems to be solved include setting the scope of your project and setting its methodology, as well as multilingualism, performance, security, and presentation. You should ask questions such as: • Do you and the IBM Cognos users agree on the model requirements? • Does the data source contain the data and metadata you need? • Does the same data exist in more than one source? • Which data source tables are the fact tables, which are the dimensions, and which

are both fact tables and dimensions? What are the keys and attributes of each dimension?




• Do fact tables contain only facts and foreign keys? Do they also contain dimensional attributes that should be in dimension tables?

• What are the required relationships and are there multiple paths between tables? Interview authors and users to determine what their needs are and if possible, view existing reports that IBM Cognos will be replacing. Ralph Kimball (author on the subject of data warehousing and business intelligence) recommends an interview-based approach to determine report requirements. The focus is on what information the key business decision makers require to do their jobs. This will result in a framework of key performance indicators (KPI) and business contexts.

Explore data sources to identify data access strategies Consider your data access strategy. Particularly some of the strategic items mentioned in the previous topic. Questions you should ask include? • What are your data sources? • Are there multiple data sources? • Are your data sources operational or reporting data? • What type of relationships are involved in your source data and what relationships

will you need to build in your model? Understand and list your data access strategies as much as possible based on what you know and can find out about your data sources.

Prepare for modeling metadata as a star schema In your first activity you will be modeling operational, relational data. Although a reporting (star schema) database is recommended for performance and ease of use, in this course you will model an operational system to provide you with a wider variety of modeling techniques and prepare you for more data scenarios at your place of work. In your first activity, you will need to locate and determine the name of the relational database in your environment that contains operational data. You will be using that database to model metadata for various scenarios. You will focus on the portion of the database that facilitates the measures you choose to use as your facts, and the dimensions that help define those measures. The first activity is called Identify data sources. Before you create a Framework Manager project, you must do the following. • Analyze and understand your reporting requirements based on the business

process that authors will be reporting on. • Understand your data and the structure of your data source(s).




Once you interview your users, you will determine what measures they want to report on. Is it sales data, talent, workforce performance, budgets and transaction amounts from financials? Your interviews will let you know what metrics or facts you are measuring. Your interviews will also guide you as to how, or by which dimensions, your users want to see those measures. Is it over time? Surely time will be involved in some way. What other dimensions will you use? If you report on sales data, it's possible that your dimensions will be sales reps, vendors, retailers, products, and so on. If you report on financial data, your dimensions may be due dates, discount dates, geography, chart of accounts, vendors, and so on. Once you know your facts or measures and your dimensions, you should interview the database administrator to find out where this information can be obtained. What database will your source be? What tables contain the metrics you seek? Is it the Sales table? Is it the Orders table? Maybe it is the Accounts Payable or Accounts Receivables table? What tables contain the attributes or dimensions your users want to see? The database administrator can also guide you in determining how the dimensions relate to the facts, and possibly provide diagrams that give a visual representation of these relationships. Those diagrams are called ERDs (entity relationship diagrams). ERDs can be useful references to you in the creation of a model in a star schema format.

Model in stages A recommended practice is to model in stages using an iterative approach. A common tendency is to immediately import all metadata to meet all reporting requirements which creates a complex set of objects to work with as a starting point. The recommended approach is to develop your model in stages. You should start with a subset of report requirements and then import additional metadata as needed. As you progress in your modeling activities, you may discover other requirements or the data itself may present you with other reporting options that were not thought of by the end users. This is the iterative approach. You should revisit your model and revise it as required.

Model in layers Modeling in layers means that you use a Presentation View for logical groupings. A Presentation View contains only the star schema groupings. This logically groups objects appropriate for the business and easily allows you to create separate packages for different reporting needs.




This graphic represents different approaches to layer modeling using various models. Views are presented as labeled rectangles. From left to right, model 1 presents the Presentation View on top of a blank view, on top of the Foundation Objects View. Model 2 shows the Presentation View directly on top of the Foundation Objects View. Model 3 shows the Presentation on top of a Business Logic View, on top of the Data Source View. Model 4 shows the Presentation View on top of the Consolidation View, on top of the Foundation Objects View. This graphic will be referred to in the following descriptions. The decision to have another layer between the Foundation Objects View and the Presentation View, shown by model 1 in the previous graphic, involves several factors. For example, what is the size of the model? Do you need to reduce development time rather than ensure ease of maintenance later in the modeling cycle? You can model in layers using no middle layer as shown in model 2 in the previous graphic. When you do so, the Foundation Objects View contains data source and model query subjects, as well as calculations and filters. Though it is appropriate for large projects, it can be difficult to maintain if the data source structure changes frequently. This method requires the least duplication of query subjects, keeping the physical size of the project files to a minimum. It is best suited to large implementations or situations where a data warehouse has already been set up to accommodate the majority of the specialized business logic for reporting. While it requires less development time, this method can require more maintenance when in production, since you will need to remodel to reflect any changes to the underlying data source objects, since the published objects are simply shortcuts to the data source query subjects. Therefore, if you expect ongoing changes to the underlying data structure, this may not be a suitable option.




Using a Business Logic View layer, as shown in model 3 in the graphic, lets you set up the complex queries and reuse foundation layer objects in multiple locations. This provides insulation from the underlying data source for the reports. No work is required in the Data Source View since it is all done in the Business Logic View. Creating the model query subjects (and rebuilding all their relationships) in the Business Logic View takes extra work, but it provides a layered structure for improved model maintenance, readability and portability. For example, to move the application from one database vendor to another, all you have to do is re-map the model query subjects in the Business Logic View to the tables in the new data source. There is no need to rebuild the reports, or remodel the metadata. Using a Consolidation View layer, shown in model 4 in the previous graphic, is a compromise between the previous two methods, you create model query subjects and their relationships in the lowest layer. The middle layer acts as a consolidation layer with some business logic (where required). For example, this view is where snowflake dimensions are consolidated. It also acts as an insulation layer between reports and the data source. Calculations may appear in either the lowest or the middle layer, depending on where the related model query subject is created. A model query subject that is created to resolve a reporting issue will be created in the lowest layer. Therefore, any calculations required for that object will be defined in the lowest layer. The Business Logic View and Consolidation View methods create additional model query subjects even when data source query subjects present no issue and could technically be used in the Presentation View. This can affect physical file size noticeably. The Consolidation View method is the middle ground and is the approach that this course will use. After the Foundation Objects View layer is completed, it will contain the following: • all data source query subjects • any model query subjects required to resolve reporting issues • some calculations and filters where appropriate




Activity: Identify data sources based on requirements

As the modeler for The Sample Outdoors Company, your task is to develop a model that supports the business requirements of report and ad hoc query authors working with IBM Cognos Analytics. Before you begin the modeling process, you will locate the data sources identified as necessary to meet those reporting requirements. In this activity, you will accomplish the following: • Open IBM Data Studio and connect to the database • Explore the tables

Open IBM Data Studio and connect to the database. • From the Start menu, click IBM Data Studio, and then click Data Studio 4.1.0.0

Client. • Click OK to close the Workspace Launcher (if necessary). • From the Administration Explorer pane, expand localhost and 50000.

• Click 50000, and then on the toolbar, click New Connection to a database . The New Connection dialog box appears.

• Specify these parameters: • Local tab (Select a database manager): DB2 for Linux, UNIX, and Windows • JDBC driver: IBM Data Server Driver for JDBC and SQLJ (JDBC 4.0)

Default • Database: GS_DB • Host: localhost • Port number: 50000 • User name: db2admin • Password: Education1 • Ensure the Save password check box is selected




The results appear as follows:

• Click Test Connection.

The connection is tested successfully. • Click OK to close the confirmation message, and then click Finish. • Under the 50000 node, ensure the GS_DB1 (DB2 for Linux, UNIX, and Windows

V9.1) node is expanded. • Click the Tables folder.

The GS_DB1 tab appears in the Details pane on the right, containing information about the tables.

Explore the tables. The sales reports will be focused on orders, so note the ORDER_DETAILS, ORDER_HEADER, and ORDER_METHOD tables.

• In the Name column, double-click ORDER_HEADER to view details for the ORDER_HEADER table in the Details pane. You can identify the tables related to the ORDER_HEADER header table by looking for foreign keys. Here you can see several keys: ORDER_NUMBER, RETAILER_SITE_CODE, RETAILER_CONTACT_CODE, SALES_STAFF_CODE, SALES_BRANCH_CODE, and ORDER_METHOD_CODE. You will now examine some of these relationships.




• On the toolbar, click the Back to Tables arrow, and then double-click ORDER_DETAILS to view details for the ORDER_DETAILS table in the Details pane. You can see the facts needed for many reports: QUANTITY, UNIT_COST, UNIT_PRICE, and UNIT_SALE_PRICE. You also see ORDER_NUMBER, confirming the relationship to ORDER_DETAILS. You also see PRODUCT_NUMBER. You will confirm that this is the link to the Product data.

• Click the Back to Tables arrow. You can see a series of tables whose names start with PRODUCT_, so you will have to view each one to decide if they contain data that meets the reporting requirements.

• Double-click PRODUCT to view details for the PRODUCT table in the Details pane. You see PRODUCT_NUMBER, confirming that this is the link to the sales (ORDER_DETAIL) data. Upon asking the Database Administrator about BASE_PRODUCT_NUMBER, you learn that this is for handling multiple brands of a given product. You see several codes, indicating foreign keys to PRODUCT_TYPE, PRODUCT_COLOR, PRODUCT_SIZE, and PRODUCT_BRAND. However you don't see a product name or description field. You will have to keep looking.

• Click Back to Tables, and then double-click PRODUCT_TYPE to view details for the PRODUCT_TYPE table in the Details pane. You see PRODUCT_TYPE_CODE, confirming the link to PRODUCT. You also see PRODUCT_LINE_CODE (which you can confirm links to PRODUCT_LINE in a three-level hierarchy; product line>product type>product). Note the many PRODUCT_TYPE_xx columns. This is one form of multilingual support, a column for each language. Later in the course, you will see how you can modify the metadata so that authors and consumers can access a single product type column, which will automatically return the appropriate language based on the user's regional settings. Recall that you did not see such a list of columns for the name of the product itself in PRODUCT, so that table must have a different form of multilingual support.




• Click Back to Tables, and then double-click PRODUCT_NAME_LOOKUP to view details for the PRODUCT_NAME_LOOKUP table in the Details pane. Now you see PRODUCT_NAME and PRODUCT_DESCRIPTION as well as PRODUCT_LANGUAGE, and you can conclude that this table must have multiple language records for each PRODUCT_NUMBER. The only outstanding report item required before beginning a baseline project is an order method. Recall that ORDER_HEADER holds an ORDER_METHOD_CODE column.

• Click Back to Tables, and then double-click ORDER_METHOD. You see the order method columns; one for each supported language in the data. You will need to resolve this multilingual challenge in the same manner you will use for PRODUCT_TYPE_xx.

• Close IBM Data Studio.




Overview of IBM Cognos Framework Manager Explore Framework Manager in Cognos Analytics Framework Manager provides the metadata model development environment for IBM Cognos Analytics. It is used to create simplified business presentations of metadata derived from one or more data sources. Framework Manager is a Windows-based client application as opposed to IBM Cognos Analytics, which is a Web-based application. When you work in Framework Manager, you work in a project. A project contains metadata objects (the model) organized for report authors according to the business model and rules. A model in Framework Manager is a business presentation of the structure of the data from one or more data sources. A model defines the metadata objects, structure, and grouping, as well as relationships and security. The modeler's job is to take the complexity of the underlying data structures and create simplified presentations for authors and business analysts that provide predictable results. These simplified views are then published as packages to IBM Cognos Analytics for use in creating reports. The connection between Framework Manager and the Cognos dispatcher is defined in Cognos Configuration. Since Framework Manager is a local installation and most IBM Cognos Analytics resides on the cloud, the installer must define a connection that allows Framework Manager to communicate with the dispatcher, either directly or through a dedicated gateway. This connection allows the modeler to publish packages to the Cognos Analytics environment, by ensuring that Framework Manager connects to the same URI as the non-modeling components of IBM Cognos Analytics. Framework Manager uses two query modes: compatible or dynamic. Dynamic Query Mode (DQM) is best for new IBM Cognos Analytics applications that have supported data sources. DQM optimizes query planning, execution, and results in supported environments. Projects created in version 10.1 or earlier were created in Compatible Query Mode (CQM). Existing CQM projects can be tested, published, or changed to dynamic query mode. When you create a project in Framework Manager, you can select which query mode it will use. If your data sources are supported, DQM is the recommended mode, as it improves query performance by reducing query complexity and using in-memory caching to optimize query execution. As described in a previous topic, you can create two model types: • Relational for reporting • Dimensionally modeled relational (DMR) for OLAP-style analysis and reporting




Relational models consist of query subjects and within those, query items. DMR models consist of dimensional information provided by the modeler, such as hierarchies and levels, to allow authors to perform OLAP-style queries. These two model types can be developed in the same project and published as separate packages.

Explore the Framework Manager project As you will see in the next activity, the system files of a project consist of a folder containing a project file (.cpf) and a set of XML files specific to that project. These files should be backed up or checked into a repository control system regularly to prevent data loss. At the highest level, objects in a project include the following: • A Model: the set of metadata objects organized and modeled for report authors.

The root of the model is a namespace that can contain other namespaces and folders, which are containers for organizing objects; however the names of objects in a namespace are qualified with the namespace name to uniquely identify them. This allows you to have objects of the same name in different namespaces.

• Data sources: information IBM Cognos Analytics uses to connect to data sources. • Parameter maps: optional lists allowing the substitution of one value for another at

run time. • Packages: subsets of the project objects that are published to IBM Cognos

Analytics for use by authors and business analysts. Though you will become familiar with the icons in the next activity for each of the objects you will interact with in Framework Manager, the objects can be summarized as follows: • Query subjects: map to objects in the data source, such as tables, views,

synonyms, procedures, or functions. There are three types of query subjects: • Data source: maps to a corresponding object in the data source and uses a

modifiable SQL statement to retrieve the data. • Model: maps to existing metadata in the model. • Stored procedure: executes a database stored procedure to retrieve or

update the data. • Query items: contained within a query subject and map to a corresponding object

in the data source. For example, a query subject that references an entire table contains query items that represent each column in the table.

• Relationships: represent the connection that explains how the data in one query subject relates to the data in another. When you create a relationship, you define the cardinality of each end of the relationship.




• Regular dimensions: contain descriptive and business key information, and organize the information in a hierarchy from the highest level of granularity to the lowest, allowing for OLAP-style queries. Regular and measure dimensions map to query items. You work with regular and measure dimensions when you model dimensionally. You model dimensionally when your report and business analysts require OLAP-style queries, reports, and analyses.

• Measure dimensions: a collection of facts for OLAP-style queries. • Scope relationships: exist between measure dimensions and regular dimensions

to define the level at which the measures are available for reporting. • Shortcuts: pointers to an underlying object that can act as an alias or reference. In

this course you will mainly use shortcuts to create star schema groupings for presentation of logical groupings to the authors.

So, what do report authors actually view? Within IBM Cognos Analytics, report authors interact with a run-time version of a subset of the Framework Manager model. This subset, which the modeler publishes as a package from Framework Manager to the IBM Cognos Analytics server, contains metadata that exists in the development model. It is packaged in a structure reflecting a viewpoint appropriate for report authors and business analysts. The actual data is not published with the package; it is retrieved from the underlying data source at run time. In Framework Manager, you can create several packages containing different subsets of the model.




Activity: Explore a complete Framework Manager project

You will examine the objects and the different logical development layers that comprise a Framework Manager model. You will explore the user interface, publish a package from Framework Manager, and create a report based on that package. In this activity, you will accomplish the following: • Examine the Framework Manager UI and view the top-level objects • View the detail objects • View the package as a report author

Examine the Framework Manager UI and view the top-level objects. • Open File Explorer, and then navigate to

C:\Training\B6252G\CBIFM-Files\Final. The project files for a Framework Manager model appear. The .cpf file is the main project file. The .xml files store model information, preferences, session logging, action logging (each modeling action you make), and so on.

• From the Start menu, navigate to and then expand IBM Cognos Framework Manager.

• Right-click IBM Cognos Framework Manager , point to More, and then click Run as administrator. To avoid potential errors when opening a project, ensure that you run Framework Manager as the administrator user, as indicated above.

• Click Open a project, navigate to C:\Training\B6252G\CBIFM-Files\Final, and then double-click GO Operational.cpf.

• Log in as admin/Education1.




• On the Tools pane (on the right side of the window), click the Summary tab. The left half of your screen appears similar to the following:




The right half of your screen appears similar to the following:

• Examine the different panes:

• Project Viewer: provides access to all of your project's objects in a tree format. • Project Information: provides access to the project's objects through three

tabs (Explorer, Diagram, and Dimension Map) that allow you to create, edit, configure, or delete objects.

• Properties: allows you to configure various properties for any of the project's objects.

• Tools: lets you quickly switch the project language, view project statistics, and perform common tasks for selected objects. This pane also provides a search utility (second tab) and an object dependencies utility (third tab). Simply drag an object (and its children if it has any) to the top panel, select the object or one of its children in the top panel and view the dependent objects in the bottom panel. This is very useful when you want to change an object and assess the impact that the change will have on other objects in the model.




All panes can be hidden except the Project Information pane, which is the main work area. To bring them back, simply select them from the View menu or use the toggles on the toolbar. You can also detach and rearrange the Project Viewer, Properties, and Tools panes.

• Expand Data Sources, click GOSALES, and then expand Type in the Properties pane. The results appear as follows:

Notice the Query Type property indicates that these are relational sources.

• In the Project Viewer pane, expand GO Operational Model. The results appear as follows:

Notice the four namespaces for logical separation of objects by function. These are the naming conventions used in this course. You can use whatever naming convention and object organization you are comfortable with. • Consolidation View is an isolation layer. It is made up of model query

subjects that are used as containers to consolidate multiple query subjects into one (such as Product, Product Type, and Product Line). It also simplifies query subjects by hiding codes or organizing them in subfolders. This layer insulates reports from potential changes in the underlying data source.

• Dimensional View contains multidimensional objects based on model query subjects in the Consolidation View. These are used for OLAP-style queries and are based on objects in the Consolidation View.




• Presentation View contains groupings of shortcuts that present the underlying objects in a logical presentation.

• Foundation Objects View contains the "base" query subjects; data source query subjects as well as any model query subjects used to resolve reporting issues.

View the detail objects. • Expand Foundation Objects View > gosales.

A section of the results appears as follows:

The gosales namespace contains all the data source query subjects (represented with a small database icon) created during the import process from the GOSALES database as well as model query subjects that are used to alias original data source query subjects or to create views (merge query subjects together to create "As View" behavior) of original data source query subjects. The small yellow angle ruler icon indicates the query subject contains measures as seen on Sales Fact, SALES_TARGET, and Returns Fact.




• In the Project Viewer pane, under the gosales namespace, expand SALES_TARGET. The results appear as follows:

Notice that, with the exception of a few property changes, these data source query subjects are untouched after being imported. This is recommended to ease maintenance.

• Expand Sales Fact. The results appear as follows:

This is a model query subject that is the result of merging two data source query subjects together to create "As View" behavior. Query items to be used by authors have been given user-friendly names. This is not needed for query items that will not be included in the final Presentation View. Calculations have also been implemented in this object.




• Double-click Sales Fact to open its definition dialog. A section of the results appears as follows:

Here you can see all the query items that make up the model query subject as well as any filters or determinants that might be specified. The source column tells you how the query item is derived. You can edit the definition of each query item in this dialog by clicking the ellipses in the Source column. You can also go directly to the query item definition from the Project Viewer tree. You will do this now.

• Click Cancel, and then under Sales Fact, double-click ORDER_NUMBER. A section of the results appear as follows:

Here you can see and edit the definition of the query item. The query item can be a direct reference to another item, or a calculation. In this case it is a direct reference that is broken down as follows: [Namespace].[Query Subject].[Query Item].

• Click Cancel, and in Foundation Objects View > gosales, expand Reusable Objects > Model Calculations. The results appear as follows:

This folder contains several commonly requested calculations (in this case, the calculation retrieves a specific language value from the data source) to allow maintenance from a single source.




• Expand Consolidation View > Sales Fact. The results appear as follows:

This namespace is a simplified version of Sales Fact from the Foundation Objects View. It only contains the measures (facts), hiding the complex keys. This layer is a consistent presentation where all objects simply act as containers to consolidate information from the underlying Foundation Objects View. It also contains calculations, filters, and appropriate naming conventions. These are the objects authors will work with directly or indirectly.

• In Consolidation View, expand Model Filters > Retailer Location Filters. The results appear as follows:

These folders contain several filters that authors can pick from to simplify report filtering.




• Expand Dimensional View. The results appear as follows:

This view comprises dimensions and measures that are based on objects in the Consolidation View. These objects contain dimensional information (hierarchies, levels, attributes, and so on). They are used for OLAP-style queries in IBM Cognos Analytics - Reporting.

• Expand Presentation View, and then expand GO Operational Sales (query) and GO Operational Sales (analysis). The results appear as follows:

There are two namespaces: one contains objects for queries and reports, and the other for analysis. There is also a Call Center Application namespace that is specific to a particular application to quickly retrieve order information.




• In GO Operational Sales (query), expand both Sales (query) and Returns (query). A section of the results appears as follows:

These two namespaces contain shortcuts that logically group the Consolidation View objects. Facts are grouped with their related dimensions. The namespaces have some overlapping object names (conformed dimensions). To create multi-fact queries across multiple areas of the business, include at least one conformed dimension.

View the package as a report author. • Expand Packages (scroll to bottom), and then double-click

GO Operational (query). The results appear as follows:

The package contains a subset of the project specific to objects to be used for relational queries and reports.




• Click Cancel, right-click GO Operational (query), and then click Publish Packages.

• Click Next twice, clear the Verify the package before publishing check box (if necessary), and then click Publish.

• Click Finish. • Open Google Chrome and navigate to http://localhost:9300/bi/ (if necessary). • Sign in as admin/Education1.

This will sign you in to IBM Cognos Analytics. • Click Team content, and then point to the GO Operational (query) to expose the

More button (…). This accesses the package you just published.

• Click the More button, and then click Create report. • From the Templates and themes page, select Blank, and then click OK.

• In the work area, click Add , click List, and then click OK to accept the query defaults.

• In the upper-right corner, click Manage , and then click Options. • In the Options dialog box, click the Report tab, ensure the Automatic group and

summary behavior for lists check box is cleared, and then click OK. • In the Sources tab, expand Sales (query) and Returns (query).

Notice that this is the same structure and grouping as seen in the Presentation View in the previous task.

• Add the following items to the report: • Sales (query) > Products > Product Line • Sales (query) > Time > Year • Sales (query ) > Sales Fact > Revenue • Returns (query) > Returns Fact > Return Quantity Tip: To add a query item to the report, you can either double-click the query item in the Sources tab, or click and drag the item onto the report area.

• Click the <Product Line> list column body, and then from the on-demand toolbar,

click Group/Ungroup to group the report on Product Line.




• On the Application bar, click Run options, and then click Run HTML. The results appear similar to the following:

• Close the rendered report tab.

• On the Application bar, click Admin Person , and then click Sign out without saving the report.

• In Framework Manager, from the File menu, click Close to close the project without saving changes.

• Close all open windows.




Create a baseline project Review the Framework Manager workflow process Once you create the initial Framework Manager project, the workflow process is a loop, or reiteration of the steps listed here: • Import metadata: import objects such as tables, views, and procedures • Prepare metadata: examine and modify properties and relationships • Model metadata for reporting: add business value specific to reporting

requirements and model for predictable results • Create and manage packages: identify subsets of the metadata to be published • Set security: apply security at various levels to restrict access • Publish: publish packages to the IBM Cognos servers for use by report authors As stated, this workflow is a reiterative process. Once the package is published and you need to enhance or grow your metadata, you start over at the Import metadata stage. Managing the project is another important activity, not shown on the diagram because it is to be performed throughout the modeling process. This includes activities such as implementing multi-user modeling, sharing and reusing information, action logging and synchronizing, and validating the project.

Importing metadata When importing metadata, you should only import the required metadata in a phased approach to minimize clutter in the model. For relational data sources, choose the model object into which you will import, and then do the following in sequential order: 1. Select Data Sources as the import source. 2. Select the data source to be used (usually a relational database), or create a data

source connection, and then select it. Creating a data source connection is usually done by an Administrator, using IBM Cognos Administration. Depending on the roles and responsibilities in your organization, you may need to request that your Administrator perform this task for you.

3. Select the required objects to import; for example, tables, views, or procedures. 4. Select the criteria by which Framework Manager will generate relationships.




The Metadata Wizard appears by default when you create a new project. You can either work through the wizard, or cancel and import your metadata at a later time when you see fit. It is in this wizard that you can choose the objects you want to import and whether to create relationships among either the objects being imported, or the objects being imported and the existing objects in the model, or both. By default, an import converts outer joins to inner joins. This is done for performance reasons. You can choose to generate outer joins if that meets your business needs or you can edit specific relationships after import to meet your needs. Another option is to enable or disable fact detection. If this option is disabled, all relationships will be 1..1 to 1..1.




Activity: Create a baseline project Your first step as a data modeler for the Sample Outdoors Company is to create a new project, set up a data source connection, and start the metadata modeling process. You will also create and publish a package. In this activity, you will accomplish the following: • Create a new project • Create and organize objects • Create a data source and test the connection • Import metadata • Test basic data access • Change SQL generation settings and specify a function list • Test multiple query subject data access • Create and publish a package • View the package in IBM Cognos Analytics • Create a report

Create a new project. • From the Start menu, navigate to and expand IBM Cognos Framework Manager.

• Right-click IBM Cognos Framework Manager , point to More, and then click Run as administrator.

• Under Projects, click Create a new project.

• In the Location box, click Browse , select C:\Training\B6252G\Course_Project, click OK, and then update what appears in the Project name box, by typing GO Operational. The GO Operational folder is created by default and appears in the Location box.

• Clear the Use Dynamic Query Mode check box, and then click OK. • Log in using admin/Education1.

The Select Languages dialog box appears. You will initially set the default and design language for this project as English.




• Ensure that English is selected, and then click OK. The Metadata Wizard appears. You will first organize your project and then import metadata into the appropriate location in a later task.

• Click Cancel. The project opens in Framework Manager. Notice in the Project Viewer that the project appears with the name you provided and a default namespace called Model.

Create and organize objects.

• Rename the Model namespace to GO Operational Model. Tip: You can press F2 to edit the label.

• Right-click the GO Operational Model namespace, point to Create, and then click Namespace.

• Rename New Namespace to Foundation Objects View. • Right-click the Foundation Objects View namespace, point to Create, and then

click Namespace. • Rename New Namespace to gosales.

The model appears as shown below:

Creating the gosales namespace makes the Foundation Objects View extensible in the event you want to import metadata from another data source. At the time of the import of the second data source, you would create another namespace to contain those data source query subjects. You will now begin the process for importing the metadata into the gosales namespace. You will start by creating a data source and testing the connection to it.

Create a data source and test the connection. • Right-click the gosales namespace, and then click Run Metadata Wizard.

The Metadata Wizard appears. From here you can select the source from which you will import the metadata. You will import data from a relational database.




• Ensure that Data Sources is selected, and then click Next. You are now prompted to select a data source from a list of available data sources. You can create data source connections in either IBM Cognos Administration, or in Framework Manager. In order to demonstrate this process, you will create a new data source named GOSALES2. The majority of the course uses a pre-defined data source connection (GOSALES), which connects to the same underlying database as GOSALES2.

• Click New. The Welcome page of the New Data Source wizard appears. This is the same wizard that is used to create data sources through the Directory tool in the IBM Cognos Analytics administration interface.

• Click Next, in the Name field, type GOSALES2, and then click Next. • In the Type list, click IBM Db2, clear the Configure JDBC connection check box,

and then click Next. When you select the Configure JDBC connection check box, you are prompted to enter additional connection details that support Dynamic Query Mode. This feature is discussed elsewhere in the course.

• In the DB2 database name field, type GS_DB. • Under Signons, select the Password check box, in the User ID box, type

GOSALES, and then in the Password and Confirm password boxes, type Education1.

• Click Test the connection, and then click Test. The View the results - Test the connection page appears indicating that the test succeeded.

• Click Close, and then click Close again. • Click Finish, and then click Close.

A new data source called GOSALES2, through which you will import metadata, now appears in the list. You will now take a moment to view this data source in IBM Cognos Analytics. Leave the Metadata Wizard dialog open.

• Open Google Chrome and sign in to IBM Cognos Analytics (http://localhost:9300/bi/) as admin/Education1.




• On the Side panel, click Manage, click Administration console, and then click the Configuration tab. The GOSALES2 data source appears in the list. You could have also created the data source here rather than through Framework Manager. If you need to edit the data source connection, you will need to do it in this location.

• Log off of the Administration tab, and then close the web browser, closing all tabs.

Import metadata. • From the Wizard in Framework Manager, ensure the newly created GOSALES2

data source is selected in the Metadata Wizard, and then click Next. • Under GOSALES2, expand GOSALES > Tables. • Select the following initial tables:

• ORDER_DETAILS • ORDER_HEADER • ORDER_METHOD • PRODUCT • PRODUCT_LINE • PRODUCT_NAME_LOOKUP • PRODUCT_TYPE

• Click Next, and then using the default settings for the Generate Relationship criteria, click Import. The import process begins, and then a message appears summarizing the seven query subjects and six relationships that were imported.

• Click Finish.




• In the Project Viewer pane, expand the gosales namespace. The results appear as follows:

The namespace now contains a list of data source query subjects, which represent each of the tables that were imported from the relational database.

• Expand the Data Sources folder. This folder now contains the GOSALES2 data source, which you specified during the import. This data source is now associated with the objects you just imported.

• Select the GOSALES2 data source. • In the Properties pane, set the Query Processing property to Limited Local.

This will allow IBM Cognos to process operations locally that are not supported by the data source.




Test basic data access. • In the Project Viewer pane, expand PRODUCT.


Here you see all the query items for this query subject. These query items represent the columns found in the data source table.

• Double-click PRODUCT. The SQL tab shows "Select * from [GOSALES2].PRODUCT". This SQL statement defines the scope of the PRODUCT query subject. It is used to generate your query item list as well as the run time SQL when you create a query using the query items. The [GOSALES2] portion is the name of the data source connection with which the query subject is associated.

• Click the Test tab, and then click Test Sample in the lower-right corner. A section of the results appears similar to the following:

The test sample contains the first 25 records, confirming your access to the data. You can increase or decrease the amount of rows retrieved in the Options located in the lower-right corner. If you want to know how many rows of data there are in the data source table, click Total Rows.




• Click the Query Information tab. This tab displays the full SQL in two formats: the generic Cognos syntax (Cognos SQL) and the syntax specific to the data source (Native SQL). This is the SQL generated at run time and passed to the data source. The SQL generated here is based on the SQL defined on the SQL tab of the data source query subject.

• Click OK.

Change SQL generation settings and specify a function list. • From the Project menu, click Edit Governors.

These properties govern the queries that are generated based on the model. These will be described in more detail later in the course.

• Clear the Use WITH clause when generating SQL check box, and then click OK. You will now specify a function list specific to the data source you are using in this model. These functions are specific to the database vendor and allow authors and modelers to perform advanced tasks with the data sources such as date and string manipulations. Specifying a function set per data source will limit the function sets that are published to IBM Cognos Analytics with a package. By default, all supported function sets are published with a package. Publishing only the required functions sets can reduce the package size and prevent confusion where authors may inadvertently use functions from another data source.

• From the Project menu, click Project Function List. • Select Set function list based on the data source type, and then in the

Function set column, beside GOSALES2, select DB2. The results appear as follows:

Now, by default, only DB2 functions will be published with a package in this project.

• Click OK.




Test multiple query subject data access. • If necessary, in the middle pane, click Diagram. • Close the Properties and Tools panes to view more of the center pane diagram,

and then double-click the gosales box to focus on the gosales namespace.

• Click Fit All . The results appear similar to the following:

This pane displays all of the relationships generated by Framework Manager during import. These relationships allow IBM Cognos to generate the appropriate SQL at run time in order to join query items from the different query subjects. You can adjust the settings of the diagram from the Diagram menu. For example, you can choose to view cardinalities in Merise notation (as seen in the screen capture) or Crowsfeet notation (provides a pictorial representation of the relationship). Take a moment to explore the options.




• In the diagram, Ctrl+click to select the following query items: • PRODUCT_LINE > PRODUCT_LINE_EN • PRODUCT_TYPE > PRODUCT_TYPE_EN • PRODUCT > PRODUCT_NUMBER • ORDER_DETAILS > QUANTITY • ORDER_DETAILS > UNIT_SALE_PRICE

• Right-click one of the selected items, click Test, and then click Test Sample. A sample 25-row report confirms that you can access the data. Note the values for quantity and unit sale price.

• In the upper-right corner of the Test Results dialog box, select Auto Sum, and then click Test Sample again. A section of the results appears similar to the following:

This time, you see that QUANTITY has been summed. UNIT_SALE_PRICE has also been summed, which you will correct later.

• Close the Test Results window, and then save the project.




Create and publish a package. • In the Project Viewer pane, right-click Packages, point to Create, and then click

Package. The Create Package Wizard appears. Since the package will include the full contents of the project, you will give it the same name as the project. Note: To be able to publish packages, a user must belong to the Report Administrators role, or have write privileges to the Team content area of IBM Cognos Analytics.

• In the Name field, type GO Operational, and then click Next. • Expand Foundation Objects View and gosales.


This is where you can restrict the package contents to a subset of your model.




• Click Next. The results appear as follows:

Here you have the option to specify which function sets get published with the package. Since you associated DB2 functions with the GOSALES data source, it is by default, the only function set currently selected.

• Click Finish. A dialog box appears indicating that the package was created successfully, and prompts you to open the Publish Package wizard. Publishing places a package in the IBM Cognos Content Store, where it can be accessed from IBM Cognos Analytics.

• Click Yes. • Clear the Enable model versioning check box, accept the remaining defaults,

and then click Next. • Click Next, and then click Publish.

The package is verified by default before the package is published. Once verified and published, a message appears within the wizard indicating that the package was successfully published.

• Click Finish to close the wizard, and then save the project.




View the package in IBM Cognos Analytics. • In a web browser, navigate to http://localhost:9300/bi/. • Sign in as admin/Education1.

The Welcome to IBM Cognos Analytics page appears. • Click Team content, and then point to GO Operational to expose the More

button. • Click More, and then click Create report. • From the Templates and themes page, select Blank, and then click OK.

• In the work area, click Add , click List, and then click OK to accept the query defaults. In the Source pane, you can see that the GO Operational root namespace and the Foundation Objects View namespace appear. These were the objects you specified in the Publish Package wizard in Framework Manager.

• Expand Foundation Objects View, and then gosales. The query subjects appear and are available to the author to create a report.

Create a report. • In the gosales namespace, expand the PRODUCT_LINE query subject, and then

double-click the PRODUCT_LINE_EN query item. • Repeat the previous step to add the following items:

• PRODUCT_TYPE > PRODUCT_TYPE_EN • PRODUCT > PRODUCT_NUMBER • ORDER_DETAILS > QUANTITY • ORDER_DETAILS > UNIT_SALE_PRICE




• On the Application bar, click Run options, and then click Run HTML. The results appear similar to the following:

You have successfully created the same query that you tested in Framework Manager earlier. Here the values are automatically sorted and summarized (the values in the UNIT_SALE_PRICE column are added up at this point, which explains why they are so high).

• Close the rendered report tab. • Sign out as Admin Person without saving the report. • Leave Framework Manager open for the next activity.




Extend a model Recall from the topic on Modeling strategies that it is recommended to model in stages using an iterative approach. The iteration involves importing metadata, publishing your model, and then testing the model against your business requirements, repeating as necessary until your model reflects the desired metadata. The same iteration, with a little added detail around packages and security, remained a constant as you learned about the Framework Manager workflow process. You iterate through that process as needed to fine tune the model or to match ever-changing business requirements. As you iterate through the process, you will import additional metadata to supplement the existing metadata.

Importing additional metadata You have already imported metadata, so you have used the Import Metadata Wizard. However, now you are adding metadata to the existing metadata. There is an important screen in the wizard where you designate whether the new metadata will relate to the existing metadata, and if so, how it relates. The Import Metadata Wizard can automatically detect relationships that exist at the database level. When importing additional metadata from the same data source or another compatible data source (primary and foreign keys match), select Both in the wizard. This generates relationships among the objects being imported as well as the existing objects in the model. By selecting this option, you will not need to create the relationships manually after import.




Activity: Extend the Framework Manager model Now that you have an understanding of the Framework Manager modeling environment and process, you can extend your model to support additional business requirements from report and ad hoc query authors, namely reporting sales by sales staff location. In this activity, you will accomplish the following: • Import additional metadata • Rearrange the diagram

Import additional metadata. • Ensure you are logged into IBM Cognos Framework Manager as admin

(password is Education1), with the C:\Training\B6252G\Course_Project\GO Operational project open.

• In the Project Viewer pane, expand GO Operational Model > Foundation Objects View.

• Right-click the gosales namespace, and then click Run Metadata Wizard. You will import more items from the GOSALES database.

• Ensure that Data Sources is selected, and then click Next. • Ensure that GOSALES is selected, and then click Next. • In the list of objects, expand GOSALES > Tables, and then select the following

tables: • BRANCH • COUNTRY • SALES_REGION

• Expand GOSALESHR > Tables, and then select the following tables: • EMPLOYEE • EMPLOYEE_HISTORY • POSITION_LOOKUP

• Click Next. • On the Generate Relationships page, select the Both radio button.

You want to generate relationships among the new query subjects as well as between the new and existing query subjects. This will prevent you from having to manually create the relationships after the import.




• Click Import. The import process begins, and then a message appears summarizing the count of objects that were imported.

• Click Finish. The gosales namespace now contains a list of query subjects, which represent each of the tables that were imported from the relational database.

• Expand the Data Sources folder, and then click GOSALES1. The second data source, GOSALES1, was created for the query subjects you selected from the second schema, GOSALESHR.

• If the Properties pane is not open, from the View menu, click Properties to open it.

• In the Properties pane, note that the Schema property is set to GOSALESHR.

Rearrange the diagram. • If the diagram is not currently visible, in the middle pane, click the Diagram link. • From the Diagram menu, click Diagram settings. • Under Level of Details, clear Query Items, and then click OK.

• Ensure Diagram is selected, and then from the toolbar, click Auto Layout . • In the Auto Layout dialog box, beside Layout Style, ensure that Standard is

selected, and then set both Horizontal and Vertical distances to 30.




• Click Apply, and then click Close. The results appear similar to the following:

You can now view all the items imported into your project in a simplified way by reducing the detail and adjusting the space between the objects. If you were importing a star schema structure, you would select the Star option under Layout Style to set fact query subjects as focal points with their related dimensions surrounding them. You will identify and correct any missing relationships later.

• Save and close the project, but leave Framework Manager open.




Prepare reusable metadata Framework Manager workflow: Prepare Metadata phase The Prepare Metadata phase involves verifying and modifying relationships and object properties and customizing metadata for run time. These changes can be made either to the original data source query subjects (in the Foundation Objects View), or to the model query subjects (such as those you might create later in different modeling layers). Changes to the original data source query subjects are reusable. These query subjects may later be used in several different model query subjects, each of which will inherit the same changes. However, if you do not intend for a modification to be universal, then it should be made in the specific model query subjects that require that change.

Verify relationships After you import metadata, whether the first iteration, or a subsequent iteration, you should ensure that your model has all required relationships and that the join cardinality between query subjects meet your needs. • 0..n Zero occurrences to multiple occurrences • 1..n One occurrence to multiple occurrences • 0..1 Zero occurrences to one occurrence • 1..1 Must have one occurrence In Framework Manager, relationships are maintained in the Object Diagram or Context Explorer. When verifying your relationships, you must ensure that the appropriate relationships exist to meet your reporting needs and you must decide if you require optional or mandatory cardinalities. Optional cardinalities require more processing, but may be needed to return the desired results. Remember that optional cardinality is represented by a 0 as seen in the 0..n and 0..1 examples.

Optional versus mandatory cardinality In mandatory cardinality, only rows in which the join condition is met are returned. Mandatory cardinality is represented by a 1 as seen in the 1..n in the following image. For example, in the following example where the product line number (PL#) exists in both tables. The Razors product line is omitted from the record set because PL# value of 2 does not exist in the Product Type table.




This example depicts mandatory cardinality in joins between related tables and provides the final result set based on that cardinality which removes non-matching rows. Optional cardinality is represented by a 0 as indicated in the 0..n in the following example.

This example depicts optional cardinality in joins between related tables and shows the final result set based on that cardinality, which includes non-matching rows.




In this example, with the cardinality set to 0..n on the Product Type table, all rows from the Product Line table are returned since a mandatory match in the Product Line table is not required. The Razors product line now appears in the record set. In this course, you primarily use mandatory cardinalities (inner joins), as they provide better performance. However, if you require optional cardinality (outer join for reporting purposes), you can implement it, and optimize performance in other ways, such as adding filters, to offset the performance impact of outer joins.

Verify query item properties. Framework Manager populates object properties, such as Name, Usage, and Description, during import. When you see a property value that seems questionable, you should ask the database administrator how the item is configured in the database. When you perform the following activity, you should keep the following principles in mind. After import, verify that the metadata represents the business needs. Should the Usage property for Manager_ID = Identifier, Fact, or Attribute? Should the Regular Aggregate property for Unit_Price = SUM? Remember that facts are numeric or time-interval, non-indexed columns. Identifiers are key, index, date, datetime, or any indexed columns. Attributes are typically strings. The Regular Aggregate property for numeric facts (measures) defaults to SUM, which is correct for most measures, such as REVENUE and QUANTITY. However a report identifying four items of various quantities each that were sold to a customer would probably not display the sum of their item prices, but instead the average.




Activity: Verify relationships To meet reporting requirements, you will verify your relationships to ensure none are missing and that the cardinality is set accordingly. In this activity, you will accomplish the following: • Examine relationships • Identify missing relationships • Test relationships

Examine relationships. • In Framework Manager, open the GO Operational project located at

C:\Training\B6252G\CBIFM-Start Files\01_Verify_relationships\GO Operational.

• If prompted, log in as admin/Education1. • In the middle pane, click Diagram, and then double-click the gosales pane to give

it focus in the diagram. • Click the Auto Layout button, and set the horizontal and vertical distance to 25 to

set the distance between objects. • If necessary, from the toolbar set the zoom percentage to 100%, and then scroll

the diagram to view the ORDER_DETAILS and PRODUCT query subjects. • Click the relationship between ORDER_DETAILS and PRODUCT.


The relationship line turns red and the query items used in the join are highlighted, in this case PRODUCT_NUMBER.




• Double-click the relationship line. A section of the results appears as follows:

You can change the query items used in the join, the cardinality settings, the operator, or edit the expression to create a more complex join.




• Click the Relationship SQL tab. A section of the results appears similar to the following:

Here you can view the SQL that is generated to join these two query subjects together and can test the items returned by the join.

• Click Cancel.

• In the lower-right corner of the diagram, click Diagram Overview . Tip: This icon only appears when there is more data than the window can display, both horizontal and vertical. If it is not visible, minimize the screen to the point where horizontal and vertical scroll bars appear.

• On the Diagram Navigation pane, drag the red viewing window to view all parts of the diagram. This feature is useful when dealing with larger models. You can see that all query subjects are linked to at least one other query subject, and that most relationships are one-to-many. You will examine one relationship in detail.

• Close the Diagram Navigation window. It is recommended that you examine each relationship to verify that it is the relationship required for reporting purposes (with the appropriate cardinality) and make note of any missing relationships, where issues might occur, or items may need to be revisited.




Identify missing relationships. • Examine the portion of the diagram below:

EMPLOYEE is joined to EMPLOYEE_HISTORY in a one-to-many relationship, allowing you to report on past positions. You will test this later. BRANCH is also joined to EMPLOYEE_HISTORY in a one-to-many relationship. In this scenario EMPLOYEE_HISTORY is acting as a bridge table in a many-to-many relationship between BRANCH and EMPLOYEE. An employee may have worked in several branches and a branch may have several employees. BRANCH has a relationship to ORDER_HEADER that indicates which branch made a sale. EMPLOYEE does not have a relationship to ORDER_HEADER. In this state, you cannot report on sales by staff, which is one of the requirements. EMPLOYEE needs a relationship to ORDER_HEADER. In speaking with the database modeler, you discover that the relationship between the two objects should be EMPLOYEE.EMPLOYEE_CODE to ORDER_HEADER.SALES_STAFF_CODE. The names are different, but they do in fact represent the same information.

• In the diagram, Ctrl+click EMPLOYEE.EMPLOYEE_CODE and ORDER_HEADER.SALES_STAFF_CODE.




• Right-click one of the selected items, point to Create, and then click Relationship. A section of the results appears as follows:

A relationship with the selected query items is created.

• Under the ORDER_HEADER query subject, set the Cardinality to 1..n. This reflects the fact that each Employee can have one or more Order Headers.




• Click Validate, and then click OK. The results appear similar to the following:

At this point, you are just ensuring that all required relationships are in place. Refining the model for presentation and predictable results will occur later in the modeling process.

Test relationships. You will now test one relationship to help you understand the data, as well as test the new relationship you just created.

• Ctrl+click to select the following query items: • EMPLOYEE > FIRST_NAME • EMPLOYEE > LAST_NAME • EMPLOYEE_HISTORY > RECORD_START_DATE • EMPLOYEE_HISTORY > RECORD_END_DATE • EMPLOYEE_HISTORY > MANAGER • EMPLOYEE_HISTORY > BRANCH_CODE • POSITION_LOOKUP > POSITION_EN

• Right-click one of the selected items, click Test, and then click Test Sample.




• Scroll down until you see the manager named Maria Iacobucci. The results appear similar to the following:

There are two rows of data for Maria because she changed managers (perhaps moving to a different part of the organization, but within the same branch).

• Click Close. You will now test the new relationship between EMPLOYEE and ORDER_HEADER.

• In the diagram, select and Test the following query items: • EMPLOYEE > FIRST_NAME • EMPLOYEE > LAST_NAME • EMPLOYEE > EMPLOYEE_CODE • ORDER_HEADER > SALES_STAFF_CODE • ORDER_DETAILS > QUANTITY




A section of the results will appear similar to the following:

Since the EMPLOYEE_CODE values and SALES_STAFF_CODE values match, you can use Auto Sum to display how many items each employee sold overall.

• Select Auto Sum, and then click Test Sample. A section of the results appears similar to the following:

Quantity is now summed for each employee. The relationship is working as expected. However, notice the SALES_STAFF_CODE value. It seems to have been summed as well. This is because it was set as an integer during import. You will examine and fix this issue in the next activity.

• Click Close, and then save the project as GO Operational.cpf in C:\Training\B6252G\Course_Project.

• Click Yes when prompted to replace the existing project. • Keep Framework Manager open for the next activity.




Activity: Verify and modify query item properties To meet reporting requirements, you will verify that important query item properties, such as Usage and Regular Aggregate, are correct. In this activity, you will accomplish the following: • Verify Usage property settings • Use Bulk Replace to change property settings • Verify Regular Aggregate property settings • Test property changes in Framework Manager

Verify Usage property settings. • Ensure you are logged into IBM Cognos Framework Manager as admin


• If the Properties pane is not currently open, then from the View menu, click Properties to select it.

• In the Project Viewer pane, expand GO Operational Model > Foundation Objects View > gosales > ORDER_HEADER, and then click ORDER_NUMBER.

Both the query item icon and the Usage property field tell you that ORDER_NUMBER is an identifier, and was identified as such during import because this is the primary key in the database table.

• Click SALES_STAFF_CODE. In comparison, SALES_STAFF_CODE has a measure icon (also known as a Fact)

and its Usage property is set to Fact. This was specified during the import because it is a non-indexed numeric field in the database. You know that this query item is not a measure. It is used for associating several employees to an order. You will set this query item's Usage property to Attribute. If you know that any item would be used in relationships or that report authors would filter on an item regularly, you would ask the database administrator to index the field in the database. At that point you would set the Usage property to Identifier. For now, you will set SALES_STAFF_CODE as Attribute to indicate to yourself and other modelers that this integer field is not indexed in the database.




• In the Properties pane, click the Usage property, and then select Attribute from the list. You will now change multiple properties at once to correct other items that Framework Manager incorrectly set as facts.

• Under ORDER_HEADER, Ctrl+click to select the following items: • RETAILER_SITE_CODE • RETAILER_CONTACT_CODE • SALES_BRANCH_CODE

• In the Properties pane, in the RETAILER_SITE_CODE row, scroll to the right, click Fact below the Usage heading, and then select Attribute from the list.

• Drag the small black arrow beneath the value downward to change the values to Attribute for the other two query items.

Use Bulk Replace to change property settings. Rather than go through each query subject and manually change the Usage setting for codes from Fact to Attribute, you can use the Search tool to perform bulk changes.

• If the Tools pane is not currently open, then from the View menu, click Tools. • In the Tools pane, click the Search tab, and then in the Search string box, type

_CODE.

• Beside the Search button, click to see additional search options. • Set the following:

• Class: Query Item • Property: Object Name

• Click Search, and then resize the Tools pane to view the results. You will search a subset of this result set to display only items whose Usage property is set to Fact.

• Select the Subset check box, in the Search string box type fact, and then change the Property selection to Usage.




• Click Search. The results appear as follows:

You will now use the Bulk Replace feature to change the Usage property for these items to Attribute.

• In the lower-right corner, click Bulk Replace. • Set Replace with to Attribute. • Click Replace All, and then click Yes.


All Usage properties are now changed to attribute. Using the Search tool can save a lot of time when performing these types of tasks. However, you should still examine all query items to ensure the settings are correct. For example, BASE_PRODUCT_NUMBER from PRODUCT and EMPLOYEE_HISTORY_PARENT from EMPLOYEE_HISTORY are still identified as facts. The search did not catch these because they did not contain the string _CODE.




Verify Regular Aggregate property settings. • Select and Test the following query items with Auto Sum enabled:

• PRODUCT_LINE > PRODUCT_LINE_EN • PRODUCT_TYPE > PRODUCT_TYPE_EN • PRODUCT > PRODUCT_NUMBER • ORDER_DETAILS > QUANTITY • ORDER_DETAILS > UNIT_SALE_PRICE A section of the results appears similar to the following:

Notice UNIT_SALE_PRICE is summed. This does not meet the reporting requirements. In a report on ORDER_DETAILS rolled up for each product you would expect the QUANTITY to be summed, but it would make no sense to sum up the UNIT_SALE_PRICE (the sale price for one unit of each product in the order), since you may have sold several units in one order detail. You will change this aggregation to default to something more useful, in this case Average. The same situation applies to UNIT_COST and UNIT_PRICE. (Later in the course, you will create a Revenue calculation, QUANTITY * UNIT_SALE_PRICE.)

• Click Close, and then in the Project Viewer pane, under ORDER_DETAILS, select the following items: • UNIT_COST • UNIT_PRICE • UNIT_SALE_PRICE




• In the Properties pane, change the Regular Aggregate property values to Average for all the items. The results appear as follows:

You will change the format for these objects to $USD Currency.

• In the UNIT_COST row, under Format, click <Click to edit.>. • Under Format type, select Currency, and then in the Properties pane, set

Currency to $ (USD) - United States of America, dollar. • Click OK, and under Format, drag the small black arrow down to change the

property setting for the other two items. • Click OK to close the confirmation message.


• Save the project.




Test property changes in Framework Manager. • Select and Test the following query items, with Auto Sum enabled:

• PRODUCT_LINE > PRODUCT_LINE_EN • PRODUCTY_TYPE > PRODUCT_TYPE_EN • PRODUCT > PRODUCT_NUMBER • ORDER_DETAILS > QUANTITY • ORDER_DETAILS > UNIT_SALE_PRICE The results appear as follows:

QUANTITY has been summed while UNIT_SALE_PRICE has been averaged. This is based on the property setting you specified earlier.

• Click Close, and then close all open windows.




Identify query issues Prior to modeling the metadata, you should consider identifying potential reporting issues.

Single fact queries A single-fact query consists of one or more measures from the same fact table.

The diagram presents a star schema with a Sales Fact table in the center, surrounded by Retailer, Staff, Product, and Time Dimensions. In this example, if you only queried items from the dimensions, such as Product and Retailer, your query would go through the fact table. Performance may be an issue if the fact table is very large. This is something to be aware of when viewing the generated SQL and considering performance for those types of queries. If you use optional cardinalities, the full outer joins ensure that all data is returned, not just where matches occur. For example, if you wanted to see all sales, regardless of whether a sales rep made the sale, and see all sales reps, regardless of whether they made sales or not, you would set optional cardinality on both Staff Dimension and Sales Fact. This would generate a full outer join, ensuring that all rows are returned from each table. These types of scenarios should be configured with caution as they have the potential to be resource intensive. The measures can be constricted by dimensional attributes taken from related dimension query subjects at the 1..1 end of 1..1 to 1..n relationships. In most cases, single-fact queries are not a problem for reporting and usually generate simple and expected SQL.




Multi-fact queries A multi-fact query consists of one or more measures from multiple fact tables.

The diagram presents four rows of data from two different fact tables, Sales Fact and Returned Items Fact. Two of the rows in each fact table represent identical values in the DAY_DATE and ORDER_METHOD columns. But each fact has two additional rows of data that does not match for those column values. In the diagram, the first two rows have identical DAY_DATE and ORDER_METHOD information, rows three and four do not. Since an inner join in a select statement assumes that the same information exist in both facts, the inner join would only return the first two records. If a filter ORDER_METHOD = 'Web' was added, 0 records would be returned because there is no Web ORDER_METHOD value in the second fact table. Data is lost in this scenario. A full outer join, on the other hand, can break queries into multiple selects, one for each fact table, and then merges the data.

The diagram presents rows of data from the two different fact tables in one report set. All the matching elements have been merged, whereas the unmatched elements have been included with no values in the measure columns that do not apply to those records. In the above example, no data is lost. This is what IBM Cognos Analytics refers to as a stitch query.




This type of data pattern is not exclusive to star schema data sources, it is also found in operational systems. For example, an employee has skills and also has billings. Employee is a conformed dimension that relates to a Skills table as well as a Billings table. To avoid losing any skills or billings related to an employee, the two result sets would be stitched together. This type of query could be further complicated if optional cardinalities (outer joins) were specified. For example, you could have a left outer join on the Sales Fact from the Order Method dimension. This would return order methods that had sales as well as those that did not, which means it would be possible to see null values in both fact fields of the report.

Cardinalities IBM Cognos uses cardinality for aggregation purposes and to identify which query subjects are dimensions and which are facts.

The diagram presents two dimensions EMPLOYEE and ORDER_METHOD joined to the ORDER_HEADER table in a one-to-many fashion, treating the ORDER_HEADER as a fact. Additionally ORDER_HEADER is joined in a one-to-many cardinality to the ORDER_DETAILS table, which causes ORDER_HEADER to be treated as a dimension to the ORDER_DETAILS fact. Typically, facts are found on the 1..n side of a query. The facts found in these tables can then be aggregated if requested by the user. For every generated query, IBM Cognos Analytics identifies each query subject as either a fact or a dimension based on cardinality. Query subjects with only 0..n or 1..n cardinalities attached are identified as facts and query subjects with 0..1 or 1..1 cardinalities attached are identified as dimensions. Query subjects with both types of cardinality have the potential to be ambiguous. This is the case with ORDER_HEADER.




Although query subjects may contain no measures, such as ORDER_HEADER, IBM Cognos Analytics will view them as fact tables based on cardinality. Treating the query subjects on the 1..n side on the cardinality as facts is a logical choice when trying to apply aggregation rules since measures are usually on this end of the cardinality. If they were on the 1..1 side, there would not be very much to aggregate. So, query usage is applied based on which query subjects are used in a query. If all four tables in the example are used in the query, ORDER_HEADER has both 1..1 and 1..n cardinalities attached. Since fact query subjects must have only 1..n or 0..n cardinalities attached, ORDER_HEADER will be treated as a dimension in this scenario. However, if a query included only ORDER_METHOD, EMPLOYEE, and ORDER_HEADER, then since ORDER_HEADER has only 1..n cardinalities attached, it will be treated as a fact.

Stitch queries Stitch Query is an IBM Cognos term. A stitch query uses conformed dimensions to stitch multi-fact queries together with a full outer join. When one or more conformed dimensions are used in a multi-fact query (where query subjects are identified as facts by the IBM Cognos query engine), a stitch query (full outer join) will occur. Conformed dimensions contain the descriptive attributes and corresponding names, meanings, and values that have been agreed to across the enterprise. Conformed dimensions can be used to merge two independent fact queries together, as seen in the multi-fact query report set. It does so without loss of data. No values are lost on either side of the query. Where the facts have the same data in common, both fact cells contain values. Where a fact does not share common data, the fact cells are null. If the data source supports this type of query, the processing will be done at the data source level. If not, the processing will be done on the IBM Cognos Analytics servers.

The diagram presents two entity relationships. In one relationship, a Time dimensions is joined in a one-to-many cardinality with two fact tables: Sales Fact and Sales Target Fact. In the second relationship, an Employee table is joined to two tables in a one-to-one cardinality: Pay and Federal Tax Deduction.




In the first example, Sales Fact and Sales Target Fact have only 1..n cardinality attached and are therefore treated as facts and stitched together in this query. In the second example, Pay and Federal Tax Deduction will not be identified as facts due to cardinality and therefore no stitch query will be performed. In these cases where the facts are at the same level of granularity, you may want to avoid the extra processing of a full outer join and simply configure 1..1 to 1..1 relationships between your dimension and fact query subjects. You must be extremely familiar with your data and the expected results when implementing this type of configuration. Use this approach with caution as there is potential to prevent required stitch queries as the model scales and involves dimensions with different levels of granularity. As a rule, a stitch query is required when you have different levels of granularity between the facts and do not want to lose uncommon rows of data.




Identify reporting traps Two facts with no dimension context When beginning to model for predictable results, you will want to initially identify any reporting traps that exist within your model. A query on two facts with no dimension context is treated as a cross-product join. This brings duplicate data from the two datasets together in one query. Authors can accidentally author these types of queries if you have left textual (dimensional information) items in a fact query subject. For example, if in attempt to query two fact tables Orders and Sales Targets, the Retailer name was a query item in the Sales Targets table, authors might choose this item thinking it also applies to Orders. This can be avoided if textual items are removed from the fact query subjects. Doing so will force authors to use at least one common dimension in the query to join the facts together. Another example of querying two facts with no dimension context might be that you query one fact, a dimension that has dimension context from that fact, and include a second fact that is not related to the first fact, or to the dimension used by the first fact. This type of query may result in the repetition of overall values for the measures from the second fact table.

Generating unwanted query splits Unwanted query splits (full outer joins) occur when query subjects are incorrectly identified as facts. This is especially common when using a lookup table that has a complex join (joins on more than one column) or contains more than one lookup value for each dimension item to be looked up. This scenario is normally resolved by using a filter, but without a filter, it can cause the lookup table to behave as a fact based on cardinality. If you change the cardinality to 1..1 and put a filter in place to ensure that only one value is returned, it will always act as a dimension. This will become clear in the following activity.

Ambiguous joins Ambiguous joins can happen when there is more than one query path to an object that you have included in your query. You need to remove the risk of taking the wrong query path by removing the ambiguity. You can create aliases of the query item with the appropriate relationships to allow report authors to choose the desired path. Query subjects may still have multiple cardinalities attached. This is not necessarily a problem because IBM Cognos understands hierarchy paths. IBM Cognos can traverse the hierarchies and terminate at the actual fact.




You will examine an ambiguous join in the following activity.

Use tools to analyze the model There are a number of Framework Manager tools you can use to help you analyze your model. • Verify Model identifies errors • Model Advisor identifies areas that need review • Model in freehand to identify query issues After you select the conditions and severity for which you want to test, you can use Verify Model to identify the errors and perform automated or manual repairs. After you select the conditions for which you want to test, Model Advisor gives a clear, graphical presentation that summarizes the design issues uncovered and offers links to documentation for evaluating and resolving the issues. Modeling in freehand can help you to identify which query subjects can act as either a fact or a dimension, fact query subjects that include descriptive data, unclear query paths, and groupings of data (which items will be used to create a fact or dimension query subject for presentation to end users?). When modeling in freehand, you should use a diagram printout to identify areas for concern and how you will build your final model. Concentrate on modeling dimensions first, since they are usually easy to identify, more problematic, and can resolve most of the modeling design issues. When modeling in freehand, it is important to have an understanding of the business processes that created the facts. You cannot create a correct model without interaction with functional users and data modelers. Your requirements and understanding of the data should be clear. You will examine some of these tools in a later activity.




Activity: Reference two facts with no dimension context

You want to view the results of a multi-fact queries that initially use no dimension context. You will adjust the multi-fact query to where only one of the facts has dimension context and view the results. Finally, you will examine the solution to these problems by correctly using a conformed dimension in your multi-fact query. In this activity, you will accomplish the following: • Import SALES_TARGET into the gosales namespace • Test a Targets versus Actual Revenue report • Analyze the query in Framework Manager • Attempt a resolution • Correct the query

Import SALES_TARGET into the gosales namespace. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• Open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\02_Reference_two_facts\GO Operational.

• Log in as admin/Education1, if prompted. • In the Project Viewer pane, expand

GO Operational Model > Foundation Objects View. • Right-click the gosales namespace, and then click Run Metadata Wizard.

You will import more items from the GOSALES database. • Click Next twice. • Expand GOSALES > Tables, select SALES_TARGET, and then click Next. • On the Generate Relationships page, select the Both radio button, and then click

Import. • Click Finish.

The gosales namespace now contains the SALES_TARGET query subject.




Test a Targets versus Actual Revenue report. • Publish the GO Operational package (click Yes to close the prompt dialog box, if

necessary). • In Google Chrome, sign in to IBM Cognos Analytics (http://localhost:9300/bi/)

as admin/Education1. • Click Team content, point to GO Operational, click More, and then click Create

report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults. • Expand Foundation Objects View, expand gosales, and then add the following

query items to the list data container: • SALES_TARGET > RETAILER_NAME • SALES_TARGET > SALES_TARGET • ORDER_DETAILS > QUANTITY • ORDER_DETAILS > UNIT_SALE_PRICE You could have taken COMPANY_NAME from RETAILER, but to identify potential areas of unpredictability for authors you will take the company-related information from SALES_TARGET.

• Run the report in HTML. The results appear similar to the following:




The resulting report has the same QUANTITY and UNIT_SALE_PRICE for every row, which is unexpected. To complete the report, you would create a calculation of Quantity multiplied by Unit Sale Price to get Actual Revenue values, but there is no need to continue since an issue has already been found.

• Close the rendered report tab. • On the Application bar, click Admin Person, and then click Sign out without

saving the report.

Analyze the query in Framework Manager. • In Framework Manager, in the middle pane, click Diagram, locate

SALES_TARGET and ORDER_DETAILS. There are no direct relationships between these two query subjects. To see how they are joined in a query, you will recreate the same query in Framework Manager and view the generated SQL.

• In the Project Viewer pane, select and Test the following query items, with Auto Sum enabled: • SALES_TARGET > RETAILER_NAME • SALES_TARGET > SALES_TARGET • ORDER_DETAILS > QUANTITY • ORDER_DETAILS > UNIT_SALE_PRICE

• Click the Query Information tab.




The results appear similar to the following (they may be formatted differently on your screen):

The query has two sub queries (aliased as D2 and D3) that are not joined. The two queries are simply separated by a comma with no join conditions. This is known as a cross-product join. In this case, one query is on all sales targets grouped by retailer name, and the other is on a distinct value for all order quantities and unit sale prices with no grouping. This explains why all the quantities and prices are the same. IBM Cognos does not join the two query structures because they are both facts and there is no conformed (shared) dimension joining them. You will need an alternate source for RETAILER_NAME, so you will try the only other instance of RETAILER_NAME in the project, the one in ORDER_HEADER.

• Click Close.

Attempt a resolution. • Select and Test the following query items, with Auto Sum enabled:

• ORDER_HEADER > RETAILER_NAME • SALES_TARGET > SALES_TARGET • ORDER_DETAILS > QUANTITY • ORDER_DETAILS > UNIT_SALE_PRICE




A section of the results appears similar to the following:

You can now see separate quantities and unit sale prices for each retailer, but the sales targets are now all identical.

• Click the Query Information tab. A section of the results appears similar to the following (the text may be formatted differently):

Once again you have two subqueries that are not joined. However, this time it is sales targets that are not grouped by retailer name. IBM Cognos still does not join the two query subjects because you have not provided a conformed dimension. If you speak with the database administrator, you will find out that COMPANY_NAME in the RETAILER query subject holds the retailer name that can be used between the two fact query subjects. You will try this in the next task.

• Click Close.




Correct the query. • Select and Test the following query items, with Auto Sum enabled:

• RETAILER > COMPANY_NAME • SALES_TARGET > SALES_TARGET • ORDER_DETAILS > QUANTITY • ORDER_DETAILS > UNIT_SALE_PRICE A section of the results appears similar to the following:

You can now see separate targets, quantities, and prices for each retailer. If you were to create this report in IBM Cognos Analytics - Reporting, you would now calculate Actual Revenue to compare against the targets. (You will not do this now in order to continue investigating modeling issues and will create a Revenue calculation in the model later in the course.)




• Click the Query Information tab. The results appear similar to the following (the text may be formatted differently):

There are two sub queries joined by COMPANY_NAME (retailer name) through a full outer join. Again, in this case, a full outer join is expected since you are stitching two separate fact queries together. The query scenarios you just went through support the concept of ensuring descriptive data is retrieved from dimensions and not facts.

• Close the test results window, and then in the Diagram, review the join paths for this query. RETAILER goes through RETAILER_SITE and ORDER_HEADER to get to ORDER_DETAILS, and has a direct relationship with SALES_TARGET.

• Leave Framework Manager open for the next activity.




Activity: Identify unwanted query splits Authors will want to report on the overall quantity of products sold. You will test such a query to identify a possible reporting trap. In this activity, you will accomplish the following: • Create a query to view total quantity sold by product • Examine the objects and their cardinality

Create a query to view total quantity sold by product. • Ensure Framework Manager is open with the C:\Training\B6252G\CBIFM-Start

Files\02_Reference_two_facts\GO Operational project still open from the last activity.

• In the Project Viewer pane, in Foundation Objects View > gosales, select and Test the following query items, with Auto Sum enabled: • PRODUCT_NAME_LOOKUP > PRODUCT_NAME • PRODUCT > PRODUCT_NUMBER • ORDER_DETAILS > QUANTITY In order to return a larger result set, you will alter the options.

• In the lower-right corner, click Options, under Number of results, change the value from 25 to 250, and then click OK. Other options will be covered later in the course.




• Click Test Sample. A section of the results appears similar to the following:

Notice the different language names but the same quantity value for the same product number. PRODUCT_NAME_LOOKUP is a table in the database that contains multiple rows for each product, one for each supported language. Because there are multiple rows, the relationship is currently correct. 1..1 from PRODUCT to 1..n to PRODUCT_NAME_LOOKUP. It is not that this query is incorrect, but it may not be what the author expected. Likely you would want to see one product, in one language, with one summarized QUANTITY value. You will look at the SQL to see what occurred.





Notice the two sub queries that are being joined with a full outer join. One retrieves all the multilingual product names for each product number, and the other, summarizes order quantities for each product number. The two queries are then stitched together. This is an unwanted query split, since the intent in this query is to return one product name per product and show the quantities sold for that product.

• Click Close.

Examine the objects and their cardinality. • In the middle pane, if necessary, click Diagram, and then double-click the gosales

box to give it focus in the diagram. You will increase the level of detail in the diagram to include query items.

• Click the Auto Layout icon, and set the horizontal and vertical distance to 25.




• In the diagram, locate PRODUCT_NAME_LOOKUP, PRODUCT, and ORDER_DETAILS. The results appear similar to the following:

In this scenario, PRODUCT is treated as a dimension (only 1..1 cardinalities attached), and ORDER_DETAILS and PRODUCT_NAME_LOOKUP are treated as facts (only 1..n cardinalities attached). The PRODUCT_NAME_LOOKUP issue will be resolved later by applying a filter and changing the cardinality.





Model virtual star schemas Modify data source query subjects To modify a data source query subject, you should create a model query subject that is based on the data source query subject you wish to modify. When you modify a query subject, it may make the SQL more complex than a simple query subject that is based on a simple, all-inclusive select statement. In this case, Cognos may need to make extra calls to the database for metadata at run time to fulfill the query request. When creating model query subjects with relationships attached, the generated SQL will honor any encapsulated join syntax for that query subject. All other underlying relationships that are not encapsulated, are no longer accessible. Modelers should be aware of this and understand that this is expected behavior to give them a technique in which they can control query paths and obtain consistent and predictable results. Modelers should always review the generated SQL of any query subject to be used in the final business view, especially, if they have modified them. This is so they can determine that IBM Cognos Analytics is generating the SQL they expected to achieve the desired results.

Operational versus reporting databases Reporting databases, or star schemas, generally require less metadata modeling than reporting databases. Operational databases typically require more of a metadata modeling effort in Framework Manager since they are confusing for users to understand and can present several reporting traps. This course focuses on modeling an operational source because it illustrates more modeling scenarios that may apply to any database, both operational and reporting. Star schema databases will likely require much less modeling since they are already designed for reporting. However, not all reporting database designs are immune to design issues and may require some of the very same techniques found in this course.

Model virtual star schemas A common practice in IBM Cognos Framework Manager is to model operational metadata as a virtual star schema in order to control SQL generation and to provide predictable results. You can create model query subjects that are basically views of the data source data at run time by using the technique described in Modify data source query subjects. These views organize and/or control the SQL generation, which helps to provide an easy to use model and predictable results.




When you model an operational or reporting data source as a star schema, you are not changing the underlying, data structure. You are creating a virtual star schema that allows IBM Cognos Analytics to generate the correct SQL for predictable results. Another benefit of virtual star schema models is that they are more flexible, allowing authors to answer a wider range of queries.

Why model as a star schema? Why would you want to model operational data as a star schema? There are several reasons. Because it: • lets you create star schema groupings or packages • is simpler to understand, since there are fewer query subjects • is adaptable and extendable: you can easily add and reuse facts and dimensions • lets you use conformed dimensions and prevent data silos: facts are related to one

another through dimensions The advantage of modeling dimensionally is that the end result is a business view that is organized by subject area. By presenting each subject area in a namespace with the relevant objects, it is easier for a business user to select the appropriate dimensions to go with a particular fact. Also, adding more facts and relevant dimensions can extend the model without affecting the existing metadata presentation. This allows you to easily add another subject area to the model. Some people with a relational database design background may challenge the idea of modeling operational data as a star schema because it generates lots of SQL at the reporting end. This is true, but it is an accepted trade-off to present authors with a structure that ensures that they retrieve the correct data. If you want simpler SQL in the reports without the risk of queries retrieving incorrect data (a risk encountered when you report directly on operational data structures), your only other solution is to physically store the data in a star schema.




Use query subjects, modify relationships, and consolidate metadata using virtual objects Benefits of using model query subjects Model query subjects simply take a copy of the characteristics of the underlying objects on which they are based when they are created. They are independent of the underlying objects and can have their default behaviors changed without affecting the underlying objects. Changes to underlying objects will also not be reflected in the model query subjects. The query engine interprets the model query subject to be a fact or dimension, based on the cardinalities you attach to it. You can use model query subjects to control query paths by using model query subjects as aliases to prevent ambiguous join paths, when multiple potential paths exist. You can also group query items from multiple query subjects to create a simplified business view. For example, you can combine product line, product type and product info into a simplified and more intuitive product dimension. This creates what is known as an as-view behavior. By using model query subjects, you simplify the model for presentation. Using query subjects lets you override relationship settings for underlying query subjects if you need to. It also gives you the power to resolve recursive relationships by creating an alias of a query subject and then relating it back to itself. You should be aware that after implementing a relationship, you cannot simply rely on underlying relationships to other query subjects. At that point you must implement all relationships required for queries with that model query subject. You will examine some of these benefits in the next few sections.




Use model query subjects to override relationships

The diagram shows how data source relationships can be overridden using model query subjects. It presents two entity relationships. On the left, a data source table, EMPLOYEE, is joined to another data source table, SALES_TARGET_FACT, in a mandatory one-to-many relationship. On the right, a model query subject, Employee, which is based on the data source table EMPLOYEE, is joined to a model query subject Sales Target Fact, based on the data source table SALES_TARGET_FACT in an optional one-to-many relationship. Using model query subjects, you can override underlying relationships to meet alternate reporting requirements. In the diagram example, authors would like to report only on employees who have sales targets. The data source query subjects' relationship meets this requirement because they have an inner join. But for other authors who would like to report on all employees regardless of whether they have sales targets or not, they can use the model query subjects to accomplish this since the cardinality has been changes to optional on the Sales Target Fact side. Again, once you begin attaching relationships to model query subjects, you will need to create all required relationships for the query subject to meet your reporting needs. For example, if Sales Target Fact in the diagram example will be queried with Time, then a relationship to Time would need to be created. The IBM Cognos query engine would not go back down to the data source query subject level to try and use the original relationship between SALES_TARGET_FACT and TIME_DIMENSION.




Use model query subjects as views

The diagram presents entity relationships. The join from the PRODUCT dimension to the ORDER_DETAILS fact is one-to-many. The join from the EMPLOYEE dimension to the ORDER_HEADER is one-to-many. There is also a one-to-many join between two facts ORDER_HEADER to ORDER_DETAILS, which causes the usage of ORDER_HEADER to be ambiguous. Is it to be treated as a fact, or a dimension? In the example, because of the mix of cardinalities, the query engine could identify ORDER_HEADER as either a fact or a dimension, depending on the query in which it is used. To remove this ambiguity, you can merge ORDER_HEADER and ORDER_DETAILS into a model query subject, keeping only required query items. By merging ORDER_HEADER and ORDER_DETAILS and maintaining existing relationships, you create an as-view behavior in which the underlying join between them is always honored. In this way, these two query subjects will always be treated as one, and in this case, always as a fact.




Identify recursive relationships

The example presents a recursive entity relationship. The entity is called SALES_STAFF and the highlighted query items are SALES_STAFF_CODE and MANAGER_CODE. There is a one-to-many recursive relationship drawn from the table to itself that identifies that one MANAGER_CODE query item may be related to many SALES_STAFF_CODE items. The diagram depicts a recursive relationship between SALES_STAFF_CODE and MANAGER_CODE in the same table. Framework Manager displays self-joins in the Diagram view, but does not execute them as queries. You must specify the self-join relationship at the data source level for the recursive relationship to be displayed in Framework Manager. While you can view the metadata that defines the relationship, you cannot edit a recursive relationship in Framework Manager. What if you need to edit that relationship?

Resolve recursive relationships

The example presents the same entity as the previous diagram, SALES_STAFF, with the same recursive relationship on the right side. Only now there is a new query subject called MANAGERS on the left side. The two entities are related with a one-to-many relationship from MANAGERS to SALES_STAFF.




You can use model query subjects (or shortcuts) to create and modify recursive relationships. To modify a relationship that exists as a self-join in the data source, you can create a model query subject or shortcut and define a relationship between it and the original query subject. Using the two query subjects in the diagram example, you can create a master-detail query based on the same table in the data source. Using this solution, you can create a report that lists managers and all staff that report to them. You should know that there is no actual recursive relationship on the database. This example shows a case where it could exist. Framework Manager does not recreate recursive relationships when metadata is imported, even if they actually exist in the database.

Modify relationships Relationship modifications are reflected in the generated SQL. For example, optional cardinality on one end creates a left outer join in the SQL, while optional cardinality on both ends creates a full outer join. You can modify the operator to further define how the objects are related to one another. For example, to ensure that the related query subjects do not return data outside of a posted date, you could define the following relationship: FactTable.FactDate <= SecurityTable.PostedDate You can also use the Expression editor to create complex join conditions. For example, you can extend the join syntax to include additional filter criteria. This lets you create a filter that is only applied when items from both query subjects are used, and leaves the individual query subjects unrestricted in other query scenarios. You will see this in a later activity.

Why consolidate metadata? It is common to consolidate metadata for a number of reasons using alias query subjects and virtual query subjects. A consolidation view of the data can act as an insulation layer between the reports and the data source. By consolidating metadata, you can create a virtual fact where no fact table physically exists at the database level. You can create virtual dimensions to resolve fact-to-fact joins. Consolidating lets you simplify the model in various ways. In a consolidation view, model query subjects are used as containers to multiple query subjects into one for these purposes.




Consolidate metadata The Consolidation View provides a layer of metadata that is separate from the foundation layer that contains all the relationships. To understand query paths, view the Foundation Objects View. To view how metadata will be presented to authors, view objects in the Consolidation View. Consolidating the metadata involves tasks such as consolidating snowflake dimensions into one model query subject, or hiding codes found in fact query subjects, which are used for relationships.

Consolidation example A practical example of metadata consolidation is to consolidate a snowflake dimension into one model query subject that can be used for presentation.

The example diagram displays a snowflake dimension's structure on the left side indicating the structure before metadata consolidation. It features three product dimensional hierarchy tables, PRODUCT, PRODUCT_TYPE, and PRODUCT_LINE. Snowflaked off the PRODUCT table is the PRODUCT_NAME_LOOKUP snowflake dimension. On the right side, depicting the after metadata consolidation view, is only a single Products dimension model query subject.




Create virtual facts When the nature of the data itself does not let you directly report certain measures that you want to view, you will need to use modeling techniques to make that fact data appear directly related to the required dimensions. For example, if you have an Orders fact table to report on sales. However, that fact does not report returned items. Possibly you have a Returned Items table that is related to the Orders table. You may need to create a virtual Sales Returns Fact query subject by using the relationship from Returned Items to your Orders, and then adding the same dimensions, such as Products, used by your Orders table. In this example, since the Returns are related to the Orders, your virtual Sales Returns Fact query subject would require relationships with the same dimensions as your Orders fact. Creating a virtual fact as such as this, gives authors the ability to write logical reports, such as which products were returned, without having to include sales information to get data for returns. To create a virtual fact, you can add the missing context by creating a model query subject with the query items (keys) required to create relationships between the Sales Returns Fact and the required dimensions. The new model query subject behaves like a virtual fact table in a star schema data warehouse. You are simply creating a view that has the required items, and then creating relationships. Keys are hidden so that only facts are visible to authors.

Create virtual dimensions Certain non-fact query items from fact tables can be placed in a model query subject to ensure that they are viewed as coming from a dimension by IBM Cognos. For example, say that ORDER_NUMBER and ORDER_DETAIL_CODE are required for reporting purposes, but they are located in the ORDER_HEADER and ORDER_DETAILS fact tables respectively. By placing these query items in a new model query subject called Order Codes, you create a query subject that acts like a virtual dimension table as seen in a star schema data warehouse. This ensures that the dimensional query items are not missing from the final model presentation. Additionally, this virtual dimension may be able to act as a conformed dimension between two fact tables that share this data.




Activity: Identify ambiguous joins Another common requirement for the business analysts will be to report on sales figures by retailer country. You will test such a query to identify a possible reporting trap. In this activity, you will accomplish the following: • Create the report • Examine the objects and their relationships

Create the report. • Ensure Framework Manager is open with the C:\Training\B6252G\CBIFM-Start

Files\02_Reference_two_facts\GO Operational project still open from the last activity.

• In Foundation Objects View > gosales, select and Test the following query items, with Auto Sum enabled: • COUNTRY > COUNTRY_EN • ORDER_DETAILS > QUANTITY A section of the results appears as follows:

The goal is to create a query for the number of units sold in the country of each retailer. These results seem like they might be correct. But to be sure, you will look at the SQL generated for this query.




• View the SQL on the Query Information tab. The results appear similar to the following (the text may be formatted differently):

The query did not take the path you wanted (through RETAILER_SITE). Instead, it took the path through BRANCH to ORDER_HEADER to ORDER_DETAILS. So the query set returned the number of units sold in each sales branch country.

• Click Close.

Examine the objects and their relationships. You will use a feature called Context Explorer that helps you isolate modeling objects for closer examination and testing. It is a focused subset of the overall diagram. You will first change the default behavior of the Context Explorer to only show objects you select and not all related objects of the items you select.

• From the Diagram menu, click Diagram settings. • Click the Context Diagram tab, select Show only the selected objects, and then

click OK. • In the Project Viewer pane, select the following query subjects:

• COUNTRY • BRANCH • RETAILER_SITE • ORDER_HEADER • ORDER_DETAILS

• Right-click one of the selected objects, and then click Launch Context Explorer.




• Arrange the diagram as shown below:

When a query can take more than one path of equal length and all query subjects are in a single namespace or folder, IBM Cognos chooses the relationship that comes first alphabetically. Using modeling techniques such as alias query subjects, you can avoid all ambiguity. You will apply a solution later in the course.

• Close the Context Explorer. • From the File menu, click Close to close the current project without saving it. • Leave Framework Manager open for the next activity.




Activity: Use model query subjects to resolve ambiguous query paths

You want to review the model to find any ambiguous joins, and use model query subjects to resolve any issues that you identify. In this activity, you will accomplish the following: • Review an ambiguous join reporting trap • Create Region aliases as model query subjects • Create Country aliases as model query subjects • Create relationships • Remove old relationships

Review the ambiguous join reporting trap. • In Framework Manager, open the GO Operational model located at

C:\Training\B6252G\CBIFM-Start Files\03_Use_model_query_subjects\GO Operational.

• Log in as admin/Education1 if prompted. • In the Project Viewer pane, in the gosales namespace (inside GO Operational

Model > Foundation Objects View), right-click COUNTRY, and then click Launch Context Explorer.

• If Context Explorer only displays the COUNTRY table, click

Show Related Objects . • Click the BRANCH table, and then click Show Related Objects. • Click the EMPLOYEE_HISTORY table, and then click Show Related Objects.




• Arrange the diagram similar to the below, to better see the hierarchy structure:

SALES_REGION and COUNTRY have two separate paths that lead to ORDER_HEADER (three if you include the route through EMPLOYEE_HISTORY and EMPLOYEE). To resolve ambiguity, create three aliases of SALES_REGION and COUNTRY, and link each to one of the paths to ORDER_HEADER and ORDER_DETAIL. Keep the original SALES_REGION and COUNTRY to link to SALES_TARGET. Note: You will achieve the following design at the end of this activity:

SALES REGION

COUNTRY

SALES_ TARGET

Retailer Site Region

Retailer Site Country

RETAILER_ SITE

ORDER_ HEADER

Branch Region

Branch Country

BRANCH EMPLOYEE_HISTORY

EMPLOYEE




• Close the Context Explorer.

Create Region aliases as model query subjects. • In the Project Viewer pane, right-click gosales, point to Create, and then click

Query Subject. • Name the query subject Retailer Site Region (alias), and then with Model (Query

Subjects and Query Items) selected, click OK. • Expand Foundation Objects View > gosales > SALES_REGION. • Add the following query items by double-clicking them.

• SALES_REGION_CODE • SALES_REGION_EN This alias could also have been created by expanding SALES_REGION in the Project Viewer pane, selecting the two query items, right-clicking one of them, and clicking Merge in New Query Subject. Both methods have the same results. You will include only the columns your report authors will require. Later in the course, you will replace SALES_REGION_EN with a calculation that dynamically picks up the appropriate language column based on the language setting of the user's computer. You should rename the items to be more user-friendly before you make copies.

• Click OK, and then in the Project Viewer pane, expand the new Retailer Site Region (alias) query subject, and then rename the query items as follows: • Retailer Site Region Code • Retailer Site Region

• Right-click Retailer Site Region (alias), and then click Edit > Copy. • Right-click the gosales namespace, and select Edit > Paste.




• Rename the copy, and its two query items, as follows: • Branch Region (alias) • Branch Region Code • Branch Region The results appear as follows:

Create Country aliases as model query subjects. • Repeat the previous task to create two aliases of COUNTRY as follows:

• Retailer Site Country (alias) • Retailer Site Country Code (from COUNTRY > COUNTRY_CODE) • Retailer Site Region Code

(from SALES_REGION > SALES_REGION_CODE) • Retailer Site Country (from COUNTRY > COUNTRY_EN) • Branch Country (alias) • Branch Country Code • Branch Region Code • Branch Country




• Drag Retailer Site Country (alias) below Retailer Site Region (alias). The results appear as follows (your objects may be in a different order, this is acceptable):

You now have aliases for two of the three relationships between Region/Country and ORDER_HEADER/ORDER_DETAILS. Note: The original SALES_REGION and COUNTRY query subjects will be used for relationships to SALES_TARGET later in the course. You will not rename them now because they are original data source query subjects, not model query subjects.

Create relationships. • In the Project Viewer pane, select the following items:

• Retailer Site Region (alias) > Retailer Site Region Code • Retailer Site Country (alias) > Retailer Site Region Code




• Right-click one of the selected items, point to Create and then click Relationship. The results appear as follows:

You now have a relationship between the two query subjects on a common key with the correct cardinality. Again, using this method, the first object selected will be on the 1..1 side of the relationship. You can modify the cardinality after the fact if it does not meet your needs.

• Under Retailer Site Country (alias), set the Cardinality to 1..n. • Click OK. • Click No when prompted about existing underlying relationships. • Repeat the previous steps to create a relationship from Branch Region (alias)

(1..1) to Branch Country (alias) (1..n) on Branch Region Code. As shown in the diagram in a previous task, you also want to create relationships between the COUNTRY aliases and the query subjects that lead them to ORDER_HEADER, RETAILER_SITE and BRANCH respectively.

• Repeat the previous steps to create the following relationships: • Retailer Site Country (alias) (Retailer Site Country Code, 1..1) to

RETAILER_SITE (RTL_COUNTRY_CODE, 1..n) • Branch Country (alias) (Branch Country Code, 1..1) to

BRANCH (COUNTRY_CODE, 1..n)




Remove old relationships. • Right-click COUNTRY, click Launch Context Explorer, and then click

Show Related Objects. Next, you will remove relationships that are no long required. Specifically, COUNTRY should no longer link to RETAILER_SITE or BRANCH, now that Retailer Site Country (alias) links to RETAILER_SITE and Branch Country (alias) links to BRANCH.

• Delete the relationship between the following items: • COUNTRY and RETAILER_SITE • COUNTRY and BRANCH

• Close Context Explorer. • In the middle pane, click Diagram. • From the Diagram menu, click Diagram settings, under Level of Details, select

the Query Items check box, and then click OK. • In the Diagram, focus on gosales, and then arrange the objects as follows:

SALES_REGION and COUNTRY no longer have ambiguous query paths. There is now a clear path for retailer queries, branch queries and sales target queries.

• Save the project in C:\Training\B6252G\Course_Project folder, overwriting the previous project.





Activity: Create a Sales Fact model query subject To further simplify the model, you will create a Sales Fact model query subject that merges ORDER_HEADER and ORDER_DETAILS into one model query subject. This ensures that the query path through ORDER_HEADER is maintained when reporting on sales facts, and that the query engine correctly interprets the usage. In this activity, you will accomplish the following: • Create a Sales Fact model query subject • Test "As View" behavior • Organize the gosales namespace and reduce model clutter • Test your new virtual star schema query subjects (optional)

Create a Sales Fact model query subject. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In the Project Viewer pane, expand GO Operational Model > Foundation Object view > gosales.

• Ctrl+click ORDER_HEADER and ORDER_DETAILS, right-click one of the selected items, and then click Merge in New Query Subject. You are asked if you would like to recreate existing relationships.

• Click Yes. You want all of the relationships recreated because this is a fact query subject that connects too many dimensional query subjects. You did not want to recreate relationships when creating aliases earlier, because you were specifically creating new relationships to avoid ambiguous query paths. By merging these two objects and maintaining relationships, the query subject will behave as a view and always generate the underlying join between the two query subjects.

• Rename the new model query subject to Sales Fact. • Double-click Sales Fact to open its Query Subject Definition dialog box.




• Right-click each of the following query items, and then click Delete: • RETAILER_NAME • RETAILER_NAME_MB • ORDER_NUMBER1 By deleting the retailer names, you are preventing authors from accessing the incorrect version of the retailer name and inadvertently taking descriptive information from a fact query subject. ORDER_NUMBER1 is a redundant query item merged in from ORDER_DETAILS. You will use ORDER_NUMBER from ORDER_HEADER.

• Click OK to close the Query Subject Definition dialog box, and then rename the following: • QUANTITY to Quantity • UNIT_COST to Unit Cost • UNIT_PRICE to Unit Price • UNIT_SALE_PRICE to Unit Sale Price The results appear similar to the following:

These are the query items that will eventually be used in the Presentation View that your authors will see.




Test "As View" behavior. • Test the Quantity query item, if the window appears blank, click Test Sample, and

then click the Query Information tab. The results appear similar to the following (the text may be formatted differently):

Although you selected an item only associated with ORDER_DETAILS, a join with ORDER_HEADER is honored as shown in the where clause. The two underlying query subjects are now treated as one.

• Click Close. You will now test the behavior of a merged query with no relationships attached.

• In the Project Viewer pane, Ctrl+click to select ORDER_HEADER and ORDER_DETAILS, right-click one of the selected items, and then click Merge in New Query Subject. You are asked if you would like to recreate existing relationships.

• Click No. • Expand ORDER_HEADER_ORDER_DETAILS, test QUANTITY, and then click

the Query Information tab. The results appear similar to the following (the text may be formatted differently):

There is no join with ORDER_HEADER. This new query subject is simply acting as a container for the two underlying query subjects. Since you only queried an item from ORDER_DETAILS, the SQL is minimized and only requests information from that one table in the database.

• Click Close, and then click Undo to remove the new query subject.




Organize the gosales namespace and reduce model clutter. As a convention, you will sort your project objects alphabetically, but place all facts before all dimensions.

• In the Project Viewer pane, right-click the gosales namespace, and then click Reorder.

• Ensure Ascending is selected, and then click OK. • Collapse Sales Fact and then drag it below the gosales namespace, and then

drag SALES_TARGET below Sales Fact. The results appear as follows:

Original data source query subjects that have been replaced by model query subjects (in order to prevent reporting traps) will be placed in a separate folder and non-required relationships will be deleted in order to reduce model clutter. You will do this now for ORDER_HEADER and ORDER_DETAILS.

• Right-click the gosales namespace, point to Create, click Folder, name it Original Sales Objects, and then click Next.




• Expand Foundation Object View > gosales, and then click the ORDER_DETAILS and ORDER_HEADER check boxes to select them. They will change to green check marks.

• Click Finish. • In the Project Viewer pane, expand Original Sales Objects. • Ctrl+click to select ORDER_HEADER and ORDER_DETAILS, right-click one of

the selected items, and then click Launch Context Explorer. • Click Show Related Objects, and then delete all relationships except the one

between ORDER_HEADER and ORDER_DETAILS. The results appear similar to the following:

• Close the Context Explorer. • Save the project.




Test your new virtual star schema query subjects (optional). In a previous activity, there were multiple paths between COUNTRY_EN and QUANTITY, so there was potential for unexpected results. Now authors must explicitly take the country name from either Retailer Country (down one path) or Branch Country (down another path), depending on whether they want the countries of the clients (retailers) or of the sales offices (branches). The results are always expected and predictable.

• Ctrl+click to select the following query items, and then test them with Auto Sum enabled: • Retailer Site Country (alias) > Retailer Site Country Code • Sales Fact > Quantity The goal is to report on the number of units sold to each retailer's country.


Notice the final where clause. The query takes the path you expected, Retailer Country (alias) to RETAILER_SITE to Sales Fact. This query works because the model has no alternative query paths. You have removed any ambiguity. The same concept would apply if you tested Branch Country (alias) and Sales Fact.

• Close the Test Results window, save the project, and then leave Framework Manager open for the next activity.




Activity: Modify relationships You want to modify relationships in your model for two purposes. First, you will resolve a recursive relationship. Next you will create a complex relationship expression. In this activity, you will accomplish the following: • Create an alias to resolve a recursive relationship in the data • Reorganize the query items and test the relationship • View the existing EMPLOYEE_HISTORY filter and move it to a relationship

expression • Create an alias for EMPLOYEE using a model query subject

Create an alias to resolve a recursive relationship in the data. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In GO Operational Model > Foundation Object View > gosales, create a model query subject called Manager.

• From the Foundation Object View > gosales, add the following query items: • EMPLOYEE > EMPLOYEE_CODE • EMPLOYEE > FIRST_NAME • EMPLOYEE > LAST_NAME • EMPLOYEE > WORK_PHONE • EMPLOYEE > EXTENSION • EMPLOYEE > FAX • EMPLOYEE > EMAIL • POSITION_LOOKUP > POSITION_EN




• Click OK, and then create a relationship from Manager (EMPLOYEE_CODE, 1..1) to EMPLOYEE_HISTORY (MANAGER_CODE, 1..n). The results appear as follows:

• Click OK, and then click No to replicating the existing relationships. • Move the Manager model query subject below EMPLOYEE_HISTORY, to more

logically group the items together. • Right-click EMPLOYEE_HISTORY, and then click Launch Context Explorer.

The Context Explorer window appears. • On the toolbar, click the Show Related Objects button.




• Click Auto Layout, ensure the Layout Style is set to Standard, set the distances to 25, and then click Apply. The results appear similar to the following:

The recursive relationship is resolved, and you can use the Manager query subject to return data for managers and their staff. Because POSITION_EN is in the Manager model query subject (which now has a relationship defined) As View behavior will occur. All underlying relationships will be honored in any query that uses the Manager query subject.

• Close the Auto Layout dialog box and the Context Explorer window.




Reorganize the query items and test the relationship. • In Manager, create a Query Item Folder named Codes, and then move

EMPLOYEE_CODE into it. • Rename and organize the query items as follows:

• Change FIRST_NAME to Manager First Name • Change LAST_NAME to Manager Last Name • Change WORK_PHONE to Manager Work Phone • Change EXTENSION to Manager Extension • Change FAX to Manager Fax • Change EMAIL to Manager Email • Change POSITION_EN to Manager Position • Change EMPLOYEE CODE to Manager Code The results appear as follows:




• In the Project Viewer pane, select the following items, and then test them: • EMPLOYEE > FIRST_NAME • EMPLOYEE > LAST_NAME • Manager > Manager First Name • Manager > Manager Last Name The results appear as follows:

• Close the Test Results window.

View the existing EMPLOYEE_HISTORY filter and move it to a relationship expression. • In Foundation Object View > gosales, double-click EMPLOYEE_HISTORY, and

then click the Filters tab. • In the Source column beside New Filter, click the ellipsis.


This is a filter applied on a data source query subject to retrieve only current records for each employee (the one with no End Date assigned).




• Copy the expression in the Expression definition pane, and then click Cancel. • With the filter selected, click Delete, and then click OK.

You will now test the effect of removing the filter. • Select and test the following items:

• EMPLOYEE > EMPLOYEE_CODE • EMPLOYEE > FIRST_NAME • EMPLOYEE > LAST_NAME • EMPLOYEE_HISTORY > EMPLOYEE_HISTORY_CODE • EMPLOYEE_HISTORY > MANAGER The results appear as follows:

Some of the employees, such as those with codes 10016 and 10020, have more than one record. These are their current and historical records. This is the type of data that the human resources staff requires.

• Click Close. • Right-click EMPLOYEE_HISTORY, click Launch Context Explorer, and then

click Show Related Objects. • Double-click the relationship between EMPLOYEE_HISTORY and EMPLOYEE.

The Relationship Definition dialog appears.




• In the lower-right corner, click the ellipsis next to the Expression pane. • At the end of the expression, type and, and then paste the syntax from the filter. • Click OK.


The link between the two query subjects is no longer present since the expression contains non-join specific syntax.

• Click the Relationship SQL tab, and then scroll down to the where clause. The results appear as follows:

The compound expression is reflected in the generated SQL.




• Click the Test button. Multiple records per employee (for example, for 10016 and 10020) no longer exist. This filter is applied when items from both query subjects, or the relationship between them, is used in a query. For example, if you query items from EMPLOYEE_HISTORY and SALES_TARGET_FACT, the EMPLOYEE query subject is in the query path, and therefore the filter will be applied.

• Click OK, and then close the Context Explorer window.

Create an alias for EMPLOYEE using a model query subject. Human Resources need to be able to report on employee data without having historical data restricted.

• In the Project Viewer pane, right-click EMPLOYEE, and then click Merge in New Query Subject.

• Click No to recreating the relationships. • Rename the EMPLOYEE_EMPLOYEE query subject to Employee (Human

Resources). • Create a relationship between Employee (Human Resources) (1..1) and

EMPLOYEE_HISTORY (1..n) on EMPLOYEE_CODE. • Click OK, and then click No when asked to create other underlying relationships. • Select and test the following items:

• Employee (Human Resources) > EMPLOYEE_CODE • Employee (Human Resources) > FIRST_NAME • Employee (Human Resources) > LAST_NAME • EMPLOYEE_HISTORY > EMPLOYEE_HISTORY_CODE • EMPLOYEE_HISTORY > MANAGER





The historical records are now returned when querying between the employee alias query subject and EMPLOYEE_HISTORY and can be leveraged by the human resources staff.

• Click Close, save and close the project, and then close Framework Manager and all other open windows.




Create calculations, filter data, and customize metadata for runtime Create calculations You can add business logic to your model by creating calculations. Creating calculations is a way to provide report authors with values that they regularly use. An example of this might be where report authors regularly report on revenue. The calculation might read REVENUE = QUANTITY * UNIT SALE PRICE. Calculations can use query items, parameters, and functions in their expressions. There are two types of calculations: embedded and stand-alone. If you want to create a calculation specifically for one query subject or dimension, you can embed the calculation directly in that object. For query subjects, this calculation can be done for either data source query subjects or model query subjects. However, it is recommended that you apply calculations in model query subjects wherever possible. This allows for better maintenance and change management. Create a stand-alone calculation when you want to apply the calculation to more than one query subject or dimension. Stand-alone calculations are also valuable if you need to do aggregation before performing the calculation. You can also create stand-alone calculations as an alternate way to present information rather than in a query subject or dimension. If you start with an embedded calculation, you can later convert it into a stand-alone calculation that you can apply to other query subjects.

Filter data As mentioned above, there are two types of filters you can create: embedded and stand-alone. The filter appears in different locations in the Query Subject Definition, depending on which of the two types it is.




The example shows the Filters tab of a Query Subject Definition dialog box. Displayed under the expanded Filters folder are six stand-alone filters. There are two filters displayed in the Filters pane along with their Usage settings. One is an embedded filter, and the other is one of the six stand-alone filters. Embedded filters are appropriate when the filter is intended for just one query subject or dimension. Stand-alone filters are appropriate when required in multiple query subjects or dimensions, or to make commonly used filters readily available for authors. Filters have a Usage setting with the following options: • Always - the filter will always be applied, regardless of whether the filtered query

item is in the query or not • Optional - users may choose to enter a filter value or leave it blank (only applies to

filters that use a prompt value or macro) • Design Mode Only - limits the amount of data that is retrieved when testing in

Framework Manager or when authoring reports You can also restrict the data that a query retrieves by adding a WHERE clause to the SQL definition, or by setting governors.

Parameters and macros Parameters and macros can be used to dynamically return data from specific columns or rows, and even from specific data sources. You can modify query subjects to dynamically control the data returned using session parameters, parameter maps, and macros. An example of why you would do this is to dynamically implement security by using a calculation to retrieve a user's account, group, or role information, and then implement row-level security based on values stored in the data source. You could also retrieve location specific data for a particular user. For example, if a user works in Mexico, you can use a calculation to return sales values for Mexico by querying the Revenue_Mexico column rather than other columns in the table such as Revenue_Canada or Revenue_Germany. A session parameter returns session information at run time (for example, runLocale or account.UserName). A parameter map is a two-column table that maps a set of keys (source) to a set of substitution values. The keys must be unique, and the table is used to substitute one value for another. A macro is a fragment of code that you can insert within filters, calculations, properties, and so on, that are to be evaluated at run time. Macros are enclosed by the # character.




The example shows a filter expression filtering on a query item where it equals the result of a macro called SecurityLookup. The macro takes as a parameter a session parameter called account.defaultName. There is a parameter map table below the filter expression and a box showing the generated SQL based on all three components working together. The diagram shows the practical use of all three metadata customizing tools: a session parameter, a parameter map, and a macro. In the diagram, the filter expression is filtering the value of a query item called Sales_Staff_Code where it equals the value returned by a macro (SecurityLookup). The macro takes as its argument a session parameter called account.defaultName. Here is how it works. A user named Bart Scott is signed into IBM Cognos. The session parameter, account.defaultName is evaluated and returns the value Bart Scott as an argument to the macro statement. The macro, SecurityLookup, is a function that consults the parameter map for the key, Bart Scott. It is evaluated and the value 60 is returned by the macro to the filter expression, where the generated SQL becomes:

WHERE Sales_Target_Fact.Sales_Staff_Code = 60

These tools comprise a very dynamic and elegant way of customizing metadata at runtime.




Activity: Create embedded calculations Report authors want to include the revenue, gross profit, and margin of each order in their reports. Therefore, you will create three embedded calculations in the Sales Fact query subject. This will produce three new query items. In this activity, you will accomplish the following: • Create the calculations • Set formatting properties on query items in the Foundation Objects View • Update the Consolidation View Sales Fact query subject and test

Create the calculations. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• Open the GO Operational model located at C:\Training\B6252G\CBIFM-Start Files\04_Create_embedded_calculations\GO Operational.

• Log in as admin/Education1, if prompted. • Expand GO Operational Model > Foundation Objects View > gosales, and then

double-click Sales Fact. The calculations you are about to create could also be placed in the Consolidation View Sales Fact model query subject. However, placing them in the lower level increases opportunities for reuse.

• Click Add in the bottom right corner. • In the Name field, type Revenue, and then in the Available Components pane,

double-click Quantity. • Click the Functions tab, expand Operators, and then double-click the

multiplication operator *. Notice there is a description of the function in the Tips pane.

• Under Available Components, click the Model tab, and then double-click Unit Sale Price. The results appear as follows: [gosales].[Sales Fact].[Quantity] * [gosales].[Sales Fact].[Unit Sale Price]




• Click Validate , then click Test Sample to verify that the calculation works, and then click OK after the test results appear.

• Click Add, and then create and test a Gross Profit calculation using the following expression: [gosales].[Sales Fact].[Revenue] - ([gosales].[Sales Fact].[Quantity] * [gosales].[Sales Fact].[Unit Cost])

Note: Revenue is the calculation you just created. • Click Add, and then create and test a Margin calculation using the following

expression, where Gross Profit and Revenue are the calculations you just created: [gosales].[Sales Fact].[Gross Profit] /[gosales].[Sales Fact].[Revenue] Currently the new calculations appear as attributes because they have not been evaluated yet.

• In the Query Subject Definition window, click Validate, and then click OK. The query subject and its new calculations are evaluated. The results appear as follows:

The new calculations (Revenue, Gross Profit, and Margin) now appear as facts.




Set formatting properties on query items in the Foundation Objects View. • In Foundation Objects View > gosales > Sales Fact, Ctrl+click Revenue and

Gross Profit. • From the View menu, ensure that Properties is selected. • In the Properties pane, for the Revenue query item, click the cell under Format. • Set Format type to Currency, and the Currency property to

$ (USD) - United States of America, dollar.

• Click OK, apply the same formatting to Gross Profit by dragging down the small

black arrow, and then click OK to close the message saying that the properties have been successfully modified.

• In the Project Viewer pane, click Margin, and then change the Format type to Percentage.

• Click OK.

Update the Consolidation View Sales Fact query subject and test. • In Consolidation View, double-click Sales Fact. • Navigate to Foundation Objects View > gosales > Sales Fact, and then drag

Revenue, Gross Profit, and Margin to the right pane.

• Click Revenue, and then click Top to move it to the top of the list.




• Click the Test tab, and then click Test Sample. A section of the results appears as follows:

Notice that the Margin values are equal to Gross Profit divided by Revenue, as expected. If you use auto sum you will not get the expected results for the Margin calculation. This is because the calculation is performed first and then aggregated (in this case summed). For this type of calculation, you need to aggregate first and then perform the calculation. This can only be done with a stand-alone calculation. This technique is covered towards the end of the course.

• Click OK. The results appear as follows in the Project Viewer:

• Save the project in C:\Training\B6252G\Course_Project, overwriting the previous

project file. • Leave Framework Manager open for the next activity.




Activity: Create embedded and stand-alone filters

Employee data includes historical job information that is not required by report authors. Therefore you will restrict EMPLOYEE_HISTORY to each employee's current record. As well, report authors want to be able to restrict retailer data to specific regions. To do this, you will create standalone filters that authors can apply during report creation. In this activity, you will accomplish the following: • Create an embedded filter to retrieve current employee records • Create standalone Retailer Location filters • Test the standalone filters

Create an embedded filter to retrieve current employee records.

To retrieve current employee records, you will filter data by EMPLOYEE_HISTORY.RECORD_END_DATE IS NULL. You will place the filter on EMPLOYEE_HISTORY in the Foundation Objects View (rather than on Staff by Location in the Consolidation View) because the filter causes the relationship between EMPLOYEE and EMPLOYEE_HISTORY to change from one-to-many to one-to-one, and all of your relationships are in the Foundation Objects View. Changing this cardinality also prevents EMPLOYEE_HISTORY from acting as an ambiguous query subject.

• In the Project Viewer pane, expand GO Operational Model > Foundation Objects View > gosales, and then double-click EMPLOYEE_HISTORY. EMPLOYEE_HISTORY can act as a fact in certain query scenarios because of its cardinalities that can cause unwanted query splits.

• Click the Filters tab, click Add, and then in the Name field, type Current Employee History Record.

• In the Available Components pane, double-click RECORD_END_DATE. • Click in the Expression Definition pane at the end of the expression, and then

type IS NULL. Note: Be sure to type IS NULL and not =Null; the difference is subtle, but important. The results appear as follows: [gosales].[EMPLOYEE_HISTORY].[RECORD_END_DATE] IS NULL




• Click OK, click the Test tab, and then click Test Sample. The results are similar to the following:

Only one record for every employee is returned and each has a null RECORD_END_DATE.

• Click OK. • Right-click EMPLOYEE_HISTORY, and then click Launch Context Explorer. • Click Show Related Objects if necessary, and then double-click the relationship

between EMPLOYEE_HISTORY and EMPLOYEE. • Change the EMPLOYEE_HISTORY side to 1..1.

This reflects the impact of the new filter. • Click OK, close the Context Explorer, and then Save the project.

Create standalone Retailer Location filters. • In Foundation Objects View > gosales, right-click SALES_REGION, click Test,

and then click Test Sample. There are five regions as follows: • 710 = Americas • 740 = Asia Pacific • 750 = Northern Europe • 760 = Central Europe • 770 = Southern Europe

• Click Close. • In the Consolidation View, create a new folder called Model Filters, without

selecting any data.




You will create filters in the Consolidation View rather than the Foundation Objects View because the filters you are creating are going to be used in the final presentation view.

• In the new Model Filters folder, create a new folder named Retailer Location Filters, without selecting data.

• Right-click Retailer Location Filters, point to Create, and then click Filter. • In the Name field, type Americas. • In the Available Components pane, under Consolidation View, expand Retailer

by Location > Codes. • Add Retailer Site Region Code to the Expression definition pane, and then type =

710. The results appear as follows: [Consolidation View].[Retailer by Location].[Retailer Site Region Code] = 710

• Click OK. • Repeat the previous steps to create new filters using the appropriate

Retailer Site Region Code. • Asia Pacific: 740 • Northern Europe: 750 • Central Europe: 760 • Southern Europe: 770 Tip: You can also copy the Americas filter and simply edit it to meet your needs. The expression for Asia Pacific will appear as follows: [Consolidation View].[Retailer by Location].Retailer Site Region Code] = 740 The results appear as follows:





Test the standalone filters. • Publish the GO Operational package (click Yes to close the prompt if necessary). • Open a browser, and then in IBM Cognos Analytics (http://localhost:9300/bi/)

sign in using admin/Education1. • Click Team content, point to the GO Operational package, click More, and then

click Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults. • In the Sources tab, expand Consolidation View > Retailer by Location, and

then drag Retailer Site Country to the report data container. • Expand Model Filters > Retailer Location Filters, and then drag Americas onto

the report. A message indicates that Query1 is now filtered by "Americas".

• Click OK, and then run the report in HTML. The results appear as follows:

The report is limited to records for countries in the Americas.

• Close the rendered report tab. • Sign out as Admin Person without saving it. • Leave Framework Manager open for the next activity.




Activity: Create a language-based calculation Report authors want report consumers to automatically view region names in the language of their locale. To enable this, you will replace Retailer Site Region with a calculation that references a parameter map and a session parameter. You will make this calculation standalone, so that you can reuse it for Branch Region, Staff Region, and Sales Target by Location. In this activity, you will accomplish the following: • Create a parameter map • Create an embedded calculation for multilingual data • Test the calculation under a different language • Make the calculation reusable • Apply the calculation to Branch Region (alias)

Create a parameter map. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In the Project Viewer pane, navigate to Foundation Objects View > gosales, and expand SALES_REGION. This query subject has column-based multilingual data. This lets you select the language in which you want to view the data.

• In Foundation Objects View > gosales, double-click Retailer Site Region (alias). This model query subject was created with just one language query item, SALES_REGION_EN. You want to change this to choose the underlying query item based on a user's locale session parameter at run time. For example, the session locales for United States and France are en-us and fr-fr respectively.

• Click Cancel. You will now create a parameter map to substitute a locale session parameter to a value found in the data.




• Right-click Parameter Maps, point to Create, and then click Parameter Map. You can manually type the values or import them from a file. You can also base the parameter map on existing query items (for example, a table that maps locales to language values in other tables). If so, consider filtering the query subject based on the session parameter you are using to look up the value (for example, runLocale). This reduces the record set to one record, rather than forcing a scan of the entire table at run time. For example, if the value is en-us at run time, the query subject will only return one row consisting of en-us and EN (the key field and the value field) instead of all rows. In other words, you are dynamically reducing the parameter map list to one record before accessing it for a value. For this activity there is no table that contains these mapping values, so you will use a text file that has the mappings entered for you.

• In the Name field, type Language_lookup, and then click Next. • Click Import File. • Navigate to C:\Program Files (x86)\ibm\cognos\c10\webcontent\

samples\models, click Language_lookup.txt, and then click Open. • Click OK.

The values in the file are imported. Note that 'en-us' (and all other English variants) map to 'EN'. The same applies for other languages and their locales.

• Click Finish.

Create an embedded calculation for multilingual data. • In Foundation Objects View > gosales > Retailer Site Region (alias), double-

click Retailer Site Region. • In the Expression definition pane, to the left of

[gosales].[SALES_REGION].[SALES_REGION_EN], type #' • Replace EN] with ' +

The results appear as follows: #'[gosales].[SALES_REGION].[SALES_REGION_' +

• Under Available Components, click the Parameters tab, expand Parameter Maps, and then double-click Language_lookup.




• Collapse Language_lookup, expand Session Parameters, and then double-click runLocale. The runLocale session parameter will convert the string to the language code for the current session user's locale setting (for example, EN), which will be merged with the SALES_REGION_ prefix and the ] suffix to create the desired query item name.

• At the end of the expression, type + ']'# The results appear as follows: #'[gosales].[SALES_REGION].[SALES_REGION_' + $Language_lookup{$runLocale} + ']'#

The # character at the beginning and the end of the expression identify this expression as a macro. This technique hard codes the path to your source query item. If you move or rename the source, you will have to update this calculation manually.

• Click Test Sample to verify that the calculation works for your current locale. The sales regions appear in the lower pane in the language of your locale.

• Click OK. • Save the project.

Test the calculation under a different language. • From the Project menu, point to Languages, and then click

Define Languages. • Select French, click the arrow to add it to the list of Project languages, and then

click OK twice. • If the Tools pane is not displayed, then from the View menu, click Tools. • On the Summary tab, change Active Language to French.

Notice that all object names in the Project Viewer are preceded by (fr). This is to remind you to translate the strings if required.




• In (fr) Foundation Objects View > (fr) gosales, right-click (fr) Retailer Site Region (alias), click Test, and then click Test Sample. The results appear as follows:

The names appear in French based on the macro you created.

• Click Close, and then in the Tools pane, change the Active Language back to English.

Make the calculation reusable. • In Foundation Objects View > gosales, double-click

Retailer Site Region (alias). • In the Query Items and Calculations pane, right-click Retailer Site Region, and

then click Convert to Stand-alone Calculation. • Click OK.

A new Retailer Site Region calculation appears at the bottom of the gosales namespace. You may need to refresh the screen to see the new calculation.

• At the bottom of the gosales namespace, double-click the new Retailer Site Region calculation. The calculation has been preserved.

• Click Cancel. • In Foundation Objects View > gosales, create a folder called

Reusable Objects, without selecting data. • In the Reusable Objects folder, create a folder called Model Calculations without

selecting data. • Drag the Retailer Site Region calculation into the Model Calculations folder.




• Rename the calculation to Region. The results appear as follows:

Apply the calculation to Branch Region (alias). • In the Foundation Objects View > gosales namespace, expand Branch Region

(alias), and then double-click Branch Region. The expression uses the English region column. Rather than recreate the more generic language-based version, you will reuse the Region calculation.

• Delete the expression in the Expression definition pane. • In the Available Components pane, expand

Reusable Objects > Model Calculations, and then double-click Region. • Test the expression, and then click OK. • Repeat the previous steps to apply the Region calculation to the following query

items: • Foundation Objects View > Staff Region (alias) > Staff Region • Consolidation View > Sales Target by Location > Sales Target Region To see if you applied the calculation in all the required locations, you can use the Show Object Dependencies feature.

• In Foundation Objects View > gosales > Reusable Objects > Model Calculations, right-click the Region calculation, and then click Show Object Dependencies.




The Tools pane displays a list of dependent objects (your objects may be listed in a different order):

You can click any of these objects to give them focus in the Project Viewer or Diagram pane. By doing this, you can verify that you applied the calculation in all required areas. You could have placed the calculation directly in the SALES_REGION data source query subject, but calculations in data source query subjects will cause additional queries to the data source for metadata. For some data source vendors this can have a performance impact. This also affects portability of the model and change management.

• Save the project, and then close Framework Manager.




Implement a time dimension and specify determinants Reporting without a time dimension When you do not have a time dimension, you have to use date calculations to create matching values that let you compare data from different areas of the business. This can cause slower performance because it compares data on non-indexed values. When you do not have a time dimension, you have to create an abundance of time calculations to satisfy queries that report on data over time, which is prevalent in most business reporting requirements. A time dimension in an operational model can simplify time-based queries across different facts. In addition, a time dimension can contain the useful hierarchies for yearly calendar and time, as well as those for other types of calendars, such as fiscal or corporate calendars. A time dimension gives you somewhere to put all of those extra date attributes that accompany a date, such as day of the week, day of the year, day name, and so on. Also, when date fields reside in fact tables, the queries cannot be properly stitched together, since there is no conformed dimension.

Implement a time dimension A time dimension provides a conformed dimension that supports time-based queries across facts, either at the same or different levels of granularity. Many organizations data models have various date formats in the fact tables, such as ORDER_DATE or SALES_PERIOD, that make time-based queries between facts difficult. Time dimensions also allow for easy rollups, for example, day-based facts can be rolled up to the month level. You can create a time dimension by using a table with all applicable dates for a time period, ensuring that it includes all required keys, date derivatives, and formats. There are many SQL scripts available on the internet to build time dimensions. You can import the time dimension into Framework Manager and create relationships as necessary. If the fact query subjects do not contain the keys required to relate to the time dimension, speak to the database administrator to see if they can be incorporated. You can also create time keys in Framework Manager using calculations, but this may reduce performance since you are filtering on non-indexed fields.




Resolve multiple ambiguous joins You can use role-playing dimensions to resolve multiple ambiguous joins. Role-playing dimensions used in this case are basically an alias of the time dimension. A table with multiple valid relationships between itself and another table presents a reporting trap. For example, if you have a Sales Fact table containing attributes for ship_date, order_date, and close_date, you then have three possible ways of joining to the Time dimension. You can create additional aliases for the Time dimension and assign each a role. In this case, your aliases might include a Time Dimension (Order Date), a Time Dimension (Ship Date), and a Time Dimension (Close Date). In such a scenario, the relationships would be: • Time Dimension (Order Date).Day Key = Sales Fact.Order Date • Time Dimension (Ship Date).Day Key = Sales Fact.Ship Date • Time Dimension (Close Date.Day Key = Sales Fact.Close Date The three time dimensions are just aliases for the same table, so the Day Key column for all three aliases is the same column. However, it's joined to different columns from the Sales Fact. This ensures that queries will use the correct relationship.

IBM Cognos determinants Now that you have been introduced to a time dimension and the ability to report on multiple facts using a conformed time dimension, you have to consider the time granularity of the fact data. Typically, you use determinants to control granularity when aggregating. They are required for dimensions connected to facts at levels of granularity that have repeating keys. For example, if you are using a time dimension which is at the day grain by nature, yet you are reporting on a fact with measures at the month grain, your join needs to account for 30 to 31 records in that time dimension, all of which contain the month you are interested in. Determinants are how you overcome this.

The example shows a time dimension with a month key and a day key, indicating that there are two levels of granularity. It is joined in a one-to-many relationship to a fact query subject using the month key of the fact. It shows that you can use the time dimension to join to facts at different grains.




As shown in the diagram, a time dimension can have several levels of granularity, for example, year, or month, or day levels. In the time dimension in the example, each unique instance of MONTH_KEY repeats once for every day in the month. If you do not tell IBM Cognos Analytics that MONTH_KEY requires grouping at the month level, your queries will double-count SALES_TARGET for every day of the month. Setting a determinant at each level of granularity avoids any potential instances of double-counting. As stated above, determinants can be specified to allow IBM Cognos Analytics to correctly aggregate facts in queries. Some designers also specify determinants proactively on any query subject with multiple levels of granularity, since you may link a fact at one of those levels of granularity in the future. Determinants are linked to the relationships their keys represent and are only used when the corresponding relationship is used in a query. Determinants on unique data values, such as surrogate keys or dates, can prevent the generation of the distinct clause in the select statement when summarizing the data. Selecting distinct values unnecessarily can reduce performance. If the values are truly unique, then there is no need to scan for distinct values. Querying Binary Large Objects (BLOBs) require additional key and index type information. If this information is not present in the data source, you can add it using determinants. To leverage indexes with DMR (especially when filtering on captions) associating your captions with the correct key in a determinant will improve query generation.




Activity: Implement a time dimension Report authors want to create a business report that compares the Monthly Sales Targets to Actual Sales. In this activity, you will examine whether this goal is easy to accomplish with the current metadata. In this activity, you will accomplish the following: • Examine problems when a time dimension is absent. • Import Time Dimension metadata • Test and adjust TIME_DIMENSION • Build relationships between TIME_DIMENSION and facts • Create the Time model query subject in the Consolidation View • Prepare the model for multilingual data • Publish and test the package

Examine problems when a time dimension is absent. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\05_Implement_a_time_dimension\GO Operational.

• If prompted, log in as admin/Education1. • Publish the GO Operational package without verifying the package (click Yes to

close the prompt, if necessary). • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) using admin/Education1. • Click Team content, point to the GO Operational package, click More, and then

click Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults.




• Expand Foundation Objects View > gosales, and then add the following five items to the list: • Sales Fact > ORDER_DATE • Sales Fact > Revenue • SALES_TARGET > SALES_YEAR • SALES_TARGET > SALES_PERIOD • SALES_TARGET > SALES_TARGET

• Run the report in HTML. A section of the results appears similar to the following:

The year and period (month) from SALES_TARGET do not match those in the ORDER_DATE from Sales Fact. You cannot get expected results without using a time dimension, creating calculations, or modeling complex summary queries that manipulate date fields to tie the data together. For example, you could extract the year and month from ORDER_DATE to match the fields in SALES_TARGET using functions such as: • Year(ORDER_DATE) • Month(ORDER_DATE) You could then sort in ascending order on the two new columns in order to match them to the SALES_YEAR and SALES_PERIOD columns from SALES_TARGET.




However, this cannot be accomplished in IBM Cognos Analytics - Reporting and therefore requires the modeler to create the calculations or restricts these types of calculations to report authors. The results also do not properly stitch the two fact queries because the items used to compare the data do not come from a conformed source.

• Close the rendered report tab. • Sign out as Admin Person, without saving it.

Import Time Dimension metadata. • In Framework Manager, expand GO Operations Model > Foundation Objects

View, right-click gosales, and then click Run Metadata Wizard. • Ensure that Data Sources is selected, and then click Next. • Ensure that GOSALES is selected, and then click Next. • Expand GOSALES > Tables, and then select TIME_DIMENSION. • Click Next, and then click Import. • Click Finish.

Test and adjust TIME_DIMENSION. • Expand gosales, and then drag TIME_DIMENSION below the Staff Region

(alias) query subject, to organize it alphabetically. • Right-click TIME_DIMENSION, and click Launch Context Explorer, and then

click Show Related Objects. TIME_DIMENSION is a generic query subject with no relationships to other query subjects.

• Close Context Explorer. • Right-click TIME_DIMENSION, click Test, and then click Test Sample.

This query subject is simply a calendar breakdown, giving the time over a certain range in multiple formats. It can be used to join two fact tables with different date formats. In this case, TIME_DIMENSION's DAY_DATE matches the format of Sales Fact's ORDER_DATE and TIME_DIMENSION's CURRENT_YEAR and CURRENT_MONTH match SALES_TARGET's SALES_YEAR and SALES_PERIOD.

• Click Close. • If the Properties pane is not visible, then from the View menu, click Properties.




• Expand TIME_DIMENSION, click CURRENT_YEAR, and then in the Properties pane beside Format, click <Click to edit.>.

• Under Format type, select Number, set Use Thousands Separator to No, and then click OK.

• In the Project Viewer pane, select all of the TIME_DIMENSION query items that are identified as facts, and then change the Usage properties from Fact to Attribute. The results appear as follows:

Build relationships between TIME_DIMENSION and facts. • In the Project Viewer pane, in the Foundation Objects View, create the following

relationships: • TIME_DIMENSION (DAY_DATE, 1..1) to

Sales Fact (ORDER_DATE, 1..n) • TIME_DIMENSION (DAY_DATE, 1..1) to

Returns Fact (RETURN_DATE, 1..n) • Create the following relationship, but do not close the Relationship Definition dialog

box: • TIME_DIMENSION (CURRENT_YEAR, 1..1) to

SALES_TARGET (SALES_YEAR, 1..n)




• Click New Link to add a second segment to this two-segment relationship: • TIME_DIMENSION (CURRENT_MONTH, 1..1) to

SALES TARGET (SALES_PERIOD, 1..n) The results appear as follows:

Note the Expression below the linkages: TIME_DIMENSION.CURRENT_YEAR = SALES_TARGET.SALES_YEAR AND TIME_DIMENSION.CURRENT_MONTH = SALES_TARGET.SALES_PERIOD This relationship now consists of two values in TIME_DIMENSION that match time period values in SALES_TARGET. The fields used from the TIME_DIMENSION table, in this scenario, are not indexed in the database. This may affect performance. The ideal situation would be to have a month key in the SALES_TARGET table in the database. This would allow you to create your relationship based on one common indexed key in each table. If this is not an option, you should consider asking the database administrator to index the CURRENT_MONTH and CURRENT_YEAR fields in the TIME_DIMENSION table if performance is an issue.

• Click OK.

Create the Time model query subject in the Consolidation View. • Right-click Consolidation View, point to Create, and then click Query Subject. • Name the query subject Time, and then click OK. • In the Available Model Objects pane, expand Foundation Objects View >

gosales > TIME_DIMENSION.




• Add the following query items by double-clicking them: • CURRENT_YEAR • QUARTER_KEY • CURRENT_QUARTER • MONTH_KEY • CURRENT_MONTH • MONTH_EN • DAY_KEY • DAY_DATE

• Click OK, and then rename the items in the Time query subject as follows: • Change CURRENT_YEAR to Year • Change QUARTER_KEY to Quarter Key • Change CURRENT_QUARTER to Quarter • Change MONTH_KEY to Month Key • Change CURRENT_MONTH to Month (numeric) • Change MONTH_EN to Month • Change DAY_KEY to Day Key • Change DAY_DATE to Date

• Ensure that the items are organized as shown below:

• Drag the Time query subject above the Model Filters folder. • Save the project in C:\Training\B6252G\Course_Project, overwriting the previous

project.




Prepare the model for multilingual data. • Expand GO Operational Model > Foundation Objects View > gosales >

Reusable Objects, right-click Model Calculation, point to Create, and then click Calculation.

• In the Name field, type Month. • In the Available Components box, navigate to Foundation Objects View >

gosales > TIME_DIMENSION, and then drag the MONTH_EN data item into the Expression definition pane.

• In the Expression definition pane, add #' in front of [gosales] and replace EN] with ' + $Language_lookup{$runLocale} + ']'#. The completed expression should read as follows: #'[gosales].[TIME_DIMENSION].[MONTH_'+$Language_lookup

{$runLocale}+']'#

• Click OK, and then save the project.

Publish and test the package. • Publish the GO Operational package without verifying it (click Yes to the prompt if

necessary). • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to GO Operational, click More, and then click

Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults. • Expand Consolidation View, and then add the following data items to the

list data container: • Time > Year • Time > Month (numeric) • Sales Target Fact > Sales Target

• Select the <Year> column body, in the toolbar, click Sort , and then click Ascending.





Monthly sales targets are in the billions, which is too high. Double counting is occurring because there is not enough information specified on the time dimension to roll up values correctly at the month level. Later in this course, you will learn how to specify determinants for the underlying TIME_DIMENSION query subject to resolve this issue.

• Close the rendered report tab. • Save the report as Test Time Dimension to Team content > GO Operational.

Note: It is important that you save this query because it will be used in a subsequent activity. You will now test a multi-fact query using the Time dimension as a conformed dimension.

• From the Side panel, click New , and then click Report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults.

• In the Insertable objects pane, click Add a source , click the GO Operational package, and then click Open.




• Expand the Consolidation View, and then add the following data items to the list data container: • Time > Year • Time > Month (numeric) • Sales Fact > Revenue • Returns Fact > Return Quantity

• Run the report in HTML. A section of the results appears as follows:

This multi-fact query was accomplished using Time as a conformed dimension to stitch the two fact queries together. To verify this, you will look at the report SQL.

• Close the rendered report tab. • At the top of the Properties pane on the right, ensure List is selected (if it is not,

click Select ancestor and then choose List).

• With the entire List selected, in the upper-right corner, click Manage , and then click Show Generated SQL/MDX. The Generated SQL dialog box appears.




• From the list in the right pane that currently reads Native SQL, select IBM Cognos SQL. A section of the results appears as follows:

If you scroll through the SQL, you will see that there are two queries merged together using a full outer join.

• Close the Generated SQL dialog box. • Close IBM Cognos Analytics - Reporting without saving it.

By implementing a Time dimension, you can now easily query across fact query subjects. You also discovered that Sales Target values are not correct, and will correct this later in the modeling process by using determinants.





Activity: Resolve multiple ambiguous joins Report authors require queries based on shipping and closing dates as well as the standard order date. However, while analyzing your model design, you see that this causes multiple relationships between Sales Fact and Time. This means that proper join may not be performed at run time. You will resolve this ambiguity by creating role-playing dimensions for each relationship. In this activity, you will accomplish the following: • Use Model Advisor to identify the issue • Create a role-playing dimension (alias)

Use Model Advisor to identify the issue. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In Foundation Objects View > gosales, right-click Sales Fact, click Launch Context Explorer, and then click Show Related Objects if necessary.

• Double-click the relationship between Sales Fact and TIME_DIMENSION. Note that DAY_DATE is joined to ORDER_DATE. There should also be a relationship to ORDER_CLOSE_DATE and to SHIP_DATE.

• Create two new links between TIME_DIMENSION and Sales Fact: • DAY_DATE (1..1) to ORDER_CLOSE_DATE (1..n) • DAY_DATE (1..1) to SHIP_DATE (1..n)




• Click OK to close the Relationship Definition dialog box. • In Context Explorer, click the relationship between Sales Fact and

TIME_DIMENSION (you may have to click off and then back onto the relationship connector line).

Notice the multiple relationships between Sales Fact and TIME_DIMENSION. You cannot use the relationships in this state and get expected results. There is not enough information for IBM Cognos to select the correct relationship for different queries. Next, you will implement role-playing time dimensions to handle ship dates and close dates.

• Double-click the relationship, and delete the two new relationships on SHIP_DATE and ORDER_CLOSE_DATE (select each one and then press the Delete key).

• Click OK, and then close the Context Explorer.




Create a role-playing dimension (alias). • In Foundation Objects View > gosales, create a new model query subject called

Time (Close), and then click OK. • In the Available Model Objects pane, expand Foundation Objects View >

gosales > TIME_DIMENSION, and then double-click the following query items to add them to the definition: • DAY_DATE • CURRENT_YEAR • QUARTER_KEY • CURRENT_QUARTER • MONTH_KEY • CURRENT_MONTH • MONTH_EN • DAY_KEY

• Click OK, and then drag Time (Close) below TIME_DIMENSION. • In Time (Close), rename the data items as follows:

• Change DAY_DATE to Close Date • Change CURRENT_YEAR to Close Year • Change QUARTER_KEY to Close Quarter Key • Change CURRENT_QUARTER to Close Quarter • Change MONTH_KEY to Close Month Key • Change CURRENT_MONTH to Close Month (numeric) • Change MONTH_EN to Close Month • Change DAY_KEY to Close Day Key

• Create a relationship from Time (Close) (Close Date, 1..1) to Sales Fact (ORDER_CLOSE_DATE, 1..n).

• In the Project Viewer pane, right-click Time (Close), click Edit > Copy, then right-click the gosales namespace, and then click Edit > Paste.




• Rename the copy to Time (Ship), and then rename the data items to: • Ship Date • Ship Year • Ship Quarter Key • Ship Quarter • Ship Month Key • Ship Month (numeric) • Ship Month • Ship Day Key

• Move Time (Ship) below Time (Close), and create the following relationship: • Time (Ship) (Ship Date, 1..1) to Sales Fact (SHIP_DATE, 1..n)

• In the Time (Close) query subject, double-click Close Month, and delete the expression in the Expression definition pane.

• From gosales > Reusable Objects > Model Calculation, add the Month calculation, and then click OK.

• In Time (Ship), double-click Ship Month, replace the existing expression with the Month calculation, and then click OK.

• In the Project Viewer pane, select and test the following query items, with Auto Sum disabled: • Sales Fact > ORDER_NUMBER • TIME_DIMENSION > DAY_DATE • Time (Ship) > Ship Date • Time (Close) > Close Date • Sales Fact > Quantity




A section of the results appears similar to the following (your specific rows may be different):

The ambiguity has been resolved.

• Close Framework Manager, saving if prompted, and then close all other open windows.




Activity: Specify determinants on the time dimension

Report consumers require a report that compares the monthly sales targets to actual sales. In a previous test it was discovered that sales target values are being double-counted. In this activity, you will specify determinants on TIME_DIMENSION and other dimensions to correct this problem. • Review the double-counting issue • Examine the keys and unique values in TIME_DIMENSION • Specify determinants in TIME_DIMENSION • Re-test DAY_DATE • Publish and test the package • Specify determinants to for Product Type & Product • Specify determinants for Retailer & Retailer Site • Run the Products Dimension Test report

Review the double-counting issue. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\06_Specify_determinants\GO Operational.

• If prompted, log in as admin/Education1. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1.




• In IBM Cognos Analytics, navigate to Team content > GO Operational, and then click the Test Time Dimension report you created earlier. A section of the results appears similar to the following:

The monthly sales target values are in the billions, which is too high. This is due to the values being counted once for every day in a month, rather than just once per month. You will specify determinants for the underlying TIME_DIMENSION query subject to resolve this issue.

• From the Application bar, click the down arrow to the right of the report title to open the Currently active report list.

• Click the Close icon to the right of the Test Time Dimension title to close the report.

Examine keys and unique values in TIME_DIMENSION. • In Framework Manager, expand GO Operational Model > Foundation Objects

View > gosales, right-click TIME_DIMENSION, and then click Launch Context Explorer.

• Click Show Related Objects if necessary.




• Click the relationship between TIME_DIMENSION and Sales Fact. The results appear similar to the following:

When you specify determinants, it is good practice to view the relationships to the object and examine the keys used in the relationships. In this case DAY_DATE, not DAY_KEY, relates TIME_DIMENSION to both Sales Fact and Returns fact. This is an important piece of information for your determinant at the day level.

• Click the relationship between TIME_DIMENSION and SALES_TARGET. This relationship is based on CURRENT_YEAR and CURRENT_MONTH. Before applying determinants on TIME_DIMENSION you will also test the effects of having no determinants on a unique value in the data. In this case DAY_DATE is unique.

• Close Context Explorer. • Expand TIME_DIMENSION, and then test the DAY_DATE query item with

Auto Sum enabled.





The distinct clause in the select statement is unnecessary, since the DAY_DATE values in this table are all unique. When you specify determinants, the distinct clause will not be applied when querying DAY_DATE.

• Click Close.

Specify determinants in TIME_DIMENSION. • In the Project Viewer pane, double-click TIME_DIMENSION, and then click the

Determinants tab. The results appear similar to the following:

During import, the primary key value is used to create a determinant for you. This value is unique and therefore all other values in the table can be associated with it. However, the relationships to Sales Fact and Returns Fact use DAY_DATE rather than DAY_KEY. You will alter this determinant to reflect these relationships.




• In the Key pane, select DAY_KEY, and then press Delete. • Under Available items, drag DAY_DATE to the Key pane.

You will now add the remaining determinants. • Under the Determinants pane, click Add.

New Determinant appears below DAY_KEY, in the Determinants pane:

• Right-click New Determinant, and then click Rename. • Type Year, and then press Enter. • Click the Up Arrow key on the right to move Year above DAY_KEY. • From the Available items pane, drag CURRENT_YEAR to the Key pane. • Select the Group By check box to the right of Year. • Repeat the previous steps to create a determinant named Quarter, with the Key

set to QUARTER_KEY, move the determinant up one position, and select Group By.

• With the focus still on Quarter, drag CURRENT_QUARTER into the Attributes box.

• Repeat the previous steps to create a determinant named Month, with two Keys: CURRENT_MONTH and CURRENT_YEAR.

• Move the Month determinant up one position, and select Group By. These query items are used as the key for this determinant because the relationship to SALES_TARGET is based on them. These two fields uniquely identify the relationship to SALES_TARGET and therefore will be used to correctly aggregate sales target values.




• In the Determinants pane, click Month to ensure it is selected, in the Available items pane, use the Ctrl key to select MONTH_KEY and all MONTH_xx items, and then right-click one of the items, and click Add as Attributes. Typically MONTH_KEY would be used as the key for a determinant describing month data values. In this case however, MONTH_KEY is not used in any relationships, and therefore can act as an attribute of the Month determinant, so that it is available if it is used in a report. If you use this key in a relationship in the future, you will need to create a new determinant to represent that relationship. Ideally, you would use a month key exclusively and consistently across all facts that report at the month level. You can request these types of keys from the database administrator if they do not exist.

• Rename the DAY_KEY determinant to Day. The results appear as follows:

• Click OK, and then save the project in C:\Training\B6252G\Course_Project,

overwriting the previous project.




Re-test DAY_DATE. Determinants and relationships work together. If a query uses Date (attribute of the Day determinant) with Revenue from Sales Fact (which is at the day level), Date will not be grouped, since the determinant is specified as unique. However, if you query Month (attribute of the Month determinant) and Sales Target (which is at the month level), the query will be grouped by CURRENT_YEAR and CURRENT_MONTH, as specified by the Month determinant.

• In Project Viewer, ensure GO Operational Model > Foundation Objects View > gosales > TIME_DIMENSION is expanded.

• Under TIME_DIMENSION, test DAY_DATE with Auto Sum enabled, and then click the Query Information tab. The results appear as follows (the text may be formatted differently):

There is no longer a distinct clause in your select statement because the DAY_DATE key is identified as unique; therefore the IBM Cognos query engine will not scan the table for distinct values. If you need another relationship later on using the DAY_KEY, you would also specify a determinant on it and set it as unique. You can have more than one unique determinant if they are truly unique. At query time, the relationship being used will determine which unique determent to use. If more than one relationship to a unique determinant is used, then each related determinant will be used in the query.

• Click Close.

Publish and test the package. • Publish the GO Operational package (click Yes to close the prompt if necessary). • In IBM Cognos Analytics, click Team content > GO Operational, and then click

Test Time Dimension to run the report again.




• If prompted to update the report, click OK. A section of the results appears similar to the following:

You now have accurate sales targets.

• On the Application bar, click Edit (close the confirmation message if necessary).

• From the Side panel, click Insertable Objects to open the Insertable Objects pane.

• Expand the Consolidation View, and then add Time > Date and Sales Fact > Revenue to the report.

• In the report, Ctrl+click the Year and Month (numeric) columns, and then from the

on-demand toolbar, click Group/Ungroup . The results appear as follows:




Although the sales target values repeat (because they are not at the day level) they are not double-counted at the Month grouping level.

• Click the Year column (not the column header), from the on-demand toolbar, click Filter, and then click Edit Filters.

• Click Add, click Advanced, and then click OK. • Create and validate the following expression:

[Year]=2010

Hint: drag Year from the Data items tab. • Click OK, and then OK again to close the Filters dialog box. • Click the Month (numeric) column, and then from the on-demand toolbar, click

Filter, and then click Edit Filters. • Click Add, click Advanced, and then click OK. • Create and validate the following expression:

[Month (numeric)]=1

Hint: drag Month (numeric) from the Data items tab. • Click OK, and then OK again to close the Filters dialog box.


This provides a smaller data set that you can use to conduct your next test. You will now add Product Line from Products to investigate the results.




• From the Sources tab in the Insertable Objects pane, expand Products, and then drag Product Line onto the report after Month (numeric), releasing when a flashing black bar appears. A section of the results appears as follows:

The sales target values are double-counted. You will examine and correct this issue.

• Click the down arrow beside Save, and then click Save as to save the report in Team content > GO Operational as Products Dimension Test, and then close the current report.

Specify determinants for Product Type & Product. Earlier in the modeling process, query subjects were merged together to resolve ambiguous query subjects. PRODUCT_TYPE was merged with PRODUCT to create Product Type & Product, and RETAILER was merged with RETAILER_SITE to create Retailer & Retailer Site. Both these query subjects now contain multiple levels of granularity, and cause double-counting when querying against sales targets. You will resolve this reporting issue by specifying determinants.

• In Framework Manager, navigate to Foundation Objects View > gosales, and then double-click the Product Type & Product query subject. The Query Subject Definition dialog box appears.

• Click the Determinants tab.




• Add the following determinant: • Name: Product • Key: PRODUCT_NUMBER • Uniquely Identified: checked

• Add the following determinant: • Name: Product Type • Key: PRODUCT_TYPE_CODE • Attributes: PRODUCT_LINE_CODE and all PRODUCT_TYPE_xx (all of the

languages) • Group By: checked • Move the Product Type determinant to the top. The results appear as follows:

• Click OK.




Specify determinants for Retailer & Retailer Site. • Under Foundation Objects View > gosales, double-click the Retailer & Retailer

Site query subject, and then click the Determinants tab. • Add the following determinant:

• Name: Retailer Site • Key: RETAILER_SITE_CODE • Uniquely Identified: checked

• Add the following determinant: • Name: Retailer • Key: RETAILER_CODE • Attributes: COMPANY_NAME, COMPANY_NAME_MB,

RETAILER_TYPE_CODE, and RETAILER_START_DATE • Group By: checked • Move the Retailer determinant to the top. The results appear as follows:

• Click OK. • Save the project.




Run the Products Dimension Test report. • Publish the GO Operational package (click Yes to close the prompt if necessary). • In IBM Cognos Analytics (http://localhost:9300/bi/, logged on as

admin/Education1), in Team content > GO Operational, click the Products Dimension Test report to run it. If you are prompted to update the report, click OK. If the report is still open, it may not work as expected due to caching. Simply close the browser, and then try again. A section of the results appears as follows:

As expected, the report did not double-count Sales Target values.

• Sign out as Admin Person without saving it. • Close Framework Manager, saving if prompted, and then close all other open

windows.




Create a presentation view What is a presentation view? A presentation view provides a logical and simplified presentation of metadata for report authors. It groups related model objects together and provides authors with commonly used tools, such as filters and calculations.

Use a presentation view Generally, a consolidation view and a foundation objects view are hidden from report authors. Presentation views often consist of shortcuts to consolidation view model query subjects, arranged in star schema groupings (a fact query subject and all its related dimensions). You can create and publish several packages that are based on the presentation view, each one providing a different view of metadata for different reporting needs. You do not have to model and present as a star schema. For example, if your model is designed to satisfy only a certain set of pre-built reports from which authors cannot stray, then you can model your metadata to that specific end. However, if you are modeling to a broader and largely ad hoc audience, then modeling as a star schema is an excellent choice for achieving predictable results.

Populate a presentation view The Create Star Schema Grouping wizard creates logical groupings of central fact tables and their related dimensions. These groupings consist of shortcuts to the underlying objects and are placed in a namespace so that the same dimension names can occur in other star schema groupings. This allows authors to identify conformed dimensions. As you model, you should document your logical groupings with a dimension map. You can then use the dimension map to quickly create your star schema groupings. The consolidation view normally contains objects which are based on objects in the foundation objects view. The model query subjects are related to each other in the foundation objects view. These objects are then grouped for presentation in the presentation view.




Identify conformed dimensions

This diagram illustrates how you can query two facts, Sales Fact and Sales Target Fact, by using one or all of the conformed dimensions in a presentation view. The dimension shortcuts, in each namespace, have the same name. You must use at least one conformed dimension to report across facts to allow for stitch queries and to ensure that each fact is correctly aggregated. The dimension shortcuts in each namespace of the presentation view should have the same name to indicate they are conformed and point back to the same original query subject. Modelers and authors can quickly identify conformed dimensions in the presentation view based on naming conventions. If designed correctly, dimensions with the exact same name in different namespaces are shared between the facts. Dimensions that are not shared between facts (non-conformed) can still be used in multi-fact queries providing at least one conformed dimension is used.




Activity: Create the presentation view To provide report authors with an intuitive view of the metadata, you will create a presentation view, based on star schema groupings of your relational metadata. You will use a provided dimension map to create these groupings. You will then create a package, publish it, and test it. In this activity, you will accomplish the following: • Use star schema groupings to populate the presentation view. • Make model filters available to report authors • Create and publish a presentation view package • Test the package

Use star schema groupings to populate the presentation view. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\07_Create_presentation_view\GO Operational, logging in as admin/Education1 if prompted.

• In the Project Viewer pane, in the GO Operational Model namespace, create a new namespace called Presentation View, and then drag it above the Consolidation View namespace. The results appear as follows:




• In the Presentation View namespace, create a new namespace called GO Operational Sales (query). The (query) suffix indicates that these objects are relational. For dimensional objects, you will use the suffix (analysis) to indicate that the objects are dimensional. You will populate this new namespace with star schema groupings of your Consolidation View model query subjects.

• In the Consolidation View, Ctrl+click the following query subjects: • Sales Fact • Branch by Location • Order Codes • Order Method • Products • Retailer by Location • Staff by Location • Time • Time (Close) • Time (Ship)

• Right-click one of the selected objects, and then click Create Star Schema Grouping. The Create Star Schema Grouping dialog box appears. The objects that represent tables in a star schema grouping function as shortcuts.

• In the Namespace name field, type Sales (query), and then click OK. • Drag the new namespace into the GO Operational Sales (query) namespace in

the Presentation View.




• Expand Sales (query). The results appear similar to the following:

Note that all the model query subjects are shortcuts to the ones in the Consolidation View. You have simply grouped the ones needed for sales queries in one place. Tip: If the dimensions are not listed alphabetically, you can use the Reorder feature to sort them and then drag Sales Fact to the top for easy access.

• In the Consolidation View, Ctrl+click the following: • Returns Fact • Branch by Location • Order Codes • Order Method • Products • Retailer by Location • Return Reason • Staff by Location • Time

• Right-click one of the selected objects, and then click Create Star Schema Grouping.

• In the Namespace name field, type Returns (query), and then click OK. • Drag Returns (query) into the GO Operational Sales (query) namespace.




• Collapse Sales (query), and then expand Returns (query). The results appear similar to the following:

The conformed dimensions, such as Products and Staff by Location, allow authors to create queries across sales and returns facts. Note: If you encounter any problems with these groupings, check the Foundation Objects View to ensure all the proper relationships are in place and that there are no unresolved reporting traps.

Make model filters available to report authors. You will now make the Retailer Location Filters available in the Presentation View by using a shortcut.

• In the Consolidation View, expand Model Filters, right-click Retailer Location Filters, point to Create, and click Shortcut.

• Drag the shortcut to the GO Operational Sales (query) namespace, and then rename it to Retailer Location Filters.

• Collapse Returns (query). The results appear as follows:




Create and publish a presentation view package. You will create a new package containing just the metadata that was modeled for report authors.

• Right-click Packages, point to Create, and then click Package. • In the Name field, type GO Operational (query), and then click Next. • Click GO Operational Model so that an X appears beside it, and then expand

Presentation View > GO Operational Sales (query). • Click to select all three children of GO Operational Sales (query) as shown below:

• Click Finish.

You are prompted to open the Publish Package wizard. • Click Yes. • Clear the Enable model versioning check box, click Next twice, and then click

Publish. Tip: You can open IBM Cognos Analytics from this dialog in order to quickly view and test your work.

• Click Yes, and then click Finish. The Verify Model dialog box appears listing messages that indicate underlying objects will be published with the package but hidden from authors. This is necessary as IBM Cognos Analytics will require information from these items to properly generate queries.

• Click Close. • Save the project in C:\Training\B6252G\Course_Project, overwriting the previous

project, and then close Framework Manager.




Test the package. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to the GO Operational (query) package, click More,

and then click Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults. • In the Sources tab, expand GO Operational (query) > Sales (query), and then

add Products > Product Line and Sales Fact > Quantity to the report. • Expand Returns (query), and drag Returns Fact > Return Quantity to the report. • Run the report in HTML.


You have created a report that returns data from two facts (Sales Fact and Returns Fact), based on a conformed dimension (Product Line).

• Close the rendered report tab. • Close the report without saving it. • Close all open windows.




Examine data source query subject types and stored procedure query subject types Overview of data source query subjects

In this diagram, the SQL on the left side for the imported RETURNED_ITEM data source query subject is a simple, all-inclusive select statement. If you do not alter this SQL and new columns are added to the table, they will automatically be included when you update the query subject or test it. If you modify the SQL as seen on the right side of the diagram, new columns will need to be added manually in the SQL statement. Sometimes customized SQL is required for a specific application. You can modify the SQL as required, to generate SQL that meets specific needs. You can also implement parameter driven dynamic SQL. However, you should alter the simple select statements as little as possible to generate the most efficient SQL and simplify model maintenance. You should try to have only one instance of a SQL statement per table to reduce future maintenance. This is not always possible, but should be implemented as much as possible.




Set the SQL Type You can set the SQL type for data source query subjects. Available SQL Type settings are: • Cognos • Native • Pass-through At run time, IBM Cognos Analytics generates native SQL that is designed to use the optimizers of the database. It is optimized for database vendor and version, and it leverages the features of databases wherever possible. The SQL Type setting is local to the query subject and impacts how a table-based query is defined and used in query generation. By default, Framework Manager uses Cognos SQL to create and edit query subjects. For more information about changing the SQL Type, see the product documentation. Cognos SQL adheres to SQL standards and is portable. It can contain metadata from multiple data sources and it has fewer database restrictions. Cognos SQL works with all relational and tabular data sources. If you need to port your model from one vendor to another, you should use Cognos SQL since it works with all relational and tabular data sources. It also allows IBM Cognos to generate the most optimized SQL possible, for example, by removing unused elements at query time. If a database does not support a particular function, using Cognos SQL will allow the function to be performed locally if Limited Local processing is allowed. Native SQL allows SQL that is specific to your database. It may not be portable and it cannot contain metadata from multiple data sources. When you edit a query subject, you can specify Native SQL. Native SQL is the SQL the data source uses, such as Oracle SQL. Native SQL lets you use keywords that are not available in Cognos SQL. You can copy and paste SQL from another application into Framework Manager for quick replication of application specific requirements and leverage work already done. When viewing generated Cognos SQL at run-time for a query subject that is set to Native SQL, the native SQL appears as a sub-query contained between {}. IBM Cognos may add statements to the SQL you enter in order to optimize the performance of the query. Pass-through SQL lets you use native SQL without any of the restrictions the data source imposes on sub-queries. There are some databases that do not extend support for all constructs to sub-queries. In these cases, as well as cases where you require constructs that are not supported by the query layer, use Pass-through SQL.




You should use the Pass-through SQL setting with caution as it may have a negative performance impact. With Cognos SQL and Native SQL, when SQL is generated, IBM Cognos may create wrappers for sub-query constructs, and pass the entire construct (wrapper and sub-query) to the database. Some vendors may not support this. Pass-through SQL will tell IBM Cognos to send only the sub-query to the database and then process the remaining SQL construct (wrapper) locally. When viewing Cognos SQL for a query subject that is set to Pass-through SQL, the native SQL that you typed will appear as a sub-query contained between {{}}.

IBM Cognos query generation architecture

The diagram shows how the IBM Cognos user interfaces submit SQL, how the selected SQL type determines how IBM Cognos generates the SQL, and how Pass-through SQL bypasses the IBM Cognos Query Generation to run directly against the data source. Cognos SQL is generated by one layer in the query engine and then passed to another for conversion to native SQL and optimization. The query is then passed to the appropriate database. If you have chosen the Native SQL option, IBM Cognos will send the SQL directly to the optimization layer mentioned above and then on to the appropriate database. Pass-through SQL will simply send the sub-queries of unsupported sub-query constructs directly to the database.




Overview of stored procedure query subjects There are two types of stored procedure query subjects, data query and data modification. Both types can accept arguments. A data query stored procedure returns a single result set based on a simple or complex query. A data modification stored procedure leverages a stored procedure in the data source to modify the data source. If a stored procedure returns multiple result sets, IBM Cognos Analytics only supports the first result set. Framework Manager defines the metadata according to the result set returned by the stored procedure when it is first created. If an existing stored procedure returns a different result set than when it was created, it will cause an error. You can import a stored procedure into Framework Manager by either creating a query subject, or using the Metadata Import Wizard. If you use the Metadata Import Wizard, the query subject will appear to be broken until you verify its projection list. Some data source systems allow for multiple stored procedures with the same name; however each accepts a different number and/or type of argument that determines which stored procedure is used. This is known as an overloaded signature. To work with overloaded signatures, create multiple stored procedures with unique names, and then create a separate query subject for each result set.

Data query stored procedures A data query stored procedure returns data. It must have at least one column, but the data can be a single column or result set of many rows and columns. The exact specifications for creating these stored procedures is outside the scope of this course, and is also database dependent. What you need to know that a data query stored procedure query subject can be treated exactly like a regular query subject, in a tabular fashion. Consider that it may have no rows, one row, or many rows, just like a table. Consider that it may have one column or many columns, just like a table. Once you create a query stored procedure query subject, you can create relationships using that query subject, just like you can a regular query subject. Your own knowledge of the returned data such as column names, unique values, multiple rows, and so on will govern you and influence your cardinalities if you choose to join the stored procedure query subject to other query subjects.




Use prompt values Use prompt values when user input is required for variables beyond the report author’s control. The syntax for using a prompt as a value is ?Prompt Name?. In general, it is better to define prompts in the reporting application to make use of the additional prompt features. However, there are some variables that report authors cannot modify such as parameters in a stored procedure. For these, you can use Framework Manager to define prompts. Prompt values can also be used in: • parameter maps • session parameters • expressions including filters, calculations, and relationships If a stored procedure with an order number parameter returns rows for a specified order, instead of using a hard-coded order number as the argument for the stored procedure query subject, you can use a prompt, such as ?Order Number?. This will allow the end-user to specify which order they want to retrieve information for.

Data modification stored procedures Data modification stored procedures update data sources by adding, updating, or deleting records. If the stored procedures are available in a package, report authors can define conditions that trigger stored procedures to execute. There are some potential limitations to the usage of data modification stored procedures. Many organizations do not allow external applications to update source data. Additionally, database administrators may limit which tables and columns can be modified. IBM Cognos Analytics data sources have two properties that control how report authors can use stored procedure query subjects: • Transaction Access Mode: controls the level of access for each transaction. This

value can be set to either Read-Only, or Read-Write. • Transaction Statement Mode: specifies the action that will occur when the

transaction ends. This value can be set to either: Rollback, Commit, or Autocommit.




Activity: Configure the SQL Type setting in a data source query subject

This activity explores the difference between the SQL that Framework Manager uses to create data source query subjects and the SQL that is generated by query subjects during runtime. You have been asked to provide a query item that returns the current year for use in various reports. To accomplish this, you will use a select construct, and a vendor specific function that requires you to change the SQL Type setting. In this activity, you will accomplish the following: • View the data source query subject SQL • Use a vendor-specific function and configure the SQL Type setting

View data source query subject SQL. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\08_Configure_the_SQL_Type_setting\GO Operational.

• If prompted, log in as admin/Education1. • In the Project Viewer pane, expand

GO Operational Model > Foundation Objects View > gosales. • Double-click SALES_TARGET.

On the SQL tab, notice the simple, all-inclusive select statement shown: Select * from [GOSALES].SALES_TARGET

This statement is written in Cognos SQL. It defines the scope of the query subject and generates run-time SQL when authoring a report or testing query subjects or query items in Framework Manager.

• Click the Test tab, and then in the lower-right corner, click Test Sample. The data is retrieved and displayed in the Test results pane.




• Click the Query Information tab. This tab shows the SQL that the query engine used to retrieve the data in the Test results pane. The SQL is presented in both Cognos SQL and Native SQL as follows (the text may be formatted differently):

The syntax in the From clause of the Cognos SQL contains the following parts:

GOSALES..GOSALES.SALES_TARGET SALES_TARGET

Cognos SQL is an easy-to-read version, while Native SQL represents the SQL that is sent to the database. In both, the SQL selects each column individually, rather than using Select * from SALES_TARGET. This is because the SQL is generated based on the individual query items that make up the query subject. When you test the entire query subject, all query items are included in the query and therefore you see each column in the generated SQL.

• Click Cancel. • Under SALES_TARGET, right-click the SALES_TARGET query item, click Test,

and then click Test Sample.

Projection list

IBM Cognos alias Content Manager datasource

Schema Database table




• Click the Query Information tab. The results appear as follows (the text may be formatted differently):

Because you only selected one query item to test, only one column appears in the generated SQL. All unused items in the scope of the query subject have been dropped during optimization.

• Click Close.

Use a vendor specific function and configure the SQL Type setting. • In the Foundation Objects View, right-click the gosales namespace, point to

Create, and then click Query Subject. • In the Name field, type Current Year, select Data Source (Tables and Columns),

and then click OK. • Under Select a data source, ensure GOSALES is selected, clear the

Run database query subject wizard check box, and then click Finish. • Change the SQL statement to:

Select YEAR(current timestamp) "Current Year" FROM sysibm.sysdummy1




• Click the Test tab.

A message indicates that there is a syntax error near "Year". Cognos SQL expects the From clause to specify a table name. You will use Native SQL to leverage this statement.

• Click OK, and then in the lower-right corner, click Options. • Click the SQL Settings tab, from the SQL Type list, select Native, click OK to the

message, and then click OK. • Click Test Sample.

You have successfully retrieved the current year using a vendor-specific function by using Native SQL.


The native SQL is reflected in the derived table portion of the Cognos SQL between the {} brackets. Derived tables will be discussed in further detail later in this course.

• Click OK, and then save the project in C:\Training\B6252G\Course_Project, overwriting the previous project.




Activity: Create and test a data query stored procedure query subject

Phone representatives at the Sample Outdoors Company call center need an application to help them quickly retrieve information for specific orders. There is a stored procedure in the GOSALES database that can be used to create this application. To do this, you will create and configure a stored procedure query subject. In this activity, you will accomplish the following: • Create a stored procedure query to retrieve data • Edit query item properties and create a relationship • Create a new package for the call center phone representatives • Test the Find Order Information query subject in IBM Cognos Analytics - Reporting

Create a stored procedure query to retrieve data. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In the Project Viewer pane, under GO Operational Model > Foundation Objects View > gosales, create a folder called Stored Procedures, click Next, and then click Finish.

• Right-click the Stored Procedures folder, point to Create, and then click Query Subject.

• In the Name field, type Find Order Information, select Stored Procedure, and then click OK.

• In the Select a data source pane, ensure GOSALES is selected, and then click Next.

• In the Stored Procedures pane, expand GOSALES > Procedures. • Click the FINDORDERINFO stored procedure, and then click Finish.

The Query Subject Definition window for the stored procedure appears. Note: If the stored procedure is missing, navigate to C:\Training\B6252G\Instructor Files, and then double-click B6252G.bat. Once the .bat file finishes running, save the project and begin creating the query subject again. You will now add a prompt value to allow for user input as opposed to hard coding a value for the ORDERNUMBER argument.




• Click the ORDERNUMBER argument, and then click the ellipsis in the Value column.

• In the Value pane, type ?Order Number?. • Click OK, and then click the Test tab.

The Prompt Values dialog box appears. In order to prevent continually being prompted, you will clear the Always prompt for values when testing box.

• Double-click in the Value field, type 100002, and press Enter. • Clear the Always prompt for values when testing check box, and then

click OK. • In the lower-right corner, click Test Sample.


Several records are returned in the Test Results pane with related order information.


Edit query item properties and create a relationship. The stored procedure returns a product number, however a product name would be easier for report consumers to interpret. To enable users to obtain a product name, you will create a relationship between PRODUCT_NAME_LOOKUP and the Find Order Information stored procedure, based on the PRODUCT_NUMBER attribute.

• In the Stored Procedures folder, expand Find Order Information. • Ctrl+click ORDER_NUMBER and PRODUCT_NUMBER, and then in the

Properties pane, change the Usage property for both query items to Identifier. In this case, you know that the underlying fields in the database are indexed and can therefore be set as identifiers instead of attributes.




• In the Project Viewer pane, under Foundation Objects View > gosales, click PRODUCT_NAME_LOOKUP, and then Ctrl+click Find Order Information.

• Right-click either query subject, and then select Create > Relationship. • Define the relationship from PRODUCT_NAME_LOOKUP

(PRODUCT_NUMBER, 1..1) to Find Order Information (PRODUCT_NUMBER, 1..1).

PRODUCT_NAME_LOOKUP will act as a lookup table for Find Order Information to retrieve product name values.

• Click OK, and then save the project. Now that you have a relationship between Find Order Information and PRODUCT_NAME_LOOKUP, you can create a model query subject that retrieves all of the required information for your call center application. You will create a business view for this application.




• In the Project Viewer pane, in the Presentation View namespace, create a new namespace called Call Center Application. The results appear as follows:

• In the Call Center Application namespace, create a new model query subject

called Find Order Information, and then click OK. • In the Available Model Objects pane, expand Foundation Objects View >

gosales > Stored Procedures > Find Order Information. • Add all query items to the Query Items and Calculations pane, except for

PRODUCT_NUMBER. • Expand PRODUCT_NAME_LOOKUP, and then add PRODUCT_NAME to the

Query Items and Calculations pane. • Use the up arrow to move PRODUCT_NAME under RETAILER_NAME. • Click the Test tab, and then in the lower-right corner, click Test Sample.

The order information appears with the appropriate product name, as shown:

• Click OK. • Navigate to Presentation View > Call Center Application > Find Order

Information.




• Expand Find Order Information and rename the query items to mixed case, with no underscores, such as ORDER_NUMBER becomes Order number. The results appear as follows:

If time is short, you can skip renaming the query items because this will be done for you at the start of another activity. This renaming is optional for the purposes of this activity, but it reinforces the value of making objects in the Presentation View user-friendly for reporting.

Create a new package for the call center phone representatives. • In Packages, create a package called GO Call Center that only contains

Presentation View > Call Center Application > Find Order Information. The results appear as follows:

Only the Find Order Information query subject appears with a check mark beside it.

• Click Finish. You are prompted to open the Publish Package wizard.

• Click Yes. • Clear the Enable model versioning check box, and then click Next twice.




• Click Publish, and then click Finish. The Verify Model dialog appears listing warning and informational messages.

• Click Close. • Save the project.

Test the Find Order Information query subject in IBM Cognos Analytics - Reporting. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to GO Call Center, click More, and then click


defaults. • Drag the Find Order Information query subject to the list. • Run the report in HTML.

An Order Number prompt appears. • In the Order Number prompt, type 100004, and then click OK.

A list appears displaying all the records for the requested order number.

• Close the rendered report tab. • Sign out as Admin Person, without saving it. • Leave Framework Manager open for the next activity.




Activity: Create a data modification stored procedure query subject

Report Authors want to automate a process that notifies sales representatives when one of their orders has been returned. To do this, you will create a stored procedure query subject, based on an existing stored procedure in the GOSALES database, which updates columns in the RETURNED_ITEM table. In this activity, you will accomplish the following: • Test the RETURNED_ITEM query subject • Import the stored procedure into the model • Re-test the RETURNED_ITEM query subject The Sample Outdoors Company database contains a data modification stored procedure named ASSIGNSTAFF, which is defined as follows:

This stored procedure updates the RETURNED_ITEM table. It adds the sales staff code to the ASSIGNED_TO column, and then retrieves and adds the system date to the DATE_ADVISED column. It also has two arguments that must be supplied: SALES_STAFF_CODE and ORDER_DETAIL_CODE.




Test the RETURNED_ITEM query subject. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In Foundation Objects View > gosales, expand the Original Sales & Returns Objects folder.

• Test the RETURNED_ITEM query subject. • Scroll to the right if necessary to find the ASSIGNED_TO column.

A section of the results appears as follows

Notice that the ASSIGNED_TO values are null. You will import a stored procedure to update columns in this table and test for the ORDER_DETAIL_CODE value of 4000059; the first row in this table.

• Click Close.

Import the stored procedure into the model. • Right-click the Stored Procedures folder, point to Create, and then click

Query Subject. • In the Name field, type AssignStaff, select Stored Procedure, and then click OK. • In the Select a data source pane, ensure GOSALES is selected, and then click

Next. • In the Stored Procedures pane, expand GOSALES > Procedures, click the

ASSIGNSTAFF stored procedure, and then click Finish. The Query Subject Definition window for the stored procedure appears. You will now add prompt values to allow for user input, as opposed to hard coding values for the expected arguments.

• Click the PARAM_SALES_STAFF_CODE argument, and then click the ellipsis in the Value column.

• In the Value pane, type ?SalesStaffCode?, and then click OK.




• Click the PARAM_ORDER_DETAIL_CODE argument, and then add the following prompt value to the Value column: ?OrderDetailCode?


• Click the Test tab, and then enter the following values:

• Order Detail Code: 4000059 • Sales Staff Code: 572

• Press Enter, and then click OK. An error message appears stating the stored procedure is unable to return a result set:

This is because the stored procedure updates a table and does not retrieve rows from a table. You will modify the definition of this stored procedure query subject to act as a data modification stored procedure query subject.

• Click OK to close the error message, click Cancel when prompted to save your changes, and then click the Definition tab. In the Type list at the top of the window, notice that the current setting is Data Query. With this setting, the stored procedure, when tested, should return a result set.

• Change the Type setting to Data Modification. • Click the Test tab, and then click Test Sample.

A message appears stating the stored procedure executed successfully. • Click OK three times, and then Save the project.




Re-test the RETURNED_ITEM query subject. • In the Original Sales & Returns Objects folder, test the RETURNED_ITEM query

subject. • Scroll to the right if necessary to find the ASSIGNED_TO column.


Notice that the ASSIGNED_TO value in the first row is now 572, the value you provided in the prompt dialog. If you scroll right a little further, you will see that the DATE_ADVISED column has a value for the current date and time. The row for ORDER_DETAIL_CODE 4000059 was successfully updated.

• Click Close. • In Project Viewer, expand Data Sources, and then click GOSALES. • In the Properties pane, set Transaction Access Mode to Read-Write, and then

set Transaction Statement Mode to Commit. • Save and close the project.

This stored procedure can now be added to a package and used by report authors to automate a process that notifies sales representatives when one of their orders has been returned.

• Close all open windows.




Specify data security and package security Overview of IBM Cognos security There are three possible layers of security: • Third-party Authentication: authenticates users and secures objects • Cognos Namespace: uses IBM Cognos groups and roles to secure applications • Capabilities and UI Profiles: grant or deny users access to IBM Cognos

components or features IBM Cognos Analytics can leverage third-party authentication providers to authenticate users. You can use the provider to define and maintain users, groups, and roles. You set up and configure authentication providers in IBM Cognos Configuration. Each authentication provider known to IBM Cognos is referred to as a namespace. IBM Cognos Analytics provides its own namespace called Cognos, which contains groups and roles that define user privileges in the IBM Cognos Analytics environment. The Cognos namespace is not used to authenticate; however, you can use it to enhance your security policies, and ensure the portability of your applications. For example, you can add users and groups from a third-party authentication provider to Cognos namespace groups and roles, in order to secure your application. If you port your application to a different environment, you can continue to use the Cognos groups and roles, and add the appropriate users or groups from the new authentication provider. Since security is optional and anonymous access is allowed in Cognos Analytics, security can be omitted entirely, or combined with anonymous access for open access to specific items. Typically, anonymous users have limited, read-only access. The anonymous authentication process does not require a user to provide logon credentials. The anonymous authentication uses a pre-defined account under which all anonymous users are logged in.




Apply Framework Manager security IBM Cognos Framework Manager lets you control access for selected users, groups, and roles. You can grant or deny access for packages, data, and objects. • Package security: controls which IBM Cognos Analytics users can author or run a

report that uses the package. Users without access to the package can view saved report outputs if they have been granted access to those reports. You can give administrative access to packages for users who are required to republish packages or perform impact analysis based on model changes.

• Data security: restricts the data returned by query subjects, by using a security filter that is applied to the specific users, groups, or roles that require that query subject.

• Object security: restricts access to objects, such as query subjects, query items, and filters.

A user who only has package-level access cannot set properties (including permissions), or edit the entry in IBM Cognos Analytics. These access rights are assigned through IBM Cognos Analytics by a user who has access to package administration features.

Assign permissions IBM Cognos administrators can allow or deny the following permissions: • Read: View entries • Write: Delete entries, create entries in a container (package or folder), and modify

report specifications and output • Execute: Process entries, for example, run a report • Set Policy: View and modify security settings for entries • Traverse: View container contents and properties

Add security in the Publish Wizard The Add Security page lets you add security to a package the first time you publish it. You can add users, groups, or roles to two levels of access: • User Access: Read, Write, Execute, and Traverse permissions • Administrator Access: Read, Write, Set Policy, and Traverse permissions After the initial publish, you can modify package permissions in the Permissions dialog box, which can be accessed in either the IBM Cognos Analytics portal, or from the Framework Manager Action menu.




Specify data security Data security affects authors when they create a report, as well as users when they run a report. To specify data security, first you add the groups and roles that will access the data. Then you specify a security filter for a query subject. If a user does not belong to any of the groups specified in security filters, they will have unrestricted access to the data, regardless of the restrictions specified by the filter expressions. In some cases, you may want to avoid this scenario and completely restrict access to particular groups or roles. To do this, you can create a filter expression that will always resolve to a false outcome, such as: 1=2 or more professionally, [Consolidation View].[Products].[Product Line Code] = 1, where 1 does not exist in the data for Product Line Code. You could then specify the groups or roles to which this filter expression will be applied. The result is that a user who is a member of the defined groups or roles for this filter expression will be denied access to the data, provided they are not members of a group that does have access to the data. The filter expression can incorporate macros, parameter maps, and session parameters. You can base the security filter on existing security filters, in which case the new security filter inherits the existing filter and all its properties. You can also use existing project filters, or create new filters using the Expression Editor.




Activity: Specify package access You want to set up security to control who can access the GO Operational (query) package. You also want to ensure that only System Administrators can administer the package. To do this, you will use the Publish wizard to assign the required permissions to existing Cognos Analytics user groups. You will then test the results in IBM Cognos Analytics by logging in as a system administrator, query user, and report author. In this activity, you will accomplish the following: • Provide administrator privileges to the GO Operational (query) package for system

administrators • Test the package security • Define package permissions in Framework Manager • Test access in IBM Cognos Analytics

Provide administrator privileges to the GO Operational (query) package for system administrators.

Because you can only specify security in the Publish wizard on the first publish of a package, you will first remove the package from the Content Store which will reset the publish history. You can also configure admin access for a package in the package properties.


• Click Team content, point to the GO Operational (query), click More, click Delete, and then click OK.

• From the Start menu, navigate to and expand IBM Cognos Framework Manager.


• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\09_Specify_package_access\GO Operational.

• If prompted, log in as admin/Education1.




• Expand Packages, right-click GO Operational (query), click Publish Packages, and then click Next. You will grant User access to the package for the Authors role, and Administrator access to the System Administrators role.

• In the User Access tab, click Add. Note: If the GO Operational (query) package already existed in IBM Cognos Analytics this button would not be enabled. The Select Users and Groups dialog box appears. This is the same dialog box that is used to add security in IBM Cognos Administration. Framework Manager is simply providing a portal to it. There are two sources to identify security users, groups, and roles: • Cognos: contains Groups and Roles defined within IBM Cognos Analytics. • LDAP: contains Users and Groups defined within the Apache Directory

Authentication Server. • Click Cognos, select the Authors check box, and then click Add (the arrow button

between the two panes). A section of the results appears similar to the following:

• Click OK to close the dialog box (scroll down if necessary). • Click the Administrator Access tab, and then click Add.

• Click Cognos, and then click Last Page . • Select the System Administrators check box, and then click Add (the arrow

button). • Click OK to close the dialog box (scroll down if necessary). • Click Next, and then clear the Verify the package before publishing

check box. • Click Publish, and then click Finish.




Test the package security. The newly published package gives Write permission to Authors, and Custom permissions to System Administrators. You will now sign in as an Author to see the effects of package access security.

• In IBM Cognos Analytics, on the Application bar, click Admin Person, and then click Sign out. You will now sign in as an Author to see the effects of package access security.

• Sign in as brettonf/Education1 (Frank Bretton). • Click Team content, point to GO Operational (query), and then click More.

Notice that Frank has the rights to create a report. • On the Application bar, click Frank Bretton, and then click Sign Out. • Sign in as whites/Education1 (Sally White). • Click Team content.

Notice that the GO Operational (query) package is not visible. This is because Sally White is only a member of the Query Users role, which is not assigned access to this package. Now you will give the Query Users role user access permissions, and then limit the extent of that access.

Define package permissions in Framework Manager. • In Framework Manager, click the GO Operational (query) package. • From the Actions menu, point to Package, and then click Edit Package Settings. • Click the Permissions tab.

You have access to the Permissions tab because you are still logged on as admin within Framework Manager.

• Click Add, and then click Cognos. • Scroll through the pages to locate Query Users, select the Query Users check

box, click the Add button (the arrow button), and then click OK.




• Select the Query Users check box, and then select the Grant check boxes next to Read, Write, and Execute. The results appear similar to the following:

While Read, Write, and Execute permissions have been explicitly granted, Set Policy is only implicitly denied (by not being granted). You will learn more about this distinction later.

• Click OK, and then publish the GO Operational (query) package, clicking Yes to overwrite the existing version, and clicking Close to close the informational messages.

Test access in IBM Cognos Analytics. • In IBM Cognos Analytics, while still logged in as Sally White, refresh the web

browser, and then click Team content. The GO Operational (query) package now appears.

• Point to the GO Operational (query) package, and then click More. Notice that Create report is not available. Sally White, a member of the Query Users role, cannot author reports. By granting Read, Write, and Execute permissions she can view the package but she is not able to create a report.

• Sign out as Sally White. • In Framework Manager, save the project in

C:\Training\B6252G\Course_Project, overwriting the previous project. • Leave Framework Manager open for the next activity.




Activity: Specify data security Sales managers at The Sample Outdoors Company want to ensure that Camping Equipment sales reps only see orders related to the Camping Equipment product line. To do this, you will create and add members to the Sales Managers and Camping Equipment Reps groups. You will then grant these groups access to the GO Operational (query) package. Next, you will apply a security filter to the Products query subject that restricts access to camping equipment data. In this activity, you will accomplish the following: • Grant access to the GO Operational (query) package • Create a security filter for the Product query subject • Publish the package and view the results in IBM Cognos Analytics - Reporting

Grant access to the GO Operational (query) package. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In Project Viewer, ensure Packages is expanded, and then select the GO Operational (query) package.

• From the Actions menu, point to Package, and click Edit Package Settings. • Click the Permissions tab, click Add, and then click Cognos. • Select the Camping Equipment Reps check box, and then click the Add button

(the arrow button between the two panes). • At the top of the left pane, click the Last Page button, select the Sales Manager

check box, and then click the Add button. • Click OK. • Select the Camping Equipment Reps and Sales Manager check boxes.




• Under Grant, select the Read, Write, Execute, and Traverse check boxes. The results appear similar to the following:

• Click OK.

Create a security filter for the Product query subject. • In the Project Viewer pane, expand GO Operational Model > Consolidation

View. • Click Products, and then from the Actions menu, click Specify Data Security. • Click Add Groups. • Click Cognos, select the Camping Equipment Reps check box, and then click

the Add button. • Click OK (scroll down if necessary).

At this point, if you already had another group defined with a filter on camping equipment products, you could click below Based On and specify that other group. In this situation you do not, so you will create a new filter.

• In the first row, click the Filter value, and then select Create/Edit Embedded from the list. The Filter Definition dialog box appears.

• In the Available Components pane, expand GO Operational Model > Consolidation View > Products > Codes.




• Double-click Product Line Code, and then in the Expression definition pane, at the end of the expression, type = 991. The results appear as follows: [Consolidation View].[Products].[Product Line Code] = 991

This filter will ensure that members of the Camping Equipment Reps will only see camping equipment products.

• Click OK twice, and then save the project.

Publish the package and view the results in IBM Cognos Analytics - Reporting. • Publish the GO Operational (query) package, overwriting the existing package

and clicking Close to close the informational messages. • In IBM Cognos Analytics (http://localhost:9300/bi/), sign in as

uragomek/Education1 (Kazumi Uragome). Kazumi Uragome is a member of the Sales Manager group.

• On the Welcome page, click Team content, point to the GO Operational (query) package, click More, and then click Create report.

• From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults. • On the Sources tab, expand Sales (query) > Products, and then double-click

Product Line and Product Type. • Run the report in HTML.

A section of the results appears similar to the following:




Kazumi Uragome can view data for all product lines. He is a member of the Sales Managers group, so the security filter you applied to Camping Equipment Reps does not apply to this group.

• Close the rendered report tab.

• On the Application bar, click Save , click the GO Operational (query) package, in the Save as field, type Security Filter Test, and then click Save.

• Sign out as Kazumi Uragome, and then sign in as admin/Education1. You will now ensure that members of the Camping Equipment Reps group can access this report.

• In the lower-left corner, click Manage, and then click Administration console. • Click the Security tab, and then click Cognos.

• In the Actions column, for the Authors role, click Set properties – Authors , and then click the Members tab.

• Click Add, click Cognos, and then select the Camping Equipment Reps check box.

• Click the Add button, and then click OK. The results appear as follows:




• Click OK, and then close the IBM Cognos Administration tab. • Sign out as the Admin Person user, and then sign in as kunzej/Education1.

Jörg Kunze is a member of the Camping Equipment Reps group. • Click Team content, click the GO Operational (query) package, and then click

Security Filter Test to run the report. The results appear as shown below:

Due to the data security you added to the Product query subject for the Camping Equipment Reps group (of which Jörg Kunze is a member), the report only displays product types from the Camping Equipment product line. Note: If you added Jörg to the Sales Managers group (which can see all product lines), his membership in Camping Equipment Reps would not block him from viewing other product lines.

• Sign out of IBM Cognos Analytics. • Leave Framework Manager open for the next activity.




Specify object security and dynamic data security Secure which objects? Allow or deny access to objects such as: • Namespaces • Folders • Query subjects • Query items • Filters When granting access to objects, ensure that the selected users, groups, or roles have access to the package that contains them. By default, the Everyone group is on the access control list of every object. An example of applying object security is to only allow access to the Sales Targets namespace to the Sales Manager group. Then only members of the Sales Manager group will see the Sales Target namespace in IBM Cognos Analytics. When you publish a package that contains secured objects, the visible objects for IBM Cognos users are the intersection of the package definition and the object security applied to those objects. If you run a report and you do not have access to a query subject or query item referenced in the report, the report will fail. However, you can still view saved report outputs.

Object security rules Some important object security rules to remember are: • If no object security is applied, all objects are accessible • After applying object security, only objects to which access has been granted can

be accessed by the selected users, groups, or roles • Child objects inherit the security of parent objects • Deny overrides Allow When you begin to apply object security (Allow or Deny), all other objects (other than the children of the object on which you specified security) are hidden from users until access is explicitly granted. Only the objects to which access has been explicitly granted for the selected users, groups, or roles, are visible.




When you set object security on a parent object, a child object inherits the security of the parent if object security has not already been specified for the child object. In the case of an access conflict, such as being a member of two groups with conflicting access to an object, denied access to the object overrides granted access to it. For example, to deny access to the Sales Targets query subject for the Sales Reps group, you will have to add the Sales Reps group to the Sales Target query subject's access control list. You must then deny access for the Sales Reps group. As soon as you do this the Sales Reps group will be added to the access control list of every object.

Object security methodologies There are two ways to implement object-based security: • Allow access to all objects, and then restrict access to specific objects • Restrict an object, and then allow access as required You can allow access to all objects, and then restrict access to specific child objects for selected users, groups, or roles. To deny access, you can either explicitly deny access (Deny option) or implicitly deny access by leaving both Allow and Deny options unselected. Deny overrides allow, which ensures that a user does not accidentally gain access to an object through another group or role that has access. Restrict an object, and then allow access as required. Applying initial security to an object that allows specific users, groups or roles access will automatically implement security across the model and make all other objects inaccessible to all users. You can then grant access to specific objects for selected users, groups, or roles as required. If you want to remove all object security from the model, you can double-click the Packages folder in Project Viewer, and delete the Everyone role-based package. This will also remove all other role-based views.




Create dynamic data security

The preceding diagram illustrates an advanced technique for applying security. In this example, a macro is used to look up the current user, a session parameter, in a parameter map and provide an appropriate value for the Where clause of the generated SQL. If the logged in user was Bart Scott in this example, his account.defaultName would be sent to the parameter map, where the value of 60 would be substituted for his user name. Then the Where clause in the generated SQL would evaluate to:

where Sales_fact__employee_secured_.STAFF_KEY = 60

You can use environment session parameters in a macro to create a dynamic data security filter when you want the security to only apply to specific groups. You can also use the macro directly in the query subject, but then the security would be applied to everyone using the query subject rather than specific groups or people. You might do this if, for example, you wanted members of the Sales Managers group to have access to all sales targets and not be restricted. Conversely, you want to restrict members of the Sales Reps group to only have access to their own data and not other sales reps. Data security filters can accomplish this.




Activity: Specify object security In order to run reports with the projected sales targets for each sales rep, managers need access to all data in GO Operational Sales (query), including the Sales Target namespace. However, you want to ensure that sales reps cannot access projected sales targets for every sales rep. To support these requirements you will assign the Sales Manager and Sales Reps groups access to the appropriate objects. In this activity, you will accomplish the following: • Grant access to the GO Operational (query) package • Specify object security on the GO Operational Sales (query) namespace for the

Sales Managers and Sales Reps groups • Specify object security on the Sales Targets (query) namespace for the Sales

Reps group • View the results in IBM Cognos Analytics • Grant access to objects pointed to by shortcuts

Grant access to the GO Operational (query) package. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In the Project Viewer pane, select the GO Operational (query) package. • From the Actions menu, point to Package, and then click Edit Package Settings. • Click the Permissions tab, click Add, and then click Cognos. • Click the Last Page button, select the Sales Reps check box, and then click the

Add arrow.




• Click OK, select the Sales Reps check box, and then under Grant, select the Read, Write, Execute, and Traverse check boxes. The results appear as follows:

The Sales Reps group has been granted Read, Write, Execute, and Traverse access.

• Click OK.

Specify object security on the GO Operational Sales (query) namespace for the Sales Managers and Sales Reps groups. • In the Project Viewer pane, under Presentation View, click the

GO Operational Sales (query) namespace. • From the Actions menu, click Specify Object Security, and then click Add. • Click Cognos, click the Last Page button, and then scroll down if necessary and

select the Sales Manager and Sales Reps check boxes. • Click the Add button (the arrow button), and then scroll down if necessary and click

OK. • Under Allow, select the Sales Manager and Sales Reps check boxes, and then

click OK. A prompt appears, advising on object security in the model.




• Click OK to close this message and to complete the security specifications you have implemented. The security on the GO Operational Sales (query) namespace is inherited by all its children. You will now restrict access to the Sales Targets (query) namespace.

Specify object security on the Sales Targets (query) namespace for the Sales Reps group.

Notice the new icon on the GO Operational Sales (query) namespace. • In the Presentation View, expand the GO Operational Sales (query)

namespace, and click the Sales Targets (query) namespace. • From the Actions menu, click Specify Object Security.

The Specify Object Security dialog box appears. Notice that the Sales Targets (query) namespace has inherited the security that was applied to its parent object, the GO Operational Sales (query) namespace.

• Next to Sales Reps, select the Deny check box, and then click OK. A message appears, indicating that the security for the Sales Targets (query) namespace will override the settings already specified for the GO Operational Sales (query) namespace. Rather than select deny, you could also have cleared the Allow setting for Sales Reps, which would have implicitly denied access, but the method you have implemented ensures members of this group will not have access regardless of any other group they belong to.


View the results in IBM Cognos Analytics. • Publish the GO Operational (query) package, overwriting the existing package

and clicking Close to close the informational messages. • In IBM Cognos Analytics, sign in as uragomek/Education1 (Kazumi Uragome).

As a member of the Sales Manager group, the current user has access to all namespaces in the package, including the Sales Targets (query) namespace.

• Click Team content, point to the GO Operational (query) package, click More, and then click Create report.


defaults.




• On the Sources tab, expand all of the namespaces. Notice that they are empty, and there are no query subjects available. You will investigate this issue later in Framework Manager.

• Sign out of IBM Cognos Analytics without saving the report. • Sign in as turpind/Education1 (Daniel Turpin). • Click Team content, point to the GO Operational (query) package, click More,

and then click Create report. • From the Templates and themes page, select Blank, and then click OK. • On the Sources tab, expand all of the namespaces.

As a member of the Sales Reps group, the current user does not have access to any the namespaces.

• Sign out of IBM Cognos Analytics without saving the report.

Grant access to objects pointed to by shortcuts. • In Framework Manager, expand

Presentation View > GO Operational Sales (query) > Sales (query). When you granted access to the GO Operational Sales (query) namespace, the security was inherited at all levels below it. However, those levels only contain shortcuts to the query subjects, and security on shortcuts is not inherited by underlying objects. To ensure that users can access underlying objects, and then restrict objects as required, you will grant access to everyone for model objects that do not have object security configured.

• Click the GO Operational Model namespace (the root namespace), and then from the Actions menu, click Specify Object Security. The results appear similar to the following:

Notice that no one is allowed access. By allowing access to everyone, all objects will inherit this setting with the exception of the objects you already configured.

• Under Allow, select the Everyone check box, and then click OK. You can use a different group to open up access to users, such as the All Authenticated Users group.




• Save the project, and then publish the GO Operational (query) package, overwriting the existing package and clicking Close to close the informational messages.

• In IBM Cognos Analytics, sign in as turpind/Education1 (Daniel Turpin). • Click Team content, point to the GO Operational (query) package, click More,

and then click Create report. • From the Templates and themes page, select Blank, and then click OK.

Daniel Turpin cannot see the Sales Targets (query) namespace because he is part of the Sales Reps group, which has been denied access to the namespace. Notice that the Retailer Location Filters folder is now visible. This is also a shortcut in the GO Operational Sales (query) namespace. Now that the underlying object is available to everyone, it is visible.

• Expand Sales (query) > Sales Fact. You now see the query subjects and query items.





Activity: Use a macro in a data security filter You have been asked to publish a package in which members of the Sales Manager group can view sales targets for all employees, but members of the Sales Reps group can only see their own sales targets. To do this, you will create a macro that references an environment session parameter in order to implement data security for a particular group on a query subject. In this activity, you will accomplish the following: • Change the security from the last activity • Create a parameter map • Apply data security to a query subject • Publish and test the package in IBM Cognos Analytics - Reporting

Change the security from the last activity. In order to allow Sales Reps members access to their own sales targets data, you will need to grant Sales Reps members access to the Sales Targets (query) namespace.

• Ensure you are logged into IBM Cognos Framework Manager as admin (password is Education1), with the C:\Training\B6252G\Course_Project\GO Operational project open.

• In the Project Viewer pane, under Presentation View > GO Operational Sales (query), click the Sales Targets (query) namespace.

• From the Actions menu, click Specify Object Security. • Select Allow for Sales Reps, and then click OK.

Create a parameter map. • In the Project Viewer pane, right-click Parameter Maps, point to Create, and then

click Parameter Map. • In the Name field, type SecurityLookup, select Base the parameter map on

existing Query Items, and then click Next. • Expand Consolidation View > Staff by Location. • Click Staff Full Name, and then click Set as Key.




• Expand the Codes folder, select Sales Staff Code, and then click Set as Value. Staff Full Name acts as the unique key for the parameter map and Sales Staff Code acts as the substitution value that will be used to apply security in a data security filter. By basing this parameter map on existing query items in the data source, the parameter map will always reflect the latest data updates. As new employees join the company, they will automatically be reflected in the parameter map. To optimize this approach, you could filter the query subject used to feed the parameter map to make it more efficient. In this case, first make a copy of the query subject, filter it dynamically on Staff Full Name = account.defaultName, and then base the parameter map on the new query subject. It will only return one record when the parameter map is called, and prevents scanning the whole table. Since this is a relatively small table, you will simply use the existing query subject.

• Click Next. A section of the results appears as follows:

You can provide a default value that will be used if no match is found in the parameter map. In this activity, you do not want to return any data if there is no match, so you will leave the field blank.

• Click Finish.




Apply data security to a query subject. You will now secure the original SALES_TARGET query subject in the Foundation Objects View so that the security is applied to all objects that reference it.

• Under Foundation Objects View > gosales, click SALES_TARGET. • From the Actions menu, click Specify Data Security. • Click Add Groups, click Cognos, and then click the Last Page button. • Click the Sales Reps check box, and then click the Add button (the arrow button). • Click OK (scroll down if necessary). • In the first row, click the Filter value, and then select Create/Edit Embedded from

the list. The Filter Definition dialog box appears.

• Under Available Components, expand GO Operational Model > Foundation Objects View > gosales > SALES_TARGET.

• Double-click SALES_STAFF_CODE to add it to the expression definition. • At the end of the expression, type =. • Under Available Components, click the Parameters tab, expand

Parameter Maps, and then double-click SecurityLookup to add it to the expression.

• In the Expression definition pane, place the cursor between {} of the #$SecurityLookup{}# expression.

• Under Available Components, collapse SecurityLookup, expand Session Parameters, and then double-click account.defaultName to add it to the expression. The red line in the expression definition indicates that there is an error with the expression. This is due to the fact that you are currently logged in as admin, which does not exist in the data, and therefore cannot resolve the filter. You will now override the account.defaultName value in order to test and validate this filter.

• Click Options , and then click Set. • In the Override Value field for account.defaultName, type Daniel Turpin.




• Click OK twice. The results appear as follows:

Notice that the red line is gone and that the expression now resolves to a value.

• Click OK twice, and then save the project.

Publish and test the package in IBM Cognos Analytics - Reporting. • Publish the GO Operational (query) package, overwriting the existing package

and clicking Close to close the informational messages. • In IBM Cognos Analytics, sign in as turpind/Education1.

Daniel Turpin is a member of the Sales Reps group. • Click Team content, point to the GO Operational (query) package, click More,


defaults. • On the Sources tab, expand Sales Targets (query) > Staff by Location. • Add Staff Full Name to the report.

All names will be returned because the filter is on the sales target data. • Expand Sales Target Fact, and then add Sales Target to the report.




• Run the report in HTML. The results appear as follows:

The report is limited to the sales target for Daniel Turpin. Close the rendered report tab.

• Save the report in the GO Operational (query) folder, as Macro Security Filter Test.

• Sign out as Daniel Turpin, and then sign in as scottb/Education1. Bart Scott is also a member of the Sales Reps group.

• Click Team content, click GO Operational (query), and then click Macro Security Filter Test. The results appear as follows:

Data is now limited to Bart Scott. You will now sign in as a member of the Sales Manager group to test their access.

• Sign out as Bart Scott, and then sign in as uragomek/Education1 (Kazumi Uragome).




• Click Team content, click GO Operational (query), and then click Macro Security Filter Test. A section of the results appears similar to the following:

The report returns all employees and their sales targets.





Activity: Remove security In order to remove the impact of the security you applied, you will remove the security applied throughout previous activities. In this activity, you will accomplish the following: • Remove security from the package • Remove data security • Remove object security

Remove security from the package. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In the Project Viewer pane, under Packages, click the GO Operational (query) package, and then from the Actions menu, click Package > Edit Package Settings.

• Click the Permissions tab, and then clear the Override the access permissions acquired from the parent entry check box. An alert appears, explaining that this will cause the parent's policies to be acquired.

• Click OK. A section of the results appears similar to the following:

This package is now available to all of the roles that have access to the other packages found in the Team content area of IBM Cognos Analytics.

• Click OK.




Remove data security. • In the Project Viewer pane, under Consolidation View, click Products. • From the Actions menu, click Specify Data Security. • With the Camping Equipment Reps group selected, click Delete Group, and

then click OK. • Repeat the previous steps to delete the Sales Reps group from Foundation

Objects View > gosales > SALES_TARGET.

Remove object security. • In the middle pane, click Explorer. • In the Project Viewer pane, double-click the Packages folder to give it focus in the

Explorer. The results appear similar to the following:

Notice the security-based packages. These packages contain the security information you specified earlier.

• Double-click _Sales Manager to view the definition. The results appear as follows:

The Package Definition dialog box identifies the objects this group has access to.

• Click Cancel. You will now remove all object security by deleting the _Everyone package.




• Click the _Everyone package, and then press Delete. A message appears stating that this role is required for security implementation, and that removing it will remove all object security from the model.

• Click OK, and then save and close the project. • Close all open windows.




Create analysis objects Review Dimensionally Modeled Relational (DMR) metadata DMR metadata enables OLAP-style queries that include drill through functionality, provides the ability to use dimensional functions, such as parent([member]). It is defined by using: • Regular Dimensions • Measure Dimensions • Scope Relationships You can provide dimensional information to any metadata that is in star schema format, for example, you can add hierarchy information to dimensions, and define scope relationships for measures. DMR metadata works best with projects that are set up to use Dynamic Query Mode (DQM). When you use DQM with DMR metadata you get: • an increased ability to perform complex aggregation, and consistent results from

OLAP functions • a default sort order, which removes the requirement to manually specify sort

options • improved query execution performance IBM Cognos Analytics can access all types of packages (Relational, OLAP, or DMR), and is member aware (allowing you to work directly with members). If you just want to perform basic relational ad hoc querying and reporting, you should use standard relational modeling. However, you should use DMR metadata modeling when you want to: • Enable analysis on relational data • Enable drill up and down functionality in reports and ad hoc queries • Use member-specific functions in an authoring tool




Review OLAP data structures

The preceding diagram shows an OLAP cube data structure comprised of cells, as well as several dimensions. The dimensions are broken down by members. Additionally, there is a Time dimension broken down by its hierarchies: years and quarters, with attributes showing at the day level. Providing dimensional information in your Framework Manager models allows IBM Cognos to create multi-dimensional OLAP (MOLAP) structures at run time. To optimize a model for large data sets, you can create a dynamic cube with the IBM Cognos Cube Designer, which offers Relational over OLAP style models. Modeling with the IBM Cognos Cube Designer is outside the scope of this course. IBM Cognos dynamically generates the following elements at run-time: • dimensions: contain members, which may be structured into hierarchies and

levels • hierarchies: provide context to the level structures they contain • levels: provide structure for the members of a hierarchy • members: data entities that provide context to cell values • attributes: provide additional information for members • cells: are intersection points containing values (measures) for various members

from different dimensions (also referred to as tuples)




The preceding diagram shows the IBM Cognos Analytics Reporting Data Tree, which is what a report author would use to select their source items for inclusion in a report. The tree is expanded so that you can see the various hierarchies, levels, members, and child members of a Product dimension. Just as with OLAP data sources, your report authors are presented with multi-dimensional metadata when you apply dimensional information to your model. They will see the members in IBM Cognos Analytics - Reporting, because it is member-aware. When using relational models, report authors cannot see the underlying data while they are creating a report unless they create a filter (such as Product Type = Tents). With a DMR model, they can drag the data item (for example, Tents) into the report and actually see the data.

Define regular dimensions A regular dimension consists of one or more user-defined hierarchies which allow OLAP-style analysis against relational data. Each hierarchy consists of levels, keys, captions, and attributes. Level information is used to roll up measures accurately when performing queries or analyses. Regular dimensions require that each level have key and captions specified, and that captions be of the type string.




These items are used to generate members in the IBM Cognos Analytics data trees (where applicable) and retrieve the members at run time. To indicate that the keys in the levels above the current level are not necessary to identify the members in a level, select the Unique Level check box. When working with regular dimensions, use determinants to enable IBM Cognos Analytics to properly aggregate facts by preventing double-counting. Determinants do not provide OLAP functionality or the ability to use the metadata in IBM Cognos Analytics - Reporting. When you create a regular dimension, you specify hierarchy levels, but do not define granularity. Therefore, Framework Manager requires both the dimensional information and determinants to generate the proper SQL. Determinants are specified for query subjects. They are required for dimensions with granularity levels with repeating keys and blobs. If you convert a data source query subject to a regular dimension, Framework Manager will use joins and defined levels to properly interpret granularity. However, because the original data source query subject is replaced by a dimensional object, you should only use this feature if the underlying data structure is a perfect star schema and the final model is only intended for OLAP-style analysis. Note: when you use the Merge in New Regular Dimension feature on a query subject with determinants, Framework Manager creates a regular dimension whose hierarchy is based on the determinants, and the original query subject is retained.

Work with members IBM Cognos Analytics allows authors to create reports using levels, which return all members of that level. In IBM Cognos Analytics, members can be used independently as data items. The metadata items (member attributes) from the multidimensional model can also be used for report creation. Each member must have a query item that is assigned the role of member key (_businessKey) and a query item that is assigned the role of caption (_memberCaption). The member key is used to identify a particular member in a multidimensional structure and can be used as a value in drill though and master-detail operations. The member caption is the name that is displayed for the member. Members may also have attributes such as alternate member names or other descriptive information. Recall from the previous diagram that members are located in levels of an OLAP or DMR structure.




Define measure dimensions A measure dimension is a logical collection of facts that enables OLAP-style analytical querying. Measure dimensions are related to regular dimensions within scope. They can be created from a single table in a database, or from multiple tables across multiple databases. Measure dimensions are related to regular dimensions through scope relationships that define at what levels a measure is in scope. However, underlying join relationships are required to generate the SQL that is sent to the data source. With respect to joins, even with scope relationships in place, physical relationships between query subjects will always be required and cardinality is still used to determine if a query subject is a fact or a dimension in context to the query.

Define scope relationships

The preceding diagram shows a Sales Fact measure dimension with scope relationships to a Time dimension and a regular dimension (Products). A scope relationship is automatically created between a regular dimension and a measure dimension whose underlying query subjects have a valid join relationship defined. Scope relationships are required between measures and their related dimensions to achieve predictable rollups. Scope relationships determine which regular dimensions are included by default in star schema groupings.




Scope relationships are not the same as join relationships. They do not impact the WHERE clause of the generated SQL, but rather which hierarchy levels in a dimension are available for reporting for a particular measure. You can create, modify, or delete scope relationships. Shortcuts cannot be created for scope relationships. Nor can scope relationships be created for shortcuts. When shortcuts to dimensions are used, the scope will be derived from the scope of the original objects.

Edit DMR metadata You can use the Dimension Map to create and modify: • Regular or measure dimensions • Hierarchies or levels • Scope relationships The Dimension Map view displays all regular and measure dimensions contained in a namespace and can be directly modified in this view. If a measure is not in scope for a particular level of a regular dimension, you will see blank values, or repeating values (based on the values found at the parent level) in IBM Cognos Analytics - Reporting, but the values are not double counted. You can edit scope relationships for either measure dimensions or individual measures within a measure dimension (in cases where the fact table has multiple levels of granularity).

Examine Member Unique Names Member Unique Names (MUNs) ensure that members are unique within the multidimensional structure. They are referenced in an expression when a member is used: • In a report • In a filter or calculation • For drill-through When modeling DMR metadata in Framework Manager, you do not manually create the MUN for each member. Rather, you specify the member key and member caption, and the member key is used in the MUN when it is generated at run time.




Changes that impact a MUN MUNs can change when: • Hierarchies or levels change • Member keys change

• Category codes in PowerCubes • Member Key Column in MSAS cubes • _memberKey role in DMR models

• Members no longer exist in the data source • A production environment has more members than in the test environment You should avoid changing the objects in a package after it has been published into the production environment. When MUNs change, they impact the reports that directly reference the members to which they point. Those MUNs must then be identified and fixed in the report. In drill-through scenarios, once a broken MUN reference is fixed, there is potential for the report to pass the wrong parameter to the target report. This can occur when the member key changes. This is why it is not recommended to change member keys. It is critical that business keys are conformed across the business, ensuring that that they do not change and that there is no need to change them.




Activity: Create regular dimensions Business analysts require OLAP-style queries that allow them to analyze Sales and Sales Target measures against Products, Time, and Staff. To support this requirement, you will create a dimensional view and use DMR techniques to create the required regular dimensions. In this activity, you will accomplish the following: • Create the top level of a regular dimension for products • Create remaining levels for the Products regular dimension • Create a regular dimension from the time dimension • Create string calculations for member captions • Create a regular dimension named Staff by Location • Define the query items and attributes for each level

Create the top level of a regular dimension for products. You will organize dimensional objects in the Dimensional View namespace. Once the regular and measure dimensions are complete, you can use star schema groupings to populate the Presentation View.



• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\10_Create_regular_dimensions\GO Operational. If necessary, log in as admin/Education1.

• In GO Operational Model, create a namespace called Dimensional View.




• Drag the new namespace above the Consolidation View namespace. The results appear as follows:

• Right-click Dimensional View, point to Create, and then click

Regular Dimension. The Dimension Definition dialog box appears.

• In the Available items pane, expand Consolidation View > Products. • Drag Product Line into the Hierarchies pane, right-click the top Product Line

hierarchy, and then click Rename. • Type Products, and then press Enter. • Rename Product Line(All) to Product (All). • In the Hierarchies pane, click the Product Line level. • In the Available items pane, expand the Products > Codes query item folder,

and then drag Product Line Code to the lower-right pane ("Select a level…") below Product Line. You are prompted to select a role.




• Click _businessKey. The right side of the Dimension Definition dialog box appears as follows:

Create remaining levels for the Products regular dimension. • In the Available items pane, under Consolidation View > Products, drag

Product Type to the Hierarchies pane, below Product Line. • From Codes, drag Product Type Code to the lower-right pane, select

_businessKey as the role, and then select the Unique Level check box above. Selecting Unique Level indicates that this level (Product Type Code) is unique, and does not rely on the parent object (Product Line Code) for uniqueness. While it is also true that every Product Line Code is unique, you do not need to set the Unique Level check box for the Product Line level because there is no parent level above it.




• In the Available items pane, drag the following: • Product Name to the Hierarchies pane (below Product Type), and rename it

Product. • Codes > Product Number to the lower-right pane, and set it as the

_businessKey. • Product Description to the lower-right pane, and set it as

_memberDescription. • In the Products query subject, click Product Image, Shift+click Discontinued

Date, and then drag the three selected items to the lower-right pane, with No Role. The Product level is the lowest level of the hierarchy and is also represented by a unique key (Product Number). You will specify this level as unique as well.

• Select the Unique Level check box. The results appear as follows:

• In the lower-right pane, rename Product Name to Product Caption. • Click OK.




• In the Project Viewer pane, rename the new dimension to Products, and then expand the dimension and hierarchy. The results appear as follows:

The Dimensional View contains the Products dimension, which contains the Products hierarchy and four levels.

Create a regular dimension from the time dimension. • Create a Time regular dimension as follows:

• In Dimensional View, create a new Regular Dimension. • From Consolidation View > Time, drag Year, Quarter Key, Month Key, and

Day Key into the Hierarchies pane. • Rename the levels as follows: Time, Time (All), Year, Quarter, Month, Day. • Individually select the Quarter, Month, and Day hierarchies, and select the

Unique Level check box. • Ensure that for the Year, Quarter, Month, and Day hierarchies, the role for

each level is set to _businessKey by clicking the ellipsis under Role. • Select the Month hierarchy, and drag Month (numeric) to the lower-right

pane, selecting No Role. • Click OK, and then rename the new dimension Time. • Expand the Time dimension and hierarchy.





You are creating the Time dimension manually, so that all hierarchies come from the Consolidation View. However, you could also create it from the TIME_DIMENSION data query subject by right-clicking it, and selecting Merge Into Regular Dimension. This would allow you to take advantage of the determinants specified in the query subject, which are used to automatically populate the hierarchy information.

• Right-click the Time dimension, click Verify Selected Objects, and then in the lower-right corner, click Verify Model. There are four error messages and one warning message. The error messages indicate that four of the levels do not have captions specified. To attempt to resolve one of these errors, you will set the Year level as both the business key and the caption. You can safely ignore the warning message that indicates that you have not yet validated the new Time dimension.

• Click Close, and then double-click Time to open the Dimension Definition dialog box.

• In the Hierarchies pane, click Year, and then in the lower-right pane, click the ellipsis in the Role column.

• Select _memberCaption, click Close, and then click OK. • Right-click Time, click Verify Selected Objects, and then click Verify Model.

There are still four errors. The error related to the Year level, however, has changed. It indicates that you cannot assign the _memberCaption role to a data type that is not "string". You will fix this in the next task.




• Click Close, and then Save the project in C:\Training\B6252G\Course_Project, overwriting the previous project.

Create string calculations for member captions. • Ensure GO Operations Model > Dimensional View is expanded, double-click

Time to open the Dimension Definition dialog box. • In the Hierarchies pane, click Year, click the ellipsis under Role, clear the

_memberCaption check box, and then click Close. Note: _businessKey should still be selected.

• With the Year hierarchy selected, in the lower-right corner, click Add. • In the Name field, type Year Caption, and then in the Expression definition

pane, type cast(. • In Available Components, expand Consolidation View > Time. • Double-click Year to add it to the Expression definition pane, click to place your

cursor at the end of the expression, and then type the following: , VARCHAR(4)). The results appear as follows: cast([Consolidation View].[Time].[Year] , VARCHAR(4))

• Click the Test Sample button to verify the results, and then click OK. • Set the Role for Year Caption to _memberCaption, and then click Close. • Repeat the previous steps to create _memberCaption levels for the Quarter,

Month, and Day hierarchies, based on the following: • Quarter Caption: cast([Consolidation View].[Time].[Year] ,VARCHAR

(4)) ||'Q'|| cast([Consolidation View].[Time].[Quarter], VARCHAR (2))

• Month Caption: [Consolidation View].[Time].[Month]

• Day Caption: cast([Consolidation View].[Time].[Date], VARCHAR (10)) Tip: Remember to select the appropriate hierarchy (for example, Quarter) before you create the query item for its member caption. Instead of creating a calculation for Month Caption, you could have directly added the Month query item back in the previous steps, and then renamed it to Month Caption. Either method is appropriate.

• Click OK.




• Right-click the Time dimension, then click Verify Selected Objects, and then click Verify Model. There are no errors. You can safely ignore the warning message, which is generated because you are publishing a query item that references another query item in a different namespace.

• Click Close, and Save the project.

Create a regular dimension named Staff by Location. • Right-click Dimensional View, and then click Create > Regular Dimension.

The Dimension Definition dialog box appears. • In the Available items pane, expand Consolidation View > Staff by Location. • Drag the following items to the Hierarchies pane:

• Staff Region • Staff Country • Staff City • Staff Full Name

• In the Hierarchies pane, make the following changes: • Rename the Staff Region hierarchy to Staff by Location. • Rename the top Staff Region(All) level to Staff by Location (All). • Rename the bottom Staff Full Name level to Staff Name. • Set the Staff Country, Staff City, and Staff Name levels as unique. The results appear as follows:




Define the query items and attributes for each level. • Staff Region level: In the lower-right pane, ensure Staff Region is the member

caption, and then rename it to Staff Region Caption • from the Codes folder, add Staff Region Code, as the business key

• Staff Country level: Ensure Staff Country is the member caption, and then rename it to Staff Country Caption • add Staff Country Code as the business key

• Staff City level: Ensure Staff City is the member caption, and then rename it to Staff City Caption • add Staff Branch Code as the business key • add Staff Address 1, Staff Address 2, Staff Prov/State, Staff Postal Zone,

(no role for each) • Staff Name level: Ensure Staff Full Name is the member caption, and then

rename it to Staff Name Caption • add Sales Staff Code as the business key • add First Name, Last Name, Work Phone, Extension, Fax, Email,

Position, Manager (no role for each) • Click OK. • In the Project Viewer pane, rename the new dimension to Staff by Location.




• Expand the dimension, the hierarchy, and all of the levels. The results appear as follows:

• Save the project. • Leave Framework Manager open for the next activity.




Activity: Create measure dimensions, set scope, and create a presentation view

To continue the development of the DMR view required by authors and business analysts, you will create two measure dimensions, one for Sales Facts, and one for Sales Target Facts. You will specify the scope of the measures, and then populate a new Presentation view before testing the DMR portion of the model. In this activity, you will accomplish the following: • Create Sales Fact and Sales Target Fact measure dimensions • Set scope relationships for the measure dimensions • Create a DMR presentation view using star schema groupings • Create a GO Operational (analysis) package • Test the new package in IBM Cognos Analytics

Create Sales Fact and Sales Target Fact measure dimensions. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In Project Viewer, right-click Dimensional View, point to Create, and then click Measure Dimension. The Dimension Definition dialog box appears.

• Expand Consolidation View > Sales Fact. • Click Revenue, Shift+click Margin to select all seven measures, drag the selected

measures to the Measures pane, and then click OK. • Rename the new dimension Sales Fact, and then move it above Products. • In Dimensional View, create a new measure dimension, expand Consolidation

View > Sales Target Fact, and then drag Sales Target to the measures pane. • Click OK, rename the new dimension Sales Target Fact, and then move it below

the Sales Fact measure dimension.




• Expand the Sales Fact and Sales Target Fact measure dimensions. The results appear as follows:


Set scope relationships for the measure dimensions. • Double-click the Dimensional View namespace to give it focus in the middle pane,

and then click the Diagram tab. • From the Diagram menu, click Diagram settings, select the

Scope Relationships check box, and then click OK.

• Click Auto Layout , and then beside Layout Style, select Star.




• Set the Sibling Distance to 30, click Apply, and then click Close. The results appear as follows:

The facts are joined to their related dimensions through scope relationships. These relationships were automatically generated based on the underlying relationships in the Foundation Objects View.




• Double-click the Scope relationship between Time and Sales Target Fact, and then in the right pane, click Sales Target Fact. The results appear as follows:

All levels in the Time dimension are highlighted, which indicates that they are in scope. This is not the case for sales targets since they are at the month level. You can set the scope in this dialog box, or in the Dimension Map pane. You will set the scope for this measure here, but then cancel the changes and then set the scope in the Dimension Map in order to learn both methods.

• Click the Month level, and then click Set Scope. The results appear as follows:

The Day level is no longer highlighted and is now out of scope for the Sales Target measure.




• Click Cancel, and then in the middle pane, click the Dimension Map tab. The results appear as follows:

The three dimensions appear in the left pane and the measure dimensions appear in the right pane. Here you can create, edit, and delete dimensions and set scope.

• In the Measures pane, click Sales Fact. The results appear as follows:

All regular dimensions are highlighted, indicating that all measures in Sales are in scope.

• Click Sales Target Fact. Again, the measure is in scope for all dimensions. You will set the scope for Sales Target Fact to be at the Month level for Time and Product Type level for Products.

• In the Time dimension, click Month, and then on the toolbar, click

Set Scope .




• In the Products dimension, click Product Type, and then click Set Scope. The results appear as follows:

The Day level for the Time dimension and the Products level for the Products dimension are no longer highlighted and are out of scope for Sales Target Fact. You will now explore the Attributes tab.

• In the right pane, click the Attributes tab. The results appear as follows:

Here you see the business key, member caption and any other attributes for the selected level in the dimension map. You can edit these items here if you wish. Each time you select a different level in any of the dimensions, their attributes will be displayed here.

Create a DMR presentation view using star schema groupings. • In the Presentation View namespace, create a namespace called

GO Operational Sales (analysis), and then drag it below GO Operational Sales (query). The results appear as follows:




• In the Dimensional View namespace, right-click Sales Fact, and then click Create Star Schema Grouping. Unlike when you create star-schema groupings for relational metadata in the Consolidation View, here you do not need to select all the desired dimensions along with the fact. This is because Framework Manager uses the scope relationships to identify related dimensions. The Consolidation View objects have no relationships; therefore you needed to select all required objects. If there had been relationships, the Star Schema Grouping wizard would use them to detect related objects for the grouping.

• In the Namespace name field, type Sales (analysis), and then click OK. • Drag Sales (analysis) into the GO Operational Sales (analysis) namespace. • Repeat the previous steps with Sales Target Fact, to create

Sales Targets (analysis), and then drag Sales Targets (analysis) into the GO Operational Sales (analysis) namespace. The results appear as follows:

Create a GO Operational (analysis) package. • Right-click Packages, point to Create, and then click Package. • In the Name field, type GO Operational (analysis), and then click Next. • Clear the GO Operational Model check box, and then expand

Presentation View > GO Operational Sales (analysis).




• Select Sales (analysis) and Sales Targets (analysis). The results appear as follows:

• Click Finish, and click Yes to open the Publish Package wizard. • Clear the Enable model versioning check box, and then click Next twice. • Select the Use Dynamic Query Mode check box, click Publish, and then click

Yes to continue. • Click Finish.

The Verify Model dialog box appears listing informational messages. • Click Close. • Save the project.

Test the new package in IBM Cognos Analytics. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to GO Operational (analysis), click More, and then

click Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click Crosstab, and then click OK to accept the query

defaults. • In the upper-right corner, click the arrow beside Page design, and then click

Page preview. • From the Sources tab, expand Sales (analysis) > Products dimension >

Products hierarchy, and then drag Product Line to the Columns drop zone in the work area.




• Expand the Time dimension and hierarchy, and then drag Year to the Rows drop zone in the work area.

• Expand the Sales Fact measure dimension, and then drag Revenue to the Measures drop zone in the work area. The crosstab is now populated, and is currently the active object. You want to select the entire report so you can change its properties.

• If the Properties pane is not open, in the upper-right corner, click Properties to open it. The top of the Properties pane shows that the Crosstab is currently selected. In the upper-left corner of the screen, there is a breadcrumb trail that reads: Report > Pages > Page1. This path shows you the part of the report you are working with currently.

• In the breadcrumb trail, click Report, and then from the list, click Report. The Properties pane now shows properties for the entire report.

• In the Properties pane, under RUNNING & VALIDATING, change the Run with full interactivity property to No.

• In the Properties pane, under DATA, change the Drill-up and drill-down property to Yes.

• From the breadcrumb trail, click Report, and then from the list, click Page1. The results appear as follows:

Notice that the years are sorted from earliest to latest and the product lines are sorted alphabetically. This is due to the automatic sort features of Dynamic Query Modeling (DQM).

• Click the intersection of Camping Equipment and 2013 once to give $352,910,329.97 focus, and then click it again to drill down on both the row and the column at the same time.




• In the Insertable objects pane, with the Sources tab selected, expand the Staff by Location dimension and hierarchy, and then drag Staff Region below the column headings as a nested dimension, releasing when a flashing black line appears between the headers and first row of data. A section of the results appears similar to the following:

You can now further analyze sales in relation to location. Again notice that the crosstab is sorted.

• Under Cooking Gear, click the cell twice where Central Europe and 2013 Q2 intersect. A section of the results appears as follows:

• Click the June row header twice.

The rows now display days in June. • From the Sources tab, expand Sales Targets (analysis) > Sales Target Fact. • Drag Sales Target to the measures section of the crosstab (upper-left corner) to

replace the existing Revenue measure. A message appears, indicating that no data is available. There are no measure values shown because the Sales Target measure is not in scope at the Day level.

• On the toolbar, click Undo .




• Click any row header that displays a day in June (such as 2013-06-12).

• From the on-demand toolbar, click Explore , and then click Drill Up. The rows display data at the month level again.

• From the Sources tab, drag Sales Target to the measures section of the crosstab (upper-left corner) to replace the existing Revenue measure. Sales Target values appear because you are at the Month level, which is in scope.

• On the Application bar, close the report without saving it. • Close IBM Cognos Analytics. • Leave Framework Manager open for the next activity.




Activity: Identify how changes to MUNs impact reports

In this activity, you will explore how package changes can impact reports. To do so, you will use a DMR source to create a report that uses members as data items, and then identify a MUN for a member in the report. You will then make a change to the model that impacts the MUN, re-publish the package, and re-run the report. You will identify how the report is impacted, and subsequently how the MUN is impacted. You will then fix the report. For this activity you will use the great_outdoors_warehouse model, which is based on a reporting database (star schema) for the Sample Outdoors Company. In this activity, you will accomplish the following: • Publish the GO Data Warehouse (analysis) package • Create a report using members • Change the _businessKey role for a level within a dimension • Examine the impact of a model change on the MUN

Publish the GO Data Warehouse (analysis) package. • In Framework Manager, close any projects that may be open, and then open the

great_outdoors_warehouse project located at C:\Training\B6252G\CBIFM-Start Files\11_Changes_to_MUNs\great_outdoors_warehouse.

• Publish the GO Data Warehouse (analysis) package. If prompted, enter month and year values (for example, May, 2010).

Create a report using members. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to GO Data Warehouse (analysis), click More, and

then click Create report. If this package is not available, refresh your web browser and try again.

• From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click Crosstab, and then click OK to accept the query

defaults.




• In the Sources tab, expand Sales and Marketing (analysis) > Sales target > Sales target fact, and then drag the Sales target measure to the Measures drop zone in the report.

• Expand Employee (by position) > Employee (by position-department) > Position-department (level 1) > Members > Executive > Operations > Sales > Level 3 Sales Representative.

• Click Aiko Watanabe, Shift+click Alessandra Torta, and then drag the three selected items to the Rows drop zone.

• Drag the Employee (by position-department)(All) level to the Rows drop zone under the existing rows, releasing when a black flashing line appears.

• Under Sales and Marketing (analysis), expand the Sales > Time dimension > Time dimension hierarchy, and then drag the Year level to the Columns drop zone. The results appear as follows:

• Run the report in HTML.


The report contains the values of the member items that you added during design.

• Close the rendered report tab. • In the Source pane, right-click the Aiko Watanabe member, and then click

Properties. Notice the Member Unique Name property: [Sales target]. [Employee (by position)].[Employee (by position-department)].[Employee]->[all].[100].[220 ].[390 ].[43639].[4116]

At the very end of the MUN, the _businessKey role value used is 4116. This value is based on the Employee key in the data source.




• Click Close. • Save the report in GO Data Warehouse (analysis) as MUN Test, and then close

the report.

Change the _businessKey role for a level within a dimension. • In Framework Manager, in the Project Viewer pane, expand

go_data_warehouse > Dimensional view. • Double-click the Employee (by position-department) dimension.

The Dimension Definition dialog box appears. • In the Hierarchies pane, scroll down if necessary and click the Employee level.

In the bottom pane, the _businessKey role is set on Employee key. The values represented by this item are those that appear as the member key for the MUN of a member as shown earlier.

• In the bottom pane, under the Role column, click the ellipsis next to Employee code.

• Select the _businessKey check box, and then click OK to close the warning message.

• Click Close, and then click OK. • Save the project in a new location at

C:\Training\B6252G\Course_Project\Great Outdoors Warehouse. • Publish the GO Data Warehouse (analysis) package, clicking Yes to overwrite

the existing package.

Examine the impact of a model change on the MUN. • In IBM Cognos Analytics, click Team content, click the GO Data

Warehouse (analysis) package, and then click the MUN Test report to run it. The results appear as follows:

Data appears to be missing. The report does not contain the values of the member items that you added during design. It contains only the values for the metadata item you added (Employee (by position-department)(All)). The report is running against the most recent version of the package.




• On the Application bar, click Edit (click OK if necessary to close the message related to the updated package).

• On the Side panel, click Insertable objects, expand Sales and Marketing (analysis) > Sales target > Employee (by position) > Employee (by position-department) > Position-department (level 1) > Members > Executive > Operations > Sales > Level 3 Sales Representative.

• Right-click Aiko Wantanabe, and then click Properties. At the end of the Member Unique Name, the _businessKey role value is now 10572. This value is based on the Employee code in the data source. This MUN is now different based on the change you made to the model. The current employee members in the report layout are associated with MUNs that no longer exist and therefore are not returned in the report. To correct this you must replace the existing members in the report layout with the current members from the Insertable Objects pane.

• Click Close. • From the Sources tab, select the following three members, then and drag them to

the rows area above Employee (by position-department)(All): • Aiko Wantanabe • Akemi Yamada • Alessandra Torta The results appear as follows:

The rows are now returned appropriately. Note: If the report contains calculations based on members whose MUNs change, you need to delete the members referenced in the calculation before adding the new members to the report.

• On the Application bar, sign out as Admin Person without saving it. • Close the web browser, and then close Framework manager, saving the project if

prompted.




Manage OLAP data sources Identify OLAP data sources in IBM Cognos IBM Cognos Analytics provides full support for the analysis of PowerCubes and other OLAP data sources. Other OLAP sources include: • IBM Cognos Planning Analyst Models • Microsoft Analysis Services • IBM DB2 OLAP • Hyperion Essbase SAP BW is also an OLAP data source, but unlike other cube sources, you can lightly model SAP BW metadata after it is imported.

Use OLAP data sources You can use Framework Manager or IBM Cognos Analytics to create data source connections to various cube data sources. Once your connection is in place, you can import a cube into Framework Manager. No modeling is required since the modeling has already been done in an OLAP modeling tool such as IBM Cognos Transformer. The package is then published directly to the portal, making it available to report authors. Not only can you publish IBM Cognos PowerCubes from Framework Manager, you can also publish them directly in IBM Cognos Analytics or from IBM Cognos Transformer. You can also use Framework Manager to create multi-cube packages and to combine cubes and relational metadata into one package. Creating reports that link multiple cube sources, or a cube source and a relational source, may require the caption function on the OLAP source(s) to retrieve a string value that can be used to match a string value in the other source. This is required when MUNs do not match or the value extracted from the MUN does not match the value in the relational source.




Activity: Import and publish an OLAP data source

Authors would like to be able to report from data stored in multiple OLAP sources. To support this, you will create a Framework Manager project and import a PowerCube. In this activity, you will accomplish the following: • Create a new project and import a cube • Examine the objects and publish a package • Test the GO Cube package

Create a new project and import a cube. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, click Create a new project, and then name the new project OLAP Model.

• Clear the Use Dynamic Query Mode check box. • Set the Location to C:\Training\B6252G\Course_Project\OLAP Model. • Click OK, and then log on as admin/Education1 (if necessary). • In the Select Languages dialog box, ensure that English is selected, and then

click OK. • Ensure that Data Sources is selected, and click Next. • Click New, and then click Next. • In the Name box, type GO Cube, and then click Next. • Under Type, select IBM Cognos PowerCube, and then click Next.

The connectivity information you supply for a cube data source connection will depend on the type of cube source you are accessing. For example, PowerCubes require that you supply the filename and path for the cube. To specify the location, you will use File Explorer to obtain the path and file name since the cube is local. For a network cube, use a UNC path.




• In the Windows location field, type: C:\Program Files (x86)\ibm\cognos\c10\webcontent\samples\ datasources\cubes\PowerCubes\EN\sales_and_marketing.mdc.

• Scroll down, under Testing, click Test the connection, and then click Test. A message appears indicating that the test was successful.

• Click Close, and then click Close again. • Scroll down if necessary to click Finish, and then click Close. • In the list of data sources, select GO Cube, click Next, and then click Finish.

You are now prompted to create a package for this project. You will use the name GO Cube for your package.

• Click Finish. • Click No when asked if you want to open the Publish Package wizard.

Examine the objects and publish a package. • In the Project Viewer pane, expand Model.

The GO Cube model does not include any additional information. Everything needed to publish it is stored internally in the data source. You could have created your connection to the cube and your package entirely in IBM Cognos Analytics, but you are doing it here so that you can add additional cubes to the model in the next activity.

• Expand Packages, right-click GO Cube, and then click Publish Packages. • Clear the Enable model versioning check box, click Next twice, click Publish,

and then click Finish. • Save your project.

Test the GO Cube package. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to GO Cube, click More, and then click

Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click Crosstab, and then click OK to accept the query

defaults.




• In the upper-right corner, click the arrow beside Page design, and then click Page preview.

• From the Sources tab, expand the Time dimension and hierarchy, and then drag Year to the rows drop zone.

• Expand the Products dimension and hierarchy, and then drag Product line to the columns drop zone.

• Expand Measures, and then drag Revenue to the Measures drop zone. The results appear as follows:

You have successfully published an IBM Cognos PowerCube that can be used to analyze data and write reports in IBM Cognos Analytics.

• Close the report without saving it. • Leave IBM Cognos Analytics and Framework Manager open for the next

activity.




Activity: Import and publish multiple OLAP data sources

Authors would like to access financial data stored in a Microsoft Analysis Services cube. They would also like to be able to link data from this cube to the original Sample Outdoors Company PowerCube. You will add a second cube to your model and then create a test report. In this activity, you will accomplish the following: • Add the sales_and_marketing cube to the model • Add the sales_and_marketing package to the GO Cube package and publish • Create a report with the GO Cube package • Create a master-detail link

Add the sales_and_marketing cube to the model. • In Framework Manager, in the Project Viewer pane, right-click Model, and then

click Run Metadata Wizard. • Ensure that Data Sources is selected, and then click Next. • Click sales_and_marketing, and then click Next. • Click Finish to complete the wizard. • Click Finish to create the sales_and_marketing package. • Click No when asked if you want to open the Publish Package wizard.





Add the sales_and_marketing package to the GO Cube package and publish. • In the Project Viewer pane, under Packages, double-click GO Cube. • Click the sales_and_marketing check box to select it, and then click OK. • Publish the GO Cube package, overwriting the existing package.

Create a report with the GO Cube package. • In IBM Cognos Analytics, click Team content, point to GO Cube, click More,


defaults. • In the Sources tab, under GO Cube, expand GO Cube and

sales_and_marketing. The dimensions for each cube appear. You will now create a report that displays data from both cubes.

• Expand GO Cube > Products > Products, and then drag the Product line level to the report.

• Expand GO Cube > Measures, and then double-click Revenue to add it to the list.




• At the top of the Insertable objects pane, click Toolbox , drag a List object to the right of Revenue, releasing when a flashing black bar appears, and then click OK to accept the query defaults. The results appear as follows:

The new list data container is added as a new column. If the new list does not appear in the correct location, click Undo and add the list again.

• At the top of the Insertable objects pane, click Sources, under sales_and_marketing, expand Products > Products, and then drag Product line into the new List data container.

• Expand sales_and_marketing > Measures, and then drag Profit margin and Revenue beside the Product line column under List. The results appear as follows:





Profit Margin and Revenue is repeated for each Product line. Next, you will link the two lists on Product line.

Create a master-detail link. • Close the rendered report tab. • Click the right Product line column (not the header), from the on-demand toolbar,

click More , and then click Master Detail Relationships. Note: You may have to resize the panes to enlarge the workspace area in order to see the More button. The Master detail relationships dialog box appears.

• Click New Link.




• Ensure Product line is selected in both columns. The results appear as follows:

A link appears between the first column of each query (between Product line and Product line). This is the link that you want to create.

• Click OK, and then run the report in HTML. The results appear similar to the following:

The profit margin and revenue data for each Product line appears in the proper rows. You have left the Product line column in the report for verification, but you would remove it from the report layout for the production report.

• Close the rendered report tab and then sign out of IBM Cognos Analytics - Reporting without saving it.

• Close the web browser, and then close Framework Manager, without saving the changes.




Explore SQL generation and the use of governors Explore SQL generation in IBM Cognos Framework Manager Consider the following SQL:

select coalesce(D2.Year1,D3.Year1) as Year1, D2.Revenue as Revenue, D3.Sales_Target as Sales_Target

from (select Time_Dimension.Year1 as Year1, XSUM(Sales_Fact.Revenue for Time_Dimension.Year1) as Revenue from

………………………… where (Time_Dimension.Day_Date = Sales_Fact.Order_Date)

group by Time_Dimension.Year1

) D2 full outer join (select

Time_Dimension.Year1 as Year1, XSUM(Sales_Target.Sales_Target for Time_Dimension.Year1) as Sales_Target

from …………………………. where

((Time_Dimension.Year1 = Sales_Target.Sales_Year) and (Time_Dimension.Month1 = Sales_Target.Sales_Period))

group by Time_Dimension.Year1 ) D3 on (D2.Year1 = D3.Year1)

Confusion is a common reaction. Frequently asked questions are: • What is the coalesce function? • Why are the same columns being selected in two different derived tables? • Why is there a full outer join? • What does the XSUM function do?




The SQL in the preceding example is IBM Cognos SQL generated, based on the selection of various query items, and with auto aggregation enabled. Most samples shown in this unit will use SQL with auto aggregation values, since it is the default setting in IBM Cognos Analytics - Reporting.

Governors that affect SQL generation Several project governors can limit queries and affect the SQL generated at run time. These include: • Outer Joins (Allow, Deny) • Cross-Product Joins (Allow, Deny) • Shortcut Processing (Automatic, Explicit) • SQL Join Syntax (Explicit, Implicit) • Grouping of Measure Attributes (Enable, Disable) • SQL Generation for Level Attributes (Group by, Minimum) • SQL Generation for Determinant Attributes (Group by, Minimum) • SQL Parameter Syntax (Marker, Literal) • Use WITH clause when generating SQL (Yes, No) This course examines only some of the available governors in detail, since some are used in rare cases. Refer to the product documentation for details on each governor setting. The SQL Join Syntax governor controls how SQL is generated for inner joins. Selecting Explicit will generate INNER JOIN syntax, and selecting Implicit will use WHERE syntax. This setting you choose depends on your own personal preference. The Use WITH clause when generating SQL governor lets you choose to use the WITH clause with IBM Cognos SQL if your data source supports it. The With clause governor toggles Common Table Expression syntax. IBM Cognos Framework Manager currently only supports the Non-Recursive form of common table expressions. The With clause is used to avoid scanning the same table several times if the query against it is required more than once in a larger query.




Using derived tables Derived tables: • Are aliased sub-selects • Enable developers to return values without observing complex SQL • Are generated in both IBM Cognos SQL and native SQL A derived table retrieves a record set that fulfills the requirements of the parent query. Although the use of derived tables can create queries that are very long and verbose, the advantage is that they articulate the work being done by the query in blocks that can be linked back to the database: Cognos SQL

select ……………………… from (select ………………………… ) D2

In the above example, the second SELECT statement is a derived table, and D2 is the derived table alias. Not only are derived tables essential for complex queries that require layers of calculations and filters, but they also make the queries easier to debug. Each block of native SQL in a derived table query can be executed independently in the native interface of a database vendor, and are therefore more easily diagnosed when the behavior is not as expected. The outer blocks of SQL are derived from the inner blocks of SQL. In Oracle environments, derived tables are known as in-line views.




Derived tables use alias names that make it easy to identify the query from which the projected items come. In the following example, there are two derived tables, D2 and D3, which achieve the final projections list. The derived table alias names are also used in the Join statement:

select coalesce(D2.Year1,D3.Year1) as Year1, D2.Revenue as Revenue, D3.Sales_Target as Sales_Target

from (select Time_Dimension.Year1 as Year1, XSUM(Sales_Fact.Revenue for Time_Dimension.Year1) as Revenue from

………………………… where

(Time_Dimension.Day_Date = Sales_Fact.Order_Date) group by

Time_Dimension.Year1 ) D2

full outer join (select Time_Dimension. Year1 as Year1, XSUM(Sales_Target.Sales_Target for Time_Dimension.Year1)

as Sales_Target from …………………………. where

((Time_Dimension.Year1 = Sales_Target.Sales_Year) and (Time_Dimension.Month1 = Sales_Target.Sales_Period))

group by Time_Dimension.Year1 ) D3 on (D2.Year1 = D3.Year1)

Derived tables are instrumental in stitch queries, so they will be reviewed first before stitch query SQL is examined. Each derived table returns values that are used to achieve the final projection list (the first select statement) as well as values to achieve the final join statement. Notice the alias names in the first select statement and in the final join statement.




Identifying stitch query SQL Stitch queries are used to achieve predictable results for multi-fact queries. There are three essential components of a stitch query: • coalesce function • full outer join • multiple queries that query some of the same information In the following example, the SQL represents a multi-fact query based on one conformed dimension (Time Dimension) and two facts (Sales_Fact.Revenue and Sales Target.Sales Target). If the query requires local processing, IBM Cognos includes a local relational engine that is able to process local stitch queries efficiently:




In the preceding example, Year1 is queried more than once. Repeated information comes from conformed dimensions used in multi-fact queries. This is done to generate result sets that can be merge-sorted together in the full outer join. For each additional fact table that is included in a query, there will be another full outer join. If you added another fact to the query, there would be another full outer join and another derived table for the new fact introduced into the query.

What is a coalesce function? A coalesce function: • merges query items that exist on multiple sides of the query • indicates that a query item is part of a conformed dimension Anything included in the report as a column, filter, or prompt can be treated as a conformed dimension if it is common to the fact items in the query. In the example below, the coalesce function is used in a SQL statement to combine data from the Sales Fact and Returned Items Fact tables into a single report set. Both tables contain the DAY_DATE and ORDER_METHOD columns, which are treated as conformed dimensions. The Sales Fact table contains the SALE_TOTAL fact item, while the Returned Items Fact table contains the RETURN_QUANTITY fact item. The resulting report set includes both of these fact items:

select coalesce(D2.DAY_DATE,D3.DAY_DATE) as DAY_DATE, coalesce(D2.ORDER_METHOD,D3.ORDER_METHOD) as ORDER_METHOD




Coalesce functions: • return the first non-NULL value from a series of expressions. It returns NULL if the

series contains only NULL. • create the results set, including nulls, but not necessarily by the shared dimension

key. For example, if two different products had the same product name, they would end up as a single result on this report.

Non-conformed dimensions in generated SQL Non-conformed dimensions will not use a coalesce function, and only show up in the derived table of the fact to which they are related. If you are using what you expect to be a conformed dimension in a multi-fact query and no coalesce function is generated, you should investigate your model to ensure that no query path has been missed, or that the IBM Cognos query engine is not identifying the dimension as a fact based on cardinality. In the following example, REASON_DESCRIPTION comes from the Return_Reason_Dimension table, which is not conformed between the Sales Fact and Returns Fact tables. Because it is not conformed, it will only be a part of the derived table query that is related to the Returned Items Fact table. By observing the SQL, you can quickly determine a non-conformed dimension by the absence of the coalesce function:




What is an RSUM(1 …asc local) as sc? If automatic aggregation is not enabled and at least one conformed dimension is present, the same stitch column will be generated in both derived tables of a stitch query. This stitch column takes a common key(s) from the conformed dimension(s) between the two queries and sorts it ascending locally on the IBM Cognos server. These columns and others then merge the two result sets. The fact values in the fact columns will be related to the conformed dimension but not necessarily to each other. If automatic aggregation is not enabled and there are no conformed dimensions present, IBM Cognos Analytics will attempt to generate a stitch column by selecting a column from each query and using it to create unique values that will merge the queries. There are no definite relationships between the facts. In either case RSUM(1….asc local) as sc is cause for investigation to ensure the correct results are returned. A running total (RSUM) is used to create unique instances of the stitch key. The sc stands for stitch column, as in the following examples:

RSUM(1 for Order_Method_Dimension.ORDER_METHOD_KEY order by Order_Method_Dimension.ORDER_METHOD_KEY asc local) as sc1 RSUM(1 order by Sales_Target_Fact.SALES_TARGET asc local) as sc

The following syntax indicates that a conformed dimension is not included in a multi-fact query:

Each query uses a different column to generate the stitch column that, in most cases, returns unrelated results. This functionality may not work, depending on the nature of the data. For predictable results, ensure that there is a conformed dimension between the two facts and a common level of granularity. If this type of SQL is being generated, you should investigate and rework your query so that it appears as expected.




Why is there an XSUM? XSUM in IBM Cognos SQL indicates a windowed aggregate, which indicates what value is being aggregated and to what level(s), as displayed below: • IBM Cognos SQL:

XSUM(Sales_Fact.SALE_TOTAL for Time_Dimension.MONTH_KEY) as SALE_TOTAL

• Native SQL: sum("Sales_Fact"."SALE_TOTAL") AS "SALE_TOTAL"

The X in XSUM stands for extended, which indicates that the overall total for each row of a particular grouping will be calculated and retrieved. Extended versus Running aggregates (XSUM vs. RSUM ) are discussed later in this course. For database vendors who support SQL-OLAP aggregates such as Oracle and DB2, you can also quickly identify to what levels facts are aggregated. For example, Oracle uses sum and over syntax, as shown below:

select "T0"."C0" "ORDERDATE", "T0"."C1" "ACTUALREVENUE", sum("T0"."C1") over (order by "T0"."C0" asc rows unbounded preceding) "ACTUALREVENUE1" From




Activity: Identify stitch queries in generated SQL When running multi-fact queries, you must identify the components of the generated SQL. Understanding the patterns of correctly generated stitch queries will let you effectively troubleshoot improperly constructed queries. To that end, you will test various multi-fact query scenarios and explore the generated SQL. In this activity, you will accomplish the following: • Test fact queries individually • Test multi-fact and multi-grain queries • Identify improperly formed multi-fact queries

Test fact queries individually. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\12_Identify_stitch_queries_in_generated_SQL\GO Operational.

• If prompted, log in as admin/Education1. • In the Project Viewer pane, expand GO Operational Model > Consolidation

View. • Test the following items, with the Auto Sum check box cleared:

• Time > Month • Sales Fact > Revenue The Test Results dialog box appears. You will view the generated SQL before applying Auto Sum.





This is a basic query where the TIME_DIMENSION dimension and Sales Fact query subjects are joined. A derived table is generated in the Cognos SQL for Sales Fact since the Revenue column you selected in the query is based on a calculation. Again, Cognos SQL is more verbose. The native SQL does not require a derived table for this basic calculation based on columns from the same table. Note: Month1 appears in the generated SQL as opposed to Month because month is a reserved word. Therefore, a 1 is appended to avoid any conflicts.

• Click the Test tab, select the Auto Sum check box, and then click Test Sample.





XSUM has been applied in the Cognos SQL to aggregate Revenue to the month level. The sum function is used in the native SQL.

• Click Close. • In the Project Viewer pane, test the following items together from the

Consolidation View, ensuring Auto Sum is cleared: • Time > Month • Sales Target Fact > Sales Target





Because Sales Target rolls up to the month level (instead of day level), and you have specified determinants on the TIME_DIMENSION, an XMIN function and a group by clause is generated in the Cognos SQL. The XMIN function in the Cognos SQL (min in the native SQL) ensures that only one month value is returned for each month. The determinant for the month level specifies a multi-part key, which is why the derived table for TIME_DIMENSION uses a group by clause on CURRENT_YEAR and CURRENT_MONTH. This prevents double-counting for Sales Target, because the values are not aggregated for every day in the month, but rather at the grouped month level. Without the determinants, the generated SQL would not include the XMIN function or a grouping on the keys. You will test this in the next few steps. The X in XMIN will be covered in more detail later in this unit. XMIN is used in order to prevent 'dirty' data from slipping through. For example, the data may include Aug and August. By using min, only one of these values is selected, which results in a cleaner view of the data. If this is not desired, you can use the SQL Generation for Determinant Attributes governor to change the behavior.

• Click Close, expand Foundation Objects View > gosales, and then double-click TIME_DIMENSION.

• Click the Determinants tab, delete all the determinants except for the Day determinant, and then click OK.

• Test the following query items in the Consolidation View with Auto Sum cleared: • Time > Month • Sales Target Fact > Sales Target Remember, the items in the Consolidation View are based on items in the Foundation Objects View. You are testing the objects that authors will use.





The XMIN function and group by clause are no longer present. Now, if you aggregated Sales Target, each value would be double-counted, once for every day in the month for which it is associated. You can verify the effect of double-counting by retesting with Auto Sum enabled. Take note of the totals and then compare them to the values seen in the following steps when determinants are returned.

• Click Close, and then from the Edit menu, click Undo Edit Definition. The determinants have been added back to TIME_DIMENSION.

• Retest the same query items with Auto Sum enabled, and then click the Query Information tab. The results appear as shown below (the text may be formatted differently):

XSUM has been applied in the Cognos SQL to aggregate Sales Target to the month level. The sum function is used in the native SQL. The sales target values are correct now that determinants have been re-applied.

• Click Close.




Test multi-fact and multi-grain queries. Now that you have reviewed how the generated SQL appears for each of the fact queries individually, you will test them together. This task also illustrates multiple levels of granularity, since Revenue rolls up to the day level, and Sales Target rolls up to the month level.

• In the Project Viewer pane, in the Consolidation View, test the following items together, ensuring Auto Sum is cleared: • Time > Month • Sales Fact > Revenue • Sales Target Fact > Sales Target Note: due to the large data set, this query may take some time.


The generated Cognos SQL contains a Coalesce function, because Time is a conformed dimension between Sales Fact and Sales Target Fact. Auto Sum is not enabled, so there are two facts without a common level of granularity between them.




Because Revenue rolls up to the day level, and Sales Target rolls up to the month level, the RSUM(1….asc local) as sc syntax appears in both derived tables (D2 and D3), which are joined together by a full outer join. The full outer join uses two stitch columns, sc and sc4, to merge the two record sets together. The native SQL does not contain a full outer join. It is actually two separate queries sent to the database, since you are asking for local processing in the RSUM functions. Therefore, the merging is done locally. The merged results for Revenue and Sales Target will be related to Month, but not necessarily to each other.

• Click the Test tab, select Auto Sum, and then click Test Sample. • Click the Query Information tab.

The results appear as shown below (the text may be formatted differently):

The D2 and D3 derived tables represent the same generated SQL you saw when you tested the fact queries individually. However, they are now a part of a larger query that will merge them. There is also a common level of granularity between the queries because both are now aggregated to and grouped by the Month level. In the Native SQL, IBM Cognos is now sending a single query and requesting that the database process the full outer join.

• Click Close.




Identify improperly formed multi-fact queries. • In the Project Viewer pane, in the Consolidation View, test the following items

together with Auto Sum cleared: • Order Method > Order Method • Sales Fact > Revenue • Sales Target Fact > Sales Target


You can immediately tell that this query is suspect by the absence of the coalesce function. When you author multi-fact queries, you must include at least one conformed dimension. Other indicators are the generated stitch columns highlighted in the preceding graphic. Each one uses a different column to generate a key that will merge the queries.




• Click the Test tab, select Auto Sum, and then click Test Sample. The results appear as follows:

Sales Target repeats the overall total for each row.


The query can still be identified as an improper attempt to query multiple facts. There is no coalesce function, and you are sending two separate queries, one for each fact. The first derived table, which queries the Revenue fact, appears to be correct. But the second derived table, which queries the Sales Target fact, is simply requesting a distinct overall total. This value will be repeated for each row returned by the first derived table.

• Click Close, and then leave Framework Manager open for the next activity.




Examine the use of IBM Cognos SQL and generated SQL for DMR data IBM Cognos SQL in reports By default, IBM Cognos summarizes data in reports, as shown in the following example:

In the preceding example, Month1 is automatically grouped to roll Revenue and Total Revenue up to each individual instance of a month. This is done at the tabular level of the query. Extra aggregation may be done at the report layout level if summary footers are involved. If Auto Group & Summarize is turned off in IBM Cognos Analytics - Reporting, the XSUM does not appear at the tabular level, but will appear at the report level for any summaries in the report layout. The SQL in the preceding example is from the Generated SQL/MDX property of the query object, which displays the basic tabular query without any header/footer information. This is similar to the SQL Framework Manager generates when Auto Sum is enabled. When identifying the generated SQL at the tabular level in IBM Cognos Analytics - Reporting, you are not necessarily observing the SQL that will be submitted to the database. If the page contains fewer columns than are defined in the query object, the SQL may remove columns from the query at runtime that are not needed. For example, a list may show columns A and B but the tabular query has columns A, B, and C. Since column C is not required in the layout, it may be dropped at runtime. This can be determined by the generated SQL that is displayed from the Tools menu.




There may be two XSUMs, as in the following example:

When summary footers are created in the report, they are represented by another XSUM, as indicated in the previous example. Total_Revenue_ is aggregated at the tabular level (Auto Group & Summarize is turned on) as indicated by the inner XSUM, and then summarized for a summary footer for a particular grouping in the report layout as indicated by the outer XSUM. Typically, there will be a nested XSUM for footers because auto summarization is enabled in the report. If it were not enabled, there would be no nested XSUM. If rollup processing is done locally on the IBM Cognos Analytics servers, there will be RSUM instead of XSUM, as indicated below:

RSUM(XSUM(Sales_Fact.SALE_TOTAL for Time_Dimension.MONTH1) at Time_Dimension.MONTH1 order by Time_Dimension.MONTH1 asc local) as SALE_TOTAL1

The SQL in the preceding example is taken from IBM Cognos Analytics - Reporting's Generated SQL/MDX selection. This tool displays the SQL, including summary requests for footers.




Extended versus running aggregates Extended aggregate (XSUM, XAVG, XMIN) operations retrieve overall totals. They are found in generated SQL for queries run in batch mode (PDF, CVS, XML and so on), as indicated in the following example:

XSUM(XSUM(Sales_Fact.Revenue for TIME_DIMENSION.MONTH_EN) at TIME_DIMENSION.MONTH_EN ) as Total_Revenue_

Running aggregate (RSUM, RAVG, RMIN) operations calculate totals as they are needed. They are found in generated SQL for queries run in interactive mode (HTML), as indicated in the following example:

RSUM(XSUM(Sales_Fact.Revenue for TIME_DIMENSION.MONTH_EN) at TIME_DIMENSION.MONTH_EN) as Total_Revenue_

If the Rollup Processing property in Framework Manager or IBM Cognos Analytics - Reporting is set to default, IBM Cognos will generate the appropriate SQL based on the report output type. Depending on the selected setting, you can force extended aggregation for interactive reports. In the above examples, X represents extended aggregates, while R represents running aggregates. These functions may be calculated locally if you request the processing to be local to improve performance, or if the database vendor does not support the requested construct, such as SQL-OLAP constructs. Running aggregates are useful when you need to display the first page of an interactive report quickly. For these types of reports, a user may not observe all pages of the report. Therefore, where possible, a query should avoid computing information until the last possible moment. However, there are exceptions. For example, totals in headers, or comparing detail rows to group totals, may prevent the use of a running aggregate.

Example: Reverse engineering a Framework Manager model from generated IBM Cognos SQL You have been given some generated SQL from a report author who is concerned about the SQL, which uses explicit join syntax (INNER JOIN) rather than implicit join syntax (WHERE clauses). If you review the SQL, you can try to reverse-engineer the model, based on the query subjects used to author the report. During this process, you can note any unexpected SQL, and explain it. The following pages contain the SQL, and descriptions of its component parts.




Based on the generated SQL, the report would display as follows:




A high-level representation of the SQL query is shown below:




The model diagram, based on the query subjects used to generate SQL, is shown below:

The preceding example depicts these relationships: • Each instance of QUANTITY in the Sales Fact query subject is related to one and

only one instance of MONTH in the Time Dimension query subject. • Each instance of MONTH in the Time Dimension query subject is related to one or

more instances of QUANTITY in the Sales Fact query subject. • Each instance of MONTH in the Time Dimension query subject is related to one or

more instances of RETURN_QUANTITY in the Returned Items Fact query subject. • Each instance of RETURN_QUANTITY in the Returned Items Fact query subject

is related to one and only one instance of MONTH in the Time Dimension query subject.

• Each instance of RETURN_QUANTITY in the Returned Items Fact query subject is related to one and only one instance of REASON_DESCRIPTION in the Return Reason Dimension query subject.

• Each instance of REASON_DESCRIPTION in the Return Reason Dimension query subject is related to one or more instances of RETURN_QUANTITY in the Returned Items Fact query subject.




• Each instance of RETURN_QUANTITY in the Returned Items Fact query subject is related to one and only one instance of ORDER_METHOD in the Order Method Dimension query subject.

• Each instance of ORDER_METHOD in the Order Method Dimension query subject is related to one or more instances of RETURN_QUANTITY in the Returned Items Fact query subject.

• Each instance of ORDER_METHOD in the Order Method Dimension query subject is related to one or more instances of QUANTITY in the Sales Fact query subject.

• Each instance of QUANTITY in the Sales Fact query subject is related to one and only one instance of ORDER_METHOD in the Order Method Dimension query subject.

When testing regular dimensions in Framework Manager, the generated SQL can include columns that you did not select. This occurs when you test levels that have attributes specified. This is does not happen in IBM Cognos Analytics - Reporting, where only the items required for OLAP-style querying are requested. In Framework Manager, you are always testing all objects in the parent container. For example, if you test a query subject you are in fact requesting all query items in that query subject. When you test a level in a regular dimension, you are requesting the business key, member caption and any attributes. When you add a level to the report, IBM Cognos Analytics will only request the business key and the member caption and parent keys unless you specifically ask for other attributes of the level.




Activity: Examine generated SQL in a report As a modeler, you need to understand SQL patterns that may be generated in IBM Cognos Analytics - Reporting to help troubleshoot problems encountered by authors, or to simply answer their questions. By testing the model in IBM Cognos Analytics - Reporting and observing the generated SQL for different aggregation scenarios, you can identify these patterns and learn how to identify what a report is requesting. In this activity, you will accomplish the following: • Author a simple report in IBM Cognos Analytics - Reporting and observe the

generated SQL • Create a footer and display the generated SQL

Author a simple report in IBM Cognos Analytics - Reporting and display the generated SQL. • Ensure you are logged into IBM Cognos Framework Manager as admin

(password is Education1), with the C:\Training\B6252G\CBIFM-Start Files\12_Identify_stitch_queries_in_generated_SQL\GO Operational project open.

• In the Project Viewer pane, expand Packages, and then publish the GO Operational (query) package, overwriting the existing package, and clearing the Verify the package before publishing check box when prompted.


• Click Team content, point to the GO Operational (query) package, click More, and then click Create report.


defaults. You do not want the report to automatically include a summary row.


summary behavior for lists check box is cleared, and then click OK.




• On the Sources tab, expand Sales (query), and then add the following items to the report: • Time > Month • Sales Fact > Revenue

• In the breadcrumb trail above the Insertable objects pane, click Report, and then click Query1.

• If the Properties pane is not open, then in the upper-right corner, click Show properties to open it.

• In the Properties pane, double-click Generated SQL. A warning message appears indicating that you will be viewing a tabular representation of the query. Viewing the generated SQL by this method lets you see the SQL specific to this query. Header and footer summaries are not reflected in this SQL because it is specific to the report.

• Click OK, and then from the list at the top left of the dialog box, select IBM Cognos SQL. The results appear as follows:

Because the Auto Group & Summarize property is set to Yes (by default), there is an XSUM for Revenue. To see detailed rows of data, set this property to No, which tells IBM Cognos not to apply the sum function.

• Click Close.




Create a footer and display the generated SQL. • From the breadcrumb trail, click Report, and then click Page1. • In the report, click the Revenue column header, from the on-demand toolbar, click

Summarize , and then click Total. The report appears as shown below:

A Total Revenue row appears at the bottom of the report.

• From the breadcrumb trail, click Report, and then click Query 1. • In the Properties pane, double-click Generated SQL. • Click OK to close the warning, and then select IBM Cognos SQL.


The SQL is similar to that in the previous task, except that the tabular SQL is requesting a second summed Revenue as Total Revenue. This does not mean that two identical requests for Revenue will be sent to the database at run time. This just represents the data items that make up the query at the tabular level. The derived table only requests Revenue once. If you look at the native SQL, you will also see only one request is made for revenue aliased as C1.




• Click Close.

• In the upper-right corner above the Properties pane, click Manage , and then click Show generated SQL/MDX. Viewing the generated SQL by this method allows you to see the complete SQL statement including footer summary requests.

• From the list, select IBM Cognos SQL. The results appear as follows:

The additional XSUM for the Revenue column populates the report footer. If you change the Rollup processing property to Local, you will see an RSUM instead of an XSUM. This is illustrated in the Optimize and Tune Framework Manager Models unit. If you turn off Auto Group & Summarize, you will not see nested XSUMs, since you would then be aggregating detailed rows for the footer and not summarized values. You will test this in the next steps.




• Select Native SQL. Footer summary information is not requested, which indicates that the footer summary information will be processed locally on the IBM Cognos servers. This environment uses a DB2 data source. The request for the footer summary is processed locally because DB2 does not support SQL-OLAP. If the data source were an Oracle database, you would see SQL-OLAP syntax requesting the footer value as shown below: select "T0"."C0" "MONTH1", "T0"."C1" "Revenue", sum("T0"."C1") over () "Total_Revenue_" from (………) "C1" where ………. group by ………..

• Click Close. • In the Properties pane, click the cell beside Auto Group & Summarize, and then

set the value to No. • In the upper-right corner, click Manage, click Show generated SQL/MDX, and

then from the list, select IBM Cognos SQL. The results appear as follows:




The footer value (Total_Revenue_) is now based on the aggregation of detailed rows, rather than summarized values. In the Native SQL, Revenue is now requested twice from the database: once as detail rows aliased as C1, and again as a summarized row using the sum function aliased as C0. This type of aggregation is supported by the database and is therefore conducted at the database level.

• Click Close, and then close the report without saving it. • Leave IBM Cognos Analytics and Framework Manager open for the next

activity.




Activity: Examine generated SQL for DMR metadata

When testing DMR levels in either Framework Manager or IBM Cognos Analytics - Reporting, you should be aware of the SQL generation behavior in either scenario so that you can verify the modeling techniques. In this activity, you will accomplish the following: • Test a level in the Products regular dimension in Framework Manager • Test a level in the Products regular dimension in IBM Cognos Analytics - Reporting

Test a level in the Products regular dimension in Framework Manager. • Ensure you are logged into IBM Cognos Framework Manager as admin

(password is Education1), with the C:\Training\B6252G\CBIFM-Start Files\12_Identify_stitch_queries_in_generated_SQL\GO Operational project open.

• In the Project Viewer pane, expand Dimensional View > Products > Products.

• Test the Product level (below Product Type), and then click the Query Information tab. The results appear as follows (the text may be formatted differently):

The projection list is requesting columns other than the business key (PRODUCT_NUMBER) and member caption (PRODUCT_NAME + PRODUCT_NUMBER). PRODUCT_IMAGE, INTRODUCTION_DATE, and DISCONTINUED_DATE are attributes of the Product level, and PRODUCT_DESCRIPTION is the member description.

• Click Close, and then double-click the Products regular dimension to open the Dimension Definition dialog box.




• In the Hierarchies pane, click the Product level. The results appear as follows:

This displays the member description and other attributes that were returned when you tested the Product level. In Framework Manager, these columns are returned to show the contents of the level. These columns would not necessarily be returned in IBM Cognos Analytics - Reporting unless requested. Only the member caption and business key are returned with the level's parent keys, which you will see in the next task.

• Click Cancel, and then publish the GO Operational (analysis) package, overwriting the existing package and clicking Close to close the informational messages.

Test a level in the Products regular dimension in IBM Cognos Analytics - Reporting. • In IBM Cognos Analytics, click Team content, point to

GO Operational (analysis), click More, and then click Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults.




• In the Sources tab, expand Sales (analysis) > Products > Products, and then drag the Product level onto the report.

• In the upper-right corner above the Properties pane, click Manage , and then click Show generated SQL/MDX.

• From the list, click IBM Cognos SQL. The results appear as follows:

The projection list only requests the member caption (PRODUCT_NAME + PRODUCT_NUMBER), the business key (PRODUCT_NUMBER), and parent business key and member caption columns. The parent information is returned to support drill operations such as drill-up, drill-down, and drill-through.

• Click Close, and then from the Application bar, sign out as Admin Person, without saving it.

• Close the web browser. • In Framework Manager, close the project, saving if prompted, and then close

Framework Manager.




Other query considerations Using cross-product joins A cross-product join combines data by matching each row in one table to each row in another table, as in the following example:

In the preceding example, the Manager table has two rows (Philippe and Beatrice) and the Product table has three rows (1, 2, and 3). The resulting report set has two columns (Sales Rep and Product) and six rows that match Philippe and Beatrice with products 1, 2, and 3. A Cross-product join is also known as a Cartesian product. A cross-product join occurs when there is no relationship between two query subjects. It is not the same thing as a full outer join. The results and aggregation totals for these types of queries are typically meaningless. By default, Framework Manager does not allow cross joins because they can be resource intensive. Sometimes this type of join produces meaningless results, but under the right circumstances, it can be very useful. For example, you could use this to combine each product with a pricing table so you can analyze each product at each price. In one table, you have the current price of each product. In a second table, you have a list of increase values such as .05 percent, .06 percent, .10 percent, and so on. In this case, a cross join combines each product price with each increase value.




Cross-product join SQL The SQL for a cross-product join selects the requested columns from their respective tables where no joins exist, as in the following example: select Manager.Manager as Manager, Product.Product as Product from datasource_name.database_name.schema.Manager Manager datasource_name.database_name.schema.Product Product

Multi-fact query results A contiguous result set uses only conformed dimensions, as in the following example:

In a correlated list, non-conformed dimensions are present, as indicated below (note the new column, ORDER_METHOD, and the repeated values for EXPECTED_VOLUME):

Interpreting a multi-fact query is not as easy as authoring one. It is important to understand the impact of conformed and non-conformed dimensions on a multi-fact query, and the level of granularity and additive nature of the data. A contiguous result set means the results of each fact query can be mapped to each other with 0..1 to 1..0 precision. A correlated list refers to a looser coupling of the data in which non-conformed dimensions have been introduced. In the above example, a non-conformed dimension (ORDER_METHOD) introduces a difference in granularity. In this case, the result is more closely related to a master-detail report. There are dimensions that both queries have in common, and a dimension that is not common to both. This additional level creates a 0..n relationship between the fact queries, resulting in 0..n records in query 2 for any record in query 1.




ORDER_METHOD is related to QUANTITY and therefore further breaks down QUANTITY values into the various order methods used to sell products. Because EXPECTED_VOLUME is not related to ORDER_METHOD, the overall EXPECTED_VOLUME totals for each instance of PRODUCT_NAME are simply repeated across each new ORDER_METHOD instance, but not double counted.

Contiguous result sets Multi-fact queries with only conformed dimensions can have different levels of granularity, as shown here: Common grain from conformed dimensions

Different levels of granularity from conformed dimensions

The top report in this example illustrates the same contiguous result set shown previously. There has only been an element from the Time Dimension included at the month level. There is a common grain between the two fact tables because QUANTITY is automatically rolled up to the month level and EXPECTED_VOLUME is a value that begins at the month level. If DAY_DATE is included in the report (as indicated in the bottom report example), there will still be a contiguous result set, but with another level of granularity. Provided determinants have been specified on the Time Dimension, IBM Cognos will still stitch and aggregate the facts correctly, but there will be repeating values on the higher level of granularity. Although it has the appearance of a correlated result set, it is not. The facts are stitched together by only conformed dimensions (Time Dimension and Product Dimension). Adding a lower granularity level than the common level between facts causes repeating values for the fact at the higher level. With determinants specified, IBM Cognos will not double-count the values at the higher level of granularity, as shown in the following graphic:




Multi-Fact/Multi-Grain Report

As indicated in the example above, EXPECTED_VOLUME is not double counted because the determinants specified on the Time Dimension dictate that those values should be aggregated to, and grouped by, the month key.

Troubleshooting unexpected results When the data results are unexpected, check the SQL: • What kind of joins are there? • Do they correspond with the relationships you have in Framework Manager? • Is there a stitch query that you do not expect? • Is there a stitch query without all required conformed dimensions? • Is there a stitch query with no conformed dimensions? Do you have determinants specified for multiple levels of granularity in a single query subject? Are you using the correct SQL options? You may also want to check the native SQL to verify if it is expected.




Use session parameters, prompt macros, and security macro functions Defining IBM Cognos session parameters A session parameter is a variable associated with an IBM Cognos session. There are two types of session parameters: environment and model. Each session parameter must have a name and a default value to ensure the session parameter resolves to a value at run time. You cannot have more than one session parameter with the same name. You can set override values only for testing inside the model. The modeler defines model session parameters, while environment session parameters are defined in the user's environment, such as user ID and locale setting. The amount of environment session parameters IBM Cognos Analytics identifies depends on the environment. For example, if a user is on an NT domain, there will be fewer session parameters available than if they were using LDAP as an authentication provider. A session lasts from the time a user logs on until the time they log off or time out. If you log on anonymously, you will observe only runLocale and account.defaultName(Anonymous).

Environment session parameters Environment session parameters are predefined and stored in the content store database. By default, the following session parameters appear in Framework Manager: • account.defaultName • account.personalInfo.userName • runLocale For example, the session parameters available for an LDAP provider include account.personalInfo.email and account.personalInfo.givenName. If the LDAP provider supports custom parameters, they can be exposed in Framework Manager. In the following example, a macro is used to look up the current user in a parameter map to provide an appropriate value for the Where clause of the generated SQL:




You can use environment session parameters in filters, SQL statements, property settings, and other model objects to create a model with dynamic values.

Model session parameters Model session parameters are created in Framework Manager and published with every package. They can include the use of existing environment session parameters and static values. Model session parameters can be useful when you are trying to centralize the maintenance on a macro that is used throughout a model. For example, a model may have many instances of multilingual data that the modeler must build a macro for. Creating a model session parameter that uses this macro can simplify the SQL for the multilingual query subjects, as indicated in the following example:

The modeler simply inserts the UserLanguage session parameter. UserLanguage will be substituted for the value returned by the #Language_lookup{$runLocale)# macro. If the macro, or the parameter map it uses, needs to be changed, it can be done in one location, without affecting the rest of the model.




Filtering data by package access To filter data by package access, you can create model session parameters with static values. These values are then published with the package. By using a model session parameter, you can centrally control a value throughout your model. In the example below, the value is static and controls which country for which a user can display values:

In the preceding example, the filter expression generates a Where clause in which Country code equates to 6001, which is the value specified in the model session parameter.

Custom environment session parameters Custom environment session parameters require a customizable LDAP security provider and are exposed to IBM Cognos through IBM Cognos Configuration. They appear as session parameters in Framework Manager. Microsoft Active Directory and Sun Java System Server are both supported with respect to custom environment session parameters. Attributes available from an LDAP security provider are exposed to IBM Cognos as custom properties through IBM Cognos Configuration. You can use these custom properties in macros as you would any of the other session parameters. You can also use the custom properties inside command blocks that configure Oracle sessions and connections. These command blocks can be used with Oracle lightweight connections and virtual private databases.




Where can you use session parameters? Session parameters can be used in macros to dynamically change many model elements, including: • object properties, such as content manager data source, catalog, and schema

properties in data source connections • SQL in a data source query subject • filter and calculation syntax • stored procedure arguments • model session parameter values Although you can add macros to the SQL of a data source query subject, it is recommended to do this in the model query subject layer to make maintenance easier.

What prompt macros allow you to do Prompt macros allow you to do the following: • provide prompt names • specify data types • provide default values • use Prompt Info properties • append text • make filters and prompts optional • request single or multiple values The token data type is used for passing SQL syntax. You can reference query items allowing the use of the Prompt Info property setting. You can append text at the beginning or end of the prompt. Specify a default value to make the prompt optional. If no default value is specified, the prompt is mandatory. You can use either the prompt function for single values, or the promptmany function for multiple values.




Using the prompt macro function The prompt macro allows the end user to enter a single value (in the following example, a token value) to dynamically affect the SQL generated for selecting a language based column:

For example, select rows from the MONTH_FR column if the FR parameter is supplied by the user. If no value is supplied, the default EN value will be used, which will return rows from the MONTH_EN column.

Using preceding text in a prompt The following prompt macro uses the prompt function with preceding text to allow end users to select the data source to which they would like to connect:

The prompt macro uses preceding text to specify the data source name which is concatenated to a value supplied by the user. If the user supplies a value of 2, it will result in a data source name of great_outdoors_warehouse.

What are the security macro functions? There are five macro functions associated with security: • CAMIDList • CAMIDListForType • CAMPassport • CSVIdentityName • CSVIdentityNameList These macro functions retrieve security-related information from a user's session and can be used in a macro to filter data or display user information in a calculation.




CAMIDList, CSVIdentityName, and CSVIdentityNameList are used to retrieve account, group, and role information. The following section will focus on CSVIdentityName and CSVIdentityNameList. CAMIDList and CSVIdentityNameList both return information related to the authentication for the current user(s). However, CAMIDList returns complex information, such as namespace and user IDs, which requires parsing to obtain the information you wish to retrieve for the reporting environment. CAMPassport returns the current user's CAM passport. This can be useful when implementing single sign-on from a report to a custom IBM Cognos SDK application. CAMIDListForType returns an array of the user's identities, based on the identity type (account, group, or role).

CSVIdentityName This macro function retrieves account, group, and role information for the current user. You can use it as a key in a parameter map to implement row-level security based on values stored in a data source. In the following example, the parameter map is called SecurityLookup. If the user belongs to the security group or role by the name of Americas, then they will have access to data from Canada and the United States. If they also belonged to Europe and Australia, then they would notice data from these locations as well, as indicated below:

Each value in the comma-separated value list for the current user is passed to the parameter map for evaluation and if a match is found for the key, it is substituted with the corresponding value. If the user did belong to the Americas, Europe, and Australia groups, then the resulting filter would appear like the following:

[Business view].[Employee].[Security_Access] in ('NA','EU','AU')




CSVIdentityNameList This macro function returns a separator-delimited list of the account, group, and role information for the current user. You can use it to filter on data that has the same name as the account, group, or role information returned in the delimited list. In the following example, the city column will be filtered on Lyon:

[Business view].[Retailer site].[City] in (#CSVIdentityNameList()#) [Business view].[Retailer site].[City] in ('Everyone','Authors','Lyon')

The resulting database table is displayed below:




Activity: Use custom environment session parameters

Report authors need to filter reports based on location. To support this, you will use a custom property that the Administrator created in the Sample Outdoors Company LDAP authentication provider. You will make this custom property available as a session parameter in Framework Manager, and then use that parameter in a model filter. In this activity, you will accomplish the following: • View the customized Location session parameter in Framework Manager • Create a model filter that uses the custom parameter • Test the model filter in IBM Cognos Analytics - Reporting

View the customized Location session parameter in Framework Manager. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\13_Use_custom_environment_session_parameters\GO Operational.

• Log on as brettonf (password=Education1). Tip: If you are not prompted to log in, from the Project menu, click Logoff, and then click Log on again. Frank Bretton is a report author that works out of the Calgary office.




• From the Project menu, click Session Parameters. The results appear as follows:

The current user (Frank Bretton) has an account.parameters.Location parameter set to Calgary, which identifies the city in which he works.

• Click Cancel.

Create a model filter that uses the custom parameter. • Expand GO Operational Model > Presentation View, right-click the GO

Operational Sales (query) namespace, point to Create, and then click Filter. The Filter Definition dialog box appears.

• In the Name field, type My Location, and then in the Expression definition pane, enter the following: [Consolidation View].[Staff by Location].[Staff City] =

• Under Available Components, click the Parameters tab, expand Macro Functions, and then double-click sq to add it to the expression definition. Tip: You can view syntax assistance for macro functions by selecting them and viewing the Tips pane. There you can see explanations of the functions as well as examples.

• Expand Session Parameters, and then double-click account.parameters.Location to add it to the expression definition. The expression appears as shown below: [Consolidation View].[Staff by Location].[Staff City] = #sq($account.parameters.Location)#

This filter uses the custom environment session parameter called Location to focus a query.

• Click OK.




• In the Project Viewer pane, expand Packages, double-click GO Operational (query), and then select My Location to add it to the package. The results appear as follows:

• Click OK, and then publish the GO Operational (query) package without verifying

the package, and overwriting the existing package when prompted. • Save the project in C:\Training\B6252G\Course_project, overwriting the previous

project.

Test the model filter in IBM Cognos Analytics - Reporting. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as brettonf/Education1. • Click Team content, point to GO Operational (query), click More, and then click


defaults. • In the upper-right corner, click the arrow beside Page design, and then click

Page preview. • On the Sources tab, expand Sales (query), and then add the following items to

the report: • Staff by Location > Staff City • Sales Fact > Revenue All cities and their revenue appear.

• From the Sources tab, drag the My Location filter onto any column in the report. A message indicates that the report is now filtered by My Location.




• Click OK. The results appear as follows:

Because you are logged in as Frank Bretton, the report is filtered by his city, Calgary, using the custom environment session parameter.

• Close the report without saving it. • Leave Framework Manager and IBM Cognos Analytics open for the next

activity.




Activity: Dynamically change the data source connection

The Sample Outdoors Company has different databases with the same structure but different data that serve different regions of the business. You need to support the dynamic selection of a database, based on the current user. You will do this by using a macro and session parameter to change the Content Manager Datasource connection name at run time. In this activity, you will accomplish the following: • Create a data source lookup parameter map • Add a macro to the data source properties • Test the data source property macro

Create a data source lookup parameter map. • Ensure you are logged into IBM Cognos Framework Manager as brettonf


• In the Project Viewer pane, right-click Parameter Maps, and then click Create > Parameter Map.

• In the Name field, type DataSourceLookup, and then click Next. • In the Default value box, type GOSALES. • Under Key, in the first row, type brettonf, and then under Value, type GOSALES. • Under Key, in the second row, type scottb, and then under Value, type

GOSALES2. The results appear as follows:

• Click Finish.




Add a macro to the data source properties. • If the Properties pane is not open, click View > Properties. • In the Project Viewer pane, expand Data Sources, and click GOSALES. • In the Properties pane, beside the Content Manager Data Source property, click

GOSALES, and then click the ellipsis. The Edit Property Value dialog box appears.

• In the Value box, delete the GOSALES text, and then click the Insert Macro button. The Macro Editor dialog box appears.

• Under Available components, expand Parameter Maps, and then double-click DataSourceLookup to add it to the definition.

• Under Available components, expand Session Parameters, and then drag account.personalInfo.userName inside the brackets of the DataSourceLookup parameter map. The macro definition appears as follows: #$DataSourceLookup{$account.personalInfo.userName}#

• Click OK. The Value pane displays the new macro.

• Click OK.

Test the data source property macro. You are currently logged on to Framework Manager as Frank Bretton. You will test this account first.

• Expand GO Operational Model> Consolidation View > Return Reason, and test the Return Reason Description query item.

• Click the Query Information tab. The results appear as follows: Cognos SQL select RETURN_REASON.REASON_DESCRIPTION_EN as Return_Reason_Description from GOSALES..GOSALES.RETURN_REASON RETURN_REASON

Notice that the data source connection name is GOSALES. You will now log on as a different user to dynamically use another data source connection.




• Click Close. • Click Project > Logoff, and then log on again as scottb/Education1. • If a new IBM Cognos Analytics window appears, close it. • In Framework Manager, test Return Reason Description again.

The results appear as follows: Cognos SQL select RETURN_REASON.REASON_DESCRIPTION_EN as Return_Reason_Description from GOSALES2..GOSALES.RETURN_REASON RETURN_REASON

Notice that the data source connection name has changed to GOSALES2. For this technique to work, the underlying database structures must be mirror images with the exception being the data they contain. Note: If you get an error message, launch IBM Cognos Administration (from IBM Cognos Analytics > Manage > Administration console > Configuration tab), and then verify that the GOSALES2 data source connection is defined as follows: • Name: GOSALES2 • Type: IBM DB2 (deselect Configure JDBC connection) • Database name: GS_DB • User ID: GOSALES • Password: Education1

• Click Close. • From the Project menu, click Logoff, and then log on again as

admin/Education1. • If a new IBM Cognos Analytics window appears, close it. • Test the Return Reason Description query item again, and then click the Query

Information tab. The query uses the default parameter map value of GOSALES because the admin user is not a value in the parameter map.

• Click Close.




• Save the project and leave it open for the next activity. Note: You can also set up a dynamic data source connection when you configure your data source connections. For example, you can create one data source, and then create multiple connections for that data source. Each connection points to a different version of the database, which contains region-specific data. You would then apply security on each of the connections. When a user accesses the data source, they will automatically use the connection to which they have access. If a user has access to more than one connection, they will be prompted at run time to select the connection they want to use. To support multiple data source connections in your Framework Manager project, you must clear the data source catalog and schema properties. This information is obtained from the connection information at run time.




Activity: Create prompt macros to filter data Report users want to choose which data source they will connect to, rather than connecting to a data source based on their user ID. You will use a prompt function in the data source properties to support this requirement. As well, report users want to be prompted for the reason why items are returned, and be able to supply one or more values for the Return Reason code. In this activity, you will accomplish the following: • Apply a prompt macro in the data source properties • Apply a filter to the Return Reason Dimension query subject

Apply a prompt macro in the data source properties. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In the Project Viewer pane, expand Data Sources, and select the GOSALES data source.

• In the Properties pane, for the Content Manager Data Source property, change the macro to the following: #prompt('Enter data source number', 'int', 'GOSALES', 'GOSALES')#

This prompt syntax requests a number value from the user and appends it to the preceding text specified, in this case, GOSALES. If no value is specified, then the default value of GOSALES will be used.

• Click OK, and then click OK again. (Also click OK to close any additional dialog boxes that may appear.)

• In the Consolidation View namespace, test the Order Codes query subject, setting the prompt value to 2, and ensuring that Always prompt for values when testing is selected. Note: If you are not prompted as expected, in the Test Results window, click Options, and then in the Options dialog box that appears, click the Prompts button. In the Model Prompts Manager, you can modify the prompt as instructed.




• Click OK to close the Prompt Values dialog box, and then in the Test Results dialog box, click the Query Information tab. The results appear as follows: Cognos SQL select Order_Codes.Order_Number as Order_Number, Order_Codes.Order_Detail_Code as Order_Detail_Code from (select ORDER_DETAILS.ORDER_NUMBER as Order_Number, ORDER_DETAILS.ORDER_DETAIL_CODE as Order_Detail_Code from GOSALES2..GOSALES.ORDER_DETAILS ORDER_DETAILS ) Order_Codes

Notice that the data source name is GOSALES2. The value of 2 provided in the prompt was appended to the preceding text GOSALES. This query has gone against the GOSALES2 data source.

• Click the Test tab, and then click Test Sample, leaving the prompt value blank, if prompted, and then click OK.

• Click the Query Information tab. The results appear as follows: Cognos SQL select Order_Codes.Order_Number as Order_Number, Order_Codes.Order_Detail_Code as Order_Detail_Code from (select ORDER_DETAILS.ORDER_NUMBER as Order_Number, ORDER_DETAILS.ORDER_DETAIL_CODE as Order_Detail_Code from GOSALES.GOSALES.ORDER_DETAILS ORDER_DETAILS ) Order_Codes

Notice that the data source name is now GOSALES. The default value of GOSALES is used. This query has gone against the GOSALES data source. If a value of anything other than blank or 2 were provided at this point it would return an error because, in this environment, there is no data source configured in the content store other than GOSALES and GOSALES2.




• Click Close. You can achieve the same effect in IBM Cognos Analytics by giving a user access to more than one connection associated with a defined data source. If a user has permissions to access more than one connection for a data source, they will be prompted at run time to select a connection.

Apply a filter to the Return Reason Dimension query subject. • In the Consolidation View namespace, double-click the Return Reason model

query subject to open the Query Subject Definition dialog box. • Click the Filters tab, and then add a filter named

Prompt Many for Return Reason, with the following expression: [Consolidation View].[Return Reason].[Return Reason Code] in (#promptmany('Enter Return Reason Code(s)','integer')#)

• Click OK to close the Filter Definition dialog box, click the Test tab, and then click Test Sample. You are prompted to enter values.

• Click the Value field for Enter Return Reason Code(s). A multi-value prompt dialog box appears:

• In the Provide a value field, type 1, and then click the right arrow to add the value to the Choices list.

• Repeat to add the values 3 and 5. • Click OK, and then click OK again.


Only the values that you typed are returned. This is a mandatory prompt since no default values have been provided. If you do not provide a value, you cannot proceed beyond the prompt.





Activity: Leverage a macro function associated with security

Report authors need to be able to filter report results based on retailers located in the user's city. The IT department has set up an LDAP authentication provider with groups based on city names and has added the appropriate users to each group. With this knowledge, you can leverage the group names from the authentication provider in your filter through the CSVIdentityNameList macro function. Report consumers also need to obtain their personal IBM Cognos security information. To accomplish this, you will create a calculation that will return this information for them. In this activity, you will accomplish the following: • Create a filter using the CSVIdentityNameList macro function • Test the Retailers Near Me filter • Create a calculation to retrieve a user's IBM Cognos security information • Test the security information calculation in IBM Cognos Analytics - Reporting

Create a filter using the CSVIdentityNameList macro function. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In the GO Operational Model > Presentation View namespace, right-click the GO Operational Sales (query) namespace, and then create a new filter called Retailers Near Me.

• In the Available Components pane, expand Consolidation View > Retailer by Location, and then add Retailer City to the expression definition.

• In the Expression definition pane, after [Consolidation View].[Retailer by Location].[Retailer City], type in (.

• Under Available Components, click the Parameters tab, and then expand Macro Functions.




• Double-click CSVIdentityNameList to add it to the expression definition, and then type ) to complete the expression. The results appear as follows: Expression definition [Consolidation View].[Retailer by Location].[Retailer City] in (#CSVIdentityNameList()#)

Tips pane [Consolidation View].[Retailer by Location].[Retailer City] in ('Admin Person', 'All Authenticated Users', 'Cognos', 'Everyone', 'LDAP', 'System Administrators') Notice the comma-separated list that appears in the Tips pane after the word in. This list is alphabetical and indicates the user's name and all the groups and roles to which they belong. The test user you will use is Daniel Turpin who belongs to a group called Lyon named after the city where he works.

• Click OK. • Click Project > Logoff, and then log on again as turpind/Education1. • If a new IBM Cognos Analytics window appears, close it. • Double-click the Retailers Near Me filter.

The results appear as follows: Expression definition [Consolidation View].[Retailer by Location].[Retailer City] in (#CSVIdentityNameList()#)

Tips pane [Consolidation View].[Retailer by Location].[Retailer City] in ('All Authenticated Users', 'Authors', 'Cognos', 'Daniel Turpin', 'Everyone', 'LDAP', 'Lyon', 'Query Users', 'Sales Reps') Notice the group called Lyon.

• Click OK. • Log off, and then log on again as admin/Education1. • If a new IBM Cognos Analytics window appears, close it.




• In Packages, double-click GO Operational (query), and then select Retailers Near Me. The results appear as follows:

• Click OK, and then publish the GO Operational (query) package, clearing Verify

the package before publishing and overwriting the existing package when prompted.


Test the Retailers Near Me filter. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as turpind/Education1 (you may have to first sign out as another user).

• Click Team content, point to GO Operational (query), click More, and then click Create report.


defaults. • Expand Sales (query), and then add the following items to the report:

• Query subject = Retailer by Location, Query items = Retailer City, Retailer Name

• Query subject = Sales Fact, Query item = Revenue • Click the Retailer City column, and then from the on-demand toolbar, click

Group/Ungroup. • Drag the Retailers Near Me filter onto the report, and click OK to close the

message.




• Run the report in HTML. A prompt appears because you created a prompt on the data source.

• In the Enter data source number prompt field, type 2, and then click OK. A section of the results appears as follows:

The report is now filtered on Lyon since that is the group to which Daniel Turpin belongs.

• Close the rendered report tab, and then close the current report without saving it.

Create a calculation to retrieve a user's IBM Cognos security information. • In Framework Manager, in the Presentation View, right-click the

GO Operational Sales (query) namespace, point to Create, and then click Calculation.

• In the Name field, type My Security Info. You will use the sq (single quote) function, the csv (comma separated values) function, and the CAMIDListForType function to return the user's roles. The sq function places the entire results in single quotes making it a string. The csv function takes the results of the CAMIDListForType function and separates the values with a comma. The CAMIDListForType retrieves specific security information for the user based on a parameter. You can request the user's roles, groups, or account.

• Use the Parameters tab to create the following expression: #sq(csv(CAMIDListForType('role')))#

In this expression, role has been hard coded into the CAMIDListForType function to return the user's roles.




• Click the Test Sample button. The results are similar to the following: 'CAMID("::System Administrators")'

You are logged on as the admin user, which belongs to the System Administrators, role. You can change the role value in the expression to Group or Account to retrieve different security information.


Test the security information calculation in IBM Cognos Analytics - Reporting. • In Packages, double-click GO Operational (query), and select the

My Security Info calculation. • Click OK, and then Publish the package without verifying the package, and

overwriting the existing package when prompted. • Ensure you are signed in to IBM Cognos Analytics (http://localhost:9300/bi/) as

turpind/Education1 (Daniel Turpin). • Click Team content, point to GO Operational (query), click More, and then click


defaults. • Drag the My Security Info calculation to the list, and then run the report in HTML.

The results appear as follows: 'CAMID(":Authors")','CAMID(":Query Users")'

This user belongs to the Authors and Query Users roles. • Close IBM Cognos Analytics - Reporting without saving. • Close IBM Cognos Framework Manager, saving if prompted.




Use materialized views, minimize SQL, and enable Dynamic Query Mode (DQM) Why use materialized views? IBM Cognos queries typically aggregate data. Materialized views that contain aggregated values can significantly improve performance. Below is an example of how values in a fact table can be aggregated in a materialized view.

Base Sales Fact Table Materialized View for Sales Facts Measures at the day level Measures aggregated to the month level

Materialization is a benefit for relational models. However, it is highly recommended with dimensional modeling. Modeling relational data dimensionally adds another layer in your model which enables OLAP behaviors in reports. In addition, database optimization can capitalize on materialized views. To provide the best performance, materialization in the database should be in place. Common database vendor implementations include: • Microsoft SQL Server - view index • Oracle - materialized view • IBM DB2 UDB - materialized query tables • NCR Teradata - aggregate join indexes • Informix RedBrick - VISTA

Achieving minimized SQL Minimized SQL is more likely to take advantage of database optimization, compared to more complex SQL. However, there may be times when losing SQL minimization is necessary, such as when you need to: add a relationship to model query subjects with overriding relationships, to change the SQL of data source queries, or to add filters, calculations, or determinants. When you add a relationship to a model query subject that comprises two or more underlying query subjects that have relationships to each other, the underlying joins will be honored. This is considered As View behavior. Also, if the SQL for data source query subjects is altered, there is potential for minimized SQL to be lost. For example, hard coding a join in the SQL will force that join in each query using items from that query subject. Consider using SQL minimization as you model, not towards the end of development.




What is Dynamic Query Mode (DQM)? DQM is an enhanced query execution mode that optimizes query planning, execution, and results. With DQM, users get the right information quickly without compromising security. It is the recommended mode for creating new IBM Cognos Analytics applications in a supported environment. DQM is a Java-based query mode which offers: • Query optimizations that address query complexity, data volumes, and timeliness

expectations, with improved query execution techniques. • Significant improvement for complex OLAP queries through intelligent combination

of local and remote processing and better MDX generation. • Support for relational databases through JDBC connectivity. • OLAP functionality for relational data sources when using a dimensionally modeled

relational (DMR) package. • Security-aware caching. Non-DQM projects can be tested, published, or migrated to dynamic query mode. By default, all packages created in Framework Manager version 10.1 and earlier are created in Compatible Query Mode (CQM). If your data sources are supported, you can take advantage of Dynamic Query Mode capabilities by either creating a new DQM project, or converting an existing project to DQM.

Using dimensional metadata with DQM When used with dimensional metadata, DQM offers: • Enhanced member sorting capabilities • The ability to perform complex aggregate computations • Greatly improved query performance • Optimized SQL statements that create an in-memory cube for OLAP over

Relational (OOR) reporting Dynamic Query Mode supports a consistent OLAP-style experience across data sources and IBM Cognos Analytics. When you publish a DMR package from a DQM-enabled project, it is available to report authors as an OLAP over Relational (OOR) package. The first time you run a report that is based on an OOR package, the query engine creates a virtual cube. Subsequent queries can then re-use the objects that already exist in the cube, and continue to build the in-memory cube by adding newly queried objects.




Note: To avoid the performance impact of creating the cube for the initial query, you can pre-run a report during off hours to populate the cache for the day.

Member sorting in DQM Member order is vital for OLAP analysis to ensure consistent results, especially when using member relative functions, such as NextMember and ClosingPeriod. In CQM, you can declare sort orders by level in regular dimensions. However, if no sort order is specified, SQL returns the members in whatever order it retrieves them from the relational tables. Since SQL does not order by default, results can be unpredictable. Sorting options for dimensional metadata are not required in dynamic query mode. With OLAP over Relational, DQM specifies a natural order (sort on parent) to all result sets. Child members are only ordered within their parent members, even if all members of a level are reported, as shown in the following example:

If no ordering is specified in the model, the members are sorted in ascending order, by member caption. If there are duplicate captions, they are sorted by business key. To order all level members by just the captions in the level, the sort order must be specified in the report design.

Creating a DQM-enabled project You can specify that a project will use DQM mode when you create a new project. After you do this, the default mode for testing and publishing objects in that project will be DQM. Note that the data source connection for DQM-enabled projects must have a connection to both the content store and a JDBC driver. This information is defined in IBM Cognos Administration when creating or editing a data source connection. Data source connections can only be defined by users with administrative access in the IBM Cognos Analytics environment.




Activity: Create a DQM-enabled project You want to create a new project with dimensional metadata, and decide to use dynamic query mode in order to optimize the performance. To do this, you will create a dynamic query mode enabled project, define a JDBC connection to the data source, and publish a package in DQM. In this activity, you will accomplish the following: • Create a DQM-enabled project and data source connection • Import metadata and test query subjects • Create and publish a DQM package and then verify the package properties • Create and run a simple report based on a DQM source The following instructions use the Sample Outdoors Warehouse IBM DB2 database called GS_DB to allow you to create a data source connection to a relational data source and JDBC driver.

Create a DQM-enabled project and data source connection. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, click Create a new project. • In the Project name field, type GO Warehouse (DQM).

By default, the Use Dynamic Query Mode check box is already selected, which is what you want.

• In Location, navigate to C:\Training\B6252G\Course_Project, click OK, and then click OK again. If necessary, login as admin/Education1.

• In the Select Language dialog box, ensure that English is selected, and then click OK.

• Ensure Data Sources is selected, and then click Next. • Click New to create a new data source connection. • In the New Data Source wizard, click Next. • In the Name field, type GOSALESDW, and then click Next.




• Under Type, select IBM Db2, and then ensure Configure JDBC connection is selected. You want to configure the JDBC connection so that information can be provided to connect through the JDBC driver which is required for Dynamic Query Mode.

• Click Next. In the next steps, the information provided is based on how the IBM Db2 clients on the Framework Manager machine and the IBM Cognos Analytics servers were configured and how security is implemented for IBM Db2. Connection information and sign on information should be provided by the database administrator.

• In the DB2 database name field, type GS_DB. • Under Signons, click the Password check box to select it. • In the User ID box, type GOSALESDW, and then in the Password and Confirm

password boxes, type Education1. • Click Test the connection, and then click Test.

Notice that the Query Mode is Compatible. This only indicates that Dynamic Query Mode has not been configured for this data source at this point.

• Click Close, click Close again, and then click Next. You will now configure the JDBC connection.

• In the Server name box, type VCLASSBASE (the name of the server hosting the database), in the Port number box, type 50000 (the port number of the database), and then in the Database name box, type GS_DB.

• Click Test the connection, and then click Test. Notice that the Query Mode is Dynamic.

• Click Close, and then click Close again. • Click Finish, and then click Close.

The new data source that appears in the list is configured to query using either query mode.




Import metadata and test query subjects. • In the Metadata Wizard, click GOSALESDW, and then click Next. • Expand GOSALESDW > Tables, and then select the following check boxes:

• GO_TIME_DIM • SLS_PRODUCT_DIM • SLS_SALES_FACT

• Click Next, click Import, and then click Finish. • In the Project Viewer pane, expand GOSALESDW.

The query subjects appear as child objects as shown below.

• Double-click GO_TIME_DIM to open its definition, and then click the Test tab.

If the Query Mode property of the project is set to Dynamic when testing a query subject, the test query will run in Dynamic Query Mode. If the Query Mode property is set to Compatible, however, there is an option to use the Dynamic Query Mode on the Test tab in the lower left corner, provided that the query subject is for a data source supported by the Dynamic Query Mode. In this case, the property for this project was set to Dynamic Query Mode, and therefore you do not see this check box option.

• Click Test Sample. Framework Manager sends the test query through the IBM Cognos gateway to one of the IBM Cognos Analytics servers, which queries the reporting database. The data retrieved by the test query appears in the Test results pane.

• Click OK to close the Query Subject Definition window. You should test all your model objects against the Dynamic Query Mode to ensure that the generated SQL is as expected for your requirements. If you are building a DMR model, this includes foundation objects such as data source and model query subjects as well as regular and measure dimensions. After you have built the model, you can create and publish a DQM package.




Create and publish a DQM package and then verify the package properties. • In the Project Viewer pane, right-click Packages, point to Create, and then click

Package. • In the Name field, type GOSALESDW, click Next, and then click Finish. • Click Yes, clear the Enable model versioning check box, and then

click Next twice. Note: If the Query Mode property of the project was set to Compatible, and the package contained supported DQM data sources, the wizard dialog would have a Use Dynamic Query Mode check box option. You have already defined the property of this project as Dynamic Query Mode, so this option does not appear.

• Click Publish, and then click Finish. The package is now available in IBM Cognos Analytics, and will use the Dynamic Query Mode for reports written against this package. In IBM Cognos Analytics, the query mode used by the package can be verified in the package properties.

• Save and close the project, and then close Framework Manager.

Create and run a simple report based on a DQM source. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to GOSALESDW, click More, and then click Create

report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults. • From the Sources tab, populate the list with the following items:

• GO_TIME_DIM > DAY_DATE • SLS_PRODUCT_DIM > PRODUCT_KEY • SLS_SALES_FACT > QUANTITY You could use any items from the package for your report; the specific content of the items selected above is not important to this activity.




• Run the report in HTML. A section of the results appears as follows:

The DQM package works as expected.

• Close the rendered report tab. • Save the report as DQM Report in the GOSALESDW folder, and then close the

current report. • Close all open windows.




DQM, CQM, caching metadata, query processing, aggregate calculation, and other ways to improve performance Using DQM features in a Compatible Query Mode project If your Framework Manager project uses Compatible Query Mode, you can still test queries and publish packages using dynamic query mode, as long as your data sources are supported by DQM. You can even change the query mode of the entire project, so that all testing and publishing is automatically performed in DQM. Keep in mind that publishing a package in dynamic query mode, or changing the query mode of a project, can negatively impact any reports that use the package or project. This is because DQM enforces best practice design rules which the existing reports may not already adhere to. As well, when you change a project to DQM, you (or the administrator) will need to update the data source connection to include the JDBC connection information. When changing a project or package to DQM, it is important to work closely with the report authors who use those packages. This will help you to ensure that the benefit of changing the query mode outweighs the effort to ensure that reports function as required.

Testing and publishing CQM projects in DQM Whether you are using a CQM or DQM project, you can test objects (such as query subjects) and publish packages in DQM. When you publish CQM packages in DQM, all reports assigned to that package will run in dynamic query mode. However, to ensure consistency and accuracy of the metadata, IBM recommends that you only perform DQM actions on DQM projects. Before you use DQM to publish an existing package, you should be sure that this will not negatively impact any of the reports that consume this package. When you create a new DQM project, the Use Dynamic Query Mode check box does not appear, because that is the default mode. However, if you change the project's query mode to CQM, the check box will appear.




Migrating an existing project to DQM You can change a CQM project to DQM by setting the project's Query Mode property to Dynamic. Before you change the query mode: • Ensure that all data sources are supported by DQM • Work with report authors to evaluate the impact on existing reports • Ensure that the benefits are worth the effort to resolve any impact to existing

reports Not all existing applications will benefit from migrating to DQM. The report author can use Lifecycle Manager to determine the visual and performance impact of migrations without permanently altering the package. When you convert an existing CQM project to DQM, you will need to identify and fix any issues that arise from the enhanced rules that DQM enforces. For example, if you attempt to publish a package in DQM that has a many-to-many cardinality, you will get an error message. When connecting to a relational data source, you (or your administrator) must add JDBC connection parameters to the existing data source connection, since dynamic queries run on JDBC.

Using governors to set limits on query execution By using governors, you can reduce system resource requirements and improve performance. They are set at the project level, in the Project > Edit Governors menu. SQL is automatically generated whenever you test a query subject, create a query subject based on other objects, or run a report in IBM Cognos Analytics. By setting governors, you can improve the performance of SQL generation. For example, you can: • restrict the number of report tables or rows returned • set time limits for query executions • deny runtime activities that are resource-intensive, such as outer joins • allow reports to run against cached data, so that the service does not have to re-

query the database You must specify project governors before you publish packages to ensure the metadata for each package uses the specified limits. All packages that are subsequently published use the new settings.




DQM governors The governors for the DQM control division calculations and the security of cached data to ensure that only authorized users access cached data. Keys which are unique to users control access to the cache. You can configure these keys with the dynamic query mode cache governors: • (DQM) Adjust SQL generation for exact numeric division: Controls how

calculations with divisions are adjusted to ensure that the division results contain information that is significant for the reports.

• (DQM) Cache is sensitive to connection command blocks: Specifies whether the cache key includes the expanded value of the connection command blocks.

• (DQM) Cache is sensitive to DB info: Controls the sensitivity of the cache associated with a package that is shared by users of the connection. It also specifies what database information is used to restrict sharing in that cache (DB, DB + Connection, or DB + Connection + Signon).

• (DQM) Cache is sensitive to model security: Controls the security that is used to access the cache (Automatic, User, UserClass, None).

What is metadata caching? Framework Manager metadata: • Describes objects imported from your data source and any model objects created

from them • Is cached in the RTM file The RTM file is: • Where the server retrieves package metadata from • Created when a user first accesses a package in IBM Cognos Analytics • Stored in <C11_install_location>\data\cqe\RTModels When you run a report for the first time, the query request is sent to the database, and a result set is returned. The query and result are stored in the cache for each user for their current session. When you run the report again, the cached query and result can be used without having to query the database again. To take advantage of the improved query performance, enable the Allow Usage of Local Cache governor. For users that require the latest data, consider publishing a separate package with this governor disabled.




You should try to only include the metadata that is required in the packages that you publish. The larger that an RTM file is, the longer it will take to open the package in IBM Cognos Analytics. File size can be especially significant for packages that contain cube data sources.

How do reports use cached metadata? Reports require metadata and descriptions of that metadata to fulfill queries. Uncached metadata results in additional database calls, as indicated in the diagram below:

After the data source connection has the metadata information, it is cached in memory for the duration of the connection only. By default, queries will always use cached RTM file metadata. However, if metadata is not cached, the query service is forced to fetch the metadata from the database. Query performance may become an issue if there are numerous call backs for metadata.

When is metadata not cached? You can disable metadata caching for an entire project by enabling the Allow Enhanced Model Portability governor, which forces the server to get metadata from the database. Only use this setting if the model is being used in multiple environments where the columns in the database could potentially change in data type. Metadata is also not cached when you modify a data source query subject by: • Editing the SQL statement • Embedding filter or calculation objects • Adding macros, parameter maps, or prompts




For example, when you add a language macro and parameter map reference to the SQL expression of the PRODUCT_LINE query subject, the query engine retrieves the values from the appropriate PRODUCT_LINE column in the data source based on the user's locale setting. In this case, metadata for the query subject cannot be cached in the model because the definition of the PRODUCT_LINE column is dynamic in nature. From one locale to the next you will receive different columns or expressions with potentially different data types. The end result is that a call must be made to the data source when the query is executed to determine the properties of the relevant column used by PRODUCT_LINE.

Security-aware caching in DQM Members and data are cached as queries are executed. Data is retrieved from cache if it exists and if security profiles match. This approach lets you quickly interact with information, such as sorting, filtering, and formatting. The performance benefits of the cache are most noticeable when executing: • Similar reports with small modifications • Repeated analysis within the same cube • Repetitive master-detail requests for large reports DQM provides a greater degree of secure, smart caching, which offers significant performance improvements for most queries and workloads. The local processing approach to dimensional reporting is broken down into two simple steps: metadata fetch and data fetch. When a report is executed, the query service retrieves all members requested (metadata), either by level and/or unique member inclusion, and then uses the retrieved members to construct the MDX used for data retrieval (facts). As these calls are performed, for both metadata and data requests, each result is cached. When connected to secured metadata sources, the caching logic available in DQM can determine the access level of each user as they query the data source. Then, if any subsequent queries are made in the same context (that is, security profile, metadata, and data), the cached results will be used.

Query processing types To improve performance, for relational metadata, you can specify whether SQL processing is performed by the database server or processed locally: • Limited Local: the database server does as much of the SQL processing and

execution as possible • Database Only: the database server does all the SQL processing and execution.

An error appears if any reports or report sections require local SQL processing




In Framework Manager, Query Processing is a property of a data source object. However, these properties can be overridden for individual reports in IBM Cognos Analytics - Reporting. Although the database server can usually run the SQL and run reports much faster, local processing is sometimes necessary. For example, choose limited local processing if you want to create cross-database joins or if you want report authors to use unsupported SQL99 functions. Some complex queries require limited local processing, such as a query that must generate an At clause to avoid double-counting. In this case, the query automatically uses limited local processing even if the package was published with database only processing.

Determine where aggregates are calculated Calculating aggregate values can be process-intensive. To improve performance, you can specify whether aggregates are calculated at the database or application level. In Framework Manager, Rollup Processing is a property of a data source object, which determines where the aggregation of report summary values is calculated, based on the output type of the report. The default Rollup Processing property setting is Unspecified in Framework Manager (named Default in IBM Cognos Analytics - Reporting); however you can also set the value to Extended, Database, or Local: • Extended: instructs the query engine to always use extended forms of aggregates.

Remember: Extended aggregate (XSUM, XAVG, XMIN) operations are pushed to the database.

• Database: instructs the query engine to use running aggregates where possible. The Database setting pushes the running aggregation to the database using derived tables if the database vendor supports this feature. If not, the running aggregation is performed locally.

• Local: instructs the query engine to use running aggregates where possible. Local will force the query engine to compute the running aggregates at the IBM Cognos application tier versus at the database tier. This can offload some of the computation load from the RDBMS server, which can be beneficial when there is more compute capacity at the application engine tier than the data tier.

Using filters to improve performance Reducing the number of retrieved rows improves performance. You can do this by using: • Embedded filters • Embedded filters with prompts (allows users to focus their queries) • Stand-alone filters • Security filters




You can build mandatory filters into the model to ensure that consumers do not retrieve excessively large data sets when running reports. This is useful when the users do not always need to access all of the data. All filter types (listed above) limit the data set retrieved, resulting in a decreased query processing load. You should consider filtering data sets when modeling relational data dimensionally. This will help offset any decrease in performance from having an additional layer of metadata in your model. Prompt Info properties can be set on query items to improve performance as well. Essentially, you want to ensure that an indexed field is used to filter a query while at the same time providing user-friendly values for selection. For example, set the Product Line query item's Filter Item Reference property to use Product Line Code. This way IBM Cognos generated prompts will use the Product Line Code in the Where clause of the query while allowing users to select values represented by Product Line.

Applying design mode filters You can use design mode filters to improve performance when: • Testing query subjects in Framework Manager • Designing reports in IBM Cognos Analytics Apply design mode filters in query subjects to limit the amount of data that report authors and modelers retrieve when testing and designing. By limiting data retrieval, design time results appear more quickly. Design mode is one of three options available for a filter's Usage property in Framework Manager. The Usage property is accessible from the Filter tab of the Query Subject Definition dialog box. After design mode is set as the usage for a filter, it must then be applied. In Framework Manager it is applied for testing purposes using the Options dialog box, which is available from the Test tab of the Query Subject Definition dialog box. In IBM Cognos Analytics - Reporting, it is applied for design purposes using the Preview with Limited Data option, which is available from the Run Report menu. In IBM Cognos Analytics - Reporting, it is applied using the Run Options dialog box, which is available from the Run menu. Select the data mode you would like to run in.




Reducing the number of database connections Using the same data source name for multiple data source connections to the same database instance allows for fewer database connections at run time and allows the database server to perform the joins between the databases rather than the IBM Cognos servers. This technique can be implemented in the data source properties in Framework Manager. In the following example, the IBM Cognos query is pulling from two tables, each from a separate database in the same Microsoft SQL Server instance:

These two tables have a join defined between them in Framework Manager. Using the same Content Manager data source name in the data source properties allows IBM Cognos to make one database connection rather than two. It also sends only one Select statement with join criteria to be performed by the database rather than two Select statements, which would require local processing for the join condition specified in Framework Manager.




Indicating the performance impact of functions Through a Framework Manager model, report authors can write reports that query any combination of data source types, but not all data sources support functions the same way. The quality of service indicator provides report authors with a visual clue about the performance of individual functions when used in conjunction with the data sources accessed by the model: • Not Available: the function is not available for any data sources • Limited Availability: the function is not available for some data sources in the

package • Poor Performance: the function is available for all data sources but may have

poor performance in some data sources • Unconstrained: the function is available for all data sources This lets report authors avoid using functions that could result in long running queries or queries that fail. You can also provide descriptive text about a function. You can set the indicator at the project or package level.




Activity: Identify the use of cached metadata by a query

In order to understand how modifying data source query subjects can impact query performance, you will identify when the queries generated from your data source query subjects are using cached metadata, and when they are not. In this activity, you will accomplish the following: • View a metadata call back to the database in Framework Manager

View a metadata call back to the database in Framework Manager.

You will first add a calculation to a data source query subject and then identify the effects of that calculation.



• In Framework Manager, open the great_outdoors_warehouse project located at: C:\Training\B6252G\CBIFM-Start Files\14_Identify_the_use_of_cached_metadata_by_a_query\great_outdoors_warehouse.

• If prompted, log in as admin/Education1. • In the Project Viewer pane, expand

go_data_warehouse > Database view > Sales and marketing data, and then double-click SLS_SALES_FACT.

• Click the Calculations tab, and then click Add. • In Name field, type Planned Revenue. • In Available Components, ensure the Database view is expanded, and then

create the following expression: [Sales and marketing data].[SLS_SALES_FACT].[QUANTITY] * [Sales and marketing data].[SLS_SALES_FACT].[UNIT_PRICE]

Now this data source query subject includes an embedded calculation. • Click OK twice. • In SLS_SALES_FACT, test Planned Revenue.




• Click the Query Information tab, and then click the Response tab. The xml response from the IBM Cognos server for this query appears. Notice the text shown below: RQP-DEF-0543 Metadata will be retrieved from the database, because a simple DB query subject definition with matching metadata does not exist. This indicates that the data source query subject has been altered and is no longer considered a simple query subject. This occurred because the query subject contains a calculation which results in a dynamic query, which cannot be resolved using the metadata currently cached in the model. This test can also be run in IBM Cognos Analytics - Reporting by going to the Tools menu, Validate Options, and selecting Information in the Validation level list. Now when you validate the report, you will be able to see this message if it is generated.

• Click Close, and then delete the Planned Revenue calculation from the SLS_SALES_FACT query subject.

• Test the SLS_SALES_FACT query subject, click the Query Information tab, and then click the Response tab. The metadata call back message no longer appears since cached metadata is used.

• Click Close, and then save the project in C:\Training\B6252G\Course_Project. • Leave Framework Manager open for the next activity.




Activity: Examine rollup processing and generated SQL

A report author wants IBM Cognos to perform certain aggregations locally rather than at the database level. You will show the report author how to accomplish this in IBM Cognos Analytics - Reporting, and identify what to expect in the generated SQL. In this activity, you will accomplish the following: • Author a report with summary values • View the Generated SQL and set the appropriate option • Examine the Rollup Processing property in Framework Manager

Author a report with summary values. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Navigate to Team content > Samples > Models, point to GO data warehouse

(query), click More, and then click Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults.


summary behavior for lists check box is cleared, and then click OK. • In the Sources tab, expand Sales and Marketing (query) > Sales (query) >

Retailers, and then add Retailer name to the list. • Expand Sales Fact, and add Quantity to the list.

• Click the Quantity column, from the on-demand toolbar, click Summarize , and then click Total. The results appear as follows:




View the Generated SQL and set the appropriate option.

• In the upper-right corner, click Manage , and then click Show Generated SQL/MDX.

• From the list, select IBM Cognos SQL. The SQL appears as shown below: IBM Cognos SQL SELECT SQ0_Query1.Retailer_name AS Retailer_name, SQ0_Query1.Total_Quantity AS Quantity, SUM(SQ0_Query1.Total_Quantity_) OVER( ) AS Total_Quantity

FROM ( SELECT Retailer_site.Retailer_name AS Retailer_name, SUM(SLS_SALES_FACT.QUANTITY) AS Total_Quantity_

Notice that Total_Quantity is totaled for Retailer_site.Retailer_name. This represents the summary total at the bottom of the report. Normally you would expect to see this as an aggregated total display using extended aggregates based on the presence of the XSUM(XSUM) function. However the model for this report is set to DQM, and therefore you see SUM instead of XSUM. This SQL was generated based on the default setting. With this setting, you always see SQL generated based on batch mode.

• Click Close, and then in the breadcrumb trail above the Insertable objects pane, click Report, and then click Query1.

• If the Properties pane is not open, then in the upper-right corner, click Show properties to open it.

• In the Properties pane, under QUERY HINTS, click the Rollup processing row, and then from the list, select Local.




• In the upper-right corner, click Manage , click Show Generated SQL/MDX, and then review the generated IBM Cognos SQL. The SQL appears as shown below: IBM Cognos SQL SELECT SQ0_Query1.Retailer_name AS Retailer_name, SQ0_Query1.Total_Quantity_ AS Quantity, SUM(SQ0_Query1.Total_Quantity_) OVER( ) AS Total_Quantity_ FROM ( SELECT Retailer_site.Retailer_name AS Retailer_name, SUM(SLS_SALES_FACT.QUANTITY) AS Total_Quantity_

Normally you would expect to identify the aggregated total being displayed using running aggregates based on the presence of the RSUM function. Due to the DQM settings in the model, you only notice the SUM function. However, the Rollup processing property setting ensures local processing of the summary totals no matter what the output format of the report is.

• Click Close. • In the Properties pane, change the Rollup processing property to Extended. • Click Manage, click Show Generated SQL/MDX, and then review the generated

IBM Cognos SQL. The SQL appears the same as in the first two examples because you are explicitly asking for an extended aggregate.

• Click Close, and then change the Rollup processing property to Database. • Click Manage, click Show Generated SQL/MDX, and then review the generated

IBM Cognos SQL. The SQL appears the same as in the first three examples because you are using DQM. The Database setting instructs the IBM Cognos query engine to use running aggregates where possible. The Database setting pushes the running aggregation to the database using derived tables if the database vendor supports this feature. If not, the running aggregation is performed locally.

• Click Close, and then close IBM Cognos Analytics without saving the report.




Examine the Rollup Processing property in Framework Manager. • In Framework Manager, with the go_data_warehouse project open, expand

Data Sources, and then click go_data_warehouse. • In the Properties pane, click the Rollup Processing property value, and then click

the list to view the available settings. When the corresponding property in IBM Cognos Analytics - Reporting is set to Default, the model's value defines the default behavior for every report that is based on the data source. However, as you have seen in this activity, you can still override the model setting for an individual report in IBM Cognos Analytics - Reporting.





Activity: Apply design mode filters You want to control how long it takes for queries to run when report authors are designing reports in IBM Cognos Analytics - Reporting. To do this, you will begin by adding a design mode filter to one of the query subjects in your model. In this activity, you will accomplish the following: • Create a design mode filter • Test the design mode filter in IBM Cognos Analytics - Reporting

Create a design mode filter. • Ensure you are logged into IBM Cognos Framework Manager as admin

(password is Education1), with the C:\Training\B6252G\Course_Project\great_outdoors_warehouse project open.

• In the Project Viewer pane, expand go_data_warehouse > Business view. • Double-click Sales fact, and then click the Filters tab. • Click Add, and name the filter Limited Products Design Mode Filter. • In the Available Components pane, expand Database view, and then create the

following expression: [Sales and marketing data].[SLS_SALES_FACT].[PRODUCT_KEY] in (30001, 30002, 30003, 30004, 30005)

• Click OK. Notice that the current Usage for the filter is set to Always.

• Under the Usage column, click the ellipsis beside Always. • In the list, click Design Mode Only, and then click the Test tab. • Click the Options link in the lower-right corner, under Design mode filter select

Apply all relevant design mode filters when testing, and then click OK.




• Click Test Sample. A section of the results appears similar to the following: Test results (Design Mode filter applied)

Notice that the test results have the design mode filter applied. The values retrieved are restricted to the product key specified in the filter.

• Click Options, and then clear Apply all relevant design mode filters when testing.

• Click OK, and then click OK again.

Test the design mode filter in IBM Cognos Analytics – Reporting. • Publish the GO Data Warehouse (query) package, entering December and 2010

if prompted for MONTH and YEAR. • Save and close the project. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to GO Data Warehouse (query), click More, and then

click Create report. Ensure that you select the package that is at the root of Team content, which is the one that you just published.


defaults. • Expand Sales and Marketing (query) > Sales (query), and then add the following

items to the report: • Query subject = Product, Query item = Product name • Query subject = Product > Codes, Query item = Product key • Query subject = Sales fact, Query item = Revenue




• On the Application bar, click Run options, click Show run options, and then under Data mode, select Limited Data.

• Click OK and then run the report in HTML. The results appear as follows:

The design mode filter is applied. In the preceding example, the Sales fact Revenue values are restricted to only the products specified in the filter.

• Close the rendered report tab. • Sign out of IBM Cognos Analytics - Reporting without saving the report. • Close all open windows.




Perform basic maintenance and management on a model Managing projects Copying, Moving, Renaming, and Deleting projects: • Are available from the File > Manage Projects menu • Allow you to organize projects in a meaningful way • Affect the file folder and all of the files it contains (except Rename) • Require closing the project first (except Copy) The .cpf file acts as a pointer to the files that comprise the project. Rename Project renames the .cpf file but no other files in the folder. If the folder has the same name, it is also renamed. Of course these same actions can be performed manually on the system files in File Explorer. If the project has segments, Copy, Move, and Delete work on all segments and the main project. However deleting a project segment does not delete the main project or other segments. Segments are discussed elsewhere in this course.

Deploying packages and content A simple way to deploy a package to a different server is to change the Dispatcher URI setting (in the Environment > Group properties) in IBM Cognos Configuration. However, this only allows you to deploy a package to a different environment, not content (reports, analysis, and so on) based on that package. For example, reports created in the development environment will not be deployed to the production environment using this method.




To deploy both packages and their related content, an administrator can create an Export Deployment Specification, which can be imported to other IBM Cognos servers (such as multiple production sites). You can also create an export deployment of the entire Content Store:

This method is easier because you do not have to reconfigure the IBM Cognos environment each time you want to publish a package to a different server. It is also safer, as it prevents accidently publishing a package to the wrong server by forgetting to change the Dispatcher URI.

Analyzing the impact of publishing You can analyze the effects of model changes on a published package, such as: • changed model objects • other model objects affected by the changes • reports that use the changed objects For each object identified as a changed model item, an icon identifies whether the change may or will break any related reports. You can then identify specific reports affected by the changes, and even directly run those reports from the Analyze Change Impact dialog box. With this information, you can notify report authors that a change was made to the model that affects their reports. They can then fix their reports so that consumers are not affected. Something to be aware of is that changed cardinality is not detected and identified by this tool since changed cardinality does not break reports. It may, however, change the amount of data returned (outer join versus inner join), and therefore should be discussed with authors.




Activity: Perform impact analysis on a modified package

A number of reports have been created using the GO Operational model. You need to make some changes to the model in Framework Manager and re-publish the package. Before publishing, you want to analyze what effect this change will have on existing reports. To accomplish this you will perform an impact analysis on the GO Operational package. In this activity, you will accomplish the following: • Modify a model object • Analyze the impact of changing the model

Modify a model object. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the GO Operational project located at C:\Training\B6252G\CBIFM-Start Files\15_Perform_impact_analysis_on_a_modified_package\GO Operational.

• If prompted, log in as admin/Education1. • Publish the GO Operational (query) package, overwriting the existing package

and closing the informational messages. • In the Project Viewer pane, expand GO Operational Model > Consolidation

View, and then rename Time to Time (Sale).

Analyze the impact of changing the model. • Under Packages, click the GO Operational (query) package. • Right-click the GO Operational (query) package, and then click

Analyze Publish Impact. The Analyze Publish Impact dialog box appears.




• In the Changed Model Items section, click Time (Sale) to select it. The results appear as follows:

Notice the red X icon, which indicates that the change you made will break related reports. The Change details for section identifies the nature of the change, in this case the renaming of Time to Time (Sale). Under Actions, you can show the object dependencies, find the object in the Project Viewer pane, or open the objects definition.




• To the right of Time (Sale), under Actions, click Show Dependencies . In the Tools pane, a section of the results appears as follows:

In the Tools pane, the Dependencies tab identifies the modified query subject and its contents. Below it, the Dependent Objects pane list identifies all objects affected by the modified query subject, including shortcuts, model query subjects and query items.




• In the Analyze Publish Impact dialog box, to the left of Time (Sale), select the check box.

• Above Actions, click the Find Report Dependencies link. You can choose the scope of your dependencies search.

• Click Search. The results appear similar to the following (your list may be different, depending on the reports you have previously created):

A list of the reports that are affected by your change is returned. Because you have not saved many reports, this change has little effect. You can identify the report the object appears in and how it is being used. In a production system this could identify hundreds of reports, indicating that it might not be practical to make this change now. You could enable model versioning to allow authors time to repair their reports. Model Versioning is discussed elsewhere. You can click on any of the report names in the list to view and edit the report in IBM Cognos Analytics - Reporting.

• Click Close twice, and then close the Tools pane. • In Consolidation View, rename Time (Sale) back to Time. • Save the project in C:\Training\B6252G\Course_Project, overwriting the previous

project. • Leave Framework Manager open for the next activity.




Remap metadata to another source and import and link additional data sources Remapping an object to a new source Remapping is useful when underlying objects have changed. This process remaps objects to new items. The remapping feature can be very useful in remapping your consolidation view (middle layer) to new or changed data source objects. For example, you may switch database vendors or database structures (move from an operational structure to a star schema structure). Remapping is also useful if you decide to change how you modeled an underlying object or objects. For example, if your Product dimension in the Consolidation View references two underlying query subjects (Product and Product Type) and you decide to merge those underlying query subjects, you can use the remap tool to point the Product dimension query subject to the newly merged query subject in the lower layer. You can remap automatically (based on name matching or by object reference) or manually (drag and drop).

Linking multiple data sources You can import metadata from multiple data sources. When linking different types of data sources, you must create relationships on common data to obtain expected results. For example, if you imported an Inventory fact table from another data source that contained a Product Key (matching in values and data type to the Product Key in your existing Product dimension) you can use that key to create a relationship to the Product dimension. By doing so, you can create queries that retrieve data from separate data sources with related results.

Non-database data sources In addition to using databases as data sources for your models, several file types can be set up as data sources as well, including: • third-party metadata sources (such as SAP BusinessObjects Designer files) • IBM Cognos PowerCubes • XML files




Activity: Remap the physical layer You have a new data source which will replace the data source under your foundation objects view. Your goal is to remap all the model query subjects in your consolidated objects view to data source query subjects in the new data source. You will start this process by remapping one model query subject in the consolidated objects view to a new data source query subject in the foundation objects view. In this activity, you will accomplish the following: • Import the new metadata • Remap Time to GO_TIME_DIM

Import the new metadata. You will create another version of your model to perform the remapping technique. This will allow you to maintain a backup copy of your original project.

• Open File Explorer, navigate to C:\Training\B6252G\Course_Project, and create a folder called GO Operational Maintenance.

• In Framework Manager, click File > Save As, and then save your current project as GO Operational Maintenance in C:\Training\B6252G\Course_Project\GO Operational Maintenance.

• In the GO Operational Model >Foundation Objects View namespace, create a namespace called GO Data Warehouse.

• Right-click GO Data Warehouse, and then click Run Metadata Wizard. • With Data Sources selected, click Next. • Select great_outdoors_warehouse, and then click Next. • Expand GOSALESDW > Tables, select the GO_TIME_DIM check box, and then

click Next. • Click Import, and then click Finish. • Expand GO Data Warehouse > GO_TIME_DIM.

• Select all the query items displayed as Facts , and change their Usage properties to Attribute.




Remap Time to GO_TIME_DIM. Before you remap an object, it is a good idea to find all object dependencies for the object that will be replaced with a new one. In this case, you are replacing the TIME_DIMENSION query subject from the gosales namespace. You will use the Dependencies feature to identify which objects will require remapping after you replace this query subject.

• In the Foundation Objects View > gosales namespace, right-click TIME_DIMENSION, and then click Show Object Dependencies. Note: If nothing appears the first time, select it to put it in focus, and repeat. In the Tools pane, on the Dependencies tab, TIME_DIMENSION and its children appear in the top pane, and dependent objects appear in the bottom pane. Selecting items in the top pane filters the items in the bottom pane. The items in the bottom pane include dependent packages, security, relationships, query items, and determinants. If you scroll down in the Dependent objects list, you can select individual query items. Each one you select receives focus in the Project Viewer tree. This way you can identify which objects will require remapping.

• In the Tools pane, under Dependent objects, select the first Day Key. In the Project Viewer pane Consolidation View > Time > Day Key is also selected, so you now know this object requires remapping to the new GO_TIME_DIM query subject. Other objects also require remapping, but for the purposes of this activity, you will only remap one object.

• In the Project Viewer pane, in the Consolidation View namespace, right-click Time, and then click Remap to New Source. The Remap to New Source dialog box appears. The right pane identifies the original source for all query items.

• Under Available Model Objects, expand Foundation Objects View > GO Data Warehouse > GO_TIME_DIM. Comparing left and right panes, it appears that the new query subject uses the same query item names as the original query items. You can drag each query item from the left to the right pane individually, or you can use the matching criteria feature. Note that Use matching criteria options is selected.




• Click Options. Note that the default for matching criteria is to Remap To…By Name.

• Click Cancel, and then drag GO_TIME_DIM under Original Source.

A match was found for all query items, except for one calculation. This must be handled manually, since a match was not found because of different names.

• Clear the Use matching criteria options check box, and then drag MONTH_EN from the left pane, over to the Month query item in the right pane.

• If a warning message appears prompting you to use the matching criteria option, click No. The Month query item is now mapped to MONTH_EN.

• Click OK. • Save the project. • Leave Framework Manager open for the next activity.




Run scripts to automate or update a model and report on a model Playing back parts of an action log Each sequence of actions that you perform in Framework Manager is considered a transaction. Each transaction is recorded in the action log file. You can observe the history of transactions, and play back individual transactions or a combination of transactions in a log file. This is useful for: • Repeating identical sequences within a model • Creating a starting point for multiple similar models • Moving a model change from test environment to production • Auditing or troubleshooting • Bulk upgrades in batch mode You can also save transactions to a separate log file (script). The action log file is an XML file that is stored in the project folder. When troubleshooting a model with IBM Cognos Customer Support, the technical analyst will likely request the log files to be sent in. You can create scripts that support bulk upgrades of Framework Manager models. To do this, use the BmtScriptPlayer, which is a console application that you can use to create simple scripts that will process Framework Manager log files in batches. After the script in a log file has run successfully, a backup of the original product is created in the parent directory of the project. If the outcome of running the script is undesirable, you can use the backup to restore the project to its original state. You must disable or clear any commands that will conflict with the contents of the model. You can then run the script again. Or, you can use the Synchronize command, which begins with an empty model.

Synchronizing projects You can use log files to synchronize a project with changes in the metadata source. All actions performed in the model are replayed. The result is: • A new project is created • Metadata is re-imported to capture any changes • The entire modeling process is repeated using updated metadata




You can choose to accept the new changes and create a new project, or return to the original project. If you accept the changes, the original project is deleted. The Synchronize dialog includes a check box to back up the original project before synchronizing. It is recommended that you select this check box. After you save and close a project, changes are added to the log file. Because every action that you made in your project is re-run, synchronization may take a long time. Synchronization can be run only on the master project or a stand-alone segment. You cannot synchronize linked projects or segments in the master project. You may encounter errors when running script files if an object that is referenced by a transaction no longer exists or if you renamed objects. If a script stops because an object no longer exists, you should retarget the missing object to another object. All remaining script transactions use the new object. If the script stops for any other reason, you should modify the temporary project to correct the problem.

Checking a project To check a project at a high level, you can verify selected objects. This process: • identifies invalid relationships, references, and object definitions • offers automated or manual repairs To check a project at a low level, you can run model advisor. This process: • identifies design issues around relationships, determinants, and other model

factors • offers direct links to online help for resolving issues Both options are available by right-clicking any objects in your model. They can be invoked at any time in the modeling process.

Create a model report Select the entire model or any object within it, and then click Tools > Model Report. The details of every model object are presented. They can be saved in HTML or XML format for documentation purposes or for debugging. To make searching easier, it is recommended that you make a separate Model Report for each high-level namespace and/or folder in your project.




Activity: Run a script to replay actions You want to add a Business View folder and query subject in the test environment model. To quickly apply these changes to the corresponding model in the production environment, you will create a script based on the actions performed on the project in the test environment, and then run that script on the project in the production environment. In this activity, you will accomplish the following: • Model a business view for report authors in the test environment • Create a script for the creation and population of the Business View folder • Run the script in the production environment to recreate the Business View folder

Model a business view for report authors in the test environment. • Ensure you are logged into IBM Cognos Framework Manager as admin

(password is Education1), with the C:\Training\B6252G\Course_Project\GO Operational Maintenance project open.

• In the root GO Operational Model namespace, create an empty folder called Business View.

• Right-click the Business View folder, and then click Create > Query Subject. • In the Name field, type Retailers, and then click OK. • In the Available Model Objects pane, expand

Foundation Objects View > gosales. • Add the following items to the Query Items and Calculations pane:

• Query subject = RETAILER_TYPE, Query item = TYPE_NAME_EN • Query subject = Retailer & Retailer Site, Query items = RTL_ADDRESS1,

RTL_ADDRESS2, RTL_CITY, RTL_COUNTRY_CODE • Click OK.

The Retailers query subject now appears within the Business View folder. • Save and close the project.

This updates the log file that has been generated for this session. If you wish, you can examine the timestamp for this projects log.xml file in File Explorer.




Create a script for the creation and population of the Business View folder. • Under Recent Projects, open the GO Operational Maintenance project that you

just saved. • From the Project menu, click View Transaction History. • Under Transaction list, expand the first entry in the list:

C:\Training\B6252G\Course_Project\GO Operational Maintenance\GO Operational Maintenance\log.xml.

• Expand the last child entry, and then scroll to the bottom of that entry. The results appear similar to the following:

• Select the check boxes beside Create a folder with name "Business View"…

and Update the model object…. The results appear similar to the following (the preceding numbers may be different):

• Click Save as Script. • In the File name field, type Create Business View, and then click Save.




• Click Close. • In Project Viewer, expand the GO Operational Model namespace, select the

Business View folder, and then click the Delete button on the toolbar. The Business View folder, and the Retailer query subject that it contains, no longer appear in the Project Viewer.

Run the script in the production environment to recreate the Business View folder.

For the purpose of this activity, you will now assume that you are in the production environment.

• From the Project menu, click Run Script, and then double-click Create Business View.xml.

• Ensure that all check boxes are selected, and then click Run. A status message quickly appears and then a transaction message appears in the Transaction details pane.

• Click Accept. • Expand Business View > Retailers.


You successfully used a script to recreate the Business View folder, and the Retailers query subject.

• Save and close the project. • Leave Framework Manager open for the next activity.




Segment a project, link a project, and branch a model Creating a segment When you create a segment, you create a new project in a new folder, complete with its own associated project files. The new project is linked by a shortcut in the main project from which it was created. The master project has access to the entire model, including the segments. You can use segments to: • Distribute a project according to business rules and organizational requirements • Share and re-use project information with other projects You can only segment a project either at the folder or namespace level. You can also link the segments to other projects that contain the same information to maintain consistency and reuse information. Avoid making changes in both the segment and the main project. If the segment is open when the main project is updated, the potential exists for updates to be lost as a result of overwriting saved changes. It is recommended that access to the main project be limited and that you avoid updating segments from the main project. Update the segment from the segmented project.

Segmenting and linking example In the following example, Modeler 1 can create segments for the Employees and Marketing metadata. These segments are new projects created by Framework Manager and become links in the master project:




Modeler 2 will work on the Employees metadata, to model for predictable results, while modeler 3 will work on the Marketing metadata. The changes they make will be reflected in the master project. Communication is required between the modelers to ensure that no one overwrites each other's changes. For example, modeler 1 should not make any changes to the Employees or Marketing metadata without talking to the respective segment owner otherwise modeling conflicts might occur and changes may be lost. The Employees and Marketing segments can also be linked into other projects that may require this type of information. Regarding source control: For segmented projects, the segments are simply project directories stored under the parent project directory. There are two ways to work with a segmented project. Question 1: The segments can be individually opened as stand-alone projects, in

which case repository handling is the same as for any other project. Question 2: Or segments can be opened as part of the main project. In this case

you have to Check Out the projects for each segment you intend to modify, which are located, as sub-directories under the main project.

Note: The repository should maintain the same hierarchy as the project directory. If you do require the Model Synchronization feature, you must Check In any new log files that are created. When you are ready to synchronize, you will need to get a copy of all the project log files. It is not necessary to Check Out the log files, as they are never updated after they are first created.

Creating links A link is a shortcut to an existing project, folder, or namespace. You must create the project, folder or namespace before you can link to it. Linking to an existing project lets you: • Organize work across large projects • Maintain consistency • Re-use information Use a link when you have modeled metadata in an existing project and want it available in another project. Use a segment when you want to distribute work to other modelers from a main project or share portions of a project with other projects. Essentially, once you have created a link or segment, they behave the same. They are a shortcut in one project to another project.




Links and segments can be difficult to manage. Use them appropriately. For example, if a master project consists of multiple links or segments, consider creating a separate model for each.

Consolidating linked segments You can consolidate linked segments in a project by publishing a package to a network location:

The new package published to the network will include all the metadata specified by the modeler without any linked segments. This process is useful when a multi-modeler environment is no longer required and you wish to consolidate your metadata into one project. This process is also useful if you would like assistance troubleshooting your model from support or other modelers. Rather than sending the master project and all the linked projects, you can send one consolidated model.

Branch a model Branching a model enables parallel modeling. The process creates a copy of the project for simultaneous development on any portion of the model, allowing you to: • Create unlimited branches • Merge changes (bi-directional) The Branch > Merge feature essentially executes the scripts from one copy of a project onto another copy. Unlike segmenting and linking, which allow modelers to work on individual segments of a model independently, branching and merging allow multiple modelers to work on the same model in its entirety at the same time. To do this, the project owner makes a copy of the root project, called a branch. A team member can modify the branch as required, independently of the root project:




Branches can be merged back into the root project or from the root project into the branch as required. Conflicts between the root project and a branch are resolved during the merge process. However, only the root (master) version of the model can be the subject of source control repositories. Modelers should be in constant communication to ensure their modeling actions will not affect other branches or the root project. Project branching is compatible with segmenting and linking.




Activity: Create a segment You want to distribute the project workload between you and another modeler. You want the other modeler to work on employee-related data, while you work on other business areas. In this activity, you will accomplish the following: • Create a project • Create a folder containing objects you want to segment • Create a segment and view the project files • Make changes in the segmented project • View changes in the main project

Create a project. • In Framework Manager, click Create a new project. • In the Project name field, type great_outdoors_warehouse_MASTER. • In the Location box, navigate to C:\Training\B6252G\Course_Project, and then

click OK twice. • If prompted, log in as admin/Education1. • On the Select a Language dialog, ensure English is selected, and then click OK. • Ensure Data Sources is selected, and then click Next. • Click GOSALESDW, and then click Next. • Expand GOSALESDW > Tables, and then select all tables prefixed with EMP and

SLS. Tip: You can select the first EMP_ table, scroll down to the last EMP_ table, and then Shift+click the last EMP_ table to select them all. Then repeat for the SLS_ tables.

• Click Next, click Import, and then Finish. You will rename the root namespace and organize the imported objects.

• Rename the GOSALESDW namespace to Great Outdoors Warehouse. • In the Great Outdoors Warehouse namespace, create an empty folder called

Data Source View. • In the Data Source View folder, create a namespace named gosalesdw.




• In the Great Outdoors Warehouse namespace, Shift+click to select all query subjects, and then drag them into the gosalesdw namespace. The results appear as follows:


Create a folder containing objects you want to segment. • In the gosalesdw namespace, Shift+click to select all query subjects prefixed with

EMP. • Right-click one of the selected query subjects, point to New Parent, and then click

Folder. The employee data source query subjects are now contained in the new folder.

• Rename New Folder to Employee Info.




• Expand the Employee Info folder to view the objects inside. A section of the results appears as shown below:


Create a segment and view the project files. • Right-click the Employee Info folder, and then click Create Segment. • Click OK to accept the defaults.

The Employee Info folder is now represented by a link icon .




• Open or maximize File Explorer, and then navigate to C:\Training\B6252G\Course_Project\great_outdoors_warehouse_MASTER. The results appear as follows:

• Open the Employee Info folder.


The folder contains a new set of Framework Manager project files. Another modeler can work on this separate project and have the changes reflected in the main project.

Make changes in the segmented project. • In Framework Manager, close the great_outdoors_warehouse_MASTER

project, and click Yes to save the changes. • Click Open a project, click Employee Info, click Open, and then double-click

Employee Info.cpf. If File Explorer did not open to the Employee Info location by default, then navigate to C:\Training\B6252G\Course_Project\great_outdoors_warehouse_MASTER.

• In the middle pane, click the Diagram link.




• In the Project Viewer pane, expand gosalesdw > Employee Info. • Right-click EMP_TERMINATION_LOOKUP, and then click

Locate in Diagram. The EMP_TERMINATION_LOOKUP table appears highlighted in the diagram.

• In the Diagram pane, double-click the relationship between EMP_TERMINATION_LOOKUP and EMP_EMPLOYEE_DIM, change the cardinality of EMP_EMPLOYEE_DIM to 1..1, and then click OK.

• In the Project Viewer pane, expand EMP_EMPLOYEE_DIM, and click TERMINATION_CODE.

• In the Properties pane, change the Usage property to Attribute. • Save and close the project.

View changes in the main project. • Open the great_outdoors_warehouse_MASTER project. • In the Project Viewer pane, expand Great Outdoors Warehouse >

Data Source View > gosalesdw > Employee Info > EMP_EMPLOYEE_DIM, and then select TERMINATION_CODE. Notice that the Usage property is now set to Attribute.

• Right-click EMP_TERMINATION_LOOKUP, and then click Launch Context Explorer.

• Click the Show Related Objects button if necessary. Notice the relationship cardinality to EMP_EMPLOYEE_DIM is 1..1, which reflects the change you made in the previous task.

• Close the Context Explorer window, and then close the project. • Leave Framework Manager open for the next activity.




Activity: Create a link You will create a new project that will model the marketing metadata of the Sample Outdoors Company. This project can also be leveraged in the great_outdoors_warehouse_MASTER project, so you will create a link to it. In this activity, you will accomplish the following: • Create a New Project for marketing information • Create a link in the main project

Create a New Project for marketing information. • In Framework Manager, click Create a new project. • In the Project name field, type Marketing Info. • In Location, navigate to the Course_Project folder, and then click OK. • If a message appears regarding the structure of the project, click OK. • On the Select a Language dialog, ensure English is selected, and then

click OK. • Ensure Data Sources is selected, and then click Next. • Click GOSALESDW, and then click Next. • Expand GOSALESDW > Tables, and then select all tables prefixed with MRK.

You need to create the same namespace parent in this project as in the main great_outdoors_warehouse_MASTER project to link in the marketing metadata.

• Click Next, click Import, and then click Finish. • Rename the GOSALESDW namespace to great_outdoors_warehouse. • In the great_outdoors_warehouse namespace, create an empty folder named

Data Source View. • In the Data Source View folder, create a namespace named gosalesdw. • In the gosalesdw namespace, create an empty folder called Marketing Info.




• In the great_outdoors_warehouse namespace, Shift+click to select all of query subjects, and then drag them into the Marketing Info folder. The results appear as shown below:

• Save and close the project.

Create a link in the main project. • Open the great_outdoors_warehouse_MASTER project. • Expand Great Outdoors Warehouse > Data Source View, right-click the

gosalesdw namespace, and then click Link Segment. • If a message appears regarding the structure of the project, click Yes. • Browse to C:\Training\B6252G\Course_Project\Marketing Info, click the

Marketing Info.cpf file, and then click Open. • Click OK to close the message. • In the Link Segment dialog box, expand great_outdoors_warehouse >

Data Source View > gosalesdw, and then click Marketing Info. • Click Add, and then click OK.




• In the Project Viewer pane, expand gosalesdw and Marketing Info. The Marketing Info project is now linked in the great_outdoors_warehouse_MASTER project as shown below:

• Save the project, and leave it open for the next activity.




Activity: Consolidate linked segments You would like to consolidate your multi-modeler environment by creating a single project that contains all the metadata without links to other projects. In this activity, you will accomplish the following: • Publish a package to the network • Examine the consolidated project

Publish a package to the network. • Ensure you are logged into IBM Cognos Framework Manager as admin

(password is Education1), with the C:\Training\B6252G\Course_Project\ great_outdoors_warehouse_MASTER project open.

• Create a new package named great_outdoors_warehouse_FINAL. • Click Next, and then click Finish. • Click Yes to open the Publish Package wizard. • On the Publish Wizard - Select Location Type page, click the

Location on the network radio button, click the Network location folder, and then browse to C:\Training\B6252G\Course_Project.

• In the Select Network Location dialog box, create a new folder named great_outdoors_warehouse_FINAL, double-click it, and then click OK.

• Click Next twice, and then click Publish. • Click Finish, and then save and close the project.

Examine the consolidated project. • Click Open a project, navigate to

C:\Training\B6252G\Course_Project\ great_outdoors_warehouse_FINAL, and then open the great_outdoors_warehouse_FINAL.cpf project.




• Expand Great Outdoors Warehouse > Data Source View > gosalesdw.

Notice that the Employee Info and Marketing Info folders are no longer links. All metadata is now contained within this one project. Also notice that the project maintains the original project name, great_outdoors_warehouse_MASTER. However the .cpf name is identified in the title bar, great_outdoors_warehouse_FINAL. To avoid confusion, it is recommended to rename the project to match the .cpf file.

• Rename the root namespace to great_outdoors_warehouse_FINAL, and then save the project.

• Leave the project open for the next activity.




Activity: Branch a model, make changes, and merge results

You would like to allow another modeler to work on your model at the same time as you. Use the project branching feature in Framework Manager to allow a second modeler to work on a branch of your project, and then merge the changes with your root project. In this activity, you will accomplish the following: • Create a branch of the root model as Modeler 1 • Modify the branch model as Modeler 2 • Merge the branch into the root project as Modeler 1

Create a branch of the root model as Modeler 1. This task is completed as Modeler 1.

• In the great_outdoors_warehouse_FINAL project, click the Project menu, and then click Branch to.

• In the Create Branch Project dialog box, change the branch project name to great_outdoors_warehouse_FINAL Branch 1, and then click OK.

• Save and then close the great_outdoors_warehouse_FINAL project.

Modify the branch model as Modeler 2. This task is completed as Modeler 2.

• From the Recent Project list, open the great_outdoors_warehouse_FINAL Branch 1 project.

• Expand Great Outdoors Warehouse > Data Source View > gosalesdw > SLS_PRODUCT_DIM.

• Change the Usage property for the following items from Fact to Attribute: • PRODUCT_TYPE_KEY • PRODUCT_NUMBER • BASE_PRODUCT_KEY • BASE_PRODUCT_NUMBER • PRODUCT_BRAND_KEY




• Right-click SLS_RTL_DIM, and then click Launch Context Explorer; if necessary, click the Show Related Objects button.

• Double-click the relationship between SLS_RTL_DIM and SLS_SALES_FACT. • Change the cardinality for SLS_SALES_FACT to 0..n. • Click OK, and then close the Context Explorer. • Save and then close the project.

Merge the branch into the root project as Modeler 1. This task is performed as Modeler 1.

• From the Recent Project list, open the great_outdoors_warehouse_FINAL model.

• From the Project menu, select Merge from. • Navigate to C:\Training\B6252G\Course_Project\

great_outdoors_warehouse_FINAL Branch 1, click great_outdoors_warehouse_FINAL Branch 1.cpf, and then click Open. A section of the results appears similar to the following:

You are presented with a transaction list. You have the option to clear check boxes for transactions that you do not want updated in the root model. In this case, you will accept all the changes. You can also choose to step through each transaction and then pause, or simply run all transactions.




• Click Run. All transactions are successfully merged into the root project. A backup project is created on the file system in the same location as the root project with a data timestamp. This allows you to revert to the previous version if required. After the branch project is merged, it still exists on the file system. If it is no longer required, it is recommended that you delete the branch project after it is merged into the root project. New branches can be created as required.

• Click Accept. • In the great_outdoors_warehouse_FINAL project, verify that the branch project

changes made by Modeler 2 in the previous task appear. • Save and then close the project. • Close all open windows.




Nest packages and specify package languages and functions What is a Framework Manager package? A package is a subset of the project metadata to be published to IBM Cognos Analytics. Each package can contain a different set of folders, filters, query subjects, and query items. You can customize its contents to satisfy different reporting requirements and to set up a logical presentation of the metadata. Each report can only contain information from a single package. You can also apply security to packages to restrict access. Packages can be referenced by other packages. This is known as nesting, which can save development and maintenance time.

Create and modify packages When you create a package, you include the model objects that you want to publish:

At any time, you may go back and edit the definition of your package by adding or removing objects. You must exercise caution when doing this as you may break reports based on a previous version of the model.




When you create a package, you can choose which model objects will be included, excluded, or hidden, based on the requirements of report authors. These three options are described as follows: • Select - the object and its child objects can be used in reports by report authors. • Hide - the object and its child objects cannot be used by report authors, but objects

available to report authors that reference the hidden objects can. With this option, you will not receive informational messages when publishing your package stating that underlying objects will be published because other objects in the package reference them.

• Unselect - the object and its child objects are not published. It cannot be used for reports and cannot be selected by report authors. If other objects in the package reference the unselected object, the object will be included and hidden in the package and you will receive informational messages stating this.

Language and function sets In the case where you have modeled for a multilingual audience, you can specify the languages to be published with a package. You must add languages to the project before you can add them to a package, and must translate the metadata for the model objects. If you have multiple data sources in your model that are heterogeneous, publish your package with the appropriate vendor-specific function sets so that report authors can leverage them while authoring reports. You can create several packages based on the same model, that all have different languages. For example, you may have one package designed for the Mexican sales offices. This package may include Spanish and English; whereas the Canadian sales offices package would include French and English.

Publishing packages When you publish a package, you can choose to: • Publish to the IBM Cognos content store or to a network location • Externalize query subjects • Verify the package When you publish a package to the IBM Cognos server, you make it available to report authors with the appropriate security rights. Publishing to the network lets you back up or share all or a portion of your model with other metadata modelers. To avoid potential problems, select the verify package option in the Publish Wizard to check for errors.




You can choose to externalize query subjects to make metadata and data available from the underlying data source available for use in other applications.

Nest packages When you create nested packages, you create a master package that is based on other packages, as shown in the following example:

Use nested packages to reuse model information. Nested packages save time, are easier to maintain, and let you publish only the master package to make all referenced packages available to report authors. In the preceding example, three separate packages named Canada, Mexico, and the United States are created. Each package contains the project objects and security appropriate for that package. You can create one master North America package and include the packages Canada, Mexico, and the United States. When you need to publish the package for report authors, you publish only the North America package. When users from any of the three groups sign in to IBM Cognos Analytics and begin to author a report, they will only notice the package objects that apply to them in the metadata tree, which was defined in the security settings.




Activity: Nest packages and specify package languages and functions

One of the quality assurance teams that tests your packages wants to combine the GO Data Warehouse (query) and the Sales and Marketing (conformed) packages into one package for testing and comparison purposes. You will use a nested package to fulfill this request. This package is only required in a few regions. Therefore, you will reduce the number of languages published with the project to those required for the regions. You will also reduce the number of function sets published with the package, to one required for the database vendor they are using. In this activity, you will accomplish the following: • Create a nested package • Specify package languages and functions • Use the package in IBM Cognos Analytics - Reporting

Create a nested package. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the great_outdoors_warehouse project located at C:\Training\B6252G\CBIFM-Start Files\16_Nest_packages_and_specify_package_languages_and_functions\great_outdoors_warehouse.

• If prompted, log in as admin/Education1. • In Framework Manager, right-click Packages, and then click

Create > Package. • In the Name field, type GDW (query)_Sales and Marketing (conformed), and

then click Next. • On the Define Objects page, click the Using existing packages radio button.




• Enable both the GO Data Warehouse (query) and Sales and Marketing (conformed) packages. The results appear as follows:

• Click Next, and then click Finish. • Click No, to not open the Publish Wizard.

Specify package languages and functions. • In the Packages folder, click the new GDW (query)_Sales and Marketing

(conformed) package. This package will be used primarily in Germany, Canada and Russia for drill through from dimensional data sources. You will limit the languages published with this package for the appropriate regions.

• From the Actions menu, click Package > Specify Package Languages. • In the Selected Languages pane, remove all languages except English,

German, and Russian using the left pointing green arrow button. The results appear as follows:




By default, all languages available in a project will be added to a package when you create it. If languages are added to the project after you create the package, you must add them to the package in order to include them. You can specify languages for several packages at a time. To do this, click the Packages folder, and click Actions > Package > Specify Package Languages. From the Packages sub menu, you can also click Explore Packages to view the contents of each package and any object security specified.

• Click OK. These regions use a Db2 vendor, so you will limit this package to the Db2 function set. First you will examine where you can define which function set is associated with a data source.

• From the Project menu, click Project Function List. The results appear as follows:

The Project Function List dialog controls the functions sets that will appear when you create a new package. You can choose to include all function sets, or define a function set for each data source in the project. If you choose the second option, only defined function sets will be selected for your package, based on the data sources referenced in the package.

• Click the Set function list based on the data source type radio button.




• On the go_data_warehouse row, click in the Function set column. A list of database-specific function sets appears.

• Select DB2, and then click OK. When this package was initially created, the setting was to include all function sets. You will configure this package appropriate to your data source.

• Ensure that the GDW (query)_Sales and Marketing (conformed) package is selected, and then from the Actions menu, click Package > Specify Package Function List.

• Remove all function sets except DB2. The results appear as follows:

• Click OK. • In Packages, publish the GDW (query)_Sales and Marketing (conformed)

package as follows: • Clear the Enable model versioning check box, and then click Next twice. • Clear the Verify the package before publishing check box, click Publish,

and then click Finish. • Save the project in C:\Training\B6252G\Course_Project overwriting the existing

project.




View the package in IBM Cognos Analytics - Reporting. • Open Google Chrome and sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) as admin/Education1. • Click Team content, point to GDW (query)_Sales and Marketing (conformed),

click More, and then click Create report. • From the Templates and themes page, select Blank, and then click OK. • In the work area, click Add, click List, and then click OK to accept the query

defaults. The results appear as follows:

Quality assurance staff now has access to both the query and conformed views of the metadata, and can quickly perform tests on either view without having to switch between multiple packages.

• Sign out of IBM Cognos Analytics - Reporting without saving the report. • Close the web browser. • Close Framework Manager, saving the project if prompted.




Explore additional modeling techniques and customize metadata for a multilingual audience Leveraging user-defined functions User-defined functions: • Return a single value per request (per row) • Can be imported or referenced in the SQL of the query subject definition When you reference a user-defined function in a query subject, it will be represented as a query item and will return a value for each row of data as calculated by the function. The following example shows a user-defined function called Calc_Planned_Revenue being referenced in a calculation called Plan Revenue.

If you wanted to reference the user-defined function in the above example in the SQL of the query subject rather than importing it into the project, the syntax would appears as shown below:

select ORDER_DETAILS.ORDER_DETAIL_CODE, ………. dbo.Calc_Planned_Revenue(ORDER_DETAILS.QUANTITY,ORDER_D ETAILS.UNIT_PRICE) as "Planned Revenue" from [GOSALES].ORDER_DETAILS




Regular aggregate property The Regular Aggregate property has the following settings: • Automatic • Average • Calculated (applies only to standalone calculations) • Count • Maximum • Minimum • Sum The previous are options for relational data source query items with their Usage property set to Fact. The setting made in the model will become the default behavior in IBM Cognos Analytics. When IBM Cognos generates SQL, by default, Minimum may be applied to aggregated items with the Regular Aggregate property set to unsupported. When the Regular Aggregate property is set to Automatic, if the data type of the query item is numeric, the query item is summarized. If the data type is non-numeric, the query item is grouped. If the query item refers to only one query item in the model, then the aggregation defined for that model item is used.

Order of operations for model calculations The Calculated setting in the Regular Aggregate property controls the order of operations in standalone model calculations. When a model calculation (A*B) is set to Calculated (where A and B are set to sum) the calculation is applied to the summary values:

In the preceding example, the A * B column is a result of the summaries of A and B being multiplied (15 * 15 = 225). In other words, A and B were summarized first and then calculated. This is a less common approach but valid in certain scenarios.




When the same calculation (A*B) is set to Sum, the calculation is applied, and then the results are summarized as follows:

In the preceding example, the A * B column is the result of A and B being calculated first and then summarized (50 + 50 = 100). This is the more common approach to reporting and is the default behavior in IBM Cognos unless you override it with the calculated setting.

IBM Cognos as a Transformer data source As shown below, IBM Cognos Transformer can use IBM Cognos reports and packages as a data source:

Transformer is an IBM Cognos OLAP modeling component used to model and build PowerCubes. You can make metadata available for use in Transformer. To do this, you must have items that act as category codes (business keys) and captions. The business key values should be unique across all levels in the dimension. For fact data, you need to make items available in your fact query subjects that Transformer will use as measures and as the keys that allow the measures to be related to the dimensions.




For example, if your measures will relate to the Product dimension, you will need to make the Product Key available in your fact query subject. When the appropriate metadata is available, Transformer modelers can access the individual dimension information and measure information (each accessed as a separate data source) through IBM Cognos reports, or directly from metadata in the package. After a Transformer modeler has created a PowerCube, it can be published as a package in IBM Cognos for use as a multidimensional data source. This data will be conformed to the relational data since both are based on the same source data.

Creating query sets As shown in the following example, you can define a query set to merge, compare, or equate similar data from different sources:

Query sets are useful when modeling data from disparate systems, or when the desired result is not directly available through a query of the data source.




A query set can be defined using the following operations: • Union: include all the rows of two query subjects. For example, your company

recently acquired another company and you need a complete list of all customers. • Intersect: include only the rows that are shared between the query subjects. For

example, you want to find out which staff members are also managers. • Except: include only the rows that are different between the query subjects. For

example, you want to highlight the differences between where your products were sold this year and ten years ago.

Each query subject must have the same number of columns, and columns must be in the same order and have the same (or similar) data types. The data types do not need to be exactly the same if those in the second result set can be automatically converted by the data source to data types compatible with those in the first result set.

Using source control Use a source control system of your choice on Framework Manager project files to: • Manage and backup versions of you project • Prevent change conflict between users by checking files in and out • Ensure modelers are always working on the latest version Please refer to the documentation on how to put the Framework Manager project files into an external repository. Framework Manager Projects consist of three essential files, plus a log file directory. These files are: • [Project name].cpf (Required): This project file tracks segments and links. • model.xml (Required): This is the model data. • customdata.xml (Required): This saves user interface information such as

diagram layout. • preferences.xml (Optional): This file is not used. • repository.xml: This file must not be present if you are handling your own

repository. If this file is in your project, you must delete it.




In File Explorer, the files appear similar to the following:

Log files are found in the logs subdirectory:

A new log file is created each for each Framework Manager session. These logs are required only if you intend to use the Model Synchronization feature. External repository handling is simpler if you ignore the log files. After your Framework Manager project is created, make sure it is closed, and then, Check In the project file.cpf, model.xml, and customdata.xml into your repository of choice. Before opening the Framework Manager project to begin modeling again, you will be required to Check Out those three files out from your repository. If you fail to do so (and your repository system marks checked in files as read-only), Framework Manager will open in read-only mode. The text "[Read Only]" will appear on the application title. If this happens, close the project, and check out the files. If you have done a lot of work in a read-only project, then you may save the project, and you must then ensure those files get checked in properly. When your Framework Manager session is complete, close the project, and then Check In these three files to your repository.




Modifying language properties You can translate the multilingual text properties associated with metadata; names, descriptions, and screen tips. Only the metadata is translated. You can then publish your package to make the translated metadata available to authors. To do this: • define the languages to be included in the project • modify the Language properties manually or export the multilingual text properties

to a translation file, which translators use to input the correct text for each language. Once translation is complete, import the file to update the Language properties with the translated strings.

• specify the languages you want to include in your package (they must be available at the project level first) and then publish the metadata.

Each model object has three Language properties: • Name • Description • Screen Tip




Activity: Set order of operations for a model calculation

Report authors would like to see margin values in their reports. Currently a margin query item calculation is available to them, but it is performing the margin calculation first and then aggregating the values, which is returning undesired results. They would like to see the underlying values aggregated first and then perform the margin calculation. To accomplish this, you will create a stand-alone margin calculation, since this type of operation is only supported for stand-alone calculations, and set the Regular Aggregate property accordingly. In this activity, you will accomplish the following: • Test the existing Margin query item • Create a stand-alone Margin calculation and set its Regular Aggregate property • Change the Regular Aggregate property for the calculation and test it in IBM

Cognos Analytics - Reporting

Test the existing Margin query item. • From the Start menu, navigate to and expand IBM Cognos Framework

Manager.


• In Framework Manager, open the GO Operational project at C:\Training\B6252G\CBIFM-Start Files\17_Set_order_of_operations_for_a_model_calculation\GO Operational.

• If prompted, log in as admin/Education1. • In the Project Viewer pane, expand GO Operational Model > Foundation

Objects View > gosales > Sales Fact. • Select and test the following items:

• Revenue • Gross Profit • Margin




The results appear similar to the following: Revenue Gross Profit Margin 8624.64 4625.92 0.53636093796379 9411.6 4840.12 0.51427174975562 18032.22 5072.22 0.28128649717007 These are non-aggregated values. The Margin calculation is Gross Profit divided by Revenue. The margin values are correct. You will now test the items with Auto Sum enabled.

• Select Auto Sum, and then test again. The results appear similar to the following: Revenue Gross Profit Margin 4686775768.85 1924834994.68 194030.904167937 Notice the margin value is not what is expected. All the detail records are being calculated first and then aggregated. The value shown in the Margin column is the sum of all the margin values seen in the un-aggregated result set in the previous test. The expected result would be the Gross Profit value above divided by the Revenue value above for a margin of 0.41.

• Click Close.

Create a stand-alone Margin calculation and set its Regular Aggregate property. • Double-click Sales Fact, in the Query Items and Calculations pane, right-click

Margin, and then click Convert to Stand-alone Calculation. The Margin query item will no longer be required in the Sales Fact query subject. Setting the order of operations to aggregate first and then calculate is only valid for stand-alone calculations. The calculation cannot be restricted by the scope of a query subject container.

• Delete the Margin query item. A message appears, indicating that the Margin query item in the Sales Fact query subject in the Consolidation View will be invalidated. You will also delete that query item in the next few steps.

• Click OK twice. The stand-alone Margin calculation appears at the bottom of the gosales namespace.




• In the Consolidation View, expand Sales Fact, and then delete the Margin query item. A message appears, saying that the Margin measure in the Sales Fact regular dimension in the Dimensional View namespace will be invalidated. You will delete this object in the next few steps.

• Click OK. • Expand Dimensional View > Sales Fact, and then delete the Margin query item,

clicking OK to close the warning message. Note: If you want to make the Margin calculation available for your analysis package, simply make the stand-alone calculation available in that package.

Change the Regular Aggregate property for the Margin calculation and test in IBM Cognos Analytics - Reporting. • In the Foundation Objects View, at the bottom of the gosales namespace, select

the stand-alone Margin calculation, and then in the Properties pane, change the Regular Aggregate property from Sum to Calculated.

• Move the stand-alone Margin calculation to the Presentation View > GO Operational Sales (query) > Sales (query) namespace, and then drag Margin below Sales Fact as shown below:

• Publish the GO Operational (query) package, clearing the Verify the package

before publishing check box, and clicking Yes to overwrite the existing package. • Open Google Chrome, and then sign in to IBM Cognos Analytics

(http://localhost:9300/bi/) using admin/Education1.




• Click Team content, point to GO Operational (query), click More, and then click Create report.


defaults. • On the Sources tab, expand Sales (query), and then add the following items to

the report: • Sales Fact > Revenue • Sales Fact > Gross Profit • Margin (stand-alone calculation)

• Run the report in HTML. The results appear similar to the following: Revenue Gross Profit Margin $4,686,775,768.85 $1,924,834,994.68 41% Notice the aggregated Margin value is now correct. The detail values for Gross Profit and Revenue are aggregated first and then Margin is calculated. This value has been formatted as a percentage in Framework Manager. If it had not been formatted, it would have appeared as 0.41069491898314.

• Close the rendered report tab, and then sign out of IBM Cognos Analytics - Reporting without saving the report.

• Close the web browser. • Save the Framework Manager project in C:\Training\B6252G\Course_Project,

overwriting the existing project. • Close the project, and leave Framework Manger open for the next activity.




Activity: Apply multilingual query item properties You want to ensure that users working in languages other than English can easily use the GO Operational model to create reports. You will add French support to the project, translate a query item name and description, publish the package with both French and English metadata, and test the package in IBM Cognos Analytics - Reporting. In this activity, you will accomplish the following: • Add languages to the project • Add a French name and description • Publish the model in both English and French, and create a report • Create a report to verify the French query item name and description

Add languages to the project. • In Framework Manager, open the GO Operational project located at

C:\Training\B6252G\CBIFM-Start Files\18_Apply_multilingual_query_item_properties\GO Operational.

• If prompted, log in using admin/Education1. This project has had many additional languages removed from the model in order to perform this activity.

• From the Project menu, point to Languages, and then click Define Languages. The Define Languages dialog box appears.

• In the Available languages pane, click French, click Add , and then click OK. A warning message appears, indicating that the languages will be added to every text property of every object. Optionally, you can add a locale you will not use in order to preserve the original data source table and column names if you plan to modify them in the English and French Locales.

• Click OK.




Add a French name and description. • Expand GO Operational Model > Consolidation View > Products, and then

click the Product Type query item. • At the top of the Properties pane, click the Language tab.


Notice that for the Name, Description and Screen Tip properties, you now see one field for each language. However, all entries are in English initially, the project's design language. The description and screen tip are blank for the French columns. You cannot add a French value for either the description or screen tip until you supply a value for the primary language (English).

• In the Description column, under English, type Product Type identifies a set of related products, and then press Enter. You can now add a French value, because you have supplied a value for the primary language.

• In the Description column, under French, delete the existing text, type Type de produit, and then press Enter. If you want to type a full translation, you can enter Le Type de Produit identifie un ensemble de produits liés.

• In the Name column, under French, type Type de produit, and then press Enter. You can also change the active language in the Tools pane to edit query subject names for the appropriate language. You will leave the Screen Tip empty for both English and French.

• Save the project in C:\Training\B6252G\Course_Project, overwriting the existing project.




Publish the model in both English and French, and create a report. • In Packages, click the GO Operational package, and then from the Actions

menu, click Package > Specify Package Languages. • Under Available Project Languages, select French, click the Add arrow, and

then click OK. • Publish the GO Operational package, clearing Verify the package when

publishing, and overwriting the existing package (enter group if prompted for a value). Tip: In the Properties pane for packages, you can also translate the package name and any descriptions or tool tips required by end users.


• Click Team content, point to GO Operational, click More, and then click Create report.


defaults. • In the Sources tab, expand Presentation View > GO Operational Sales (query)

> Sales (query) > Products. • Right-click Product Type, and then click Properties.

In the Description property for Product Type, the text that you specified earlier appears.

• Click Close, and then close the report without saving it.




Create a report to verify the French query item name and description. • In IBM Cognos Analytics, on the Application bar, in the upper-right corner, click

Admin Person , and then click My preferences. • Change the Content language setting to French.

If you change the Product Language to French, the UI will be displayed in French.

• Click the Application bar to close My Preferences. • Click Team content, point to (fr) GO Operational, click More, and then click

Create report. • From the Templates and themes page, select Blank, and then click OK.

Notice the package name is (fr) GO Operational, indicating the content language is in French.

• In the work area, click Add, click List, and then click OK to accept the query defaults. • In the Sources tab, expand (fr) Presentation View > (fr) GO Operational Sales

(query) > (fr) Sales (query) > (fr) Products. IBM Cognos Analytics - Reporting opens with the metadata from the (fr) GO Operational model appearing in the Sources pane. Notice that all items are prefixed with (fr). This indicates that you are now in the French version of the model but you have not yet translated all of your metadata titles and properties. Notice that Type de produit stands out from the (fr) prefixed query item names.

• Right-click Type de produit, and then click Properties. The description matches the text that you specified in Framework Manager.

• Click Close, and then close the report without saving it. • On the Application bar, click Admin Person, and then click My preferences. • Change the Content language back to English (United States). • Click the Application bar to close My preferences. • Close the browser, but keep Framework Manager open for the next activity.




Activity: Apply multilingual translation files You want to ensure that users working in languages other than English can easily use the GO Operational model to create reports. To this end, you will enhance the model by exporting a translation file and modifying it so that it contains French and English strings. You will then import this file back into the model and view the results. In this activity, you will accomplish the following: • Export metadata to a CSV file for translation • Import a CSV file that contains translated strings

Export metadata to a CSV file for translation. • Ensure you are logged into IBM Cognos Framework Manager as admin


• In Framework Manager, from the Project menu, point to Languages, and then click Export Translation File. This approach is an alternative to editing the metadata in Framework Manager, as you did in a previous activity. When you export language strings to a TXT or CSV file, you can translate them in a single edit session. You may even send this file to a translation firm for professional translation. The TXT or CSV file only contains the strings that exist. If a given item has no description or screen tip, then no entry will be created during export, and therefore no translation can be imported. For this reason, you should add descriptions and tool tips to the model objects in the primary language before exporting. The Export Translation File dialog box appears.

• In the Project Languages pane, use Ctrl+click to select both English and French,

and then click Add to move them to the Languages to be exported pane.

• Next to the Export languages to this file field, click Browse . • In the left pane, click Desktop, and then in the File name field, type

GO_Application_LOC. • In the Save as type field, select CSV (comma delimited) (*.csv). • Click Save, and then click OK.

A message appears, indicating that the language strings were successfully exported.

• Click OK.




• On the Windows Desktop, double-click GO_Application_LOC.csv to open it in Microsoft Excel, and then expand the first two columns. Notice that each column represents a given language; in this case, English and French. These are based on the language selections you made when you exported the model languages earlier.

• In the second column of row 18, change the French value of (fr) Branch City to Ville de Succursale.

• In the second column of row 21, change the French value of (fr) Branch Country to Pays de Succursale.

• Save the file, click Yes to the warning message, and then close Microsoft Excel without saving again.

Import a CSV file that contains translated strings. • In Framework Manager, from the Project menu, point to Languages, and then

click Import Translation File. The Import Translation File dialog box appears.

• In the Project Languages pane, click French, and then below Translate into,

click Add to add it to the Translate into pane. • Next to the Import translation table from this file field, click Browse. • In the Files of type list, click CSV (comma delimited) (*.csv), navigate to the

Desktop, and then double-click GO_Application_LOC.csv • Click OK to close the Import Translation File dialog box.

A message appears, indicating that the import was successful. All objects that reference the translated metadata are updated, such as items in the Consolidation View and the Dimensional View.

• Click OK. • In the Project Viewer pane, expand GO Operational Model > Consolidation

View > Branch by Location, and then click Branch Country.


Thank you for taking a class with us.

We look forward to working with you again soon.

Powered by TCPDF (www.tcpdf.org)Name: Kari Hurst Email: [email protected] TCW Adobe Connect 2021/03/08

http://www.tcpdf.org

IBM Cognos Framework Manager: Design Metadata Models ...

Documents

Transcript of IBM Cognos Framework Manager: Design Metadata Models ...