הצטרף

שימוש

explore: explore_name {
  join: view_name { ... }
}

היררכיה קובץ מודל explore join

ערך ברירת המחדל ללא אמצעי תשלום מקובלים השם של תצוגה קיימת כללים מיוחדים הפרמטר הזה מקבל שם של תצוגה, ולא את השם של הטבלה שעליה מבוססת התצוגה (למרות שלעיתים קרובות הם זהים) אם הניב שלכם לא תומך ב-symmetric_aggregates, רוב סוגי המדדים לא נכללים בתצוגות המצורפות אתם יכולים להצטרף לאותה תצוגה יותר מפעם אחת באמצעות from

הגדרה

הפרמטר join מאפשר להגדיר את קשר הצירוף בין Explore לבין תצוגה, כדי שתוכלו לשלב נתונים מכמה תצוגות. אפשר להצטרף לכמה תצוגות שרוצים בכל חקירה נתונה.

זכרו שכל תצוגה משויכת לטבלה במסד הנתונים, או לטבלה נגזרת שהגדרתם ב-Looker. באופן דומה, מכיוון ש-Explore משויך לתצוגה, הוא גם מחובר לטבלה מסוג כלשהו.

הטבלה שמשויכת ל-Explore ממוקמת בסעיף FROM של ה-SQL שנוצר על ידי Looker. טבלאות שמשויכות לתצוגות מאוחדות ממוקמות בסעיף JOIN של ה-SQL שנוצר על ידי Looker.

פרמטרים עיקריים של איחוד (join)

כדי להגדיר את קשר הצירוף (הפסוקית ON ב-SQL) בין חקירה לבין תצוגה, צריך להשתמש ב-join בשילוב עם פרמטרים אחרים.

כדי להגדיר את הסעיף ON ב-SQL, צריך להשתמש בפרמטר sql_on או בפרמטר foreign_key.

אתם גם צריכים לוודא שאתם משתמשים בסוגי הצירופים והקשרים המתאימים, למרות שהפרמטרים type ו-relationship לא תמיד נדרשים באופן מפורש. אם ערכי ברירת המחדל שלהם, type: left_outer ו-relationship: many_to_one, מתאימים לתרחיש לדוגמה שלכם, אפשר להחריג את הפרמטרים האלה.

אפשר לסכם את הפרמטרים העיקריים האלה ואת הקשר שלהם ל-SQL ש-Looker יוצר באופן הבא:

• הפרמטר explore קובע את הטבלה בסעיף FROM של שאילתת ה-SQL שנוצרה.
• כל פרמטר join קובע פסוקית JOIN של שאילתת ה-SQL שנוצרת.
  • הפרמטר type קובע את סוג ה-SQL join.
  • הפרמטר sql_on והפרמטר foreign_key קובעים את הסעיף ON של שאילתת ה-SQL שנוצרה.

sql_on

sql_on מאפשר לכם ליצור קשר של איחוד (join) על ידי כתיבת משפט ה-SQL ON ישירות. היא יכולה לבצע את אותם איחודים כמו foreign_key, אבל קל יותר לקרוא ולהבין אותה.

מידע נוסף זמין בדף התיעוד של הפרמטר sql_on.

foreign_key

foreign_key מאפשר ליצור קשר של צירוף באמצעות המפתח הראשי של התצוגה המצורפת, ולקשר אותו למאפיין ב-Explore. התבנית הזו נפוצה מאוד בעיצוב מסדי נתונים, ו-foreign_key היא דרך אלגנטית לבטא את הצירוף במקרים האלה.

כדי להבין את הנושא לעומק, כדאי לעיין בדף העזרה בנושא הפרמטר foreign_key.

type

רוב הצירופים ב-Looker הם LEFT JOIN מהסיבות שמתוארות בקטע אם אפשר, לא כדאי להחיל לוגיקה עסקית בצירופים בדף הזה. לכן, אם לא מוסיפים באופן מפורש type, המערכת של Looker תניח שאתם רוצים LEFT JOIN. עם זאת, אם מסיבה כלשהי אתם צריכים סוג אחר של צירוף, אתם יכולים לעשות זאת באמצעות type.

הסבר מלא זמין בדף העזרה בנושא הפרמטר type.

relationship

ל-relationship אין השפעה ישירה על ה-SQL ש-Looker יוצר, אבל הוא קריטי לפעולה התקינה של Looker. אם לא מוסיפים relationship באופן מפורש, Looker יפרש את הקשר כ-many-to-one, כלומר, להרבה שורות ב-Explore יכולה להיות שורה אחת בתצוגה המצורפת. לא כל הצירופים הם מהסוג הזה, וצריך להצהיר בצורה נכונה על צירופים עם קשרים אחרים.

כדי להבין את הנושא לעומק, כדאי לעיין בדף העזרה בנושא הפרמטר relationship.

דוגמאות

צירוף התצוגה בשם customer ל-Explore בשם order, כאשר קשר הצירוף הוא

FROM order LEFT JOIN customer ON order.customer_id = customer.id:

explore: order {
  join: customer {
    foreign_key: customer_id
    relationship: many_to_one # Could be excluded since many_to_one is the default
    type: left_outer          # Could be excluded since left_outer is the default
  }
}

מצרפים את התצוגה בשם address ל-Explore בשם person, כאשר קשר הצירוף הוא

FROM person LEFT JOIN address ON person.id = address.person_id AND address.type = 'permanent':

explore: person {
  join: address {
    sql_on: ${person.id} = ${address.person_id} AND ${address.type} = 'permanent' ;;
    relationship: one_to_many
    type: left_outer # Could be excluded since left_outer is the default
  }
}

צירוף התצוגה בשם member ל-Explore בשם event, כאשר קשר הצירוף הוא

FROM event INNER JOIN member ON member.id = event.member_id:

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    relationship: many_to_one # Could be excluded since many_to_one is the default
    type: inner
  }
}

אתגרים נפוצים

השדה join חייב להשתמש בשמות של תצוגות ולא בשמות של טבלאות בסיסיות

הפרמטר join מקבל רק שם של תצוגה, ולא את שם הטבלה שמשויכת לתצוגה הזו. הרבה פעמים שם התצוגה ושם הטבלה זהים, וזה עלול להוביל למסקנה השגויה שאפשר להשתמש בשמות של טבלאות.

סוגים מסוימים של מדדים דורשים צבירה סימטרית

אם אתם לא משתמשים בצבירה סימטרית, רוב סוגי המדדים לא נכללים בתצוגות המצורפות. כדי ש-Looker יתמוך בצבירה סימטרית בפרויקט Looker, גם הניב של מסד הנתונים צריך לתמוך בה. בטבלה הבאה מפורט אילו ניבים תומכים בצבירה סימטרית בגרסה האחרונה של Looker:

ניב	יש תמיכה?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
ClickHouse 26+
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Dremio 26+ with Arrow Flight SQL
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

בלי צבירה סימטרית, קשרי גומלין של צירוף שהם לא אחד לאחד יכולים ליצור תוצאות לא מדויקות בפונקציות צבירה. מאחר שהמדדים של Looker הם פונקציות נצברות, רק מדדים של type: count (כמו COUNT DISTINCT) מועברים מתצוגות מצורפות אל ה-Explore. אם יש לכם קשר של אחד לאחד, אתם יכולים להשתמש בפרמטר relationship כדי לאלץ את הכללת סוגי המדדים האחרים, באופן הבא:

explore: person {
  join: dna {
    sql_on: ${person.dna_id} = ${dna.id} ;;
    relationship: one_to_one
  }
}

הסיבות לכך ש-Looker פועל בצורה הזו (בניבים שלא תומכים בצבירה סימטרית) מפורטות בפוסט לקהילה בנושא הבעיה של פיצול SQL.

חשוב לדעת

אפשר להצטרף לאותו שולחן יותר מפעם אחת באמצעות from

במקרים שבהם טבלה אחת מכילה סוגים שונים של ישויות, אפשר לצרף תצוגה לעולם תוכן מורחב יותר מפעם אחת. כדי לעשות את זה, צריך להשתמש בפרמטר from. נניח שיש לכם order Explore ואתם צריכים לצרף אליו תצוגה של person פעמיים: פעם אחת בשביל הלקוח ופעם אחת בשביל נציג שירות הלקוחות. לדוגמה:

explore: order {
  join: customer {
    from: person
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
  join: representative {
    from: person
    sql_on: ${order.representative_id} = ${representative.id} ;;
  }
}

אם אפשר, לא להחיל לוגיקה עסקית על צירופים

הגישה הרגילה של Looker לצירוף היא להשתמש ב-LEFT JOIN בכל פעם שאפשר. אם אתם מוצאים את עצמכם עושים משהו דומה, כדאי לשקול גישה אחרת:

explore: member_event {
  from: event
  always_join: [member]
  join: member {
    sql_on: ${member_event.member_id} = ${member.id} ;;
    type: inner
  }
}

בדוגמה הזו יצרנו ניתוח שמתייחס רק לאירועים שמשויכים לחברים מוכרים. עם זאת, הדרך המועדפת לבצע את זה ב-Looker היא להשתמש ב-LEFT JOIN כדי לחבר בין נתוני האירועים לנתוני החברים, כך:

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
  }
}

אחר כך יוצרים מאפיין שאפשר להגדיר כ-yes או כ-no, אם רוצים לבחון רק אירועים של חברים, למשל:

dimension: is_member_event {
  type: yesno
  sql: ${member.id} IS NOT NULL ;;
}

הגישה הזו עדיפה כי היא נותנת למשתמשים את הגמישות להסתכל על כל האירועים או רק על אירועים של חברים, לפי מה שהם רוצים. לא אילצתם אותם לצפות רק באירועים של חברי המועדון באמצעות ההצטרפות.

אם לא משתמשים בצבירה סימטרית, כדאי להימנע מצירופים שגורמים ל-fanout

הקטע הזה רלוונטי רק לניבים של מסדי נתונים שלא תומכים בצבירה סימטרית. כדי לבדוק אם הניב תומך בצבירה סימטרית, עיינו בדיון על צבירה סימטרית בקטע אתגרים נפוצים בדף הזה.

אם הדיאלקט של מסד הנתונים לא תומך בצבירה סימטרית, כדאי להימנע משאילתות JOIN שגורמות ל-fanout. במילים אחרות, בדרך כלל כדאי להימנע מצירופים שיש להם קשר של אחד לרבים בין ה-Explore לתצוגה. במקום זאת, צריך לצבור את הנתונים מהתצוגה בטבלה נגזרת כדי ליצור קשר של אחד לאחד עם ה-Explore, ואז לצרף את הטבלה הנגזרת ל-Explore.

המושג החשוב הזה מוסבר בהרחבה בפוסט לקהילה The problem of SQL fanouts.