Databases may store sensitive information. Some users may be allowed access to sensitive information while other users may not be allowed access to sensitive data. An organization may have both production databases and databases that are used for testing and development. Testing and development systems may be required (e.g., by law, by policy) to not store any sensitive information. Conventionally, production database data may have been masked to prevent unauthorized or undesired presentation of sensitive data. Similarly, testing and development systems may interact with masked data. However, testing and developing systems may require access to live data and/or data that conforms with certain requirements to improve the likelihood that the thing being tested and/or developed will integrate seamlessly with a production database. For example, to validate a certain type of credit card that has a sixteen digit identifier, a subset of the sixteen available digits may need to be “live” or unmasked to accurately test interactions between a test system and a credit card verification application. Thus, conventional masking may frustrate some testing and development operations.
Databases are generally organized into sets of tables. Some tables may refer to other tables using keys. Conventional masking may produce issues when a key, (e.g., primary key, foreign key) is masked. For example, masking live data with substitute data may compromise or destroy links between tables. By way of illustration, a value for an employee identifier may be a primary key in a first table and a foreign key in another table(s). If the real value for the employee identifier is changed during a masking process, then the referential integrity of the table(s) that relies on the value as a key may be destroyed. Additionally, masking data to prevent unauthorized or undesired display may be expensive in terms of processor cycles and/or clock time.