framework manager cardinality

Download Framework Manager Cardinality

Post on 14-Apr-2015

296 views

Category:

Documents

3 download

Embed Size (px)

DESCRIPTION

Framework

TRANSCRIPT

FRAMEWORK MANAGERFramework Manager is a Cognos 8 modeling tool for creating and managing business-related metadata for use in all Cognos 8 BI applications. It lets modelers model relational data dimensionally, apply hierarchies to allow drill behavior, apply member functions and query any of the supported data sources (relational database with SQL or OLAP with MDX).

1) What are the different types of data sources used by Framework Manager?The ability to pull data from multiple data sources is one of Cognos' strengths. Native Metadata - IBM Cognos 8 supports OLAP data sources as well as relational data sources. The term native metadata refers to objects such as models, packages, and queries that are based on an OLAP data source. OLAP data sources are metadata rich data sources. A data source is necessary to create models in Framework Manager. A data source defines the physical connection to a database. IBM Cognos 8 supports the following types of data sources: DB2 IBM Cognos Cubes IBM DB2 OLAP and Hyperion Essbase IBM Infosphere Warehouse Cubing Services Informix Microsoft SQL Server Microsoft Analysis Services ODBC Oracle SAP BW TM1 XML -----------------------------------------------------------------------------------------------------------

2) Cardinality or RelationshipsThe cardinality of a relationship defines the number of rows of one table that is related to the rows of another table based on a particular set (or join) of keys. Cardinality is used by IBM Cognos 8 to infer which query subjects behave as facts or dimensions. Relationships exist between two query subjects. The different types of relationships are: one-to-one One-to-one relationships occur when one instance of data in a query subject relates to exactly one instance of another. For example, each student has one student number. one-to-many or zero-to-many One-to-many or zero-to-many relationships occur when one instance of data in a query subject relates to many instances of another. For example, each teacher has many students. many-to-many Many-to-many relationships occur when many instances of data in a query subject relate to many instances of another. For example, many students have many teachers. IBM Cognos 8 uses the cardinality of a relationship in the following ways: to avoid double-counting fact data to support loop joins that are common in star schema models to optimize access to the underlying data source system to identify query subjects that behave as facts or dimensions IBM Cognos 8 supports both minimum-maximum cardinality and optional cardinality. In 0:1, 0 is the minimum cardinality, 1 is the maximum cardinality. In 1:n , 1 is the minimum cardinality, n is the maximum cardinality. A relationship with cardinality specified as 1:1 to 1:n is commonly referred to as 1 to n when focusing on the maximum cardinalities. A minimum cardinality of 0 indicates that the relationship is optional.

When generating queries, IBM Cognos 8 follows these basic rules to apply cardinality: Cardinality is applied in the context of a query. 1 to n cardinality implies fact data on the n side and implies dimension data on the 1 side. A query subject may behave as a fact query subject or as a dimensional query subject, depending on the relationships that are required to answer a particular query. Cardinality & Joins 0..1 to 0..1 Full outer join 0..1 to 0..n Full outer join 0..n to 0..n Full outer join 1..n to 0..n Right outer join 1..n to 0..1 Right outer join 1..1 to 1..n Inner join 0..n to 1..n Left outer join 0..n to 1..1 Left outer join Cognos defines relationships in both directions. The order in which the tables are specified is important. ----------------------------------------------------------------------------------------------------------

3) Difference between alias and shortcutA shortcut is a pointer to an object, such as a relationship, a dimension, a query subject, or a folder. Shortcuts are automatically updated when the target object is updated. Why shortcuts? Use shortcuts in the business view when there is an overlap between user groups and you want to include the metadata in more than one folder. With shortcuts, you can have multiple references to an object. For example, you create folders named Orders, Products, and Customers. If you want both Orders and Customers to contain the same dimension, you must create a shortcut to the dimension and add it to both folders. Why alias? Framework Manager imports reflexive relationships ,which are self-joins. To create a functioning reflexive relationship, you can create an alias shortcut. In the case of loop joins, ambiguously defined query subjects are the primary sign of problems. Aliases can be used to resolve loop joins. When query subjects are ambiguously defined and are part of a loop join, the joins used in a given query are decided based on a number of factors, such as the location of relationships, the number of segments in join paths, and, if all else is equal, the alphabetically first join path. Loop Join Example It is possible to join Branch directly to Order or through Sales Staff to Order. The main problem is that when Branch and Order are together, you get a different result than when the join path is Branch to Sales Staff to Order.

Framework Manager has two types of shortcuts: regular shortcuts alias shortcuts Regular Shortcut Is a simple reference to the target object Alias Shortcut Behaves as if it is a copy of the original object with completely independent behavior. Alias shortcuts are available only for query subjects and dimensions. Used in role-playing dimensions or shared tables.

Typically used as conformed dimensions with star schema groups, creating multiple references with the exact same name and appearance in multiple places.

Conformed dimensions with star schema group In the example below, the shortcuts created for Products and Order Time behave as references. If a query is written that brings Products from both Product Forecast and Sales Target, the query uses the definition of Products based on the original and this definition appears only once in the query.

Role playing Dimensions A table with multiple valid relationships between itself and another table is known as a role-playing dimension. This is most commonly seen in dimensions such as Time and Customer. For example, the Sales fact has multiple relationships to the Time query subject on the keys Order Day, Ship Day, and Close Day.

Shared Tables In this example, Sales Staff and Sales Branch can be treated as different hierarchies. From our knowledge of the data, we know that because staff can move between branches, we need to be able to report orders against Sales Branch and Sales Staff independently as well as together. To achieve this, we need to create an alias to Sales Branch that can be used as a level in the Sales Staff hierarchy.

With the new alias shortcut in place, it is possible to create queries that require orders by sales branch and orders by sales staff with their current branch information simultaneously. -----------------------------------------------------------------------------------------------------------

4) What are the different layers in Framework Manager ? Why are they needed?Database Layer Contains Data source query subjects Define query item properties Define all relationships Calculations and filters where possible Shields presentation layer from data(base) changes

Presentation Layer The presentation layer is used only as an organization structure in order to make it easier for report writers to more easily find their needed information. This layer includes shortcuts , plus organization items such as folders and namespaces. Dimensional Layer The dimensional layer is required only for models which include dimensionally modeled data. Leaving aside the trivial situations where cubes are simply imported into the model, this includes dimensionally modeled relational data (DMR). Specifically, this is for creating Dimensional and Measure Dimension Query subjects.

By structuring the framework in a layered approach, any downstream effects of database changes can be minimized , i.e. this will shield the end-user from changes at database level such as migration to a different database technology or version or changes to column or table names. By creating an efficient layered structure, relational models can be modeled into virtual star schemas , providing predictable and reliable query results to the end user.

5) Parameter MapsWe use parameters to create conditional query subjects that allow for substitutions when the report is run. Parameter maps are objects that store key-value pairs. Parameter maps are similar to data source look-up tables. Each parameter map has two columns, one for the key and one for the value that the key represents. You can manually enter the keys and values, import them from a file, or base them on existing query items in the model. Steps to Manually Create a Parameter Map1. Click the Parameter Maps folder and, from the Actions menu, click Create,

Parameter Map.2. In the Name box, type a name for the new parameter map. 3. Click Manually enter the parameter keys, and/or import them from a file and

click Next. 4. Do one of the following: To manually enter values, click New Key, type a key, and press Tab to enter a value for that key. To import keys and values, click Import File and identify the location of the appropriate .csv or .txt file. For a .txt file to be used for import, the values must be separated by tabs and the file must be saved as UTF8 or Unicode format. ANSI text files are not supported. 5. Modify existing parameters as required. Goal Assign a default value Action In the Default Value box, type a value. If the key is used in an expression that is not mapped, the default value is use