What is a View in Looker?

Getting started with Looker means getting comfortable with its core components, and nothing is more fundamental than a “View.” It’s the foundational building block for all your analysis. This article will break down exactly what a View is, what its components are, and how you can use them to define your data for your entire organization.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

What is a Looker View?

In Looker, a View is a file that describes a database table or a derived table. Think of it as a blueprint for your data. Its primary job is to define the lists of dimensions (columns you can group by) and measures (calculations or aggregations) that are available for that table. You're essentially teaching Looker what each column in your table means and how it should be used in reports.

Each View file typically corresponds to one underlying table in your database. For instance, you might have a users table, an orders table, and a products table in your database. In Looker, you would create users.view, orders.view, and products.view files to represent each one. These files, written in Looker's modeling language, LookML, tell Looker how to interact with the raw data.

It's important not to confuse a View with an “Explore.” An Explore is the user-facing query builder in the Looker UI where business users go to build reports. An Explore is built using one or more Views that have been joined together in the data model. The View is the behind-the-scenes foundation, the Explore is the playground.

The Core Components of a Looker View File

Every view file is structured using LookML parameters. While there are dozens of potential parameters you can use, they all start with a few essential components that define the view and its fields.

view and sql_table_name

These are the first two lines you'll typically see in a view file. The view parameter simply gives your view a name. This name will be used throughout Looker to refer to this set of fields.

The sql_table_name parameter tells Looker which specific table (and schema, if necessary) to query in your connected database. This creates the direct link between your LookML object and your raw data table.

view: users {
  sql_table_name: `public.users` ,,
}

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

dimension

Dimensions are the bread and butter of your analysis. They represent a single, groupable field from your data table - essentially, a column you can use to slice and dice your data. Dimensions describe your data.

Examples of dimensions include:

• A user ID
• A product name
• An order status
• A country or city
• A signup date

In a View file, you define each dimension and can customize its type, a user-friendly label, its description, and much more. The simplest dimension definition just points to a column in your table.

dimension: id {
  primary_key: yes
  type: number
  sql: ${TABLE}.id ,,
}

dimension: city {
  type: string
  sql: ${TABLE}.city ,,
}

dimension: status {
  type: string
  sql: ${TABLE}.status ,,
}

Notice the ${TABLE}.column_name syntax. This is Looker's substitution operator, which dynamically references the table and column from your database.

Dimension Groups for Timeframes

For any date or timestamp columns, you’ll want to use a dimension_group. This is a special type of dimension that tells Looker to automatically generate multiple time-based dimensions from a single timestamp column. It's incredibly efficient.

dimension_group: created {
  type: time
  timeframes: [
    raw,
    time,
    date,
    week,
    month,
    quarter,
    year
  ]
  sql: ${TABLE}.created_at ,,
}

With this single block of LookML, Looker creates individual dimensions like Created Date, Created Month, Created Week, etc., which users can grab directly from the Explore interface.

measure

While dimensions describe your data, measures perform calculations on it. Measures are aggregations of data across multiple rows, answering questions like "how many?" or "what is the total?". You cannot group by a measure.

Examples of measures include:

• A count of total users
• The sum of revenue
• The average order value
• The maximum price of a product sold

A measure is defined by its type (like count, sum, average) and the dimension or SQL expression it operates on.

measure: count {
  type: count
}

measure: total_order_value {
  type: sum
  sql: ${order_value} ,,
  value_format_name: usd
}

The key difference to remember is simple: dimensions are columns you group by (User Status, Created Date, Country), while measures are the numbers you calculate for those groups (Count of Users, Total Sales, Average Session time).

Types of Views in Looker

While most views link directly to a database table, Looker also allows for more complex "derived" views when the data you need doesn't exist in a single, clean table.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Table-Based Views

This is the most common and straightforward type of view. It maps one-to-one with a physical table in your database. When you first connect Looker to your database, it can even auto-generate basic view files for every table in a schema, giving you a massive head start on your project.

Derived Views (Derived Tables)

A derived view (or derived table) is a view based on a query you define, rather than a direct table in your database. You create a derived table when you need to transform or pre-aggregate data before users can analyze it. For instance, you might want to create a table of daily aggregated sales or a table of user lifetime value that requires complex joins and logic.

There are two primary ways to create them:

1. SQL-Based Derived Tables

You write the raw SQL query that defines the table structure directly within your view file. Looker then runs this query against your database when users explore the data.

view: user_order_facts {
  derived_table: {
    sql: SELECT
        user_id,
        MIN(orders.created_at) as first_order_date,
        COUNT(DISTINCT orders.id) as total_orders
      FROM public.orders
      GROUP BY 1
      ,,
  }

  dimension: user_id { ... }
  dimension: total_orders { ... }
}

2. Native Derived Tables (NDTs)

Native Derived Tables allow you to define a derived table using LookML instead of raw SQL. You structure your query using LookML parameters, referencing other existing Looker views and fields. This makes NDTs more reusable and easier to debug, as Looker writes the optimized SQL for your specific database dialect on the fly.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Putting It All Together: A Simple ‘Orders’ View Example

Let's imagine you have a raw orders table in your database. Here is what a simple but complete orders.view file might look like, combining all the components we've discussed so far.

The goal is to turn the raw columns into useful, business-friendly fields.

view: orders {
  # This tells Looker which database table to query
  sql_table_name: `public.orders` ,,

  # ---- DIMENSIONS ----

  # The primary key for the orders table
  dimension: order_id {
    primary_key: yes
    type: string
    sql: ${TABLE}.id ,,
  }

  # The ID of the user who placed the order
  dimension: user_id {
    type: number
    # This creates a link to the users view, enabling joins
    foreign_key: users.id
    sql: ${TABLE}.user_id ,,
  }

  dimension: status {
    type: string
    sql: ${TABLE}.status ,,
  }

  # Creates multiple dimensions (date, week, month, etc.) from the created_at column
  dimension: created {
    type: time
    timeframes: [
      raw,
      time,
      date,
      week,
      month,
      quarter,
      year
    ]
    sql: ${TABLE}.created_at ,,
  }

  # The dollar value of the order
  dimension: order_value {
    type: number
    label: "Order Value"
    sql: ${TABLE}.order_total_usd ,,
  }

  # ---- MEASURES ----

  # A simple count of all a.k.a the Total Number of Orders
  measure: count {
    type: count
  }

  # A measure that calculates the total revenue by summing up the order_value dimension defined above
  measure: total_revenue {
    type: sum
    label: "Total Revenue"
    sql: ${order_value} ,,
    value_format_name: usd_0 # Formats the number as a rounded US dollar
  }

  measure: average_order_value {
    type: average
    label: "Average Order Value (AOV)"
    sql: ${order_value} ,,
    value_format_name: usd # Formats as US Dollars with two decimal places
  }
}

Why Views are So Important

Understanding and building high-quality views is the most leveraged skill in Looker development. Properly defined views are what transform Looker from a simple data viewer into a true business intelligence platform.

• Abstraction: Views hide the raw, messy SQL from your business users. Instead of writing COUNT(DISTINCT CASE WHEN status = 'complete' THEN id ELSE NULL END), a user just has to pick the "Count of Complete Orders" measure.
• Reusability (DRY Principle): You can define a view once and reuse it across multiple Explores and dashboards. This "Don't Repeat Yourself" approach saves enormous amounts of time.
• Governance & Consistency: Views establish a single source of truth for your business metrics. Everyone in the company who wants to know the "Total Revenue" will be using the exact same calculation, because it’s centrally defined in the orders view. This eliminates the classic problem of two teams showing up with different numbers for the same metric.
• Maintainability: If your database schema changes or a business definition is updated, you only need to edit it in one place - the view file. That change automatically populates to every report and dashboard that uses that field.

Final Thoughts

In short, Looker Views are the powerful, foundational layers that connect your raw database tables to your end-users. They transform raw data columns into a reusable library of business-friendly dimensions and measures, creating a reliable, single source of truth for your entire organization's reporting and analysis.

The Looker modeling layer is what differentiates it from so many other BI tools, but mastering LookML takes time and often relies on a dedicated data team. For marketing and sales teams who need to answer questions now, we created an easier path. Graphed connects directly to your platforms like Google Analytics, Shopify, Salesforce, and Facebook Ads, letting you create dashboards and get insights just by asking questions in plain English. There’s no modeling language to learn, giving you direct access to the answers you need in seconds.