This is a privileged operation.
Aliasing
In some business cases, it may be common to share exactly the same dimensional structure and data, but under more than one name. Rather than define, load, and, maintain two or more copies of the same information, an alias creates additional, logical dimensions that share the structure and data of the original, or source, dimension. A dimension and its alias may seem to be exact copies of each other, but any change in one will be mirrored immediately in the other. Since the underlying data is shared among all related aliases, there is no chance of introducing errors due to one dimension being out of synchronization with the others.
One example from the airline industry: flights take off from and land at the same general
set of airports (location
) but it takes a pair of aiports (origin
and destination
) to properly communicate the starting and ending point for a flight,
respectively. Using an alias in this case will eliminate redundancy while ensuring that
it is always possible to make a round-trip itinerary between any two airports in the
airline's network.
Internationalization Support
Dimensions support international users by providing human-readable, descriptive
labels separate from the external name and system-generated
id values. Labels are distinguished by an associated locale,
represented by an IETF BCP-47 tag,
which combines a base language (e.g. en,
es, fr, etc.)
with an optional region (e.g. US,
MX, DE, etc.).
Every dimension requires a default
locale, as a fallback when a user or request does not indicate any preference, or
when the user's preferred locale has no label data.
When creating an alias of another, existing dimension, the locale information is
inherited from that dimension. Otherwise, the default locale must be specified as a part
of this operation when defining a brand new, non-aliased dimension.
It is recommended that a dimension's default locale be set to a common base language
(e.g. en for English) and not a region-specific locale, so that the
default locale applies to the broadest potential user base.
In addition to the default locale, each non-alias dimension may declare full support for other languages or language-region locales. Again, alias dimensions will inherit the settings from the source (aliased) dimension. New, standalone dimensions must set the Dimension.locales array so that it includes all the desired locales. Language-aware features such as label text search will build indexes only for those configured languages/locales. In most cases, supporting one or more base languages is sufficient; it is possible, however, to add support for regional locales where desired or necessary. For instance, supporting the base language en is generally adequate for English-speaking users from the United States (en-US) and from Great Britain (en-GB) even though the two regions prefer different spellings for some words. In this case, the language-aware index knows how to normalize British and American English and support both sets of users from the same index. As long as the base language (en) is configured as one of the dimension's locales, it is possible to store separate label text for the en-US and/or en-GB regional locales when actually necessary, on an item-by-item basis, even though the regional variants were not explicitly configured. (Note: a label for the configured, base language should always be defined.) However, if two regional variants are drastically different in spelling or meaning then it may be justified to configure support for one (or both) variant(s) in addition to the base language — but this will incur additional costs for storing and maintaining the extra index data. Declaring support for additional languages or language-region variants is only useful when appropriate label text exists and can be constistently loaded for those locales.
The labels for the dimension itself can be optionally set when creating a new dimension or alias by populating the Dimension.labels field with labels for zero or more unique languages/locales. Configured locales that do not have a provided label will generally fall back to using the item's configured name; when this occurs, search results may be suboptimal for those affected items and/or locales. Labels for locales whose base languages are not configured in the Dimension.locales field may be ignored. When assigning labels to an new alias, the configured locales are those defined by the source dimension.