Integrity constraints in DBMS Theory - Time & Space Complexity
When using integrity constraints in a database, it is important to understand how checking these rules affects performance.
We want to know how the time to verify constraints grows as the amount of data increases.
Analyze the time complexity of the following SQL constraint check.
-- Check uniqueness of a column before insert
SELECT COUNT(*) FROM Employees WHERE EmployeeID = new.EmployeeID;
-- If count is 0, allow insert; else reject
This code checks if a new employee ID already exists to keep IDs unique.
Look at what repeats when checking the constraint.
- Primary operation: Scanning the Employees table to find matching EmployeeID.
- How many times: Once per insert operation, but the scan may check many rows depending on data size.
As the number of employees grows, the time to check uniqueness grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 checks |
| 100 | 100 checks |
| 1000 | 1000 checks |
Pattern observation: The time grows roughly in direct proportion to the number of rows.
Time Complexity: O(n)
This means the time to check the constraint grows linearly with the number of rows in the table.
[X] Wrong: "Checking a constraint always takes the same time no matter how big the table is."
[OK] Correct: The database often needs to look through many rows to verify constraints, so more data usually means more work.
Understanding how constraints affect performance helps you design databases that stay fast as they grow.
What if we added an index on EmployeeID? How would the time complexity change?
Practice
integrity constraints in a database?Solution
Step 1: Understand the role of integrity constraints
Integrity constraints are rules that keep data accurate and consistent in a database.Step 2: Match the purpose with the options
Only To ensure data accuracy and consistency mentions accuracy and consistency, which matches the purpose of integrity constraints.Final Answer:
To ensure data accuracy and consistency -> Option AQuick Check:
Integrity constraints = data accuracy and consistency [OK]
- Confusing constraints with performance features
- Thinking constraints create user interfaces
- Assuming constraints store data
NOT NULL constraint on a column named email in SQL?Solution
Step 1: Recall the syntax for NOT NULL constraint
The NOT NULL constraint is added after the data type to ensure the column cannot have empty values.Step 2: Identify the correct option
email VARCHAR(50) NOT NULL correctly usesemail VARCHAR(50) NOT NULL. Other options either allow NULL or use different constraints.Final Answer:
email VARCHAR(50) NOT NULL -> Option AQuick Check:
NOT NULL syntax = column datatype NOT NULL [OK]
- Using NULL instead of NOT NULL
- Confusing UNIQUE with NOT NULL
- Using PRIMARY KEY when only NOT NULL is needed
<pre>CREATE TABLE Students ( ID INT PRIMARY KEY, Name VARCHAR(100) NOT NULL, Age INT CHECK (Age >= 18) );
What will happen if you try to insert
(1, 'Alice', 16) into this table?Solution
Step 1: Analyze the CHECK constraint on Age
The CHECK constraint requires Age to be 18 or older.Step 2: Compare the inserted Age value
The inserted Age is 16, which violates the CHECK constraint.Final Answer:
Insertion fails due to CHECK constraint violation -> Option BQuick Check:
Age 16 violates CHECK (Age >= 18) [OK]
- Ignoring CHECK constraints and assuming insert works
- Confusing PRIMARY KEY violation with CHECK violation
- Thinking NOT NULL is violated when it is not
UNIQUE constraint on the username column. Assume the table already contains a row with username = 'john_doe'. Which of the following SQL statements will cause an error?Solution
Step 1: Understand UNIQUE constraint behavior
The UNIQUE constraint prevents duplicate values in the username column.Step 2: Identify duplicate insertion
INSERT INTO Users (username) VALUES ('john_doe'); tries to insert 'john_doe' which already exists, causing a UNIQUE violation.Final Answer:
INSERT INTO Users (username) VALUES ('john_doe'); -> Option CQuick Check:
Duplicate username violates UNIQUE constraint [OK]
- Assuming UPDATE causes error without duplicate
- Thinking inserts of new usernames cause error
- Confusing UNIQUE with PRIMARY KEY
OrderID and CustomerID. You want to ensure that each order belongs to an existing customer and that no two orders have the same OrderID. Which combination of integrity constraints should you use?Solution
Step 1: Ensure unique OrderID
Use PRIMARY KEY on OrderID to guarantee uniqueness and not null.Step 2: Ensure Order belongs to existing Customer
Use FOREIGN KEY on CustomerID referencing the Customers table to enforce valid customer links.Final Answer:
PRIMARY KEY on OrderID and FOREIGN KEY on CustomerID referencing Customers table -> Option DQuick Check:
Unique orders + valid customers = PRIMARY + FOREIGN KEY [OK]
- Using UNIQUE instead of PRIMARY KEY for OrderID
- Missing FOREIGN KEY for CustomerID
- Assuming NOT NULL alone enforces relationships
Ready to prove it?
Pass the test and this pattern moves unknown
