Erreur: valeur/clé primaire non unique (ou sql_distinct_key), débordement de valeur ou collision lors du calcul de la somme

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

Cette erreur peut être due à l'un des problèmes suivants:

Clé primaire non unique

La cause la plus courante de cette erreur est que votre requête implique une clé primaire non unique. Pour spécifier une clé primaire, utilisez primary_key: yes sur une dimension, qui doit être 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 vérifier leur unicité dans l'exécuteur SQL de Looker avec cette requête:

SELECT
  COUNT(*),
  COUNT(DISTINCT your_primary_key)
FROM
  your_table_name

Si les totaux de cette requête correspondent, la clé primaire est unique. Si les totaux ne correspondent pas, la clé primaire n'est pas unique et apparaît sur plusieurs lignes. Vous devez choisir ou créer une dimension comme clé primaire. Si aucune dimension ne contient des valeurs entièrement uniques, vous devrez peut-être concatenater des champs pour 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 ce message d'erreur s'affiche avec une table dérivée, vous pouvez utiliser la fenêtrage row_number() dans les 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 est possible qu'il existe une incohérence d'unicité entre les paramètres sql_distinct_key et sql de cette mesure.

Solution rapide

Consultez notre page de documentation sum_distinct pour connaître les exigences de ces paramètres.

Référencer des champs dans les vues avec des fanouts

Votre requête peut utiliser une mesure de la vue A, mais la mesure fait référence à un champ de la vue B. Dans ce cas, Looker utilisera la clé primaire de la vue A pour calculer cette mesure. Si votre requête implique un fanout, il se peut que la clé primaire utilisée ne soit pas la bonne. (Pour en savoir plus sur les fanouts, consultez notre post destiné à la communauté.)

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 listé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, et les autres causes de ce problème ne s'appliquent pas à votre requête, mais cette erreur se produit quand même. Tout d'abord, votre requête impliquera plusieurs jointures de relationship: one_to_many. Deuxièmement, l'une des mesures de votre requête fait 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:

  1. Recherchez la dimension dans la mesure qui combine les valeurs de plusieurs vues jointes.
  2. Recherchez les vues référencées par cette dimension.
  3. Concatenatez les clés primaires de ces vues à l'aide de la fonction de concatenaison de votre dialecte SQL.
  4. Placez cette clé concaténée dans un paramètre sql_distinct_key sur la mesure à l'origine du problème.