Database design: entities, relationships & user stories

Designing a database well starts with modelling the entities (the distinct types of things being tracked, like a movie, a user or a review) and the relationships between them (how they connect — a user writes many reviews, a review belongs to one movie). A user story is a simple template used to capture what a system actually needs to do from a real user's perspective: "As a [type of user], I want [some goal] so that [some reason]" — gathered by talking to actual or representative stakeholders, then used to inform what data and structure the system needs to support.

Key terms

Entity:

A distinct type of thing being tracked and stored in a database, like a user or a product.

User story:

A simple template capturing what a system needs to do from a real user's perspective.

Questions

1. 1. An entity in database design is:

   • A distinct type of thing being tracked, like a movie or user
   • A type of password
   • A single row of data only
   • Something unrelated to databases

2. 2. A relationship in database design describes:

   • How different entities connect to each other
   • A type of chart colour
   • A single, isolated entity with no connections
   • Something unrelated to data at all

3. 3. A user story follows a template like:

   • "As a [type of user], I want [goal] so that [reason]"
   • A completely random sentence with no structure
   • Only a single word with no context
   • A list of unrelated numbers

4. 4. User stories are gathered by:

   • Talking to actual or representative stakeholders
   • Guessing randomly with no research
   • Ignoring what users actually need
   • Copying an unrelated system exactly

5. 5. "A User writes many Reviews" describes:

   • A relationship between two entities
   • A single isolated entity
   • A type of password requirement
   • Something unrelated to database design

6. 6. User stories help inform:

   • What data and structure a system needs to support
   • Nothing useful about a system's design
   • Only the colour scheme of a website
   • A system's advertising strategy only

7. 7. Modelling entities and relationships is a step in:

   • Designing a database
   • Writing a persuasive essay
   • Painting a picture
   • Planning a sports event

8. 8. Why is identifying the relationships between entities (not just the entities themselves) an essential part of database design?

   • Relationships determine how data connects and can be retrieved together, which is central to how a database actually functions
   • Relationships between entities have no real bearing on how a database is structured or used
   • Identifying entities alone always provides a fully complete database design with nothing more needed
   • Database design only ever requires understanding entities, never how they relate to each other

9. 9. Why might writing a user story from a real or representative user's perspective lead to a more useful database design than guessing what data might be needed?

   • Grounding design decisions in actual user needs and goals helps ensure the resulting data structure genuinely supports how the system will really be used
   • Guessing what data might be needed always produces an equally useful design as gathering real user stories
   • User perspective has no real bearing on what data structure a database actually needs to support
   • A database can only ever be designed effectively without any reference to how real users will interact with it

10. 10. Why might the relationship "a Review belongs to one Movie" (rather than a review belonging to many movies) shape how the database's tables need to be structured?

    • This type of relationship (one movie, many reviews) determines how tables should be linked, such as a Review needing a reference back to a single specific Movie
    • The type of relationship between entities never actually affects how a database's tables need to be structured
    • A Review having a specific relationship type to a Movie has no bearing on the resulting table design
    • Every relationship in a database, regardless of type, is always structured in an identical way

11. 11. Why might a user story like "As a movie fan, I want to filter reviews by star rating" directly inform a specific technical decision, like adding a rating field to the Review entity?

    • The specific goal described in the user story reveals a concrete data requirement (a filterable rating value) needed to support that functionality
    • User stories never actually translate into any specific, concrete technical requirements for a database
    • This particular user story has no real connection to what data fields the Review entity actually needs
    • Technical decisions about database fields are always made with absolutely no connection to user stories

12. 12. Why might interviewing a genuine stakeholder (rather than only the development team's own assumptions) to write user stories improve a database's eventual usefulness?

    • Direct stakeholder input can surface real needs and priorities that a development team working from assumptions alone might miss or misjudge
    • A development team's own internal assumptions always produce exactly as useful a result as direct stakeholder interviews
    • Stakeholder interviews provide no additional insight beyond what a development team could assume on their own
    • The usefulness of a completed database has no real connection to whether real stakeholder input informed its design

13. 13. Why might poorly identifying entities at the start of a database design (like merging two genuinely distinct entities into one) create problems later in a project?

    • An inaccurate entity model can make it difficult to represent real relationships correctly, potentially requiring significant rework once the flaw becomes apparent
    • Merging two genuinely distinct entities into one always has no negative effect on a database's later design or performance
    • Entity identification made early in the design process never has any bearing on later stages of a database project
    • Poor entity modelling is always easy and cost-free to correct no matter how late it is discovered in a project

14. 14. Why might a user story specifically avoid dictating a technical solution (like "add a filter button") and instead focus on the underlying goal ("I want to quickly find the most positive reviews")?

    • Focusing on the underlying goal keeps the door open for the best possible technical solution to be worked out separately, rather than assuming the first idea is the right one
    • A user story should always specify the exact technical implementation rather than describing the user's actual underlying goal
    • Focusing on an underlying goal rather than a specific technical solution provides no real benefit to the design process
    • There is no meaningful difference between a user story describing a goal and one dictating a specific technical solution

15. 15. Why might a database supporting a genuinely complex system (like a large e-commerce platform) require modelling many entities and relationships, rather than just one or two simple tables?

    • Complex real-world systems typically involve many interacting types of data (users, products, orders, payments), each requiring its own entity and set of connecting relationships
    • A single simple table is always fully sufficient for representing any real-world system, no matter how complex
    • The complexity of a real-world system has no bearing on how many entities or relationships its supporting database needs
    • Complex systems never actually require modelling more than one or two entities in their underlying database

16. 16. Why might well-modelled entities and relationships make it easier to later add new functionality to a system, compared to a poorly structured database?

    • A clear, logical structure provides a solid foundation that new features can extend, whereas a poorly structured database may require significant rework to accommodate change
    • A poorly structured database is always exactly as easy to extend with new functionality as a well-modelled one
    • The quality of a database's original entity and relationship modelling has no bearing on how easily new functionality can later be added
    • Adding new functionality to a system never actually depends on how well its underlying database was originally structured

17. 17. Why might conflicting user stories from different types of stakeholders (like a casual user and an administrator) require careful reconciliation when designing a database's structure?

    • Different user types can have genuinely different needs from the same system, so the final design may need to balance or accommodate multiple, sometimes competing, requirements
    • Different stakeholder groups always want exactly identical things from the same system, with no possibility of conflicting needs
    • Reconciling conflicting stakeholder needs has no real bearing on how a database should ultimately be structured
    • A database's structure should always be designed around only a single type of user, ignoring any other stakeholders entirely

18. 18. Why might a database designer choose to split a single, sprawling entity (like storing a movie's cast list as one long text field) into a properly related, separate entity instead?

    • A properly related entity (like a separate Actor entity connected to Movie) allows structured, reliable querying and avoids the limitations of trying to search or filter within a single unstructured text field
    • Storing complex, related data as one long unstructured text field is always exactly as effective as modelling it as a separate related entity
    • Splitting sprawling data into properly related entities never actually improves how effectively a database can be queried
    • The way related data is structured within a database has no bearing on how effectively it can later be searched or filtered

19. 19. Why might a "many-to-many" relationship (like actors appearing in many movies, and movies having many actors) require an additional connecting entity, rather than a simple direct link?

    • A simple direct link can only cleanly represent one-to-one or one-to-many connections, so a many-to-many relationship needs an intermediate entity to correctly record all the individual pairings
    • Many-to-many relationships can always be represented using exactly the same simple direct link used for one-to-many relationships
    • The type of relationship between two entities never actually affects what structure is needed to represent it correctly
    • An additional connecting entity is never actually required for representing any type of relationship between two entities

20. 20. Why might revisiting and refining an entity-relationship model partway through development (after building an initial version) be a normal and expected part of good database design practice?

    • Early modelling decisions are based on the best understanding available at the time, and further insight gained during development can reveal a need for genuine refinement
    • A database's entity-relationship model should always be considered perfect and unchangeable once it is first created
    • Revisiting an entity-relationship model partway through a project always indicates a serious, unacceptable design failure
    • Further insight gained during development never actually reveals any need to refine an original database model

21. 21. Understanding database design through entities, relationships and user stories mainly helps you to:

    • Model real-world data and user needs into a well-structured, functional database design
    • Assume every database only ever needs to represent a single, isolated entity
    • Ignore genuine user needs when deciding what data a system should store
    • Treat relationships between entities as an unnecessary consideration in database design