Unique Value Access Path
The unique value access path is used when the same replacement row must always be returned for the same source value, and each replacement row can only be returned for one source value. The access path defines the data that will be combined to produce the unique value. The source values are not contained within the translate table. Instead, a special table called the Unique Value Table (UVT) is created to store the unique source values that have been processed, along with the row number of the translate table that was used as the source of the replacement value for that source value. Translate table entries are selected randomly, but each row is selected only once.
This type of access path requires that labels be defined for each field that will be used as part of the unique value. These labels are not related to the names of the columns in the translate table or source data tables. They represent parts of the UVT table key value and can be any string value that the user desires. For example, a user could decide to use a data element name to represent a label. Additionally, the length specified for the label is the length of the value derived from the mapped source while forming the search key. This length does not necessarily represent the length of the translate table column(s), but rather a length that needs to be taken into account when forming the UVT key. Refer to Create-Unique-Value-Access-Path-Definition for details.
The UVT tables themselves are created on the File-AID Services server and within the server's workspace. The default location for the UVT folder is: C:\Program Files (x86)\Compuware\File-AID Services\MMCServer\eclipse\workspace\uvt. During processing, the table is created by a file-based database system and uses, in part, the project ID of the Data Privacy project in the table name. Since the UVT tables are file-based and stored on the File-AID Services server, the tables can use as much available disk space as the host allows. That being said, the disguise will fail if the available disk space on the host has been exhausted, or if there is not enough RAM available to store a new source value in the table prior to writing it to disk. The disguise will also fail if all of the replacement values in the translation table have been used before processing of the source has completed. If these conditions occur, the disguise failed action defined for the translate table will apply.
Unique value table access is repeatable as long as the translate table is not changed, but is not reversible. Values are unique as long as values in the translate table are unique. Long source values occur when the unique value table allows for a value to contain a specific number of positions but the source value contains a longer value. When this happens, there is no way to store the value, so the long source value option will apply to this condition. If truncate is selected, the value will be truncated and a replacement value will be returned. In this case, multiple source values could get the same replacement value and uniqueness is compromised.
A sharing level is defined for each unique value access path: Project (share within the project), Global (share across projects), or No sharing (create a new unique value table for each disguise execution). Project is the default.
When the sharing level is Project, a unique value table is created for each project that uses the access path. All rules within a project that use the same unique access path will use the same unique value table, even though they may be using different replacement fields from the translate table.
When the sharing level is Global, only one unique value table will be created and all projects that use the access path will share that unique value table. Entries will be populated into the unique value table from whatever project presents the value first. There is no tracking to identify which project created which entry in the unique value table.
When sharing level is No sharing, a unique value table will be created for each execution, but it will not be saved. All objects that are being disguised within the same execution that use the same unique access path to the same replacement table will use the same unique value table. Values will be consistent only within the execution.
To obtain consistent results between executions, you must specify a sharing level of Project or Global. Only one disguise job can update the unique value table at a time, so if the unique value table is in use and another job requests the same unique value table, the second job will wait until the first one finishes, which may cause performance issues. The second job will wait for 5 minutes and if the unique value table does not become available, the job will terminate.
At execution time, the source values that were mapped to the access path labels are used as search values into the unique value table. The replacement translate table row that corresponds with the unique value table entry is returned as the replacement row.
Key access is not supported for either the unique value table or the replacement table.
You can add additional entries to the end of the translate table after the unique value table has been created and populated if you need more unique values than were originally expected. However, once the UVT access path has been defined, the number of rows in the translation table should not be reduced. If the number of rows in the translate table is reduced, and entries have been populated into the unique value table, the disguise job will fail. In this case, the UVT access path would have to be replaced with a new one that defines the access path, and the old access path deleted. All associated rule actions would have to be updated to use the new access path.
For information on how to use a unique value access path in a rule, see Translation-Rule-Actions-Unique-Value-Access-Path. For information on how to create a unique value access path, see Create-Unique-Value-Access-Path-Definition.