Looker LookML developerProprietary

learning journey
+ Confidential

2. Data Modeling Using LookML

Anatomy of a
LookML project

Lesson 06

To prepare yourself for writing LookML code, there are some key terms and overall
project structure that you need to know.

Let’s begin with an easy one - what does the “ML” in LookML stand for?
 What is LookML?
Proprietary + Confidential

Examples are based on fictional data.

LookML stands for Looker Modeling Language. It is Looker’s proprietary language

that establishes an abstraction layer for SQL. Developers use LookML to tell Looker
what data to use from the connected database and how it should interpret that data.

Specifically, LookML acts as the modeling layer between the connected SQL
database and your business users. Looker uses the LookML code written by
developers to define how business users interact with a connected database and to
construct SQL queries against that particular database.
 SQL and LookML
Proprietary + Confidential

Examples are based on fictional data.

Developers use LookML to define many items from the connected SQL database
including data attributes called dimensions, aggregates of dimensions called
measures, data relationships such as how to join tables, and custom tables and fields.

A key concept of LookML to remember is: If it’s possible in your SQL dialect, it should
be possible in Looker. If you can go to your database console and hand-write a
SELECT statement that does something in the database, you can also code LookML
that Looker can use to accomplish the same task.
 Hierarchy overview
Proprietary + Confidential

Hierarchy of
LookML objects

For full comprehension of the key LookML terms, developers need to understand
where each object fits into the overall hierarchy of a LookML project.
 Project-level
Proprietary + Confidential

Hierarchy of
LookML objects

Project Git repository

The highest level is the LookML project itself, which is a library of self-contained
LookML code. Because Looker uses Git for version control, a best practice is for
each project to map one-to-one with a dedicated Git repository.
 LookML projects in the UI
Proprietary + Confidential

Examples are based on fictional data.

A project is essentially a library of code for a specific data source or database

connection and contains one or more data models. You can think of each project as
an semi-independent or mini-instance of Looker, and each project should map
one-to-one to a Git repository for version control.

Data that cannot be joined together should be separated into different projects
because there is no relation to be made across the data.
 Model-level
Proprietary + Confidential

Hierarchy of
LookML objects

Git repository
Model

The next level in the hierarchy are models. As previously mentioned, a LookML
project is composed of one or more models.

A model specifies a database connection and the data views that utilize that
connection.
 LookML
Proprietary + model
Confidential files

Examples are based on fictional data.

Specifically, a model file is used to define:

● the database connection,

● the view files that are accessible to this model,
● and the Explores (which are pre-joined views) and their join logic.

Models can also be used to separate and organize Explores by business area.
 Explore-level
Proprietary + Confidential

Hierarchy of
LookML objects

Git repository
Explore

Next on the hierarchy are Explores, which are sets of pre-joined views organized by
business area defined within the model files.

For example, you might create a model file containing multiple Explores pertaining to
customer purchases.
 Explores in the UI
Proprietary + Confidential

Examples are based on fictional data.

Explores are the central component of Looker that allow business and data analysts
to conduct self-serve data exploration, analysis, and visualization.

Within a model file, developers define Explores that join one or more views together
to target specific questions that business users may have. Business users then use
the predefined Explores to run queries and create reports and visualizations to
answer their questions.

So you can think of an Explore as a predefined set of tables that would frequently be
joined for business inquiries and use cases.
 View-level
Proprietary + Confidential

Hierarchy of
LookML objects

Git repository
View

Next, the views that are joined in the Explores represent the underlying database
tables.
 LookML view files
Proprietary + Confidential

Examples are based on fictional data.

Views are the building blocks of Explores used by business users.

Within view files, developers can define the dimensions (or data attributes) and
measures (or aggregations of attributes) to provide to business users in the Explore
interface.

The view names that are joined to create an Explore are also the headers that
business users see in the Explore. For example, in an Explore called Order Items,
business users may see the Users view, which contains dimensions on users, such
as their age and city of residence, and measures, such as their total purchases.
 Dimensions and
Proprietary measures
+ Confidential

Hierarchy of
LookML objects

Dimensions Git repository

View
Measures

Last, but not least on the hierarchy, are the dimensions and measures defined in the
view files.
 The SQL of +dimensions
Proprietary Confidential

Examples are based on fictional data.

Dimensions are data attributes and represent the fields or column of a database table.

When the view files are generated from a table by Looker, dimensions are
automatically created for any columns that already exist within your database tables.
You can also create additional dimensions that would serve as logical representations
of table columns.

All dimensions appear in the SELECT and GROUP BY clause of a SQL statement that
is generated by Looker based on the business user’s selections in the Explore.
 The SQL of
Proprietary measures
+ Confidential

Examples are based on fictional data.

Measures are aggregates of dimensions and do not live explicitly in your database
tables. They must be created using LookML. They aggregate dimensions into values
like sums or counts.

Note that they do not appear in the GROUP BY statement of the SQL generated by
Looker. Instead, they depend on dimensions to determine that grouping, so they
appear as aggregate functions in the SELECT statement of the SQL query.
 Project Proprietary
maps+ Confidential
to Git repo

Hierarchy of
Project
Model LookML objects
Explore
View

Dimensions: Git repository

attributes
Measures:
aggregations

To recap, a LookML project is a library of code that models a data source and should
map 1:1 to a Git repository for version control.
 Models Proprietary
contain Explores
+ Confidential

Hierarchy of
Project
Model LookML objects
Explore
View

Dimensions: Git repository

attributes
Measures:
aggregations

Projects contain model files, which define the Explores that should be packaged
together, how those Explores work, and which views are joined in which Explores.
 Explores expose
Proprietary + Confidentialviews

Hierarchy of
Project
Model LookML objects
Explore
View

Dimensions: Git repository

attributes
Measures:
aggregations

View files describe database tables or logical representations of them and are joined
together to define Explores in the model files.

Views are then accessed by business users through the Explore to query data and
create reports and visualizations.
 Explores expose
Proprietary + Confidentialviews

Hierarchy of
Project
Model LookML objects
Explore
View

Dimensions: Git repository

attributes
Measures:
aggregations

Dimensions and measures are defined within view files. Dimensions are attributes of
data and represent fields or columns in the database tables, while measures are
aggregates of dimensions such as a COUNT or SUM.

After this introduction to the LookML key terms and hierarchy, you are now ready to
start exploring your organization’s Looker instance as a LookML developer.
 Looker LookML developerProprietary
learning journey
+ Confidential

2. Data Modeling Using LookML

Modeling
dimensions

Lesson 07

In Looker, dimensions are qualities or attributes of your data. Typically, each

dimension represents a column in your underlying database.

If you use Looker to generate your model files from a data source, your model’s view
files will already contain a dimension for each column in the database tables. In the
view files, you can also define custom dimensions using LookML.

Let’s dive into modeling dimensions within view files, so that you can create new ones
or modify existing ones using LookML.
 Referencing
Proprietary + Confidentialtables

Modeling dimensions

dimension: first_name {
type: string
sql: ${TABLE}.first_name ;;
}

Examples are based on fictional data.

When Looker generates a new view file from a table, it automatically creates
dimensions for every column (or field) in the database table.

Auto-generated dimensions have a sql parameter containing the word TABLE

highlighted in blue, with a dollar sign and curly braces, such as:
sql: ${TABLE}.first_name

${TABLE} references the table specified in the sql_table_name parameter at the

top of your view file. This lets Looker know which database table to use as the default
table when pulling the dimensions and measures.
 Referencing LookML
Proprietary objects
+ Confidential

Modeling dimensions

dimension: full_name {
type: string
sql: concat(${first_name}, "
",
${last_name}) ;;
}

Examples are based on fictional data.

Another version of the substitution syntax is using an existing dimension or measure

name within curly braces, preceded by a dollar sign, such as:
sql: ${field_name}

When defining new dimensions that build on existing ones, it is a best practice to use
the ${field_name} substitution operator instead of the ${TABLE} reference, so
that you can reduce the instances of hard-coding columns names in your code.

In this example, the syntax references existing LookML objects called first_name and
last_name to build a new dimension called full_name.

Referencing the Looker object is better than the hard-coded database column, so that
the new field inherits any transformations or additional logic from the overall
dimension. It also reduces the number of times or places you’ll need to make updates
if something like the database column name changes.
 Dimension
Proprietarytype - string
+ Confidential

Modeling dimensions
dimension: first_name {
type: string
sql: ${TABLE}.first_name ;;
}

dimension: full_name {
type: string
sql: concat(${first_name}, " ",
${last_name}) ;;
}
Examples are based on fictional data.

In Looker, there are four common dimension types. The first one is string.

String is the LookML term for what in your database dialect could be varchar, char,
text… or simply string! It is used for text values, such as a name, and is the default
dimension type in Looker.

This example shows how a new string dimension called full_name can be created
from concatenating two existing string dimensions, first_name and last_name.
 Dimension type
Proprietary - number
+ Confidential

Modeling dimensions
dimension: age {
type: number
sql: ${TABLE}.age ;;
}

dimension: days_since_signup {
type: number
sql: DATE_DIFF(current_date(),
${created_date}, day) ;;
}
Examples are based on fictional data.

The next common dimension type is number. Number type fields are used for
columns of numeric data types such as int, decimal, or float.

You should also use the number type to define new dimensions whenever you will use
it to store mathematical computations like addition or subtraction.

For example, a common use case for number is date difference logic, such as the
one seen in this example which calculates the number of days since a user signed up
on a platform.
 Dimension
Proprietarytype - yesno
+ Confidential

Modeling dimensions

dimension: is_new_customer {
type: yesno
sql: ${days_since_signup} <= 90 ;;
}

Examples are based on fictional data.

The third common dimension type is the yesno field type, which is a Boolean.

It produces a “Yes” value if the condition entered in the sql parameter is met. If the
condition is not met, then it produces a “No” value.

An example use case for yesno field types would be to label “new” users who have
only been users on a platform for a specific length of time, such as 90 days or fewer.
 Dimension type - tier
Proprietary + Confidential

Modeling dimensions

dimension: days_since_signup_tier {
type: tier
sql: ${days_since_signup} ;;
tiers: [0, 30, 90, 180, 360, 720]
style: integer
}

Examples are based on fictional data.

The last common dimension type are Tier dimensions, which are useful for bucketing
values.

When defining a new tier dimension, you need to use the tiers parameter to
indicate which buckets you want to assign.

Each comma-separated number will be the start of a range. For example, a 0 followed
by 30 means that there is a first bin containing the values from 0 to 29, followed by a
second bin beginning at 30, and so on.

There is also a style parameter where you can specify how you want the results to
be formatted for business users, such as integer to display the bin range as whole
numbers or relational to display a text expressions that include symbols such as
less than (<) or greater than (>). To learn more about the various style options, refer
to the Looker docs on styles for tier dimensions.
 Dimension groups
Proprietary + Confidential- time

Modeling dimensions

dimension: days_since_signup_tier {
type: tier
sql: ${days_since_signup} ;;
tiers: [0, 30, 90, 180, 360, 720]
style: integer
}

Examples are based on fictional data.

Less commonly used but still very useful is the dimension group of type time.

For these dimension groups, you use the timeframes parameter to specify the date
and time parts required for the data. There are many options for the timeframe, such
as hour, day_of_week, month, quarter, or year.

The number of dimension fields created within a dimension group is dependent on the
number of timeframes listed in the timeframes parameter. For example, including
only date, hour, month, and year will result in only these four dimension fields
created as part of the dimension group called “created”.

When generating new view files from tables, Looker will automatically create
dimension groups for most date and time columns; though, it is possible for some
formats to not be automatically recognized by Looker.
 Define other LookML
Proprietary objects
+ Confidential

Modeling dimensions

dimension: shipping_days {
type: number
sql: DATE_DIFF(${shipped_date},
${created_date}, DAY) ;;
}

Examples are based on fictional data.

When using an existing dimension group timeframe to define another dimension—for

example, in a dimension performing a DATE_DIFF() or difference between two
dates—you can specify the desired date or time unit to identify the date field from the
dimension group called “created”.

To do this, simply append the date or time unit to the name of the dimension group
using an underscore, such as ${created_date} to specify that you want the date
field from the dimension group called created.

In this example, a new dimension named shipping_days is created based on the

difference between the ${shipped_date} and the ${created_date} in number
of days.
 Dimension Proprietary
groups - duration
+ Confidential

Modeling dimensions

dimension_group: enrolled {
type: duration
intervals: [second, minute, hour,
day, week, month, quarter, year]
sql_start: ${TABLE}.enrollment_date ;;
sql_end: ${TABLE}.graduation_date ;;
}

Examples are based on fictional data.

Another dimension group type that is not as commonly used and can be quite helpful
is the dimension group of type duration.

Using the intervals parameter, you can allow business users to choose from a
range of time intervals.

When possible, a best practice is to create dimension groups of type duration

instead of defining dimensions that perform DATE_DIFF() functions in the sql
parameter. This allows you to avoid hard-coding the date part, so your business users
can choose what works best for them.

Additionally, this prompts Looker to write the function for you, which is easier if you’re
not as comfortable with SQL, and it will create less work for you in the future, in case
your company ever decides to change the underlying data source.
 Intervals
Proprietary + Confidential

Modeling dimensions

dimension_group: enrolled {
type: duration
intervals: [second, minute, hour,
day, week, month, quarter, year]
sql_start: ${TABLE}.enrollment_date ;;
sql_end: ${TABLE}.graduation_date ;;
}

To reference one of these fields, use

${hours_enrolled}, ${days_enrolled},
${years_enrolled}, etc.

Examples are based on fictional data.

Similar to timeframes, the number of dimension fields created for a dimension group
of type duration depends on the number of intervals provided in the intervals
parameter.

To use a dimension group interval to define another dimension, you need to write the
desired interval before the dimension group name itself, like ${hours_enrolled} or
${days_enrolled}.
 Lesson summary
Proprietary + Confidential

Modeling dimensions

dimension_group: enrolled {
type: duration
intervals: [second, minute, hour,
day, week, month, quarter, year]
sql_start: ${TABLE}.enrollment_date ;;
sql_end: ${TABLE}.graduation_date ;;
}

Examples are based on fictional data.

In conclusion, there are many dimension types in Looker including string, number,
yesno, tier, and dimension groups for time and duration.

When referencing a column from a database table for the first time in a LookML
model, use ${TABLE}.

When defining new dimensions that build on existing ones, you can reduce the
instances of hard-coding column names by using the ${field_name} substitution
operator to reference the existing LookML object.

After this introduction to modeling dimensions, you are now ready to start curating
dimensions in your organization’s Looker instance!
 Example walkthrough
Proprietary + Confidential

Creating dimensions
using LookML
Define a new dimension for full name by
combining the existing dimensions for
first name and last name.

Examples are based on fictional data.

As a LookML developer, you can modify existing dimensions and define new new
ones as needed for your business users.

For example, imagine you are working with marketing business users. They
appreciate that they can see the first name and last name of each user in the Order
Items Explore, but they have asked if you can create a single dimension that contains
the users’ full names.

Let’s walk through an example to see how you can create a new dimension for full
name by combining existing dimensions for first name and last name in the Users
view file.
 Example walkthrough
Proprietary + Confidential 2

Examples are based on fictional data.

To begin, enable Development Mode by toggling the button for Development Mode on
the bottom left corner of the Looker home page.

Then, click Develop on the left side navigation menu to see the develop options.
 Example walkthrough
Proprietary + Confidential 3

Examples are based on fictional data.

Within the Develop options, click on Projects.

 Example walkthrough
Proprietary + Confidential 4

Examples are based on fictional data.

Click on the training_ecommerce project under Project.

 Example walkthrough
Proprietary + Confidential 5

Examples are based on fictional data.

In the file browser, navigate to the users.view file in the training_ecommerce

project.
 Example walkthrough
Proprietary + Confidential 6

Examples are based on fictional data.

To make a new dimension to represent a user’s full name, scroll down to find the
last_name dimension.

Then, add a new blank line to make space for the new dimension.
 Example walkthrough
Proprietary + Confidential 7

Examples are based on fictional data.

Now, using the same indentation as the existing dimensions, start typing the word
dimension.

Notice that as you write code, the Looker IDE will check your syntax and make
suggestions in real time.
 Example walkthrough
Proprietary + Confidential 8

Examples are based on fictional data.

Enter a colon (:) after the word dimension. You will see two curly braces appear.

Be sure to leave these curly braces. You will add code within these curly braces to tell
Looker how this dimension should be defined.
 Example walkthrough
Proprietary + Confidential 9

Examples are based on fictional data.

After the colon following the word dimension, but before the curly braces, you need
to provide a name for the new dimension.

We recommend using all lowercase letters because LookML is case-sensitive. For

names containing multiple words, we recommend using underscores to represent
spaces between words.

For example, full_name would work well as the name for the new dimension that
combines first_name and last_name.
 ExampleProprietary
walkthrough
+ Confidential 10

Examples are based on fictional data.

Next, between the curly braces on the following line, define the type of dimension you
want with the keyword type, followed by a colon (:).

Now, because you are combining two other string dimensions (first_name and
last_name) to create this new dimension, you would choose the dimension type
string.
 Example walkthrough
Proprietary + Confidential 11

Examples are based on fictional data.

On another new line between the curly braces, add the sql parameter by typing sql,
followed by a colon (:).

Just like before, Looker will suggest options and add syntax, such as the two
auto-generated semicolons (;;) at the end of the sql parameter.

Be sure to leave these semicolons, as this syntax is how Looker knows where the
SQL expression ends for a given field.
 Example walkthrough
Proprietary + Confidential 12

Examples are based on fictional data.

For the SQL, there are two options to select existing dimensions such as first_name.

The first way that we can specify first_name is to type ${TABLE}.first_name.

This substitution syntax hard-codes the first_name column in the database and will
plug in the view’s sql_table_name at runtime.
 Example walkthrough
Proprietary + Confidential 13

Examples are based on fictional data.

However, because there is an existing dimension in our view file, it is a best practice
to use ${first_name} for the sql parameter, so we can reference the existing
LookML dimension.

So you can replace ${TABLE}.first_name with ${first_name}.

 Example walkthrough
Proprietary + Confidential 14

,
,

Examples are based on fictional data.

To finish the SQL statement, you need to combine first_name and last_name. To do
this, you can use the SQL function CONCAT.

It’s important to note that anything you write in the sql parameter needs to be valid
for your database dialect.

So for this example that uses data in BigQuery, start the SQL expression with
concat, followed by an open set of parentheses (). Within the parentheses, include
the first_name dimension, followed by a comma. Then, include an empty space
within double quotes (“ ”), followed by another comma and then the last_name
dimension.

Notice again that you are referencing the existing dimension names, so the final code
for the sql parameter is: concat(${first_name}, “ ”, ${last_name})
 Example walkthrough
Proprietary + Confidential 15

,
,

Examples are based on fictional data.

Now, click Save Changes.

 Example walkthrough
Proprietary + Confidential 16

Examples are based on fictional data.

Then, click Validate LookML to check that you have written valid LookML to define
your new dimension.
 Example walkthrough
Proprietary + Confidential 17

Examples are based on fictional data.

If you have the permissions to make changes to production, you will see a button to
commit changes and push to production.

For now, know that while you can choose to commit and push the changes after
validating the LookML, it is always a good idea to review your changes in the Explore
first.
 Example walkthrough
Proprietary + Confidential 18

Examples are based on fictional data.

Within the Explore tab, click on Order Items to pull up the Explore.

When developing LookML, we recommend keeping one tab open on the Explore, so
you can switch to it, refresh, and quickly validate what you’ve just built.
 Example walkthrough
Proprietary + Confidential 19

Examples are based on fictional data.

Notice that Full Name is now a new dimension under Users. You can select Full
Name along with First Name and Last Name, and click Run to see the results.
 ExampleProprietary
walkthrough
+ Confidential 20

Examples are based on fictional data.

Congratulations - you have successfully defined and tested a new dimension in

Looker!
 Looker LookML developerProprietary
learning journey
+ Confidential

2. Data Modeling Using LookML

Modeling
measures

Lesson 08

In Looker, dimensions represent the data attributes in a database table, whereas

measures are ways to perform aggregate functions, such as a count, on the
dimensions.

In this section, we will focus on how you can define measures within view files to
curate various types of aggregations using LookML.
 Defining measures
Proprietary + Confidential

Modeling measures

measure: name_of_measure {
type: measure_type
sql: ${field_name} ;;
}

Examples are based on fictional data.

Whenever you define new dimensions and measures that build on existing ones, it is
a best practice in Looker to use ${field_name} to reference existing LookML
objects.

Since measures aggregate dimensions, it makes sense that definitions of new

measures use this syntax to reference existing dimensions, rather than hard-coding
the underlying column name.

Specifically, the LookML code for a measure points to one or more existing
dimensions in the sql parameter and then defines a way to aggregate them in the
type parameter.
 Measure type - sum
Proprietary + Confidential

Modeling measures
dimension: sale_price {
type: number
sql: ${TABLE}.sale_price ;;
}

measure: total_revenue {
type: average
sql: ${sale_price} ;;
}

Examples are based on fictional data.

There are three common types of measures in Looker. The first type is sum.

As it sounds, sum aggregates the values in a specified dimension by adding all values
together to calculate a total value.

In this example, a new sum measure called total_revenue is defined, based on the
existing dimension called sale_price. The final result is a measure that provides the
total of the values in the sale_price dimension.
 Measure - average
type+ Confidential
Proprietary

Modeling measures
dimension: sale_price {
type: number
sql: ${TABLE}.sale_price ;;
}

measure: average_sale_price {
type: average
sql: ${sale_price} ;;
}

Examples are based on fictional data.

The second type of measure is average. This measure delivers its namesake, in
other words, the mean value of the specified dimension.

In this example, a new average measure called average_sale_price is defined and

uses the same existing dimension (sale_price) as the previously created sum
measure.

In this case, Looker knows that the new measure called average_sale_price is an
average and not a sum because the measure type is set to average. This results in a
measure that provides the average of the values in the sale_price dimension.
 Measure type
Proprietary - count
+ Confidential

Modeling measures

measure: count_items_ordered {
type: count
}

Examples are based on fictional data.

The last type of measure is count. Unlike the sum and average measures, count
measures do not require the sql parameter by default.

For instance, if you use Looker to generate your model files from a data source, your
model’s view files will already contain a default measure for the count of rows. This
count does not use the sql parameter; instead, it will simply use the view’s primary
key as the dimension to aggregate.

In this example, the default count measure would provide a count of the
order_item_id, which is the primary key of the view.
 - count_distinct
Measure type Proprietary + Confidential

Modeling measures

measure: count_items_ordered {
type: count
}

measure: count_users {
type: count_distinct
sql: ${user_id} ;;
}

Examples are based on fictional data.

If you want to count something other than the view’s primary key, you need to use the
measure type called count_distinct. This type does allow you to input a sql
parameter for the dimension you want to count.

In the second example, the count_distinct uses the ${user_id} dimension to

calculate the count of unique users.
 Modeling measures summary
Proprietary + Confidential

Modeling dimensions

measure: name_of_measure {
type: measure_type
sql: ${field_name} ;;
}

Examples are based on fictional data.

In summary, there are three primary measure types in Looker including sum,
average, and count.

To define a new measure, use the sql parameter to specify which dimensions you
want to aggregate, and then define a way to aggregate them using the type
parameter.

And that’s it! Hope you are excited to start creating new measures in your
organization’s Looker instance!
 Example walkthrough
Proprietary + Confidential

Modeling measures
using LookML
example walkthrough Calculate the total dollar amount of
all ordered items.

Examples are based on fictional data.

In Looker, you can define measures to aggregate dimensions in your data such as
getting a count or average.

For this example, imagine that your view already contains a dimension for sale price
for ordered items, and you want to use it to calculate the total dollar amount of all
ordered items. What kind of measure do you need to create?

The keyword total tells you that you need to create a measure of type sum.

Let’s see how easy it is to create a new measure to calculate a total of all sale prices
for ordered items.
 Example walkthrough
Proprietary + Confidential 2

Examples are based on fictional data.

To begin, enable Development Mode by toggling the button for Development Mode on
the bottom left corner of the Looker home page.

Then, click Develop on the left side navigation menu to see the develop options.
 Example walkthrough
Proprietary + Confidential 3

Examples are based on fictional data.

Within the Develop options, click on Projects.

 Example walkthrough
Proprietary + Confidential 4

Examples are based on fictional data.

Click on the training_ecommerce project under Project.

 Example walkthrough
Proprietary + Confidential 5

Examples are based on fictional data.

In the file browser, navigate to the order_items.view file in the training_ecommerce

project.
 Example walkthrough
Proprietary + Confidential 6

Examples are based on fictional data.

To make a new measure for total sales, scroll down to the last dimension in the
order_items.view, and add a new blank line under the last dimension.

This supports readability of the view file, as all measures will be defined after the
dimensions in the view.
 Example walkthrough
Proprietary + Confidential 7

Examples are based on fictional data.

Now, using the same indentation as the existing dimensions, start typing the word
measure.

Notice that as you write code, the Looker IDE will check your syntax and make
suggestions in real time.
 Example walkthrough
Proprietary + Confidential 8

Examples are based on fictional data.

Now, enter a colon (:) after the word “measure”. You will see two curly braces appear.

In the next steps, you will add code within these curly braces to tell Looker how this
measure should be defined.
 Example walkthrough
Proprietary + Confidential 9

Examples are based on fictional data.

Add a name for the new measure after the colon, following the word measure but
before the curly braces.

Similar to naming other LookML objects, we recommend using all lowercase letters
and using underscores to represent spaces between words.

In this case, “total_sales” would work well as the name of the new measure that you
are creating for the total dollar amount of all ordered items.
 ExampleProprietary
walkthrough
+ Confidential 10

Examples are based on fictional data.

Next, between the curly braces on the following line, define the type of measure you
want with the keyword type, followed by a colon (:).

Now because you are calculating a total, you would choose the measure type sum.
 Example walkthrough
Proprietary + Confidential 11

Examples are based on fictional data.

On another new line between the curly braces, add the sql parameter by typing sql,
followed by a colon (:).

Notice that Looker adds two auto-generated semicolons (;;) at the end of the sql
parameter. Similar to defining dimensions, you need to add the desired SQL before
these two auto-generated semicolons (;;), so that Looker knows where the sql
parameter ends.

In this case, you can use the syntax to identify an existing dimension called
sale_price by typing: ${sale_price}.

The sql parameter combined with the type sum will result in a new measure that is
the sum of all values in the sale_price dimension.
 Example walkthrough
Proprietary + Confidential 12

Examples are based on fictional data.

Last, specify a format for the measure using the value_format_name parameter
and the parameter value usd_0, which represents the currency format ($) used in the
United States, rounding to the nearest dollar.
 Example walkthrough
Proprietary + Confidential 13

Examples are based on fictional data.

Now, click Save Changes.

 Example walkthrough
Proprietary + Confidential 14

Examples are based on fictional data.

Then, click Validate LookML to check that you have written valid LookML to define
your new measure.
 Example walkthrough
Proprietary + Confidential 15

Examples are based on fictional data.

At this point, you could commit your changes, but you should test your new measure
locally to ensure it works as intended for your end users.
 Example walkthrough
Proprietary + Confidential 16

Examples are based on fictional data.

Within the Explore click on Order Items under E-Commerce Training to pull up the
Explore.
 Example walkthrough
Proprietary + Confidential 17

Examples are based on fictional data.

Notice that Total Sales is now a new measure under Order Items. You can select
Total Sales, and click Run to see the results.
 Example walkthrough
Proprietary + Confidential 18

Examples are based on fictional data.

And with that, you have now defined and tested a new measure in Looker! Pretty
easy, right?
 Looker LookML developerProprietary
learning journey
+ Confidential

2. Data Modeling Using LookML

Dimension + measure
modeling logic

Lesson 09

LookML provides advanced logic options that you can use when you define
dimensions and measures.

Let’s review some of these options, so that you can further customize dimensions and
measures to curate data experiences for your business users.
 Referencing
Proprietary + Confidentialfields

Referencing fields in
other view files

dimension: profit {
type: number
value_format_name: usd
sql: ${sale_price} -
${inventory_items.cost} ;;
}

Examples are based on fictional data.

As you may know, in LookML, you can use the syntax ${field_name} to reference
existing dimensions and measures within the current view file.

Additionally, you can also reference dimensions and measures from other view files
by fully identifying them, just as you would in SQL.

To do this, you simply write the view name and a period before the field name, all
within the curly braces following a dollar sign, such as:
${inventory_items.cost}.

Keep in mind, though, that in order for this syntax to work correctly, the two views
involved need to be joined together in an Explore. In this example, the current view
containing the sale_price dimension would need to be joined with the
inventory_items view in an Explore.
 DefiningProprietary
other measures
+ Confidential

Using measures to define

others measures

measure: percentage_usa_users {
type: number
value_format_name: percent_1
sql: 1.0*${count_usa_users}
/NULLIF(${count}, 0) ;;
}

Examples are based on fictional data.

Now, just as you can reference existing dimensions when creating new measures,
you can also reference previously-modeled measures when defining a new measure.

For example, your new measure could include multiple measures interacting with
each other, such as calculating the percentage of users located in a specific country,
out of the total number of users.

Please remember though that whenever you want to include other measures in the
sql parameter of a new measure, you need to use the measure type called
number.
 Filtered measures
Proprietary + Confidential

Use dimensions to
define filters

measure: count_usa_users {
type: count
filters: [country: "USA"]
}

Examples are based on fictional data.

Last, a useful parameter for defining measures is the filters parameter, which you
can use to create measures based on specific dimension values.

In this example, the filter is based on the value “USA” in the country dimension. The
count is completed using the primary key of the view, which in this case is user_id for
the users view.

The resulting measure is a count of user ids with a country value equal to “USA”.

Take note though that although the filters parameter does not use the familiar
substitution syntax of ${field_name}, the field names still actually refer to existing
LookML dimensions, not the literal database column names.
 Filtered measures - yesno
Proprietary + Confidential

Use dimensions to
define filters
measure: count_usa_users {
type: count
filters: [country: "USA"]
}

measure: total_sales_new_users {
type: sum
sql: ${sale_price} ;;
filters: [users.is_new_user: "Yes”]
}
Examples are based on fictional data.

However, in this second example, the filter is based on an existing yesno dimension
named is_new_user. Only rows that return a value of “Yes” for this dimension are
summed across the sales_price dimension for a sum of sales to only new users.

Both of these examples would generate a CASE statement (in other words,
if/then/else) within the aggregate function of the SQL query.
 Lesson summary
Proprietary + Confidential

Dimension + measure
modeling logic
dimension: profit {
type: number
value_format_name: usd
sql: ${sale_price} -
${inventory_items.cost} ;;
}

measure: percentage_usa_users {
type: number
value_format_name: percent_1
sql: 1.0*${count_usa_users}
/NULLIF(${count}, 0) ;;
}

measure: count_usa_users {
type: count
filters: [country: "USA"]
}

Examples are based on fictional data.

In summary, LookML provides several options for advanced logic when defining
custom dimensions and measures.

As demonstrated through these examples, you can reference fields in other views,
use measures to define other measures, and use dimensions to filter measures.

You should find these advanced logic options useful, as you gain more experience
with curating dimensions and measures for your business users.
 Looker LookML developerProprietary
learning journey
+ Confidential

2. Data Modeling Using LookML

LookML
dashboards

Lesson 10

This final lesson picks up near the conclusion of a relatively realistic scenario
involving a number of employees of a company who are working together to answer a
data-related question.
 WhatProprietary
is a dashboard?
+ Confidential

Examples are based on fictional data.

A Looker dashboard is a collection of queries displayed as visualizations on a page.

Dashboards let you combine key queries and visualizations into a one page executive
view.

You can add filters to make the dashboard interactive and rearrange its tiles. You can
create as many dashboards as you want, so you can tailor each dashboard to the
specific needs of the people who use it.
 Different types of +dashboards
Proprietary Confidential

User-defined vs LookML

Characteristic User-defined dashboard LookML dashboard

Generally created and edited by business users and Looker developers a select group of LookML developers
Defined by picking query tiles in the user interface, written and edited in a YAML-based
arranging them using drag-and-drop dashboard file
operations, and choosing dashboard settings
Updated when the dashboard is edited or the when the LookML file for the dashboard is
corresponding saved Looks are updated edited
Stored in a user’s personal folder or a shared folder as version-controlled files associated with the
for easy collaboration across a wider group of project in a Git repository
users
Convertible to a LookML dashboard a user-defined dashboard

Examples are based on fictional data.

Depending on the type of user, Looker provides the capability of creating two different
types of dashboards: user-defined, or LookML dashboards.

User-defined dashboards are the ones data viewer and data explorer end users
create, modify and otherwise generally work with, stored locally in the Looker
instance. LookML dashboards, however, are modeled by LookML developers using
LookML and live in a code storage with version control system, like GitHub.

One of the powerful features of Looker offers for user-defined dashboards to be

dynamically converted to user-defined dashboards, and LookML dashboards to be
dynamically converted to user-defined dashboards, allowing for ultimate dashboard
flexibility in who can use what.
 Enter development
Proprietary + Confidentialmode

Examples are based on fictional data.

To create a LookML dashboard, we first need to be in Development Mode.

Begin by enabling Development Mode by toggling the button for Development Mode
on the bottom left corner of the Looker home page.

Then, click Develop on the left side navigation menu to see the develop options.
 Develop menu
Proprietary + Confidential

Examples are based on fictional data.

Within the Develop options, click on Projects.

 Project selection
Proprietary + Confidential

Examples are based on fictional data.

Click on the training_ecommerce project under Project.

 Create dashboard
Proprietary + Confidential file

Examples are based on fictional data.

In the training_ecommerce project, click vertical three-dot menu at the top of the file
browser panel in the Looker IDE and click Create Dashboard.
 Name dashboard
Proprietary + Confidential file

Examples are based on fictional data.

Give your dashboard a new name, but take note of the file extension
.dashboard.lookml. This naming convention is Looker best practices when
working with LookML dashboards.

Once your new dashboard file has a name, click on the Create button.
 Baseline
Proprietary +LookML
Confidential file

Examples are based on fictional data.

You will then be presented with the LookML dashboard version of a Hello World
coding example. This is the scaffolding of a blank LookML dashboard.

As a LookML developer, you could begin coding your own LookML into this framework
to create your new LookML dashboard. However, you could also reuse LookML from
an existing user-defined dashboard.

It’s very easy. Let’s do that.

 User-defined dash
Proprietary LookML
+ Confidential

Examples are based on fictional data.

If your Looker administrator has enabled the see_lookml permission for your
account, you can navigate to a user-defined dashboard’s underlying LookML by
selecting Go to Dashboard LookML from the dashboard’s vertical three-dot menu and
select “Get LookML”.
 View LookML
Proprietary + Confidential

Examples are based on fictional data.

When you select Get LookML, Looker generates that user-defined dashboard into its
comparable LookML code.

You can click the “Copy to Clipboard” link to grab all of this user-defined dashboard’s
LookML, or you can highlight only what you want and right-click and select “Copy”.
 Paste in Proprietary
the LookML + Confidential code

Examples are based on fictional data.

Once you paste in the LookML from the user-defined dashboard, you will edit the
LookML dashboard’s file header with the name, title, and any configuration or layout
preferences.

When the dashboard configuration is completed, you would validate, test, commit and
ultimately push it to a repository like GitHub just like you would for any other LookML
file.
 LookML dashboards
Proprietary + Confidentialfolder

Examples are based on fictional data.

But how can we accomplish the reverse: creating a user-defined dashboard from a
LookML dashboard?

From the navigation pane on the left, click on the Folders drop-down menu and
select the LookML dashboards folder.
 Choose LookML dashboard(s)
Proprietary + Confidential

Examples are based on fictional data.

On the LookML Dashboards page, tick the checkboxes on for any LookML
dashboards that you want to convert to user-defined dashboards.
 Import LookML dashboard(s)
Proprietary + Confidential

Examples are based on fictional data.

When you’ve completed your LookML dashboard selection, click on the Import button
to begin the process of deciding what parts of the LookML dashboard to pull into your
new user-defined dashboard.
 Choose
Proprietary + destination
Confidential

Examples are based on fictional data.

In the Import Dashboards pop-up, choose a folder for your new user-defined
dashboard.

Select OK to import the dashboard into the selected folder.

 New dashboard created
Proprietary + Confidential

Examples are based on fictional data.

You have have a brand new user-defined dashboard, mirroring its LookML dashboard
sibling! Note that it’s very easy to distinguish which is which, because the new
user-defined dashboard has (imported) in its name.
 From the LookML dashboard
Proprietary + Confidential

Examples are based on fictional data.

If you’re already viewing a LookML dashboard, though, you can click on the vertical
three-dot menu and select the “Copy LookML dashboard” menu option to
accomplish the same thing.
 Save the new+ Confidential
Proprietary dashboard

Examples are based on fictional data.

In the Copy <Dashboard name> pop-up, assign your new user-defined dashboard a
name, its folder destination, and whether you want the new dashboard to preserve the
existing LookML dashboard locale keys. Only select this option if you believe it will
get converted back into a LookML dashboard in the future.

When you’re ready, click on the Copy button to create the new user-defined
dashboard. And that’s it. You have a brand new user-defined dashboard once again!