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

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

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

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

השיפורים שימושיים כשרוצים לשנות תצוגה קיימת או ניתוח ב-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 מוגדר גם באובייקט extended וגם באובייקט extending, נעשה שימוש בגרסה שבאובייקט extending, אלא אם הפרמטר הוא additive. פרטים נוספים מופיעים בדף שימוש חוזר בקוד באמצעות 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 הוא Users Base.
  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 ניתוחים ירחיב עכשיו את orders_base ואת users_base, כאילו זה היה קובץ ה-LookML המקורי של הניתוח:

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

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

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

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

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

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

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