• ברוכים הבאים
    לאתר הקורסים שלנו!

  • קורסים בBO,SQL וDWH

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

    אנו משקיעים משאבים רבים כדי שחומר הלימוד יהיה מובן ומעודכן

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

    אנו מסבירים את החומר בסבלנות ועונים על כל שאלה

    יש לנו סבלנות לכל אחד
  • מדריכים מנוסים

    אצלנו המדריכים מנוסים הן בנושאי הקורס והן בהדרכה
  • 1
  • 2
  • 3
  • 4
  • 5
  • קורס הSQL המהפכני, המלמד SQL מההתחלה , לא רק את תחביר הפקודות אלא גם את כל הדינמיקות השונת המתרחשות בשפה.
    הקורס נלמד על מגוון בסיסי נתונים כדי לחקות את סביבת העבודה לאחר סיום הקורס.
    קראו עוד
  • בקורס זה אנו מלמדים כיצד לפתח דוחות באמצעות הWebintelligence. הקורס שם דגש על מספר נושאים, כגון הבאת נתונים מהDB באמצעות יצירת שאילתא, יצירה ועיצוב אובייקטים גרפים דוגמת, טבלה וגרף, ושימושיות למשל כדי לתזמן דוח. הקורס מלווה בתרגול רב, חלק נקודתי וחלק על ידי תרגילים מסכמים.
    קראו עוד
  • בקורס זה אנו נלמד כיצד לפתח דוחות באמצעות הWebintelligence של תוכנת Business Objects בגרסא 4.x . הקורס הוא קורס בן יום אחד למשתמשים אשר מכירים את הBO בגרסאות ישנות שלו, אשר שונות בצורה מהותית מגרסא 4. הקורס כרגיל מלווה בתרגול ובהרבה טיפים.
    קראו עוד
  • קורס ה Bo Designer Master הוא קורס ייחודי שפותח בארץ המקנה למשתמש מיומנויות מקצועיות בפיתוח עולמות תוכן באמצעות כלי הDesigner של Business Objects. קורס זה מדמה את סביבת העבודה של הDesigner וכן את המצבים והבעיות בהם נתקל בעבודתו. הקורס מועבר באמצעות סביבות של בסיסי נתונים "חיים" המכילים מודלים הקרובים מאד למודלים האמיתיים הנמצאים בפרויקטים. התלמיד בוחר את בסיס הנתונים שעליו רוצה לפתח את עולמות התוכן. (ישנן שתי אפשרויות: Sql Server או Oracle.)
    קראו עוד
  • למדתי מספר קורסים של אתר dwh.co.il בנושאי Business Objects. למרות שאני מנוסה מאד בתחום הBI למדתי דברים רבים ומעניינים שפתחו לי אפשרות לבצע דברים חדשים בעבודה היומיומית....
    קראו עוד
  • לאחר שמערכת הBO הוטמעה בארגון , החלטנו להרחיב את היריעה ולהכניס עוד משתמשים למעגל כותבי הדוחות. לצורך זה הזמנו קורסי Business Objects מאתר dwh.co.il. הקורסים של האתר היו מותאמים בדיוק למה שהיינו צריכים, המדריך הסביר בסבלנות....
    קראו עוד
  • dwh,אני חייב לכם תודה על הקורס שהעברתם לנו כאן בישראכרט - קורס מצויין ברמה גבוה, עם המון תכלס דרך תרגולים בה גם אנשי ה-BI המנוסים ביותר שלנו הצליחו ללמוד ולחדש...
    קראו עוד
  • DWH.CO.IL העבירו קורס Business Objects לקבוצת מנהלים ואנליסטים בביטוח ישיר ,הקורס הועבר בצורה מקצועית ויעילה ונגע בנקודות החשובות בעבודה היומיות....
    קראו עוד
  • במסגרת הטמעת מערכת הBusiness Objects בארגון , הזמנו קורס infoview באתר dwh.co.il....
    קראו עוד
  • הזמנו לבזק את אחת מהסדנאות BO Design למתקדמים. בהתחלה לא ידענו אם זה באמת מה שאנחנו צריכים, מאחר ויש לנו ניסיון רב בDesign בארגון....
    קראו עוד
  • פיתוח הקורסים

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

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

SCD הלכה למעשה-חלק 2

פרק בניתוח מערכות DWH

חלקו השני של המאמר הזה.

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

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

ניקח את הדוגמא, של dim_agents מחלקו הראשון של המאמר:

Agent_id- קוד סוכן המכירות

Agent_name-שם הסוכן

Agent_Region- אזור מכירה

כעת נוסיף תכונה נוספת:

שם מחלקה- Agent_Department

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

Agent_Department

Agent_Region

Agent_Name

Agent_id

Marketing

North

John Smith

1

 

 

 

כיצד נוכל לבטא את השינויים הבאים בטבלת הSCD:

נקודת התחלה: 

Agent_Region=North

Agent_Department=Marketing

לאחר מכן:

בתאריך ה1/1/2011 הAgent_Region השתנה לSouth

בתאריך ה5/3/2011 הAgent_Region השתנה לEast

בתאריך ה10/7/2011t ה Agent_Department השתנה לSales

בתאריך ה 11/7/2011 הAgent_Region השתנה לWest

בתאריך ה12/8/2012 הAgent_Department  השתנה לProduction

בתאריך ה1/10/2012 הAgent_Department השתנה בחזרה לMarketing

 

כיצד נבטא שינויים אלו בטבלת הSCD?

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

הערה

Is_Current

Date_to

Date_from

Agent_Department

Agent_region

Agent_id

השורה הראשונה , לאחר תאריך מ מכיל ערך תאריכי נמוך בצורה קיצונית

0

1/1/2011

1/1/1911

Marketing

North

1

 

0

5/3/2011

1/1/2011

Marketing

South

1

 

0

10/7/2011

5/3/2011

Marketing

East

1

 

0

11/7/2011

10/7/2011

Sales

East

1

 

0

12/8/2012

11/7/2011

Sales

West

1

 

0

1/10/2012

12/8/2012

Production

West

1

מאחר וזאת הכניסה האחרונה בטבלה, הערך עד, מכיל תאריך קיצוני והשדה is_current=1

1

1/1/9999

1/10/2012

Marketing

West

1

 

כעת לכל תאריך, יש לנו את הAttributes הרלוונטיים של המימד.

בואו נסקור טעויות נפוצות:

לגבי חיבור טבלת הSCD לטבלת הFact: אפשר להשתמש בחיבור הטרווילי לפי agent_id וכן התאריך בFact בין שני התאריכים בSCD, אך חיבור זה אינו מומלץ.

הדרך הנכונה לבצע זאת היא ליצור GK לכל כניסה בטבלת הSCD ואת GK זה לשתול בשורה הרלוונטית בFact Table. כלומר, את האלגוריתם של החיבור בין הSCD לFact לבטא בתהליך הETL ולא בזמן הרצת שאילתות. במצב כזה, השאילתא תהיה הרבה יותר יעילה וכלל, במערכות DWH לא נהוג joins מלבד inner join רגיל. שאילתות המכילות Between אינן יעילות ואינן מקובלות.

הSCD הוא לא חזות הכל: בא בצמוד למימד, אך לא מחליף אותו

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

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

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

ניקח את טבלת הFact הבאה:

total

Quantity

Product_id

Agnet_id

Sales_date

1000

5

2

1

1/1/2010

900

10

5

1

1/2/2010

1300

20

7

1

7/9/2010

3000

15

9

1

5/1/2011

9000

10

12

1

2/10/2012

1200

6

17

1

1/11/2012

יחד עם הSCD הבא:

הערה

Is_Current

Date_to

Date_from

Agent_Department

Agent_region

Agent_id

השורה הראשונה , לאחר תאריך מ מכיל ערך תאריכי נמוך בצורה קיצונית

0

1/1/2011

1/1/1911

Marketing

North

1

 

0

5/3/2011

1/1/2011

Marketing

South

1

 

0

10/7/2011

5/3/2011

Marketing

East

1

 

0

11/7/2011

10/7/2011

Sales

East

1

 

0

12/8/2012

11/7/2011

Sales

West

1

 

0

1/10/2012

12/8/2012

Production

West

1

מאחר וזאת הכניסה האחרונה בטבלה, הערך עד, מכיל תאריך קיצוני והשדה is_current=1

1

1/1/9999

1/10/2012

Marketing

West

1

 

אם נרצה לדעת את סכום המכירה יחד עם Agent_Region הנוכחי נשתמש בSQL הנוכחי:

 

Select count(total),agent_region
From fact,scd
Where scd.agent_id=fact.scd and facr.sales_date between scd.from_date and scd.to_date
And agent_id=1
And is_current=1
Group by agent_region

הערה: לצורך ההמחשה, השתמשנו בשיטת החיבור הישנה והפחות טובה

השאילתא תרוץ, אך במקום לקבל :

West  16400

קיבלנו :

West 10200

הסיבה לכך היא ש is_current מתייחס אך ורק לשורה הנוכחית (האחרונה) ושכך join עם הfact ישלוף את הרשומות מהfact אשר התאריך שלהם בין 1/10/2012 ל1/1/9999. ישנן שתי רשומות כאלו ,אשר סכומם מצטבר ל10200 בלבד.

היזהרו לא לבלבל את המשתמשים עם נוכחי והיסטורי לא לצורך

מימד רגיל משמש לקביעת תכונות נוכחיות , בעוד SCD משתמש לקביעת תכונות היסטוריות של המימד.

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

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

עיר נוכחית

עיר היסטורית

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

באיזה עיר המשתמש יבחר?

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

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

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

 

תנו לנו לייק לקבלת עדכונים שוטפים