יצירת Dimension
EmployeeBusinessKey (int, not null, המפתח מהמערכת התפעולית) ו-EmployeeSK, מפתח Surrogate מסוג int עם identity (1,1) שהוא המפתח הראשי. אחר כך FullName (nvarchar), שאיחד את First Name ו-Last Name, ואפשר לשמור גם את השמות הנפרדים. הוסיפו Title, BirthDate, ואת הגיל, וגם Seniority, כלומר הוותק בשנים. אלה עמודות מחושבות שמאחסנים כדי שיהיו זמינות. הוסיפו גם City ו-Country.ProductBusinessKey ו-ProductSK, ProductName, ושמות הקטגוריה והספק במקום קודים, כדי לא לעשות Join. שומרים גם Discontinued. את Unit Price אפשר לשמור גם ב-Dimension, כמחיר המקורי של המוצר, וגם ב-Fact, כמחיר בהזמנה.CustomerBusinessKey (nvarchar 5, not null), CustomerSK (int, identity, מפתח ראשי), שם הלקוח כ-CustomerName (nvarchar 40), City ו-Country.USE ומריצים את הסקריפט. הטבלאות מופיעות תחת הסכמה.פרקי ההרצאה: יצירת Dimension
תמלול ההרצאה: יצירת Dimension
הטקסט המלא של הדקות הראשונות בהרצאה «יצירת Dimension» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בסדרת השיעורים שלפנינו אנחנו ניקח את דאטאבייס האופרשנל NorthWing ונגזור אותו עד להבאתו לרמה של Data Warehouse.
נבנה מתוכו Data Warehouse. על מנת לבנות את כל התהליך הזה אנחנו צריכים להכיר מה יש לנו בתוך הדאטאבייס התפעולי שלנו, הדאטאבייס של NorthWing.
מתוכו אנחנו צריכים להחליט אילו אובייקטים אנחנו רוצים לבנות, כלומר השאלות שאנחנו צריכים לשאול את עצמנו זה מה הם אותם Dimensions, מה ה-Fact שאותו אנחנו נבנה, הוא אותו כל הדאטה שאותו רלוונטי שאנחנו רוצים לענות, ובעצם שאלת המפתח היא בעצם מה שאלת הרווחיות, מה שאלת הרווחיות שמעניינת אותנו בתור עיר.
נכתוב זאת כך: What is the main business process? מהו התהליך בעצם שאותו אנחנו רוצים לכמת, לאמוד, לבדוק, לבחון? האם מדובר על תהליך של ייצור?
Manufacturing? האם מדובר על תהליך של הזמנות? האם מדובר על תהליך של מכירה? האם מדובר על תהליך של Customer Service? כלומר, מהו התהליך שבעצם הארגון שלנו מתמחה בו?
וזה בעצם רק דוגמאות לתהליכים שיכולים להיות, שאותם אנחנו נרצה לכמת. Once מצאנו את התהליך הרלוונטי, אנחנו צריכים לשאול את עצמנו מהו המידע עבור אותו תהליך, מהו המידע שמסביבו אנחנו נרצה לאסוף את הנתונים שלנו על מנת לכמת את התהליך הזה ועל מנת לאמוד אותו ברמה של מספר.
אחרי שמצאנו את התהליך המרכזי אנחנו יכולים בעצם לדעת מה הם אותם measures, מה הם אותם מדדים שרלוונטיים ואותם אנחנו נכניס לתוך הטבלת fact.
אבל לצד המדדים הללו אנחנו צריכים גם לדעת לזהות את כל הטבלאות לוויין, את כל האובייקטים, Identify the Object, כל האובייקטים שבעצם יהיו מסביב לתוך התהליך עצמו יעזרו לנו. כל אחד מהאובייקטים הללו זה בעצם Dimensions שאותם אנחנו רוצים ללכת ולהביא אותם.
חשוב לנו גם בתהליך BI, בתהליך יצירה של Data Warehouse, גם לזהות את כל מקורות המידע שיש לנו בארגון. Sources, את כל מקורות המידע שיש לנו בארגון.
חשוב לאסוף קבצים, חשוב לאסוף את כל האקסלים, חשוב לאסוף את כל הלוגים, חשוב לאסוף מערכות CRM ו-ERP ו-Web ועוד ועוד ועוד מערכות מידע שיש לנו אותם כאן, שהם יעזרו לנו בעצם על מנת להביא תמונה מלאה לכל התהליך הארגוני עצמו.
כשאנחנו מדברים על Data Warehouse, אין ספק שליבת הארגון שלנו מסתובבת סביב תהליך המכירות. כאן נמצאים המספרים. בתוך טבלת ההזמנות שלנו שהיא מציינת לנו כבר תהליך מכירה סופי אנחנו שומרים פרטים פר הזמנה מיהו הלקוח מיהו העובד מתי היא נעשתה מתי היא הוזמנה וכולי וכולי על כל הזמנה ואם אנחנו רוצים לעשות drill down לכל הזמנה אז
אנחנו נכנסים לטבלת order details שבתוך order details פר כל ההזמנה אנחנו מקבלים את המידע המפורט מה הוזמן בה מה עם שורות ההזמנה שבוצעו מה עם המוצרים באיזה מחיר כמה כמות על כל מוצר והאם בוצעה הנחה ומה גובה ההנחה עבור כל מוצר ומוצר.
בטבלאות שלנו, כשאנחנו נרצה עכשיו לכנס את הנתונים הללו לתוך דאטה וייראוס, נרצה להבחין בעצם מהו המידע שאותו אנחנו נכניס לתוך טבלאות פאקט ומהם האובייקטים שמשחקים לנו תפקיד.
מאחר ולטבלת פאקט אנחנו נרצה לנטר את כל תהליך ההזמנה עצמה, שזה תהליך אורדר והוא נמצא לנו גם ב-Order Details, כאן אנחנו יכולים לגזור בעצם מה יהיו לנו טבלאות הדיימנשן.
מה יהיו אותן טבלאות דיימנשן שיסתובבו וישרתו את תהליך ההזמנה עצמה. בטבלאות עצמם אנחנו רואים שיש לנו שחקן מרכזי כעובדים, יש לנו את קסטומרס, יש לנו את הפרודקט שאנחנו יכולים לתת מידע ברמה של איזה מוצר נקנה עבור איזה לקוח, מהם הנתונים עצמם של הפרטי עובד שביצעו את
אותה מכירה, ודבר נוסף שאנחנו יכולים גם להציג זה את המידע עצמו ברמת תאריכים, מהו אותו דייט. הדייט זה על פי רוב יהיה dimensions קבוע בכל מערכת דאטה וייראוס שאיתה אנחנו נעבוד.
כל מה שנותר לנו כעת לעשות זה להתחיל בבניית ארכיטקטורה של הדאטה וייראוס שלנו על כל שלל הטבלאות הרלוונטיות שבו. אנחנו נתחיל מתוך טבלאות dimensions. כל טבלאות dimensions שיש, הראשונה שתעלה זו טבלת אימפלואיז על מנת לייצר אותם אנחנו ניצור לעצמנו סכמה כדי ליצור את המידע שלנו בצורה מסודרת אנחנו ניצור להם סכמה
של טבלאות דיימנשיונס ולכן קוריאט סקימה ואנחנו נקרא לזה טבלאות דיימנשיונס כפי שאנחנו מכירים זאת מכאן בתוך הסכמה של טבלאות דיימנשיונס אנחנו ניצור טבלה חדשה של אימפלואיז וכאן אנחנו נצטרך לעבור על כל הסקריפט של יצירת טבלת אימפלואיז ומתוכו לדלות מה
רלוונטי מבחינתנו לתוך דאטאבס של דאטה ויירהאוס. ובכן, בטבלת אימפלואיז יש לנו את המפתח ה-employee ID. יש לנו את ה-First Name ואת ה-Last Name, ומאוד יכול להיות שבתוך טבלת אימפלואיז אנחנו כבר לא נשמור אותם כשתי שדות נפרדים, אלא כשדה אחד.
איך ניצור את הנתונים הללו? אז כאן אנחנו נתחיל לרשום את העמודות אחת לאחת כפי שהן רשומות כאן. אז אנחנו רוצים שתהיה לנו כאן Employee ID, אבל אנחנו נבחין בזה שכאן ה-Employee ID שלנו הוא בעצם יהיה מסוג Business Key.
מאחר ובכל טבלת Employees אנחנו לא רק יוצרים Employee Business Key שהוא עבור המערכת התפעולית, אלא גם Employee שהוא יהיה SK, Circuit Key.
נבדיל בין שני המצבים הללו של employee business key לעומת employee SK. employee business key הוא יהיה אינטג'ר כמספר, הוא בהחלט יהיה not null כי אנחנו מייבאים אותו ממערכת שבה הוא not null.
גם ה-surget key שלנו יהיה אינטג'ר וגם הוא יהיה not null אבל הוא יהיה בעצם אידנטיטי שירוץ לנו בין הערכים אחד בצורה אינקרימנטלית של אחד והוא יהיה גם ה-primary key שלנו בתוך הטבלה עצמה.
יצרנו את ה-employee SK ואת ה-employee Business Key, והעמודות הבאות שאנחנו צריכים ליצור זה אולי את full name, שם מלא ששומר לנו.
נשמור אותו כ-n varkar וניתן לו מספיק מקום, כאן הוא כן יכול להיות נ"ל והוא בעצם מאחד לנו את שתי השורות הללו first name ו-last name לתוך מקום אחד. יש מצב שנחליט שאנחנו גם שומרים את ה-first name בעצמו וגם את ה-last name וגם את ה-full name. כלומר, כאן יכול להיות התירות של מידע, מה שלא היה יכול להיות לנו בדאטאבס הרלציוני,
בהחלט יכול להיות לנו במערכת כאן, בתוך הדאטאבס של ה-data warehouse, בהחלט יכול להיות לנו מצב שבו אנחנו ניקח כאן נתונים ונציג אותם פעמיים בשתי מקומות שונים.
רק לתקן כאן את השגיאה שיש לנו כאן not null שצריך להיות כאן בשביל שהוא יקבל לנו את המערכת עצמה ואחרי שיצרנו כאן את הדיימנשן אז בקריאת הטבלה אנחנו ניצור את הטבלה שלנו בתוך דיימנשן יש לנו כאן אימפלואי sq שפותח לנו כאן את הריאט טייבל וזה מה שהיה חסר כאן ריאט טייבל
דיימנשן זה אימפלואי וכולי וכולי אז בשביל הפרסנינג. עמודה נוספת שאנחנו נרצה להביא זה את העמודת טייטל גם היא כ-n varkar כפי שהיא מצוינת לנו בטבלת מקור כשדה שהוא בעצם שומר לנו את הטייטל עצמו.
האם היא נרצה להביא את הטייטל of courtesy? יכול להיות שזה מידע שהוא פחות רלוונטי, אותו אנחנו לא נרצה להביא. ב-birthdate יש מצב שלא נרצה להביא את התאריך, אלא נרצה להביא כבר את הגיל עצמו, שהוא יותר מעניין אותנו. אולי גם הנתון עצמו, birthdate, מעניין אותנו ולכן גם אותו אנחנו נכניס, אבל יש מצב במערכות של Data
Warehouse שאנחנו גם נוסיף כאן עמודה נוספת, שהיא תהיה מסוג אינטג'ר, היא תהיה בעצם מנהל, אבל היא בעצם, אפילו שזו עמודה מחושבת שאנחנו יכולים לחשב אותה, בדאטה וויראוס אנחנו נרצה שהיא תהיה לנו זמינה ונביא אותה. ולכן כמו שיש לנו את ה-birthdate, את התאריך לידה, אנחנו גם נביא את הגיל של העובד בעצמו, וכמו שיש לנו כאן ה-hiredate, תאריך תחילת
עבודה, יכול להיות שאנחנו נרצה להביא את הוותק שלו בעבודה, כי נרצה שם לפלח כבר לפי הוותק, ולכן כאן אני מביא את העמודת סניוריטי, היא מסוג אינטג'ר על מנת לגלות כמה שנים הבחור עובד אצלנו בחברה.
והסניוריטי הזה יחזיק לנו בעצם מספר שנים שהבחור נמצא בחברה. נתקדם לעמודת סיטי כ-NVARCAR, גם כאן ניתן מספיק מקום עבור העמודה עצמה של סיטי.
אנחנו, יכול להיות שגם המידע קאנטרי יהיה מבחינתנו רלוונטי, וגם אותו אנחנו כאן נרצה לשמור ולהביא אותו למערכות עצמם. בהחלט גם אותו נשמור. יכול להיות שעמודות כמו פוסטל קוד כאזור מגורים או ריג'ל או אדרס לא רלוונטיות לנו בשביל החישוב של הפילוחים של ההזמנות.
כי את הפילוחים של ההזמנות אנחנו אולי עושים ברמה של עובד,