What is a data model?
A data model is a description of the things a business keeps records about, such as customers, accounts, products, and locations, along with the facts recorded for each and the rules that connect them. It settles questions such as whether a customer can have several billing addresses, whether an order can ship from two warehouses, and whether a product can sit in more than one category.
A schema is the form a data model takes inside a particular database, and a canonical schema is a shared model used to translate between systems. Despite the shared word, a data model is a different thing from an AI model. The first describes how information is organized, and the second is a trained program that makes predictions.
Types of data models
Data models are usually drawn at three levels of detail.
- Conceptual models show the main business entities and how they relate, in terms a department head can review.
- Logical models add attributes, keys, and rules without committing to a particular database product.
- Physical models specify the actual tables, columns, data types, and indexes in a specific database or lakehouse.
The modeling style depends on the job. Transaction systems such as an ERP use normalized relational models that store each fact once. Data warehouses usually use dimensional models, with tables of events such as payments or shipments linked to descriptive tables for customer, date, and product. Knowledge graphs store entities and relationships as nodes and edges.
Data model in practice
A collections agency that works accounts for many creditors has to decide whether the debtor is an entity of its own or a set of fields copied onto each account. With copies, a corrected phone number reaches one account and not the others, so collectors on the other accounts keep calling the old number. Modeling the debtor once and linking that record to every account, payment, and contact attempt means a new address is entered once and a bankruptcy notice flags every account the person owes. The same structure lets a text-to-SQL assistant total a person’s balances with one correct query, because the relationships are explicit.
What to watch for
- Agree on what a customer, an account, and an order mean before anyone builds tables, because definitions are harder to change than code.
- Choose stable identifiers early, and use master data management where the same entity lives in several systems.
- Keep the model documented in a data dictionary that analysts and AI tools can read.
- Version changes to the model so that reports, pipelines, and agents are updated deliberately.