view

Usage

view: view_name { ... }
Hierarchy
Default Value
None

Accepts
A Looker identifier

Special Rules
  • To be usable, the view must be referenced by an explore or join parameter
  • View names must be unique within any given model

Definition

If there is a plus sign (+) in front of the view name, such as view: +orders, that is a refinement of a view. See the LookML refinements documentation page for more information.

The view parameter, along with its underlying parameters, describes a table of data that will be used in a Looker model. That table can already exist in your database or you can create a new table using Looker's derived table functionality.

In the case of an existing database table, the name of the view generally matches the name of the table that you want to work with. If you want the view name to be different than the underlying table or if you need to reference a table from a different database or schema, you can add the sql_table_name parameter.

In the case of a derived table, the name of the view can be any identifier. Then references to the derived table use that identifier name.

After you create a view, you must reference that view in an explore or join parameter to make the view available to users.

When you use a measure of type: count in an Explore, the visualization labels the resulting values with the view name rather than the word "Count." To avoid confusion, we recommend pluralizing your view name, selecting Show Full Field Name under Series in the visualization settings, or using a view_label with a pluralized version of your view name.

Examples

Make the orders table in your database available for modeling:

view: orders {}

Create a derived_table named user_facts:

view: user_facts {
  derived_table: {
    sql: … ;;
  }
}

Make the order_1 table in your database available for modeling, but use the sql_table_name parameter to call it orders:

view: orders {
  sql_table_name: order_1 ;;
}

Use the sql_table_name parameter to make the users table from your analytics schema available for modeling:

view: users {
  sql_table_name: analytics.user ;;
}

Common challenges

A view is not accessible by users until added using explore or join

Creating a view will not do anything in and of itself. In order for users to be able to interact with it the view must be referenced by an explore or join parameter.

Two views must be referred to by different names within an Explore

Within any given Explore, a view can be used more than once, but each view must have a unique reference. If you need to join a view to an Explore more than once, you need to use the from parameter in your join.

Tables referenced by view must be accessible from the current connection

Views are referenced by an explore or join parameter, which in turn is referenced by a model. The model determines which database connection is used (see the connection parameter). Database connections themselves are defined in the Admin section of Looker, and they have a default schema associated with them.

When you reference a table in the view parameter, the table needs to be accessible within the associated connection. Additionally, if you need to reference a table from the non-default schema, you'll need to make use of the sql_table_name parameter to provide the non-default schema name.

Things to know

view usually contains dimensions and measures

Although view could theoretically be used all by itself, in practice, it almost always has dimensions and measures nested underneath it. Dimensions provide access to the columns of the database table, while measures allow aggregation of columns.

Dimensions are described on the Dimension, filter, and parameter types documentation page, while measures are described on the Measure types documentation page. In addition, you can define filter fields and groups of date-based dimension fields using dimension groups.