Consider the above example - the FULL_NAME field is composed of data from other columns in the same row. After the data has been masked, the FIRST_NAME and LAST_NAME columns will have been changed to other values. For the information to be secure, clearly the FULL_NAME field must also change. However, it must change to contain values synchronized with the rest of the data in the row so that the masked data reflects the denormalized structure of the row. This type of synchronization is called row-internal synchronization and it is quite distinct from the other two types: Table-Internal and Table-To-Table synchronization.
A Row-Internal Synchronization Rule updates a field in a row with a combination of values from the same row. This means that if, after masking, the FIRST_NAME and LAST_NAME change to Albert and Wilson then (in this example) the FULL_NAME column should contain Albert Wilson.
Row-Internal Synchronization is a common requirement and the Data Masker software makes it simple to accomplish - just implement the specialized Row-Internal Synchronization rule. To configure a Row-Internal Synchronization Rule it is necessary to know how the column should be built and to be able to express that knowledge in a T-SQL statement. In the example above, the FULL_NAME field is a concatenation of the FIRST_NAME and LAST_NAME columns and a suitable build statement would be: FIRST_NAME+' '+LAST_NAME.
The build statement is formatted as a standard T-SQL update clause and it can be as complex as required. For example, the following update statement would also be valid:
/* build the columns as LASTNAME INITIAL (TITLE) */
LastName+SUBSTRING(FirstName, 1, 1)+'('+Title+')'
It is also possible to dispense entirely with any references to other columns within a row and simply call a function (either system or user defined).
CAST(GetDate() as varchar(100))
The rest of the Row-Internal Synchronization Rule configuration is simple. The target table and column is chosen and the build statement pasted into the box provided. Data Masker does the rest of the work - any columns referred to by name in the build statement will be substituted at run time with the actual data values from the columns in the row. The help file for the New Row-Internal Synchronization Rule form provides more details on the mechanics of this process.
