Study Sprint Builder

Example inputs

Topic and source notes to study: Intro database notes: A primary key uniquely identifies each row and cannot be null. A foreign key references a key in another table and enforces referential integrity. A one-to-many relationship can be modeled by placing a foreign key on the many side. Example: one customer can have many orders; orders.customer_id references customers.id. Normalization reduces redundant data and update anomalies. A JOIN combines rows using a related column; it does not permanently merge the tables.

What do you need to be able to do?: Short-answer test on these notes only. I need to explain keys, model customers/orders and spot common misconceptions. No SQL syntax required.

Available study sessions: Three study sessions of exactly 20 minutes each. Put the complete answer key after every practice question.

Generated example

Learning targets

• Memorization: State the definitions of primary key, foreign key, and normalization in your own words.
• Memorization: Recall the customers/orders foreign key example (`orders.customer_id` references `customers.id`).
• Application: Given a new one-to-many scenario, correctly decide which table gets the foreign key.
• Application: Explain what a JOIN does (and does not do) to the underlying tables.

Sprint schedule

Three 20-minute sessions (as supplied), total 60 minutes.

• Session 1 – Recall (20 min): Closed-notes recall of the five key facts (blurting/flashcards) before rereading. Reread notes only afterward to check gaps.
• Session 2 – Practice (20 min): Answer the "Try without looking" questions from memory; attempt the worked example variant unaided.
• Session 3 – Correction (20 min): Compare answers to the answer key, note mistakes, redo only missed items, then re-explain the FK/JOIN distinction aloud.

Worked example

*Synthetic scenario, using only supplied rules:* One store can have many products.

| Step | Reasoning |
|---|---|
| 1 | Relationship is one-to-many (one store → many products). |
| 2 | Notes say the foreign key goes on the "many" side. |
| 3 | So `products` gets a foreign key, e.g. `products.store_id`. |
| 4 | It references the key on `stores` (the notes only say "a key in another table" — not necessarily labeled primary key). |

Check: does `products.store_id` point to the "one" side? Yes → placement is correct.

Try without looking

1. 1.What must be true of a primary key's values (two properties)?
2. 2.What does a foreign key enforce?
3. 3.A library has one branch with many books. Which table gets the foreign key, and what would you name the column?
4. 4.Using the customers/orders example, write the referencing relationship in words (no SQL).
5. 5.True/False: A foreign key must always reference a column explicitly labeled "primary key" in the notes. Justify from the material.
6. 6.True/False: A JOIN permanently merges two tables into one. Justify from the material.

Answer key

1. 1.Unique per row, and cannot be null. *Mistake:* forgetting the not-null part. *Check:* reread the primary key sentence.
2. 2.Referential integrity between the referencing and referenced tables. *Mistake:* confusing it with uniqueness. *Check:* re-say the FK definition.
3. 3.`books` gets the FK (many side), e.g. `books.branch_id`. *Mistake:* placing it on `branch` (the one side). *Check:* identify which side has "many."
4. 4.One customer can have many orders; `orders.customer_id` references `customers.id`. *Mistake:* reversing direction. *Check:* "many" table holds the FK.
5. 5.False — notes only say a foreign key "references a key in another table," not specifically a primary key. *Mistake:* assuming PK rules transfer to FK targets. *Check:* reread definitions separately.
6. 6.False — a JOIN combines rows using a related column but doesn't permanently merge tables. *Mistake:* thinking JOIN alters storage. *Check:* reread the JOIN sentence.

Flag: The notes don't state whether foreign key values can be null; do not assume they follow the primary key's not-null rule.

Next review

Self-check: you pass if you can state all definitions and correctly place a foreign key in a new one-to-many example without notes.

• Suggested review: ~1 day later
• Suggested review: ~1 week later

(Suggestions only — no cadence guarantees retention.)