Configure friendly names and OLAP export settings

Expand Layers

In the navigation tree of the intended Data Warehouse (DWH) project, expand Layers.

Expand the datamart schema

Expand Datamart layer, then expand the schema containing the table you want to configure. A schema groups the project's table definitions. STAR is the schema used in the example.

Open the Tables context menu

Right-click the Tables folder under that schema.

List the tables

Click List tables in the context menu. The table list opens for the selected schema.

Open the intended table

In the list, identify the table by the Table Schema and Table Name columns. Review Table Type to confirm its role, then double-click the required row to open the table definition.

The selected DIM_CustomerCustomerDemo row is an example. Select the table whose analytical presentation you need to change.

Enter the table's friendly name

In the table definition, confirm Table Name and Table Schema. The upper area contains table settings; the Columns tab below contains settings for individual columns.

Enter the intended display label in Friendly name. A friendly name can be used instead of the technical name in the diagram and generated OLAP content. Keep the technical Table Name unchanged when your task is only to change its display label.

Naming example: Customer_Star is the friendly name entered in the capture. It is a literal display label, not a required naming pattern.

Friendly names can also pass to dependent objects through inheritance rules. If a name must follow an upstream object, retain the intended inheritance rule rather than treating the current label as independent.

Select a table category when needed

If the analytical model requires a table category, select it in OLAP Category. This setting classifies the table as a whole. Choose a category that describes what the table represents: for example, Customers for customer data or Products for product data. Do not copy Customers merely because it appears in the capture.

If no table category is required, leave the setting unassigned. If a category is already assigned, check that it still describes the table before keeping it. Column categories are configured separately in Configure the required columns.

Set table inclusion and visibility

Use the two table settings for distinct decisions:

1. Export to OLAP — Select this checkbox when the table should be included as a fact or dimension during analytical model generation. Clear it when the table should be excluded.
2. Hidden in OLAP — For a table being exported, select this checkbox when the generated fact or dimension should be hidden from normal browsing. Clear it when the object should be visible. Hiding an object is different from excluding it from generation.

Check the final checkbox states against your inclusion and visibility requirements. Selecting Export to OLAP configures inclusion; it does not itself generate or deploy a model.

Configure the required columns

Select the Columns tab. Identify each intended row by Column name and check its Data Type before changing its analytical settings. Use the horizontal scrollbar to reach settings farther to the right, keeping track of the row being edited.

Enter the column's display label in FriendlyName when report users need a different label from its technical name. This setting can be used in transformations and generated OLAP content, and can be inherited by dependent objects.

For each column, review the following settings and change those required by your analytical design:

1. OLAP Reference — Select an existing column reference when the relationship is required in the analytical model. Confirm that the reference points to the intended table and column. If a required reference does not yet exist, define it using Define OLAP table references and many-to-many cardinality before selecting it here. Leave the setting unassigned for a column that does not require an analytical relationship.
2. 2-sided — For a tabular OLAP model, select this checkbox only when the selected relationship is intended to be two-sided. Clear it when that behavior is not required. This setting is not a substitute for defining many-to-many cardinality.
3. In OLAP — Controls column transfer and visibility in the analytical model. Review it separately from the table's Export to OLAP setting. The capture shows Transfer; use that choice for a column intended for transfer, and retain an existing hidden or excluded configuration when that is the intended design.
4. Default aggregate — Select the default aggregation rule required for the column. Base the decision on what its values mean: an amount intended to be added across rows has different requirements from an identifier, date, or rate. Use the rule established for that column in the target model; do not infer it from a numeric data type alone.
5. DisplayFolder — Enter a folder name when fields need to be grouped in the analytical model. Use the same folder name for fields intended to appear together. Leave this setting empty when no folder grouping is required.
6. FormatString — Enter a display format supported by the target analytical model when values need a particular presentation, such as a date, amount, or percentage. Check the column's data type and the meaning of its stored values before entering the format. Leave this setting empty when no explicit format is required. A display format does not correct an incorrect underlying data type.
7. DataCategory — Assign a column category when the analytical model needs to interpret the field's meaning. Choose a supported category that matches the actual values, not the table's name or its OLAP Category. Leave this setting unassigned when no semantic category is required.
8. Inheritance — Rules can pass friendly names, descriptions, and display folders to dependent objects. Before relying on a local name or folder, check whether its intended behavior is to inherit only when empty, to inherit always, or not to inherit. For column-to-column friendly name and display folder inheritance, the project parameters use 0 for inherit if empty, 1 for always, and 2 for never. Their exact names are listed in Table.

Check every changed row before saving. The screenshot's column names, Transfer selections, and blank aggregation cells are examples, not defaults for all columns.

Save and check the table settings

Review the table's friendly name, category, inclusion, and visibility, then review the column settings changed in Configure the required columns. Click Save at the bottom of the table definition.

Use List tables again as described in Open the Tables context menu and reopen the same table. Compare its saved settings with the intended configuration using the checks in Expected Results.