Context:FIT2094_MOC · a marker that a value is absent, not a value itself · an SQL feature, not classical relational algebra · four distinct reasons
Quick Revision
🎯 Objective: a marker that a value is absent/not applicable ➔ not a value itself.
📦 Core Components: four reasons ➔ not applicable / unknown / does not exist / undefined.
Definition ➔ a value does not exist / is not applicable for a tuple — not a value.
SQL only âž” classical Relational Algebra has no NULLs (assumes complete info).
2. Four Reasons
Not applicable ➔ attribute doesn’t apply (non-sales employee’s commission; 0 would be wrong).
Unknown ➔ value exists but not yet known (new employee’s salary).
Does not exist âž” genuinely absent (no tax file number yet).
Undefined âž” explicitly undefined (average payment before any payment).
3. Not Zero / Not Empty
NULL ≠0 ➔ 0 is a value; NULL is absence.
NULL ≠” ➔ empty string is a value too.
⚙️ Core Implementation
🔹 The four reasons (worked)
EMP example
-- EMP(empno, deptno, salary, commission)-- warehouse employee: commission IS NULL (not applicable, NOT 0)-- new employee Joe: salary IS NULL (unknown)
💡 Common Mistake:NULL ≠0 ➔ a non-sales employee has no commission (NULL), not commission = 0; entity integrity bans NULL PKs but referential integrity allows NULL FKs.
When It Flips:entity integrity forbids a NULL primary key; referential integrity permits a NULL foreign key (optional participation). Comparisons/aggregates over NULLs need three-valued logic — an extension of FIT1058 two-valued logic.
📊 Exam Execution Trace
Manual Execution Trace
Classifying NULLs:
Step / State
Case
Reason
0 (Init)
—
—
1
warehouse commission
not applicable
2
new employee salary
unknown
3
no tfn
does not exist
Applied Exercise
Problem: A non-sales employee has no commission. Is commission = 0 correct?
Derivation Proof / Hand-Calculation Walkthrough: