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.