|
נרמול מסדי נתונים –חלק 2כעת, המידע שלנו מאורגן בטבלה, אך עדיין יש כמה בעיות עמו. בטבלה שלנו אנו מאחסנים מידע, שבו קוד 1023 מתייחס 3 פעמים לאתר טיולים מדגסקר. מלבד בזבוז מקום יש כאן בעיה חמורה נוספת. תסתכלו היטב על הנתונים הבאים: Employee project table
שמתם לב למשהו יוצא דופן בנתונים שהובאו לעיל? מדגסקר מאוית באופן שונה ברשומה השלישית. תארו לכם אם הייתם צריכים למצוא את הטעות הזו בטבלה עם אלפי רשומות! אם משתמשים במבנה שלעיל, הסיכויים לשיבושים בנתונים עולים באופן דראסטי. הפתרון הוא הסרת הכפילויות. באופן רשמי אנחנו מחפשים תלויות חלקיות, כלומר שדות שתלויים בחלק מהמפתח ולא במפתח כולו. מכיוון שמספר פרויקט ומספר עובד ביחד מרכיבים את המפתח, נחפש שדות שתלויים רק במספר עובד או רק במספר פרויקט. אנחנו מזהים שני שדות. שם פרויקט תלוי רק במספר פרויקט ( employee_number לא משחק תפקיד בהגדרת שם פרויקט, זה נכון גם לגבי שם עובד, תשלום לשעה, קטגוריית התשלום, שתלויים במספר עובד). נוציא את שני השדות הללו. Employee project table
ברור, שלא נוכל להוציא נתון ולהשאירו מחוץ למסד הנתונים. אנחנו מוציאים אותו ומכניסים לטבלה חדשה, המורכבת משדה בעל תלות חלקית והשדה שבו הוא תלוי. כך זיהינו את שם העובד, תשלום לשעה וקטגוריית התשלום כתלויים במספר עובד. הטבלה החדשה תהיה מורכבת ממספר עובד כמפתח, ושם עובד, תשלום לשעה וקטגוריית התשלום, כפי שרואים בטבלה הבאה: Employee table
אותו דבר לגבי המידע על פרויקט. Project table
שימו לב לירידה בכפילויות. הטקסט “Madagascar travel site" נשמר רק פעם אחת, ולא עבור כל מופע של עובד שמועסק שם. הקישור נעשה דרך המפתח – מספר פרויקט. כמובן, שאין דרך להסרת כפילויות של מספר זה ללא איבוד הקשרים אך זה הרבה יותר יעיל לאחסן כמה פעמים מספר קצר, מאשר טקסט ארוך. תוכן עניינים נרמול מסדי נתונים - חלק 3 פרק 1 -> פרק 2 -> פרק 3 -> פרק 4 -> פרק 5 -> |