derived_analytic_model

Uso

# SQL-based derived analytic model
view: view_name {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes | no
    sql: analytic_model_definition ;;
  }
}

# LookML-based derived analytic model
view: view_name {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes | no
    model_source: explore_name {
      fields: [field_1, field_2, ...]
      join: +joined_view_name {
        foreign_key: field_name
      }
    }
  }
}
Jerarquía
view
derived_analytic_model
Valor predeterminado
Ninguno

Reglas especiales
Los modelos analíticos solo son compatibles con las conexiones de BigQuery y Snowflake.

Definición

En el caso de las conexiones de BigQuery y Snowflake, el parámetro derived_analytic_model define un modelo analítico integrado en la base de datos (un gráfico de BigQuery o una vista semántica en Snowflake) que administra Looker.

A diferencia de las tablas derivadas, los objetos de modelos analíticos administrados por Looker no conservan ningún dato en la base de datos y no se actualizan de forma incremental. En cambio, representan modelos semánticos que definen relaciones y medidas directamente en la base de datos.

Looker admite dos tipos de modelos analíticos derivados:

Modelos analíticos derivados basados en SQL

En un modelo analítico derivado basado en SQL, Looker genera el modelo analítico dentro de tu base de datos ejecutando las declaraciones del lenguaje de definición de datos (DDL) de SQL adecuadas que especificas en la definición del parámetro derived_analytic_model de LookML. La sintaxis de SQL que definas en el parámetro derived_analytic_model debe ser compatible con tu base de datos.

Para definir un modelo analítico basado en SQL, usa uno de los siguientes subparámetros del parámetro derived_analytic_model:

Además, si defines tu vista analítica con el subparámetro sql, puedes usar el subparámetro publish_as_db_analytic_model del parámetro derived_analytic_model para crear un modelo analítico estable que se pueda consultar fuera de Looker.

Después de definir el modelo analítico dentro del parámetro derived_analytic_model, puedes definir dimensiones y medidas de LookML que se asignen a tu modelo analítico. Consulta la sección Ejemplos de modelos analíticos derivados basados en SQL para obtener más información.

sql

Usa el parámetro sql si deseas proporcionar el código SQL solo para la definición del modelo analítico y que Looker administre la creación del modelo analítico. Cuando uses el parámetro secundario sql, no incluyas una instrucción CREATE ni CREATE OR REPLACE, ya que Looker generará automáticamente la instrucción DDL para crear el modelo analítico en el lado de la base de datos.

Consulta Cómo crear un modelo analítico derivado con sql para ver un ejemplo del uso del parámetro sql para crear un modelo analítico en tu base de datos.

sql_create

Usa el parámetro sql_create para definir una instrucción de SQL completa que permita crear un modelo analítico. Cuando usas el parámetro sql_create, debes incluir una instrucción CREATE OR REPLACE (o una instrucción CREATE, si tu dialecto no admite CREATE OR REPLACE).

Ten en cuenta lo siguiente cuando uses el parámetro secundario sql_create:

  • En el caso de las conexiones de BigQuery, usa una sentencia CREATE OR REPLACE para crear el modelo analítico.
  • Usa ${SQL_TABLE_NAME} para sustituir el nombre calculado del modelo analítico que se está creando. Esto garantiza que la instrucción de SQL incluya correctamente el nombre del modelo analítico que proporcionas en el parámetro view de LookML.

Consulta Cómo crear un modelo analítico derivado con sql_create para ver un ejemplo del uso del parámetro sql_create para crear un modelo analítico en tu base de datos.

create_process

Usa el parámetro create_process cuando necesites definir varias instrucciones de SQL secuenciales para definir el modelo analítico. En el parámetro create_process, usa el subparámetro sql_step para especificar las instrucciones de SQL individuales. Tu base de datos ejecutará las instrucciones sql_step una a la vez, en el orden en que las especificaste. Looker emite las instrucciones SQL en los subparámetros sql_step a medida que los defines, sin ningún wrapper, lo que significa que debes incluir un paso con una instrucción CREATE OR REPLACE (o una instrucción CREATE, si tu dialecto no admite CREATE OR REPLACE).

Consulta Cómo crear un modelo analítico derivado con create_process para ver un ejemplo del uso del parámetro create_process para crear un modelo analítico en tu base de datos.

publish_as_db_analytic_model

En el caso de los modelos analíticos derivados que se crean con el parámetro sql, puedes definir tu modelo analítico derivado con publish_as_db_analytic_model: yes para solicitar a Looker que cree un modelo analítico estable al que se pueda consultar fuera de Looker.

El modelo analítico estable se publicará (creará) en el próximo ciclo del regenerador de Looker después de que el LookML del modelo analítico derivado se implemente en producción con publish_as_db_analytic_model: yes.

Cuando especificas publish_as_db_analytic_model: yes, el regenerador de Looker crea dos modelos analíticos en tu base de datos: uno con un nombre interno y otro con un nombre estable. De lo contrario, el regenerador crea solo un modelo analítico en la base de datos, con el nombre interno.

Consulta la sección Cómo acceder al modelo analítico estable para obtener información sobre cómo obtener el nombre del modelo analítico estable y, así, poder usarlo para consultar el modelo analítico estable fuera de Looker.

Crea dimensiones y medidas de LookML basadas en tu vista de análisis basada en SQL

Después de definir tu modelo analítico, 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 adecuada que debes usar para definir tu modelo analítico y 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 BigQuery Graph, debes usar guiones bajos para separar los elementos cuando definas el alcance. Por ejemplo, para BigQuery Graph, 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 basada en una vista semántica de Snowflake, debes usar el nombre no calificado de una métrica o dimensión.

Ejemplos de modelos analíticos derivados basados en SQL

En las siguientes secciones, se proporcionan ejemplos de cómo crear una vista analítica con los diferentes subparámetros de derived_analytic_model:

Cómo crear un modelo analítico derivado con sql

A continuación, se muestra un ejemplo de archivo de vistas de LookML que define un modelo analítico basado en SQL para una base de datos de BigQuery con el subparámetro sql de derived_analytic_model. Looker creará el modelo analítico dentro de la base de datos ejecutando los comandos DDL de SQL que se proporcionan en el parámetro sql.

Ten en cuenta lo siguiente en el ejemplo:

  • El subparámetro sql solo contiene la definición del modelo analítico. No hay ninguna declaración CREATE, ya que, con sql, Looker controla automáticamente los comandos CREATE para el modelo analítico.
  • El modelo analítico se define con publish_as_db_analytic_model: yes, por lo que Looker creará un modelo analítico estable que se puede consultar fuera de Looker.
view: MyWarehouseOrdersView {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes

    # Defining the analytic model
    
    sql:
      NODE TABLES (
        Customers
        KEY(customer_id)
        PROPERTIES(
          country_code,
          concat(first_name, ' ', last_name) AS name,
          age,
          MEASURE(AVG(age)) AS AvgAge 
        ),
      Orders
        KEY(order_id)
        PROPERTIES (
          customer_id,
          employee_id,
          date,
          discount,
          MEASURE(AVG(discount)) AS AvgDiscount
        )

      EDGE TABLES (
        -- Relationship: Orders -> Customers
        looker_test.orders AS orders_to_users
          KEY(id)
          SOURCE KEY (order_id) REFERENCES orders (order_id)
          DESTINATION KEY (customer_id) REFERENCES Customers (customer_id)
          NO PROPERTIES
      ) ;;
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: customer_id {
    type: number
    sql: Customers_customer_id ;;
  }

  dimension: customer_age {
    type: number
    sql: Customers_age ;;
  }

  measure: orders_avg_discount {
    type: number
    sql: Orders_AvgDiscount ;; 
  }
}

Cómo crear un modelo analítico derivado con create_process

A continuación, se muestra un ejemplo de archivo de vistas de LookML que define un modelo analítico basado en SQL para una base de datos de BigQuery con el subparámetro create_process de derived_analytic_model. En este ejemplo, debes definir varias instrucciones de SQL secuenciales para definir el modelo analítico. El primer paso descarta el modelo analítico si ya existe, y el segundo paso crea el modelo analítico.

view: university_statistics {
  derived_analytic_model: {
    create_process: {
      sql_step: 
        DROP PROPERTY GRAPH IF EXISTS ${SQL_TABLE_NAME} ;;
      sql_step: 
        CREATE PROPERTY GRAPH ${SQL_TABLE_NAME}
         NODE TABLES (
          university.College
            KEY(college_id)
            PROPERTIES(college_id, college_name),
          university.Department
            KEY(dept_id)
            PROPERTIES(dept_id, dept_name, college_id,
              budget OPTIONS(description="Department budget in USD"),
              MEASURE(SUM(budget)) AS total_budget),
          university.Course
            KEY(course_id)
            PROPERTIES(
              course_id,
              course_name,
              credits,
              dept_id,
              MEASURE(AVG(credits)) AS avg_credits,
              MEASURE(SUM(credits)) AS total_credits,
              MEASURE(COUNT(course_id)) AS course_count)
        )
        EDGE TABLES (
          university.Department AS CollegeDept
            SOURCE KEY (college_id) REFERENCES College (college_id)
            DESTINATION KEY (dept_id) REFERENCES Department (dept_id),
          university.Course AS DeptCourse
            SOURCE KEY (dept_id) REFERENCES Department (dept_id)
            DESTINATION KEY (course_id) REFERENCES Course (course_id)
        );;
    }
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: college_id {
    type: number
    sql: College_college_id ;;
  }

  dimension: course_name {
    type: string
    sql: Course_course_name ;;
  }
  
  ...
}

Cómo crear un modelo analítico derivado con sql_create

A continuación, se muestra un ejemplo de archivo de vistas de LookML que define un modelo analítico basado en SQL para una base de datos de BigQuery con el subparámetro sql_create de derived_analytic_model. En este ejemplo, el parámetro sql_create define la instrucción CREATE OR REPLACE completa que se ejecutará para crear el modelo analítico en un solo paso.

view: MyWarehouseOrdersView {
  derived_analytic_model: {
    sql_create:
      CREATE OR REPLACE PROPERTY GRAPH ${SQL_TABLE_NAME}
        NODE TABLES(
          accounting.Loan AS Loan
            KEY(loanId)
            LABEL Loan PROPERTIES(
              loanId,
              loanAmount,
              balance,
              createTime,
              interestRate,
              accountId,
              balance + 100 AS derived_balance,
              CASE WHEN balance > 1000 THEN "High" ELSE "Low" END AS risk_level,
              CONCAT("ID-", CAST(loanId AS STRING)) AS full_id,
              DATE(2024, 1, 1) AS fixed_date,
              MEASURE(AVG(interestRate)) AS avg_interest_rate
            ),
          accounting.AccountView AS Account
            KEY(accountId)
            LABEL Account PROPERTIES(
              accountId,
              createTime,
              isBlocked,
              accountType,
              amount,
              ownerId,
              MEASURE(MIN(createTime)) AS oldest_account_create_time,
              MEASURE(MAX(createTime)) AS newest_account_create_time,
              MEASURE(AVG(amount)) AS avg_account_amount,
              MEASURE(SUM(amount)) AS total_account_amount,
              MEASURE(COUNT(DISTINCT accountType)) AS account_type_count
            ),
          accounting.PersonMV AS Person
            KEY(personId)
            LABEL Person PROPERTIES(
              personId,
              personName,
              age,
              age_tier,
              MEASURE(AVG(age)) AS avg_age,
              MEASURE(COUNT(DISTINCT age_tier)) AS age_tier_count
            )
        )
        EDGE TABLES(
          accounting.Loan AS Account_Repay_Loan
            KEY(loanId)
            SOURCE KEY(loanId) REFERENCES Loan(loanId)
            DESTINATION KEY(accountId) REFERENCES Account(accountId)
            LABEL Repay NO PROPERTIES,
          accounting.Account AS Person_Own_Account
            KEY(accountId)
            SOURCE KEY(accountId) REFERENCES Account(accountId)
            DESTINATION KEY(ownerId) REFERENCES Person(personId)
            LABEL Own NO PROPERTIES
        );;
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: loan_id {
    type: number
    sql: Loan_loanId ;;
  }

  dimension: account_ID {
    type: number
    sql: Account_accountID ;;
  }

  ...

}

Cómo acceder al modelo analítico estable

Si creaste tu modelo analítico derivado con el subparámetro sql y, además, incluiste la instrucción publish_as_db_analytic_model: yes en tu parámetro derived_analytic_model, Looker publicará (creará) el modelo analítico estable en el próximo ciclo del regenerador de Looker después de que el LookML del modelo analítico derivado se implemente en producción con publish_as_db_analytic_model: yes.

Cuando se publique el modelo analítico estable, podrás consultarlo directamente con su nombre estable. Existen dos formas de obtener el nombre estable de un modelo analítico:

Modal de detalles de la PDT

Si eres administrador o usuario con permiso de see_pdts, puedes seguir estos pasos para usar la página Tablas derivadas persistentes en la sección Administrador de Looker y obtener el nombre estable del modelo analítico para un modelo analítico:

  1. Haz clic en el ícono del menú principal de Looker y selecciona Administrador si el menú Administrador aún no se muestra. (Si estás en la sección Explorar o Desarrollar del Menú principal de Looker, es posible que debas hacer clic en la flecha hacia atrás para ver el menú Administrador).
  2. En el menú Administrador, selecciona Tablas derivadas persistentes.
  3. En la página Tablas derivadas persistentes, busca el nombre de tu modelo analítico.
  4. Haz clic en el menú de tres puntos de tu modelo analítico y, luego, selecciona Detalles del PDT.
  5. En la ventana modal Detalles del PDT, busca el campo Nombre estable.

Para consultar el modelo analítico estable directamente, agrega el nombre del esquema de borrador antes del nombre del modelo. Por ejemplo, si el nombre del esquema de borrador es tmp, puedes consultar el modelo analítico estable con un comando como este:

SELECT * from tmp.PA_bq_analytic_model_sales_semantic_view

Pestaña SQL de una exploración

Si no tienes acceso a la página de administrador de Persistent Derived Tables, puedes determinar el nombre estable a partir de la información que se incluye en la pestaña SQL de la sección Datos de una consulta de Explorar del modelo analítico. Sigue estos pasos para obtener el nombre estable de un modelo analítico:

  1. Abre la Explorar para la vista de tu modelo analítico.

  2. En la exploración, selecciona cualquier dimensión o medición del selector de campos.

  3. Haz clic en la pestaña SQL de la sección Datos.

  4. En la pestaña SQL, busca una de las siguientes instrucciones de SQL:

    • Para BigQuery Graph, haz lo siguiente:
      • CREATE PROPERTY GRAPH
      • SELECT ... FROM GRAPH_EXPAND('PROPERTY_GRAPH_NAME')
    • Para la vista semántica de Snowflake:
      • CREATE SEMANTIC VIEW
      • SELECT ... FROM SEMANTIC_VIEW_NAME

  5. El nombre estable es una vista que Looker crea en el esquema temporal y que apunta a la tabla ofuscada real que se muestra en la pestaña SQL. Para obtener el nombre estable de la vista analítica, completa la siguiente información de la instrucción de SQL:

    SCRATCH_SCHEMA_NAME.CONNECTION_REGISTRATION_KEY_MODEL_NAME_VIEW_NAME
    • SCRATCH_SCHEMA_NAME: El nombre del esquema de borrador es el comienzo de la cadena que sigue a la instrucción CREATE o SELECT, antes del ".".
    • CONNECTION_REGISTRATION_KEY: La clave de registro de la conexión tiene dos caracteres. Según el dialecto de la base de datos, seguirá un signo de dólar o el primer guion bajo en el nombre de la tabla en la instrucción CREATE o SELECT.
    • MODEL_NAME: Es el nombre del modelo de LookML.
    • VIEW_NAME: Es el nombre de la vista en la que se define el modelo analítico.

Por ejemplo, aquí se muestra el texto de la pestaña SQL de una consulta de Explorar para una conexión de BigQuery. El modelo analítico se define en la vista llamada sales_analytic_model, y el nombre del modelo de LookML es thelook. En este caso, Looker ya creó el modelo analítico, por lo que no hay ninguna declaración CREATE. Sin embargo, la instrucción SELECT ... FROM GRAPH_EXPAND contiene la información del nombre de la tabla:

-- use existing sales_analytic_model in `looker-test-db.looker_scratch.LG_J7LSZ1778710001008_sales_analytic_model`
SELECT
    sales_analytic_model.orders_id  AS sales_analytic_model_orders_id,
    AGG(sales_analytic_model.orders_count_orders ) AS sales_analytic_model_count_orders
FROM GRAPH_EXPAND("looker-test-db.looker_scratch.LG_J7LSZ1778710001008_sales_analytic_model") AS sales_analytic_model
GROUP BY
    1
ORDER BY
    2 DESC
LIMIT 500

Estos son los valores que necesitas para derivar el nombre estable del modelo analítico:

  • SCRATCH_SCHEMA_NAME es looker-test-db.looker_scratch
  • CONNECTION_REGISTRATION_KEY es J7
  • MODEL_NAME es thelook
  • VIEW_NAME es sales_analytic_model

Por lo tanto, el nombre estable del modelo analítico es el siguiente:

looker-test-db.looker_scratch.J7_thelook_sales_analytic_model

Una vez que tengas el nombre estable del modelo analítico, puedes consultarlo directamente.

Modelos analíticos derivados basados en LookML

Los modelos analíticos derivados basados en LookML te permiten definir un modelo analítico en la base de datos (como un gráfico de BigQuery o una vista semántica de Snowflake) directamente desde un Explore de LookML existente sin necesidad de escribir instrucciones DDL de SQL específicas de la base de datos.

Usa los siguientes parámetros para definir un modelo analítico derivado basado en LookML:

  • model_source
    • fields (subparámetro de model_source)
    • join (parámetro secundario de model_source; la unión en sí tiene parámetros secundarios)
  • publish_as_db_analytic_model (este parámetro se aplica a los modelos analíticos derivados basados en LookML y en SQL)

Para crear un modelo analítico derivado basado en LookML, usa el parámetro model_source para apuntar a una exploración fuente que defina tu topología de datos. Luego, Looker traduce automáticamente tus vistas, uniones, dimensiones y medidas de LookML en instrucciones DDL de modelos analíticos nativos de la base de datos:

  • Nodos / tablas: Cada vista de LookML en el Explore de origen se convierte en una tabla de nodos en BigQuery Graph o en una tabla en una vista semántica de Snowflake.
  • Bordes / Relaciones: Cada unión definida con el parámetro foreign_key en el Explore de origen se convierte en una tabla de borde en BigQuery Graph o en una relación en una vista semántica de Snowflake.
  • Propiedades, dimensiones y métricas: Las dimensiones y las medidas de LookML de las vistas de origen se convierten en propiedades de nodos en el gráfico de BigQuery o en dimensiones y métricas en una vista semántica de Snowflake.

Cuando consultas un Explorar basado en una vista de modelo analítico derivado basado en LookML, Looker genera y ejecuta el DDL de la base de datos para crear el modelo analítico en el esquema de trabajo de tu base de datos y, luego, ejecuta la consulta en el modelo analítico generado. Una vez que se crea el modelo analítico, Looker lo conserva para que las consultas posteriores hagan referencia directamente al modelo existente hasta que se modifique su definición de LookML.

model_source

El parámetro model_source especifica el nombre de la Exploración de LookML que sirve como fuente de topología y relaciones para el modelo analítico.

view: sales_analytic_model {
  derived_analytic_model: {
    model_source: order_items {
      fields: [order_items.id, orders.id, orders.status, users.name]
    }
  }
}

Las vistas que se incluyen en el Explorar de origen deben tener una clave primaria definida con primary_key: yes en su dimensión de clave primaria.

model_source acepta los siguientes subparámetros:

Parámetro Descripción
fields Es opcional. Especifica una lista de entidades permitidas o una lista de entidades bloqueadas de los campos de la exploración de origen para exportar al modelo analítico.
join (o joins) Es opcional. Define o refina las uniones de la exploración fuente específicamente para el modelo analítico.

fields

De forma predeterminada, todos los campos disponibles de las vistas en la exploración de origen se exportan al modelo analítico (es posible que algunos campos de la exploración de origen no estén disponibles si la exploración de origen se define con un parámetro fields). Puedes usar el subparámetro fields dentro de model_source para especificar un subconjunto de campos que se exportarán o para excluir campos específicos con la sintaxis de lista estándar de LookML:

  view: sales_analytic_model {
    derived_analytic_model: {
      model_source: order_items {
        fields: [
          order_items.id,
          order_items.price,
          orders.id,
          orders.status,
          users.name
        ]
      }
    }
  }

join

El parámetro join dentro de model_source te permite agregar ajustes a las uniones que ya se especificaron en la exploración fuente. Agregar ajustes te permite realizar modificaciones que se limitan exclusivamente al modelo analítico sin alterar la definición de Explore fuente.

En el parámetro join de model_source, especifica el nombre de una unión del Explorar fuente con el indicador de refinamiento +. Por ejemplo, join: +view_name. Luego, usa los subparámetros join para definir mejor la unión desde la exploración de origen según sea necesario en tu modelo analítico. Consulta el paso 2 para ver un ejemplo.

El parámetro join dentro de model_source solo admite refinamientos de unión. No puedes agregar una unión nueva al modelo analítico que no exista en la exploración fuente.

El parámetro join dentro de model_source admite los siguientes subparámetros:

Subparámetro Descripción
foreign_key Especifica la columna o dimensión de clave externa que establece la relación para el modelo analítico. Para ver un ejemplo con el parámetro foreign_key, consulta el ejemplo del paso 1.
relationship Define la cardinalidad de la unión (many_to_one, one_to_one, one_to_many o many_to_many).

Cómo configurar un modelo analítico derivado basado en LookML

Para configurar un modelo analítico derivado basado en LookML, sigue estos pasos:

  1. Define las vistas básicas y la exploración de origen con combinaciones foreign_key
  2. Crea la vista del modelo analítico derivado
  3. Define dimensiones y medidas de LookML en la vista del modelo analítico
  4. Crea una exploración para la vista del modelo analítico
  5. Cómo consultar el modelo analítico en Looker

Paso 1: Define las vistas básicas y el Explore de origen con uniones foreign_key

Primero, asegúrate de que tus vistas básicas (como order_items, orders y users) estén definidas con claves principales.

A continuación, define una exploración en tu archivo de modelo de LookML que especifique las relaciones entre las vistas. Establecer relaciones dentro de un modelo analítico integrado en la base de datos requiere estrictamente el parámetro foreign_key en cada unión de la exploración fuente:

explore: order_items {
  fields: [ALL_FIELDS*]

  join: orders {
    relationship: many_to_one
    foreign_key: order_id
  }

  join: users {
    relationship: many_to_one
    foreign_key: orders.user_id
  }
}

Paso 2: Crea la vista del modelo analítico derivado

Crea un nuevo archivo de vista (por ejemplo, sales_analytic_model.view.lkml) y agrega un bloque derived_analytic_model con el parámetro model_source que apunta a tu Explorar fuente:

view: sales_analytic_model {
  derived_analytic_model: {
    model_source: order_items {
      # Optional: Use fields to restrict the properties exported to the analytic model
      # fields: [order_items.id, orders.id, orders.status, users.name]

      # Optional: Use join refinements to refine the relationships from the source Explore
      # join: +orders {
      #   foreign_key: order_id
      # }
      # join: +users {
      #   foreign_key: orders.user_id
      # }
    }
  }
  ...

Paso 3: Define las dimensiones y medidas de LookML en la vista del modelo analítico

En el mismo archivo de vista del modelo analítico, define las dimensiones, los grupos de dimensiones y las medidas que se asignan a las propiedades del modelo analítico generado para que se puedan consultar en las Exploraciones de Looker.

Haz referencia a los campos del modelo subyacente con ${TABLE}.<view_name>_<field_name> (o ${TABLE}.<property_name>):

  # Dimensions
  dimension: order_items_id {
    type: number
    sql: ${TABLE}.order_items_id ;;
  }

  dimension: orders_id {
    type: number
    sql: ${TABLE}.orders_id ;;
  }

  dimension: orders_status {
    type: string
    sql: ${TABLE}.orders_status ;;
  }

  dimension_group: orders_created {
    type: time
    timeframes: [raw, time, date, week, month, quarter, year]
    sql: ${TABLE}.orders_created_at ;;
  }

  dimension: users_name {
    type: string
    sql: ${TABLE}.users_name ;;
  }

  dimension_group: users_created {
    type: time
    timeframes: [raw, time, date, week, month, quarter, year]
    sql: ${TABLE}.users_created_at ;;
  }

  # Measures
  measure: count_users {
    type: number
    sql: ${TABLE}.users_count_users ;;
  }

  measure: count_orders {
    type: number
    sql: ${TABLE}.orders_count_orders ;;
  }

  measure: total_order_amount {
    type: number
    sql: ${TABLE}.orders_total_order_amount ;;
  }

  measure: total_order_item_amount {
    type: number
    sql: ${TABLE}.order_items_total_order_item_amount ;;
  }
}

Paso 4: Crea un Explorar para la vista del modelo analítico

En tu archivo de modelo (como sales.model.lkml), crea un Explore para la vista del modelo analítico con el nombre de la vista:

explore: sales_analytic_model {}

Un Explore basado en una vista de modelo analítico no puede contener uniones, ya que las relaciones se definen internamente dentro del propio modelo analítico.

Paso 5: Consulta el modelo analítico en Looker

Abre la nueva exploración (por ejemplo, Sales Analytic Model) en Looker, selecciona dimensiones y medidas, y ejecuta tu consulta.

Para inspeccionar el código SQL generado, sigue estos pasos:

  1. Haz clic en la pestaña SQL del panel Datos.
  2. En la pestaña SQL, puedes ver la sentencia DDL específica de la base de datos que genera Looker (como CREATE PROPERTY GRAPH ... con NODE TABLES y EDGE TABLES para BigQuery Graph) y la consulta que se ejecuta en el modelo analítico (como FROM GRAPH_EXPAND(...) AS sales_analytic_model).
  3. Cuando se ejecuta la consulta, Looker conserva el modelo analítico en el esquema de trabajo de la base de datos. Las consultas posteriores reutilizan el modelo persistente, lo que evita la reejecución del DDL hasta que cambie la definición de LookML.

Consideraciones para los modelos analíticos derivados basados en LookML

Cuando definas modelos analíticos derivados basados en LookML, ten en cuenta las siguientes consideraciones:

  • Claves primarias: Cada vista en la Exploración de la fuente debe tener una dimensión de clave primaria que se defina con primary_key: yes.
  • Topología acíclica: Las relaciones que se definen mediante las uniones en la Exploración de origen deben formar una estructura de árbol acíclica estricta. No se admiten las relaciones cíclicas.
  • Requisitos de la vista de fuente: Las vistas que se incluyen en el Explorar de origen deben ser tablas de bases de datos estándar o tablas derivadas persistentes (PDT) con un nombre estable. Las tablas y vistas derivadas efímeras (no persistentes) que se basan en otros modelos analíticos no se pueden usar como fuentes.
  • Parámetros de exploración: Los parámetros de filtrado dinámico en el tiempo de ejecución (sql_always_where, always_filter, access_filter) y sql_always_join en la exploración de origen se ignoran durante la generación del modelo analítico.

Aspectos para tener en cuenta

Cuando uses modelos analíticos integrados en la base de datos, ten en cuenta las siguientes consideraciones y limitaciones:

  • Tipos de datos: Los modelos analíticos solo admiten los siguientes tipos de datos para las dimensiones y las métricas:

    • Se admiten las siguientes dimensiones y medidas:
      • string
      • number
      • date
      • yesno
    • Solo se admite para dimensiones:
      • time
      • date_time

  • Mediciones:

    • Las medidas básicas deben estar predefinidas: Las medidas básicas deben estar predefinidas en el modelo analítico de la base de datos subyacente. Looker no puede definir una nueva medida base realizando una agregación (como type: sum o type: count) en una dimensión de un modelo analítico.

    • Se admiten las medidas basadas en otras medidas: Puedes usar el parámetro sql de una medida de LookML para realizar cálculos no agregados que usen medidas básicas predefinidas del modelo analítico. Cuando creas una medida basada en otras medidas, no puedes definir la nueva medida como un tipo de medida agregada, como sum o count. Debes definir la nueva métrica como un tipo de métrica 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 basada en un modelo analítico no se puede unir a una exploración que tenga una vista base de LookML estándar.

  • Combinaciones implícitas: Las funciones que dependen de combinaciones implícitas no son compatibles con los modelos analíticos. Algunos ejemplos de funciones que se basan en 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: