Data Container Keys

Data container objects can be uniquely identified via a key. This allows users to create and update data containers via imports. The data container key serves as a unique identifier and can be based on the values of selected attributes and/or the target object IDs of selected reference types. These unique identifiers are necessary in order to identify data containers when that data is imported (e.g., from an external system that cannot identify an internal STEP ID) and to ensure that duplicate data container objects are not created.

In order to ensure uniqueness, keys are defined by and cover the scope of their node, workspace, and data container type.

In addition to creating data container keys within the workbench, there are pertinent aspects of data container keys that are addressed in other topics:

  • Data Container Keys in STEPXML - Users can modify data container keys using the <KeyDefinition> tag. For more information regarding data container keys in STEPXML, refer to the Data Containers in STEPXML topic in the STEPXML Format documentation here.
  • Mapping Data Containers - Users can specify the mapping of attributes and reference types for data container keys. For more information, refer to the Data Container - Map Inbound topic (here) or the Data Container Type ID - Map Inbound topic (here), both in the Data Exchange documentation.
  • Data Containers in Web UI - Users working with data containers in Web UI are able to add values to attributes and/or reference types that make up data container keys. For more information, refer to the Data Containers in Web UI topic in the Using Web UI documentation here.

Creating a Data Container Key in the Workbench

Users can create data container keys within the workbench using the Configure Key feature, located within the Key Definition flipper parameter.

Note: Within the Data Container Type editor, the Inheritance parameter (located under the Description flipper) must be set to 'None' in order to create data container keys. If the parameter is set to 'Inherited,' the key definition cannot be configured. Additionally, if a user attempts to set the Inheritance parameter to 'Inherited' after a key definition has been configured, they will receive an error.

  1. Select the data container to which you want to apply a unique key, then open the Key Definition flipper within the Data Container Type editor.
  2. Click Configure Key.

  1. In the Configure Data Container Key dialog, select the attributes and reference types that the key will consist of from the Available Attributes/Reference Types column and click the right single arrow to place those options into the Selected Attributes/Reference Types column. Only attributes and reference types that fit the specific criteria to be part of a key definition will be available for selection. The specific criteria is detailed later in this topic.

In this example, the user has selected the attributes PM_ID and PM_Name, and the reference type DC_Reference_Type. These attributes and the reference type will be used to create the data container key.

Note: By clicking the right double arrow, all options in the Available Attributes/Reference Types column will be moved to the Selected Attributes/Reference Types column. By clicking the left double arrow, all options in the Selected Attributes/Reference Types column will be moved back to the Available Attributes/Reference Types column.

Attributes and reference types must meet specific criteria to be used as data container keys.

Attributes cannot be:

  • inherited
  • dimension-dependent
  • calculated
  • multi-valued

Reference types cannot be:

  • inherited
  • dimension-dependent
  • multi-valued

Additionally, attributes and reference types must be valid for the selected data container.

  1. Once the desired attributes and/or reference types are selected, click OK to close the dialog.

The selected data container keys are now visible in the Key Definition parameter within the workbench.

Note: Only users with the 'Edit Data Containers' privilege can make edits to the attributes /reference types after they have been assigned to data containers. It is recommended that only select admin users have this privilege added to their user profile and that this privilege be used sparingly to avoid creating duplicate keys. For more information regarding privileges, refer to the User Actions and Error Descriptions topic in the System Setup documentation here.

Note: Users can edit the target of a reference type that has been used as part of the data container key by right-clicking within the data container cell that holds the reference type and selecting 'Edit.' This will open up the node picker where another target for the reference type can be selected.

Using Lists of Values (LOV) in Data Container Keys

Lists of Values (LOV) can be used as part of a data container key. When the user creates a data container key using the LOV as part of the key, the STEP system uses the Value ID of the LOV's values rather than the values themselves to identify the key.

This means that the data container can contain, for example, two instances of a valid attribute ('EmailType') using the same LOV value ('Primary') because they have different value IDs ('001' and '003').

If an attribute with a 'List of Values' validation base type is used as a data container key definition, the LOV must have 'Yes' selected as the 'Use Ids on values' setting if the LOV is language-dependent.

Check Duplicate Keys

Users are able to check duplicate keys on the same data container type using the Check Duplicate Keys feature. Duplicate keys, which can occur when a user selects an attribute or reference type to be used as a key definition that already has duplicate values, undermine the overall value of applying uniquely identifiable keys for data containers.

For example, in the image below, there are two data containers within the DCMap data container type that include the value 'Yellow' for the attribute 'Colors.'

If the user creates a data container key using the attribute 'Colors' as the key definition to be part of the data container key after these data containers have already been created, this will result in duplicate keys.

To check for duplicate keys on a data container type:

  1. Right-click the data container type and select Check Duplicate Key.

  1. Click 'Go to process' to identify any duplicate keys (and if necessary, which data containers they are in), or click 'Close' to shut dialog.

If there are no duplicate keys, the execution report message will state that no duplicate keys are found.

If there are duplicate keys, the execution report message will include the name and link of the collection that is created to store the objects that contain the data containers with duplicate keys. In this example, the name of the relevant collection is Duplicate Check - DCMap.

Removing Duplicate Keys in Collections

Once objects that contain data containers with duplicate keys are placed into a collection, the data containers that are attached to those objects can be modified to remove the duplicate key values.

  1. In Tree, expand the Collections node, locate the collection which houses the objects holding the data containers with duplicate key values, and click on the plus sign next to the selected collection.

  1. Select the product that contains the data container with duplicate keys.

  1. With the product selected, click the Data Containers tab. In this example are two duplicate values for the attribute 'Colors.'

  1. Change one of the 'Colors' attribute values to a different value.

Note: Only users with the 'Edit Data Containers' privilege can make edits to data container keys after they have been assigned to data containers.

  1. Run the Check Duplicate Keys on the selected data container type (DCMap) again.

The execution report returns stating that there are no duplicate keys found.

For more information regarding collections, refer to the Collections topic of the Object Maintenance in Tree section of the Getting Started documentation here.