ניהול שינויים במימד

By | 22 ביוני 2010

מאמר זה הינו המאמר השלישי בסדרה של ארבעה מאמרים אשר מתארים את הדרך הטובה ביותר לדעתי לנהל שינויים במימד (Slowly Changing Dimension) באמצעות SQL Server 2008.

המאמרים הקודמים דנו ברכיב ה- Output אשר התווסף לפקודות השינויים בטבלאות (Update, Insert, Delete) ובפקודה החדשה (מגרסה 2008), Mקרעקה 2008חדשה Deleteינויים בטבלאות אמרים אשר מתארים את הדרך הטובה ביותר לדעתי לנהל שינויים במימד erge.

מאמר זה יעסוק בתיאוריה של ניהול שינויים במימד וזאת כהקדמה למאמר האחרון אשר יתאר את אופן הביצוע בפועל.

מדוע לנהל שינויים במימד?

נניח שיש לנו מימד לקוחות בנק ובו היררכיה של סניף הלקוח ß לקוח. בקוביה מנתחים את ההכנסות מלקוחות בסניפים השונים. ביוני 2010 עבר הלקוח משה כהן מסניף חיפה לסניף תל אביב. ישנן מספר צורות בהן נוכל לשקף שינוי זה בקוביה ולכל צורה ישנו מספר סידורי:

SCD Type 1
אנו נרצה לראות רק את המצב האחרון של הלקוח. כלומר הלקוח עם כל ההכנסות שלו עברו מסניף חיפה לסניף תל אביב. למעשה גם ההכנסות שהניב הלקוח בשנים עברו בסניף חיפה, נמצאות עכשיו תחת סניף תל אביב.

SCD Type 2
אנו נרצה לשמר את היסטורית השינויים במימד. כלומר ההכנסות מהלקוח משה כהן יהיו תחת סניף חיפה עד מועד המעבר ותחת סניף תל אביב ממועד המעבר והלאה. אופן שמירת השינויים בשיטה זו הינו באמצעות הוספת רשומה חדשה למימד החשבונות בעת השינוי. שיטה זו הינה הנפוצה ביותר ואנו נממש את שמירת השינויים סדרת המאמרים על שיטה זו.

SCD Type 3 – שמירת השינויים באמצעות מספר שדות. במקום להחזיק שדה סניף לקוח, נחזיק שני שדות: סניף נוכחי וסניף קודם. שיטה זו מגבילה את מספר השינויים הנשמרים למספר השדות שהוגדרו מראש.

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

Type 6 – Hybird לא תתואר במסגרת מאמר זה.

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

קריאה נוספת:

חבילת הבינה העסקית של מיקרוסופט מאפשרת לנהל את השינויים במימד באמצעות אשף ה- Slowly Changing Dimension אשר הינו חלק מ- Integration Services החל מגרסת 2005.

ברם לאשף זה ישנן מספר מגרעות אשר מונעות ממני להשתמש בו:

  • הוא איטי. בשימוש מול טבלת מימד עם מעל 10,000 SSIS עם הרכיבים שהקים האשף פועל לאט.
  • הוא לא ממש אשף. בסיום שלבי האשף נוצרים מספר אובייקטים של SSIS. אין אפשרות לבצע שינויים אלא יש צורך בהרצה של הכל מחדש.
  • חסרה גמישות. לדוגמה אני אוהב שבמימדים בהם אני מנהל שינויים, יהיה שדה בו נשמר יומן של השינויים ברשומה: (תאריך X רשומה חדשה, תאריך Y הרשומה הפכה לפגת תוקף עקב שינוי בשדה עיר מגורים וכו').

ישנם שני פתרונות אחד באמצעות ייבוא רכיב חיצוני ל- SSIS והשני באמצעות פקודת T-SQL חדשה, Merge.

רכיב חיצוני ל- SSIS ניתן לייבא מתוך Codeplex. לרכיב קוראים Kimball Method SSIS Slowly Changing Dimension Component בפועל אין לרכיב זה כל קשר לראלף קימבל. באם, מפתחיו טוענים שבניגוד לאשף המקורי, רכיב זה מאפשר לבצע ניהול שינויים
על פי שיטת ראלף קימבל. ניסיתי להשתמש ברכיב זה. אני מודה שהוא היה מסובך מעבר לתחום היכולת המנטלית שלי.

נשארה שיטת הניהול השינויים באמצעות פקודת ה- Merge. במאמר הבא אשר יהיה האחרון בסדרת ארבעת המאמרים על ניהול שינויים, יתואר אופן השימוש בפקודה זו על מנת לנהל שינויים במימד.


Share

One thought on “ניהול שינויים במימד

  1. Pingback: ניהול שינויים במימד באמצעות T-SQL | BI and More

כתיבת תגובה

האימייל לא יוצג באתר.