How a project works in Looker

Stay organized with collections Save and categorize content based on your preferences.

In Looker, a project is a collection of files that describe the objects, connections, and user interface elements that will be used to carry out SQL queries. At the most basic level, these files describe how your database tables relate to each other and how Looker should interpret them. They may also include LookML parameters that define or change the options presented in Looker's UI.

Parts of a project

The main files in a project are view files and model files.

A view corresponds to a database table or a derived table. Here, a developer defines a list of fields from those tables that should appear in the UI to build queries from.

A model specifies a connection to a single database. A developer also defines the model's Explores here.

In Looker, an Explore refers to two closely related things. explore (which you'll see in code font throughout our documentation) is a LookML parameter used within a model file to define query options. An Explore (capitalized throughout our documentation) is also an interactive page in Looker where users can build SQL queries by selecting fields, applying filters, and choosing from options that were established in the project's files.

In addition to models and views, a project can have other types of files related to things like built-in dashboards, documentation, localization, and more. For more information, see the Understanding other project files documentation page.

These files together make up one project. If you are using Git for version control, then each project is typically backed up by its own Git repository.

What users see

How the project is set up, and the specific contents of its files, determines what users see and how they can interact with Looker.

  1. The Explore menu is organized by model names. Under each model name is a list of available Explores defined in that model.
  2. Users can search the menu if they know the name of the Explore that they want.
  3. Developers can include descriptions for Explores, which users can view on hover. This example shows an Explore called Order Items within a model called eCommerce.

  4. The field picker pane is organized by view names. Under each view name is a list of available fields from the tables included in that view. Most views show both dimensions and measures. This example selects a Month dimension from within a Returned Date dimension group, which was defined in the view file.

  5. Users can select multiple measures on which to base the query.

  6. Users can apply options like filters and pivots in the field picker pane.

  7. Users can refine the terms of the query.

  8. Users can choose a visualization type to apply to the query results.

  9. Running this Explore generates a SQL query that returns both a data table and a visualization of the total sale price and total gross margin of the returned orders from the past year.