Use base models and relationships to facilitate data exploration

Holistics is designed for a modeling-first approach so you should focus on reusable data components.

Create your base models, add custom dimensions and measures (that rely on fields within the same table/model), and add relationships. This should enable reports to be built for 60-80% of your use cases.

Define commonly-used fields as custom fields in your model

Both custom dimensions or custom measures created can be reused easily across all reports with central definitions.

• Custom dimensions can be added to any dashboard filter. And also serves as the basis for drill-throughs.

• Only use custom measures when basic aggregations in the Data Exploration UI won’t suffice, like conditional SUM

• Instead of building a pre-aggregated table in the modeling layer (with hardcode), you could use custom measures to automatically apply GROUP BY clauses based on the reports you build.

• Build recursive dimensions on existing custom dimensions.

  For example, we figure out someone's age by subtracting the birth date from the current date. Then, we enter a series of CASE... WHEN... to group people into different groups:

  dimension 1: age= NOW() - {{self.birth_date}};
  dimension 2: age_group = CASE WHEN {{age}}  .... END;

For a detailed article on Creating Dimensions & Measures, please visit our insightful guide on this topic.

Build relationships across data models where possible

• If you need more than one model, you need to specify how they should be joined together by setting up Relationships between models, then create Datasets out of those related models.
• Relationships are a key component of the dataset. Each relationship will help you create flexible permutations of any models into datasets.
• You get a native database ERD diagram that can be built and maintained easily.

Document your data fields

• Add metadata (table description, field description, etc...) to important models as you need.
• This provides the basis for your data context (eg when someone asks a question about the context of a data field) and reduces communication overheads.

Hide fields that are not needed (only in 4.0)

Hiding a field (dimension or measure) means that it’s still loaded into the data model and can be used in calculations. When you hide a field, it’s only hidden from the Exploration interface of Dataset and Report but can still be seen in the Data Model view.

How to hide a field?

By using the hidden parameter on dimensions or measures, you can hide a field that will never be used in your Exploration to avoid confusion.

How to decide which fields you should hide?

Below are our guidelines for when it is usually better to hide them or leave them visible.

HIDE	DON’T HIDE
Join Keys/IDs and compound primary keys Field used to sort other fields Field is purely technical and is only created for some calculations Have you created a measure that shows the same result as the actual value field? (i.e. The field Revenue can be hidden once you have a measure that calculates the revenue)	The field is used in a visual