Relational Model

Context: FIT2094_MOC · Codd’s (1970) model representing data as mathematical relations · the basis of modern RDBMSs · the logical model a conceptual design maps to

Quick Revision

  • 🎯 Objective: represent data as mathematical relations (Codd 1970) ➔ access by content, not navigation.
  • 📦 Core Components: relationdomainRelational Algebra.
  • ⚡ Key Constraint: a relation is an abstract set, not a table; classical model assumes complete info (no NULLs).

📝 Core

1. The Model

  • Definition ➔ Codd (1970): data as mathematical relations (visualised as tables).
  • Superseded ➔ hierarchical (tree) and network (multi-parent), both navigational (pointer-following).
  • Relational access ➔ by content, not navigation.

2. Core Elements

  • Relation = abstract set ➔ the table is only a visualisation; drives the Relation Properties.
  • Domain ➔ valid atomic values per attribute (type/format/range).

3. Why It Won

  • Rigorous ➔ built on set theory.
  • Declarative ➔ non-navigational access by value.
  • ClosureRelational Algebra results are relations, so queries compose.

⚖️ Core Decision Matrix

ModelAccessStructure
hierarchicalnavigationaltree (one parent)
networknavigationalgraph (multi-parent)
relationalby contentset of relations
logical vs physicalportablevendor storage differs

When It Flips: the logical relation is independent of the physical binary storage — the separation that makes relational designs portable across vendors. A relation is the FIT1058 n-ary Relation; the ER design becomes relations in the logical model.

📊 Exam Execution Trace

Manual Execution Trace

Classifying access:

Step / StateModelAccess
0 (Init)
1hierarchicalnavigate pointers
2networknavigate multi-parent
3relationalcondition on values

⚠️ Common Mistakes

  • 💡 Relation ≠ table ➔ a relation is a set of tuples (no duplicates, unordered, atomic); a table is a display that may have duplicate/ordered rows.

🧠 Active Recall