Relation (Database)

Context: FIT2094_MOC Β· the central object of the Relational Model Β· heading (schema) + body (tuples) Β· sized by degree and cardinality

Quick Revision

  • 🎯 Objective: a structured set of data βž” heading (schema) + body (tuples).
  • πŸ“¦ Core Components: heading βž” body .
  • ⚑ Key Constraint: degree ( attributes, fixed) vs cardinality ( tuples, varies).

πŸ“ Core

1. Two Parts

  • Heading (schema) βž” β€” name + attributes, each from a domain.
  • Body (instance) βž” β€” the current set of tuples, changing over time.

2. Tuple, Degree, Cardinality

  • Tuple βž” ordered list .
  • Degree βž” = number of attributes (heading property).
  • Cardinality βž” = number of tuples (body property, fluctuates).

3. Writing a Relation

  • Singular name βž” it denotes a set.
  • PK underlined βž” .

Key identities:

βš–οΈ Core Decision Matrix

TermMeaningBelongs to
headingschema structure
bodytuples data
degree# attributes heading
cardinality# tuples body

When It Flips: because the body is a set, no duplicate tuples and tuples/attributes are unordered (Relation Properties). An -degree relation is a subset of the Cartesian Product of its attribute domains β€” the n-ary Relation.

πŸ“Š Exam Execution Trace

Manual Execution Trace

CUSTOMER with 3 rows:

Step / StateQuantityValue
0 (Init)β€”β€”
1degree4 (attributes)
2cardinality3 (tuples)
3PKcustno (underlined)

⚠️ Common Mistakes

  • πŸ’‘ Degree fixed, cardinality varies βž” degree is a design-time schema property; cardinality is run-time data that changes as rows are inserted/deleted.

🧠 Active Recall