הערה
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות להיכנס או לשנות מדריכי כתובות.
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות לשנות מדריכי כתובות.
מאמר זה מסביר את הטרמינולוגיה של נורמליזציה של מסד נתונים למתחילים. הבנה בסיסית של טרמינולוגיה זו מועילה כאשר דנים בעיצוב של מסד נתונים יחסי.
תיאור של נורמליזציה
נורמליזציה היא תהליך ארגון הנתונים במסד נתונים. הוא כולל יצירת טבלאות ויצירת קשרי גומלין בין טבלאות אלה בהתאם לכללים המיועדים הן להגן על הנתונים והן כדי להפוך את מסד הנתונים לגמיש יותר על-ידי ביטול יתירות ו תלות לא עקבית.
נתונים מיותרים מבזבזים שטח דיסק ויוצרים בעיות תחזוקה. אם יש לשנות נתונים שקיימים ביותר ממקום אחד, יש לשנות את הנתונים בדיוק באותו אופן בכל המיקומים. קל יותר ליישם שינוי כתובת לקוח אם נתונים אלה מאוחסנים רק בטבלה 'לקוחות' ולא בשום מקום אחר במסד הנתונים.
מהי "תלות לא עקבית"? על אף שהאפשרות אינטואיטיבית עבור המשתמש לחפש בטבלה 'לקוחות' את הכתובת של לקוח מסוים, ייתכן שלא יהיה הגיוני לחפש שם את שכר העובדים ששולחים את הלקוחות. שכרו של העובד קשור או תלוי בעובד ולכן יש להעבירו לטבלת העובדים. תלות לא עקבית יכולה להקשות על הגישה לנתונים מכיוון שהנתיב למציאת הנתונים עשוי להיות חסר או שבור.
ישנם כמה כללים לנורמליזציה של מסד הנתונים. כל כלל נקרא "טופס רגיל". אם הכלל הראשון נצפה, ייציין כי מסד הנתונים הוא "צורה רגילה ראשונה". אם שלושת הכללים הראשונים נצפו, מסד הנתונים נחשב ל"צורה רגילה שלישית". אף על פי שניתן להשתמש ברמות נרמול אחרות, צורה רגילה שלישית נחשבת לרמה הגבוהה ביותר הדרושה עבור רוב האפליקציות.
בדומה לכללים ומפרטים רשמיים רבים, תרחישים מהעולם האמיתי לא תמיד מאפשרים תאימות מושלמת. באופן כללי, נורמליזציה דורשת טבלאות נוספות וחלק מהלקוחות מוצאים את זה מסורבל. אם תחליט להפר את אחד משלושת הכללים הראשונים של נורמליזציה, ודא שהיישום שלך צופה בעיות שעלולות להתרחש, כגון נתונים מיותרים ותלות לא עקבית.
התיאורים הבאים כוללים דוגמאות.
צורה רגילה ראשונה
- הסר קבוצות חוזרות בטבלאות בודדות.
- צור טבלה נפרדת עבור כל קבוצה של נתונים קשורים.
- זהה כל קבוצה של נתונים קשורים באמצעות מפתח ראשי.
אל תשתמש בשדות מרובים בטבלה אחת כדי לאחסן נתונים דומים. לדוגמה, כדי לעקוב אחר פריט מלאי עשוי להגיע משני מקורות אפשריים, רשומת מלאי עשויה להכיל שדות עבור קוד ספק 1 וקוד ספק 2.
מה קורה בעת הוספת ספק שלישי? הוספת שדה אינה התשובה; היא דורשת שינויי תוכניות וטבלאות, והיא אינה מתאימה בצורה חלקה למספר דינאמי של ספקים. במקום זאת, מקם את כל פרטי הספקים בטבלה נפרדת בשם ספקים, ולאחר מכן קשר את המלאי לספקים עם מפתח מספר פריט, או ספקים למלאי עם מפתח קוד ספק.
הצורה הנורמלית השניה
- צור טבלאות נפרדות עבור ערכות ערכים החלות על רשומות מרובות.
- קשר טבלאות אלה עם מפתח זר.
רשומות אינן אמורות להיות תלויות במפתח ראשי אחר מלבד טבלה (מפתח מורכב, במידת הצורך). למשל, קחו בחשבון כתובת של לקוח במערכת הנהלת חשבונות. הכתובת נדרשת על-ידי הטבלה Customers, אך גם על-ידי הטבלאות הזמנות, משלוח, חשבוניות, חשבונות חייבים ואוספים. במקום לאחסן את כתובת הלקוח כערך נפרד בכל אחת מהטבלאות הללו, אחסן אותה במקום אחד, או בטבלת לקוחות או בטבלת כתובות נפרדת.
צורה נורמלית שלישית
- הסר שדות שאינם תלויים במפתח.
ערכים ברשומה שאינם חלק ממפתח הרשומה אינם שייכים לטבלה. באופן כללי, בכל פעם שהתוכן של קבוצת שדות עשוי לחול על יותר מרשומה בודדת בטבלה, שקול למקם את השדות הללו בטבלה נפרדת.
לדוגמה, בטבלת גיוס עובדים, ניתן לכלול את השם והכתובת של האוניברסיטה של המועמד. אבל אתה צריך רשימה מלאה של אוניברסיטאות עבור דיוור קבוצתי. אם מידע אוניברסיטאי מאוחסן בטבלת המועמדים, אין דרך לרשום אוניברסיטאות ללא מועמדים נוכחיים. צור טבלת אוניברסיטאות נפרדת וקשר אותה לטבלה 'מועמדים' עם מפתח קוד באוניברסיטה.
חריגה: צייתות לצורה הנורמלית השלישית, בעוד תיאורטית רצויה, אינה תמיד מעשית. אם יש לך טבלת לקוחות וברצונך לבטל את כל התלות האפשרית בין-שדות, עליך ליצור טבלאות נפרדות עבור ערים, מיקודים, נציגי מכירות, מחלקות לקוחות וכל גורם אחר שעלול להיות משוכפל במספר רשומות. בתיאוריה, כדאי לרדוף אחר נרמול. עם זאת, טבלאות קטנות רבות עלולות לפגוע בביצועים או לחרוג מיכולות קבצים פתוחים וזיכרון.
ייתכן שיהיה כדאי יותר ליישם צורה רגילה שלישית רק על נתונים המשתנים לעתים קרובות. אם נותרו כמה שדות תלויים, עצב את האפליקציה שלך כך שתדרוש מהמשתמש לאמת את כל השדות הקשורים כאשר כל אחד מהם משתנה.
צורות נורמליזציה אחרות
צורה רגילה רביעית, נקראת גם Boyce-Codd רגיל (BCNF), וצורה נורמלית חמישית קיימות, אך לעתים רחוקות נחשבים בעיצוב מעשי. התעלמות מכללים אלה עלולה לגרום לעיצוב מסד נתונים קטן מהמושלם, אך אינה אמורה להשפיע על הפונקציונליות.
מנרמל טבלה לדוגמה
שלבים אלה מדגימים את התהליך של נורמליזציה של טבלת סטודנטים לדוגמה.
טבלה לא מנורמלת:
Student# Advisor Adv-Room Class1 Class2 Class3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04 צורה רגילה ראשונה: אין קבוצות חוזרות
לטבלאות צריך להיות רק שני ממדים. מכיוון לסטודנט אחד יש מספר כיתות, כיתות אלו יופיעו בטבלה נפרדת. השדות Class1, Class2 ו- Class3 ברשומות לעיל הם אינדיקציות לבעיית עיצוב.
גליונות אלקטרוניים משתמשים לעתים קרובות בממד השלישי, אך טבלאות אינן אמורות להשתמש בהן. דרך נוספת להביט בבעיה זו היא קשר גומלין של אחד לרבים, אל תמקם את הצד אחד ואת הצד הרבים באותה טבלה. במקום זאת, צור טבלה אחרת בטופס הרגיל הראשון על-ידי ביטול הקבוצה החוזרת (Class#), כפי שמוצג בדוגמה הבאה:
Student# Advisor Adv-Room Class# 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 101-07 4123 Smith 216 143-01 4123 Smith 216 179-04 צורה רגילה שניה: הסר נתונים מיותרים
שים לב לערכים המכפלים של Class # עבור כל ערך של תלמיד בטבלה לעיל. Class# אינו תלוי באופן פונקציונלי ב- Student# (מפתח ראשי), ולכן קשר גומלין זה אינו בצורה רגילה שניה.
הטבלאות הבאות מדגימות צורה נורמלית שנייה:
סטודנטים:
Student# Advisor Adv-Room 1022 Jones 412 4123 Smith 216 רישום:
Student# Class# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 צורה רגילה שלישית: הסר נתונים שאינם תלויים במפתח
בדוגמה האחרונה, Adv-Room (מספר משרד היועץ) תלוי פונקציונלית בתכונת Advisor. הפתרון הוא להעביר את התכונה הזו מטבלת הסטודנטים לטבלת הפקולטה, כפי שמוצג להלן:
סטודנטים:
Student# Advisor 1022 Jones 4123 Smith סגל:
Name חדר מחלקה Jones 412 42 Smith 216 42