sql_analytic_model_name (pour les explorations)

Cette page fait référence au paramètre sql_analytic_model_name qui fait partie d'une exploration.

sql_analytic_model_name peut également être utilisé dans une vue, comme décrit sur la page de documentation du paramètre sql_analytic_model_name (pour les vues).

Utilisation

explore: explore_name {
  sql_analytic_model_name: analytic_model_name ;;
}
Hiérarchie
explore
sql_analytic_model_name
Valeur par défaut
Aucun

Acceptation
Nom d'un modèle analytique dans la base de données

Règles spéciales
  • Les modèles analytiques ne sont compatibles qu'avec les connexions BigQuery et Snowflake.
  • sql_analytic_model_name pour les explorations ne doit être utilisé que lorsque la même vue peut décrire plusieurs modèles analytiques dans votre base de données.
  • Le modèle analytique référencé par sql_analytic_model_name doit être accessible dans la connexion à la base de données de son modèle.
  • Si le modèle analytique se trouve dans une base de données, un schéma, un projet ou un ensemble de données différents du chemin par défaut que vous avez défini dans votre connexion à la base de données, vous devez définir le champ d'application du nom du modèle analytique.

Définition

Pour les connexions BigQuery et Snowflake, le paramètre sql_analytic_model_name spécifie le nom d'un modèle analytique existant dans la base de données (un graphique BigQuery ou une vue sémantique dans Snowflake) à utiliser comme base pour une exploration LookML.

Dans la plupart des cas, vous utilisez le paramètre sql_analytic_model_name (pour les vues) pour spécifier un modèle analytique dans votre fichier de vue. Ensuite, dans ce fichier de vue, vous définissez les dimensions et les mesures LookML basées sur le modèle analytique de votre base de données. Toutefois, dans les cas où votre base de données comporte plusieurs modèles analytiques pouvant être définis par les mêmes champs LookML, vous pouvez utiliser le paramètre sql_analytic_model_name sous un paramètre explore.

Lorsque vous spécifiez un sql_analytic_model_name sous un paramètre explore, l'exploration remplace le modèle analytique spécifié dans le fichier d'affichage et interroge à la place le modèle analytique que vous avez spécifié dans le sql_analytic_model_name sous le paramètre explore. Dans ce cas, l'exploration utilisera les mesures et les dimensions LookML définies dans le fichier de vue, mais les appliquera au modèle analytique spécifié dans le paramètre sql_analytic_model_name du paramètre explore.

Définir le champ d'application des noms de modèles analytiques

Lorsque vous référencez un modèle analytique en utilisant uniquement son nom, Looker utilise le chemin de recherche par défaut (base de données et schéma) que votre administrateur Looker a configuré dans les paramètres de la connexion à la base de données.

Si vous devez faire référence à un modèle analytique dans une base de données et un schéma différents qui ne figurent pas dans le chemin de recherche par défaut de l'utilisateur de la base de données, vous pouvez définir le champ d'application du nom du modèle analytique en utilisant le format <database_name>.<schema_name>.<analytic_model_name> pour pointer vers une autre base de données ou un autre schéma :

  • Pour faire référence à un modèle analytique provenant d'un autre schéma, utilisez <schema_name>.<analytic_model_name>.
  • Pour faire référence à un modèle analytique provenant d'une autre base de données, utilisez le <database_name>.<schema_name>.<analytic_model_name> complet.

Pour une connexion Google BigQuery, vous pouvez faire référence à un modèle analytique dans un autre projet et ensemble de données en définissant le nom du modèle analytique à l'aide du format <project_name>.<dataset_name>.<analytic_model_name>. Pour en savoir plus, consultez la page de documentation sur la connexion à Google BigQuery.

Exemple

Voici un exemple de vue LookML appelée MyStoreGraphView, basée sur un graphique StoreGraph BigQuery sur une base de données BigQuery, y compris les dimensions et les mesures mappées sur le graphique :

view: MyStoreGraphView {
  sql_analytic_model_name: StoreGraph ;;

  dimension: location_id {
    type: number
    sql: Stores_location_id ;;
  }

  dimension: population {
    type: number
    sql: Locations_population ;;
  }

  dimension: location_name {
    type: string
    sql: Locations_name ;;
  }

  measure: locations_total_population {
    type: number
    sql: Locations_total_population ;;
  }
}

En supposant que la base de données comporte un autre graphe appelé ShopDetailsGraph avec les mêmes éléments que StoreGraph, voici une exploration qui remplace la valeur sql_analytic_model_name dans le fichier d'affichage MyStoreGraphView. L'exploration aura les mêmes dimensions et mesures LookML que celles définies dans MyStoreGraphView, mais elle interrogera le modèle analytique ShopDetailsGraph :

explore: MyStoreGraphView {
  sql_analytic_model_name: ShopDetailsGraph ;;
}

Éléments à prendre en compte

Éléments à prendre en compte pour les modèles analytiques dans Looker

Lorsque vous utilisez des modèles analytiques intégrés à la base de données, tenez compte des considérations et des limites suivantes :

  • Types de données : seuls les types de données suivants pour les dimensions et les métriques sont compatibles avec les modèles analytiques :

    • Pris en charge pour les dimensions et les mesures :
      • string
      • number
      • date
      • yesno
    • Pris en charge pour les dimensions uniquement :
      • time
      • date_time

  • Mesures :

    • Les mesures de base doivent être prédéfinies : elles doivent l'être dans le modèle analytique de la base de données sous-jacente. Looker ne peut pas définir de mesure de base en effectuant une agrégation (telle que type: sum ou type: count) sur une dimension d'un modèle analytique.

    • Les mesures basées sur d'autres mesures sont acceptées : vous pouvez utiliser le paramètre sql d'une mesure LookML pour effectuer des calculs non agrégés qui utilisent des mesures de base prédéfinies du modèle analytique. Lorsque vous créez une mesure basée sur d'autres mesures, vous ne pouvez pas la définir comme type de mesure agrégée (sum ou count, par exemple). Vous devez définir la nouvelle mesure comme un type de mesure non agrégé, tel que string, number, date ou yesno. Consultez l'exemple ci-dessous :

      measure: average_order_amount {
  type: number
  sql: ROUND(${total_order_amount} / NULLIF(${count_orders}, 0), 2) ;;
}

  • Jointures : une exploration dont la vue de base est basée sur un modèle analytique ne peut inclure aucune jointure. De même, une vue basée sur un modèle analytique ne peut pas être jointe à une exploration comportant une vue de base LookML standard.

  • Jointures implicites : les fonctionnalités qui s'appuient sur des jointures implicites ne sont pas compatibles avec les modèles analytiques. Les calendriers personnalisés et les champs définis avec type: location, type: distance ou type: zipcode sont des exemples de fonctionnalités qui s'appuient sur des jointures implicites.

  • Les fonctionnalités suivantes ne sont pas compatibles avec les modèles analytiques :

Le modèle analytique doit être accessible à partir de la connexion actuelle.

Lorsque le paramètre sql_analytic_model_name est utilisé dans un objet explore, cet objet explore est à son tour inclus dans un objet model. (La hiérarchie sur cette page montre cette chaîne de relations.) L'objet de modèle contient une base de données connection. Lorsque vous référencez un modèle analytique dans le paramètre sql_analytic_model_name, le modèle analytique doit être accessible dans la connexion associée spécifiée dans le fichier de modèle.

La base de données et le schéma par défaut (ou, pour Google BigQuery, le projet de facturation et l'ensemble de données) sont définis par votre administrateur Looker lorsqu'il crée la connexion Looker à votre base de données.