Dimension Naming and Assignment

Member Naming Rules

Name Requirements

• Names must be unique within a dimension type — not just within a single dimension. There can be only one account named GrossIncome across all account dimensions.
• Names have a 500-character limit.
• Underscores are recommended in place of spaces and periods. Square brackets are not needed for names with underscores.
• Spaces are allowed but not recommended.
• If a member name includes a space or period, square brackets must be used when the member is queried in a POV string.

1E#[Quebec.City]      — Square brackets required (name contains a period)
2A#Revenue_Total      — No brackets needed (underscore)
3U1#[Sales Dept]      — Square brackets required (name contains a space)

Restricted Characters

Reserved Words

Assigning Dimensions to Cubes

Key Rules

1. Entity and Scenario dimensions are assigned only at the (Default) level. They are shared across all Scenario Types and cannot vary.
2. Account, Flow, and UD1–UD8 dimensions can vary by Scenario Type. Each Scenario Type can point to a different dimension instance.
3. When a new cube is created, all dimension types default to RootXXXDim at the (Default) level. At the Scenario Type level, all non-Entity/Scenario dimensions default to (UseDefault).

Recommended Approach

• Assign Entity and Scenario at the (Default) level — these are shared across all Scenario Types
• Leave all other dimensions at RootXXXDim at the (Default) level
• Assign specific dimensions at each active Scenario Type — even if the same dimension is used across multiple types, explicit assignment prevents cascading changes
• Assign RootXXXDim for unused UD types at the Scenario Type level (e.g., RootUD4Dim if UD4 is not needed)

Dimension Levels on the Cube

• The Actual Scenario Type might use SummaryAccounts (fewer members, faster processing)
• The Budget Scenario Type might use DetailAccounts (more members, including driver accounts for planning)
• Both dimensions share common parent members through inheritance, ensuring consolidated results align

• The Corporate parent cube might use SummaryAccounts
• Each business unit cube might use DetailAccounts with its own set of detail members
• During consolidation, child cube detail rolls up to the parent cube's summary level

Best Practices for Initial Setup

1. Plan dimension types before creating cubes. Map out which dimension types each Scenario Type will need and what level of detail is required. Changes to cube dimensions after data has been loaded are costly.
2. Assign RootXXXDim explicitly for unused dimension types per Scenario Type. Never leave dimensions at (UseDefault) in a production application.
3. Use underscores from the start. Adopting underscore-based naming (Revenue_Total instead of Revenue Total) avoids the need for square brackets in POV strings and prevents parsing issues.
4. Keep names short. Member names appear in POV strings, Cube Views, Transformation Rules, and Business Rules. Long names make these harder to read and maintain.
5. Document naming conventions. Establish a naming standard (e.g., prefix patterns, abbreviation rules) and communicate it to the team before members are created.
6. Test Root-to-specific upgrades in dev. Before activating a new dimension on a Scenario Type in production, test the upgrade in a development environment. Verify that existing data is not affected and that calculations produce expected results.
7. Validate constraints before loading data. Configure VaryByCubeType constraints on Account, Flow, and UD members (see Account Member Properties and UD Member Properties) before the first data load. Adding constraints after data exists can orphan records at invalid intersections.

Related Content

• Dimension Library and Inheritance — Dimension creation, inheritance, stub dimensions, and the Dimension Library
• Account Member Properties — Common properties, AccountType, FormulaType, aggregation, intercompany, constraints, and code examples
• Flow Member Properties — SwitchSign, SwitchType, FlowProcessingType, and flow hierarchy design
• UD Member Properties — UD defaults, attribute members, RelatedDimensionType, and constraints
• Configuring Cubes — Cube properties, types, algorithms, FX rates, data access, and integration
• Scenario Types and Cube Dimensions — Scenario Type setup, dimension assignment, and horizontal extensibility
• Entity Dimension Setup — Entity properties, relationships, intercompany, currencies, and adjustments
• Extensibility and Linked Cubes — Vertical extensibility, linked cube setup, and cube references
• The OneStream Data Model — Conceptual overview of cubes, dimensions, extensibility, and Data Units