When you organize the model, you make it easier for your users to find and understand the data in the model. You also make the model easier for you to manage and maintain. We recommend that you create several views, or layers, in the model:

• Keep the metadata from the data source in a separate namespace or folder.

  In Framework Manager, this is called the import view.

• Create one or more optional namespaces or folders for resolving complexities that affect querying using query subjects or dimensional objects.

  To use Analysis Studio or any OLAP-style queries, there must be a namespace or folder in the model that represents the metadata with dimensional objects.

• Create one or more namespaces or folders for the augmented business view of the metadata that contains shortcuts to dimensions or query subjects.

  In Framework Manager, these are called the business view. Use business concepts to model the business view. One model can contain many business views, each suited to a different user group. You publish the business views.

Security can be defined in any of the views. It depends on your business requirements. For example, if you need to keep everyone from viewing an object, you add security to the object in the import view. Typically security is applied in the business view.

You will likely see dimensional query subjects that are joined to more than one fact query subject. Join ambiguity is an issue when you report using items from multiple dimensions or dimensional query subjects without including any items from the measure dimension or fact query subject. This is called a fact-less query.

For example, Product and Time are related to the Product forecast and Sales facts.

Using these relationships, how do you write a report that uses only items from Product and Time? The business question could be which products were forecasted for sale in 2005 or which products were actually sold in 2005. Although this query involves only Product and Time, these dimensions are related through multiple facts. There is no way to guess which business question is being asked. You must set the context for the fact-less query.

In this example, we recommend that you create two namespaces, one containing shortcuts to Product, Time, and Product forecast, and another containing Product, Time, and Sales.

When you do this for all star schemas, you resolve join ambiguity by placing shortcuts to the fact and all dimensions in a single namespace. The shortcuts for conformed dimensions in each namespace are identical and are references to the original object. Note: The exact same rule is applied to regular dimensions and measure dimensions.

With a namespace for each star schema, it is now clear to your users which items to use. To create a report on which products were actually sold in 2005, they use Product and Year from the Sales Namespace. The only relationship that is relevant in this context is the relationship between Product, Time, and Sales, and it is used to return the data.

A shortcut is a pointer to an object, such as a relationship, a dimension, a query subject, or a folder. We recommend that you 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.

When you create a shortcut, Framework Manager does not set the Screen Tip and Description properties. Unless you define these properties, the values shown in the Cognos 8 studios are the same as those defined in the object that the shortcut references.

Tip: To go to the object that the shortcut references, right-click the shortcut and click Go To Target.

Shortcuts are less flexible from a presentation perspective than model objects, but they require much less maintenance because they are automatically updated when the target object is updated. If maintenance is a key concern and there is no need to customize the appearance of the query subject, use shortcuts.

Framework Manager has two types of shortcuts:

• regular shortcuts, which are a simple reference to the target object.

• alias shortcuts, which behave as if they were a copy of the original object with completely independent behavior. Alias shortcuts are available only for query subjects and dimensions.

Regular shortcuts are typically used as conformed dimensions with star schema groups, creating multiple references with the exact same name and appearance in multiple places. 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.

Alias shortcuts are typically used in role-playing dimensions or shared tables. Because there is already an example in this document for role-playing dimensions, we will look at the case of 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.

Shortcuts and Relationships

When you decide where to place shortcuts, consider how the scope of the shortcut affects relationships. Shortcuts in a different folder from the target query subject use the relationships of the target query subject. Shortcuts in the same folder as the target query subject ignore the relationships of the target query subject and use only those specified for the shortcut.

You can specify a different relationship for a shortcut than the relationships of the target query subject. By creating relationships from the shortcut to other query subjects, you avoid cross-join errors in the model.

You cannot create shortcuts to scope relationships.

Shortcuts and Dimensions or Query Subjects

Shortcuts result in fewer dimensions or query subjects to maintain. You can keep dimensions or query subjects in the import view and keep shortcuts in the business view. Shortcuts are most frequently used when creating star schema groups.

When you create a shortcut to a dimension or query subject, you cannot customize which query items are in the shortcut. The entire dimension or query subject is included in the shortcut.

Being able to specify the behavior of shortcuts is new to Cognos 8.3.

When you open a model from a previous release, the Shortcut Processing governor is set to Automatic. When Automatic is used, shortcuts work the same as in previous releases, that is, a shortcut that exists in the same folder as its target behaves as an alias, or independent instance, whereas a shortcut existing elsewhere in the model behaves as a reference to the original. To take advantage of the Treat As property, it is recommended that you verify the model and, when repairing, change the governor to Explicit. The repair operation changes all shortcuts to the correct value from the Treat As property based on the rules followed by the Automatic setting, this means that there should be no change in behavior of your model unless you choose to make one or more changes to the Treat As properties of your shortcuts.

When you create a new model, the Shortcut Processing governor is always set to Explicit.

When the governor is set to Explicit, the shortcut behavior is taken from the Treat As property and you have complete control over how shortcuts behave without being concerned about where in the model they are located.

Shortcuts can be created by the Create Star Schema Grouping wizard. For example, a fact table and its dimension tables are stored in the import view. If you want to represent conformed dimensions in several star schema groups, only one dimension or query subject can exist for each dimension table. Use shortcuts for all other instances of the dimension or query subject. By using shortcuts, you can build queries involving multiple fact tables that are related through shared dimension tables.

You can create folders or namespaces to organize objects in the model.

The most important thing to know about namespaces is that once you have begun authoring reports, any changes you make to the names of published namespaces will impact your Cognos 8 content. This is because changing the name of the namespace changes the IDs of the objects published in the metadata. Because the namespace is used as part of the object ID in Cognos 8, each namespace must have a unique name in the model. Each object in a namespace must also have a unique name. Part of the strategy of star schema groups is placing shortcuts into a separate namespace, which automatically creates a unique ID for each object in the namespace. This allows us to use the same name for shortcuts to conformed dimensions in different star schema groups.

The next time you try to run a query, report, or analysis against the updated model, you get an error. If you need to rename the namespace that you have published, use Analyze Publish Impact to determine which reports are impacted.

Folders are much simpler than namespaces. They are purely for organizational purposes and do not impact object IDs or your Cognos 8 content. You can create folders to organize objects by subject or functional area. This makes it easier for you to locate metadata, particularly in large projects.

The main drawback of folders is that they require unique names for all query subjects, dimensions, and shortcuts. Therefore, they are not ideal for containing shared objects such as conformed dimensions.

Tip: When viewing metadata in the Diagram tab, you can expand or collapse folders and namespaces. From the Diagram menu, click Collapse All or Expand All.

If you set security on a folder and then move objects into the folder, confirm that exclusions are set correctly.

You can create query item folders to organize query subjects or dimensions that contain a large number of query items. A query item folder can contain only query items and query item folders.

If you create a query item folder, you cannot change the order of query items in the Edit Definition dialog box for the model query subject. You can change the order of items only in the Project Viewer.

You can create measure folders to organize measure dimensions that contain a large number of query items. You can nest measure folders within other measure folders.

You cannot create a measure folder from a measure shortcut.

If you create a measure folder, you cannot change the order of measures in the Edit Definition dialog box for the measure dimension. You can change the order of measures only in the Project Viewer.