## Metadata - Author: [[getdbt.com|Getdbt]] - Full Title:: Marts: Business-defined entities - Category:: #🗞️Articles - URL:: https://docs.getdbt.com/best-practices/how-we-structure/4-marts - Read date:: [[2025-03-23]] ## Highlights > We sometimes like to call this the *entity* *layer* or *concept layer*, to emphasize that all our marts are meant to represent a specific entity or concept at its unique grain. For instance, an order, a customer, a territory, a click event, a payment — each of these would be represented with a distinct mart, and each row would represent a discrete instance of these concepts. ([View Highlight](https://read.readwise.io/read/01jphazha7thqm4bs740za1vw8)) > this first layer intended expressly for exposure to end users. ([View Highlight](https://read.readwise.io/read/01jphb0zzk6945ckf8f8fk9vf3)) > grouping though, use useful business concepts here. In our marts layer, we’re no longer worried about source-conformed data, so grouping by departments (marketing, finance, etc.) is the most common structure at this stage. ([View Highlight](https://read.readwise.io/read/01jphb2bz0ec4ckx3qq4gpbbnw)) > Use plain English to name the file based on the concept that forms the grain of the mart’s `customers`, `orders`. Marts that don't include any time-based rollups (pure marts) should not have a time dimension (`orders_per_day`) ([View Highlight](https://read.readwise.io/read/01jphb2y1dtenc1nz89zmqf7ty)) > A good general rule of thumb regarding materialization is to always start with a view (as it takes up essentially no storage and always gives you up-to-date results), once that view takes too long to practically *query*, build it into a table, and finally once that table takes too long to *build* and is slowing down your runs, [configure it as an incremental model](https://docs.getdbt.com/docs/build/incremental-models/). As always, start simple and only add complexity as necessary. The models with the most data and compute-intensive transformations should absolutely take advantage of dbt’s excellent incremental materialization options, but rushing to make all your marts models incremental by default will introduce superfluous difficulty. We recommend reading this [classic post from Tristan on the limits of incremental modeling](https://discourse.getdbt.com/t/on-the-limits-of-incrementality/303). ([View Highlight](https://read.readwise.io/read/01jphb4q0rzg9ef13n3x6pemd0)) > While we strive to preserve a narrowing DAG up to the marts layer, once here things may start to get a little less strict. ([View Highlight](https://read.readwise.io/read/01jphbdg1xsyag563rj79zs585)) > The most important aspect of marts is that they contain all of the useful data about a *particular entity* at a granular level. That doesn’t mean we don’t bring in lots of other entities and concepts, like tons of `user` data into our `orders` mart, we do! It just means that individual `orders` remain the core grain of our table. If we start grouping `users` and `orders` along a [date spine](https://github.com/dbt-labs/dbt-utils#date_spine-source), into something like `user_orders_per_day`, we’re moving past marts into *metrics*. ([View Highlight](https://read.readwise.io/read/01jphb7367d50astnm3efvhsyj))