Most BI Software, including Looker, is built atop the concept of Dimensions and Measures:
Dimensions
The qualitative data points in a dataset. Dimensions are typically not aggregated (e.g. you can't tally-up dimension data points to a total, extract an average, etc.). Dimensions are the fields you'll use to aggregate a dataset (e.g. time, location, category, etc.).
Measures
Most often, measures are the numerical values in a dataset that mathematical functions work on. Measures are typically aggregated (e.g. sum, average, minimum, etc.).
In Looker, there's a legit separation in the UI between Dimensions and Measures. For example, in the screenshot below notice how Dimensions (blue rectangle) are separated from Measures (orange rectangle):
How do Dimensions and Measures get into Looker?
The answer to this question was an epiphany moment for us. Building what shows up in the left-hand navigation of BI Software like Looker is, many times, a significant portion of where an Analyst spends their time.
For instance, the Payment Amount measure in the screenshot above is there because we wrote some code in the "backend" of Looker for it. Specifically, here's what we wrote via the proprietary Looker LookML language:
measure: total_payment {
type: sum
sql: ${TABLE}.payment_amount ;;
label: "Payment Amount"
value_format_name: usd
}
Basically, we're telling Looker to SUM the field payment_amount in our Getting Started Payments dataset. We want it formatted as USD currency (value_format_name: usd), and we want the measure to be titled Payment Amount (label: "Payment Amount") in the UI.
So, when this is clicked, Looker is actually writing the following SQL query:
And when we hit "Run" we get the following result:
