תלות טרנזיטיבית במסד נתונים היא מערכת יחסים עקיפה בין ערכים באותו טבלה שגורמת לתלות פונקציונלית. כדי להשיג את תקן הנורמליזציה של טופס רגיל שלישי (3NF), עליך לבטל כל תלות טרנזיטיבית.
מטבעו, תלות טרנזיטיבית דורשת שלוש תכונות או יותר (או עמודות מסד נתונים) בעלות תלות פונקציונלית ביניהן, כלומר, עמודה A בטבלה נשענת על עמודה B באמצעות עמודה C ביניים.
בואו נראה איך זה יכול לעבוד.
דוגמת תלות טרנזיטיבית
מחברים
| מחבר_ID | מחבר | ספר | מחבר_לאומיות |
|---|---|---|---|
| Auth_001 | אורסון סקוט קארד | המשחק של אנדר | ארצות הברית |
| Auth_001 | אורסון סקוט קארד | המשחק של אנדר | ארצות הברית |
| Auth_002 | מרגרט אטווד | סיפורו של המשרתת / | קנדה |
בדוגמה AUTHORS שלמעלה:
- ספר → מחבר : הנה ה ספר תכונה קובע את מחבר תכונה. אם אתה יודע את שם הספר, אתה יכול ללמוד את שם המחבר. למרות זאת, מחבר אינו קובע ספר , כי סופר יכול לכתוב ספרים מרובים. לדוגמה, רק בגלל שאנחנו יודעים את שמו של המחבר אורסון סקוט כרטיס, אנחנו עדיין לא יודעים את שם הספר.
- מחבר → מחבר_לאומיות : כמו כן, מחבר תכונה קובע את מחבר_לאומיות , אבל לא להיפך; רק בגלל שאנחנו יודעים את הלאום לא אומר שאנחנו יכולים לקבוע את המחבר.
אבל טבלה זו מציגה תלות טרנזיטיבית:
- ספר → Author_Nationality: אם אנחנו יודעים את שם הספר, אנחנו יכולים לקבוע את הלאום באמצעות טור המחבר.
הימנעות תלות טרנזיטיבית
כדי להבטיח צורה שלישית רגילה, הבה נסיר את התלות הטרנזיטיבית.
אנו יכולים להתחיל על ידי הסרת העמודה 'ספר' מתוך הטבלה 'מחברים' ויצירת טבלה נפרדת 'ספרים':
ספרים
| Book_ID | ספר | מחבר_ID |
|---|---|---|
| Book_001 | המשחק של אנדר | Auth_001 |
| Book_001 | ילדי הנפש | Auth_001 |
| Book_002 | סיפורו של המשרתת / | Auth_002 |
מחברים
| מחבר_ID | מחבר | מחבר_לאומיות |
|---|---|---|
| Auth_001 | אורסון סקוט קארד | ארצות הברית |
| Auth_002 | מרגרט אטווד | קנדה |
האם זה לתקן את זה? כעת נבחן את יחסי התלות שלנו:
טבלאות ספרים:
- Book_ID → ספר: ה ספר תלוי ב Book_ID .
- אין עוד תלות בטבלה זו, אז אנחנו בסדר. שים לב כי המפתח הזר מחבר_ID מקשר את הטבלה לטבלה AUTHORS באמצעות המפתח הראשי שלה מחבר_ID . יצרנו מערכת יחסים כדי למנוע תלות טרנזיטיבית, עיצוב מפתח של מסדי נתונים יחסיים.
טבלאות מחברים:
- מחבר_ID → מחבר: ה מחבר תלוי ב מחבר_ID .
- מחבר → Author_Nationality: את האזרחות ניתן לקבוע על ידי המחבר.
- מחבר_ID → Author_Nationality: ניתן לקבוע את הלאום מן מחבר_ID דרך ה מחבר תכונה. עדיין יש לנו תלות טרנזיטיבית.
אנחנו צריכים להוסיף טבלה שלישית כדי לנרמל את הנתונים האלה:
מדינות
| מדינה_ID | מדינה |
|---|---|
| Coun_001 | ארצות הברית |
| Coun_002 | קנדה |
מחברים
| מחבר_ID | מחבר | מדינה_ID |
|---|---|---|
| Auth_001 | אורסון סקוט קארד | Coun_001 |
| Auth_002 | מרגרט אטווד | Coun_002 |
עכשיו יש לנו שלושה שולחנות, תוך שימוש במפתחות זרים לקשר בין השולחנות:
- המפתח החיצוני של שולחן הספר מחבר_ID מקשר ספר למחבר בטבלה AUTHORS.
- המפתח החיצוני של הטבלה של AUTHORS מדינה_ID מחבר המחבר לארץ בטבלה COUNTRIES.
- לטבלה COUNTRIES אין מפתח זר מכיוון שאין לה צורך לקשר לטבלה אחרת בתכנון זה.
למה תלות טרנזיטיבית הם רע עיצוב מסד נתונים
מהו הערך של הימנעות תלות טרנזיטיבית כדי לעזור להבטיח 3NF? הבה נבחן את הטבלה הראשונה שלנו ונראה את הבעיות שהיא יוצרת:
מחברים
| מחבר_ID | מחבר | ספר | מחבר_לאומיות |
|---|---|---|---|
| Auth_001 | אורסון סקוט קארד | המשחק של אנדר | ארצות הברית |
| Auth_001 | אורסון סקוט קארד | ילדי הנפש | ארצות הברית |
| Auth_002 | מרגרט אטווד | סיפורו של המשרתת / | קנדה |
סוג זה של עיצוב יכול לתרום אנומליות נתונים חוסר עקביות, למשל:
- אם מחקת את שני הספרים "ילדי הנפש" ו"משחק של אנדר ", היית מוחקת את המחבר" אורסון סקוט קארד "ואת אזרחותו לחלוטין ממסד הנתונים.
- לא ניתן להוסיף מחבר חדש למסד הנתונים, אלא אם כן גם להוסיף ספר; מה אם המחבר עדיין לא פורסם או שאתה לא יודע את שמו של ספר שהיא מחברת?
- אם "אורסון סקוט קארד" שינה את אזרחותו, היית צריך לשנות את זה בכל הרשומות שבהן הוא מופיע. רישום מספר רשומות עם אותו מחבר יכול לגרום לנתונים לא מדויקים: מה אם אדם הזנת נתונים אינו מבין שיש מספר רשומות עבורו ומשנה את הנתונים ברשומה אחת בלבד?
- אתה לא יכול למחוק ספר כמו "הסיפור של מעשה ידיה" גם מבלי למחוק את המחבר לחלוטין.
אלה הן רק כמה סיבות מדוע נורמליזציה, הימנעות תלות טרנזיטיבית, להגן על הנתונים ולהבטיח עקביות.
