Data Modeling Vocabulary
Practice data modeling vocabulary: entity-relationship models, cardinality, junction tables, domain models, and bounded context schemas.
0 / 26 completed
1 / 26
A data architect says 'We start with an entity-relationship model.' What does an ER model capture?
An Entity-Relationship (ER) model is a logical data model that identifies the key entities (e.g., Customer, Order, Product), their attributes (e.g., Customer has name, email), and how they relate (e.g., Customer places Order). It is a design tool, not the implementation — the actual tables come later.
2 / 26
A model review discusses 'cardinality: one-to-many between Customer and Orders.' What does this mean?
Cardinality describes the numerical relationship between entities. One-to-many (1:N) means one record on the 'one' side relates to multiple records on the 'many' side. In practice: one Customer can have many Orders, but each Order has one Customer — implemented via a foreign key in the Orders table.
3 / 26
A schema design uses 'a junction table to resolve many-to-many.' What problem does a junction table solve?
A many-to-many relationship cannot be stored directly in relational tables. A junction table (also called a bridge or associative table) sits between the two entities, holding a foreign key to each — allowing many records on both sides. It may also carry additional attributes (e.g., enrollment_date).
4 / 26
Your architecture doc says 'The domain model maps to the database schema.' What is the relationship between a domain model and a database schema?
The domain model captures business concepts and their relationships from a business perspective. The database schema implements these concepts in relational structures. Starting from a domain model produces schemas that reflect business logic, making them easier to understand and evolve as the business changes.
5 / 26
A DDD practitioner says 'The bounded context has its own schema.' What does this mean for database design?
In DDD, each bounded context owns its data. The 'Customer' in the Orders context may only need an ID and name; the 'Customer' in the Billing context needs payment details. By giving each context its own schema, you avoid a shared, monolithic schema that becomes a source of coupling and conflict between teams.
6 / 26
PR Description:
"Implementing the new UserProfile API. This PR introduces a 'ContactInfo' entity with fields for phone number and email. We've modeled this as a separate table to avoid redundancy and improve query performance. The schema changes include adding the contact_info_id foreign key in the User table and creating the new ContactInfo table."This question assesses understanding of database normalization. The PR description correctly outlines a strategy for *normalization* by creating a new table (
ContactInfo) linked to the User entity via a foreign key. This avoids data duplication and improves query performance – a common goal in database design. Option A is too extreme, option C describes denormalization, and option D misuses terminology.7 / 26
SeniorDev writes the following comment on a code review:
"I'm seeing you've used a separate `ProductVariant` entity. While conceptually valid, are we *certain* this is necessary? Could we achieve the same result by simply using a `Product` table with an array of `VariantAttributes`? This might simplify our queries and reduce potential complexity later."This question tests understanding of trade-offs in data modeling. The correct answer highlights the importance of considering query performance and database limitations alongside design principles. The incorrect options present misconceptions – object-oriented design isn't *always* about flexibility, arrays aren't inherently bad in relational databases (though they do have limitations), DDD is about domain modelling not just entity names, and relying on a separate entity doesn't automatically guarantee efficient querying. The core issue here is recognizing that different modeling choices impact query complexity.
8 / 26
During a discussion about optimizing the `Orders` table, a developer suggests creating a separate `OrderItems` table. The data architect responds, "We need to consider the relationships between Orders and Products. What does 'referential integrity' mean in this context?"
The concept of 'referential integrity' is crucial for maintaining data consistency. It dictates that relationships between tables – particularly foreign keys – are correctly defined and enforced. This prevents situations where an order item might be linked to a non-existent product, ensuring the accuracy of your data. Options A and B misinterpret the core purpose of referential integrity, while option C focuses on a specific key constraint rather than the broader relationship management aspect.
9 / 26
Sarah, a junior developer, is discussing a new feature for an e-commerce platform with the team. She proposes creating a separate `ShippingAddress` entity to store customer shipping information. The Lead Developer responds: 'That's interesting! We're aiming for a normalized database design. What does 'denormalization' refer to in this context, and why might we *avoid* it?'.The correct answer highlights the core concept of denormalization: reducing data redundancy by combining related tables. This approach optimizes read performance by minimizing the need for complex joins during queries. The other options misinterpret denormalization, either suggesting it's purely about improving query speed (option 1), incorrectly describing a different design strategy (option 3), or using it as a vague term without its technical meaning (option 4).
10 / 26
PR Description:
"Implementing the new UserProfile API. This PR introduces a 'ContactInfo' entity with fields for phone number and email. We've modeled this as a separate table to avoid redundancy and improve query performance. The schema changes include adding the contact_info_id foreign key in the User table and creating the new ContactInfo table."This question assesses understanding of database normalization. The PR description correctly outlines a strategy for *normalization* by creating a new table (
ContactInfo) linked to the User entity via a foreign key. This avoids data duplication and improves query performance – a common goal in database design. Option A is too extreme, option C describes denormalization, and option D misuses terminology.11 / 26
SeniorDev writes the following comment on a code review:
"I'm seeing you've used a separate `ProductVariant` entity. While conceptually valid, are we *certain* this is necessary? Could we achieve the same result by simply using a `Product` table with an array of `VariantAttributes`? This might simplify our queries and reduce potential complexity later."This question tests understanding of trade-offs in data modeling. The correct answer highlights the importance of considering query performance and database limitations alongside design principles. The incorrect options present misconceptions – object-oriented design isn't *always* about flexibility, arrays aren't inherently bad in relational databases (though they do have limitations), DDD is about domain modelling not just entity names, and relying on a separate entity doesn't automatically guarantee efficient querying. The core issue here is recognizing that different modeling choices impact query complexity.
12 / 26
During a discussion about optimizing the `Orders` table, a developer suggests creating a separate `OrderItems` table. The data architect responds, "We need to consider the relationships between Orders and Products. What does 'referential integrity' mean in this context?"
The concept of 'referential integrity' is crucial for maintaining data consistency. It dictates that relationships between tables – particularly foreign keys – are correctly defined and enforced. This prevents situations where an order item might be linked to a non-existent product, ensuring the accuracy of your data. Options A and B misinterpret the core purpose of referential integrity, while option C focuses on a specific key constraint rather than the broader relationship management aspect.
13 / 26
Sarah, a junior developer, is discussing a new feature for an e-commerce platform with the team. She proposes creating a separate `ShippingAddress` entity to store customer shipping information. The Lead Developer responds: 'That's interesting! We're aiming for a normalized database design. What does 'denormalization' refer to in this context, and why might we *avoid* it?'.The correct answer highlights the core concept of denormalization: reducing data redundancy by combining related tables. This approach optimizes read performance by minimizing the need for complex joins during queries. The other options misinterpret denormalization, either suggesting it's purely about improving query speed (option 1), incorrectly describing a different design strategy (option 3), or using it as a vague term without its technical meaning (option 4).
14 / 26
PR Description:
"Implementing the new UserProfile API. This PR introduces a 'ContactInfo' entity with fields for phone number and email. We've modeled this as a separate table to avoid redundancy and improve query performance. The schema changes include adding the contact_info_id foreign key in the User table and creating the new ContactInfo table."This question assesses understanding of database normalization. The PR description correctly outlines a strategy for *normalization* by creating a new table (
ContactInfo) linked to the User entity via a foreign key. This avoids data duplication and improves query performance – a common goal in database design. Option A is too extreme, option C describes denormalization, and option D misuses terminology.15 / 26
SeniorDev writes the following comment on a code review:
"I'm seeing you've used a separate `ProductVariant` entity. While conceptually valid, are we *certain* this is necessary? Could we achieve the same result by simply using a `Product` table with an array of `VariantAttributes`? This might simplify our queries and reduce potential complexity later."This question tests understanding of trade-offs in data modeling. The correct answer highlights the importance of considering query performance and database limitations alongside design principles. The incorrect options present misconceptions – object-oriented design isn't *always* about flexibility, arrays aren't inherently bad in relational databases (though they do have limitations), DDD is about domain modelling not just entity names, and relying on a separate entity doesn't automatically guarantee efficient querying. The core issue here is recognizing that different modeling choices impact query complexity.
16 / 26
During a discussion about optimizing the `Orders` table, a developer suggests creating a separate `OrderItems` table. The data architect responds, "We need to consider the relationships between Orders and Products. What does 'referential integrity' mean in this context?"
The concept of 'referential integrity' is crucial for maintaining data consistency. It dictates that relationships between tables – particularly foreign keys – are correctly defined and enforced. This prevents situations where an order item might be linked to a non-existent product, ensuring the accuracy of your data. Options A and B misinterpret the core purpose of referential integrity, while option C focuses on a specific key constraint rather than the broader relationship management aspect.
17 / 26
Sarah, a junior developer, is discussing a new feature for an e-commerce platform with the team. She proposes creating a separate `ShippingAddress` entity to store customer shipping information. The Lead Developer responds: 'That's interesting! We're aiming for a normalized database design. What does 'denormalization' refer to in this context, and why might we *avoid* it?'.The correct answer highlights the core concept of denormalization: reducing data redundancy by combining related tables. This approach optimizes read performance by minimizing the need for complex joins during queries. The other options misinterpret denormalization, either suggesting it's purely about improving query speed (option 1), incorrectly describing a different design strategy (option 3), or using it as a vague term without its technical meaning (option 4).
18 / 26
PR Description:
"Implementing the new UserProfile API. This PR introduces a 'ContactInfo' entity with fields for phone number and email. We've modeled this as a separate table to avoid redundancy and improve query performance. The schema changes include adding the contact_info_id foreign key in the User table and creating the new ContactInfo table."This question assesses understanding of database normalization. The PR description correctly outlines a strategy for *normalization* by creating a new table (
ContactInfo) linked to the User entity via a foreign key. This avoids data duplication and improves query performance – a common goal in database design. Option A is too extreme, option C describes denormalization, and option D misuses terminology.19 / 26
SeniorDev writes the following comment on a code review:
"I'm seeing you've used a separate `ProductVariant` entity. While conceptually valid, are we *certain* this is necessary? Could we achieve the same result by simply using a `Product` table with an array of `VariantAttributes`? This might simplify our queries and reduce potential complexity later."This question tests understanding of trade-offs in data modeling. The correct answer highlights the importance of considering query performance and database limitations alongside design principles. The incorrect options present misconceptions – object-oriented design isn't *always* about flexibility, arrays aren't inherently bad in relational databases (though they do have limitations), DDD is about domain modelling not just entity names, and relying on a separate entity doesn't automatically guarantee efficient querying. The core issue here is recognizing that different modeling choices impact query complexity.
20 / 26
During a discussion about optimizing the `Orders` table, a developer suggests creating a separate `OrderItems` table. The data architect responds, "We need to consider the relationships between Orders and Products. What does 'referential integrity' mean in this context?"
The concept of 'referential integrity' is crucial for maintaining data consistency. It dictates that relationships between tables – particularly foreign keys – are correctly defined and enforced. This prevents situations where an order item might be linked to a non-existent product, ensuring the accuracy of your data. Options A and B misinterpret the core purpose of referential integrity, while option C focuses on a specific key constraint rather than the broader relationship management aspect.
21 / 26
Sarah, a junior developer, is discussing a new feature for an e-commerce platform with the team. She proposes creating a separate `ShippingAddress` entity to store customer shipping information. The Lead Developer responds: 'That's interesting! We're aiming for a normalized database design. What does 'denormalization' refer to in this context, and why might we *avoid* it?'.The correct answer highlights the core concept of denormalization: reducing data redundancy by combining related tables. This approach optimizes read performance by minimizing the need for complex joins during queries. The other options misinterpret denormalization, either suggesting it's purely about improving query speed (option 1), incorrectly describing a different design strategy (option 3), or using it as a vague term without its technical meaning (option 4).
22 / 26
During a Slack discussion about refactoring the `Customer` model, David asks: 'I'm not entirely convinced we need a separate `BillingAddress` entity. Shouldn't we just have a single `Address` field in the `Customer` table and handle different address types within the application logic? What's the key consideration here?',
The core concept here is database normalization. Creating a separate `BillingAddress` entity helps avoid data duplication – if a customer changes their billing address, you only need to update it in one place, rather than across multiple tables. Option A incorrectly suggests complexity is the primary driver; option B misrepresents the purpose of normalization. Option D highlights a fundamental principle that's often misunderstood.
23 / 26
As part of a code review for a new payment processing API, Elena writes: 'I'm seeing you've modeled the 'PaymentMethod' as a separate entity. While this seems reasonable, are we absolutely sure we won't need to frequently query across PaymentMethods and Orders? Could we improve performance by denormalizing this relationship?',
This question tests understanding of data modeling trade-offs. Denormalization – duplicating data across tables – can improve read performance when joins are frequently required. However, it introduces potential data inconsistency issues that need careful management. Elena's concern is valid and highlights the importance of considering query patterns during design.
24 / 26
"I'm reviewing this PR introducing a 'ProductCategory' entity," Mark says in his code review comment. "It seems like we could potentially represent product categories using just tags on the `Product` table itself. What is the primary reason for creating a separate entity here?"
This question assesses understanding of the benefits of entity-relationship modeling. Creating a `ProductCategory` entity allows for hierarchical categorization (e.g., 'Electronics' > 'Laptops') and simplifies reporting by grouping products based on category. Using tags directly on the product table would lead to data duplication and make it harder to manage complex relationships.
25 / 26
In a standup meeting, Alex proposes: 'Let's create a new `UserSession` entity to track user login activity'. The team lead asks, 'What's the most important reason for modeling this as its own table, rather than just storing session data within the existing `User` table?',
This scenario focuses on data modeling driven by business requirements. A `UserSession` entity enables tracking of user activity for analytics (e.g., popular pages visited) and security auditing (detecting suspicious login attempts). Storing session data within the `User` table would limit this functionality significantly.
26 / 26
"I'm seeing you've used a separate 'OrderDetails' entity," says Ben during a code review. "While it seems to adhere to the principles of normalization, are we *absolutely* sure this is necessary? Could we achieve the same result by directly linking the `Orders` and `Products` tables with a composite key? What's the critical consideration here?
This question probes understanding of relational database design. Direct linking (often using foreign keys) can simplify queries and avoid unnecessary joins – a common optimization technique. However, it introduces potential for data inconsistency if not managed correctly. The key is the balance between query simplicity and data integrity.
Frequently Asked Questions
What does the "Data Modeling Vocabulary" exercise practise?
Practice data modeling vocabulary: entity-relationship models, cardinality, junction tables, domain models, and bounded context schemas.
How many questions are in this exercise?
This exercise has 26 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 "Data Modeling 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.