Is data modeling only for relational databases?

No. Document, graph and other systems also need deliberate decisions about structure, identity, relationships and usage.

How is it different from data model?

Data modeling is the activity; a data model is one of its outputs. The model may evolve through several iterations.

Can the model change after launch?

Yes. New requirements and evidence often require changes. Use controlled migrations and compatibility planning so the deployed system and existing records remain interpretable.

AI Glossary / Data engineering and architecture / Beginner

Data Modeling

Definition

Data modeling is the process of designing and documenting how information should be represented, related and governed by rules. It turns business requirements and usage needs into a data model that can guide implementation and interpretation.

What it means

The activity begins with meaning. A designer asks what the organization needs to know, which things and events must be distinguished, and what makes each record identifiable. The answers shape the structure before detailed storage choices are made.

For example, “record customer addresses” leaves many questions unanswered. Can a customer have several addresses? Must past delivery addresses remain available? Is an address owned by a person, an account or an order? Data modeling makes those questions explicit.

The work continues after an initial diagram. Designers test examples, refine assumptions, compare implementation choices and revise the model when requirements change. AI can assist with candidate structures, but it cannot establish unprovided business facts merely by producing plausible field names.

How it works

Begin with a defined purpose and representative business scenarios. Identify major concepts and give them clear definitions. Describe relationships, their optionality and multiplicity, then specify identifiers, attributes and constraints at the appropriate level of detail.

Develop logical structures and consider normalization or other organization techniques where suitable. When selecting physical structures, examine expected queries, update patterns, scale and the capabilities of the chosen database. In document databases, for example, embedding and referencing offer different trade-offs for related information.

Validate the design with sample records and operations: creating something, changing it, recording an exception and asking a historical question. Review the results with domain owners. Document assumptions and unresolved points, then keep the model aligned with migrations and application changes rather than letting it become a forgotten design-stage picture.

Three practical examples

1. Subscription service: designers distinguish a plan, a customer's subscription and individual billing events, making upgrades and cancellations representable without rewriting history.

2. AI content system: a team models sources, document versions, extracted passages and publication decisions so retrieval can select suitable content and explain its origin.

3. Volunteer scheduling: organizers model volunteers, shifts and assignments, clarifying whether a person may hold overlapping assignments and how cancellations are recorded.

Think of it this way

Think of designing a form after observing the work it must support. The designer asks which questions belong together, what answers mean and which combinations are allowed. Data modeling extends that reasoning across many records and systems. The analogy is limited because a model should represent the domain independently of any one screen or form layout.

Worked example

A fictional rental service initially proposes Equipment(ItemID, CustomerName, ReturnDate). This mixes the equipment itself with one borrowing event. When an item is borrowed again, overwriting CustomerName and ReturnDate would lose the previous rental.

The designer separates Equipment, Customer and Rental. Each Rental links one customer to one item and records its checkout and return details. Equipment can now exist before its first rental and remain identifiable across many rentals.

With two items and three completed rentals, the model stores two equipment instances and three rental instances rather than duplicating the meaning of the equipment identifier for every event. If one rental has not ended, the model must define how that state is represented.

A further rule may forbid overlapping active rentals for an item. The team records that rule and investigates an enforcement approach appropriate to its database; drawing a relationship line alone does not enforce it.

Illustrative case study

Illustrative fictional case: Juniper Answers asks an assistant to draft a schema for customer questions and AI responses. The draft stores only the latest answer text against each question.

A review reveals that staff need to compare regenerated answers and investigate which source versions were available at the time. The team introduces Answer Attempt and separates it from the continuing Question. Each attempt records its relevant generation configuration and source references, subject to the project's retention requirements.

The team tests a question with two attempts and a corrected source document. This fictional case shows why modeling should begin with actual questions the system must answer. It does not imply that retaining unlimited conversation history is always necessary or appropriate.

Common misconceptions and mistakes

Do not start and finish with whatever table structure an AI assistant first proposes. Do not copy every field from an existing spreadsheet without questioning its meaning. Do not treat current sample uniqueness as proof that an attribute will remain a valid identifier.

Avoid optimizing solely for one query while ignoring updates and history. Do not assume normalization is a universal command to eliminate every repeated value, or that denormalization means abandoning consistency rules. Record intentional trade-offs and the mechanisms that keep derived or duplicated information correct.

Business use

Use data modeling to reduce ambiguity between business and technical teams and to make future changes more predictable. Agree what the model must support before selecting detailed storage features.

For an AI project, pay special attention to provenance, evaluation records, version changes and access boundaries. Review whether the data can support both ordinary operation and investigation of an unexpected result. Useful deliverables include definitions, diagrams, sample cases, constraint descriptions and a record of open decisions. A small tested model is generally more actionable than a large diagram whose assumptions nobody has checked.

Check your understanding

A designer uses customer email as the permanent identifier because the current spreadsheet has no duplicates. What should be checked?

Answer: Whether emails can change, be shared, be missing or be reused, and whether the business requires customer identity to survive those events. A sample pattern does not settle the identity rule.

Related terms

Data model
Normalization
Cardinality (data modeling)
Business rule
Data architecture
entity-relationship modelling
schema design
cardinality
identifier
database migration

Learn next

Model a familiar process using a normal case, a correction and a repeated event. Ask a domain expert to challenge each relationship and identifier. Next, learn logical schema design and compare how the same accepted business meaning can be implemented in relational and document systems.

Logical schema

Sources

IBM, data modeling process and conceptual, logical and physical models: https://www.ibm.com/think/topics/data-modeling

MongoDB, schema-design process and relationship mapping: https://www.mongodb.com/docs/manual/data-modeling/schema-design-process/map-relationships/

Microsoft, data modelling and business relationships: https://www.microsoft.com/en-gb/power-platform/products/power-bi/topics/data-modeling/what-is-data-modeling

PostgreSQL, changing deployed table definitions: https://www.postgresql.org/docs/17/ddl-alter.html

Rental and AI-answer scenarios are original fictional illustrations.

Previous: Data model Next: Data normalization