Skip to main content
For every table Omni can access in the underlying database, Omni will create a view file. The view file is a representation of the view’s configuration, including its:

​
Views versus topics

A view is a single object in your data model, whereas topics sit on top of the data model and reshape it into business-friendly groupings for easier exploration. Topics can include multiple views, which can be curated ahead of time for self-service. Think of views as the objects that make up topics, and topics as the presentation layer you tailor for quick insights. Topics effectively translate your database model into reusable logic for building dashboards and workbooks.

​
Accessing view files

In the model IDE, views are nested under the database schema that contains them. You can use the search or click through the Schemas section of the model IDE to locate individual views.

​
Creating views

To add a new view, click File > New view in the model IDE. Omni will prompt you to enter a name and then create a new view file. Refer to the View parameter reference to learn more about how configuring views.
To reference fields in the view where they’re defined, use {$field} rather than {$view.field}. Using ${field} ensures that the reference will remain even if the you alias the view, whereas ${view.field} will cause a model validation error because it doesn’t pick up the alias.

​
Aliasing views

Aliased views are best paired with topics and may not appear as views in All Views and Fields in the workbook.
If the name of view’s base table changes in the database, it can cause content in Omni to break. Use the aliases parameter to add the table’s original name(s), which will allow Omni to find the correct table in the databse.
In some cases, you may need to duplicate a view - for example, a users view that contains both buyers and sellers. Aliased views are automatically created when you define them as joins in the model’s Relationships file.The following example demonstrates how to alias the users view to create buyers and sellers views. Note that the names of the aliased views are used to declare the joins:
relationships.yaml
- join_to_view: users
  join_to_view_as: buyers
  join_type: always_left
  relationship_type: many_to_one
  on_sql: ${order_items.user_id} = ${buyers.id}
  reversible: false

- join_to_view: users
  join_to_view_as: sellers
  join_type: always_left
  relationship_type: many_to_one
  on_sql: ${order_items.user_id} = ${sellers.id}
  reversible: false