Qlik Join - חלק 6
drop table, כדי שלא יישארו מפתחות סינתטיים ולא יישאר מידע מיותר בזיכרון.פרקי ההרצאה: Qlik Join - חלק 6
תמלול ההרצאה: Qlik Join - חלק 6
הטקסט המלא של הדקות הראשונות בהרצאה «Qlik Join - חלק 6» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אוקיי, אז בואו נדבר על Inner Joint, מתי אנחנו בעצם צריכים לאחד טבלאות לטבלה אחת, את זה כבר ראינו ב-Left Joint, אבל עכשיו נוצא את הדוגמה האחרת ו-Inner Joint יותר מתאימה לזה.
אבל כדי להבין את זה אני רוצה רגע לדבר בכלל על המונח של Star Schema, אני לא יודע אם מי מכם שמע את זה. Star Schema זה איזושהי מתודולוגיה בפיתוח של BI ו-Data Warehouse, שמתייחסת לטבלאות בסוג של כוכב, איך קוראים לזה, Star Schema, שבעצם יש טבלה אחת מרכזית באמצע,
טבלת פאקט, טבלת המז'ר, בעצם טבלת המדדים והיא מוקפת מכל הכיוונים בטבלאות מימד, טבלאות דיימנשן. זאת אומרת יש לנו בעצם שני סוגי טבלאות, יש טבלת פאקט, טבלה שבה בעצם המידע הוא מצטבר באופן רציף, זאת בעצם הטבלה המרכזית שמתעדכנת ברמה יומית בדרך כלל והיא עטופה בכל מיני טבלאות שהן יותר מהן קטלוגים,
הם גם מתעדכנים אבל לא באותה תדירות. ניתן רגע דוגמא דווקא לא מפה, ואחרי זה נחזור לדוגמא הזאת. נניח שיש לנו חברת ביטוח, אז יש לנו מבוטחים ויש לנו מוצרים, כדומה לפה, ויש לנו את הפוליסות שבעצם מנסים למכור מוכרים.
מה משלוש הטבלאות האלו טבלת המדד, טבלת הפקט, ומה הטבלאות מימד? אז לקוחות מצטרפים מדי פעם, זה נכון. ומוצרים גם כן, יש כל מיני מוצרים ביטוחים, פיתוחים שמדי פעם מוסיפים, אבל הטבלה המרכזית שבה כל הזמן נוצרות רשומות על בסיס כמעט יומיומי או יומיומי היא טבלת הפוליסות.
מכרתי עוד פוליסה, מכרתי עוד פוליסה, מכרתי עוד פוליסה והטבלת פוליסות מקושרת גם ללקוחות וגם למוצרים, כי אני בפוליסה מכרתי ללקוח מסוים מוצר מסוים.
אז טבלת המאז'ר שלנו, טבלת הפאקט המרכזית היא טבלת הפוליסות וטבלאות המימד הן המוצרים והלקוחות. זאת אומרת שזו דוגמא די דומה לפה, כי גם פה יש מוצרים ולקוחות, אבל פה יש הזמנות.
אז די ברור ש-Customer זה באמת את טבלת מימד, טבלה לוויינית שהיא קטלוגית, הלקוחות שלי, וטבלת ה-Products, ה-Supplier זה אפילו עוד יותר מרוחק, כי זה בעצם מאפיין של ה-Product.
לכל Product יש ספק, זה עוד מעגל אחד החוצה, והנתונים המרכזיים בעצם נמצאים פה בשתי טבלאות, ב-Orders וב-Order Items. נכון שהאמאונט בעצם הוא השדה המספרי שמעניין אותי, אבל האורדר זו חלק בלתי נפרד מזה, כי בעצם שניהם מתייחסות להזמנה, ההזמנה זה כמו פוליסות, אלו הנתונים שמצטברים מהבסיס יומיומי,
כל יום יש לי הזמנות, אוקיי? ובאמת הם מפוצלים פה לשתי טבלאות. אחד השיעורים הראשונים דיברנו שאכן מבחינת המבנה הנתונים הבסיסי של המערכת, אכן צריך, הגיוני וצריך ומתבקש להפריד את זה לשתי טבלאות, זאת אומרת שיש נתונים שהם מנוהלים ברמת ההזמנה כולה,
שזה השנה, מספר הזמנה, הלקוח, אותו לקוח לכל הזמנה וכולי. יש נתונים שמנוהלים ברמת הפריטים, ברמת השורות, המספר פריט, הסכום שנמכר הפריט וכולי.
אבל מה לעשות שהסטארס קרמא זה לא עובד טוב לאורך זמן, במודל מורכב, עם שתי טבלאות פקט, ואני אסביר למה הכוונה. נניח שיש לי לאותה חברה שאני מסתכל עליה עכשיו, לא רק הזמנות, וגם החזרות.
עכשיו, החזרות, אם תשימו לב, זה מאוד מאוד דומה להזמנות. גם בהחזרות יש לי שנה או תאריך, כמו באודרס, גם בהחזרות יש לי לקוח שהחזיר, גם בלקוח יש לי את המוצר שהוא החזיר, ויש לי את הכמות, בעצם, ניסונים מאוד מאוד דומים.
עכשיו, אם אני מנסה לטעון לפה גם טבלת החזרות, אולי גם פה יהיה לי טבלת החזרות וטבלת החזרות אייטמס, בעצם יהיה לי פה סמטוכה שלמה, לא יהיה בכלל אפשר להבין, אם יבצעו לי הרבה מעגלים והרבה קשרים, זה מאוד מאוד קשה להתנהל ככה. אז מה בעצם הפתרון?
הפתרון הנכון במקרה הזה הוא לאחד את תבלת אורדר ואורדר אייטמס לטבלה אחת. אפילו שבאמת במקור הם נועלים בנפרד. לאחד אותם לטבלה אחת, שבה גם יש את הנתונים של ההזמנות וגם את הנתונים של השורות, אז את הנתונים החדשים שנכנסים לנו של החזרות לצורך העניין, אני בעצם גם אותם מצרף, אבל מתחת. אני בעצם משרשר,
תכף נראה את זה, אני משרשר מתחת לטבלת ההזמנות שכוללת גם את נתוני השורות, את נתוני ההחזרות. ואז בעצם באותו שדה פרודקט, או פרודקט איי-די, שיש לי ב-orders, המאוחד, יהיה לי גם פרודקט איי-די של ההחזרות.
כי זה בעצם המוצר שהחזירו. באותו שדה, באותו שדה של Customer ID של ה-Orders, יהיה לי בעצם גם את הלקוח שהחזיר. באותו שדה של תאריך של הרכישה, יהיה לי גם תאריך של ההחזרה.
באותו שדה של Quantity, יהיה לי גם את ה-Quantity של ההחזרה. נכון שיהיו שדות שיהיו רלוונטיים רק לרשומות מסוג הזמנה, ושדות שרלוונטיים רק לרשומות מסוג החזר.
למשל, סיבת ההחזר. סיבת ההחזר לא יהיה לי ברשומות של אורדרס, אבל עדיין, זה יהיה חלק מהטבלה. ברשומות של האורדרס זה יהיה ריק, זה יהיה נ"ל.
ברשומות של ההחזרות תהיה רשום לי מה סיבת