Choose stable keys
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.
Want more background?
The idea in everyday life
Design a small fictional equipment-loan system before writing retrieval queries.
A key identifies; a label describes and may change or repeat.
Choose stable keys — guided practice
Select identifiers that distinguish records even when labels change.
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. Mark primary keys
Underline type_id, item_id, borrower_id and loan_id in the four designs.
You should see: Each table has an explicit unique identifier.
A row needs an unambiguous reference.
2. Test a repeated alias
Imagine a new borrower B3 also uses alias River.
You should see: B1 and B3 remain distinct because their IDs differ.
Human-readable labels are not guaranteed unique.
3. Test a changed label
Rename T1 from Camera to Camera kit in one Type row.
You should see: I1 and I2 still point to T1.
Stable references survive wording changes.
4. Write key rules
State every primary key is unique and present; do not recycle an ID for a different object.
You should see: An old loan cannot silently refer to a different physical item.
Identity must remain consistent over time.
What to finish
Four primary-key choices and duplicate/rename reasoning.
Watch for this
Using a person’s name or a mutable description as a guaranteed unique ID.
How can I tell I understand it?
Complete the changed case, explain your result, and pass the three application checks.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
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 checkOptional course overview video · same video as Lesson 1
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.
Source & access notes · checked 2026-09-12
Opened and inspected on 2026-09-12: Entities, keys and relationship multiplicities.
Access: Free public web page; no paid enrollment required.
Reuse: CC BY 4.0 except credited exceptions; independent tables and explanations.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.