Erreur: valeur non unique/clé primaire (ou sql_distinct_key), dépassement 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

Plusieurs problèmes peuvent être à l'origine de cette erreur:

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:

  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. Concaténez les clés primaires de ces vues à l'aide de la fonction de concaténation 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.