sql_analytic_model_name (pour les vues)

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

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

Utilisation

view: view_name {
  sql_analytic_model_name: analytic_model_name ;;
}
Hiérarchie
view
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.
  • 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 vue LookML. Vous pouvez ainsi exploiter les modèles analytiques définis directement dans votre base de données, tels que BigQuery Graph ou les vues sémantiques dans Snowflake.

Dans ce scénario, l'objet de modèle analytique existe déjà dans votre base de données et est géré par celle-ci. Il n'est pas créé, géré ni régi par Looker. Cela correspond à la façon dont les tables de base de données standards exposées en tant que vues LookML à l'aide de sql_table_name ne sont pas régies par Looker.

Dans le fichier de vue LookML, utilisez le paramètre sql_analytic_model_name pour indiquer à Looker le modèle analytique de votre base de données. Créez ensuite des dimensions et des mesures Looker pour les mapper au modèle analytique. Vous pourrez ainsi utiliser Looker pour interroger le modèle analytique.

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.

Créer des dimensions et des mesures LookML en fonction de votre vue analytique

Une fois que vous avez créé un fichier de vue et identifié un modèle analytique comme sql_analytic_model_name, vous pouvez définir dans le même fichier de vue des dimensions et des mesures LookML basées sur le modèle analytique.

Consultez la documentation de votre dialecte pour en savoir plus sur la syntaxe SQL appropriée à utiliser pour faire référence aux éléments de votre modèle analytique. Par exemple, pour créer une dimension LookML à partir d'une entité BigQuery Graph, vous devez utiliser des traits de soulignement pour séparer les éléments lors de la définition du champ d'application. Par exemple, pour BigQuery Graph, cette dimension LookML est basée sur la propriété location_id de la table de nœuds Stores :

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

Toutefois, pour créer une dimension LookML basée sur une vue sémantique Snowflake, vous devez utiliser le nom non qualifié d'une métrique ou d'une dimension.

Exemple

Voici un exemple de graphique BigQuery nommé StoreGraph défini sur une base de données BigQuery :

CREATE OR REPLACE PROPERTY GRAPH mydataset.StoreGraph
  NODE TABLES (
    mydataset.Stores AS S,
    mydataset.Locations AS L
    PROPERTIES(id, name, population, MEASURE(SUM(population)) AS total_population)
  )
  EDGE TABLES (
    mydataset.Stores AS SL
    SOURCE KEY (location_id) REFERENCES L (id)
    DESTINATION KEY (name) REFERENCES S (name)
  );

Voici un exemple de vue LookML basée sur le graphique BigQuery StoreGraph, y compris les dimensions et les mesures mappées au 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 ;;
  }
}

É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 view, cet objet view peut être référencé dans un objet explore, qui est à son tour référencé dans un objet model. 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, il doit être accessible dans la connexion associée spécifiée dans le fichier du 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.