The Life Starter
0 of 6 complete0%
Course Library · Lesson 4 of 6
Digital · Guided lesson

Remove repeated facts

About 24 minutes · 6 reading + 18 practice and checks
Time includes reading, practice, and questions. Extra videos or further study are optional.
See this course’s project requirements

A four-table equipment-loan schema with stable keys, relationship definitions, integrity rules and checked edge cases.

Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.

What to include

  • Four entity definitions and base row counts.
  • Stable primary keys and foreign keys.
  • Relationship sketch and trace.
  • Dependency/redundancy example.
  • Integrity rules, three edge cases and limits.

Review and revise

Use these criteria to check your work and choose what to improve.

  • Objects and events remain distinct.
  • Keys reconstruct every required relationship.
  • Facts are stored with their proper owner.
  • Constraints and case decisions match the stated policy.
Open the full course project
Want more background?
Before you begin

The idea in everyday life

Design a small fictional equipment-loan system before writing retrieval queries.

The idea

Store a fact once with the key that determines it; reference that key elsewhere.

Follow along

Remove repeated facts — guided practice

Use dependencies to prevent inconsistent updates.

Work in design.md or on paper; no database installation is required. Fictional equipment library: types T1=Camera, replacement units 200; T2=Tripod, replacement units 40. Items I1 and I2 have type T1; I3 has type T2. Borrowers B1=River and B2=Sky are aliases. Loans: L1, I1, B1, returned=1; L2, I1, B2, returned=0; L3, I3, B1, returned=0. Rule: returned is 0 or 1; each item may have at most one active (returned=0) loan. Keep the base rows available throughout all six lessons.

  1. 1. Identify a dependency

    Write type_id determines label and replacement_units.

    You should see: T1 always resolves to the same current type facts.

    This says which identity controls those values.

  2. 2. Show an anomaly

    In a flat loan list, change Camera to Camera kit only in L1’s repeated fields.

    You should see: L1 and L2 now disagree about T1.

    A repeated fact can be updated inconsistently.

  3. 3. Decompose

    Remove label and replacement_units from Loan; retain item_id. Keep those facts in Type.

    You should see: Both loan paths now reach the same T1 row.

    Separating entities makes one update sufficient.

  4. 4. Test a new type

    Add T3=Microphone, replacement units 90, without inventing an item or loan.

    You should see: A new type can exist before any borrowing event.

    The model should not require fake events to store independent facts.

Now change one thing

A type label is copied into 12 flat loan rows. In the normalized Type table, how many rows need changing to rename that one type?

Your work

What to finish

A before/after redundancy example and dependency statement.

Common mistake

Watch for this

Removing repeated values without preserving the keys needed to reconstruct relationships.

How can I tell I understand it?

Complete the changed case, explain your result, and pass the three application checks.

Try 3 questions

Quick knowledge check

Answer all 3 questions. Get at least 2 right and the lesson completes automatically.

Not yet passed

You’ll get an explanation for each answer. Signed in? Your results save to your account.

1A customer address is copied into 20 orders and only 19 copies are updated. What problem appears?
2A product category can exist before any product is sold. Which design supports that?
3Order ID determines order date, while product ID determines product name. Where belongs product name?
0 of 3 answeredApply the lesson to a short question, then review the explanation.
4
Finish this lesson

Pass the check. We’ll save the progress.

Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.

Go to the knowledge check
Optional course overview video · same video as Lesson 1
freeCodeCamp.orgDatabase Design Course - Learn how to design and plan a database for beginnersYouTube
Optional course overview

Database Design Course - Learn how to design and plan a database for beginners

From freeCodeCamp.org. Watch here or open it on YouTube .

Optional course overview. Follow the written steps below at your own pace.
Tools, templates, and lesson sources

Tools and templates

Tools open in a new tab so you can keep your place here.

Sources and further reading

Explore the references behind this lesson.

BCcampus: Functional Dependencies
Source & access notes · checked 2026-09-12

Opened and inspected on 2026-09-12: Determinants and dependencies.

Access: Free public web page; no paid enrollment required.

Reuse: CC BY 4.0 except noted material; independent examples.

BCcampus: Normalization
Source & access notes · checked 2026-09-12

Opened and inspected on 2026-09-12: Redundancy and decomposition.

Access: Free public web page; no paid enrollment required.

Reuse: CC BY 4.0 except noted material; independent examples.

Report a problem with this lesson

Tell us what went wrong. Please leave out personal information and private project contents.

No sign-in needed.