AI Glossary / Data engineering and architecture / Beginner

Data model

Definition

A data model is a representation of how data is organized, what it means, how its elements relate and which rules apply. It provides a shared design for storing, exchanging or interpreting information in a particular context.

What it means

The phrase can refer to a specific design, such as a model of customers and orders, or to a general organizing approach, such as the relational or document model. In a project, it is important to state which meaning and level of detail are intended.

A useful model does more than list field names. It explains whether an order can contain several items, how an item is identified, what a missing value means and whether historical values must be preserved. Those choices shape the questions the resulting data can answer.

A data model is different from a machine-learning model. The former describes the representation of information; the latter learns or implements relationships used for prediction, generation or another task. An AI system often relies on both.

How it works

A model identifies entities or other information structures, their characteristics, their relationships and relevant constraints. Definitions should connect these structures to the actual business domain rather than merely copying an existing screen layout.

Conceptual models concentrate on major meanings and relationships. Logical models develop detailed organization and identifiers. Physical models describe implementation choices for a particular technology. The boundaries vary by methodology, so teams should define their conventions.

Different storage approaches express relationships differently. A relational design may connect tables through keys. A document design may embed related information or refer to another document. The choice should consider meaning, access patterns, updates and consistency requirements. Flexible storage does not remove the need for a model; it may simply leave more of that model implicit in application code unless documented.

Three practical examples

1. Online ordering: a model distinguishes Product, Order and Order Line so the price agreed at purchase can differ from today's catalog price.

2. AI evaluation: a team models Dataset Version, Test Case, Model Version and Evaluation Run, allowing a score to be traced to the exact inputs and configuration.

3. Personal budgeting: a model distinguishes an account transfer from spending, preventing money moved between two owned accounts from being counted as a new expense.

Think of it this way

Think of a set of labeled containers together with instructions explaining what belongs in each and how the contents are connected. The labels alone are insufficient; the rules give the arrangement meaning. The analogy is limited because a data model can describe events, identity and time, and the same logical information can have several physical storage representations.

Worked example

A shop sells product P8. Its current catalog price is 30 currency units, but an order placed last week agreed a price of 25. The customer bought two units.

If the data model stores only ProductID and Quantity on the order line and always looks up the current catalog price, the historical order appears to total 2 × 30 = 60. The agreed line amount was 2 × 25 = 50.

The model therefore needs a way to preserve the price applicable to the transaction, for example an agreed unit price on the order line with appropriate rules. That field is a historical transaction fact, not necessarily an accidental duplicate of the current catalog value.

The example shows why meanings and time matter. Choosing a numeric datatype alone cannot decide which price belongs in the record or whether later catalog updates should change historical reports.

Illustrative case study

Illustrative fictional case: Coastline AI stores evaluation scores in a table containing only model_name and score. When staff compare two runs, they discover that the dataset and scoring method changed between them.

The team revises its model to identify evaluation runs and link each run to a model version, dataset version and scoring configuration. It also records the meaning and scale of each metric. Historical records lacking those details are labeled as incomplete rather than assigned invented versions.

The fictional case illustrates how a model determines interpretability. The new structure enables better comparisons when populated correctly, but it does not prove that a metric is appropriate or that the evaluations were executed without error.

Common misconceptions and mistakes

Do not equate a data model with a diagram alone. Definitions and constraints may be essential even when they are not visible in boxes and lines. Do not assume the same field name has the same meaning across systems.

Avoid treating every repeated value as a design error without considering history and access needs. Do not use a flexible database as a reason to ignore types, relationships or validation. Conversely, do not force every kind of information into one universal structure simply because a familiar tool supports it.

Business use

Use a data model to align teams before and during implementation. Review it with examples of creation, change, deletion and historical reporting, not only ordinary read queries.

For AI projects, model provenance, versions, permissions and evaluation context where they affect use. Check whether a generated answer or score can be traced back to the relevant source facts. Maintain the model as systems evolve, recording intentional departures between the documented design and deployed structures. A model is useful when people can apply it to concrete decisions, not merely when a diagram has been approved.

Check your understanding

A record contains a field named amount with no currency or explanation of whether tax is included. Is its meaning adequately modeled?

Answer: No. A numeric field alone leaves important semantics unresolved. The model should define the amount's meaning and how currency and tax treatment are represented.

Related terms

Data Modeling
Schema
Conceptual data model
Logical Data Model
entity
attribute
relationship
physical data model
semantic model

Learn next

Choose one business record and define each field's meaning, units, identity and time context. Then test whether the design can represent a correction and a historical query. Compare relational and document representations without losing the underlying business definitions.

Sources

IBM, data modelling and model levels: https://www.ibm.com/think/topics/data-modeling

Microsoft, Entity Data Model key concepts, entities and relationships: https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/entity-data-model-key-concepts

MongoDB, embedded data and document-model choices: https://www.mongodb.com/docs/manual/data-modeling/embedding/

IBM, data architecture and the role of models: https://www.ibm.com/think/topics/data-architecture

Order pricing, budgeting and evaluation examples are original illustrations.

Previous: Data mining Next: Data Modeling