En esta página, se hace referencia al parámetro
sql_analytic_model_nameque forma parte de una vista.
sql_analytic_model_nametambién se puede usar como parte de una exploración, que se describe en la página de documentación del parámetrosql_analytic_model_name(para exploraciones).
Uso
view: view_name {
sql_analytic_model_name: analytic_model_name ;;
}
|
Jerarquía
sql_analytic_model_name |
Valor predeterminado
Ninguno
Acepta
Un nombre de modelo analítico en la base de datos
Reglas especiales
|
Definición
Para las conexiones de BigQuery y Snowflake, el parámetro sql_analytic_model_name especifica el nombre de un modelo analítico existente en la base de datos (un gráfico de BigQuery o una vista semántica en Snowflake) para usar como base para una vista de LookML. Esto te permite aprovechar los modelos analíticos definidos directamente en tu base de datos, como el gráfico de BigQuery o las vistas semánticas en Snowflake.
En este caso, el objeto del modelo analítico ya existe en tu base de datos y está regido por tu base de datos. Looker no crea, mantiene ni controla el modelo analítico. Esto es similar a cómo las tablas de bases de datos normales expuestas como vistas de LookML mediante sql_table_name no están regidas por Looker.
En el archivo de vista de LookML, usa el parámetro sql_analytic_model_name para dirigir Looker al modelo analítico en tu base de datos. Luego, crea dimensiones y mediciones de Looker para asignarlas al modelo analítico de modo que puedas usar Looker para consultarlo.
Cómo definir el alcance de los nombres de los modelos analíticos
Cuando haces referencia a un modelo analítico usando solo el nombre del modelo analítico, Looker usa la ruta de acceso de búsqueda predeterminada (la base de datos y el esquema) que el administrador de Looker configuró en los parámetros de configuración de la conexión de base de datos.
Si necesitas hacer referencia a un modelo analítico en una base de datos y un esquema diferentes que no estén en la ruta de acceso de búsqueda predeterminada del usuario de la base de datos, puedes definir el alcance del nombre del modelo analítico con el formato <database_name>.<schema_name>.<analytic_model_name> para dirigir a otra base de datos o esquema:
- Para hacer referencia a un modelo analítico desde un esquema diferente, usa
<schema_name>.<analytic_model_name>. - Para hacer referencia a un modelo analítico desde una base de datos diferente, usa el formato completo
<database_name>.<schema_name>.<analytic_model_name>.
Para una conexión de Google BigQuery, puedes hacer referencia a un modelo analítico en un proyecto y un conjunto de datos diferentes definiendo el alcance del nombre del modelo analítico con el formato <project_name>.<dataset_name>.<analytic_model_name>. Consulta la página de documentación de la conexión de Google BigQuery para obtener información adicional.
Crea dimensiones y mediciones de LookML en función de tu vista analítica
Después de crear un archivo de vista y de identificar un modelo analítico como sql_analytic_model_name, en el mismo archivo de vista, puedes definir dimensiones y mediciones de LookML que se basen en el modelo analítico.
Consulta la documentación de tu dialecto para obtener información sobre la sintaxis de SQL adecuada que se debe usar para hacer referencia a los elementos de tu modelo analítico. Por ejemplo, para crear una dimensión de LookML a partir de una entidad de gráfico de BigQuery, debes usar guiones bajos para separar los elementos cuando definas el alcance. Por ejemplo, para el gráfico de BigQuery, esta dimensión de LookML se basa en la propiedad location_id de la tabla de nodos Stores:
dimension: location_id {
type: number
sql: Stores_location_id ;;
}
Sin embargo, para crear una dimensión de LookML que se base en una vista semántica de Snowflake, debes usar el nombre no calificado de una métrica o dimensión.
Ejemplo
Este es un ejemplo de un gráfico de BigQuery llamado StoreGraph que se define en una base de datos de 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)
);
Este es un ejemplo de una vista de LookML que se basa en el gráfico de BigQuery StoreGraph, incluidas las dimensiones y las mediciones que se asignan al gráfico:
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 ;;
}
}
Aspectos para tener en cuenta
Consideraciones para los modelos analíticos en Looker
Cuando uses modelos analíticos en la base de datos, ten en cuenta las siguientes consideraciones y limitaciones:
Tipos de datos: Solo se admiten los siguientes tipos de datos para las dimensiones y las mediciones con modelos analíticos:
- Admitidos para dimensiones y mediciones:
stringnumberdateyesno
- Admitidos solo para dimensiones:
timedate_time
- Admitidos para dimensiones y mediciones:
Mediciones:
- Las mediciones base deben estar predefinidas: Las mediciones base deben estar predefinidas en el modelo analítico de la base de datos subyacente. Looker no puede definir una nueva medición base realizando una agregación (como
type: sumotype: count) en una dimensión de un modelo analítico. Se admiten las mediciones que se basan en otras mediciones: Puedes usar el parámetro
sqlde una medición de LookML para realizar cálculos no agregados que usen mediciones base predefinidas del modelo analítico. Cuando creas una medición que se basa en otras mediciones, no puedes definir la nueva medición como un tipo de medición agregada, comosumocount. Debes definir la nueva medición como un tipo de medición no agregada, comostring,number,dateoyesno. Consulta el siguiente ejemplo:measure: average_order_amount { type: number sql: ROUND(${total_order_amount} / NULLIF(${count_orders}, 0), 2) ;; }
- Las mediciones base deben estar predefinidas: Las mediciones base deben estar predefinidas en el modelo analítico de la base de datos subyacente. Looker no puede definir una nueva medición base realizando una agregación (como
Uniones: Una exploración cuya vista base se basa en un modelo analítico no puede incluir ninguna unión. Del mismo modo, una vista que se basa en un modelo analítico no se puede unir a una exploración que tenga una vista base de LookML estándar.
Uniones implícitas: Las funciones que dependen de uniones implícitas no son compatibles con los modelos analíticos. Algunos ejemplos de funciones que dependen de uniones implícitas son los calendarios personalizados y los campos que se definen con
type: location,type: distanceotype: zipcode.Las siguientes funciones no son compatibles con los modelos analíticos:
Se debe poder acceder al modelo analítico desde la conexión actual
Cuando se usa el parámetro sql_analytic_model_name dentro de un objeto view, se puede hacer referencia a ese objeto view en un objeto explore, que, a su vez, se hace referencia en un objeto modelo. El objeto de modelo tiene una base de datos connection definida en él. Cuando haces referencia a un modelo analítico en el parámetro sql_analytic_model_name, se debe poder acceder al modelo analítico dentro de la conexión asociada que se especifica en el archivo del modelo.
El administrador de Looker define la base de datos y el esquema predeterminados (o, para Google BigQuery, el proyecto de facturación y el conjunto de datos) cuando crea la conexión de Looker a tu base de datos.