Practice database normalization vocabulary: 1NF through BCNF, partial dependencies, denormalization for performance, third normal form, and normalization trade-offs.
0 / 18 completed
1 / 18
A table with a repeating group — multiple phone numbers in a single column — violates which normal form?
First Normal Form (1NF) requires that every column holds atomic (indivisible) values and that there are no repeating groups. Storing multiple phone numbers in one cell, or having columns Phone1/Phone2/Phone3, both violate 1NF.
2 / 18
The schema review notes: 'This table has a ___ dependency — the city column depends on zip code, not on the full key.'
A partial dependency occurs in a table with a composite primary key when a non-key column depends on only one part of that key. This violates 2NF. The fix is to move the partially dependent column to a separate table.
3 / 18
The architect says: 'We ___ the orders table for performance — we store customer name directly instead of joining.'
Denormalization deliberately introduces redundancy (e.g., storing customer name in the orders table) to improve read performance by avoiding JOINs. It trades data consistency risk for query speed.
4 / 18
The design document states: 'The schema is in ___ normal form — no transitive dependencies remain.'
Third Normal Form (3NF) requires that every non-key attribute depends directly on the primary key and not on any other non-key attribute. Removing transitive dependencies ensures this.
5 / 18
During a design discussion the team weighs normalization ___ off: full normalization means more JOINs and slower reads.
The normalization trade-off is the tension between data integrity (higher normalization eliminates redundancy and anomalies) and query performance (more joins slow down reads). Most production schemas are partially denormalized for this reason.
6 / 18
git diff --unified=0
During a code review of a PR that adds a new `user_profile` table to the database, Sarah comments: 'This diff shows 37 unified lines. It looks like we're still using a relatively high level of normalization here. Shouldn't we be aiming for 3rd Normal Form (3NF)?' What does Sarah *most likely* mean?
Sarah is referring to the concept of Third Normal Form (3NF) in database design. In 3NF, each non-key attribute must be fully dependent on the primary key and not have any transitive dependencies – meaning no attributes depend on other non-key attributes. By suggesting a change to 3NF, she's highlighting that the current structure likely has redundant data and should be reorganized to reduce data duplication and improve data integrity.
7 / 18
git diff --unified=0
During a code review of a PR that adds a new `user_profile` table to the database, Sarah comments: 'This diff shows 37 unified lines. It looks like we're still using a relatively high level of normalization here. Shouldn't we be aiming for 3rd Normal Form (3NF)?' What does Sarah *most likely* mean?
Sarah is referring to the concept of Third Normal Form (3NF) in database design. In 3NF, each non-key attribute must be fully dependent on the primary key and not have any transitive dependencies – meaning no attributes depend on other non-key attributes. By suggesting a change to 3NF, she's highlighting that the current structure likely has redundant data and should be reorganized to reduce data duplication and improve data integrity.
8 / 18
git diff --unified=0
During a code review of a PR that adds a new `user_profile` table to the database, Sarah comments: 'This diff shows 37 unified lines. It looks like we're still using a relatively high level of normalization here. Shouldn't we be aiming for 3rd Normal Form (3NF)?' What does Sarah *most likely* mean?
Sarah is referring to the concept of Third Normal Form (3NF) in database design. In 3NF, each non-key attribute must be fully dependent on the primary key and not have any transitive dependencies – meaning no attributes depend on other non-key attributes. By suggesting a change to 3NF, she's highlighting that the current structure likely has redundant data and should be reorganized to reduce data duplication and improve data integrity.
9 / 18
git diff --unified=0
During a code review of a PR that adds a new `user_profile` table to the database, Sarah comments: 'This diff shows 37 unified lines. It looks like we're still using a relatively high level of normalization here. Shouldn't we be aiming for 3rd Normal Form (3NF)?' What does Sarah *most likely* mean?
Sarah is referring to the concept of Third Normal Form (3NF) in database design. In 3NF, each non-key attribute must be fully dependent on the primary key and not have any transitive dependencies – meaning no attributes depend on other non-key attributes. By suggesting a change to 3NF, she's highlighting that the current structure likely has redundant data and should be reorganized to reduce data duplication and improve data integrity.
10 / 18
Alex sends a Slack message to the team: 'Just finished designing the `customers` table. We're using 3NF here, but I'm worried about performance with all these joins. Any suggestions?' Considering normalization principles, what is Alex *primarily* concerned about?
Alex's message highlights a key concern related to normalization: the potential for performance degradation due to numerous JOIN operations. Normalization aims to reduce redundancy and improve data integrity, but achieving it can sometimes lead to more complex queries requiring multiple joins – this is what Alex is worried about.
11 / 18
The backend API returns the following JSON response for a user profile request:
{
"user": {
"id": 123,
"name": 'John Doe',
"email": 'john.doe@example.com'
},
"address": {
"street": '123 Main St',
"city": 'Anytown',
"zip": '91234'
}"
In the context of database normalization, what is a potential issue with this response if the system isn't properly normalized?
This JSON response demonstrates a lack of normalization. The `address` details are repeated within the `user` object. Proper normalization would involve storing address information in its own dedicated table and linking it to the user via a foreign key, eliminating redundancy and potential inconsistencies if an address needs updating.
12 / 18
You're writing a PR description for adding a new `orders` table. The schema includes columns like `order_id`, `customer_id`, `product_id`, and `quantity`. Which of the following statements best reflects a key principle related to normalization that you should emphasize in your description?
While performance can be *a* consideration, the core of normalization is about reducing redundancy. Adhering to 3NF (or higher) ensures that data dependencies are properly defined and minimizes duplication. This makes future schema changes easier and avoids inconsistencies – this is what you should highlight in your PR description.
13 / 18
"Good morning, team! I'm working on the new `user_profiles` table. We're aiming for 3NF to avoid data duplication and ensure consistency. It's proving challenging because we need to capture a lot of address information, but we're exploring ways to normalize that out into its own table. Does anyone have any suggestions or experience with similar projects?"
This scenario directly reflects the discussion around normalization. The question highlights the tension between reducing redundancy (normalization) and maintaining efficient queries (minimizing JOINs). It's a realistic challenge developers face when designing database schemas.
14 / 18
During a standup update, Mark says: 'We've normalized the `products` table to 3NF. This means we have separate tables for product categories and product attributes, linked by IDs.' Considering the goal of normalization, what is Mark primarily trying to achieve?
Mark is focusing on reducing redundancy and ensuring data integrity, which are the primary goals of normalization. While JOINs can impact performance, the core principle is to eliminate repeating groups – this avoids inconsistencies when updating or deleting related information. Options B & C relate to *performance* optimization, not the fundamental definition of normalization itself.
15 / 18
Sarah is reviewing a PR that introduces a new `orders` table with columns like `order_id`, `customer_id`, and `product_id`. The team lead comments: 'We've designed this to be 3NF. This avoids storing redundant information about customers within the order itself.' What does this comment *primarily* indicate?
This comment directly refers to the core concept of 3NF – that a table should be dependent on primary key attributes only. By separating customer information into its own `customers` table, redundancy is avoided and data integrity is improved. Option A focuses on reporting, B on JOINs, and C misinterprets the purpose.
16 / 18
During a Slack discussion about database design, David asks: 'Should we normalize the `employees` table to include department information?' His colleague responds: 'Not necessarily. We could store department names directly in the `employees` table if it's a small number of departments and doesn't cause data duplication.' Considering normalization best practices, what is the *main* reason for this suggestion?
The colleague's suggestion reflects a pragmatic approach – sometimes, for small datasets, the performance gain from JOINs isn't worth the strict adherence to normalization. However, the *primary* reason is still data integrity: storing department names repeatedly would lead to inconsistencies if departments change. Option A is about query simplification, not the core principle.
17 / 18
A code review comment reads: 'This PR introduces a new `products` table with columns like `product_id`, `name`, and `category_id`. The schema appears to be in 3NF. However, I'm concerned about potential performance issues when querying products by category.' What is the *most* relevant consideration for addressing this concern?
Adding an index on the `category_id` column is the most direct way to improve query performance when filtering products by category. This allows the database to quickly locate relevant rows without performing a full table scan. Options B & D are incorrect approaches; C isn't a solution for the identified problem.
18 / 18
You're reviewing a PR that adds a new `users` table with columns: `user_id`, `username`, `email`, and `address_id`. The schema is described as being in 3NF. A colleague asks, 'What's the benefit of separating out the address information this way?'
Separating out address information into its own `address` table (linked via `address_id`) is a key element of 3NF. This allows you to modify or add new addresses for users without needing to update the user record itself – preventing data duplication and ensuring consistency. Option A is about email uniqueness, B about updates, and C is about storage.
What does the "Normalization Vocabulary" exercise practise?
Practice database normalization vocabulary: 1NF through BCNF, partial dependencies, denormalization for performance, third normal form, and normalization trade-offs.
How many questions are in this exercise?
This exercise has 18 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Database Schema Design category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Normalization Vocabulary" part of a larger series?
Yes — it's one exercise in the Database Schema Design category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Database Schema Design category page for related exercises, or browse the main Exercises hub for other IT English topics.