REFERENTIAL INTEGRITY

(המידע באדיבות סלבה)

ארגון BI שלא דואג לבצע השלמת REFERENTIAL INTEGRITY מסתכן באיבוד חלק מהרשומות שלו כאשר מבצעים שאילתות.

====================================== רקע

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

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

======================================

שלושה סוגי טיפולים בנושא :

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

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

מבחינת ארכיטקטורה, שלמות הנתונים צריכה להיות בDWH ולא בשלב מאוחר יותר.

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

ביצועים של המשתמשים יפגעו בגלל ה LEFT JOIN.

======================================

ישנם מקרים רבים ששינוי קל נותן תוצאות אחרות, וצריך להבין טוב טוב מה רוצים בהשוואה ל INNER JOIN שהוא פשוט יותר.

פתרון נכון הוא השלמת RI לאחר שלב הטעינה, דהיינו בסוף שלב ה-ETL.

המימוש פשוט – שולפים DISTINCT FROM FACT

שלא נמצא ב-DIM ומשלימים את הקוד ל אותו ה-DIM.

בשאר הערכים מוסיפים 1- (מינוס אחד) או ערך "לא ידוע".

======================================

דוגמא:

שלב I -

SELECT DISTINCT city_code FROM FACT_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 שמכילה אך ורק דלתאות ממערכת תפעולית. מאחר DIM יחסית טבלה קטנה, השליפה תהיה מהירה יותר.

טיפ 2 – רצוי שהתהליך כן יתמוך באפשרות של טעינה בזמן אמת