ארגון BI שלא דואג לבצע השלמת REFERENTIAL INTEGRITY (להלן השלמת RI) מסתכן באיבוד חלק מהרשומות שלו כאשר מבצעים שאילתות. מאמר זה מבוסס על הניסיון שלי בחברת אופיסופט
רקע
REFERENTIAL INTEGRITY, אמורים לעשות בכל מערכת תפעולית רלציונית (כל בסיסי הנתונים תומכים בזה). אך מאחר שאמור זה שם של דג, בפועל RI מתבצע במעט מאוד ארגונים. הסיבה העיקרית לכך היא איבוד ביצועים.
שהרי אחרי כל הכנסת רשומה של טבלת בן, בסיס הנתונים ניגש לטבלת האב ומוודא שאכן יש אבא, וכך אנחנו סמוכים ובטוחים לגבי שלמות הקשרים בין הטבלאות. כידוע, אם מאפשרים למשתמש להכניס מידע לא חוקי ל-DATABASE אזי אכן זה מה שיקרה. הפתרון הוא לדאוג שבסוף שלב ה ETL, יוכנסו הרשומות ל-DB בתהליך שנקרא השלמת RI.
מניסיון בארגונים שונים נחשפתי לשלושה סוגי טיפולים בנושא :
1. חוסר מודעות ל RI – כלומר הנושא לא מטופל בכלל. התוצאה – אבדן רשומות אשר נופלות ב JOIN. ולצערי ראיתי את זה קורה בלא מעט ארגונים.
2. לא מבצעים השלמת RI בכלל אבל דואגים ל LEFT JOIN בכל שאילתה. למרות ששיטה זו נותנת פתרון חלקי יש לה חסרונות רבים. ביניהם:
- מבחינת ארכיטקטורה, שלמות הנתונים צריכה להיות בDWH ולא בשלב מאוחר יותר.
- תידרש כפילות פתרונות במקומות שונים, שיביא לכפילות בתחזוקה, בלבול, ויותר מ "אמת ארגונית אחת".
- ביצועים של המשתמשים יפגעו בגלל ה LEFT JOIN.
- מקור רב ל באגים מאחר ו- LEFT JOIN דורש מיומנות רבה ולעיתים התערבות של DBA אפליקטיבי.בסדנאות, שאני מעביר, מומחשים מקרים רבים ששינוי קל נותן תוצאות אחרות, וצריך להבין טוב טוב מה רוצים בהשוואה ל INNER JOIN שהוא פשוט יותר.
3. פתרון נכון BY THE BOOK – וידוא השלמת RI לאחר שלב הטעינה, דהיינו בסוף שלב ה-ETL.
המימוש פשוט – שולפים DISTINCT FROM FACT שלא נמצא ב-DIM ומשלימים את הקוד ל אותו ה-DIM.
בשאר הערכים מוסיפים 1- (מינוס אחד) או ערך "לא ידוע".
דוגמא:
שלב I –
SELECT DISTINCT city_code FROM FAC_TABLE WHERE city_code NOT IN (SELECT city_code FROM DIM_TABLE)
שלב II –
INSERT INTO DIM_TABLE (city_code,city_name,region (VALUES(p_city_code_FROM_ABOVE, "לא ידוע",1-)
טיפ 1– מומלץ לשלוף מטבלת MIROR שמכילה אך ורק דלתא. מאחר וזו טבלה קטנה, השליפה תהיה מהירה יותר.
טיפ 2 – רצוי שהתהליך יתמוך באפשרות של טעינה ב NEAR REAL TIME
