Data Modeling
Data modeling turns business rules and access patterns into entities, keys, relationships, and constraints so the store can reject invalid states instead of storing them.
Definition
Data modeling is the process of translating business rules and access patterns into a storage structure: entities, attributes, keys, relationships, constraints, and lifecycle rules that determine what the system can represent and which invalid states it rejects.
Context and scope
Every persistent system has a data model, even when nobody drew one. The choice surfaces in migrations, query performance, duplication, and the number of bugs caused by states the schema permits but the business forbids.
Common misconceptions
- A data model is just an entity-relationship diagram, while the real rules live in application code and are not part of the model.
- One correct model exists for a domain, independent of how the data is read and written.
Anti-patterns
- Choosing tables from a diagram before listing the queries and write paths the system must serve.
- Storing the same fact in several places with no single owner or update rule.
Related concepts
Related examples
Authoritative source
How it works
Data modeling starts with the questions the system must answer and the rules it must never break. From there you identify entities, choose identifiers, decide which relationships are mandatory, and encode invariants as primary keys, foreign keys, uniqueness constraints, check constraints, or nullability. A model is more than a diagram: it also defines ownership, lifecycle, retention, and deletion behavior.
Different stores expose different primitives. Relational engines favor tables, joins, and constraints. Document stores favor embedded aggregates and application-level validation. Wide-column stores make the partition key the unit of distribution and query. Graph stores model edges as first-class records. The reasoning is similar, but the constraints available differ sharply.
Start from access patterns
List the top read and write paths before choosing keys. A partition key that spreads writes evenly but cannot answer the main query forces a full scan. A normalized model that is elegant on paper may need six joins for the homepage. Write down cardinality, expected growth, and the consistency each path needs.
Trade-offs
Rigid schemas catch bad data early and make reporting simpler, but every change becomes a migration. Flexible schemas accept new shapes quickly but push validation into services and often produce several versions of the same entity. Duplication improves read speed while creating update anomalies. There is no free option; pick the failure mode you can operate.
When to use it
Model deliberately for any state that outlives a request, especially when several teams read or write it. For a short-lived cache or a prototype, a minimal model is enough, but record the assumptions so they can be revisited.
Misconception and example
A common misconception is that the model is finished once the application ships. Models evolve with the product, and migrations are part of the design. Consider an order that stores the customer’s shipping address at purchase time: referencing the current customer address would silently rewrite history when the customer moves. Copying the address into the order preserves the snapshot, which is a deliberate denormalization rather than an accident.