הסבר על Surrogate Key
valid from ו-valid to, ובתוקף נוכחי מוצב תאריך עתידי רחוק כמו 9999.פרקי ההרצאה: הסבר על Surrogate Key
תמלול ההרצאה: הסבר על Surrogate Key
הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על Surrogate Key» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
מושג נוסף שאנחנו צריכים להכיר בעבודה בדאטה וייראוס הוא סולו גייט איז, מפתח דמי שאנחנו מוסיפים אותו רק למערכת דאטה וייראוס.
במערכות דאטה וייראוס החיבור שלנו בין הטבלאות פאקט ודימנשיונס מבוצע על ידי פורים כי פאקט בסטאר סקימה של דאטה וייראוס נמצא במרכז ומסביבו אנחנו אוחזים בהרבה מאוד דימנשיונס שכל אחד מתאר ישות אחרת רלוונטית לביצועים שאותם החברה רוצה למדוד, למדדים שאותם החברה רוצה למדוד.
היחס בין ה-Fact לדימנשיאנס הוא יחס של אחד לרבים. על כל מופע ייחודי כאן בתוך הדימנשיאנס אנחנו מבצעים מספר שורות מאחר ואנחנו מופיעים כאן מספר ערכים, מספר שורות מאחר ואותו פרודקט מופיע בפרמוטציות שונות בהתאם לשאר הדימנשיאנס שקיימים.
במקרה שלנו, פרודקט, אז יש לו פריימרי קי אחד ויחיד, אז בטבלה כאן הוא יופיע כיוניקי אחד, אולם אותו פרודקט יופיע בחלוקות לפי תאריכים שונים, יכול להיות לפי מפתחות שונים של עובד, לפי הזמנות שונות, לפי לקוחות שונים, כל אחד מההתפלגות,
הפרמוטציות בהתאם לדימנצ'יונס שיש, כך אותו מוצר יופיע מספר פעמים, ולכן אנחנו מדברים על קשר של אחד לרבים. במצב כזה אנחנו צריכים מפתח שיזהה לנו בצורה חד ערכית את הנתונים בתוך פרודקטס ביחס לרשומה שלו בתוך טבלת פאקט.
כדי לעשות זאת אז אנחנו יוצרים מפתח נוסף, הוא המפתח שנקרא סורוגייט אי, מפתח שרלוונטי רק לעולם הזה של הדאטה וייראוס, לבסיס נתונים של הדאטה וייראוס.
It is important to create it correctly, חייבים ליצור אותם בצורה נכונה וחייבים ליצור את המפתחות הללו, מאחר שבאמצעותם אנחנו יכולים לחבר בין שתי הטבלאות, ובאמצעותם אנחנו מוודאים יוניקיות בתוך טבלת פרודקטס, לעומת ריבוי מופעים בתוך טבלת פקט.
מה הפתרונות האחרים שיכלו להיות לנו על מנת לשרת את המודל שלנו, ללא הפתרון שאותו אנחנו רוצים כרגע להציג? היינו משתמשים באותו פריימרי קי שקיים במערכת התפעולית.
זאת אומרת, אם היינו משתמשים באותו מפתח שקיים במערכת התפעולית, היינו מביאים אותו ומשתמשים איתו גם כאן בתוך המערכת של ה-Data Warehouse.
הדבר הזה לא נכון ולא תקין מאחר ויכולות להיות לנו Overlapping Rows, יכול להיות לנו בעצם חיתוך בין מערכות שונות שבתוכם יש את אותו מוצר, את אותו ID עבור מוצרים שונים.
נותן דוגמא בהנחה שאנחנו רוצים לייבא שתי מערכות בדוגמא שלנו source system 1 ו source system 2 משתי מערכות הללו אנחנו רוצים לייבא נתונים לשפוך אותם לתוך הדאטה וייר האוס בדאטה וייר האוס שלנו אנחנו רוצים להיות מזהה חד ערכי עבור כל אותם מוצרים אממה המוצר צ'וקולד צ'יפ אוקיי
העוגיות שוקולד הללו, ה-ID שלהם במערכות שבהם הם נמצאים, המזהה החד ערכי שלהם הוא 3. גם הפוטטו באותה מערכת שבו הוא נמצא, שזו מערכת אחרת, המזהה החד ערכי שלו הוא 3.
זאת אומרת שאם נייבא את שני המוצרים הללו ונישאר עם אותו פריימרי קי כפי שהוא נמצא במערכת ה-LTP שלהם, כפי שהוא נמצא במערכת ה-Operational שלהם, במערכות הללו יש להם במקרה הזה ID, זאת אומרת שלא נוכל לזהות אותם בצורה חד ערכית בתוך הדאטה וייראוס.
אי לכך אנחנו חייבים למרות המזהה החד ערכי שיש להם בתוך המערכות שלהם כל אחת והמערכת שלה כל מוצר והמערכת מאיפה מייביאים אותו אנחנו חייבים ליצור מזהה חד ערכי נוסף הרלוונטי לתוך הדאטה וייראוס.
מהו יהיה אותה עמודה? מה יהיה המזהה הזה? מה התכונות שלו? קולום מספר אינטג'ר קולום, מספר אינקרימנטלי רציף שמחולל בצורה אוטומטית, מספר שלם אינטג'ר שלא צריך careful maintenance, איזשהו טיפול מיוחד ועבודה מיוחדת.
אנחנו בעצם נשתמש על פי רוב בעמודת אידנטיטי כמאפיין שייצור לנו את העמודה הזאת. העמודה עצמה תהיה עמודה שהיא מסוג not null, היא תהיה אינקרימנטד בצורה רציפה, ועל ידי כך אנחנו יוצרים בעצם מפתח נוסף, מפתח דאמי, מפתח שהוא רלוונטי לעולם שלנו והוא נקרא כאן סורוגייט קי.
בואו נתקדם להבנה שלו. סורוגייט קי, אנחנו יכולים לפגוש אותו במערכות שונות או בטרמינולוגיות שונות או בספרות בשמות שונים, אבל הם כולם מתכוונים לאותו סורוגייט קי, לאותו משמעות של מפתח שיצרנו אותו לעולם של הדאטה וייראוס.
קינינגלס קי, אינטגר קי, לא נאטרל קי, ארטיפישיאל קי או סינתטי קי, קי שהוא בעצם סינתטי ולא טבעי לרשומה עצמה שהוא רלוונטי רק לעולם של הדאטה ויראוס, כל אחת מהשמות הללו אלו הם שמות נרדפים למושג של הסורוגייט קי.
יתרונות לעבודה עם סורוגייט קי בתוך דאטה ויראוס, כשאנחנו נעצב את הנתונים שלנו אנחנו נבנה בהם את הסורוגייט קי והיתרונות שנוכל לעשות זאת, אז כפי שראינו מקודם, מה שהיה חיסרון הופך להיות כאן יתרון.
אז במערכות ב-data warehouse עכשיו כבר אנחנו לא צריכים להיות רגישים מכמה מערכות אנחנו מייבאים את הנתונים שלנו. גם אם נעבוד ממולטיפל סור סיסטמים, מערכות שונות שהמפתחות שם הם זהים ויש חפיפה overlapping בין המפתחות ויש זהות במפתחות עצמם, רק כשהם מתארים ישויות שונות ממערכות שונות אין לנו מה לדאוג, כי בסופו של דבר כל מוצר וכל ישות שאנחנו
מביאים אותו אלינו לתוך הדאטה וייראוס, אנחנו כביכול מעבירים אותו תהליך גיור, מעבירים אותו תהליך טרנספורמציה על ידי זה שאנחנו יוצרים לו מזהה מקומי שרלוונטי רק לעולם של הדאטה וייראוס.
ומה שהיה לו לפני כן זה לא תהיה רעיה מבחינתנו. ולכן אנחנו יכולים להביא מוצרים ממערכות שונות ומאתרים או ממקומות שונים, אין לנו בעיה שאנחנו מתנגשים.
בואו נראה, לקח דוגמה. יש לי כאן שתי מערכות שמתוכן אני רוצה לייבא נתונים ולבנות את ה-data warehouse שלי. המערכות עצמן, יכול להיות שיהיה חיתוך בין המספרים ויכול להיות שלא יהיה חיתוך.
למשל המילק 123 הוא באמת מזהה חד ערכי גם במערכת System 1 וגם ביחס למערכת Source System 2, גם שם אין לי מוצר שה-ID שלו הוא 123. לעומת זאת, 776 הוא מזהה חד ערכי ברמה הזאת, הוא מזהה כאן את שוגר במערכת של סיסטם 1, אבל בסיסטם 2 הוא מזהה של המוצר אוטר, וכאן יש לנו עוד את ה-778.
אז הוא מזהה של מוצר אחר לגמרי. כיצד נתגבר על המכשול הזה, שאותו מזהה חד ערכי במערכת שלו, כשאנחנו מביאים אותו, שופכים אותו לתוך הדאטה וייראוס, הוא כבר לא מזהה חד ערכי.
מה שנצטרך לעשות כאן זה לבנות, כשאנחנו בונים את הדאטה וייראוס, שופכים את הנתונים עצמם, את המידע כאן ואנחנו נבנה שני keys.
אנחנו נבנה את ה-Original Key, את ה-Key שמייצג אותו ביחס למערכות ה-Operational. כלומר, Key שמצביע על המערכות אופרשיונל, משם הוא מביא את ה-ID המזהה חד ערכי. כלומר, אם נרצה לקחת את אותה רשומה ולחזור אחורה לאבא שלה, למקור שלה, ל-Source שלה, אז נשתמש בעמודה הזאת ב-Original Key.
לעומת זאת, כל רשומה כאן כבר אנחנו נותנים לה מזהה חד-ערכי חדש, אותו אני ברגע זה עיצבה באדום, והמזהה החד-ערכי הזה שמופיע לנו כאן הוא מזהה ברמת Data Warehouse.
למזהה הזה אנחנו נקרא על פי רוב SK, Surgate Key, או כל אחד מהשמות הנרדפים, ואילו המזהה עצמו שנמצא כאן, ה-Original Key, זה ה-Business Key, זה בעצם המפתח שהוא רלוונטי במערכת אופרשיונל ולא במערכת דאטה וויראוס שלנו.
ברגע שנעבוד עם מערכות דאטה וויראוס עם סורוגייט קי נוכל לעשות טראקינג על אותו מוצר לאורך זמן. כלומר, יהיה לנו את התענוג ליצור עומק בתוך הטבלה, עומק מבחינת תאריכים, מבחינת זמנים.
לקחת את אותה רשומה ולדעת מה היה התפלגות השינויים שלה לאורך זמן. דאטה שהשתנה בעצם לאורך הזמן. איך אנחנו נעשה זאת?
בעצם אותה מוצר או אותה רשומה בתוך טבלת פקטס יכולה להיות מיוצגת על ידי אותו סורגריט קי מספר פעמים, וכך סורגריט קי הופיע לנו כמה פעמים, ובעצם הוא ייתן לנו וריאציות, ורז'ן, הוא ייתן לנו שינויים של אותה רשומה לאורך זמן.
ואז לקחנו כאן בעצם רשומה שהיא כרגע דו-ממדית, עמודות ושורות והפכנו אותה להיות תלת-ממדית עם עומק של תאריכים עצמם. נראה לכך דוגמם.
בדוגמה שלפנינו אנחנו מייבאים מוצר אבל אנחנו מייבאים אותו מאותה מערכת. כאן לא מדובר על מערכות שונות אלא על אותה מערכת. אממה, אנחנו מייבאים אותו בתאריכים שונים.
ישנם תאריכים שונים של יבוא שבהם גזרנו את הנתונים מתוך המערכות Operationally לתוך ה-Data Warehouse. שני התאריכים הללו, קיבלנו על אותו מזהה חד ערכי 378, קיבלנו שינוי של השם של המוצר.
כלומר, לא מדובר כאן על מוצרים שונים עם אותו אוידי, אלא זה אותו מוצר שאולי השתנה לו השם, אולי השתנו לו המאפיינים. במקרה שלנו השתנה לו השם בין התאריכים עצמם.
השם עצמו השתנה. צ'רי טופי, הפכנו את זה לסופר צ'רי טופי. כלומר, שינינו רק את השם בהתקדמות של הזמן, ב-16 לתשיעי 2018 השם עצמו השתנה, כיצד זה ישפיע עלינו בגזירה של הנתונים שנביא אותם לתוך הדאטה וויראוס.
ובכן, בתוך הדאטה וויראוס, אף על פי שיש לנו את 378 כמזהה חד ערכי של אותה רשומה שהגיעה של אותו מוצר, כדי לבדל בין 378 לפי תאריכים שונים, ה-thoroughgate key מאפשר לי בעצם על ידי זה שהוא מופיע פעמיים, דולגייט קי שונים, 112, 244, שני מספרים שונים עבור אותו מוצר,
ומכאן אני יכול לדעת שמדובר על אותו מוצר מאחר והאוריג'ינל קי שלו בסופו של דבר הוא אותו