Cette page vous aidera à résoudre cette erreur Looker:
Non-unique value/primary key (or sql_distinct_key), value overflow or collision when computing sum
Plusieurs problèmes peuvent être à l'origine de cette erreur:
- Une clé primaire non unique (la plus courante)
- Utilisation incorrecte de
sql_distinct_key
- Faire référence à un champ dans plusieurs vues en cas de fan-outs
Clé primaire non unique
La cause la plus fréquente de cette erreur est que votre requête implique une clé primaire non unique. Vous spécifiez une clé primaire en utilisant primary_key: yes
au niveau d'une dimension. Il doit s'agir d'une dimension sans valeurs répétées.
Solution rapide
Une fois que vous avez identifié les dimensions de clé primaire dans votre requête, vous pouvez tester leur unicité dans l'exécuteur SQL de Looker à l'aide de la requête suivante:
SELECT COUNT(*), COUNT(DISTINCT your_primary_key) FROM your_table_name
Si les nombres dans cette requête correspondent, la clé primaire est unique. Si les nombres ne correspondent pas, la clé primaire n'est pas unique et apparaît sur plusieurs lignes. Vous devrez choisir ou créer une dimension comme clé primaire. Si aucune dimension ne contient de valeurs totalement uniques, vous devrez peut-être concaténer les champs afin de créer votre propre dimension de clé primaire.
Utiliser row_number
pour générer une clé primaire pour une table dérivée
Si vous recevez cette erreur avec une table dérivée, vous pouvez utiliser la fonction de fenêtrage row_number()
des bases de données Postgres et Redshift pour créer un champ unique. Ce champ peut ensuite être utilisé comme clé primaire:
view: derived_table_name { derived_table { sql: SELECT row_number() OVER(ORDER BY created_at) AS prim_key, * FROM orders ;; } dimension: prim_key { type: number primary_key: yes sql: ${TABLE}.prim_key ;; } }
Dans MySQL, vous pouvez utiliser une variable qui itère chaque ligne pour obtenir le même effet:
view: derived_table_name { derived_table { sql: SELECT CAST(@rownum := @rownum + 1 AS UNSIGNED) AS prim_key, t.* FROM orders t, (SELECT @rownum := 0) r ;; } dimension: prim_key { type: number primary_key: yes sql: ${TABLE}.prim_key ;; } }
Utilisation incorrecte de sql_distinct_key
Si l'une des mesures de votre requête est de type sum_distinct
, il se peut qu'il y ait une incohérence d'unicité entre les paramètres sql_distinct_key
et sql
de cette mesure.
Solution rapide
Consultez la page de documentation de sum_distinct
pour connaître les exigences liées à ces paramètres.
Référencer des champs dans les vues avec les fan-outs
Votre requête peut utiliser une mesure de la vue A, mais cette mesure fait référence à un champ de la vue B. Dans ce cas, Looker utilise la clé primaire de la vue A pour calculer cette mesure. Si votre requête implique une distribution ramifiée, ce n'est peut-être pas la bonne clé primaire à utiliser. (Pour en savoir plus sur les fan-outs, consultez notre post à ce sujet.)
Solution rapide
Pour résoudre ce problème, ajoutez la clé primaire de la vue B à la mesure du problème avec le paramètre sql_distinct_key
.
Que se passe-t-il si aucune des causes indiquées ne s'applique, mais que l'erreur se produit toujours ?
Il existe une situation très spécifique dans laquelle votre clé primaire peut être unique. Les autres causes de ce problème ne s'appliquent pas à votre requête, mais cette erreur se produit toujours. Tout d'abord, votre requête impliquera plusieurs jointures de relationship: one_to_many
. Ensuite, l'une des mesures de votre requête fera référence à une dimension qui combine les valeurs de plusieurs vues jointes.
Pour résoudre ce problème, notez cette mesure, puis procédez comme suit:
- Recherchez la dimension dans la mesure qui combine les valeurs de plusieurs vues jointes.
- Recherchez les vues référencées par cette dimension.
- Concaténez les clés primaires de ces vues à l'aide de la fonction de concaténation de votre dialecte SQL.
- Placez cette clé concaténée dans un paramètre
sql_distinct_key
sur la mesure à l'origine du problème.