A data model is a structured description of the things a business tracks (customers, orders, campaigns, flights), the attributes of each, and how they relate. In analytics it also fixes the grain of every table, meaning exactly what one row represents. It is the layer that turns raw source tables into clean, joinable tables you can compute metrics from.
What is a data model?
Data models are usually described at three levels. A conceptual model names the business entities and relationships (“a customer has many subscriptions”). A logical model adds attributes, keys and cardinality. A physical model is the actual tables, types and indexes in a database. Analytics teams then pick a modeling style. Normalized models suit transactional systems. Dimensional (star) models, which separate facts from descriptive dimensions, suit reporting.1Source 1 · Kimball GroupDimensional Modeling Techniqueskimballgroup.com Many modern stacks use SQL-defined models built on top of the warehouse.3Source 3 · dbt LabsWhat is dbt?docs.getdbt.com
What does “grain” mean, and why does it matter?
The Kimball Group calls declaring the grain the pivotal step in a dimensional design. The grain establishes exactly what a single fact table row represents, and it must be declared before choosing dimensions or facts.2Source 2 · Kimball GroupGrainkimballgroup.com “One row per order line” and “one row per order” look similar, but summing shipping cost at the line grain multiplies it by the number of lines.
| Table | Grain | Kind |
|---|---|---|
orders | One row per order | Fact |
order_lines | One row per product per order | Fact |
subscriptions_daily | One row per subscription per day | Periodic snapshot fact |
customers | One row per customer (current state) | Dimension |
Example: answering “revenue by region”
With order_lines as the fact and customers as a dimension joined on customer_id, the query sum(line_amount) grouped by customers.region is correct by construction: each line belongs to exactly one customer. Join customers to support_tickets instead and revenue repeats once per ticket. Good models prevent that by declaring keys and cardinality, and the semantic layer enforces them.
Common misconceptions
- “The source schema is the model.” Source schemas are built for applications, not questions. They need renaming, deduplication and a declared grain.
- “One giant wide table is simpler.” It is, until two grains end up in it. Keep wide tables as outputs, not foundations.
- “Modeling is a one-time project.” Products and definitions change. Version your models like code.
How Kimo uses data models
In Kimo, Models are where raw synced or bridged tables become named entities with declared grain, keys and joins. The Catalog documents them, and every dashboard and Ask Kimo answer builds on them. Read data models and joins in the docs, or start from the SaaS metrics template, which ships with a ready-made model.
Related terms
- Semantic layer: measures and dimensions defined on top of the model.
- ELT vs ETL: where in the pipeline modeling happens.
- Cohort analysis: a common query that depends on clean grain.
Frequently asked questions
What is the difference between a data model and a database schema?
Star schema or wide tables?
How do I find the grain of an existing table?
count(*) versus count(distinct …)), then write that down as a sentence: “one row per … per …”.Sources
3 references- Dimensional Modeling Techniques (opens in a new tab)Kimball Groupkimballgroup.com
Facts, dimensions, star schemas, snapshot fact tables.
- Grain (opens in a new tab)Kimball Groupkimballgroup.com
Declaring the grain is the pivotal step; it defines what one fact row represents.
- What is dbt? (opens in a new tab)dbt Labsdocs.getdbt.com
SQL-defined, modular data models built on warehouse data.
External sources were accessed at the time of writing. Kimo product details, customers and figures in examples are illustrative unless a source is cited.
