derived_analytic_model

Utilisation

# 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
      }
    }
  }
}
Hiérarchie
view
derived_analytic_model
Valeur par défaut
Aucun

Règles spéciales
Les modèles analytiques ne sont compatibles qu'avec les connexions BigQuery et Snowflake.

Définition

Pour les connexions BigQuery et Snowflake, le paramètre derived_analytic_model définit un modèle analytique dans la base de données (un graphique BigQuery ou une vue sémantique dans Snowflake) géré par Looker.

Contrairement aux tables dérivées, les objets de modèle analytique gérés par Looker ne conservent aucune donnée dans la base de données et ne sont pas actualisés de manière incrémentielle. Au lieu de cela, ils représentent des modèles sémantiques qui définissent les relations et les mesures directement dans la base de données.

Looker est compatible avec deux types de modèles analytiques dérivés :

  • Modèles analytiques dérivés basés sur SQL : vous définissez le modèle analytique à l'aide d'instructions LDD (langage de définition de données) SQL. Looker génère le modèle analytique dans votre base de données en exécutant les instructions SQL que vous spécifiez.
  • Modèles analytiques dérivés basés sur LookML : vous définissez le modèle analytique en référençant une exploration LookML existante. Looker traduit automatiquement la topologie, les jointures, les dimensions et les mesures de votre exploration en instructions LDD de modèle analytique natif de la base de données, puis crée et gère le modèle dans votre base de données.

Modèles analytiques dérivés basés sur SQL

Dans un modèle analytique dérivé basé sur SQL, Looker génère le modèle analytique dans votre base de données en exécutant les instructions LDD (langage de définition de données) SQL appropriées que vous spécifiez dans la définition du paramètre LookML derived_analytic_model. La syntaxe SQL que vous définissez dans le paramètre derived_analytic_model doit être compatible avec votre base de données.

Pour définir un modèle analytique basé sur SQL, utilisez l'un des sous-paramètres suivants du paramètre derived_analytic_model :

De plus, si vous définissez votre vue analytique avec le sous-paramètre sql, vous pouvez utiliser le sous-paramètre publish_as_db_analytic_model du paramètre derived_analytic_model pour créer un modèle analytique stable pouvant être interrogé en dehors de Looker.

Une fois que vous avez défini le modèle analytique dans le paramètre derived_analytic_model, vous pouvez définir des dimensions et des mesures LookML qui correspondent à votre modèle analytique. Pour en savoir plus, consultez la section Exemples de modèles analytiques dérivés basés sur SQL.

sql

Utilisez le paramètre sql si vous souhaitez fournir le code SQL uniquement pour la définition du modèle analytique et laisser Looker gérer la création du modèle analytique. Lorsque vous utilisez le sous-paramètre sql, n'incluez pas d'instruction CREATE ni CREATE OR REPLACE, car Looker générera automatiquement l'instruction LDD pour créer le modèle analytique côté base de données.

Pour obtenir un exemple d'utilisation du paramètre sql afin de créer un modèle analytique sur votre base de données, consultez Créer un modèle analytique dérivé avec sql.

sql_create

Utilisez le paramètre sql_create pour définir une instruction SQL complète permettant de créer un modèle analytique. Lorsque vous utilisez le paramètre sql_create, vous devez inclure une instruction CREATE OR REPLACE (ou une instruction CREATE si votre dialecte ne prend pas en charge CREATE OR REPLACE).

Tenez compte des points suivants lorsque vous utilisez le sous-paramètre sql_create :

  • Pour les connexions BigQuery, utilisez une instruction CREATE OR REPLACE afin de créer le modèle analytique.
  • Utilisez ${SQL_TABLE_NAME} pour remplacer le nom calculé du modèle analytique en cours de création. Cela garantit que l'instruction SQL inclura correctement le nom du modèle analytique que vous fournissez dans le paramètre LookML view.

Pour obtenir un exemple d'utilisation du paramètre sql_create afin de créer un modèle analytique sur votre base de données, consultez Créer un modèle analytique dérivé avec sql_create.

create_process

Utilisez le paramètre create_process lorsque vous devez définir plusieurs instructions SQL séquentielles pour définir le modèle analytique. Sous le paramètre create_process, utilisez le sous-paramètre sql_step pour spécifier les instructions SQL individuelles. Votre base de données exécutera les instructions sql_step une par une, dans l'ordre dans lequel vous les avez spécifiées. Looker émet les instructions SQL dans les sous-paramètres sql_step tels que vous les définissez, sans wrapper. Cela signifie que vous devez inclure une étape avec une instruction CREATE OR REPLACE (ou une instruction CREATE si votre dialecte n'est pas compatible avec CREATE OR REPLACE).

Pour obtenir un exemple d'utilisation du paramètre create_process afin de créer un modèle analytique sur votre base de données, consultez Créer un modèle analytique dérivé avec create_process.

publish_as_db_analytic_model

Pour les modèles analytiques dérivés créés avec le paramètre sql, vous pouvez définir votre modèle analytique dérivé avec publish_as_db_analytic_model: yes pour inviter Looker à créer un modèle analytique stable pouvant être interrogé en dehors de Looker.

Le modèle analytique stable sera publié (créé) lors du prochain cycle du régénérateur Looker après le déploiement en production du LookML du modèle analytique dérivé avec publish_as_db_analytic_model: yes.

Lorsque vous spécifiez publish_as_db_analytic_model: yes, le régénérateur Looker crée deux modèles analytiques dans votre base de données : l'un avec un nom interne et l'autre avec un nom stable. Sinon, le régénérateur ne crée qu'un seul modèle analytique dans la base de données, en utilisant le nom interne.

Consultez la section Accéder au modèle analytique stable pour savoir comment obtenir le nom du modèle analytique stable afin de pouvoir l'utiliser pour interroger le modèle analytique stable en dehors de Looker.

Créer des dimensions et des mesures LookML basées sur votre vue analytique basée sur SQL

Une fois que vous avez défini votre modèle analytique, vous pouvez définir dans le même fichier d'affichage les dimensions et mesures LookML basées sur le modèle analytique.

Consultez la documentation de votre dialecte pour en savoir plus sur la syntaxe appropriée à utiliser pour définir votre modèle analytique et 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.

Exemples de modèles analytiques dérivés basés sur SQL

Les sections suivantes fournissent des exemples de création d'une vue analytique à l'aide des différents sous-paramètres de derived_analytic_model :

Créer un modèle analytique dérivé avec sql

Voici un exemple de fichier de vue LookML qui définit un modèle analytique basé sur SQL pour une base de données BigQuery à l'aide du sous-paramètre sql de derived_analytic_model. Looker créera le modèle analytique dans la base de données en exécutant les commandes SQL DDL fournies dans le paramètre sql.

Notez les points suivants dans l'exemple :

  • Le sous-paramètre sql ne contient que la définition du modèle analytique lui-même. Il n'y a pas d'instruction CREATE, car avec sql, Looker gère automatiquement les commandes CREATE pour le modèle analytique.
  • Le modèle analytique est défini avec publish_as_db_analytic_model: yes. Looker crée donc un modèle analytique stable qui peut être interrogé en dehors 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 ;; 
  }
}

Créer un modèle analytique dérivé avec create_process

Voici un exemple de fichier d'affichage LookML qui définit un modèle analytique basé sur SQL pour une base de données BigQuery à l'aide du sous-paramètre create_process de derived_analytic_model. Dans cet exemple, vous devez définir plusieurs instructions SQL séquentielles pour définir le modèle analytique. La première étape supprime le modèle analytique s'il existe déjà, et la deuxième étape le crée.

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 ;;
  }
  
  ...
}

Créer un modèle analytique dérivé avec sql_create

Voici un exemple de fichier d'affichage LookML qui définit un modèle analytique basé sur SQL pour une base de données BigQuery à l'aide du sous-paramètre sql_create de derived_analytic_model. Dans cet exemple, le paramètre sql_create définit l'instruction CREATE OR REPLACE complète à exécuter pour créer le modèle analytique en une seule étape.

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 ;;
  }

  ...

}

Accéder au modèle analytique stable

Si vous avez créé votre modèle analytique dérivé à l'aide du sous-paramètre sql et que vous avez inclus l'instruction publish_as_db_analytic_model: yes sous votre paramètre derived_analytic_model, Looker publiera (créera) le modèle analytique stable lors du prochain cycle du régénérateur Looker après le déploiement en production du LookML du modèle analytique dérivé avec publish_as_db_analytic_model: yes.

Une fois le modèle analytique stable publié, vous pouvez l'interroger directement à l'aide de son nom stable. Il existe deux façons d'obtenir le nom stable d'un modèle analytique :

Fenêtre modale des détails de la PDT

Si vous êtes administrateur ou utilisateur disposant de l'autorisation see_pdts, vous pouvez suivre ces étapes pour utiliser la page Tables dérivées persistantes dans la section Admin de Looker afin d'obtenir le nom stable du modèle analytique pour un modèle analytique :

  1. Cliquez sur l'icône Menu principal Looker , puis sélectionnez Admin si le menu Admin n'est pas déjà affiché. (Si vous vous trouvez dans la section Explorer ou Développer du menu principal de Looker, vous devrez peut-être cliquer sur la flèche "Retour" pour afficher le menu Admin.)
  2. Dans le menu Admin, sélectionnez Tables dérivées persistantes.
  3. Sur la page Tables dérivées persistantes, recherchez le nom de votre modèle analytique.
  4. Cliquez sur le menu à trois points de votre modèle analytique, puis sélectionnez Détails du PDT.
  5. Dans la fenêtre modale Détails du PDT, recherchez le champ Nom stable.

Pour interroger directement le modèle analytique stable, ajoutez le nom du schéma temporaire avant le nom du modèle. Par exemple, si le nom du schéma temporaire est tmp, vous pouvez interroger le modèle analytique stable avec une commande comme celle-ci :

SELECT * from tmp.PA_bq_analytic_model_sales_semantic_view

Onglet "SQL" d'une exploration

Si vous n'avez pas accès à la page d'administration Tables dérivées persistantes, vous pouvez déterminer le nom stable à partir des informations incluses dans l'onglet SQL de la section Données d'une requête Explorer du modèle analytique. Pour obtenir le nom stable d'un modèle analytique, procédez comme suit :

  1. Ouvrez l'Exploration pour la vue de votre modèle analytique.

  2. Dans "Explorer", sélectionnez des dimensions ou des mesures dans le sélecteur de champs.

  3. Cliquez sur l'onglet SQL de la section Données.

  4. Dans l'onglet SQL, recherchez l'une des instructions SQL suivantes :

    • Pour le graphique BigQuery :
      • CREATE PROPERTY GRAPH
      • SELECT ... FROM GRAPH_EXPAND('PROPERTY_GRAPH_NAME')
    • Pour la vue sémantique Snowflake :
      • CREATE SEMANTIC VIEW
      • SELECT ... FROM SEMANTIC_VIEW_NAME

  5. Le nom stable est une vue que Looker crée dans le schéma temporaire et qui pointe vers la table obscurcie réelle affichée dans l'onglet "SQL". Pour obtenir le nom stable de la vue analytique, renseignez les informations suivantes à partir de l'instruction SQL :

    SCRATCH_SCHEMA_NAME.CONNECTION_REGISTRATION_KEY_MODEL_NAME_VIEW_NAME
    • SCRATCH_SCHEMA_NAME : le nom du schéma de base est le début de la chaîne suivant l'instruction CREATE ou SELECT, avant ".".
    • CONNECTION_REGISTRATION_KEY : la clé d'enregistrement de la connexion comporte deux caractères. Selon le dialecte de votre base de données, elle suivra un signe dollar ou le premier trait de soulignement dans le nom de la table dans l'instruction CREATE ou SELECT.
    • MODEL_NAME : nom du modèle LookML.
    • VIEW_NAME : nom de la vue dans laquelle le modèle analytique est défini.

Par exemple, voici le texte de l'onglet SQL d'une requête Explorer pour une connexion BigQuery. Le modèle analytique est défini dans la vue nommée sales_analytic_model, et le nom du modèle LookML est thelook. Dans ce cas, Looker a déjà créé le modèle analytique. Il n'y a donc pas d'instruction CREATE. Toutefois, l'instruction SELECT ... FROM GRAPH_EXPAND contient les informations sur le nom de la table :

-- 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

Voici les valeurs dont vous avez besoin pour dériver le nom stable du modèle analytique :

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

Le nom stable du modèle analytique est donc le suivant :

looker-test-db.looker_scratch.J7_thelook_sales_analytic_model

Une fois que vous disposez du nom stable du modèle analytique, vous pouvez l'interroger directement.

Modèles analytiques dérivés basés sur LookML

Les modèles analytiques dérivés basés sur LookML vous permettent de définir un modèle analytique dans une base de données (comme un graphique BigQuery ou une vue sémantique Snowflake) directement à partir d'une exploration LookML existante, sans avoir à écrire d'instructions SQL DDL spécifiques à la base de données.

Utilisez les paramètres suivants pour définir un modèle analytique dérivé basé sur LookML :

  • model_source
    • fields (sous-paramètre de model_source)
    • join (sous-paramètre de model_source ; la jointure elle-même comporte des sous-paramètres)
  • publish_as_db_analytic_model (ce paramètre s'applique aux modèles analytiques dérivés basés sur LookML et sur SQL)

Pour créer un modèle analytique dérivé basé sur LookML, vous utilisez le paramètre model_source pour pointer vers une exploration source qui définit votre topologie de données. Looker traduit ensuite automatiquement vos vues, jointures, dimensions et mesures LookML en instructions LDD de modèle analytique natif de la base de données :

  • Nœuds / Tables : chaque vue LookML dans l'exploration source devient une table de nœuds dans BigQuery Graph ou une table dans une vue sémantique Snowflake.
  • Relations / Arêtes : chaque jointure définie avec le paramètre foreign_key dans l'exploration source devient une table d'arêtes dans BigQuery Graph ou une relation dans une vue sémantique Snowflake.
  • Propriétés / Dimensions et métriques : les dimensions et les mesures LookML des vues sources deviennent des propriétés de nœud dans BigQuery Graph ou des dimensions et des métriques dans une vue sémantique Snowflake.

Lorsque vous interrogez une exploration basée sur une vue de modèle analytique dérivée basée sur LookML, Looker génère et exécute le LDD de la base de données pour créer le modèle analytique dans le schéma temporaire de votre base de données, puis exécute la requête sur le modèle analytique généré. Une fois le modèle analytique créé, Looker le conserve afin que les requêtes ultérieures fassent directement référence au modèle existant jusqu'à ce que sa définition LookML soit modifiée.

model_source

Le paramètre model_source spécifie le nom de l'exploration LookML qui sert de source de topologie et de relations pour le modèle analytique.

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

Les vues incluses dans l'exploration source doivent comporter une clé primaire définie à l'aide de primary_key: yes sur leur dimension de clé primaire.

model_source accepte les sous-paramètres suivants :

Paramètre Description
fields Facultatif. Spécifie une liste d'autorisation ou de refus des champs de l'exploration source à exporter vers le modèle analytique.
join (ou joins) Facultatif. Définit ou affine les jointures de l'exploration source spécifiquement pour le modèle analytique.

fields

Par défaut, tous les champs disponibles dans les vues de l'exploration source sont exportés vers le modèle analytique (il est possible que certains champs de l'exploration source ne soient pas disponibles si l'exploration source elle-même est définie avec un paramètre fields). Vous pouvez utiliser le sous-paramètre fields dans model_source pour spécifier un sous-ensemble de champs à exporter ou pour exclure des champs spécifiques à l'aide de la syntaxe de liste LookML standard :

  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

Le paramètre join dans model_source vous permet d'ajouter des précisions aux jointures déjà spécifiées dans l'exploration source. L'ajout d'affinements vous permet d'effectuer des ajustements qui ne s'appliquent qu'au modèle analytique, sans modifier la définition Explore source.

Dans le paramètre join sous model_source, spécifiez le nom d'une jointure à partir de l'exploration source avec l'indicateur d'affinage +. Par exemple, join: +view_name. Utilisez ensuite les sous-paramètres join pour affiner la jointure à partir de l'exploration source selon vos besoins dans votre modèle analytique. Pour obtenir un exemple, consultez l'étape 2.

Le paramètre join dans model_source n'accepte que les affinements de jointure. Vous ne pouvez pas ajouter de jointure au modèle analytique si elle n'existe pas déjà dans l'exploration source.

Le paramètre join dans model_source accepte les sous-paramètres suivants :

Sous-paramètre Description
foreign_key Spécifie la colonne ou la dimension de clé étrangère qui établit la relation pour le modèle analytique. Pour obtenir un exemple avec le paramètre foreign_key, consultez l'exemple de l'étape 1.
relationship Définit la cardinalité de la jointure (many_to_one, one_to_one, one_to_many ou many_to_many).

Configurer un modèle analytique dérivé basé sur LookML

Pour configurer un modèle analytique dérivé basé sur LookML, procédez comme suit :

  1. Définir les vues de base et l'exploration source avec des jointures foreign_key
  2. Créer la vue du modèle analytique dérivé
  3. Définir des dimensions et des mesures LookML dans la vue du modèle analytique
  4. Créer une exploration pour la vue du modèle analytique
  5. Interroger le modèle analytique dans Looker

Étape 1 : Définissez les vues de base et l'exploration source avec des jointures foreign_key

Tout d'abord, assurez-vous que vos vues de base (telles que order_items, orders et users) sont définies avec des clés primaires.

Ensuite, définissez une exploration dans votre fichier de modèle LookML qui spécifie les relations entre les vues. Pour établir des relations dans un modèle analytique intégré à une base de données, vous devez impérativement utiliser le paramètre foreign_key sur chaque jointure dans l'exploration source :

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
  }
}

Étape 2 : Créez la vue du modèle analytique dérivé

Créez un fichier de vue (par exemple, sales_analytic_model.view.lkml) et ajoutez un bloc derived_analytic_model avec le paramètre model_source qui pointe vers votre source Explorer :

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
      # }
    }
  }
  ...

Étape 3 : Définissez les dimensions et les mesures LookML dans la vue du modèle analytique

Dans le même fichier d'affichage de modèle analytique, définissez les dimensions, les groupes de dimensions et les mesures qui correspondent aux propriétés du modèle analytique généré afin qu'elles puissent être interrogées dans les explorations Looker.

Référencez les champs du modèle sous-jacent à l'aide de ${TABLE}.<view_name>_<field_name> (ou ${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 ;;
  }
}

Étape 4 : Créez une exploration pour la vue du modèle analytique

Dans votre fichier de modèle (par exemple, sales.model.lkml), créez une exploration pour la vue du modèle analytique en utilisant le nom de la vue :

explore: sales_analytic_model {}

Une exploration basée sur une vue de modèle analytique ne peut pas contenir de jointures, car les relations sont définies en interne dans le modèle analytique lui-même.

Étape 5 : Interroger le modèle analytique dans Looker

Ouvrez la nouvelle exploration (par exemple, Modèle d'analyse des ventes) dans Looker, sélectionnez des dimensions et des mesures, puis exécutez votre requête.

Pour inspecter le code SQL généré, procédez comme suit :

  1. Cliquez sur l'onglet SQL dans le panneau Données.
  2. Dans l'onglet SQL, vous pouvez afficher l'instruction LDD spécifique à la base de données que Looker génère (par exemple, CREATE PROPERTY GRAPH ... avec NODE TABLES et EDGE TABLES pour BigQuery Graph) et la requête exécutée sur le modèle analytique (par exemple, FROM GRAPH_EXPAND(...) AS sales_analytic_model).
  3. Lorsque la requête s'exécute, Looker conserve le modèle analytique dans le schéma temporaire de la base de données. Les requêtes suivantes réutilisent le modèle persistant, ce qui évite la réexécution du LDD jusqu'à ce que la définition LookML change.

Éléments à prendre en compte pour les modèles analytiques dérivés basés sur LookML

Lorsque vous définissez des modèles analytiques dérivés basés sur LookML, tenez compte des points suivants :

  • Clés primaires : chaque vue de l'Explore source doit comporter une dimension de clé primaire définie à l'aide de primary_key: yes.
  • Topologie acyclique : les relations définies par les jointures dans l'exploration source doivent former une structure arborescente acyclique stricte. Les relations cycliques ne sont pas acceptées.
  • Exigences concernant la vue source : les vues incluses dans l'exploration source doivent être des tables de base de données standards ou des tables dérivées persistantes (PDT) avec un nom stable. Les tables et vues dérivées éphémères (non persistantes) basées sur d'autres modèles analytiques ne peuvent pas être utilisées comme sources.
  • Paramètres d'exploration : les paramètres de filtrage dynamique de l'exécution (sql_always_where, always_filter, access_filter) et sql_always_join dans l'exploration source sont ignorés lors de la génération du modèle analytique.

Éléments à prendre en compte

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 reposent 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 :