Facebook
Twitter
RSSמדריך תכנון בסיס נתונים – חוקי נרמול הטבלאות
מהו נרמול טבלאות ולמה זה טוב?
על רגל אחת, הנרמול הוא תהליך שיפור יעילות בסיס הנתונים שלנו. ועכשיו, כמובן, נעבור להסברים מפורטים.
חוקי הנרמול הם ארבעה חוקים הגיוניים ולוגיים שמאפשרים לנו לתכנן את בסיס הנתונים שלנו בצורה הגיונית, למנוע בעיות בעתיד, לצמצם את שטח הדיסק שבסיס הנתונים תופס ואולי הסיבה החשובה מכולם:
להביא את בסיס הנתונים למצב שיהיה קל לעבוד אתו בעזרת SQL.
סה"כ, קיימים 5 חוקי נרמול ועוד חוק אחד, קצת פחות רשמי: שלושת הראשונים בסיסיים, הרביעי מורכב קצת יותר והשימוש בחמישי נדיר מאד.
- החוק הראשון מטפל בקשר של יחיד-ליחיד (1:1)
- החוקים 2 ו-3 מטפלים בקשר של יחיד לרבים (1:N)
- החוקים 4 ו-5 מטפלים בקשר של רבים לרבים (N:N)
בפרק זה נדון בארבעת החוקים הראשונים. בחוק הנוסף (Domain key normal form – DKNF) לא נדון, בעיקר בגלל מורכבותו והתדירות הנמוכה בה משתמשים בו.
מושגים בסיסיים:
- שדה
– נתון בסיסי המאפיין ישות מסוימת. לדוגמה: הנתון הבסיסי מס' טלפון יאפיין את הישות "תלמיד". - מפתח ראשי (FK)
– שדה המזהה באופן חד ערכי רשומה מסוימת. למשל: מספר תעודת זהות. - מפתח מורכב
– אוסף של שדות המהווים ביחד מפתח ראשי. למשל: בטבלת "גולים", מספר המשחק והזמן המציין את הבקעת הגול יהוו יחד מפתח מורכב. - מפתח זר (FK)
– שדה המצביע על מפתח ראשי בטבלה אחרת. למשל: בטבלת תלמיד, מס' הכיתה הוא מפתח זר. - רשומה
– אוסף של שדות, שיש בניהם קשר. למשל: רשומת תלמיד תכלול מספר ת.ז, שם, כתובת ועוד.
חוק הנרמול הראשון (1NF)
A table is in first normal form (1NF) if and only if every attribute in the table is atomic.
טבלה מנורמלת ברמה הראשונה אם ורק אם כל רכיב בה הוא אטומי.
למשל, בטבלת תלמידים, העמודה "שם התלמיד" תהיה מפורקת לשתי עמודות: שם פרטי ושם משפחה.
חוק זה מאפשר לנו לעשות מניפולציות בקלות על הנתונים בעזרת SQL, ללא צורך בפעולות מכוערות על מה שנתקבל לאחר השאילתה. נמשיך עם הדוגמה שלנו: אם הטבלה לא הייתה מנורמלת, היינו צריכים אלגוריתם מסורבל ומיותר שידע להבחין בין השם הפרטי לשם המשפחה:
1. לצמצם רווחים משני הצדדים: " שלום שמחון " => "שלום שמחון"
2. לצמצם כל יותר מרווח אחד לרווח אחד: "שלום שמחון" =< "שלום שמחון"
3. איתור המיקום של הרווח. מתחילת המחרוזת עד המיקום של הרווח זה השם הפרטי. ממיקום הרווח עד סוף המחרוזת זה שם המשפחה.
בוודאי שמתם לב שזה מיותר.
במקרים רבים, הטבלה לא תהיה מנורמלת ברמה הראשונה (NFNF), למשל במצב שמצריך שמירת תאריך ושעת לידה. לפי חוק הנרמול, אנו צריכים עמודה נפרדת לתאריך הלידה ועמוד נפרדת לשעת הלידה. ברוב המקרים, התאריך והשעה נשמרים בשדה אחד.
חוק הנרמול השני (2NF)
A table is in second normal form (2NF) if and only if every non-key attribute in the table is functionally dependent on the entire primary key.
טבלה מנורמלת ברמה השנייה אם ורק אם היא מנורמלת ברמה הראשונה וכל מאפיין שהוא לא חלק מהמפתח הראשי, נשען על המפתח הראשי – על כל חלקיו.
חוק זה נוגע רק למצבים של מפתח מורכב.
דוגמה:
בטבלת ניסויים במעבדה, מס' המדען והתאריך והשעה בהם נערך הניסוי מהווים מפתח. מצב של שדה המכיל את שם המדען יגרום לטבלה להיות לא מנורמלת ברמה השנייה, כיוון ששם המדען לא נשען על כל חלקי המפתח הראשי, אלא רק על מס' המדען. במצב כזה, ניצור טבלת מדענים ובטבלת הניסויים יהיה שדה מפתח זר (FK) שיכלול את מספר המדען. מס' המדען ייתן לנו גישה לשם המדען, באמצעות שאילתת JOIN.
הערה:
כפי שהוסבר קודם, מצב שבו הטבלה אינה מנורמלת ברמה הראשונה נפוץ מאד, ולכן נהוג לטעון כי הטבלה מנורמלת ברמה השנייה גם אם אינה מנורמלת ברמה הראשונה.
חוק הנרמול השלישי (3NF)
A table is in third normal form (3NF) if and only if no non-key attribute in the table is functionally dependent on any other non-key attribute.
טבלה מנורמלת ברמה השלישית אם ורק אם היא מנורמלת ברמה השנייה וכל רכיב בה שאינו המפתח הראשי לא תלוי ברכיב אחר שאינו המפתח הראשי.
חוק זה נותן תשובה למקרים קלאסיים של תכנון לקוי. למשל: ברשומת תלמיד, מס' הכיתה מהווה מפתח זר. מצב בו יתווסף שדה של שם הכיתה אינו רצוי, כיוון שאז נוצר מצב של תלות בין שדות שאינם המפתח הראשי: שדה שם הכיתה תלויה בשדה מס' הכיתה.
במצב כזה נוריד את שדה שם הכיתה, וניגש אליו דרך מס' הכיתה באמצעות שאילתת JOIN.
כשטבלה מנורמלת ברמה השלישית, היא מנורמלת לפי BCNF.
חוק הנרמול הרביעי (4NF)
A table is in Fourth Normal Form (4NF) if and only if it does not represent two or more independent many-to-many relationships.
טבלה מנורמלת ברמה הרביעית אם ורק אם היא מנורמלת ברמה השלישית (BCNF) והיא לא מייצגת יותר מקשר אחד של רבים-לרבים.
טבלת קשר תייצג קשר אחד של רבים-לרבים ולא יותר, אחרת היא לא תהיה מנורמלת ברמה הרביעית. החוק בא בכדי לחסוך במקום בבסיס הנתונים (מיד יבוא הסבר…).
דוגמה:
Classes (ClassID, ClassName)
Professions (ProfessionID, ProfessionName)
נניח שלכל מורה יש כמה כיתות שהוא מלמד, וכמה מקצועות בהם הוא מתמחה. יצירת טבלה אחת שתייצג את קשרי הרבים לרבים תהיה שגויה:
הטבלה שגויה כיוון שיהיה בזבוז מקום כי יהיו שורות בהן מצוין רק מקצוע ושורות בהן מצוינת רק כיתה.
לפי חוק הנרמול הרביעי יש ליצור שתי טבלאות שונות שייצגו את קשרי הרבים-לרבים.
חוק הנרמול החמישי (5NF)
A table is in Fifth Normal Form (5NF) if it is 4NF and its information content cannot be reconstructed from several tables containing fewer attributes.
טבלה מנורמלת ברמה החמישית אם ורק אם היא מנורמלת ברמה הרביעית ותוכנה לא יכול להיות מושג מכמה טבלאות המכילות מספר נמוך של מאפיינים.
במילים אחרות: טבלה מנורמלת ברמה החמישית אם אין מידע הקשור ישירות לטבלה אשר יכול להיות מושג באמצעות יותר משאילתת איחוד (Join) אחת הקשורה לטבלת רבים-לרבים. חוק הנרמול החמישי מבטיח כי בהם מידע הקשור ישירות לטבלה מסוימת לא יהיה משוחזר "בחלקים" מטבלאות שונות.
Classes (ClassID, ClassName,TeacherID)
Professions (ProfessionID, ProfessionName,ClassID)
בדוגמה הבאה, כדי לראות באילו מקצועות מלמד המורה, נצטרך לעשות שתי שאילתות איחוד. זה, כמובן, מצב לא רצוי מבחינה לוגית ומבחינת ביצועים. כדי שטבלת Teachers תיהיה מנורמלת ברמה החמישית, נצטרך לתאר את המבנה כך:
Classes (ClassID, ClassName)
Professions (ProfessionID, ProfessionName)
ClassTeacher (ClassID, TeacherID)
ProfessionTeacher (ProfessionID, TeacherID)
במצב הזה כדי לדעת מידע הקשור ישירות לטבלת Teachers כמו למשל מקצועות הלימוד נצטרך לעבור דרך טבלת הרבים-לרבים ProfessionTeacher ולא דרך טבלה אחרת שלא קשורה לנושא שאילתת האיחוד.
הערה: במקרים רבים מדיפים מתכנני בסיס הנתונים שהטבלה תישאר מנורמלת ברמה הרביעית בלבד ולא ברמה החמישית. למעשה, חוק הנרמול החמישי הוא תיאורטי בעיקר.
תגובות בפייסבוק