מ- (לצירופים)

בדף הזה יש התייחסות לפרמטר from שהוא חלק מצירוף.

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

Usage

explore: view_name {
  join: join_name {
    from: view_name_2
  }
}

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

ערך ברירת המחדל תצוגה מפורטת שהשם שלה זהה לשם של הצטרפות מקבל השם של תצוגה קיימת

הגדרה

‫from מציין את view שייעשה בו שימוש בהצטרפות. אם לא מציינים את from, ‏ Looker מניח ששם התצוגה הבסיסית זהה לשם הצירוף.

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

• השדה הזה יופיע בדרך כלל כ-UNDERLYING VIEW Order Value בממשק המשתמש של 'ניתוח נתונים', והוא יצוין ב-LookML באמצעות ${underlying_view.order_value}.
• אם קוד ה-LookML בקטע השימוש הוחל על הדוגמה הזו, השדה יופיע במקום זאת כ-NEW ALIAS NAME Order Value וההפניה אליו תהיה ${new_alias_name.order_value}.

הטכניקה הזו שימושית במיוחד כשצריך לצרף את אותו תצוגה לניתוח בכמה דרכים שונות.

דוגמאות

מצטרפים לתצוגה person ל-Explore order, אבל קוראים לה customer במקום:

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

מצטרפים לתצוגה person ב-Explore order פעמיים – פעם בתור customer ופעם בתור representative:

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

דברים שכדאי לקחת בחשבון

‫from שינוי האופן שבו שדות מפנים לנתונים ב'ניתוח נתונים'

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

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

המשתמש person מצטרף לשיחה order, אבל הוא נקרא customer. לכן, אם הייתם צריכים להפנות לשדה מ-customer בתוך order, הייתם משתמשים ב-${customer.field_name}. אם תצטרפו שוב ל-person ל-order בחיפוש השני – אבל לא תשנו את השם ל-customer – ההפניה ל-${customer.field_name} לא תפעל בחיפוש השני. הגישה הכללית לפתרון הבעיה הזו היא להחריג את השדה הבעייתי מהניתוח השני באמצעות fields. הוא ייראה בערך כך:

explore: the_second_explore {
  fields: [ALL_FIELDS*, -person.problem_field]
  join: person {
    sql_on: ${the_second_explore.some_field} = ${person.some_field} ;;
  }
}

בדרך כלל משתמשים ב-from כדי לצרף את אותה טבלה יותר מפעם אחת לניתוח ב-Explore

במקרים שבהם טבלה אחת מכילה סוגים שונים של ישויות, אפשר לצרף תצוגה מפורטת לעולם תוכן מורחב יותר מפעם אחת. נניח שיש לכם דוח 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} ;;
  }
}

קוד ה-SQL ש-Looker ייצור מ-LookML הזה הוא:

SELECT    ...
FROM      order
LEFT JOIN person AS customer
ON        customer.id = order.customer_id
LEFT JOIN person AS representative
ON        representative.id = order.representative_id