# Data Modeling Overview

To understand data modeling in Zenlytic, there are a few key concepts to grasp. If you've used data models like LookML before, these will be intuitive, and you'll be able to go straight to the implementation of your model. To better understand how to define context for Zoë, the AI analyst, see [Context Surfaces](/core-concepts/context-surfaces.md).

Note: You can also use our automatic LookML -> ZenML converter [here](https://lookml-zenml.netlify.app/).

{% hint style="info" %}
**You don't have to author alone.** Ask Zoë in chat how to add a measure, write a calculation, or model a relationship and she'll recommend specific YAML and explain where it belongs. See [Ask Zoë for Data Model Recommendations](/data-modeling/asking-zoe-for-recommendations.md).
{% endhint %}

## Key concepts

* [Models](/data-modeling/model.md)
  * Models are references to a database connection. They serve as the data model's reference to the warehouses itself. They give your data model the ability to reference multiple data warehouses, and set some high level properties like the week start day or the timezone.
* [Views](/data-modeling/view.md)
  * Views directly represent an underlying database table. They contain both the [dimensions (columns)](/data-modeling/dimension.md) and [measures (aggregates)](/data-modeling/measure.md) inside of the table they reference. Views are organized into [topics](/legacy/topic.md) which define how they join together.
* [Dimensions](/data-modeling/dimension.md)
  * A dimension represents a column in the database table it's view references. You can also have groups of dimensions (like timeframes) which reference the same column with different transformations applied.
* [Measures (metrics)](/data-modeling/measure.md)
  * A measure (or metric) represents the aggregation of a dimension or dimensions inside the table its view references. Any valid aggregation in a SQL statement with a `group by` will work as a measure (e.g. `sum(sales)`).

## Examples

The best way to learn to to see examples. We have an example using our metrics yaml syntax.

* [Metrics Layer yaml example](https://github.com/Zenlytic/demo-data-model)

## Naming conventions

Naming is a crucial part of any data model and one of the most difficult aspects of maintaining a data model that can be understood by end users. Here are some Zenlytic naming conventions, both technically required and recommended.

### Technically Required

* The `name` field. Name fields must only contain letters, numbers, or the `_` character. They must be unique throughout your collection they are in, and despite how you may choose to enter them, they will always be lower-cased when referenced in Zenlytic. This syntax is required when naming objects in Zenlytic

### Recommendations

Naming can be challenging. This is especially true in a domain as complex as your company's data model. These are a few recommendations from our experience on how to make it easier.

* Plurals vs singulars: When you name views, be consistent with your choice of plural or singular words. For example, if you name the table with sales orders in it `orders` don't name the table with order lines `order_line`, you should name it `order_lines`. It doesn't matter if you choose to go with singular or plural name, just be consistent.
* Prefixes and suffixes: Often you'll have metrics that total or sum up a column, e.g. sales or revenue. Again, consistency is key. If you have a metric named `total_gross_revenue` don't also have one `sum_net_revenue` or just `net_revenue`, you should name that metric `total_net_revenue`. End users will be confused by inconsistency in prefixes or suffixes. Again, it is less important *which* prefixes you use (if any). Consistency is the most important aspect.
* Multiple versions: You will almost certainly have some data issue in your warehouse that duplicates some table or view. Use your data model to hide those tables from your end users. They don't care that they're getting data from the `company_ga_3` table, and you shouldn't make them care. Eliminate duplicate names by designing joins that combine previously separate data into one view.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.zenlytic.com/data-modeling/data_modeling.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.