Data modeling definition
Data modeling is the process of defining how data is structured, related, and constrained in a system before that system is built. Its output is a data model: a specification of the entities involved, the attributes each entity carries, the relationships between entities, and the rules that decide which values are valid.
Data modeling is the work of deciding what your data is made of, how its pieces relate, and which values count as valid, done before anyone writes the code that stores it. In Sanity, that model is declared as JavaScript or TypeScript objects in the Studio configuration while the Content Lake itself stays schema-less, so the model that governs structure, relationships, and validation can change without rebuilding a database underneath it.
Data modeling is the activity; a data model is the artifact it produces. The two words get used interchangeably in search results, which is the single biggest source of confusion around the term.
The model itself is, in Wikipedia's formulation, "an abstract model that organizes data elements and standardizes how they relate to one another." TechTarget describes the artifact more visually: a simplified diagram of a software system and the data elements it contains, using text and symbols to show the data and how it flows, which businesses then use as a blueprint for designing a new database or reengineering a legacy application.
The practical reason to keep the distinction is that the activity has value even when the diagram is thrown away. TechTarget notes that data modeling lets data management and analytics teams "document data requirements for applications and identify errors in development plans before any code is written." The cheap place to discover that two teams mean different things by the word "customer" is in a modeling conversation, not in a migration script.
Data modeling is normally described at three levels of abstraction, and they are usually produced in this order: conceptual, then logical, then physical.
A conceptual data model is a high-level view of the business processes a system supports. It names the kinds of data needed, how business entities relate to each other, and the associated business rules. Its audience is business stakeholders, and it is deliberately not tied to any database or technology.
A logical data model is less abstract. It shows how the entities relate and describes the data from a technical angle: data structures, attributes, keys, data types, and other characteristics. It is still independent of any particular database product.
A physical data model describes how the data is actually stored in a specific database, and is specific to the database management system or application software being implemented.
The progression is not the only route. TechTarget, in its March 19, 2024 definition, also describes models produced by reverse-engineering existing systems, "to document the structure of relational databases that were built on an ad hoc basis without upfront data modeling." That reverse case is common enough to have its own name in most teams: figuring out what the database already means.
Data modeling has several established techniques, and the one a team picks depends on what the data has to do. TechTarget names seven: hierarchical, network, relational, entity-relationship, dimensional, object-oriented, and graph data modeling.
Two of those names get mistaken for the whole discipline. Entity-relationship modeling, usually drawn as an ER diagram, is one technique among the seven, and the diagram is a notation rather than the practice. Relational modeling, which organizes data into tables of rows and columns with keys linking them, is so dominant in business systems that people sometimes assume data modeling means designing tables.
It is also worth separating data modeling from three neighboring activities. Database schema design covers roughly the physical layer only, the tables, columns, indexes, and constraints of one database, while data modeling includes the conceptual and logical layers that come before a database is even chosen. Data mapping connects fields in one system to fields in another for migration or integration, and it presumes both models already exist. Data architecture is broader: TechTarget treats data models as one component of it, alongside data flow diagrams, architectural blueprints, and a unified data vocabulary.
Content modeling is data modeling applied to editorial and marketing content, with one structural difference: humans create the data by hand, so the authoring experience is a first-class modeling concern rather than an afterthought.
In classical data modeling, the entities usually describe data a system already produces or consumes, such as transactions, sensor readings, or account records. In content modeling the entities are things like a product, an author, a campaign, or a landing page, and each field in the model becomes a field somebody fills in. A model that is technically correct but hostile to write into will be worked around, which is a failure mode data modelers for machine-generated data rarely have to price in.
Sanity's documentation uses content model and schema interchangeably, defining the content model as the complete collection of document types and field definitions that make up your content structure, and describes the design goal in the same terms a data modeler would recognize: the model should reflect your organization's business reality and align with how teams actually work and think about content, rather than forcing teams to adapt to rigid technical structures.
In Sanity, the data model is a schema written as code. Schemas are plain JavaScript or TypeScript objects that describe the structure, relationships, and constraints of your content, declared in the Studio root configuration file, typically `sanity.config.ts`, under the schema configuration's types property. The default CLI scaffold puts them in a root folder called schemaTypes. The documentation's own shorthand for the hierarchy is schema, then document types, then schema and field types.
Document types are the entity layer, and the docs compare them directly to tables in SQL databases. A document type is made of fields, carries revision history, can have copies representing published, draft, and version states, and can hold indexed, queryable references to other documents. The docs also warn against assuming a document type maps to a page or a post, offering project, person, product, and place as examples instead.
Relationships are modeled with reference fields rather than by nesting one document type inside another. Sanity's docs are explicit: a document should not be used directly as a field type, because document types carry system fields (`_id`, `_rev`, `_createdAt`, and `_updatedAt`) that mean nothing when embedded, and the pattern can break generated TypeScript types. Use a reference to link, and an object type to embed fields inline. Field-level rules come from validation methods such as required, either, all, and custom.
One more Sanity-specific property matters for anyone comparing this to database modeling. The Content Lake is schema-less, so the model lives in code rather than in the storage engine, which means the model can be modified without rebuilding the underlying database. Sanity describes itself as a Content Operating System for the AI era, providing the structured foundation, automation layer, and agentic context companies need to power every content experience, from websites to AI agents, and the schema is where that structure is declared.
Data models change because the businesses they describe change. TechTarget puts it plainly: data models "are also expected to change over time along with business needs." A model that was correct when a product had one pricing tier is wrong the week the second tier ships.
That expectation is why modeling is treated as an ongoing practice rather than a one-time design phase, and why it often sits close to data governance. TechTarget notes that data modeling can help establish common data definitions and internal data standards, frequently in connection with governance programs. The people doing it have traditionally been data modelers, data architects, and data management professionals, working with input from business analysts, executives, and users, though TechTarget observes it is now also a skill for data scientists and analysts building business intelligence and advanced analytics applications.
Change is also where modeling gets expensive, because existing records were written against the old shape. Sanity's documentation states that schemas naturally evolve as business requirements change, and ships content migration tooling to programmatically transform existing content to match new schema structures and run validation rules across a whole dataset, plus a schema validation command for checking the model itself. Whatever the stack, the question to ask of a model is not only whether it describes today's data correctly but how much it will cost to reshape next quarter.
Discover More with Sanity
Now that you've learned about data modeling, why not start exploring what Sanity has to offer? Dive into our platform and see how it can support your content needs.
Last updated: