Elements

An element is a single member of a Dimension - one product in a Product dimension, one month in a Time dimension, one line in a Measures dimension. Elements are what a cell address is made of: naming one element from each of a cube's dimensions identifies exactly one cell.

Element types

MODLR has three element types, and the distinction matters because only one of them holds data.

Type	Description
Numeric	The standard element type, and the objects of the dimension itself. Numeric elements hold values in a cube.
String	Holds text rather than a number. String elements are sub-objects of the dimension, and in practice are only used in a Measures dimension - a Comment or Source Reference measure alongside the numeric ones.
Parent (Consolidation)	An aggregation of other elements. Parent elements exist only inside a Hierarchy, never in the dimension's flat element list, and their value is derived from their children rather than stored.

Parent elements behave differently here

In many multidimensional databases a consolidation is part of the dimension itself. In MODLR the dimension is a flat, N-level list of elements, and hierarchies are built over that list to provide aggregation views. The same leaf element can therefore appear in several hierarchies, consolidating differently in each, without being duplicated.

Because a parent element belongs to a hierarchy rather than to the dimension, adding a consolidation never changes the dimension's underlying element list.

Creating elements

Elements aren't created on their own - they come into existence as part of a hierarchy. Whichever route you take, naming an element that doesn't yet exist creates it.

In the Dimension Editor

The usual way. The editor represents a hierarchy as tab-indented text, and saving it creates any element named there that the dimension doesn't already have. Adding a child at the end of a structure is all it takes:

310 - Gross Margin
    320 - Revenue
        321 - Retail Sales
        322 - Online Sales
        323 - Direct Orders

Because it's a text area, an indented range pasted straight from Excel becomes a hierarchy, which is what makes this practical for more than a handful of elements at a time.

Two modifiers can be appended to an element name here:

• [s] creates the element as a string element rather than the default numeric one.
• [-1] sets the consolidation weight to -1 for that placement, subtracting the element from its parent instead of adding it.

The weight belongs to the placement, not the element - the same element can carry [-1] in one hierarchy and the default 1 in another. The element's type, by contrast, is fixed once created and shared across every hierarchy containing it.

See Managing a Dimension Manually for the full editor, including aliases, duplicate detection and CSV export.

From a Process

The programmatic equivalent. hierarchy.group and hierarchy.structure create any member named in them that doesn't already exist, so an automated build only needs to describe the relationships:

hierarchy.structure("Account", "Profit and Loss", "EBITDA", "Total Revenue");
hierarchy.group("Account", "Profit and Loss", "Total Revenue", "600010");

Use hierarchy.structure when both members are parents, and hierarchy.group when attaching a dimension member as a child of a hierarchy member - the latter being the direct equivalent of adding a child at the end of a structure in the editor.

Both accept an optional sign of 1 or -1, the same weight the [-1] modifier sets by hand.

Most real dimensions use both routes - see Hybrid Dimension Builds for maintaining one hierarchy by process and another by hand against the same dimension.

Principal names and aliases

Every element has one principal name - its identifier, unique within the dimension, and the name a formula or process must use to address it. An alias is an alternative label for the same element, used for display.

This separation is what lets a dimension key on a stable source-system code while still reading well: an Account element named 600010 can carry the alias Advertising & Marketing, and reports show the alias while processes address the code.

element.principal resolves in the other direction, returning an element's principal name from one of its aliases - useful when loading data that arrives labelled with descriptions rather than codes:

element.principal("Account", "Net Profit");

A dimension can hold several alias sets; dimension.aliases returns those defined against it. Aliases are also readable from a cube formula via ALIAS, from Workviews through Set Instructions, and from Excel via AliasGet.

Referring to elements

Beyond naming an element directly, MODLR provides operators for selecting them in ranges and combinations:

• [+] Addition Operator - combine elements from two parents
• [&] Intersection Operator - keep only the elements two parents share
• [>] Range Operator - select a contiguous span of elements
• Element Operators - the full set

In Workviews, elements are selected using Set Instructions rather than listed individually, so a report's rows can follow a hierarchy that changes without the report needing to be edited.

Removing elements

element.delete removes an element from a dimension. Deleting an element also discards the cube data held against it, so this is worth treating as a destructive operation - see How to remove unused data from a cube for the safer paths when the goal is reclaiming space rather than removing the category.

Security

Access can be granted or withheld at the level of an individual element, through either of MODLR's two security layers:

• Instance Security - the preferred approach, and the more flexible of the two
• Element Access Tags - the application-level equivalent, now largely superseded

See MODLR Security for how the two relate.

Related

• About Dimensions - elements in the context of the dimension that holds them
• Designing a Dimension - deciding what should be an element in the first place
• Understanding a Cell Address - how elements combine to identify a cell