Metacenta

BI semantic layer · rule lookml-joined-view-no-primary-key

Looker joined views with no primary key

A Metacenta review checks this under the rule A joined view declares a primary key. Everything below applies whether or not you ever commission one.

What this rule checks

This rule flags each view taking part in a join, the explore's base view included, that declares no primary_key: yes. A bare join (sql: ;;) brings in no rows, so it does not count. Unjoined views are not judged.

Why it matters

Without a key Looker cannot apply symmetric aggregates. A sum or average over the view is silently multiplied when a join fans out its rows. The dashboard shows a confident, wrong number.

How to fix it

Declare a primary key on every joined Looker view. Mark the view's unique dimension with primary_key: yes. If there is no single unique column, build a compound key in a dimension and mark that.

Before:

view: order_items {
  dimension: order_item_id {
    sql: ${TABLE}.order_item_id ;;
  }
}

After:

view: order_items {
  dimension: order_item_id {
    primary_key: yes
    sql: ${TABLE}.order_item_id ;;
  }
}

When it is fine to leave

Where every join declares many_to_one or one_to_one, rows cannot fan out today. We rate that lower, but the key still protects against a relationship someone later gets wrong. It costs one line.

What we need to check it

The .lkml files. A key can sit in a refinement or in a base the view extends. When that file was not supplied, we leave the view unexamined rather than flag it. Findings are medium confidence.