| name | lookml-view |
| description | Use this skill to create or modify LookML Views. Covers basic view definitions, sql_table_name, file organization, and patterns. |
| license | Apache-2.0 |
| metadata | {"publisher":"google","version":"v1"} |
Instructions
1. File Organization
- Standard Views:
views/[datasource_name]/[view_name].view.lkml
- Extended Views:
views/[datasource_name]/[view_name]_ext.view.lkml
- Refinements:
views/[datasource_name]/[view_name]_rfn.view.lkml
- NDTs:
views/[datasource_name]/[view_name]_ndt.view.lkml
- SDTs:
views/[datasource_name]/[view_name]_sdt.view.lkml
2. Core Standards
- sql_table_name: Required for standard views. Defaults are fragile; be explicit.
- Primary Key:
- Convention: place the primary key as the first dimension for readability.
- Must have
primary_key: yes — Why: essential for symmetric aggregates, which Looker uses to handle JOIN row duplication correctly (prevents fanout in multi-join queries).
- Refinements: Use
+ before the view name (e.g., view: +users) to refine existing views without modifying the original file.
- Extensions: Use
extends to reuse logic from other views.
- Derived Tables: Evaluate and nudge towards Native Derived Tables (NDTs) (
explore_source) over SQL Derived Tables (sql) where possible. When creating entity rollups or summary facts (e.g., user_order_facts), assess whether an existing Explore can source the data. NDTs are recommended because they minimize code drift and automatically inherit underlying LookML descriptions, formatting, and Row-Level Security (RLS). If an NDT is too complex, or if specific SQL features are required, an SDT is fully acceptable.
3. Best Practices
- Naming: Use
snake_case for view names and filenames.
- Descriptions: Add descriptions to the view itself if it helps explain its purpose (e.g., "Daily active users aggregated by region").
- Output Format: Ensure the file ends with a newline.
4. Related Skills
Examples
Basic View
view: users {
sql_table_name: `project.dataset.users` ;;
dimension: user_id {
primary_key: yes
type: number
sql: ${TABLE}.id ;;
group_label: "IDs"
description: "Unique internal user ID."
}
dimension: email {
type: string
sql: ${TABLE}.email ;;
description: "User's email address."
}
}
Extended View
include: "/views/base/users.view"
view: users_extended {
extends: [users]
dimension: lifetime_value {
type: number
sql: ${TABLE}.ltv ;;
description: "Total lifetime value of the user."
}
}
Refinement (Layering)
include: "/views/users.view"
view: +users {
label: "All Users (Refined)"
dimension: email {
# Adding a description to an existing field
description: "Primary contact email."
}
}
Reference Skills
- Derived Tables: Standard (SDT) and Native (NDT) derived table patterns/materialization.