Metadata Filtering

Metadata filtering enables an Essbase database administrator to remove certain outline members from a user's view. The MaxL create filter statement, indicating the MetaRead permission, is one way to set up a metadata filter.

Metadata filtering provides an additional layer of security in addition to data filtering. With metadata filtering, an administrator can remove outline members from a user's view, providing access only to those members that are of interest to the user.

When a filter is used to apply MetaRead permission on a member,

Data for all ancestors of that member are hidden from the filter user’s view.
Data and metadata (member names) for all siblings of that member are hidden from the filter user’s view.

Example

The following report script for Sample.Basic:

//Meta02.rep

<COLUMN (Year, Product)
<CHILDREN Cola

<ROW (Market)
<ICHILDREN West
!

under normal unfiltered conditions returns

      Year 100-10 Measures Scenario
California          3,498
Oregon                159
Washington            679
Utah                  275
Nevada                (18)
  West              4,593

But with the following filter granted to an otherwise read-access user,

 create or replace filter sample.basic.meta02 
  meta_read on '"California","Oregon"'
 ;

the report script then returns:

      Year 100-10 Measures Scenario
California          3,498
Oregon                159
  West           #Missing

In summary, MetaRead permission on California and Oregon means that:

The affected user can see no data for ancestors of California and Oregon members. West data shows only #Missing (or #NoAccess, in a grid client interface).
The affected user can see no sibling metadata (or data) for siblings of California and Oregon. In other words, the user sees only the western states for which the filter gives MetaRead permission.

Overlapping Metadata Filter Definitions

You should define a MetaRead filter using multiple rows only when the affected member set in any given row (the metaread members and their ancestors) has no overlap with MetaRead members in other rows. Oracle recommends that you specify one dimension per row in filters that contain MetaRead on multiple rows. However, as long as there is no overlap between the ancestors and MetaRead members, it is still valid to specify different member sets of one dimension into multiple MetaRead rows.

For example, in Sample.Basic, the following filter definition has overlap conflicts:

Table 3-27 Sample Filter with Overlap Conflicts

Access	Member Specification
MetaRead	California
MetaRead	West

In the first row, applying MetaRead to California has the effect of allowing access to California but blocking access to its ancestors. Therefore, the MetaRead access to West is ignored; users who are assigned this filter will have no access to West.

If you wish to assign MetaRead access to West as well as California, then the appropriate method is to combine them into one row:

Table 3-28 Sample Filter with No Overlap Conflicts

Access	Member Specification
MetaRead	California,West