*** This package is subject to change. ***

Note:

Extension of the classes in this package is prohibited unless otherwise documented. Similarly, extension or implementation of the interfaces in this package is prohibited except as documented.

Package com.sas.iquery.metadata.business

The main package that provides modeling for SAS Query Services's two business models (information maps and data selections), which provide a logical layer of metadata modeling above the physical layer model.

See:
Description

Interface Summary

Base
BriefInformationMap	A thin object that represents an IQ Information Map in a repository.
BusinessGroup	The purpose of this object to allow the ability to group certain IQ objects outside of our normal MapFolder structure.
BusinessItem	Specifies a modeled object that has an identity within its model and used directly in forming business queries.
BusinessModel	Specified an abstract, persistable container that contains BusinessModelObject type items.
BusinessModelObject	Specifies an abstract, persistable object that is contained within a business model container and provides support for having a unique identity within that container.
BusinessModelResource	Specifies objects that can be referenced by business models other than the one they are contained in.
BusinessModelResourceReferencer	Specifies an object that can reference one or more BusinessModelResource objects.
BusinessQuery	Specifies the interface that models the information that is necessary to request a result set based on business items that are contained in business models that are managed by the Intelligent Query Metadata Service.
BusinessRule	Specifies a modeled action that affects how data is referenced at query execution time.
CascadableFilter	A class that implements this interface can by used by the the FilterCascadeInterface as a dependent filter.
CascadeRule	Contains the collection of dependent CascadeRuleItem objects and CascadableFilter objects for single CascadeRuleItem.
CascadeRuleItem
CascadeRuleSet	Contains the set of CascadeRule objects defined on a business query
CompoundFilter	Specifies a filter that is definedin terms of other separately defined filters.
DataItem	Provides support for the mapping of physical data to a single unit of business data.
DataItemReference	Specifies a reference to a DataItem object along with some set of overridden attributes of the base data item.
DataSelection	Specifies an object that is a business model and that provides the specification of a business query.
DrillThroughToDetail	Specifies a simple business rule that identifies whether the user should be allowed to drill through to detail data in OLAP results.
FilterCascadeContainer	Business Objects that can contain FilterCascadeInterfaces should implement this interface.
FilterCascadeContainerUpdater	Business objects that can modify there list of FilterCascadeInterfaces should implement this interface.
FilterCascadeInterface	Defines the prompt filter dependencies that makes up the cascade.
FilterCascadeRule	This business rule defines the prompt filter dependencies that makes up the cascade.
FilterItem	Contains a single conditional expression which is used to filter data when running a query and typically yields a resultset containing less data.
Governing	Specifies a simple business rule that governs or limits the output of a business query when the query is run.
InformationMap	Specifies a business model that provides support for organizing its business items within an internal folder structure.
LocalizableModelObject	Implemented by a model object that has localized labels and descriptions and provides methods to modify them.
MapFolder	A folder used for organizing business items within an InformationMap.
Model	A SAS Query Services model is a persistable container of information relating to queries.
ModelItem
ModelItemWithIdentity
Prompt	Enables you to specify portions of a business query at the time a query is run.
UsabilityInterface	Specifies objects that can be asked if they are usable in a business query and what the reasons are if they are not usable.

Class Summary

BusinessQueryActionType	Specfies the different types of actions that can be performed on a BusinessQuery.
BusinessQueryProperty	Defines properties for the Business Query
BusinessQueryTotalLocationType	Specfies the different total location that can be applied to a BusinessQuery.
BusinessQueryTotalModeType	Specfies the different total mode for the business query.
ChangeHistoryItem	Contains a single piece of history about a change that was made.
DataItemActionType	Specifies the different types of actions that can be performed on a data item.
DataSelectionFactory	A factory for creating DataSelection objects.
Drill	Stores drill history information for a cube inside a data selection.
FilterCascade
InformationMapFactory	Specifies a factory class for creating new instances of information map objects.
Lookup	Determines lookup type values that are set on the data item.
LookupByDataItem	Defines a Lookup that defines the data item it is associated with should be used for retrieving possible filter values.
LookupList	Contains a list of LookupValue objects that are used for possible filter values for a data item.
LookupNotAllowed	Defines a Lookup type where looking up values is not allowed.
LookupValue	Defines a single lookup value that is used by LookupList.
ModelVersion	Specifies an object that represents the version of a SAS Query Services model (information map or data selection).
Reason	Models information that gives a "reason" for some fact within the business model.
Role	Specifies the different multidimensional roles that a data item can take when it is used in the list of result items that is managed by the BusinessQuery interface.
SelectedItem	Specifies the combination of a data item (result item) and its role in a single object.
StructureOfDataItem	Specifies the different types of data item structures.

Enum Summary

BusinessGroup.Type
InformationMapFactory.FactorySettings.TYPE
QueryWriteOption	Allows for writing out drill history in cube data selections.

Package com.sas.iquery.metadata.business Description

The main package that provides modeling for SAS Query Services's two business models (information maps and data selections), which provide a logical layer of metadata modeling above the physical layer model.

Information maps provide a set of metadata objects that are defined on top of the physical model and that map physical objects (such as relational columns and OLAP dimensions) to a higher layered object called a business model object. Mapping is done by using expressions, steps and other metadata to provide a high level of functionality. These objects are then persistable within the information map container.

Data selections are query specifications that are built on metadata that is defined in and supplied by information maps. Data selections also enable you to model higher level, business model objects. The common modeling capabilities of information maps and data selections are provided by a base class called a business model.

The Business Model

A Business model and the objects that are contained within it are used in order to model data. The information that is used to model the data is usually of a "physical" nature. This means that it pertains to the physical type of data that the user wants to model and query. Another type of information that is used for modeling is user information that provides knowledge of how the data should be used.

The Business Model Object and Its Flavors

You can use a business model to create "business model objects" for modeling information about data. You add those objects to the business model in order to use them and persist them. If you do not add them to the business model, then they are considered useless.

There are three categories of objects that are contained within a business model and that are used to model data. They are:

• Data sources
• Business rules
• Business items

Data sources provide information about the sources of data such as database objects, tables, cubes, files, and information about how to access those sources.

Business rules provide information about how to use the data from the data sources. For example, rules on how to join tables or preferences on which servers to use when moving data.

Business items provide a layer of business information above the physical information; that layer of business information adds a logical layer for shielding, sharing and transparency from the physical information.

There are a few types of business items:

• Data items -- provide support the mapping of physical data to a single unit of business data. Data items enable you to describe things like formatting and ordering. Data items represent the smallest unit returned by a business query.
• Filters -- provide a means for restricting the set of data returned from queries.

Each category and type of business model object is more fully documented by its class level javadoc.

Chaining of Business Models

Business models are either a base model (which has no dependencies on other models) or are conceptually chained together. This chaining is a means of "basing one business model on another". This means that the business items that are defined in a non-base business model can be based on business items in any business model that its business model is based on. For example, an information map might be the base model of a data selection and thus data items that are defined in the data selection can be based on data items in the information map. If a second data selection is based on the first data selection, then business items in that second data selection can be based on any mixture of business items in the first data selection and business items in the information map.

Currently, this chaining of business models is limited to support inter-model usages only between business items. Architecturally, there is no reason that implementation can be extended in order to provide support for inter-model usages between data sources and business rules. For example, if you want to provide governing capabilities in data selections but only for specific data sources that are defined in an earlier business model, or, for example, you want to enable the user in a data selection to override the join attributes that are specified in the information map, then the architecture enables these types of extensions.

Multiple chains/trees of usage

Each business model knows only of its own base business model (if any) and does not directly know of any other business models. The business model knows of a source that supplies information to make up the model's definition. The business model does not know which business models are dependent on it, nor does it have any direct association with business models that its base business model is dependent (based) upon.

These chains form a tree of business model usages, although this is not directly reflected in the model. A business model can be used as the base model for N number of business models. Each of those business models can be used as a base for N other business models. As mentioned previously, the "usage" information (if viewed as forward looking information) is not currently reflected in the model. The model reflects only information about what makes up a business model's definition (backward looking information).

Types of Business Models

Currently there are two concrete types of business models: information map and data selection. There is more information about each of these in the following section.

All about IDs

The Business Model's ID

Each business model has its own ID. That ID must be unique within the chain of business models that it is used within. For example, if a data selection is created based on an information map, then the data selection must have a different ID than the information map. If a second data selection is based on that first data selection, then it must have a different ID from the other two business models within the chain (the information map and first data selection).

When each business model is created, it is automatically given a unique, default ID within the chain of business models that it is based on.

Two Views of a Business Model Object ID

There are two views of a business model object's ID. They are not two separately managed IDs, but rather two views of the same ID for the object. Each view of the ID has a name. They are called

• Intra-Model ID. This (view of the) ID is unique within the business model that contains the object.
• Inter-Model ID. This (view of the) ID is unique within the chain of business models that its object's business model is based on. This ID is made up of the business model's ID concatenated with a "." and then concatenated with the intra-model ID for the object. This view of the ID adds the business model's ID to provide a view of the ID that is unique within the environment (the chain of business models that is being used).

When each business model object is created, it is automatically given a unique, default (intra-model) ID within its business model.

Business Model Objects and IDs

All business model objects, which are created and contained within a business model, have (intra-model) IDs.

The main purpose for having IDs associated with business models and their contained objects is so that object references between business models and between their business model objects (across business models) can be represented when persisted.

For example, suppose an information map contains a data item called Revenue with both its label and intra-model ID set to "Revenue". Suppose a data selection had a data item called Profit that is defined as (Revenue - Expense) where Expense was another data item in the data selection. A reference between business models exists in the Profit data item's definition. To unambiguously reference the Revenue data item in persisted form, its inter-model ID should be used when persisting a reference to it.

Managing IDs and Repairing Parts of a Business Model

There is an inherent problem when you use IDs between two persisted models to refer to objects within the models. That is, if the objects that you refer to are deleted or have their IDs changed, then the dependent references become unresolved. This causes object that refer to those change or deleted objects to become unusable in queries until their definitions are repaired by supplying a resource to replace the resource that is now missing.

Applications that create business models that are to be the base for other persisted models (for example, SAS Information Map Studio creates information maps that are used by persisted data selections) should enable you to manage the IDs for the business model and for each of its contained objects. This should be done so that when you see information about unresolved references while using other applications, you will see meaningful IDs with meaningful names rather than generic, automatically generated default IDs such as DI_1.

Applications that create business models that use other business models as their base (for example, an application that creates data selections that are based upon information maps) should enable you to repair unresolved linkages to any business model objects it refers to from its data selection. This should be done because references to objects it depends on in any base business model (for example, an information map) might not exist anymore, which causes objects to become unusable in queries until those unresolved references are repaired.

Enforcement of Uniqueness of IDs

The enforcement of ID uniqueness within their context/namespace is enforced at persistence time.p>

Persistence of Business Models

As mentioned earlier, business models can use (be based on) other business models; that is, you can have a chain of business models. Because every dependent business model in a chain depends on its base business model to supply some context of its definition, there is a "creation order" that is required when reading in business models from storage. For example, when a data selection is being read in that is based on an information map, the information map must be read in prior to fully reading in the data selection. This is done so that the information map's contained objects are available when constructing the data selection's definition.

This "read order," starting at the base-most business model, is inherent to business model persistence. The business model code base does provide for automatic reading in of base models within the base-model chain, although use of this mechanism is not required. Also, re-use of business models that have already been read is provided for times when you might have multiple persisted business models that are dependent on the same base business model (for example multiple data selections that are based on the same information map) and you don't want the base business model to be re-read for each business model to read in. See the DataSelectionFactory.readDataSelection() method.

For example, suppose a persisted data selection is dependent on a persisted information map and the information map's persistent location was known when the data selection was written. The information map will be automatically read in if the Information Map was not supplied when reading in the data selection. Second and later calls to DataSelectionFactory.readDataSelection() can re-use the information map that was already read in for this usage. Note that this caching of business models by any client code should only be done within a safe context, for example, within a single user's use of a set of business models.

When automatic reading in of base business models occurs, those base business models and their contents are marked read-only and any attempts to change their contents will result in a runtime MetadataNotChangeableException.

The Information Map

Information Map Folders

The main function that information maps provide in addition to what they inherit from the business model, is the organization of their business items into folders called information map folders. Each information map contains a "root" information map folder which always exists. From that root folder, you can manage an arbitrarily deep nesting of information map folders, each folder containing the set of business items that the user wishes to have according to his own organizational needs. Information map folders provide support for organizing business items that are defined and contained within an information map. They do not provide support for organization of any data sources or business rules.

These information map folders not only enable a user to organize his business items but might also enable future "grouped functionality" from the model, such as securing the contents of a information map folder.

The Data Selection

A business data selection is a business model with capabilities to model information on what you want to query. You can create a business data selection via the DataSelectionFactory.newDataSelection(...) methods.

Usage and aggregations

Relational usage and aggregations

Data items in relational queries can be used as categories, aggregate measures or detail measures.
Categories are used to group aggregated measures based on the measures' aggregation function. For example to return a sum of all weights for pupils of a given sex, you would use a sex data item as a category and weight as an aggregated measure data item using the SUM function.
See Relational usage use case for an example.

Filtering and ranking

The modeling of how filtering is done is one area that is not transparent between OLAP and relational data.

Relational Filtering

Relational filtering is done through the creation and use of expressions from the com.sas.iquery.metadata.expr.relational package in FilterItem and CompoundFilter objects and specifying one or more of those filter objects on the DataSelection.setFilters() method. If more than one filter is specified on setFilters(), then filters are treated as if they were logically joined with AND.
For an example of how to use relational filters, see Relational filtering use cases.

Ranking enables the query to return either just the top (or bottom) N values of a given data item or the top values together representing at least N% of the total.
See Relational ranking use cases.

OLAP Filtering

OLAP Filtering can be illustrated in the following model.

OLAP filter that are applied (at run-time) as a step to a data item or business query are defined as a "child" filter (as displayed by the innermost box). They are applied using the step model.

OLAP "ByGroup" filter are applied as an special internal expression that is applied through the ByGroupCreator class.

OLAP filters that are applied (in IMS for the map) as expression to the business query are defined as a "parent filter (as displayed by the outermost box). They are applied as a filter for the DataSelection. A filter expression would require the definition of "WhatToFilter (dimension to filter)", a comparison operator, and a constant value and/or data item for comparison. See OLAP filter expression use case for an example.

Totaling

Relational Totaling

Currently, relational totals are calculated only for items whose aggregation function is either SUM, COUNT, FREQ, N or an expression defined by SAS Information Map Studio to be additive.

Applications that use data items which have embedded aggregations must explicitly sent the aggregation type for those data items if that data item is to be used as part of another expession or aggregation.

Function internalAggregationAdditive =
serverProperties.getFunctionByNameID(
FunctionNameID.INTERNAL_AGGREGATION_ADDITIVE );
item.setAggregationType( internalAggregationAdditive );

For examples of using relational totals, see Relational totals use case.

OLAP Totaling

OLAP has two types of totaling - "Visual Visuals" and "Cube Values".

• Visual Total is a sum of all the members at a given level which actually appear in the result set.

• Cube values are the standard aggregate value for a given member as returned by the server. Note that the value a user sees may not include all children, if security is set so that a user does not have access to all of the children, or if the query contains a filter and the user has asked for "visual total" instead of "cube value". Note that an item may or may not be a "parent" depending on context. For example, if Southeast occurs along with North Carolina , it is a parent, but if it occurs with Wake County (a grandchild) it is not. Parent values can occur either when the query contains a filter or when the user has asked for subtotals. They cannot be created just by doing an Expand or a Drill. See "all member".

Below denotes how "Cube value" contrasts "Visual Total".

Example:

Starting with the following "full" table:

If we drill and ask for "visual" totals we get:

If we now switch to "cube" totals we get instead:

Row Total and Column Total (Axis Total) occurs at the outermost hierarchy and level in the result set on either the column axis or the row axis. Column totals are displayed as the last/first row(s) on the row axis. Row totals are displayed as the last/first column(s) on the column axis. When a total is coalesced, there is a single row/column for total. If total is not coalesced, you will see the natural multidimensional presentation.

Subtotal is the value for a parent that has been added to the output because the user has asked for subtotals. It can therefore be either a Visual Total or a Cube Value.

Grand Total is the visual total or cube value on the bottom right (or top left) of a grid. This is naturally presented as the cell where Row Total and Column Total intersect. Note: There may be more than one grand total as there may be more than one measure.

Coalesced defines that most crossings with non-leaf members on outer dimensions are removed. Specifically, the rule for removing crossings is: For each outer dimension on an axis, starting with the outermost dimension and working in, remove crossings with that dimension's non-leaf members. The exception is where the member for the dimension nested within the current dimension is the common ancestor of all other members in that dimension (an example of this would be the All Member). If there is no member that is the common ancestor, remove no crossings.

The total and subtotal should inherit the inherent statistic of the current measure in the same way as the AGGREGATE function. This means that measures which are non-additive should be computed in accordance with the appropriate semantics for the various statistics: AVG, MIN, MAX, etc.

For a definition of how OLAP totaling can be applied and how it will appear, see OLAP Business QueryTotaling Use Cases

Sorting

Sorting is done by specifying the sort direction on the data item to be sorted by and specifying that data item in the list of result items that is maintained by the data selection. You can specify the sort order precedence between data items on the data selection. If a data item that is contained within the list of result items specifies a sort direction other than "none" but is not in the sort order precedence list, then its sort direction it will be honored but will be sorted with a precedence lower than all other data items that are specified in the sort order precedence list. For example, data items A, B and C are all set to "sort ascending" and are in the result item list but only A and C are in the sort order precedence list. Thus, the sort order precedence is A, C and then B.

Relational Sorting

For relational data, it is possible to sort by a data item that is not returned in the result set for a query by setting the "HIDDEN" role for the data item that is to be sorted by but not returned.
For an example of how to apply sorting to data items in a relational query, see Relational sorting use case.

OLAP Sorting

OLAP sorting (Order) arranges members of a specified set, optionally preserving or breaking the hierarchy. There are two varieties of Order: hierarchized (ASC or DESC) and nonhierarchized (BASC or BDESC, where B stands for Break hierarchy). The hierarchized ordering first arranges members according to their position in the hierarchy. Then, it orders each level. The nonhierarchized ordering arranges members in the set without regard to the hierarchy.

Sorting can be either applied to a category data item set or to the entire business query set. For a definition of how OLAP sorting can be applied and how it will appear, see either DataItem Sorting Use Case or Business Query Use Case

Note:

If the BusinessQueryProperty.BUSINESS_QUERY_OLAP_SORT_PRECEDENCE is set to TRUE, then the business query is honored and a category data item sort is not honored. The following MDX would be generated:

SELECT {[Measures].[ACTUAL_AVG]} ON COLUMNS,
ORDER (
CROSSJOIN(
{[TIME].[YEAR].MEMBERS},
{[GEOGRAPHIC].[COUNTRY].MEMBERS}),
[Measures].[ACTUAL_AVG], DESC)
ON ROWS
FROM PRDMDDB

If the BusinessQueryProperty.BUSINESS_QUERY_OLAP_SORT_PRECEDENCE is set to FALSE, then both the business query sort and a category data item sort are honored. The following MDX would be generated:

SELECT GENERATE ( ORDER([TIME].[YEAR].MEMBERS,[TIME].CURRENTMEMBER.NAME, BDESC),
CROSSJOIN ( {[TIME].CURRENTMEMBER },
ORDER( [GEOGRAPHIC].[COUNTRY].MEMBERS,
[Measures].[ACTUAL_SUM],BDESC) ) )
ON ROWS,
{[Measures].[ACTUAL_SUM]} ON COLUMNS
FROM PRDMDDB

Roles

Relational roles

The roles of data items have a special meaning when you are building relational queries: in order to return a plain table, all data items in a relational query must have a role of Role.COLUMN. If any items in a relational query have a role of Role.ROW or Role.BACKGROUND, then the result will not be a regular tabular result set, but instead will be a multi-dimensional cross tabular data set, similar to those that are returned by OLAP queries.

Several common uses of a role of Role.HIDDEN are:

• Including other data items used to comprise the Join information used when constructing the query without returning those data item in the resultset.

• It is possible to group by a data item that is not returned in the result set for a query set. You can do this by setting the "HIDDEN" role for the data item to be grouped by but not returned.

See Relational roles use case for an example of how to build relational cross tabulations.

OLAP roles

Unlike relational queries, the type of result that is returned for OLAP queries is always multi-dimensional, even if all the items are to be set to be on the COLUMN role. Roles have multiple purposes for the OLAP data selection. A role can define an axis specification or a slicer specification.

An axis specification - This would mean that a dataItem was defined as a ROW or COLUMN. It defines the dataItem as units (members) along each output axis.

In the figure below, the data item called "Store" (which has two levels) has a role of Role.COLUMN and the data item called "Accounts" (which has two levels) has a role of Role.ROW.

A slicer specification - a role of Role.BACKGROUND defines what slice of the cube is to aggregated. Applying a slicer role would define a where clause. The WHERE clause further restricts the result set. The axis that is formed by the WHERE clause is referred to as the slicer. The WHERE clause determines which dimension or member is used as a slicer dimension. This restricts the extracting of data to a specific dimension or member. Any dimension that does not appear on the output axis (in the SELECT clause as either a ROW or COLUMN) can be named on the slicer.

For example: To limit the result to Sales in 1997 and display only Unit Sales, these hierarchical levels are placed in the slicer specification.

If a role of Role.HIDDEN is applied, the following rules are followed

Expectations for OLAP items assigned to HIDDEN role (Data may be displayed in either crosstab or graph)

Based on knowledge of existing IQ support, for OLAP, the expectation is that IQ would apply the existing slicer logic for BACKGROUND items to items in the HIDDEN role that are categories. Assuming all the items below have a usage type of CATEGORY, this would mean that if any were placed into the IQ HIDDEN role, they would be placed on the slicer in the resulting query. Any items with a usage type of AGGREGATE would not be placed on the slicer.

Examples of HIDDEN items that would get placed on the slicer:

1. DataItem is a basic Hierarchy

2. DataItem is a basic Hierarchy with a starting level

3. DataItem is a ResourceAwareStringExpression

4. DataItem contains a single filter or rank step

5. DataItem contain a single navigation step

6. DataItem contains a navigation step but is followed by a filter or rank

7. DataItem contains a filter or rank, but is followed by navigation

8. DataItem contains a sort

OLAP Use-case 1: Filter on a TIME data item that has been assigned the IQ HIDDEN role. End user wishes to see Catalog sales information for the first half of 2001 but does not want the Time dimension shown.

(M) ? indicates a measure

Row items: Catalog

Column items: SALES (M)

Hidden items: TIME

Filter: Member filter step applied to TIME that selects the dates ?2001.Q1? and ?2001.Q2? (i.e. the first two quarters of 2001).

OLAP use-case 2: Filter on a measure COST data item that has been assigned the IQ HIDDEN role. End user wishes to see information for all Catalogs where the 2001, COST exceeded $100.

(M) ? indicates a measure

Row items: Catalog

Column items: TIME, SALES (M)

Hidden items: COST (M)

Filter: Filter step applied to query?s collection of row steps. The filter is to return all rows where 2001, COST is greater than $100.00. The 2001, COST column in this example, would not actually be visible in the table.

ROLAP roles

Like OLAP, the type of result that is returned for ROLAP queries can be defined as multi-dimensional, even if all the items are to be set to be on the COLUMN role. A role can define an axis specification or a slicer specification. This would mean that a dataItem was defined as a ROW or COLUMN as units (members) along each output axis.

If a role of Role.HIDDEN is applied, the following rules are followed

Expectations for items assigned to HIDDEN role in ROLAP

1. Hidden items should participate in any JOINS

2. Filters based on items assigned to the HIDDEN role should be honored. If ROLAP query generation stops reporting queries as invalid when they contain items assigned to the HIDDEN role, then this support should be automatic for Category data items.

ROLAP use-case 1: Filter on a YEAR data item that has been assigned the IQ HIDDEN role. End user wishes to see Catalog sales information for the years 2000 and 2001 but does not want the Time dimension shown.

(M) ? indicates a measure

Row items: Catalog

Column items: SALES (M)

Hidden items: YEAR

Filter: FilterItem whose expression is of type SimpleConditionalExpression_IN. Expression matches all YEAR values that match 2000 and 2001.

ROLAP use-case 2: Filter on a measure COST data item that has been assigned the IQ HIDDEN role. End user wishes to see information for all Catalogs where the 2001, COST exceeded $100.

(M) ? indicates a measure

Row items: Catalog

Column items: TIME, SALES (M)

Hidden items: COST (M)

Filter: Filter step applied to query?s collection of row steps. The filter is to return all rows where 2001, COST is greater than $100.00. The 2001, COST column in this example, would not actually be visible in the table.

Miscelleous OLAP features

Starting Location

This feature is only available for OLAP information maps. Getting the set of members for a dimension, hierarchy, or level is common. The .Member phrase (which is used in the IQ MDX generator) uses the dimension, hierarchy, or level to the left and a set of all member associated in that scope is presented. [COUNTRY].members could be defined as the top level of the [GEOGRAPHIC]. However, it is possible to change to starting location or level for a particular hierarchy. For example, [COUNTRY].[REGION] would return all the member for the country region level in geographic. The starting level can be used by apply setStartingLevel in the DataItem class.

EMPTY versus NONEMPTY

This feature is only available for OLAP information maps. When you see a OLAP cube, you might see a lot more empty cells than there are NULLs in the tables used to create the cube. This is due to the fact that not every consumer by have participated in every possible hierarchy defined in the cube. All numeric functions (such as aggregations or totaling) ignore empty cells. By using the EXCLUDE_EMPTY_DATA property of the Business Query, you can have the query suppress empty result slices from a query. When this property is specified, any tuples that correspond to entirely empty slices of the data within the set are removed.

Group By

Grouping, or "categorizing," results by a certain set of data items for a relational business model is done by specifying the "CATEGORY" usage for the data items to be grouped by (also called By-Groups). You need to set the data items that are to be aggregated during this categorization to have an "AGGREGATE" usage along with the specific type of aggregating function to be used.

For relational queries, it is possible to group by a data item that is not returned in the result set for a query set. You can do this by setting the "HIDDEN" role for the data item to be grouped by but not returned.

*** This package is subject to change. ***

Note:

Extension of the classes in this package is prohibited unless otherwise documented. Similarly, extension or implementation of the interfaces in this package is prohibited except as documented.