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