derived_analytic_model

Nutzung

# 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
      }
    }
  }
}
Hierarchie
view
derived_analytic_model
Standardwert
Keine

Besondere Regeln
Analytische Modelle werden nur für BigQuery- und Snowflake-Verbindungen unterstützt.

Definition

Bei BigQuery- und Snowflake-Verbindungen wird mit dem Parameter derived_analytic_model ein In-Database-Analysemodell (ein BigQuery-Diagramm oder eine semantische Ansicht in Snowflake) definiert, das von Looker verwaltet wird.

Im Gegensatz zu abgeleiteten Tabellen werden in Looker-verwalteten Analysemodellobjekten keine Daten in der Datenbank gespeichert und sie werden nicht inkrementell aktualisiert. Stattdessen stellen sie semantische Modelle dar, in denen Beziehungen und Messwerte direkt in der Datenbank definiert werden.

Looker unterstützt zwei Arten von abgeleiteten Analysemodellen:

SQL-basierte abgeleitete Analysemodelle

Bei einem SQL-basierten abgeleiteten Analysemodell generiert Looker das Analysemodell in Ihrer Datenbank, indem die entsprechenden SQL-DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) ausgeführt werden, die Sie in der Definition des LookML-Parameters derived_analytic_model angeben. Die SQL-Syntax, die Sie im Parameter derived_analytic_model definieren, muss von Ihrer Datenbank unterstützt werden.

Verwenden Sie einen der folgenden Unterparameter des Parameters derived_analytic_model, um ein SQL-basiertes Analysemodell zu definieren:

Wenn Sie Ihre Analyseansicht mit dem Unterparameter sql definieren, können Sie außerdem mit dem Unterparameter publish_as_db_analytic_model des Parameters derived_analytic_model ein stabiles Analysemodell erstellen, das außerhalb von Looker abgefragt werden kann.

Nachdem Sie das Analysemodell im Parameter derived_analytic_model definiert haben, können Sie LookML-Dimensionen und ‑Measures definieren, die Ihrem Analysemodell zugeordnet werden. Weitere Informationen finden Sie im Abschnitt Beispiele für abgeleitete Analysemodelle auf SQL-Basis.

sql

Verwenden Sie den Parameter sql, wenn Sie nur den SQL-Code für die Definition des Analysemodells angeben und die Erstellung des Analysemodells von Looker verwalten lassen möchten. Wenn Sie den Unterparameter sql verwenden, dürfen Sie keine CREATE- oder CREATE OR REPLACE-Anweisung einfügen, da Looker die DDL-Anweisung zum Erstellen des Analysemodells auf der Datenbankseite automatisch generiert.

Ein Beispiel für die Verwendung des Parameters sql zum Erstellen eines Analysemodells für Ihre Datenbank finden Sie unter Abgeleitetes Analysemodell mit sql erstellen.

sql_create

Mit dem Parameter sql_create können Sie eine vollständige SQL-Anweisung zum Erstellen eines Analysemodells definieren. Wenn Sie den Parameter sql_create verwenden, müssen Sie eine CREATE OR REPLACE-Anweisung (oder eine CREATE-Anweisung, wenn Ihr Dialekt CREATE OR REPLACE nicht unterstützt) einfügen.

Beachten Sie bei der Verwendung des Unterparameters sql_create Folgendes:

  • Verwenden Sie für BigQuery-Verbindungen eine CREATE OR REPLACE-Anweisung, um das Analysemodell zu erstellen.
  • Verwenden Sie ${SQL_TABLE_NAME}, um den berechneten Namen des zu erstellenden Analysemodells einzufügen. So wird sichergestellt, dass der Name des Analysemodells, den Sie im LookML-Parameter view angeben, korrekt in die SQL-Anweisung aufgenommen wird.

Ein Beispiel für die Verwendung des Parameters sql_create zum Erstellen eines Analysemodells für Ihre Datenbank finden Sie unter Abgeleitetes Analysemodell mit sql_create erstellen.

create_process

Verwenden Sie den Parameter create_process, wenn Sie mehrere aufeinanderfolgende SQL-Anweisungen zum Definieren des Analysemodells benötigen. Verwenden Sie unter dem Parameter create_process den Unterparameter sql_step, um die einzelnen SQL-Anweisungen anzugeben. Ihre Datenbank führt die sql_step-Anweisungen nacheinander in der von Ihnen angegebenen Reihenfolge aus. Looker gibt die SQL-Anweisungen in den Unterparametern sql_step so aus, wie Sie sie definieren, ohne Wrapper. Das bedeutet, dass Sie einen Schritt mit einer CREATE OR REPLACE-Anweisung (oder einer CREATE-Anweisung, wenn Ihr Dialekt CREATE OR REPLACE nicht unterstützt) einfügen müssen.

Ein Beispiel für die Verwendung des Parameters create_process zum Erstellen eines Analysemodells für Ihre Datenbank finden Sie unter Abgeleitetes Analysemodell mit create_process erstellen.

publish_as_db_analytic_model

Für abgeleitete Analysemodelle, die mit dem Parameter sql erstellt werden, können Sie Ihr abgeleitetes Analysemodell mit publish_as_db_analytic_model: yes definieren, damit Looker ein stabiles Analysemodell erstellt, das außerhalb von Looker abgefragt werden kann.

Das stabile Analysemodell wird im nächsten Zyklus des Looker-Regenerators veröffentlicht (erstellt), nachdem die LookML des abgeleiteten Analysemodells mit publish_as_db_analytic_model: yes in der Produktionsumgebung bereitgestellt wurde.

Wenn Sie publish_as_db_analytic_model: yes angeben, erstellt der Looker-Regenerator zwei Analysemodelle in Ihrer Datenbank: eines mit einem internen Namen und eines mit einem stabilen Namen. Andernfalls wird nur ein Analysemodell mit dem internen Namen in der Datenbank erstellt.

Im Abschnitt Auf das stabile Analysemodell zugreifen finden Sie Informationen dazu, wie Sie den Namen des stabilen Analysemodells abrufen können, damit Sie das Modell außerhalb von Looker abfragen können.

LookML-Dimensionen und ‑Messwerte basierend auf Ihrer SQL-basierten Analyseansicht erstellen

Nachdem Sie Ihr Analysemodell definiert haben, können Sie in derselben Ansichtsdatei LookML-Dimensionen und ‑Messwerte definieren, die auf dem Analysemodell basieren.

Informationen zur richtigen Syntax zum Definieren Ihres Analysemodells und zum Verweisen auf Elemente in Ihrem Analysemodell finden Sie in der Dokumentation Ihres Dialekts. Wenn Sie beispielsweise eine LookML-Dimension aus einer BigQuery Graph-Entität erstellen möchten, müssen Sie Unterstriche verwenden, um Elemente beim Festlegen des Bereichs zu trennen. Für BigQuery Graph basiert diese LookML-Dimension beispielsweise auf dem Attribut location_id in der Knotentabelle Stores:

  dimension: location_id {
    type: number
    sql: Stores_location_id ;;
  }

Wenn Sie jedoch eine LookML-Dimension erstellen möchten, die auf einer semantischen Snowflake-Ansicht basiert, müssen Sie den nicht qualifizierten Namen eines Messwerts oder einer Dimension verwenden.

Beispiele für SQL-basierte abgeleitete Analysemodelle

In den folgenden Abschnitten finden Sie Beispiele für das Erstellen einer Analyseansicht mit den verschiedenen Unterparametern von derived_analytic_model:

Abgeleitetes Analysemodell mit sql erstellen

Im Folgenden sehen Sie ein Beispiel für eine LookML-Ansichtsdatei, in der ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mit dem Unterparameter sql von derived_analytic_model definiert wird. Looker erstellt das Analysemodell in der Datenbank, indem die im Parameter sql angegebenen SQL-DDL-Befehle ausgeführt werden.

Beachten Sie im Beispiel Folgendes:

  • Der Unterparameter sql enthält nur die Definition des Analysemodells selbst. Es gibt keine CREATE-Anweisung, da Looker mit sql die CREATE-Befehle für das Analysemodell automatisch verarbeitet.
  • Das Analysemodell wird mit publish_as_db_analytic_model: yes definiert. Looker erstellt also ein stabiles Analysemodell, das außerhalb von Looker abgefragt werden kann.
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 ;; 
  }
}

Abgeleitetes Analysemodell mit create_process erstellen

Im Folgenden sehen Sie ein Beispiel für eine LookML-Ansichtsdatei, in der ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mit dem Unterparameter create_process von derived_analytic_model definiert wird. In diesem Beispiel müssen Sie mehrere aufeinanderfolgende SQL-Anweisungen definieren, um das Analysemodell zu definieren. Im ersten Schritt wird das Analysemodell gelöscht, falls es bereits vorhanden ist, und im zweiten Schritt wird es erstellt.

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

Abgeleitetes Analysemodell mit sql_create erstellen

Im Folgenden sehen Sie ein Beispiel für eine LookML-Ansichtsdatei, in der ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mit dem Unterparameter sql_create von derived_analytic_model definiert wird. In diesem Beispiel definiert der Parameter sql_create die vollständige CREATE OR REPLACE-Anweisung, die ausgeführt werden soll, um das Analysemodell in einem einzigen Schritt zu erstellen.

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

  ...

}

Auf das stabile Analysemodell zugreifen

Wenn Sie Ihr abgeleitetes Analysemodell mit dem Unterparameter sql erstellt und die Anweisung publish_as_db_analytic_model: yes unter dem Parameter derived_analytic_model eingefügt haben, wird das stabile Analysemodell im nächsten Zyklus des Looker-Regenerators veröffentlicht (erstellt), nachdem die LookML des abgeleiteten Analysemodells mit publish_as_db_analytic_model: yes in der Produktionsumgebung bereitgestellt wurde.

Wenn das stabile Analysemodell veröffentlicht wird, können Sie es direkt über seinen stabilen Namen abfragen. Es gibt zwei Möglichkeiten, den stabilen Namen für ein Analysemodell zu ermitteln:

Modales Fenster mit PAT-Details

Wenn Sie ein Administrator oder ein Nutzer mit der Berechtigung see_pdts sind, können Sie die folgende Anleitung verwenden, um den stabilen Namen des Analysemodells für ein Analysemodell auf der Seite Persistent Derived Tables (Abgeleitete Tabellen mit Persistenz) im Bereich Admin von Looker abzurufen:

  1. Klicken Sie auf das Symbol für das Hauptmenü  und wählen Sie Admin aus, falls das Menü Admin nicht bereits angezeigt wird. Wenn Sie sich im Hauptmenü von Looker im Bereich Explore oder Entwickeln befinden, müssen Sie möglicherweise auf den Rückwärtspfeil klicken, um das Menü Admin aufzurufen.
  2. Wählen Sie im Menü Admin die Option Persistente abgeleitete Tabellen aus.
  3. Suchen Sie auf der Seite Persistente abgeleitete Tabellen nach dem Namen Ihres Analysemodells.
  4. Klicken Sie auf das Dreipunkt-Menü für Ihr Analysemodell und wählen Sie PDT-Details aus.
  5. Suchen Sie im PDT Details-Modal nach dem Feld Stable Name.

Wenn Sie das stabile Analysemodell direkt abfragen möchten, fügen Sie den Namen des Scratch-Schemas vor dem Modellnamen ein. Wenn der Name des Scratch-Schemas beispielsweise tmp ist, können Sie das stabile Analysemodell mit einem Befehl wie diesem abfragen:

SELECT * from tmp.PA_bq_analytic_model_sales_semantic_view

Tab „SQL“ eines Explores

Wenn Sie keinen Zugriff auf die Seite Persistent Derived Tables haben, können Sie den stabilen Namen anhand der Informationen ermitteln, die auf dem Tab SQL im Bereich Daten einer Explore-Abfrage des Analysemodells enthalten sind. So rufen Sie den stabilen Namen für ein Analysemodell ab:

  1. Öffnen Sie die Explore für die Ansicht Ihres Analysemodells.

  2. Wählen Sie im Explore Dimensionen oder Messwerte aus der Feldauswahl aus.

  3. Klicken Sie im Bereich Daten auf den Tab SQL.

  4. Suchen Sie auf dem Tab SQL nach einer der folgenden SQL-Anweisungen:

    • Für BigQuery Graph:
      • CREATE PROPERTY GRAPH
      • SELECT ... FROM GRAPH_EXPAND('PROPERTY_GRAPH_NAME')
    • Für semantische Ansichten in Snowflake:
      • CREATE SEMANTIC VIEW
      • SELECT ... FROM SEMANTIC_VIEW_NAME

  5. Der stabile Name ist eine Ansicht, die Looker im Scratch-Schema erstellt und die auf die tatsächliche verschleierte Tabelle auf dem Tab „SQL“ verweist. Geben Sie die folgenden Informationen aus der SQL-Anweisung ein, um den stabilen Namen für die Analyseansicht zu erhalten:

    SCRATCH_SCHEMA_NAME.CONNECTION_REGISTRATION_KEY_MODEL_NAME_VIEW_NAME
    • SCRATCH_SCHEMA_NAME: Der Name des Scratch-Schemas ist der Anfang des Strings nach der CREATE- oder SELECT-Anweisung, vor dem „.“.
    • CONNECTION_REGISTRATION_KEY: Der Schlüssel für die Verbindungsregistrierung besteht aus zwei Zeichen. Je nach Datenbankdialekt folgt er entweder einem Dollarzeichen oder dem ersten Unterstrich im Tabellennamen in der CREATE- oder SELECT-Anweisung.
    • MODEL_NAME: Der Name des LookML-Modells.
    • VIEW_NAME: Der Name der Ansicht, in der das Analysemodell definiert ist.

Hier sehen Sie beispielsweise den Text auf dem Tab SQL einer Explore-Abfrage für eine BigQuery-Verbindung. Das Analysemodell ist in der Ansicht mit dem Namen sales_analytic_model definiert und der Name des LookML-Modells ist thelook. In diesem Fall hat Looker das Analysemodell bereits erstellt, sodass es keine CREATE-Anweisung gibt. Die SELECT ... FROM GRAPH_EXPAND-Anweisung enthält jedoch die Informationen zum Tabellennamen:

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

Hier sind die Werte, die Sie zum Ableiten des stabilen Namens des Analysemodells benötigen:

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

Der stabile Name für das Analysemodell lautet daher:

looker-test-db.looker_scratch.J7_thelook_sales_analytic_model

Sobald Sie den stabilen Namen des Analysemodells haben, können Sie das Analysemodell direkt abfragen.

LookML-basierte abgeleitete Analysemodelle

Mit LookML-basierten abgeleiteten Analysemodellen können Sie ein In-Database-Analysemodell (z. B. ein BigQuery-Diagramm oder eine semantische Snowflake-Ansicht) direkt aus einem vorhandenen LookML-Explore definieren, ohne datenbankspezifische SQL-DDL-Anweisungen schreiben zu müssen.

Verwenden Sie die folgenden Parameter, um ein LookML-basiertes abgeleitetes Analysemodell zu definieren:

  • model_source
    • fields (Unterparameter von model_source)
    • join (Unterparameter von model_source; Join selbst hat Unterparameter)
  • publish_as_db_analytic_model (Dieser Parameter gilt sowohl für LookML-basierte als auch für SQL-basierte abgeleitete Analysemodelle.)

Wenn Sie ein LookML-basiertes abgeleitetes Analysemodell erstellen möchten, verwenden Sie den Parameter model_source, um auf einen Quell-Explore zu verweisen, der Ihre Datentopologie definiert. Looker übersetzt dann automatisch Ihre LookML-Ansichten, Joins, Dimensionen und Measures in DDL-Anweisungen für das native Analysemodell der Datenbank:

  • Knoten / Tabellen:Jede LookML-Ansicht im Quell-Explore wird zu einer Knotentabelle in BigQuery Graph oder zu einer Tabelle in einer semantischen Snowflake-Ansicht.
  • Kanten / Beziehungen:Jeder Join, der mit dem Parameter foreign_key im Quell-Explore definiert ist, wird zu einer Kantentabelle in BigQuery Graph oder zu einer Beziehung in einer semantischen Snowflake-Ansicht.
  • Attribute / Dimensionen und Messwerte:LookML-Dimensionen und ‑Messwerte aus den Quellansichten werden zu Knotenattributen in BigQuery Graph oder zu Dimensionen und Messwerten in einer semantischen Snowflake-Ansicht.

Wenn Sie eine Explore-Funktion abfragen, die auf einer LookML-basierten abgeleiteten Ansicht des Analysemodells basiert, generiert und führt Looker das Datenbank-DDL aus, um das Analysemodell in Ihrem Datenbank-Scratch-Schema zu erstellen. Anschließend wird die Abfrage für das generierte Analysemodell ausgeführt. Sobald das Analysemodell erstellt wurde, wird es in Looker gespeichert, sodass nachfolgende Abfragen direkt auf das vorhandene Modell verweisen, bis die LookML-Definition geändert wird.

model_source

Der Parameter model_source gibt den Namen des LookML-Explores an, der als Topologie- und Beziehungsquelle für das Analysemodell dient.

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

Ansichten, die im Quell-Explore enthalten sind, müssen einen Primärschlüssel haben, der mit primary_key: yes für die zugehörige Dimension definiert ist.

model_source akzeptiert die folgenden Unterparameter:

Parameter Beschreibung
fields Optional. Gibt eine Zulassungs- oder Sperrliste von Feldern aus dem Quell-Explore an, die in das Analysemodell exportiert werden sollen.
join (oder joins) Optional. Definiert oder optimiert Joins aus dem Quell-Explore speziell für das Analysemodell.

fields

Standardmäßig werden alle verfügbaren Felder aus den Ansichten im Quell-Explore in das Analysemodell exportiert. Einige Felder aus dem Quell-Explore sind möglicherweise nicht verfügbar, wenn das Quell-Explore selbst mit dem Parameter fields definiert ist. Mit dem Unterparameter fields in model_source können Sie eine Teilmenge der zu exportierenden Felder angeben oder bestimmte Felder mit der Standard-LookML-Listensyntax ausschließen:

  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

Mit dem Parameter join in model_source können Sie die Joins, die bereits im Quell-Explore angegeben sind, weiter verfeinern. Durch das Hinzufügen von Verfeinerungen können Sie Anpassungen vornehmen, die sich ausschließlich auf das Analysemodell beziehen, ohne die Explore-Quelldefinition zu ändern.

Geben Sie im Parameter join unter model_source den Namen eines Joins aus dem Quell-Explore mit dem +-Verfeinerungsindikator an. Beispiel: join: +view_name Verwenden Sie dann die join-Unterparameter, um den Join aus dem Quell-Explore nach Bedarf in Ihrem Analysemodell zu optimieren. Ein Beispiel finden Sie in Schritt 2.

Der Parameter join in model_source akzeptiert nur Join-Verfeinerungen. Sie können dem Analysemodell keinen neuen Join hinzufügen, der noch nicht im Quell-Explore vorhanden ist.

Der Parameter join in model_source unterstützt die folgenden Unterparameter:

Unterparameter Beschreibung
foreign_key Gibt die Fremdschlüsselspalte oder ‑dimension an, mit der die Beziehung für das Analysemodell hergestellt wird. Ein Beispiel mit dem Parameter foreign_key finden Sie im Beispiel in Schritt 1.
relationship Definiert die Join-Kardinalität (many_to_one, one_to_one, one_to_many oder many_to_many).

LookML-basiertes abgeleitetes Analysemodell einrichten

So richten Sie ein LookML-basiertes abgeleitetes Analysemodell ein:

  1. Basisansichten und Quell-Explore mit foreign_key-Joins definieren
  2. Abgeleitete Analysemodellansicht erstellen
  3. LookML-Dimensionen und ‑Messwerte in der Ansicht des Analysemodells definieren
  4. Explore für die Ansicht des Analysemodells erstellen
  5. Analytisches Modell in Looker abfragen

Schritt 1: Basisansichten und Quell-Explore mit foreign_key-Joins definieren

Prüfen Sie zuerst, ob Ihre Basisansichten (z. B. order_items, orders und users) mit Primärschlüsseln definiert sind.

Als Nächstes definieren Sie ein Explore in Ihrer LookML-Modelldatei, in dem die Beziehungen zwischen den Ansichten angegeben werden. Um Beziehungen in einem In-Database-Analysemodell zu erstellen, ist der Parameter foreign_key für jeden Join im Quell-Explore erforderlich:

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

Schritt 2: Abgeleitete Analysemodellansicht erstellen

Erstellen Sie eine neue Ansichtsdatei (z. B. sales_analytic_model.view.lkml) und fügen Sie einen derived_analytic_model-Block mit dem Parameter model_source hinzu, der auf Ihr Quell-Explore verweist:

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

Schritt 3: LookML-Dimensionen und ‑Messwerte in der Ansicht des Analysemodells definieren

Definieren Sie in derselben Ansichtsdatei des Analysemodells die Dimensionen, Dimensionsgruppen und Messwerte, die den Eigenschaften im generierten Analysemodell zugeordnet werden, damit sie in Looker-Explores abgefragt werden können.

Verweisen Sie mit ${TABLE}.<view_name>_<field_name> (oder ${TABLE}.<property_name>) auf Felder aus dem zugrunde liegenden Modell:

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

Schritt 4: Explore für die Ansicht des Analysemodells erstellen

Erstellen Sie in Ihrer Modelldatei (z. B. sales.model.lkml) einen Explore für die Ansicht des Analysemodells mit dem Namen der Ansicht:

explore: sales_analytic_model {}

Ein Explore, das auf einer Ansicht des Analysemodells basiert, kann keine Joins enthalten, da die Beziehungen intern im Analysemodell selbst definiert sind.

Schritt 5: Analytisches Modell in Looker abfragen

Öffnen Sie die neue Explore-Ansicht (z. B. Sales Analytic Model) in Looker, wählen Sie Dimensionen und Messwerte aus und führen Sie die Abfrage aus.

So prüfen Sie den generierten SQL-Code:

  1. Klicken Sie im Bereich Daten auf den Tab SQL.
  2. Auf dem Tab SQL können Sie die datenbankspezifische DDL-Anweisung sehen, die von Looker generiert wird (z. B. CREATE PROPERTY GRAPH ... mit NODE TABLES und EDGE TABLES für BigQuery Graph), sowie die Abfrage, die für das Analysemodell ausgeführt wird (z. B. FROM GRAPH_EXPAND(...) AS sales_analytic_model).
  3. Wenn die Abfrage ausgeführt wird, speichert Looker das Analysemodell im Scratch-Schema der Datenbank. Bei nachfolgenden Abfragen wird das persistente Modell wiederverwendet. So wird die DDL erst dann neu ausgeführt, wenn sich die LookML-Definition ändert.

Hinweise zu LookML-basierten abgeleiteten Analysemodellen

Beachten Sie beim Definieren von abgeleiteten Analysemodellen auf LookML-Basis Folgendes:

  • Primärschlüssel:Jede Ansicht im Quell-Explore muss eine Primärschlüsseldimension haben, die mit primary_key: yes definiert wird.
  • Azyklische Topologie:Die Beziehungen, die durch Joins im Quell-Explore definiert werden, müssen eine streng azyklische Baumstruktur bilden. Zyklische Beziehungen werden nicht unterstützt.
  • Anforderungen an die Quellansicht:Ansichten, die im Quell-Explore enthalten sind, müssen Standarddatenbanktabellen oder persistent abgeleitete Tabellen (Persistent Derived Tables, PDTs) mit einem stabilen Namen sein. Kurzlebige (nicht persistente) abgeleitete Tabellen und Ansichten, die auf anderen Analysemodellen basieren, können nicht als Quellen verwendet werden.
  • Explore-Parameter:Dynamische Laufzeitfilterparameter (sql_always_where, always_filter, access_filter) und sql_always_join im Quell-Explore werden bei der Generierung des Analysemodells ignoriert.

Wichtige Punkte

Beachten Sie bei der Verwendung von In-Database-Analysemodellen die folgenden Hinweise und Einschränkungen:

  • Datentypen:Für Analysemodelle werden nur die folgenden Datentypen für Dimensionen und Messwerte unterstützt:

    • Unterstützt für Dimensionen und Messwerte:
      • string
      • number
      • date
      • yesno
    • Nur für Dimensionen unterstützt:
      • time
      • date_time

  • Messungen:

    • Basismesswerte müssen vordefiniert sein:Basismesswerte müssen im zugrunde liegenden analytischen Datenbankmodell vordefiniert sein. In Looker kann kein neuer Basismesswert definiert werden, indem eine Aggregation (z. B. type: sum oder type: count) für eine Dimension aus einem Analysemodell ausgeführt wird.

    • Messwerte, die auf anderen Messwerten basieren, werden unterstützt:Mit dem Parameter sql eines LookML-Messwerts können Sie Berechnungen ohne Aggregation durchführen, bei denen vordefinierte Basismesswerte aus dem Analysemodell verwendet werden. Wenn Sie ein Measure erstellen, das auf anderen Measures basiert, können Sie das neue Measure nicht als aggregierten Measure-Typ wie sum oder count definieren. Sie müssen den neuen Messwert als nicht aggregierten Messwerttyp definieren, z. B. string, number, date oder yesno. Sehen Sie sich folgendes Beispiel an:

      measure: average_order_amount {
  type: number
  sql: ROUND(${total_order_amount} / NULLIF(${count_orders}, 0), 2) ;;
}

  • Joins:Ein Explore, dessen Basisansicht auf einem Analysemodell basiert, darf keine Joins enthalten. Ebenso kann eine Ansicht, die auf einem Analysemodell basiert, nicht mit einem Explore verknüpft werden, das eine standardmäßige LookML-Basisansicht hat.

  • Implizite Joins:Funktionen, die auf impliziten Joins basieren, werden für Analysemodelle nicht unterstützt. Beispiele für Funktionen, die auf impliziten Joins basieren, sind benutzerdefinierte Kalender und Felder, die mit type: location, type: distance oder type: zipcode definiert sind.

  • Die folgenden Funktionen werden bei Analysemodellen nicht unterstützt: