Star inactiveStar inactiveStar inactiveStar inactiveStar inactive
 

בניית רשימות ערכים בצורה נכונה היא קריטית במערכות BI. בניית ערכים בצורה שגויה או לא יעילה עלולה לגרום לזמן תגובה רב ולרשימות מסובכות וכתוצאה, נטישת המערכת. number2.gif

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

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

רענון אוטומטי של רשימות ערכים

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

גזירה של טבלת רשימת ערכים

רשימות המבוססות על Fact Table

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

רשימות המבוססות על Dim Table

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

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

מבנה לדוגמא של טבלת רשימות ערכים

ללא קשר לכך באם הטבלה נגזרת מנתוני Fact או Dim, טבלה רגילה של רשימות ערכים צריכה להכיל את השדות הבאים:

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

* ערך נומרי-שדה זה יכיל את הערך של הרשימה בשדות שהם נומריים.

* ערך טקסטואלי- שדה זה יכיל את הערך של רשימה בשדות שהם טקסטואלים.

* ערך תאריכי-שדה זה יכיל את הערך של הרשימה כאשר השדה הוא תאריכי.

* סדר הרשימה-שדה אופציונאלי זה המתאר את הסדר של הרשימה כפי שתוצג למשתמש במידה וישנה חשיבות לסדר.

{הערה: אפשר להוסיף שדות נוספים, כפי שיתואר בהמשך}

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

מס"ד

ערך נומרי

ערך טקסטואלי

ערך תאריכי

סדר הרשימה

1

NULL

"עסקי"

NULL

1

1

NULL

"פרטי"

NULL

2

2

232446656

NULL

NULL

1

2

6655654

NULL

NULL

2

2

9655554

NULL

NULL

3

2

9898855

NULL

NULL

4

 

אופן הגזירה: הגזירה היא למעשה INSERT SELECT DISTINCT

אופן השימוש ברשימה (לדוגמא "סוג לקוח"). הSQL הוא SELECT על הטבלה בהתניית מספר הרשימה. לדוגמא: SELECT TEXTUALI FROM TABLE WHERE MASAD IS 1

אם הסדר חשוב יש להוסיף : ORDER BY SEDER

הוספת שדה רשימת ערכים לDim Table

 

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

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

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

הוספת שדה-דוגמא א

 

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

דוגמא לערכים אפשריים של מימד זה, תהיה בטבלה הבאה:

מספר סוכן

שם סוכן

LOV

LOV_SALES_NUM

LOV_SALES_DATE

1213

חיים לוי

TRUE

1520

1/11/2005

3254

מיכל כהן

TRUE

12

1/2/2005

5654

מוקי רם

FALSE

0

1/5/1999

8886

ששון קם

TRUE

25000

15/12/2005

5422

ארז לם

TRUE

4523

1/11/2005

7455

גד רן

FALSE

0

20/12/2002

 

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

בצורה הבסיסית ביותר נציג רק את הסוכנים שמכרו (קיצרנו 1/3 רשימה)

SELECT AGENT FROM DIM WHERE LOV=TRUE

באופן משוכלל יותר נוכל להציג רק את הסוכנים שמכרו משהו בחצי השני של 2005 (קיצרנו 1/2 רשימה)

SELECT AGENT FROM DIM WHERE LOV_SALES_DATE>1/1/2005

בדרך אחרת, נוכל להציג את הסוכנים שמכרו למעלה מ4000 יחידות. (קיצרנו 1/2 רשימה)

SELECT AGENT FROM DIM WHERE LOV_SALES_NUM>4000

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

הוספת שדה-דוגמא ב

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

שלב:

ת.התחלת שלב:

ת.סיום שלב:

זמן בדקות:

מקבל הזמנה:

מזמין מספק:

שולח ללקוח:

 

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

גם במקרה זה יש לנקוט באותה שיטה מהדוגמא הקודמת ולהוסיף 3 שדות למימד "עובדי החברה": lov_mekabel, lov_mazmin, lov_sholeach. כאשר רשימת הערכים תיבדל באמצעות משפט הWhere  של הSQL. באופן זה המשתמש יקבל רשימה ערכים מדויקת ונוחה.

רשימות ערכים תלויות משתמש

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

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

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

מס"ד- מספר סידורי של רשימת הערכים (למקרה שתשמש אותנו ליותר מרשימה אחת)

מספר מפקח-מספר המפקח שבחנות תחתיו נוצרה המכירה

מספר מנהל אזור-מספר מנהל האזור של המפקח

ערך נומרי-במקרה זה קוד מוצר

ערך טקסטואלי-שם המוצר

ערך תאריכי-במקרה זה לא רלוונטי

סדר הרשימה-סדר הרשימה כפי שתופיע

שדות נוספים, כפי שהודגמו בדוגמא הקודמת:

תאריך מכירה אחרון למוצר ולמפקח

כמות מוצרים עבור מפקח שנמכרו בשנה האחרונה

הערה: {אין צורך להכניס שדה בוליאני של קיום מכירה, משום שרק מוצרים שנמכרו יכנסו לטבלה זאת}

דוגמא לערכים בטבלה:

מס"ד

מספר מפקח

מספר מנהל אזור

ערך נומרי

(מספר מוצר)

טקסטואלי

(שם מוצר)

LOV_SALES_NUM

LOV_SALES_DATE

סדר הרשימה

1

25

67

12

מברג 11 מ"מ

11/12/2005

23

1

1

25

67

13

מפתח פטנט

4/3/2005

107

2

1

25

67

14

צבת חשמלית

18/1/2005

1

1

1

29

68

12

מברג 11 מ"מ

1/8/2005

80

2

1

29

68

28

מלחם אופטי

1/9/2005

45

3

1

29

68

29

נעץ מגנטית

1/10/2005

3

4

 

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

ניתן לומר כי צמצום רשימת הערכים על ידי "הוצאת" ערכים שלא משתמשים בהם, מקצרת בשיעור ניכר את הרשימה ומקלה על המשתמש.

עקרונות נוספים ברשימות ערכים

KISS

מתודולוגית KISS (Keep it simple stupid ) תקפה כאן, כמו בכל מקום שבו ישנה אינטראקציה עם אנשים. בשורה התחתונה, יש ליצור רשימות ערכים פשוטות וקלות לשימוש. בכלים מסוימים, ניתן ליצור רשימות ערכים עם תצוגה מורכבת, כגון רשימה מקוננת.למרות זאת אנחנו ממליצים לדבוק ברשימה פשוטה וקלה להבנה.

הפעל מיני שאילתא במקרה של רשימת ערכים גדולה

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

הערה: במקרה זה , יש לשקול שימוש באופרטור  LIKE במקום האופרטור EQUAL.

הצג את כל המידע הרלוונטי ברשימה

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

הראה את הערכים ב"סדר נכון"

"סדר נכון" הוא מושג תלוי הקשר.

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

בערכים נומריים: יש להציג את התאריכים בסדר מספרי (1,2,3,4...)

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

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

ככלל, כל מיון של כל רשימת ערכים צריך להתבצע באופן הבהיר למשתמש.

סיכום

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

הדף שלנו בפייסבוק

מעניין? שתפו דף זה באמצעות הטלפון הנייד

מאמרים

מגמות של ביג דאטה בעולם הביטוח
CA Technologies
SSIS - Buffer Size Optimization
קטגוריה ראשית
בדיקות BI ו-DWH לעומת הבדיקות בתחומים אחרים
קטגוריה ראשית
איסוף דרישות לפרויקטי BI
קטגוריה ראשית
כח המידע במיקוד
קטגוריה ראשית
0

Microsoft

Oracle

IBM

Informatica

Sap

SAS

Qlikview

Cloudera

Machine Learning