Table of Contents

Search

  1. Preface
  2. Introduction to Test Data Management
  3. Test Data Manager
  4. Projects
  5. Policies
  6. Data Discovery
  7. Data Subset
  8. Data Masking
  9. Data Masking Techniques and Parameters
  10. Data Generation
  11. Data Generation Techniques and Parameters
  12. Working with Test Data Warehouse
  13. Plans and Workflows
  14. Monitor
  15. Reports
  16. ilmcmd
  17. tdwcmd
  18. tdwquery
  19. Data Type Reference
  20. Data Type Reference for Test Data Warehouse
  21. Glossary

Major and Minor Constraint Severity

Major and Minor Constraint Severity

When you define a foreign key constraint, configure the constraint severity as major or minor. The severity determines the scope of the data that a data subset receives based on the constraints. You can change the severity to change the final output of a subset operation. The constraint severity level does not affect the structure of an entity. You can change the severity level for a constraint after you create an entity. You can also change the severity level at run time in a subset plan. Doing this does not change the severity levels in the entity.
Major constraints are constraints that move in both directions, child to parent and parent to child. When you want the parent table to select additional child records that are related to the parent, assign a major constraint between two tables.
When you define a constraint, you define it on the child table. When you define a constraint with a major severity level, all of the children of the parent are included in the data subset. For example, you define a constraint between Customer and Leads. Customer is the parent table. You create a filter on Leads to return only high-quality leads. The subset receives the customer for a high-quality lead, but it also receives all the leads for the customer. This major constraint honors referential and transactional integrity. You can apply only such a major constraint from within an entity.
The child record selected for the subset operation pulls in related parent records from both parent tables. The parent records select all the related child records from the child table. As more records are selected in the child table, the related parent records are selected again. This is because the records selected by one parent in the child table might refer to parent records in another parent that is not a part of the subset. This process continues in a loop until there are no more related records to select.
To configure a subset operation that aims to exclude additional data, you can select the Referential Integrity Only option in a plan at run time. When you select this option, the data included remains referentially intact, but this option does not guarantee that the subset will include all child records pertaining to a parent. Therefore, the subset operation might not maintain transactional integrity.
When you change the constraint definition at run time, the relations set in the entity do not change.
Minor constraints are unidirectional constraints, from child to parent. Minor constraints do not move in the reverse direction from parent to child. When you do not want the parent table to select additional child table records that are related to the parent, assign a minor constraint between two tables.
When you define a constraint with a minor severity level, the parent row is included in the data subset, but the data subset does not receive all of the children of the parent row. From the example above, the data subset receives the high-quality leads and the customers for the high-quality leads.
If the schema has constraints that form cycles, or if the schema has objects that have more than one major parent constraint, TDM performs recursive evaluation to calculate the subset. TDM needs a staging connection to perform recursive evaluation. You must therefore create a staging connection to perform subset operations on tables with cyclic or tending to cyclic constraints. It is recommended that you use the source connection as the staging connection.