Configure table names, columns, primary keys, and Identity

Open the DWH toolbar tab

In the intended Data Warehouse (DWH) project, click the DWH toolbar tab to display the table and schema commands.

Open the Tables list

Click Tables in the List group on the DWH toolbar. The table list opens.

Identify and open the required object

In the list, compare Table Schema, Table Name, and Table Type with your intended object. These columns identify the schema, technical name, and physical or logical role. For a persisted table, Persisting of Table identifies the table from which it is persisted.

Double-click the required row to open Edit Table. If you intend to configure a physical primary key or Identity column, select the physical table at this point. A similarly named view is a separate definition.

Configure technical and friendly names

At the top of Edit Table, confirm Table Name, Table Schema, and Table Type before editing. The Columns tab below contains the column definitions; the primary-key settings are beside the table details.

If a technical rename is required, review the affected references and then enter the new identifier in Table Name. Otherwise, retain the existing technical name. For a readable display label, enter the required text in Friendly name. This label can be used in diagrams and generated analytical models and can be inherited by dependent objects. It is distinct from the technical name.

If the table needs explanatory metadata, enter it in Description. Inherit FriendlyName and Inherit Description determine how the table receives those values through inheritance. The pictured (default) selection uses the corresponding project parameter; retain the existing rules unless changing inheritance is part of your task.

Screenshot example: this capture shows the DIM_Calendar view, although the preceding list highlights DIM_Calendar_T. It illustrates the naming fields only. Continue editing your chosen object.

Configure the column definitions

Select the Columns tab and locate each column that requires a change. Review dependencies before changing a technical column name or type; Inspect column dependencies describes that check. Edit the relevant cells using the following meanings:

1. Column name / Data Type — The technical column identifier and value type. Enter a new Column name only when a rename is intended. Select the Data Type required for the values the column must store.
2. MaxLength / NumPrec / NumScale — Maximum character length, numeric precision, and numeric scale. Precision is the total number of digits; scale is the number of digits after the decimal point. Enter the values applicable to the chosen data type and required data range.
3. Nullable — Select this checkbox if the column may store NULL, meaning a missing value. Clear it when the column must contain a value. Check the intended data constraints before changing it; a pictured checkbox state is not a recommendation for your column.
4. PKOrdinalPos — The column’s ordered position in the primary key. For columns in the intended key, enter 1, 2, and so on in key order, without duplicate positions. Leave it blank for a column outside the key. A key position in view metadata does not establish a physical primary-key constraint.

If a column also needs a display label, enter it in FriendlyName in the grid. This column label can be used in transformations and generated analytical models and can be inherited by dependent columns. The table’s Friendly name and the grid’s FriendlyName are separate settings.

If required by the column design, enter its default value or expression in Default and explanatory metadata in Description. A default supplies a value when an insert does not supply one; it does not replace existing data. Use the grid’s horizontal scroll bar to reach columns that are outside the visible area.

Configure the physical primary key

For a physical table whose key needs to change, confirm Table Type again and configure the settings below. For a view, or when no physical key change is required, keep the existing settings and continue to Configure the Identity column when required.

A primary key identifies each row through one column or a combination of columns. Its values must be unique and non-NULL. Confirm the key columns and their PKOrdinalPos values from Configure the column definitions against that design.

1. Has primary key — Select this checkbox when the physical table requires a primary-key constraint. Clear it only when removing that constraint is part of the intended change.
2. PK clustered — When the table has a primary key, select this checkbox for a clustered primary-key constraint, or clear it for a nonclustered constraint. A clustered index determines the table’s row storage order; a nonclustered index is separate from the table’s data. Follow the planned indexing design, including any existing clustered index, rather than copying the screenshot.
3. Primary key name — Enter the constraint name required by the project’s naming convention. PK_DWH_DIM_Calendar_T is the pictured example, not a required value or a demonstrated naming template.

If primary-key inheritance affects this table, review Don't inherit PK: selecting it prevents primary-key inheritance. Keep its existing state unless the intended change requires a different inheritance behavior.

Screenshot example: this capture shows the persisted table, whose Persist of table is DWH.DIM_Calendar. It also shows a selected Nullable checkbox alongside a key position. The capture illustrates the editor; it does not demonstrate a valid database constraint. Check your physical key’s non-NULL requirements.

Configure the Identity column when required

If the physical table needs an Identity addition or change, use the Identity column area below the Columns grid. Identity defines a column whose numeric values are generated by the database. Its value-generation behavior is separate from primary-key membership.

If no Identity change is required, keep the existing settings and continue to Review and save the definition. Do not add one merely because the editor displays this area.

1. Name — Enter the technical name of the Identity column required by the design.
2. Type — Select the data type specified for the Identity values.
3. Seed — Enter the starting value for the Identity sequence.
4. Increment — Enter the amount by which successive generated values advance. For example, a seed of 1 and an increment of 1 specify a sequence that starts at 1 and advances by 1; these are not mandatory settings.
5. PK pos — If the Identity column belongs to the primary key, enter its position in that key. Coordinate this with the other columns’ PKOrdinalPos values so each key column has its intended position. Leave PK pos blank when the Identity column is outside the key.

Review and save the definition

Before saving, confirm the following:

4.8.1. The schema, technical name, and type identify the intended object, and the table and column friendly names match the required labels.

4.8.2. The column names, data types, length or numeric settings, nullability, defaults, and descriptions match the intended changes.

4.8.3. For a physical key, the key columns, their positions, constraint name, and clustering choice agree. Include the Identity column’s PK pos in this check when it is part of the key.

4.8.4. Any Identity name, type, seed, and increment match the design, and inheritance settings still reflect the required behavior.

Click Save at the bottom of Edit Table. Then perform the checks in Expected Results.