Unnormalised Form (UNF)

Context: FIT2094_MOC · the starting point of Normalisation · a form mapped directly to a relation · repeating groups in brackets, no PK

Quick Revision

  • 🎯 Objective: map a client form directly to a relation before Normalisation ➔ raw starting point.
  • 📦 Core Components: subject name ➔ all attributes ➔ repeating group in brackets.
  • ⚡ Key Constraint: no PK yet; a UNF is not a valid relation; don’t flatten.

📝 Core

1. The UNF

  • Definition ➔ the relation mapped directly from a form, before normalisation.
  • Single named ➔ name by subject, not pluralised.
  • No PK yet ➔ and repeating groups in brackets.

2. Building It

  • Name by subject ➔ what the form represents.
  • List all attributes ➔ faithfully.
  • Bracket the repeating group ➔ attributes multivalued for one subject instance.

3. Rules

  • Not a valid relation ➔ has a repeating group / non-atomic structure.
  • No PK, no flattening ➔ don’t indicate a PK; don’t expand into tabular rows.
  • No repeating group ➔ maps to a single relation through to 3NF.

When It Flips: an accurate UNF ensures the business rules survive into the normalised schema; errors here propagate. Multivalued attributes are the repeating groups (Attribute (Conceptual Modelling)); the bracketed group is what 1NF splits out.

📊 Exam Execution Trace

Manual Execution Trace

Building the UNF:

Step / StateActionResult
0 (Init)
1name by subjectPART
2list attributespart_no, …, part_sell
3bracket repeating(vendor_no, …, restock_payment)

⚠️ Common Mistakes

  • 💡 No PK, no flattening at UNF ➔ don’t indicate a primary key and don’t expand the repeating data into rows; brackets capture the repeating group 1NF will remove.

🧠 Active Recall