אם אתם מפתחים מחסן נתונים חדש ממדי או החלפת סביבה קיימת, המאמץ ליישום ETL הוא בהכרח על הנתיב הקריטי. מקורות נתונים קשים, דרישות ברורות, בעיות איכות הנתונים, שינוי היקף הפרוייקט, בעיות בלתי צפויות אחרות נאלצים ללחוץ על צוות פיתוח ETL. זה פשוט לא ייתכן שניתן לספק באופן מלא על התחייבויות המקורי של צוות הפרויקט; פשרות תצטרך להתבצע. בסופו של דבר, הפשרות האלה, אם לא נמדדות בקפידה, עלולות ליצור כאבי ראש בטווח הארוך.
פשרה 1: הזנחת דרישות SCD`s
קבוצת קימבל כתבה בעבר בהרחבה על SCD וחלופות אסטרטגיות יישום משלימים. חשוב שהצוות ETL יאמץ SCDs כאסטרטגיה חשובה מוקדם בתהליך היישום הראשוני. פשרה
נפוצה היא לדחות לעתיד את המאמץ הנדרש לתמוך כראוי SCDs, במיוחד סוג 2 ,מימד בו השינויים בו מאותרים על ידי הוספת שורות חדשות לטבלה מימד. התוצאה היא לעתים קרובות אסון מוחלט.
פשרה 2: הימנעות מלאמץ אסטרטגיה Metadata
סביבות DW\BI, יוצרות כמות גדולה של Metadata. ישנו Metadata עסקי, Metadata תהליכי, וכן Metadata תשתיתי שכוטלם צריכים להבדק, להתאחסן וכן להיות זמינים. תהליך הETL לבדו יוצר כמות גדולה של Metadata.
לרוע המזל, הרבה צוותי ETL לא נוטים לאמץ Metadata מוקדם בהתליך הפיתוח ודוחים אותו למועדים רחוקים יותר. לרוב, פשרה זאת נגרמת משום שצוות הETL אינו אוחז בעלות על אסטרטגיית metadata.
פשרה 3: אי מסירת היקף משמעותי
צוות הETLהוא לעתים קרובות תחת האקדח כדי לספק תוצאות תחת לחץ זמנים הדוק. פשרות חייב להיעשות. צמצום היקף הפרויקט הראשוני יכול להיות פשרה מקובלת. אם, למשל, מספר רב של סכמות נכללה בהיקף הפרוייקט הראשוני, פתרון אחד מימים ימימה היא לשבור את המאמץ אל מספר שלבים. זה סביר, פשרה שקל לבצע בהנחה שצוות BI\DW הפרויקט ונותני חסות של הפרוייקט מעורבים.אבל זאת בעיה כאשר צוות ETL עושה פשרות היקף ללא קשר עם צוות DW BI / פרויקט ונותני החסות. ברור, זה מתכון לכישלון .
המקור: http://intelligent-enterprise.informationweek.com .לידיעה המלאה, הקישו כאן .