Choose NOT NULL, UNIQUE, CHECK, primary-key, and foreign-key constraints from concrete integrity rules and verify both accepted and rejected writes.

What you will be able to do

Distinguish candidate row from required value in a realistic constraints and data integrity case.
Interpret the database evidence and boundary associated with unique identity.
Choose an appropriate action involving parent relationship without exceeding the named data scope.
Verify constraint evidence through an observable database result and reproducible handoff.

Frame Constraints and Data Integrity

Choose NOT NULL, UNIQUE, CHECK, primary-key, and foreign-key constraints from concrete integrity rules and verify both accepted and rejected writes.

An orders table requires unique order numbers, positive quantities, existing customers, and a placed_at timestamp. Imports and applications must obey the same rules.

Keep the database target, stored state, input values, expected result, and allowed change scope separate. Begin in an isolated practice database, inspect before modifying, and preserve enough evidence to repeat the decision.

Candidate row

A candidate row must satisfy every applicable table constraint before acceptance. Within constraints and data integrity, this concept answers a separate data question and retains its own observable evidence.

List the order values and the rule associated with each column. Apply that action to the named database case before broadening the query or changing more stored state.

Respect this boundary: do not evaluate one constraint while ignoring the rest. The required result is specific: accepted rows satisfy the complete order contract.

Required value

NOT NULL prevents a column from accepting a null value. Within constraints and data integrity, this concept answers a separate data question and retains its own observable evidence.

Require placed_at and the fields needed for a valid order. Apply that action to the named database case before broadening the query or changing more stored state.

Respect this boundary: do not use not null to test numeric range or uniqueness. The required result is specific: rows missing required order facts are rejected.

Unique identity

UNIQUE and primary-key constraints prevent duplicate constrained values. Within constraints and data integrity, this concept answers a separate data question and retains its own observable evidence.

Protect the public order number and designate the stable row key. Apply that action to the named database case before broadening the query or changing more stored state.

Respect this boundary: do not declare several competing primary keys. The required result is specific: duplicate order identity fails before storage.

Parent relationship

A foreign key requires a matching referenced key for non-null values. Within constraints and data integrity, this concept answers a separate data question and retains its own observable evidence.

Reference the customers primary key from orders.customer_id. Apply that action to the named database case before broadening the query or changing more stored state.

Respect this boundary: do not store an unvalidated customer label as the relationship. The required result is specific: orders cannot reference missing customer keys.

Constraint evidence

Constraint verification includes valid rows and one targeted violation per rule. Within constraints and data integrity, this concept answers a separate data question and retains its own observable evidence.

Test duplicate, missing, negative, and orphaned cases independently. Apply that action to the named database case before broadening the query or changing more stored state.

Respect this boundary: do not weaken constraints to make an invalid fixture pass. The required result is specific: each invalid write fails for the intended database rule.

Apply Constraints and Data Integrity to One Case

Use the case as a bounded database task: An orders table requires unique order numbers, positive quantities, existing customers, and a placed_at timestamp. Imports and applications must obey the same rules.

First, list the order values and the rule associated with each column. Then, require placed_at and the fields needed for a valid order. Keep both observations with the target database and expected result before choosing the next statement.

Next, protect the public order number and designate the stable row key. After that, reference the customers primary key from orders.customer_id. Finish only after you test duplicate, missing, negative, and orphaned cases independently.

Recap Before Practice and Prove

Candidate row: A candidate row must satisfy every applicable table constraint before acceptance. In the database case, list the order values and the rule associated with each column. Preserve the boundary: do not evaluate one constraint while ignoring the rest.

Required value: NOT NULL prevents a column from accepting a null value. In the database case, require placed_at and the fields needed for a valid order. Preserve the boundary: do not use not null to test numeric range or uniqueness.

Unique identity: UNIQUE and primary-key constraints prevent duplicate constrained values. In the database case, protect the public order number and designate the stable row key. Preserve the boundary: do not declare several competing primary keys.

Parent relationship: A foreign key requires a matching referenced key for non-null values. In the database case, reference the customers primary key from orders.customer_id. Preserve the boundary: do not store an unvalidated customer label as the relationship.

Constraint evidence: Constraint verification includes valid rows and one targeted violation per rule. In the database case, test duplicate, missing, negative, and orphaned cases independently. Preserve the boundary: do not weaken constraints to make an invalid fixture pass.