Practice data modeling vocabulary: entity-relationship models, cardinality, junction tables, domain models, and bounded context schemas.
0 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.