Point of View (POV)

The Point of View (POV) defines the multidimensional selection for a Casabase Cube query.

A POV is represented as a JSON object. Each key identifies a cube dimension, and the corresponding value defines the members to retrieve from that dimension.

For example:

{
  "MEASURES": ["Units"],
  "TIME": [{"children": "Qtr1"}],
  "YEARS": ["Curr Year"]
}

This POV requests:

• Units from MEASURES
• The direct children of Qtr1 from TIME
• Curr Year from YEARS

The same POV syntax is used by Query Builder, QUERY_CUBE, QUERY_CUBE_PIVOT_JSON, and Saved Queries.

POV Structure

The general structure is:

{
  "<DIMENSION>": [
    <selection>,
    <selection>
  ],
  "<DIMENSION>": [
    <selection>
  ]
}

Each dimension value must be a JSON array.

A selection inside that array can be:

• A member name
• An explicit member object
• A hierarchy selection operator
• A Cube Variable reference where supported

For example:

{
  "MEASURES": ["Units"],
  "TIME": ["Jan", "Feb", "Mar"],
  "YEARS": ["Curr Year"]
}

Three Important POV Rules

1. Every Dimension Value Must Be an Array

Even when selecting only one member, the dimension value must be enclosed in a JSON array.

Correct:

{
  "TIME": [
    {"member": "Qtr1"}
  ]
}

Incorrect:

{
  "TIME": {"member": "Qtr1"}
}

The second form is not valid because the dimension value is not a JSON array.

2. Each Member Is a Separate Array Element

When selecting several members explicitly, place each member in its own array element.

For lowest-level members, the member names can be supplied directly:

Correct:

{
  "TIME": ["Jan", "Feb", "Mar"]
}

Incorrect:

{
  "TIME": ["Jan,Feb,Mar"]
}

A comma inside a string does not separate members. The second example attempts to find a single member named:

Jan,Feb,Mar

rather than three individual members.

3. Omitted Dimensions Are Resolved by the Cube

A POV does not have to explicitly contain every dimension in the cube.

For example:

{
  "MEASURES": ["Units"],
  "TIME": [
    {"member": "Qtr1"}
  ],
  "YEARS": ["Curr Year"]
}

may omit dimensions such as Product, Store, Promotion, Geography, or other dimensions in the cube.

How an omitted dimension behaves depends on whether that dimension has a configured default member.

This behavior is important because it can affect both the shape and the values of the query result.

See Default Members below.

Selecting a Member

The simplest selection is a member name:

{
  "TIME": [{"member": "Qtr1"}]
}

This requests the Qtr1 member itself.

If Qtr1 is an upper-level member, Casabase Cube returns the value aggregated at that member’s position in the hierarchy.

For example:

Qtr1
├── Jan
├── Feb
└── Mar

Selecting:

{
  "TIME": [{"member": "Qtr1"}]
}

or

{
  "TIME": ["Qtr1"]
}

returns the aggregated Qtr1 value.

It does not automatically return Jan, Feb, and Mar.

Combining Selections

Multiple selection forms can be combined within the same dimension.

For example:

{
  "TIME": [
    {"member": "Qtr1"},
    {"children": "Qtr2"}
  ]
}

This requests:

Qtr1
Apr
May
Jun

Qtr1 is returned as a single aggregated member, while the children operator expands Qtr2 into its direct children.

Selections within an array are combined into the requested member set for that dimension.

Member Selection Operators

Hierarchy operators allow a POV to derive sets of members from the cube hierarchy rather than explicitly listing every member.

The supported operators are:

Operator	Returns
{"member":"X"} or "X"	X only
{"children":"X"}	Direct children of X
{"ichildren":"X"}	X and its direct children
{"descendants":"X"}	All descendants of X at any depth
{"idescendants":"X"}	X and all descendants of X
{"bottom":"X"}	Bottom-level descendants of X
{"parent":"X"}	Immediate parent of X
{"ancestors":"X"}	All ancestors of X
{"iancestors":"X"}	X and all ancestors of X
{"siblings":"X"}	Members sharing X’s parent, excluding X
{"isiblings":"X"}	Members sharing X’s parent, including X
{"root":""}	All top-level members of the dimension

Operators beginning with i are inclusive. They include the anchor member in addition to the related members.

Children

Use:

{
  "TIME": [
    {"children": "Qtr1"}
  ]
}

to return the direct children of Qtr1.

Given:

Qtr1
├── Jan
├── Feb
└── Mar

the result contains:

Jan
Feb
Mar

but not Qtr1.

Inclusive Children

Use:

{
  "TIME": [
    {"ichildren": "Qtr1"}
  ]
}

to return the anchor and its direct children:

Qtr1
Jan
Feb
Mar

This is useful when the result should contain both a subtotal and the detail immediately beneath it.

Descendants

Use:

{
  "PRODUCTS": [
    {"descendants": "Personal Electronics"}
  ]
}

to return every member beneath Personal Electronics, at any hierarchy depth.

Intermediate roll-up members are included.

Conceptually:

Personal Electronics
├── Cameras
│   ├── Digital Cameras
│   └── Camcorders
└── Accessories
    ├── Memory
    └── Batteries

A descendants selection can return:

Cameras
Digital Cameras
Camcorders
Accessories
Memory
Batteries

but does not include Personal Electronics itself.

Inclusive Descendants

Use:

{
  "PRODUCTS": [
    {"idescendants": "Personal Electronics"}
  ]
}

when the anchor should also be included.

The result can therefore contain:

Personal Electronics
Cameras
Digital Cameras
Camcorders
Accessories
Memory
Batteries

This is useful when a report should show the complete branch together with its top-level total.

Bottom-Level Members

Use:

{
  "PRODUCTS": [
    {"bottom": "Personal Electronics"}
  ]
}

to return only bottom-level members beneath the anchor.

Given:

Personal Electronics
├── Cameras
│   ├── Digital Cameras
│   └── Camcorders
└── Accessories
    ├── Memory
    └── Batteries

bottom returns:

Digital Cameras
Camcorders
Memory
Batteries

without intermediate roll-up members.

Use bottom when the query requires detail rows without subtotals mixed into the result.

Caution

leaves is not a supported POV operator. Use bottom when you need leaf-level descendants.

Parent

Use:

{
  "TIME": [
    {"parent": "Jan"}
  ]
}

to return the immediate parent of Jan.

If:

Qtr1
└── Jan

the result is:

Qtr1

The alternate spelling parents can be accepted as a synonym for the immediate parent operation, but parent is preferred because its behavior is unambiguous.

Use ancestors when the complete upward hierarchy path is required.

Ancestors

Use:

{
  "PRODUCTS": [
    {"ancestors": "Digital Cameras"}
  ]
}

to return the members above Digital Cameras in the hierarchy.

For example:

Products
└── Personal Electronics
    └── Cameras
        └── Digital Cameras

can return:

Cameras
Personal Electronics
Products

The selected member itself is not included.

Inclusive Ancestors

Use:

{
  "PRODUCTS": [
    {"iancestors": "Digital Cameras"}
  ]
}

to return the selected member together with its ancestors:

Digital Cameras
Cameras
Personal Electronics
Products

This can be useful for drill-up paths, breadcrumbs, and reports that need both the current member and its roll-up chain.

Siblings

Use:

{
  "TIME": [
    {"siblings": "Jan"}
  ]
}

to return members sharing the same parent as Jan.

Given:

Qtr1
├── Jan
├── Feb
└── Mar

the result contains:

Feb
Mar

Jan itself is excluded.

Inclusive Siblings

Use:

{
  "TIME": [
    {"isiblings": "Jan"}
  ]
}

to include the anchor:

Jan
Feb
Mar

Root Members

Use:

{
  "PRODUCTS": [
    {"root": ""}
  ]
}

to return the top-level members of the dimension.

This can be useful for dimensions that contain multiple roots.

Default Members

A cube dimension can have a configured default member.

Default members are especially important when interpreting a POV because they affect:

• Which member is used when the dimension is omitted
• Whether the dimension appears in the result
• The values returned by the query
• How a plain reference to the dimension’s top member is resolved

Default-member behavior is therefore part of query semantics, not merely a display setting.

You can inspect the configured default members for a cube with:

CALL CUBE.GET_CUBE_INFO('MY_CUBE');

The returned DEFAULT_MEMBER value identifies the configured default for each dimension.

Omitted Dimension with No Default Member

Assume the POV is:

{
  "MEASURES": ["Units"],
  "TIME": ["Qtr1"],
  "YEARS": ["Curr Year"]
}

and PROMOTIONS is omitted.

If PROMOTIONS does not have a default member, the dimension does not appear as a result column.

Conceptually:

MEASURES   TIME   YEARS       AMT
---------  -----  ----------  -----
Units      Qtr1   Curr Year   94503

The value reflects the dimension’s implied aggregate position.

Omitted Dimension with a Default Member

Now assume PROMOTIONS has:

DEFAULT_MEMBER = No Promotion

The same POV:

{
  "MEASURES": ["Units"],
  "TIME": ["Qtr1"],
  "YEARS": ["Curr Year"]
}

now resolves PROMOTIONS to:

No Promotion

and PROMOTIONS appears in the result:

MEASURES   TIME   YEARS       PROMOTIONS    AMT
---------  -----  ----------  ------------  -----
Units      Qtr1   Curr Year   No Promotion  90866

The result value has also changed.

Without the default, the value represented all promotions at the implied aggregate position.

With the default, the query is sliced specifically to No Promotion.

A default member therefore changes both result shape and query meaning.

Explicitly Selecting the Top Member

A configured default member also affects a plain reference to the dimension’s top member.

Assume:

PROMOTIONS top member = Promotions
DEFAULT_MEMBER         = No Promotion

This POV:

{
  "PROMOTIONS": ["Promotions"]
}

does not bypass the default member.

The plain top-member reference is resolved to the configured default:

PROMOTIONS
------------
No Promotion

Therefore, explicitly naming the top member is not a reliable way to retrieve the true dimension-wide total when a default member is configured.

Hierarchy Expansions Bypass Default Substitution

Hierarchy selection operators are not replaced by the default member.

For example:

{
  "PROMOTIONS": [
    {"ichildren": "Promotions"}
  ]
}

can return:

Promotions
No Promotion
Coupon
Newspaper Ad
Temporary Price Reduction

The Promotions row represents the actual top-level aggregate.

This is different from the plain selection:

{
  "PROMOTIONS": ["Promotions"]
}

which can resolve to the configured default.

When a dimension has a default member and the query requires the actual dimension-wide total, use a hierarchy expansion such as:

{
  "PROMOTIONS": [
    {"ichildren": "Promotions"}
  ]
}

rather than relying on omission or a plain reference to the top member.

Other hierarchy expansions, such as descendants and idescendants, are likewise not replaced by the configured default member.

Defaults Can Resolve to Multiple Members

A default is not necessarily limited to a single plain member.

A configured default can represent an expansion that resolves to multiple members.

As a result, an omitted dimension with a configured default can potentially produce multiple rows in the result.

Do not assume that a defaulted dimension will always contribute exactly one member.

Practical Guidance for Default Members

When working with an unfamiliar cube:

1. Use GET_CUBE_INFO to identify dimensions with configured default members.
2. Explicitly include dimensions that materially affect the meaning of the report.
3. Do not assume that omitting a dimension means “total across that dimension.”
4. Do not assume that explicitly naming the top member bypasses a default.
5. Use a hierarchy expansion when the true top-level aggregate is required.
6. Remember that a default member can change both the columns returned and the numerical result.

Default members are part of the cube’s business model and should be considered when interpreting query results.

Cube Variables

Cube Variables can be referenced within a POV so that selections can be resolved dynamically.

For example:

{
  "MEASURES": ["Units"],
  "TIME": ["Qtr1"],
  "YEARS": ["&CurrentYear"]
}

When the query executes, &CurrentYear is replaced with the current value of the Cube Variable.

For variable names containing spaces, use the bracketed form:

&[Current Year]

Cube Variables are useful for queries that need to follow changing reporting periods, scenarios, versions, or other dynamic selections.

See Cube Variables for the complete variable syntax and management behavior.

Member Names and Aliases

POV selections always use the underlying member name.

Aliases are not valid substitutes for member names in a POV.

For example, assume:

Member Name: 100-10
Alias:       Cash

Use:

{
  "ACCOUNT": ["100-10"]
}

not:

{
  "ACCOUNT": ["Cash"]
}

An alias table can be selected when executing a query so that the returned result displays aliases instead of member names.

Aliases affect query output, not POV resolution.

POV and Result Columns

Dimensions explicitly selected in the POV normally appear as dimensions in the QUERY_CUBE result.

For example:

{
  "MEASURES": ["Units"],
  "TIME": [{"children": "Qtr1"}],
  "YEARS": ["Curr Year"]
}

can produce:

MEASURES   TIME   YEARS       AMT
---------  -----  ----------  -----
Units      Jan    Curr Year   42228
Units      Feb    Curr Year   20841
Units      Mar    Curr Year   31434

An omitted dimension with no configured default does not appear as an output column.

An omitted dimension with a configured default resolves to that default and does appear in the output.

The result shape is therefore determined by both:

POV selections
       +
Cube default-member configuration
       │
       ▼
Resolved Query Dimensions
       │
       ▼
Result Columns + AMT

See Querying Overview for additional information about query results.

POV and Security

POV selections are also subject to the cube’s configured row-level security.

Row-level filtering is opt-in per user. A security-enabled dimension restricts the executing user only when that user has at least one active Casabase Cube security rule for the cube. A user with application access but no active rules is not restricted by Casabase Cube row-level security.

For example:

{
  "ENTITY": [
    {"idescendants": "Total Entity"}
  ]
}

may represent the entire Entity hierarchy structurally.

However, a user with access to only one branch receives only the permitted subset of that expansion.

Restricted members are silently omitted rather than producing an error.

The same POV can therefore return different permitted member sets for different users.

Choosing the Right Selection

A useful guide is:

Requirement	Selection
One member	"Member"
Explicit object form	{"member":"X"}
Direct children	{"children":"X"}
Anchor + direct children	{"ichildren":"X"}
All descendants	{"descendants":"X"}
Anchor + all descendants	{"idescendants":"X"}
Leaf descendants	{"bottom":"X"}
Immediate parent	{"parent":"X"}
All ancestors	{"ancestors":"X"}
Member + ancestors	{"iancestors":"X"}
Siblings excluding anchor	{"siblings":"X"}
Siblings including anchor	{"isiblings":"X"}
Top-level members	{"root":""}
Dynamic selection	Cube Variable

Choose the operator that most closely matches the grain and hierarchy relationship required by the report.

Related Topics

• Query Builder
• Querying with SQL
• Saved Queries
• Cube Variables