Entity-relationship modelling maps out a planned database's real-world entities, the distinct things a system needs to track, customers, orders, products, together with each entity's own relevant attributes and exactly how the different entities relate to one another, before a single actual database table is created. This diagramming step gives database designers a shared, visual blueprint they can review, discuss and correct together while a design mistake still only costs redrawing part of a diagram, not rebuilding an already-populated production database.
Entities, attributes and relationships give designers a shared visual vocabulary
An entity-relationship diagram represents each entity as a distinct box, its relevant attributes listed alongside it, and draws explicit connecting lines showing exactly how different entities relate, one customer can place many orders, one order can contain many products, with the specific nature of each relationship clearly marked. This visual vocabulary lets designers, and non-technical stakeholders who understand the underlying business but not the technical database, review the exact same diagram together, catching a missing entity or a wrongly understood relationship well before it's baked into actual, deployed database structure.
Catching a design mistake at the diagram stage is dramatically cheaper than catching it later
A flawed database structure discovered only after real data has been loaded into it is genuinely expensive and risky to fix, potentially requiring a careful, error-prone data migration to correct, while the exact same flaw discovered at the entity-relationship diagramming stage costs nothing more than redrawing a box or a connecting line before any actual database structure or data exists at all. This is exactly why entity-relationship modelling is treated as an essential, deliberate early design step rather than an optional formality: it's specifically designed to move design mistakes to the cheapest possible point in the process to actually catch and fix them.
What we're still unsure about
That entity-relationship modelling helps catch database design flaws early, before they're expensive to fix in a populated production system, is well established, extensively practised database design methodology going back decades. What's more genuinely a matter of ongoing practical debate is exactly how much upfront entity-relationship diagramming a given project actually needs before starting implementation, versus how much can reasonably be worked out and refined iteratively as the system is actually built, and database designers and software teams continue to make genuinely different, context-dependent choices about how much formal upfront modelling versus iterative refinement a given project's specific risk profile actually calls for.
This sits inside Entity-Relationship Modelling, one of seven topics in Databases, one of seven domains in Computer Science, one of seventeen subjects the app can quiz you on.