sql_table_name (pour les vues)

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

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

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

Utilisation

view: view_name {
  sql_table_name: table_name ;;
}
Hiérarchie
view
sql_table_name
Valeur par défaut
Nom de la vue

Acceptation
Nom de table dans votre base de données

Règles spéciales

Définition

Le paramètre sql_table_name spécifie la table de votre base de données qui sera interrogée par une vue.

Si vous souhaitez créer une vue basée sur une table dérivée, n'utilisez pas le paramètre sql_table_name. Utilisez plutôt le paramètre derived table, décrit sur la page de documentation derived_table. L'environnement IDE de Looker renvoie une erreur si vous avez à la fois sql_table_name et derived_table dans un fichier d'affichage.

Si une vue ne contient ni le paramètre sql_table_name, ni le paramètre derived_table, Looker suppose que la vue est basée sur une table de base de données et que le nom de la table de base de données correspond au nom de la vue. En d'autres termes :

view: my_name { ... }

équivaut logiquement à :

view: my_name {
  sql_table_name: my_name ;;
}

Il est assez courant de revenir à ce comportement par défaut et de ne pas utiliser sql_table_name. Toutefois, il existe des situations majeures dans lesquelles cela peut être utile. Tout d'abord, dans certains cas, vous souhaiterez que la vue porte un nom différent de celui de la table sous-jacente, par exemple pour nettoyer un nom de table désordonné :

view: orders {
  sql_table_name: prod_orders_2 ;;
}

De plus, il existe des cas où une vue doit être basée sur une base de données ou un schéma qui ne se trouve pas dans le chemin de recherche par défaut de l'utilisateur de la base de données. Vous pouvez ensuite définir le champ d'application du nom de la table au format <schema_name>.<table_name>, comme suit :

view: desired_view_name {
  sql_table_name: database_name.schema_name.table_name ;;
}

Définir le champ d'application des noms de tables

Lorsque vous référencez une table en utilisant uniquement son nom, Looker utilise le chemin de recherche par défaut (la base de données et le schéma) que votre administrateur Looker a configuré dans les paramètres de connexion pour la connexion à la base de données. Pour en savoir plus, consultez la section Éléments à prendre en compte sur cette page.

Si vous devez référencer une table dans une base de données et un schéma différents qui ne se trouvent 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 de la table au format <database_name>.<schema_name>.<table_name> pour pointer vers une autre base de données ou un autre schéma :

Pour une connexion Google BigQuery, vous pouvez référencer une table dans un projet et un ensemble de données différents en définissant le champ d'application du nom de la table au format <project_name>.<dataset_name>.<table_name>. Pour en savoir plus, consultez la page de documentation sur la connexion Google BigQuery.

Jointures fédérées

La jointure de deux tables provenant de bases de données différentes est appelée jointure fédérée. Les jointures fédérées peuvent être effectuées à l'aide de Looker si les deux bases de données utilisent le même dialecte SQL, si le dialecte est compatible avec les jointures fédérées et si les deux bases de données sont accessibles à partir de la même connexion dans Looker. En fonction de la configuration de votre base de données, les tables devront peut-être également résider sur la même machine physique.

Dans ces conditions, vous pouvez créer une jointure fédérée en spécifiant le nom de la base de données de chaque table dans le paramètre sql_table_name de cette vue :

view: view_1 {
  sql_table_name: database_name.table_1 ;;
}

view: view_2 {
  sql_table_name: another_database_name.table_2 ;;
}

Joignez ensuite ces vues à l'aide du paramètre sql_on :

explore: view_1 {
  join: view_2 {
    sql_on: ${view_1.view_1_ID} = ${view_2.view_2_ID} ;;
  }
}

Si vous souhaitez joindre des bases de données qui utilisent des dialectes SQL différents, nous vous recommandons de répliquer une base de données dans l'autre afin de pouvoir extraire toutes les données d'une seule source.

Exemples

Dans cet exemple, la vue customers dépend de la table customer_1 du schéma par défaut :

view: customers {
  sql_table_name: customer_1 ;;
}

Dans cet exemple, la vue customers dépend de la table customer_1 de analytics en définissant le champ d'application du nom de la table pour inclure le nom du schéma (au format <schema_name>.<table_name>) :

view: customers {
  sql_table_name: analytics.customer_1 ;;
}

Éléments à prendre en compte

Les tables référencées par view doivent être accessibles à partir de la connexion actuelle

Lorsque le paramètre sql_table_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 modèle. L'objet de modèle contient une base de données connection définie. Lorsque vous référencez une table de base de données dans le paramètre sql_table_name, la table 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.

Les noms de tables non conviviaux peuvent nécessiter une mise en forme supplémentaire

Certains dialectes exigent que les noms de tables contenant des caractères non compatibles, également appelés noms de tables "non conviviaux", soient placés entre crochets, guillemets doubles ou guillemets simples. Par exemple, le nom de table Customers.PaymentInfo inclut un point dans le nom de la table, qui peut être interprété comme une table appelée PaymentInfo dans le schéma Customers. Pour corriger ce problème, si votre dialecte nécessite des crochets, vous pouvez placer le nom de la table entre crochets, comme suit :

sql_table_name: [Customers.PaymentInfo] ;;

Si votre dialecte nécessite des guillemets doubles ou simples, vous devez remplacer les crochets par ces caractères.