שינויים ב-LookML

סקירה כללית

באמצעות שיפורים ב-LookML, אתם יכולים להתאים תצוגה או ניתוח קיימים בלי לערוך את קובץ ה-LookML שמכיל אותם. האפשרות הזו מתאימה במיוחד ל:

לדוגמה, אם יש לכם את קובץ התצוגה הבא בפרויקט:

view: flights {
  sql_table_name: flightstats.accidents ;;

  dimension: id {
    label: "id"
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }
}

אפשר לשפר את התצוגה flights כמו בדוגמה הבאה: משתמשים בפרמטר view עם אותו שם תצוגה, אבל מוסיפים סימן פלוס (+) לפני השם כדי לציין שמדובר בשיפור של תצוגה קיימת.

השיפור הזה מוסיף מאפיין air_carrier לתצוגה הקיימת flights:

view: +flights {
  dimension: air_carrier {
    type: string
    sql: ${TABLE}.air_carrier ;;
  }
 }

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

התוצאה הסופית של השילוב בין ההגדרה המדויקת לבין ה-LookML המקורי היא כאילו זה היה ה-LookML המקורי של התצוגה:

view: flights {
  sql_table_name: flightstats.accidents ;;

  dimension: id {
    label: "id"
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }

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

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

מידע מפורט יותר על ההטמעה זמין בקטע דוגמה.

ההבדלים בין שיפורים לבין הרחבות

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

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

ברוב תרחישי השימוש, שיפורים הם חלופה פשוטה ונקייה יותר ל-extends.

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

הסינון המעודן מבטל את רוב הפרמטרים

חשוב לציין שברוב המקרים, שינוי יחליף את ההגדרות המקוריות של אובייקט. בדוגמה הבאה, בתצוגה המקורית יש מאפיין מוסתר (hidden: yes):

view: faa_flights {
  dimension: carrier {
    hidden: yes
  }
}

ובקובץ אחר יש שיפור של המאפיין הזה עם hidden: no:


include: "/views/faa_flights.view.lkml"

view: +faa_flights {
  dimension: carrier {
    hidden: no
  }
}

ההגדרה האחרונה שבוצעה מקבלת עדיפות, ולכן ההגדרה hidden: no מוחלת והמאפיין יוצג בתצוגה הסופית.

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

חלק מהפרמטרים הם מצטברים

במקרים רבים, אם ההגדרה המדויקת מכילה את אותו פרמטר כמו האובייקט שמדייקים, ההגדרה המדויקת תבטל את ערכי הפרמטרים של האובייקט המדויק.

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

הפרמטרים הבאים הם תוספתיים:

לדוגמה, הנה תצוגה מקדימה עם מאפיין name ופרמטר link:

view: carriers {
  sql_table_name: flightstats.carriers ;;

  dimension: name {
    sql: ${TABLE}.name ;;
    type: string
    link: {
      label: "Google {{ value }}"
      url: "http://www.google.com/search?q={{ value }}"
      icon_url: "http://google.com/favicon.ico"
    }
  }
}

והנה שיפור לתצוגה carriers, עם מאפיין name שיש לו ערכים שונים לפרמטר link:


include: "/views/carriers.view.lkml"

view: +carriers {
  label: "Refined carriers"

  dimension: name {
    sql: ${TABLE}.name ;;
    type: string
    link: {
      label: "Dashboard for {{ value }}"
      url: "https://docsexamples.dev.looker.com/dashboards/307?Carrier={{ value }}"
      icon_url: "https://www.looker.com/favicon.ico"
    }
  }
}

בתצוגה המפורטת carriers, שני הפרמטרים link מצטברים, ולכן המימד name יציג את שני הקישורים.

השיפורים מוחלים לפי הסדר

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

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

לדוגמה, בקובץ התצוגה הבא יש שני שיפורים לתצוגה faa_flights. בשיפור הראשון מוסתר מאפיין (hidden: yes), ובשיפור השני מוצג המאפיין (hidden: no). במקרים של קונפליקטים כאלה, השיפור שמופיע הכי למטה בקובץ מקבל עדיפות: 

include: "//e_faa_original/views/faa_flights.view.lkml"

view: +faa_flights {
  dimension: carrier {
    hidden: yes
  }
}

view: +faa_flights {
  dimension: carrier {
    hidden: no
  }
}

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

include: "/refinements/distance_analysis.lkml"
include: "/refinements/finishing_touches.lkml"

השיפורים בdistance_analysis.lkml יחולו קודם, ואז יחולו השיפורים בקובץ finishing_touches.lkml. אם יש סתירות, העדיפות תהיה לשיפורים בקובץ האחרון, finishing_touches.lkml.

שימוש ב-final: yes כדי למנוע שיפורים נוספים

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

אם יש לכם שיפור שאתם רוצים שייחשב כשיפור הסופי של התצוגה או של הכלי 'חיפוש חכם', אתם יכולים להוסיף את הדגל final: yes לשיפור. סביבת הפיתוח המשולבת (IDE) של Looker תחזיר שגיאת LookML אם יש חידודים קיימים שיוחלו אחרי החידוד הסופי הזה, או אם מפתח ינסה להוסיף חידוד חדש שיוחל אחרי החידוד הסופי הזה. לדוגמה, הוספת העידון השני בקובץ התצוגה הזה תיצור שגיאת LookML כי לעידון הקודם יש את הדגל final: yes:

include: "//e_faa_original/views/faa_flights.view.lkml"

view: +faa_flights {
  final: yes
  dimension: carrier {
    hidden: yes
  }
}

view: +faa_flights {
  dimension: carrier {
    hidden: no
  }
}

הוספת הדגל final: yes לחידוד היא דרך טובה לוודא שהחידודים מוחלים בסדר הרצוי.

השיפורים יכולים להכיל הרחבות

מפתחי LookML מתקדמים יכולים להשתמש בפרמטר extends בתוך שיפור LookML, שמוסיף את האובייקט המורחב לאובייקט שמשופר.

כדי לסכם את ההתנהגות של extends והשיפורים:

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

כדוגמה לשימוש רגיל בהידוקים, הנה ניתוח שנקרא orders וניתוח +orders שמחדד אותו:

explore: orders {
  view_name: orders
  # other Explore parameters
}

explore: +orders {
  label: "Orders Information"
  # other Explore parameters to build on the original Explore
}

בנוסף, אפשר להוסיף שיפור שכולל extends. בהמשך לדוגמה, הנה אותו ניתוח orders. בנוסף, יש Explore בסיסי בשם users_base, ועכשיו לחידוד +orders יש פרמטר extends שמביא את users_base:


explore: users_base {
  view_name: users
  extension: required
  # other Explore parameters
}

explore: orders {
  view_name: orders
  # other Explore parameters
}

explore: +orders {
  label: "Orders Information"
  extends: [users_base]
  # other Explore parameters to build on the original Explore
}

מה שמיוחד כאן הוא שהסינון +orders כולל בתוכו את הסינון extends. התוצאה היא שהתצוגה +orders תורחב עכשיו לusers_base 'חיפוש'.

איך Looker מטמיע את extends בתוך שיפורים

הרחבת אובייקט בתוך שיפור היא קונספט מתקדם ב-LookML. לפני שמשתמשים ב-extends לשיפור החיפוש, חשוב להבין את הנושאים הבאים:

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

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

  1. ערכים מextends שצוינו באובייקט
  2. ערכים ממאפיין extends שצוין בשיפורים של האובייקט
  3. ערכים מהאובייקט
  4. ערכים מההגדרות המדויקות של האובייקט

כדי להמחיש, הנה דוגמה שבה מוסבר איך הפרמטר label עובר דרך כל שלב בהטמעה:

explore: orders_base {
  label: "Orders Base"
  view_name: orders
  extension: required
}

explore: users_base {
  label: "Users Base"
  view_name: users
  extension: required
}

explore: orders {
  label: "Orders"
  extends: [orders_base]
}

explore: +orders {
  label: "Orders Refined"
  extends: [users_base]
}

כך Looker מטמיע את הערך label עבור orders Explore בדוגמה הזו:

  1. ערכים מextends שצוינו באובייקט. מכיוון של-orders Explore יש פרמטר extends, ‏ Looker מתחיל עם רכיבי LookML מהאובייקט שמתבצעת הרחבה שלו, ובמקרה הזה זה orders_base Explore. בשלב הזה, הערך של label הוא Orders Base.
  2. ערכים מextends שצוינו בשיפורים של האובייקט. מכיוון של-orders יש שיפור, ולשיפור יש פרמטר extends, ‏ Looker מחיל רכיבי LookML מההרחבה של השיפור, שבמקרה הזה היא ה-Explore‏ users_base. בשלב הזה, הערך של label הוא 'בסיס משתמשים'.
  3. ערכים מהאובייקט. עכשיו, אחרי שטיפלנו בכל התוספים, Looker מחיל רכיבים מהאובייקט המורחב, שבמקרה הזה הוא orders ניתוח. אם יש התנגשויות, האובייקט המרחיב מקבל עדיפות. לכן, הערך label הוא עכשיו 'הזמנות'.
  4. ערכים מההגדרות המפורטות של האובייקט. לבסוף, Looker מחיל רכיבים מכל שיפור של orders Explore. אם יש התנגשויות, אובייקט ההגדרה המדויקת גובר. הערך label הוא עכשיו Orders Refined (הזמנות משופרות).

החידודים extends מצטברים

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

לדוגמה, הנה ניתוח בסיסי שנקרא orders_base וניתוח orders שמרחיב את הניתוח הבסיסי. בנוסף, יש users_base חיפוש והרחבה של +orders:users_base

explore: orders_base {
  view_name: orders
  extension: required
  # other Explore parameters
}

explore: users_base {
  view_name: users
  extension: required
  # other Explore parameters
}

explore: orders {
  extends: [orders_base]
  # other Explore parameters to build on the base Explore
}

explore: +orders {
  extends: [users_base]
  # other Explore parameters to build on the base Explores
}

ההצעה orders מתרחבת ל-orders_base, ואז ההצעה +orders מתרחבת ל-users_base ברשימה extends. התוצאה היא ש-+orders Explore ירחיב עכשיו את orders_base ואת users_base, כאילו זה היה קובץ ה-LookML המקורי של Explore:

explore: orders {
  extends: [orders_base, users_base]
}

לאחר מכן, אם יש התנגשויות, תינתן עדיפות לפריט האחרון בשרשרת ההרחבות. בדוגמה הזו, האלמנטים ב-users_base יבטלו את האלמנטים התואמים ב-orders_base.

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

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

שימוש בשיפורים בפרויקט של LookML

אלה השלבים הכלליים לשיפור התצוגות והניתוחים בפרויקט:

  1. מציינים את התצוגה או את הניתוח שרוצים לשפר.
  2. מחליטים איפה רוצים למקם את ההגדרות המדויקות. אפשר להוסיף שיפורים לכל קובץ LookML קיים, או ליצור קובצי LookML נפרדים לשיפורים. (דוגמה ליצירת קובצי LookML גנריים מופיעה בהליך יצירת קובץ לבדיקת נתונים בדף התיעוד הסבר על קובצי פרויקט אחרים).
  3. משתמשים בפרמטר include כדי לשלב את השיפורים במודל:
    • בקובץ שבו אתם כותבים את השיפורים, אתם צריכים לכלול את קובצי ה-LookML שאתם משפרים. אם תנסו לשפר אובייקט שלא נכלל, תקבלו אזהרות ב-IDE של Looker.
    • בקובץ המודל, כוללים את הקבצים שבהם מוגדרים השיפורים. אפשר לשלב קבצים ולהשתמש ב-includes בדרכים יצירתיות מאוד. פרטים נוספים זמינים בקטע שימוש בשיפורים כדי להוסיף שכבות למודל בדף הזה.

דוגמה

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

הנה קוד LookML של aircraft Explore:


explore: aircraft {
  join: aircraft_types {
    type: left_outer
    sql_on: ${aircraft.id} = ${aircraft_types.id} ;;
    relationship: many_to_one
  }

  join: aircraft_engine_types {
    type: left_outer
    sql_on: ${aircraft.id} = ${aircraft_engine_types.id} ;;
    relationship: many_to_one
  }
}

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

עכשיו, פרויקט LookML אחר בשם e_faa_refined מייבא את קובץ ה-Explore‏ aircraft. בפרויקט e_faa_refined אפשר להשתמש בשיפור כדי לפשט באופן משמעותי את הניתוח aircraft.

אי אפשר לערוך את הקובץ aircraft ישירות כי הוא קובץ מיובא. במקום זאת, אפשר להוסיף לה חידוד. זו דוגמה לקובץ נפרד בשם refinements.lkml שמכיל את קוד ה-LookML הזה:

include: "//e_faa_original/Explores/aircraft.explore.lkml"

explore: +aircraft {
  label: "Aircraft Simplified"
  fields: [aircraft.aircraft_serial, aircraft.name, aircraft.count]
}

קובץ refinements.lkml מכיל את הפרטים הבאים:

  • הפרמטר include כדי להביא את קובץ aircraft.explore.lkml המקורי מהפרויקט המיובא (פרטים על הפנייה לקבצים של פרויקט מיובא מופיעים בדף התיעוד בנושא ייבוא קבצים מפרויקטים אחרים).
  • שיפורים בaircraft Explore:
    • הסימן + לפני השם של הניתוח מציין שמדובר בחידוד של ניתוח קיים.
    • הפרמטר label משנה את התווית של Explore ל'מטוס פשוט'.
    • הפרמטר fields מציין שיוצגו בכלי הניתוחים רק שלושה שדות.

התוצאה הסופית היא כאילו אלה היו התצוגות aircraft Explore ו-aircraft המקוריות:

explore: aircraft {
  label: "Aircraft Simplified"
  }

view: aircraft {
  sql_table_name: flightstats.aircraft ;;

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

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

  measure: count {
    type: count
  }
}

דוגמה לשימוש בשיפורים כדי להתאים אישית תצוגה אחת למספר תרחישי שימוש מופיעה במאמר Maximizing code reusability with DRY LookML: Customizing a single base view for multiple use cases (מיקסום השימוש החוזר בקוד באמצעות DRY LookML: התאמה אישית של תצוגת בסיס אחת למספר תרחישי שימוש).

תרחישי שימוש נוספים לשיפורים

כמו שכבר צוין, שיפורים הם פתרון אידיאלי להתאמת אובייקטים של LookML שהם לקריאה בלבד, כמו Looker Blocks או קבצים מיובאים.

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

שימוש בהגדרות לשיפור כדי להוסיף ניתוחים

אתם יכולים להשתמש בשיפורים כדי להוסיף ניתוחים למודל בלי לשנות את קובצי ה-LookML המקוריים. לדוגמה, אם יש פרויקט שבו התצוגות והניתוחים נוצרים מטבלאות במסד הנתונים ומאוחסנים בקובץ LookML בשם faa_basic.lkml, אפשר ליצור קובץ faa_analysis.lkml שבו משתמשים בשיפורים כדי להוסיף ניתוחים. זוהי דוגמה לטבלת נתונים חדשה שנקראת distance_stats ומכילה ניתוח של מרחקים. בדוגמה הזו מוצג שיפור של ה-Explore הקיים flights מהקובץ faa_basic.lkml, שבו מתבצע צירוף של טבלת הנגזרות distance_stats ל-Explore flights. בנוסף, בתחתית הדוגמה, התצוגה הקיימת flights עוברת שיפור כדי להוסיף שדות חדשים מהניתוח:

include: "faa_basic.lkml"

explore: +flights {
  join: distance_stats {
    relationship: one_to_one
    type: cross
  }
}

view: distance_stats {
  derived_table: {
    explore_source: flights {
      bind_all_filters: yes
      column: distance_avg {field:flights.distance_avg}
      column: distance_stddev {field:flights.distance_stddev}
    }
  }
  dimension: avg {
    type:number
    sql: CAST(${TABLE}.distance_avg as INT64) ;;
  }
  dimension: stddev {
    type:number
    sql: CAST(${TABLE}.distance_stddev as INT64) ;;
  }
}
view: +flights {
  measure: distance_avg {
    type: average
    sql: ${distance} ;;
  }
  measure: distance_stddev {
    type: number
    sql: STDDEV(${distance}) ;;
  }
  dimension: distance_tiered2 {
    type: tier
    sql: ${distance} ;;
    tiers: [500,1300]
  }
}

שימוש בשיפורים כדי להוסיף שכבות למודל

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

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

בנוסף לקובץ הגולמי, אפשר ליצור קובץ faa_basic.lkml כדי להוסיף שכבה חדשה עם שיפורים בסיסיים, כמו הוספת הצטרפויות לניתוחים או הוספת מדדים לתצוגות, כמו בדוגמה הבאה:

include: "faa_raw.lkml"

explore: +flights {
  join: carriers {
    sql_on: ${flights.carrier} = ${carriers.name} ;;
  }
}

view: +flights {
  measure: total_seats {
    type: sum
    sql: ${aircraft_models.seats} ;;
  }
}

אחר כך אפשר להוסיף קובץ faa_analysis.layer.lkml כדי להוסיף שכבה חדשה עם ניתוחים (בקטע המשנה שימוש בשיפורים להוספת ניתוחים יש דוגמה לקובץ ניתוח).

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

connection: "publicdata_standard_sql"

include: "faa_raw.lkml"
include: "faa_basic.lkml"
include: "faa_analysis.lkml"

view: +flights {
  sql_table_name: lookerdata.faa.flights;;
}
view: +airports {
  sql_table_name: lookerdata.faa.airports;;
}
view: +aircraft {
  sql_table_name: lookerdata.faa.aircraft;;
}
view: +aircraft_models{
  sql_table_name: lookerdata.faa.aircraft_models;;
}
view: +carriers {
  sql_table_name: lookerdata.faa.carriers;;
}

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

שימוש בצמצום תוצאות ל-PDT

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

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

שימוש במטא-נתונים כדי לראות שיפורים באובייקט

אפשר ללחוץ על פרמטר explore או view ב-Looker IDE ולהשתמש בחלונית המטא-נתונים כדי לראות שינויים באובייקט. מידע נוסף זמין בדף התיעוד בנושא מטא-נתונים של אובייקטים ב-LookML.

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

פרויקטים עם התאמה לשוק המקומי

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