מחסן נתונים ארגוני

הקדמה

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

ספר זה יתאר את השיטה המקובלת כיום לשמירה וניתוח נתונים, מחסן נתונים ארגוני.

מחסן נתונים – Data Warehouse

המונח מחסן נתונים הינו מושג אשר נוצר בעשור האחרון והוא מתאר סוג מיוחד של בסיס נתונים כלל ארגוני. בשונה מכל בסיס נתונים אחר בארגון, אין תפקידו של בסיס נתונים זה לשמור נתונים. למעשה כל הנתונים הנמצאים במחסן הנתונים כבר שמורים במערכת זו או אחרת בארגון. הבעיה הגדולה של ארגונים מודרניים בינוניים וגדולים איננה שמירת נתונים כפי שהיה בעבר אלא להיפך, לעיתים קרובות נשמרים נתונים רבים מידי במערכות מידע רבות אשר אין קשר בניהן. לדוגמא בחברה תעשייתית לעיתים קרובות נראה מערכת מידע אחת לניהול מלאי חומרי הגלם לייצור, מערכת שניה לניהול ריצפת הייצור ורישום שעות עבודת מכונות, מערכת שלישית להנהלת חשבונות (תשלומים לספקים וגביה מלקוחות) ומחשב בודד המריץ תוכנה לתשלום משכורות העובדים. בארגון זה, על מנת לקבל דו"ח פשוט של מספר המוצרים מכל סוג אשר נמכרו ללקוח מסוים בתקופת זמן מסוימת, התקבולים בגין מוצרים אלו ועלותם (חומרים גלם ושעות עבודה) הינה משימה אשר עשויה לגזול זמן רב מצוות מתכנתים מיומן אשר יצטרך לגשת לכל אחת ממערכות המידע, לשלוף את הנתונים הרלונטיים ואז לחברם ולעצבם לדו"ח אשר יוכל לשמש את המנהל כבסיס לקבלת החלטות. מצב זה בו הפקת דו"ח עורכת זמן רב מהווה קושי עצום בקבלת החלטות בתנאי השוק הדינמיים המאפיינים את עולם העסקים המודרני. מנהל השיווק אשר משוחח עם אותו לקוח אשר מבקש הנחה של 15% במקום 10% כפי שקיבל עד עתה ואין בידיו נתונים שלמים עשוי לגרום לארגון נזק כספי ניכר: אם ייתן את ההנחה ללא נתונים על עליית מחירי חומר הגלם הוא עלול לגרום להפסד כספי, לעומת זאת אי מתן ההנחה למרות ההתייעלות והורדת שעות העבודה על המוצרים עלולה לגרום לאיבוד לקוח חשוב. הבעיה אף מחמירה אם נזכור כי בעולם המודרני יש סיכוי רב כי מנהל הייצור נמצא במדינה א', ייצור המוצרים מבוצע במדינה ב' והלקוח נמצא במדינה ג'.

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

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

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

הערכות ארגונית לפרויקט מחסן נתונים

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

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

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

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

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

עיצוב מחסן נתונים

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

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

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

לקוחות                מכירות                מוצרים

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

כזכור, עיקר פעילות מחסן הנתונים אינה הוספת רשומות חדשות כמו במערכת התפעוליות. רשומות חדשות נכנסות למחסן הנתונים בדרך כלל כקבצים מרוכזים לאחר שעות העבודה. פעילותו העיקרית של מחסן הנתונים הינה אחזור מידע האגור בתוכו. אנו נשאף ליצור מחסן מידע אשר יוכל לאחזר את המידע בצורה מהירה ביותר. לעיתים קרובות מהירות אחזור המידע תבוא על חשבון יעילות האחסון. מחסן המידע יכילטבלת עובדות (Fact Table) מרכזית וטבלאות מקושרות אליה באופן דומה לתרשים אשר תואר לעיל. סכימה (Schema) זו של טבלא מרכזית וטבלאות לווין המקיפות אותה נקראת סכימת כוכב(Star Schema). לטבלאות הלוויין, המקיפות את ה- Fact Table ומחוברות אליה באמצעות המפתחות קוראים בדרך כלל ובלאות מימד. המימדים השונים מהווים את אפשרויות חיתוך המידע על פי נקודות מבט שונות.

נדגים יצירת סכימת כוכב עבור חברה המוכרת ציוד משרדי. לחברה מספר סניפים בארץ והיא מוכרת מוצרים שונים ללקוחות עסקיים שונים. מנהלי החברה מעוניינים לחתוך את המידע על פי המימדים: זמן, לקוח, מבנה ארגוני של החברה (סניפים ומחוזות) החברה משתמשת במחסן נתונים כדי לרכז את נתוני המכירה שלה. מבנה מחסן הנתונים יהיה: 

ניתן לראות במבנה המתואר לעיל מספר הפרות של כלל הנירמול אשר תואר לעיל:

• ב- Fact Table ישנם שדות עבור מספר יחידות אשר נמכרו וערך המכירה בש"ח. למעשה השדה ערך מכירה בש"ח הינו מיותר כיוון שבטבלת המוצרים ישנו מחיר יחידה בודדת ואם אנו שומרים את מספר היחידות אשר נמכרו אזי ניתן באמצעות מכפלה פשוטה להגיע גם לערך השני אשר לכאורה הינו בזבוז של שטח אחסון. 
  
• בטבלת החנויות מצוינת העיר בה שוכנת החנות וישנם גם נתונים המאפיינים את העיר, מספר תושבים ואזור בארץ. במידה וישנן מספר חנויות באותה עיר, הרי שהנתונים מספר תושבי העיר, ואזור גאוגרפי של העיר יחזרו על עצמם שוב ושוב. על פי התכנון המסורתי והחסכוני במקום שילוב מאפייני העיר בטבלת החנויות היה צורך ליצור טבלת ערים בה ישנם נתונים על כל הערים בהן ישנן חנויות וטבלא זו הייתה מקושרת לטבלת החנויות. כך בטבלת החנויות היינו שומרים רק מספר עיר אשר היה מפתח לטבלת הערים. 
  

הפרות אלו של כללי הנירמול יגרמו למחסן הנתונים לצרוך נפח אחסון גדול יותר אך מצד שני מהירות האחזור של המידע תהיה מהירה יותר כיוון שכל קישור בין טבלאות הינו דבר הצורך משאבי עיבוד בזמן ריצת פקודת האחזור (הפקת הדו"ח). כיוון שתפקידו העיקרי של מחסן הנתונים הינו לאחזר מידע בזמן אמיתי (Real Time) הרי שברוב המקרים נעדיף מהירות אחזו על פני יעילות אחסון מקסימלית. כמובן שההחלטה בדבר מהירות האחזור לעומת נפח אחסון צריכה לקחת בחשבון גם את שכיחות הניתוח לפי אותו נתון. אם לדוגמא יאמר מנהל השיווק אשר הינו הצרכן העיקרי של מעכת המידע בדוגמא הנ"ל כי רק פעם ברבעון הוא מוציא דו"ח על פי ערים בארץ, אזי נעדיף לא לשלם יותר בנפח אחסון על מנת לחסוך זמן של דו"ח אשר רץ פעם בשלושה חודשים.

הערה לגבי טבלת התאריכים אשר הופיעה בתרשים המתאר את טבלאות מחסן הנתונים אך לא בדוגמא הראשונה. כיוון שרצינו לשמור מידע נוסף על כל אחד מהתאריכים (אפיונו כיום חג/ערב חג או יום עבודה), נפתחה טבלא מיוחדת לתאריכים עם קישור אל ה- Fact Table.

מימדים משתנים SCD – Slowly Changed Dimensions

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

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

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

• רשומות לקוח מרובות: בשיטה זו תקושר טבלת הלקוחות אל ה- Fact Table באמצעות מפתח מלאכותי ולא באמצעות מפתח תפעולי כגון מספר זהות לקוח. בכל פעם שישתנה אחד מפרטי הלקוח בטבלת הלקוח, נפתח רשומת לקוח חדשה.
  

• הרחבת ה-
  FACT": בשיטה זו נשמור ב- Fact Table את מקצוע הלקוח (בדוגמא שלנו) בנוסף לנתוני המכירות. כדי לבצע ניתוח של מכירות על פי מקצועות לא נצטרך כלל חיבור בין ה- Fact Table לבין טבלת מימד הלקוחות. 
  

נסקור את היתרונות והחסרונות של כל אחת מהשיטות הנזכרות למעלה:

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

• רשומות לקוח מרובות: שיטה זו מאפשרת שמירה של כל היסטורית הלקוח ותחזוקתה פשוטה יחסית. גם תכנון השליפות מבסיס נתונים הבנוי על פי שיטה זו הינו קל לביצוע. ברם, במידה ובסיס הנתונים שלנו כולל מספר רב של רשומות ב- Fact Table וכן רשומות רבות בטבלת המימד (בדוגמא שלנו: טבלת הלקוחות) ובהנחה שכל רשומה בטבלת המימד משתנה מפעם לפעם, אנו עלולים למצוא עצמנו עם בסיס נתונים אשר תופס נפח רב ושליפת הנתונים ממנו צורכת משאבים רבים ועורכת זמן רב.

• הרחבת ה-
  FACT: שיטה זו הינה הקלה ביותר לביצוע אין צורך בכל פעולות תחזוקה על מנת לתפעל שיטה זו. גם שליפת הנתונים מבסיס נתונים הפועל על פי שיטה זו יהיה מהיר ביותר. למעשה כדי להוציא דו"ח של מכירות על מקצוע, לא נזדקק כלל לחיבור בין ה- Fact Table לטבלת הלקוחות אם מקצוע הלקוח יופיע ב- Fact Table עבור כל מכירה. חסרונה הגדול והמשמעותי ביותר של שיטה זו הינו הויתור המוחלט על נירמול בסיס הנתונים וכתוצאה מכך נפח האחסון של ה- Fact Table עשוי להיות גדול מהנפח העומד לרשותנו.

בחירת השיטה המתאימה לניהול שינויים במימדים תלויה במספר גורמים:

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

• כמות השאילתות המתייחסות לשדה המשתנה: ככל שהשדה המשתנה חשוב יותר לניתוח ומהווה בסיס למספר שאילתות רב יותר, כך נבחר בשיטה המצטיינת בשליפות מהירות יותר.

• גודל ה- Fact Table: ככל שה- Fact Table גדול יותר, הן מבחינת מספר רשומות והן מבחינת מספר שדות בכל רשומה, כך ויתור על נירמול הנתונים עלול להיות בעל תופעות שליליות יותר מבחינת נפח אחסון דרוש. 
  

• גודל טבלת המימד: ככל שטבלת המימד גדולה יותר, מבחינת מספר רשומות ו/או מבחינת מספר שדות ברשומה כך הוספת רשומות על מנת לשמור שינויים במימד הינה בעלת תוצאות שליליות יותר מבחינת נפח אחסון ומהירות שליפה. יש לזכור כי ברשומה אשר מכילה נניח 20 שדות, מספיק שדה אחד אשר שינה את ערכו כדי שנצטרך ליצור רשומה חדשה ולמעשה להעתיק לתוכה את כל 19 השדות אשר לא שינו את ערכם. 
  

האם זה שווה את זה?

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

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

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

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

מחזור החיים של מחסן נתונים

1. תכנון
   

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

   1. מלמעלה למטה (Top-Down Approach) – על פי אסטרטגיה זו מתחילים את התכנון מהקמה של בסיס נתונים מרכזי אשר בתוכו יהיו כל הנתונים הנכללים במחסן הנתונים כאשר משיקולים של ביצועים וזמינות נרצה לעיתים להעתיק חלק מבסיסי הנתונים לשרתי משנה הנקראים מרכולי נתונים (Data Marts) אשר ישרתו פונקציות שונות בארגון.
   2. מלמטה למעלה (Bottom-Up Approach) – על פי גישה זה מתכננים לכל אחת מפונקציות הארגון את מרכול הנתונים שלה ולאחר מכן מאחדים את כל מרכולי הנתונים למחסן נתונים אחד מרכזי על מנת לאפשר שיתוף נתונים. בפועל קורה לעיתים קרובות כי ארגון פועל על פי גישה זו לא מתוך החלטה מסודרת אלא מתוך אילוצי המציאות. לדוגמא במצב בו אין החלטה כל ארגונית להקים מחסן נתונים כללי אולם שני מנהלי מחלקות מתוך שלושה החליטו על הקמת בסיס נתונים לשרות המחלקה שלהם. במקרה כזה במידה וירצו לשתף נתונם בין כל המחלקות יהיה זול יותר להשאיר את שני מרכולי הנתונים הקיימים ולהזין מתוכם את מחסן הנתונים הכללי.
   3. שיטה מעורבת (Combination Approach) – על פי שיטה זו משתמשים בכל בסיסי הנתונים הקיימים בפונקציות השונות של הארגון ומשלבים אותם לתוך מחסן הנתונים ובמקביל לא בונים מרכולי נתונים חדשים אלא נותנים לגופים הארגוניים להם לא היו מרכולי נתונים לעבוד מול מחסן הנתונים כאשר שיקולי יעילות יכתיבו פיצול עתידי של מחסן הנתונים למרכולי נתונים.

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

1. יעדי המערכת – Business Objectives
   

   1. מהו קהל היעד של מחסן הנתונים? בדיקה ורישום של המשתמשים הפוטנציאליים במחסן הנתונים. שלב זה נראה על פניו כטריוויאלי אך הינו חשוב ביותר. למעשה היקף המשתמשים הפוטנציאליים וחשיבותם בארגון יקבע את המשאבים הארגוניים אשר נוכל לגייס לפרויקט זה. כמו כן, אפיון המשתמשים הינו הדבר המרכזי אשר ינחה אותנו בתכנון המערכת כך שתענה על צרכי לקוחותיה.
   2. מהן הפלטפורמות עליהן נשענים כיום על מנת לספק נתונים לאותם משתמשים? בשלב זה אנו בוחנים כיצד המשתמשים אותם זיהינו בסעיף הקודם מפיקים את המידע לו הם זקוקים. אנו נרצה להבטיח ששיטת הבודה תהיה קלה, מהירה ואמינה יותר לאחר יישום מחסן הנתונים ולכן חשוב תיעוד השיטות הקיימות.
   3. תיעוד היכולות והתכונות החזויות של מחסן הנתונים. בשלב זה אנו מסתמכים על שני הסעיפים הקודמים על מנת לרשום את התכונות (Features and function) באמצעותן יוכל מחסן הנתונים לספק את הצרכים אשר קיימים אצל המשתמשים הפוטנציאליים שלו.
   4. תיעוד מקורות הנתונים אשר יזינו את מחסן הנתונים. אנו נבדוק ונתעד את כל מקרות הנתונים בארגון אשר מהם יזון מחסן הנתונים. בנוסף ירשמו כל המניפולציות אותן יש לבצע על מנת להביא את הנתונים ממצבם ההתחלתי לצורה בה הם יאוכסנו במחסן הנתונים. לדוגמא: נאמר ובמערכת התפעולית נרשמות עסקאות במטבעות שונים ובמחסן הנתונים הוחלט לראות את כל העסקאות בערכים שקליים. בעת מעבר רשומות עסקאות המט"ח למחסן הנתונים יוכפל סכום העסקאות בשער החליפין והתוצאה תשמר במחסן הנתונים.
   5. לוח זמנים להפעלת מחסן הנתונים. בשלב זה אנו מעריכים את משך הזמן אשר יידרש לביצוע כל שלב בפרויקט. אנו נבדוק גם האם ישנם תהליכים אשר יכולים להתבצע במקביל לתהליכים אחרים וכן תלויות בין תהליכים. תיעוד זה יעזור לנו לקבוע את לוח הזמנים לפרויקט כולו. רישום התלויות בין התהליכים יעזור לנו לזהות אפשרות לקיצור משך הפרויקט על ידי הוספת כוח אשם לביצוע תהליכים במקביל.

1. היקף הפרויקט
   

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

1. חלוקה על בסיס מבנה ארגוני – מספר וסוג המחלקות אשר ישתתפו בפרויקט.
   
2. חלוקה על בסיס טכני – מספר מקורות הנתונים אשר ישתתפו בפרויקט. 
   
3. חלוקה על פי מודל עסקי – השאלות העסקיות איתן יעזור המידע אשר יסופק בסוף הפרויקט לפתור. 
   
4. חלוקה על פי תקציב – תיחום הפרויקט מבחינת התקציב אשר במסגרתו עליו לפעול. 
   
5. זמן – קביעת מסגרת זמן להשלמת הפרויקט. 
   

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

ניתן לקרוא מאמרים נוספים בבלוג שלי: www.OLAP.co.il

אשמח לענות על כל שאלה בטלפון: 054-5232-799 או במייל rimon@olap.co.il