Relation Properties

Context: FIT2094_MOC Β· the set-derived rules every relation obeys Β· no duplicates, unordered, atomic Β· what separates a relation from a table

Quick Revision

  • 🎯 Objective: a relation body is a set of tuples βž” four properties follow.
  • πŸ“¦ Core Components: no duplicate tuples βž” tuples unordered βž” attributes unordered βž” atomic values.
  • ⚑ Key Constraint: atomic values = First Normal Form; access is always by content, never by position.

πŸ“ Core

1. The Four Properties

  • No duplicate tuples βž” a set has no repeats.
  • Tuples unordered βž” no β€œfirst”/β€œthird” tuple; access by content.
  • Attributes unordered βž” access by name, not column position.
  • Atomic values βž” one indivisible value per attribute per tuple.

2. Atomicity = 1NF

  • Breaks atomicity βž” dependants = {Ali|12, Sara|9} in one cell (repeating values).
  • 1NF fix βž” move to a separate relation, not one attribute.

3. Relation vs Table

  • Table βž” may have duplicate/ordered rows, composite cells.
  • Relation βž” forbids duplicates, unordered, atomic β€” logical structure with integrity.

βš–οΈ Core Decision Matrix

PropertyFromConsequence
no duplicatesseta super key always exists
tuples unorderedsetaccess by content
attributes unorderedsetaccess by name
atomic values1NF ruledependencies/joins well-defined

When It Flips: unordered tuples force declarative Relational Algebra/SQL querying by value; tuple uniqueness guarantees the full attribute set is a super key. SQL tables relax some rules (permit duplicate rows unless constrained).

πŸ“Š Exam Execution Trace

Manual Execution Trace

Checking a candidate relation:

Step / StateCheckVerdict
0 (Init)β€”β€”
1duplicate tuple?forbidden
2access by row number?invalid
3dependants={Ali,Sara}breaks 1NF

⚠️ Common Mistakes

  • πŸ’‘ Never name a tuple by position βž” tuples are unordered, so access is always by attribute value; a multivalued cell violates atomicity (1NF).

🧠 Active Recall