> ## Documentation Index
> Fetch the complete documentation index at: https://oculon.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Database structure

> Design database structure in Oculon so the records stay usable across models, analysis, and reporting.

Database structure determines how easy the records are to review, map, and reuse later. A clean structure reduces downstream cleanup. A weak structure creates friction in every model or board that depends on it.

![Placeholder image for future Oculon screenshot showing database rows, typed columns, date fields, and segmented data](https://mintcdn.com/oculon/86VwbwjFLcFRyaEK/images/databases/database-structure-placeholder.svg?fit=max\&auto=format\&n=86VwbwjFLcFRyaEK\&q=85\&s=e681e1a905ff05845d060d4d6e9d408c)

## Start with the downstream use case

Before you add fields, decide how the database will be used.

Common questions include:

* Will the records feed a model?
* Will users filter or group the data directly?
* Does the dataset need a date field for time-based review?
* Should one or more fields later map to dimensions or categories?

Those answers usually matter more than the raw source shape.

## Rows and columns

In most databases:

* each row represents one record
* each column represents one field on that record

That sounds simple, but the record grain matters. A database becomes much harder to trust when one row mixes several business events or several time periods together.

## Choose the right granularity

Granularity is the level of detail each row represents.

A useful database usually keeps one clear grain, such as:

* one transaction per row
* one customer per row
* one employee per row
* one opportunity snapshot per row

If the grain is unclear, filters, formulas, and model mappings become harder to validate.

## Add date and category fields deliberately

Date and category fields often carry more downstream value than teams expect.

They help with:

* time-based review
* sorting and filtering
* grouping records into useful slices
* mapping database fields into models and dimensions

If you need time-aware analysis later, include a clean date field now instead of rebuilding the structure later.

## Keep column types readable

A well-typed, well-named field is easier to review than a catch-all text field with mixed content.

Prefer:

* one meaning per column
* stable, business-readable names
* separate numeric, text, date, and category fields where possible

## Treat structural changes carefully

Once a database feeds models, views, or boards, structural changes can have a wide effect.

Be especially careful with:

* renaming columns
* removing fields
* changing the meaning of a category
* changing the effective grain of the records

## Related pages

* [Working with data](https://oculon.mintlify.site/docs-new/databases/working-with-data.md)
* [Linked data](https://oculon.mintlify.site/docs-new/databases/linked-data.md)
* [Using dimensions with variables](https://oculon.mintlify.site/docs-new/dimensions/using-dimensions-with-variables.md)
* [Database best practices](https://oculon.mintlify.site/docs-new/databases/database-best-practices.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.