Skip to main content

Edit a Level

You can edit dimension levels to change their names and other properties.

Procedure​

To edit a level:

  1. In Design Center, open a model and switch to the Canvas tab.
  2. Find the dimension you want to edit, click its context menu, and select Edit. The Edit Dimension panel opens.
  3. In the Hierarchies section, find the level you want to edit, click its context menu, and select Edit. The Edit Level panel opens.
  4. Edit the level properties as needed. For descriptions, see the sections below.
  5. Click Apply.

General​

Display name​

The user-friendly caption name that users see in BI reporting and visualization tools. Consider the following specifics of the name:

  • Should be unique among other levels in the same hierarchy.
  • Can be the same as the name of a child secondary attribute.
  • Can be the same as the name of another level in a different dimension.

Unique name​

The SQL or MDX column name for this dimension attribute in the published AtScale model. The unique name is how the AtScale engine refers to this attribute internally.

This value must be unique across all repositories and subrepositories. Additionally, it should not be changed after the model is published, as changing it may break existing data sources and reports that rely on this model.

Time unit​

For levels on time dimensions only. The time unit to use for the level.

Sources​

Dataset​

The source dataset that contains the columns that this level is based on.

Key Columns​

The dataset column(s) that the level is based on. If the level has a compound key (a key of more than one column), click the plus icon to specify the other dataset columns that comprise the key.

  • If the key consists of one column, the values in that column must be unique.
  • If the key is a compound key, the columns together must provide unique values.

Note that when updating an existing level with relationships, you cannot add or remove key columns. You can still change the selected key columns of the level, but you cannot change the number of key columns. If a snowflake relationship is needed between two levels, one is automatically created and, consequently, neither level will allow adding or removing key columns.

To change the number of key columns of an existing level with relationships, you have two options:

  • Delete all of the relationships, update the key column definitions, and define new relationships that use the new key definitions.
  • Delete the level. AtScale automatically deletes the relationships. You can then recreate the level with the desired key column definitions.

For more about selecting key columns and modeling hierarchies, see Requirements for Modeling Dimensional Hierarchies.

Unique​

Specifies whether each row in the key columns contains a value that is unique within the dataset. Selecting this checkbox is equivalent to declaring the key to be a primary key. The AtScale engine uses this selection as input when joining rows from this dimension level to other datasets in the model.

  • If the Key Column values are unique for each row, select this option. The join behavior would then consider the first matching row at query runtime.
  • If the Key Column values are multi-valued, then leave unselected. The join behavior would then consider all matching rows at query runtime.

For more information about this check box and requirements for modeling hierarchies, see Requirements for Modeling Dimensional Hierarchies.

Value Column​

The column whose values are used when a user selects this level in a visualization or report. For example, an ID number may be the key, but you want users to see a product name instead. For more information about selecting name columns and modeling hierarchies, see Requirements for Modeling Dimensional Hierarchies.

Sort Column​

By default, sorts are on the column that you specify in the Value Column field. If you want to sort on a different column, select that column here. This applies to MDX queries only (i.e. queries received through the XMLA interface).

Data handling​

Exclude from System-Generated Dimension-Only Aggregates​

Excludes this level from system generated dimension-only aggregates. This is useful if the level contains a large number (millions) of distinct values that you don't want to aggregate.

Exclude from System-Generated Fact-Based Aggregates​

Excludes this level from system generated fact-based aggregates. This is useful if the level contains a large number (millions) of distinct values that you don't want to aggregate.

Contains Unique Names​

Determines whether each member of this level attribute has a unique name. Do not enable this functionality if two members have different keys but the same name.

Custom Empty Member​

Enable this option to ensure un-joinable values such as NULL that may reside in the foreign key columns of the fact dataset are included in your query results. The Custom Empty Member functionality provides the convenience of handling NULL values so data architects are not forced to fix their fact tables. For maximum compatibility with BI tools, you will have to add an empty member record to the dimension dataset. To learn more about Custom Empty Members, see Using Custom Empty Members for Levels and Attributes.

Dimensionally Modified Aggregates​

Enables/disables the creation of dimensionally modified aggregates for the level. The following calculation types are available:

  • Prev, Next, Lead, Lag
  • Parallel Period
  • Ancestor, Parent
  • Descendants, Children
  • Siblings
  • Periods To Date
  • Dates Periods To Date
  • Moving Window (aka Range Operator + Lag)

When working with a level on a time dimension, be aware of the following:

  • Periods To Date and Dates Periods To Date can only be set for levels on time dimensions.
  • You can only select calculation types when the Time unit for the level is set to Day or longer.

For more information, see Dimensionally Modified Aggregates.

Visualization​

Visualize in BI tool?​

Determines whether the level is visible in BI tools. You might want to make a level invisible if you need it for join relationships, but don't want users to be able to select it in their queries.