sql_analytic_model_name (para vistas)

En esta página, se hace referencia al parámetro sql_analytic_model_name que forma parte de una vista.

sql_analytic_model_name también se puede usar como parte de una exploración, que se describe en la página de documentación del parámetro sql_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:
      • string
      • number
      • date
      • yesno
    • Admitidos solo para dimensiones:
      • time
      • date_time
  • 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: sum o type: 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 sql de 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, como sum o count. Debes definir la nueva medición como un tipo de medición no agregada, como string, number, date o yesno. Consulta el siguiente ejemplo:

      measure: average_order_amount {
        type: number
        sql: ROUND(${total_order_amount} / NULLIF(${count_orders}, 0), 2) ;;
      }
      
  • 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: distance o type: 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.