Usage
Hierarchy
|
Default Value
None
Accepts
A Looker identifier
Special Rules
|
Definition
If there is a plus sign (
+
) in front of the view name, such asview: +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 aview_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.