הבדלים בין מסד נתונים רגיל ל-Data Warehouse
BK (Business Key) הוא המפתח במערכת המקור, כדי לחזור לרשומה המקורית. SK (Surrogate Key) הוא מפתח דמי שנוצר לצורך המחסן, והוא מחבר את ה-Dimension ל-Fact ביחס של אחד לרבים.sales SK היא היחידה עם ערך ייחודי לכל שורה. אותו order SK חוזר שלוש פעמים, כי בהזמנה היו שלושה מוצרים (בדוגמה 114, 157 ו-141), ובטבלה ממוינת נראים 100, 101 ו-102.פרקי ההרצאה: הבדלים בין מסד נתונים רגיל ל-Data Warehouse
תמלול ההרצאה: הבדלים בין מסד נתונים רגיל ל-Data Warehouse
הטקסט המלא של הדקות הראשונות בהרצאה «הבדלים בין מסד נתונים רגיל ל-Data Warehouse» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בשיעורנו היום נבחן את ההבדל שבין מבנה של Data Warehouse לעומת מבנה דאטאבס רלציוני שמשמש אותנו כ-OLTP. בתוך בסיס הנתונים אנחנו מכירים את בסיס הנתונים שעליו אנחנו עובדים.
לצורך הדוגמה לקחתי את לופווינד, ואם אני אכנס לתרשים ERD שלו על מנת לבנות את המערכת עצמם, אני אוכל לראות מבנה היררכי של הטבלאות. בשעה שאני בוחר אותם אז אני אצטרך לבחור את הטבלאות הרלוונטיות שאותם אני רוצה להציג בואו נבחר לנו חלק מהטבלאות על מנת לא להעמיס על התרשים ועל מנת שנוכל בקלות לראות את תורף הנתונים
עצמם שכרגע מעניינים אותנו. לקחתי את הטבלאות שעוסקות בעיקר בתהליך המכירה עצמו, את המוצרים, את ההזמנות, order details ואת כל הטבלאות לוויין שנמצאות מצידם.
ברגע שבחרתי את הטבלאות עצמם נבנה לי כאן תרשים ERD, מבנה שהוא בעצם כרטיס ביקור של הדאטאבס, בואו נתרשם ממנו.
נזיז מעט את הטבלאות על מנת לראות את הקשרים שביניהם. אני רואה שטבלת ריג'ן לא מחוברת, ולכן אנחנו נוותר עליה בשלב הזה. וטבלת Suppliers נמצאת כאן.
קודם כל, כדי להתרשם מהנתון עצמו, קודם כל אני אעשה זום-אאוט רק לראות את המבנה של הטבלאות ואת הקשרים שביניהם. בדאטאבס אופרשיונל, בדאטאבס OLTP, דאטאבס שבעצם משרת לנו את עמדות התפעול שלנו או LTP, Transactional Processing.
כך נראה דאטאבס טיפוסי. הטבלאות מקושרות זה לזה, לעיתים טבלה מקושרת לעצמה, Foreign Key של הטבלה לתוך עצמה, מפאת סיבות מסוימות.
ישנן טבלאות שמקושרות למספר גורמים, אנחנו רואים כאן ש-Orders מחובר לכמה, קודקטס מחובר למספר טבלאות, אורדר דיטלס מחובר לכמה טבלאות ואנחנו רואים איזשהו קשר בעצם שיוצר לי בסופו של דבר את האילוצים שכל אחד מהקשרים הללו מייצג לי את הפורנד קיז,
את האילוץ על מנת לבצע הכנסה של אחד לרבים. זהו מבנה טיפוסי של דאטאבס רלציוני, דאטאבס שכל הנתונים בו מאוכלסים בתוך טבלאות עם קונסטרנטים, נעבור לראות בסיס נתונים זהה לחלוטין מבחינת הדאטה שלו שכן לקחנו את כל הדאטה שהיה לנו בתוך נורפינד ובנינו סכמה של דאטה וייראוס אותו דאטה רק במודל אחר מודל שלא משרת לי את המבנה ה-OLTP משרת לי את הדרישות התפעוליות
של החברה אלא משרת לי את הדרישות הניתוח של המידע של האנליסיס של ה-OLAP במודל הזה הנתונים מאורגנים בצורה אחרת כפי שנראה אותם נכנסתי לתוך ה-Warehouse שבנינו אותו, קליק עם אני על מנת ליצור את הדיאגרמה של הנתונים, נבחר כאן את כל הטבלאות עצמם.
כאן הטבלאות כפי שאנחנו רואים וכפי שדיברנו על כך בשיעור הקודם, מחולקות לי ל-Dimensions ול-Fact. גם בשמות שלהם אני יכול לראות זאת. על מנת לבדל את הטבלאות ביניהם, אז נתנו להם קידומת לטבלאות שהן Dimensions לעומת טבלאות שמייצגות Fact.
כל הטבלאות עצמם, כשאנחנו בונים את ההיררכיה, את המבנה שלהם, אם נסתכל, נעשה רגע זום-אאוט רק כדי לראות את זה מבט ציפור של כל הטבלאות, כרגע הם במבנה של סטאר, כמו שאמרנו.
כשאנחנו מדברים על סכמה של דאטה מסוג דאטה warehouse, מדובר על שתי סכמות שונות, או סכמה של סטאר, שבה כל ה-dimensions שנמצאים מסביב לפקט מחוברים לפקט, וכל הטבלאות בעצם מחוברות לפקט עצמו, שה-Dimensions יש ביניהם עוד איזה היררכיה, דיברנו על מבנה של Snowflake.
Snowflake, בדוגמה שלנו כרגע, אנחנו רואים Data Warehouse בארכיטקטורה של star, שבה כל טבלאות ה-Dimensions, כל המימדים, סובבים סביב טבלת ציר אחת, טבלת Measures אחת, טבלה שבה יש את הנתונים המספריים עצמם, טבלת fact.
נעשה drill-down כדי לראות בפנים את הטבלאות. אז עכשיו אנחנו רואים אותם קצת יותר בבירור. אז טבלת fact שלנו מכילה בעצם מספר מפתחות כמספר ה-dimensions שמקיפים אותם.
עבור כל dimensions אנחנו צריכים בעצם ID כדי להתחבר אליו. order SK, product SK, date SK, customer SK ו-employee SK עבור כל אחת מהטבלאות שנמצאות מסביב לטבלת fact.
אחרי שחיברנו את כל הטבלאות לרשומה בודדת, כל רשומה מכילה את המספרים, את ה-measures, את המדדים עצמם, לא את המימדים אלא את המדדים, את הערכים המספריים עצמם עבור הפרמוטציה הרלוונטית שכל שורה בטבלת fact מייצגת.
נמצאנו אפוא למדים שבטבלת fact אנחנו נראה מפתחות עבור כל טבלאות dimension שמסביב, אנחנו נראה גם נתונים מספריים עבור כל טבלת דימנשיאנס, אנחנו נראה דבר מעניין.
שימו לב, אני כרגע נכנסתי זום אין לתוך טבלת דים אימפלואיז, שהיא מייצגת לנו טבלת דימנשיאנס בתוך הדאטה וייראוס.
כשאנחנו מסתכלים על הטבלה הזאת, המבנה שלה מאוד מעניין. ראשית, יש בו את העמודות הרלוונטיות, את הדאטה שאותו אני גזרתי מתוך הדאטאבס התפעולי, ושהחלטתי שכדאי לי לעבוד עליו כי אותו אני צריך לצורך הניתוחים שלי בתוך ה-Data Warehouse.
אז זה המידע שגזרתי אותו, שעשיתי לו אקסטרקט, ה-E שלנו. אולם, אנחנו מגלים שבתחילתו של הטבלה, עבור כל טבלה יש לנו שתי מפתחות.
יש לנו Employee SK ו-Employee BK. מהם אותם שתי המפתחות ומדוע עבור כל טבלה אנחנו צריכים שתי מפתחות? ההסבר לכך הוא מאוד מאוד פשוט. יש לנו את הטבלת Employee BK, BK משמעותו Business Key.
זהו מפתח ביחס להופעה של אותה רשומה בדאטאבס הרלציוני, בדאטאבס התפעולי, בדאטאבס של ה-OLTP. כלומר, כאשר אנחנו נחבר את הרשומה הרלוונטית לבסיס נתונים שממנו גזרנו את הרשומה עצמה, גזרנו את המידע עצמו, כדי לדבר עם אותו דאטאבס, שם המפתח שלנו זה ה-Employee BK.
אולם על מנת לדבר בתוך סביבת הדאטה וייראוס, בתוך הקשר שבין טבלת דים לטבלת פאקט, כאן בדאטאבס שלנו, כאן אנחנו כבר צריכים מפתח אחר.
כאן אנחנו צריכים Employee SK. SK משמעות הדבר סורגייט כי זה לא מפתח אמיתי לעומת הדאטאבס הרלציוני ה-OLTP של הרשומה עצמה שממנו הבאנו את הרשומה עצמה, זה מפתח כביכול דמי, זה מפתח שיצרנו אותו רק לטובת הדאטה וויראוס.
רק בעולם של הדאטה וויראוס, רק בדאטאבס הרלוונטי שבו אנחנו נמצאים כעת, הדאטה וויראוס עצמו, ה-all-up שלנו, שם כדי לחבר את הרשומה הזאת יחד עם הרשומה המתאימה לה בטבלת fact, יצרנו את ה-SK.
נמצאנו איפה למדים, עכשיו אנחנו נעשה זום-אאוט, אני רוצה לראות כאן שתי ישויות שמחוברות ביניהן, טבלת דים וטבלת פקט, ואני רוצה לראות במה הן מחוברות,