יסודות עיצוב מסדי נתונים

מסד נתונים שתוכנן כהלכה מספק לך גישה למידע עדכני ומדויק. מכיוון שעיצוב נכון חיוני להשגת המטרות שלך בעבודה עם מסד נתונים, השקעת הזמן הנדרש כדי ללמוד את העקרונות של עיצוב טוב היא הגיונית. בסופו של דבר, הרבה יותר סביר שתקבל מסד נתונים שעונה על הצרכים שלך ויכול להכיל בקלות שינויים.

מאמר זה מספק הנחיות לתכנון מסד נתונים של שולחן עבודה. תלמד כיצד להחליט איזה מידע דרוש לך, כיצד לחלק מידע זה לטבלאות ולעמודות המתאימות וכיצד טבלאות אלה קשורות זו לזו. עליך לקרוא מאמר זה לפני שתיצור את מסד הנתונים השולחני הראשון שלך.

במאמר זה

• כמה מונחי מסד נתונים שכדאי להכיר
• מהו עיצוב מסד נתונים טוב?
• תהליך העיצוב
• קביעת המטרה של מסד הנתונים שלך
• איתור וארגון המידע הנדרש
• חלוקת המידע לטבלאות
• הפיכת פריטי מידע לעמודות
• ציון מפתחות ראשיים
• יצירת קשרי גומלין בין טבלאות
• ליטוש העיצוב
• החלת כללי הנורמליזציה

כמה מונחי מסד נתונים שכדאי להכיר

Access מארגן את המידע שלך בטבלאות: רשימות של שורות ועמודות שמזכירות פנקס של רואה חשבון או גיליון אלקטרוני. במסד נתונים פשוט, ייתכן שתהיה לך טבלה אחת בלבד. עבור רוב מסדי הנתונים, תזדקק ליותר מאחד. לדוגמה, ייתכן שיש לך טבלה המאחסנת מידע אודות מוצרים, טבלה אחרת המאחסנת מידע אודות הזמנות וטבלה אחרת המאחסנת מידע אודות לקוחות.

כל שורה נקראת ביתר דיוק רשומה, וכל עמודה היא שדה. רשומה היא דרך משמעותית ועקבית לשלב מידע אודות פריט מסוים. שדה הוא פריט מידע יחיד - סוג פריט שמופיע בכל הרשומות. בטבלה Products, לדוגמה, כל שורה או רשומה מכילה מידע אודות מוצר אחד. כל עמודה או שדה מכילה סוג מסוים של מידע אודות מוצר זה, כגון שמו או מחירו.

לראש הדף

מהו עיצוב מסד נתונים טוב?

עקרונות מסוימים מנחים את תהליך עיצוב מסד הנתונים. העיקרון הראשון הוא שמידע כפול (הנקרא גם נתונים מיותרים) הוא רע, מכיוון שהוא מבזבז מקום ומגדיל את הסבירות לטעויות וחוסר עקביות. העיקרון השני הוא שנכונות ושלמות המידע חשובה. אם מסד הנתונים שלך מכיל מידע שגוי, כל הדוחות שימשכו מידע ממסד הנתונים יכילו גם הם מידע שגוי. כתוצאה מכך, כל החלטה שתקבל המבוססת על דוחות אלה תהיה מוטעית.

לכן, עיצוב טוב של מסד נתונים הוא:

• חלוקת המידע שלך לטבלאות מבוססות-נושא כדי לצמצם נתונים מיותרים.
• מספק ל- Access את המידע הדרוש לו כדי לצרף את המידע בטבלאות יחד לפי הצורך.
• עוזר לתמוך ולהבטיח את הדיוק והתקינות של המידע שלך.
• עונה על צרכי עיבוד הנתונים והדיווח שלך.

לראש הדף

תהליך העיצוב

תהליך העיצוב מורכב מהשלבים הבאים:

• קביעת המטרה של מסד הנתונים שלך
  פעולה זו תעזור לך להתכונן לשלבים הנותרים.
• חיפוש וארגון של המידע הנדרש
  אסוף את כל סוגי המידע שייתכן שתרצה לתעד במסד הנתונים, כגון שם מוצר ומספר הזמנה.
• חלוקת המידע לטבלאות
  חלק את פריטי המידע שלך לישויות או נושאים עיקריים, כגון מוצרים או הזמנות. לאחר מכן כל נושא הופך לטבלה.
• הפיכת פריטי מידע לעמודות
  החלט איזה מידע ברצונך לאחסן בכל טבלה. כל פריט הופך לשדה, ומוצג כעמודה בטבלה. לדוגמה, הטבלה Employees עשויה לכלול שדות כגון Last Name ו- Hire Date.
• ציין מפתחות ראשיים
  בחר את המפתח הראשי של כל טבלה. המפתח הראשי הוא עמודה המשמשת לזיהוי ייחודי של כל שורה. דוגמה יכולה להיות 'מזהה מוצר' או 'מזהה הזמנה'.
• הגדרת קשרי הגומלין בין טבלאות
  התבונן בכל טבלה והחלט כיצד הנתונים בטבלה אחת קשורים לנתונים בטבלאות אחרות. הוסף שדות לטבלאות או צור טבלאות חדשות כדי להבהיר את קשרי הגומלין, לפי הצורך.
• מיקוד העיצוב שלך
  נתח את העיצוב שלך לאיתור שגיאות. צור את הטבלאות והוסף כמה רשומות של נתונים לדוגמה. בדוק אם באפשרותך לקבל את התוצאות הרצויות מהטבלאות שלך. בצע התאמות בעיצוב, לפי הצורך.
• החלת כללי הנורמליזציה
  החל את כללי הנורמליזציה של הנתונים כדי לראות אם הטבלאות שלך בנויות כהלכה. בצע התאמות בטבלאות, לפי הצורך.

לראש הדף

קביעת המטרה של מסד הנתונים שלך

מומלץ לרשום את מטרת מסד הנתונים על נייר - מטרתו, האופן שבו אתה מצפה להשתמש בו ומי ישתמש בו. עבור מסד נתונים קטן של עסק ביתי, לדוגמה, תוכל לכתוב משהו פשוט כמו "מסד הנתונים של הלקוחות שומר רשימה של פרטי לקוחות לצורך הפקת דברי דואר ודוחות". אם מסד הנתונים מורכב יותר או נמצא בשימוש על-ידי אנשים רבים, כפי שקורה לעתים קרובות בסביבה ארגונית, המטרה יכולה בקלות להיות פיסקה או יותר והיא צריכה לכלול מתי וכיצד כל אדם ישתמש במסד הנתונים. הרעיון הוא שתהיה הצהרת כוונות מפותחת שניתן להתייחס אליה לאורך תהליך התכנון. הצהרה כזו עוזרת לך להתמקד במטרות שלך כשאתה מקבל החלטות.

לראש הדף

איתור וארגון המידע הנדרש

כדי לאתר ולארגן את המידע הנדרש, התחל עם המידע הקיים. לדוגמה, באפשרותך לתעד הזמנות רכש בספר חשבונות או לשמור פרטי לקוח על טפסי נייר בארון תיוקים. אסוף מסמכים אלה ורשום כל סוג מידע שמוצג (לדוגמה, כל תיבה שאתה ממלא בטופס). אם אין לך טפסים קיימים, דמיין במקום זאת שעליך לעצב טופס כדי לתעד את פרטי הלקוח. איזה מידע היית מוסיף לטופס? אילו תיבות מילוי היית יוצר? זהה כל אחד מהפריטים הללו ורשום אותם. לדוגמה, נניח שאתה שומר כעת את רשימת הלקוחות בכרטיסי אינדקס. בחינת כרטיסים אלה עשויה להראות כי כל כרטיס מכיל שם לקוח, כתובת, עיר, מדינה, מיקוד ומספר טלפון. כל אחד מפריטים אלה מייצג עמודה פוטנציאלית בטבלה.

בזמן שאתה מכין את הרשימה הזו, אל תדאג לקבל אותה מושלמת בהתחלה. במקום זאת, רשום כל פריט שעולה בראשך. אם מישהו אחר ישתמש במסד הנתונים, בקש גם את הרעיונות שלו. תוכל לכוונן את הרשימה מאוחר יותר.

כעת, שקול את סוגי הדוחות או דברי הדואר שייתכן שתרצה להפיק ממסד הנתונים. לדוגמה, ייתכן שתרצה שדוח מכירות של מוצרים יציג מכירות לפי אזור, או דוח סיכום מלאי שמציג רמות מלאי של מוצרים. ייתכן שתרצה גם ליצור מכתבים אחידים שיישלחו ללקוחות שמכריזים על אירוע מכירה או מציעים פרמיה. עצב את הדוח בראשך ודמיין כיצד הוא ייראה. איזה מידע היית ממקם בדוח? רשום כל פריט. עשה את אותו הדבר עבור המכתב האחיד ועבור כל דוח אחר שאתה צופה ליצור.

הקדשת מחשבה לדוחות ולדברי הדואר שייתכן שתרצה ליצור תעזור לך לזהות פריטים שתצטרך במסד הנתונים שלך. לדוגמה, נניח שאתה מעניק ללקוחות הזדמנות להצטרף (או לא להצטרף) לעדכוני דואר אלקטרוני תקופתיים, וברצונך להדפיס רשימה של המשתמשים שהסכימו להצטרף. כדי לתעד מידע זה, עליך להוסיף עמודת "שליחת דואר אלקטרוני" לטבלת הלקוחות. עבור כל לקוח, באפשרותך להגדיר את השדה ל'כן' או 'לא'.

הדרישה לשלוח הודעות דואר אלקטרוני ללקוחות מציעה פריט אחר לתיעוד. לאחר שנודע לך שלקוח מעוניין לקבל הודעות דואר אלקטרוני, תצטרך לדעת גם את כתובת הדואר האלקטרוני שאליה ברצונך לשלוח אותו. לכן, עליך לתעד כתובת דואר אלקטרוני עבור כל לקוח.

הגיוני לבנות אב טיפוס של כל דוח או רשימת פלט ולשקול אילו פריטים תצטרך כדי להפיק את הדוח. לדוגמה, כשאתה בוחן מכתב אחיד, כמה דברים עשויים לעלות בראשך. אם ברצונך לכלול ברכה הולמת - לדוגמה, המחרוזת "מר", "גברת" או "גברת" שמתחילה ברכה, יהיה עליך ליצור פריט ברכה. כמו כן, בדרך כלל אתה יכול להתחיל מכתב ב"מר סמית היקר", במקום "יקר. מר סילבסטר סמית'". פירוש הדבר הוא שבדרך כלל תרצה לאחסן את שם המשפחה בנפרד משם הפרטי.

נקודה חשובה שיש לזכור היא שעליך לחלק כל פיסת מידע לחלקים השימושיים הקטנים ביותר שלה. במקרה של שם, כדי להפוך את שם המשפחה לזמין, עליך לחלק את השם לשני חלקים – 'שם פרטי' ו'שם משפחה'. כדי למיין דוח לפי שם משפחה, לדוגמה, כדאי לאחסן את שם המשפחה של הלקוח בנפרד. באופן כללי, אם ברצונך למיין, לחפש, לחשב או לדווח בהתבסס על פריט מידע, עליך למקם פריט זה בשדה משלו.

חשוב על השאלות שייתכן שתרצה שמסד הנתונים יענה עליהן. למשל, כמה מכירות של המוצר המוצג שלך סגרת בחודש שעבר? היכן גרים הלקוחות הטובים ביותר שלך? מיהו הספק של המוצר הנמכר ביותר שלך? חיזוי שאלות אלה עוזר לך להתמקד בפריטים נוספים לתיעוד.

לאחר איסוף מידע זה, אתה מוכן לשלב הבא.

לראש הדף

חלוקת המידע לטבלאות

כדי לחלק את המידע לטבלאות, בחר את הישויות או הנושאים העיקריים. לדוגמה, לאחר איתור וארגון של מידע עבור מסד נתונים של מכירות מוצרים, הרשימה הראשונית עשויה להיראות כך:

הישויות העיקריות המוצגות כאן הן המוצרים, הספקים, הלקוחות וההזמנות. לכן, הגיוני להתחיל עם ארבע טבלאות אלה: אחת לעובדות על מוצרים, אחת לעובדות על ספקים, אחת לעובדות על לקוחות ואחת לעובדות על הזמנות. למרות שזה לא משלים את הרשימה, זו נקודת התחלה טובה. באפשרותך להמשיך ולמקד רשימה זו עד שתשיג עיצוב שמתאים לך.

כאשר תעיין לראשונה ברשימת הפריטים הראשונית, ייתכן שתתפתה להציב את כולם בטבלה אחת, במקום את הארבעה המוצגים באיור הקודם. כאן תלמדו מדוע זה רעיון גרוע. חשבו לרגע על הטבלה המוצגת כאן:

במקרה זה, כל שורה מכילה מידע הן על המוצר והן על הספק שלו. מאחר שניתן לקבל מוצרים רבים מאותו ספק, יש לחזור על פרטי שם הספק וכתובתו פעמים רבות. זה מבזבז שטח דיסק. רישום פרטי הספק פעם אחת בלבד בטבלת ספקים נפרדת, ולאחר מכן קישור טבלה זו לטבלת המוצרים, הוא פתרון טוב בהרבה.

בעיה שנייה בעיצוב זה מתעוררת כאשר אתה צריך לשנות מידע על הספק. לדוגמה, נניח שעליך לשנות כתובת של ספק. מאחר שהיא מופיעה במקומות רבים, אתה עלול לשנות בטעות את הכתובת במקום אחד אך לשכוח לשנות אותה במקום אחר. רישום כתובת הספק במקום אחד בלבד פותר את הבעיה.

בעת עיצוב מסד הנתונים, נסה תמיד לתעד כל עובדה פעם אחת בלבד. אם אתה מוצא את עצמך חוזר על אותו מידע ביותר ממקום אחד, כגון הכתובת של ספק מסוים, מקם מידע זה בטבלה נפרדת.

לבסוף, נניח שיש רק מוצר אחד שסופק על-ידי יקב Coho, וברצונך למחוק את המוצר, אך לשמור את פרטי השם והכתובת של הספק. כיצד ניתן למחוק את רשומת המוצר מבלי לאבד גם את פרטי הספק? אתה לא יכול. מאחר שכל רשומה מכילה עובדות אודות מוצר וכן עובדות אודות ספק, לא ניתן למחוק רשומה אחת מבלי למחוק את האחרת. כדי להפריד בין עובדות אלה, עליך לפצל טבלה אחת לשתיים: טבלה אחת עבור פרטי מוצרים, וטבלה אחרת עבור פרטי ספקים. מחיקת רשומה של מוצר אמורה למחוק רק את העובדות אודות המוצר, ולא את העובדות אודות הספק.

לאחר שבחרת את הנושא המיוצג על-ידי טבלה, העמודות בטבלה אמורות לאחסן עובדות רק אודות הנושא. לדוגמה, טבלת המוצר צריכה לאחסן עובדות רק לגבי מוצרים. מכיוון שכתובת הספק היא עובדה לגבי הספק, ולא עובדה לגבי המוצר, היא שייכת לטבלת הספקים.

לראש הדף

הפיכת פריטי מידע לעמודות

כדי לקבוע את העמודות בטבלה, החלט אחר איזה מידע עליך לעקוב לגבי הנושא הרשום בטבלה. לדוגמה, עבור הטבלה 'לקוחות', 'שם', 'כתובת', 'עיר-מדינה-מיקוד', 'שלח דואר אלקטרוני', 'ברכה' ו'כתובת דואר אלקטרוני' מהווים רשימת התחלה טובה של עמודות. כל רשומה בטבלה מכילה את אותה קבוצת עמודות, כך שבאפשרותך לאחסן מידע אודות שם, כתובת, עיר-מדינה-מיקוד, שליחת דואר אלקטרוני, ברכה וכתובת דואר אלקטרוני עבור כל רשומה. לדוגמה, עמודת הכתובת מכילה את כתובות הלקוחות. כל אחת מהרשומות מכילה נתונים אודות לקוח אחד, ושדה הכתובת מכיל את הכתובת של לקוח זה.

לאחר קביעת קבוצת העמודות הראשונית עבור כל טבלה, תוכל למקד את העמודות אף יותר. לדוגמה, הגיוני לאחסן את שם הלקוח בשתי עמודות נפרדות: 'שם פרטי' ו'שם משפחה', כך שתוכל למיין, לחפש וליצור אינדקס בעמודות אלה בלבד. באופן דומה, הכתובת מורכבת למעשה מחמישה רכיבים נפרדים, כתובת, עיר, מדינה, מיקוד ומדינה/אזור, והגיוני גם לאחסן אותם בעמודות נפרדות. אם ברצונך לבצע פעולת חיפוש, סינון או מיון לפי מדינה, לדוגמה, עליך לאחסן את פרטי המצב בעמודה נפרדת.

כמו כן, עליך לשקול אם מסד הנתונים יכיל מידע שמקורו מקומי בלבד, או גם בינלאומי. לדוגמה, אם בכוונתך לאחסן כתובות בינלאומיות, עדיף שתהיה עמודת 'אזור' במקום 'מדינה', מכיוון שעמודה כזו יכולה להכיל הן מדינות מקומיות והן אזורים של מדינות/אזורים אחרים. באופן דומה, מיקוד הגיוני יותר ממיקוד אם אתה מתכוון לאחסן כתובות בינלאומיות.

הרשימה הבאה מציגה כמה עצות לקביעת העמודות שלך.

• אל תכלול נתונים מחושבים
  ברוב המקרים, אין לאחסן את תוצאת החישובים בטבלאות. במקום זאת, תוכל לקבוע ש- Access יבצע את החישובים כאשר ברצונך לראות את התוצאה. לדוגמה, נניח שקיים דוח 'מוצרים בהזמנה' המציג את סכום הביניים של יחידות בהזמנה עבור כל קטגוריית מוצר במסד הנתונים. עם זאת, אין עמודת סכום ביניים של 'יחידות לפי הזמנה' באף טבלה. במקום זאת, הטבלה Products כוללת עמודת יחידות בהזמנה המאחסנת את היחידות בהזמנה עבור כל מוצר. באמצעות נתונים אלה, Access מחשב את סכום הביניים בכל פעם שאתה מדפיס את הדוח. אין לאחסן את סכום הביניים עצמו בטבלה.
• אחסון מידע בחלקים הלוגיים הקטנים ביותר שלו
  ייתכן שתתפתה להשתמש בשדה יחיד עבור שמות מלאים או עבור שמות מוצרים לצד תיאורי מוצרים. אם תשלב יותר מסוג אחד של מידע בשדה, יהיה קשה לאחזר עובדות פרטניות מאוחר יותר. נסה לפרק מידע לחלקים לוגיים; לדוגמה, צור שדות נפרדים עבור שם פרטי ושם משפחה, או עבור שם מוצר, קטגוריה ותיאור.

לאחר שמיקדת את עמודות הנתונים בכל טבלה, אתה מוכן לבחור את המפתח הראשי של כל טבלה.

לראש הדף

ציון מפתחות ראשיים

כל טבלה צריכה לכלול עמודה או קבוצת עמודות שמזהות באופן ייחודי כל שורה המאוחסנת בטבלה. לרוב זהו מספר זיהוי ייחודי, כגון מספר מזהה עובד או מספר סידורי. במינוח של מסדי נתונים, מידע זה נקרא המפתח הראשי של הטבלה. Access משתמש בשדות של מפתחות ראשיים כדי לשייך במהירות נתונים מטבלאות מרובות ולאחד את הנתונים עבורך.

אם כבר יש לך מזהה ייחודי עבור טבלה, כגון מספר מוצר המזהה באופן ייחודי כל מוצר בקטלוג, באפשרותך להשתמש במזהה זה כמפתח הראשי של הטבלה – אך רק אם הערכים בעמודה זו יהיו תמיד שונים עבור כל רשומה. לא ניתן לכלול ערכים כפולים במפתח ראשי. לדוגמה, אל תשתמש בשמות אנשים כמפתח ראשי, מכיוון ששמות אינם ייחודיים. תוכל בקלות לכלול שני אנשים בעלי שם זהה באותה טבלה.

מפתח ראשי חייב תמיד לכלול ערך. אם ערך של עמודה יכול להפוך ללא מוקצה או לא ידוע (ערך חסר) בשלב מסוים, לא ניתן להשתמש בו כרכיב במפתח ראשי.

תמיד כדאי לבחור מפתח ראשי שערכו לא ישתנה. במסד נתונים שמשתמש ביותר מטבלה אחת, המפתח הראשי של טבלה יכול לשמש כהפניה בטבלאות אחרות. אם המפתח הראשי משתנה, יש להחיל את השינוי גם בכל מקום שבו יש הפניה למפתח. שימוש במפתח ראשי שאינו משתנה מפחית את הסיכוי שהמפתח הראשי לא יהיה מסונכרן עם טבלאות אחרות המפנות אליו.

לעתים קרובות, מספר ייחודי שרירותי משמש כמפתח הראשי. לדוגמה, באפשרותך להקצות לכל הזמנה מספר הזמנה ייחודי. המטרה היחידה של מספר ההזמנה היא לזהות הזמנה. לאחר ההקצאה, הוא לעולם לא משתנה.

אם אינך חושב על עמודה או קבוצת עמודות שעשויות להוות מפתח ראשי טוב, שקול להשתמש בעמודה בעלת סוג הנתונים 'מספור אוטומטי'. בעת שימוש בסוג הנתונים 'מספור אוטומטי', Access מקצה עבורך ערך באופן אוטומטי. מזהה כזה הוא חסר עובדות; הוא אינו מכיל מידע עובדתי המתאר את השורה שהוא מייצג. מזהים ללא עובדות הם אידיאליים לשימוש כמפתח ראשי מכיוון שהם אינם משתנים. מפתח ראשי המכיל עובדות לגבי שורה - מספר טלפון או שם לקוח, לדוגמה - עשוי להשתנות מאחר שהמידע העובדתי עצמו עשוי להשתנות.

1. עמודה המוגדרת לסוג הנתונים 'מספור אוטומטי' יכולה לעתים קרובות להיות מפתח ראשי טוב. אין שני מזהי מוצרים זהים.

במקרים מסוימים, ייתכן שתרצה להשתמש בשני שדות או יותר, המספקים - ביחד - את המפתח הראשי של טבלה. לדוגמה, טבלה בשם 'פרטי הזמנה', המאחסנת פריטי שורה עבור הזמנות, תשתמש בשתי עמודות מפתח ראשי: 'מזהה הזמנה' ו'מזהה מוצר'. במקרים שבהם המפתח הראשי משתמש ביותר מעמודה אחת, הוא קרוי גם מפתח מורכב.

עבור מסד הנתונים של מכירות המוצרים, באפשרותך ליצור עמודת מספור אוטומטי עבור כל אחת מהטבלאות שתשמש כמפתח ראשי: ProductID עבור הטבלה Products, OrderID עבור הטבלה Orders, CustomerID עבור הטבלה Customers ו- SupplierID עבור הטבלה Suppliers.

לראש הדף

יצירת קשרי גומלין בין טבלאות

כעת, לאחר שחילקת את המידע שלך לטבלאות, אתה זקוק לדרך לאיחוד המידע מחדש בדרכים בעלות משמעות. לדוגמה, הטופס הבא כולל מידע ממספר טבלאות.

1. המידע בטופס זה מגיע מהטבלה 'לקוחות'...

2. ... טבלת העובדים...

3. ... הטבלה Orders...

4. ... הטבלה Products...

5. ... והטבלה Order Details.

Access הוא מערכת ניהול קשרי מסדי נתונים. במסד נתונים יחסי, עליך לחלק את המידע שלך לטבלאות נפרדות המבוססות על נושאים. לאחר מכן, תשתמש בקשרי גומלין בין טבלאות כדי לרכז את המידע יחד לפי הצורך.

לראש הדף

יצירת קשר גומלין של יחיד-לרבים

התבונן בדוגמה הבאה: הטבלאות 'ספקים' ו'מוצרים' במסד הנתונים 'הזמנות מוצרים'. ספק יכול לספק כל מספר של מוצרים. מכאן שעבור כל ספק המיוצג בטבלה Suppliers, יכולים להיות מוצרים רבים המיוצגים בטבלה Products. לכן, קשר הגומלין שבין הטבלה 'ספקים' לבין הטבלה 'מוצרים' הוא קשר גומלין של יחיד-לרבים.

כדי לייצג קשר גומלין של יחיד-לרבים בעיצוב מסד הנתונים שלך, קח את המפתח הראשי בצד "יחיד" של קשר הגומלין והוסף אותו כעמודה נוספת או כעמודות נוספות לטבלה בצד "רבים" של קשר הגומלין. במקרה זה, לדוגמה, הוסף את העמודה 'מזהה ספק' מהטבלה 'ספקים' לטבלה 'מוצרים'. לאחר מכן, Access יוכל להשתמש במספר מזהה הספק שבטבלה Products כדי לאתר את הספק המתאים עבור כל מוצר.

העמודה 'מזהה ספק' בטבלה Products נקראת מפתח זר. מפתח זר הוא המפתח הראשי של טבלה אחרת. עמודת מזהה הספק בטבלה Products היא מפתח זר מכיוון שהיא גם המפתח הראשי בטבלת הספקים.

אתה מספק את הבסיס לצירוף טבלאות קשורות על-ידי יצירת זיווגים של מפתחות ראשיים ומפתחות זרים. אם אינך בטוח אילו טבלאות צריכות לחלוק עמודה משותפת, זיהוי קשר גומלין של יחיד לרבים מבטיח ששתי הטבלאות המעורבות אכן ידרשו עמודה משותפת.

לראש הדף

יצירת קשר גומלין של רבים-לרבים

חשוב על קשר הגומלין שבין הטבלה Products והטבלה Orders.

הזמנה אחת יכולה לכלול יותר ממוצר אחד. מצד שני, מוצר אחד יכול להופיע בהזמנות רבות. לפיכך, עבור כל רשומה בטבלה Orders, יכולות להיות רשומות רבות בטבלה Products. ועבור כל רשומה בטבלה Products, יכולות להיות רשומות רבות בטבלה Orders. סוג זה של קשר גומלין נקרא קשר גומלין של רבים-לרבים מכיוון שעבור כל מוצר, יכולים להיות הזמנות רבות; ולכל הזמנה, יכולים להיות מוצרים רבים. שים לב שכדי לזהות קשרי גומלין של רבים לרבים בין הטבלאות שלך, חשוב לקחת בחשבון את שני הצדדים של קשר הגומלין.

הנושאים של שתי הטבלאות - הזמנות ומוצרים - הם בעלי קשר גומלין של רבים לרבים. זה יוצר בעיה. כדי להבין את הבעיה, חשוב מה היה קורה אילו היית מנסה ליצור את קשר הגומלין בין שתי הטבלאות על-ידי הוספת השדה Product ID לטבלה Orders. כדי שיהיה לך יותר ממוצר אחד בכל הזמנה, דרושה לך יותר מרשומה אחת בטבלה 'הזמנות' לכל הזמנה. היית חוזר על פרטי ההזמנה עבור כל שורה שמתייחסת לסדר יחיד - והתוצאה היא עיצוב לא יעיל שעלול להוביל לנתונים לא מדויקים. אתה נתקל באותה בעיה אם תמקם את השדה 'מזהה הזמנה' בטבלה Products — תהיה לך יותר מרשומה אחת בטבלה Products עבור כל מוצר. כיצד ניתן לפתור בעיה זו?

התשובה היא ליצור טבלה שלישית, הנקראת לעתים קרובות טבלת הסתעפויות, המפרקת את קשרי הגומלין של רבים לרבים לשני קשרי גומלין של יחיד לרבים. עליך להכניס את המפתח הראשי מכל אחת משתי הטבלאות לטבלה השלישית. כתוצאה מכך, הטבלה השלישית תתעד כל התרחשות או מופע של קשר הגומלין.

כל רשומה בטבלה Order Details מייצגת פריט שורה אחד בהזמנה. המפתח הראשי של הטבלה Order Details מורכב משני שדות – המפתחות הזרים מהטבלאות Orders ו- Products. השימוש בשדה 'מזהה הזמנה' בלבד אינו פועל כמפתח הראשי עבור טבלה זו, מאחר שהזמנה אחת יכולה להכיל פריטי שורה רבים. מזהה ההזמנה חוזר על עצמו עבור כל פריט שורה בהזמנה, כך שהשדה אינו מכיל ערכים ייחודיים. גם השימוש בשדה 'מזהה מוצר' לבדו אינו פועל, מאחר שמוצר אחד יכול להופיע בהזמנות שונות רבות. אך ביחד, שני השדות תמיד מייצרים ערך ייחודי עבור כל רשומה.

במסד הנתונים של מכירות מוצרים, הטבלה Orders והטבלה Products אינן קשורות זו לזו ישירות. במקום זאת, הן קשורות באופן עקיף באמצעות הטבלה Order Details. קשר הגומלין של רבים לרבים בין הזמנות ומוצרים מיוצג במסד הנתונים באמצעות שני קשרי גומלין של יחיד לרבים:

• הטבלה Orders והטבלה Order Details הן בעלות קשר גומלין של יחיד-לרבים. כל הזמנה יכולה לכלול יותר מפריט שורה אחד, אך כל פריט שורה מחובר להזמנה אחת בלבד.
• לטבלה Products ולטבלה Order Details יש קשר גומלין של יחיד לרבים. לכל מוצר יכולים להיות פריטי שורה רבים המשויכים אליו, אך כל פריט קו מתייחס למוצר אחד בלבד.

מהטבלה Order Details, באפשרותך לקבוע את כל המוצרים בהזמנה מסוימת. ניתן גם לקבוע את כל ההזמנות עבור מוצר מסוים.

לאחר שילוב הטבלה Order Details, רשימת הטבלאות והשדות עשויה להיראות בערך כך:

לראש הדף

יצירת קשר גומלין של יחיד ליחיד

סוג אחר של קשר גומלין הוא קשר גומלין של יחיד ליחיד. לדוגמה, נניח שעליך לתעד מידע משלים מיוחד על מוצר שתזדקק לו לעתים רחוקות או שהוא חל רק על מוצרים מעטים. מאחר שאינך זקוק למידע לעתים קרובות, ומאחר שאחסון המידע בטבלה Products יגרום לשטח ריק עבור כל מוצר שעליו הוא אינו חל, עליך למקם אותו בטבלה נפרדת. בדומה לטבלה Products, עליך להשתמש ב- ProductID כמפתח הראשי. קשר הגומלין בין טבלה משלימה זו לטבלת המוצר הוא קשר גומלין של יחיד ליחיד. עבור כל רשומה בטבלה Product, קיימת רשומה תואמת אחת בטבלה המשלימה. לאחר שתזהה קשר גומלין מסוג זה, לשתי הטבלאות חייב להיות שדה משותף.

כאשר אתה מזהה את הצורך בקשר גומלין של יחיד ליחיד במסד הנתונים שלך, שקול אם באפשרותך לרכז את המידע משתי הטבלאות בטבלה אחת. אם אינך מעוניין לעשות זאת מסיבה כלשהי, אולי משום שהדבר יגרום לשטח ריק רב, הרשימה הבאה מראה כיצד היית מייצג את קשרי הגומלין בעיצוב שלך:

• אם לשתי הטבלאות יש אותו נושא, סביר להניח שבאפשרותך להגדיר את קשר הגומלין באמצעות אותו מפתח ראשי בשתי הטבלאות.
• אם לשתי הטבלאות יש נושאים שונים עם מפתחות ראשיים שונים, בחר באחת מהטבלאות (כל אחת מהן) והוסף את המפתח הראשי שלה לטבלה השניה כמפתח זר.

קביעת קשרי הגומלין בין הטבלאות עוזרת לך להבטיח שיש לך את הטבלאות והעמודות הנכונות. כאשר קיים קשר גומלין של יחיד ליחיד או יחיד לרבים, הטבלאות המעורבות צריכות לחלוק עמודה או עמודות משותפות. כאשר קיים קשר גומלין של רבים-לרבים, יש צורך בטבלה שלישית כדי לייצג את קשר הגומלין.

לראש הדף

ליטוש העיצוב

לאחר שהטבלאות, השדות וקשרי הגומלין הדרושים לך, עליך ליצור ולאכלס את הטבלאות בנתונים לדוגמה ולנסות לעבוד עם המידע: יצירת שאילתות, הוספת רשומות חדשות וכן הלאה. פעולה זו מסייעת להדגיש בעיות אפשריות — לדוגמה, ייתכן שיהיה עליך להוסיף עמודה ששכחת להוסיף במהלך שלב העיצוב, או שיש לך טבלה שיש לפצל לשתי טבלאות כדי להסיר כפילויות.

בדוק אם באפשרותך להשתמש במסד הנתונים כדי לקבל את התשובות הרצויות. צור טיוטות ראשוניות של הטפסים והדוחות שלך ובדוק אם הם מציגים את הנתונים הצפויים. חפש כפילויות מיותרות של נתונים, וכאשר אתה מוצא כפילויות מיותרות, שנה את העיצוב שלך כדי לבטל אותן.

כשתנסה את מסד הנתונים הראשוני שלך, סביר להניח שתגלה מקום לשיפור. הנה כמה דברים שתוכל לבדוק:

• האם שכחת עמודות? אם כן, האם המידע שייך לטבלאות הקיימות? אם מדובר במידע אודות משהו אחר, ייתכן שיהיה עליך ליצור טבלה אחרת. צור עמודה עבור כל פריט מידע שעליך לעקוב אחריו. אם לא ניתן לחשב את המידע מעמודות אחרות, סביר להניח שתצטרך עמודה חדשה עבורו.
• האם עמודות כלשהן מיותרות מכיוון שניתן לחשב אותן משדות קיימים? אם ניתן לחשב פריט מידע מעמודות קיימות אחרות - מחיר מוזל המחושב מהמחיר הקמעונאי, לדוגמה - בדרך כלל עדיף לעשות בדיוק את זה, ולהימנע מיצירת עמודה חדשה.
• האם אתה מזין שוב ושוב מידע כפול באחת הטבלאות שלך? אם כן, סביר להניח שעליך לחלק את הטבלה לשתי טבלאות בעלות קשרי גומלין של יחיד לרבים.
• האם יש לך טבלאות עם שדות רבים, מספר מוגבל של רשומות ושדות ריקים רבים ברשומות בודדות? אם כן, שקול לעצב מחדש את הטבלה כך שהיא תכיל פחות שדות ויותר רשומות.
• האם כל פריט מידע חולק לחלקים השימושיים הקטנים ביותר שלו? אם עליך למיין, לחפש, לחשב פריט מידע או לדווח עליו, מקם פריט זה בעמודה משלו.
• האם כל עמודה מכילה עובדה לגבי נושא הטבלה? אם עמודה אינה מכילה מידע אודות נושא הטבלה, היא שייכת לטבלה אחרת.
• האם כל קשרי הגומלין בין הטבלאות מיוצגים על-ידי שדות משותפים או על-ידי טבלה שלישית? קשרי גומלין של יחיד ליחיד ויחיד לרבים דורשים עמודות משותפות. קשרי גומלין מסוג רבים לרבים מחייבים טבלה שלישית.

מיקוד הטבלה Products

נניח שכל מוצר במסד הנתונים של מכירות המוצרים שייך לקטגוריה כללית, כגון משקאות, תבלינים או מאכלי ים. הטבלה Products יכולה לכלול שדה המציג את הקטגוריה של כל מוצר.

נניח שלאחר בחינה ומיקוד של עיצוב מסד הנתונים, תחליט לאחסן תיאור של הקטגוריה יחד עם שמה. אם אתה מוסיף שדה תיאור קטגוריה לטבלה Products, עליך לחזור על כל תיאור קטגוריה עבור כל מוצר השייך לקטגוריה - זה אינו פתרון טוב.

פתרון טוב יותר הוא להפוך את הקטגוריות לנושא חדש שמסד הנתונים יעקוב אחריו, עם טבלה משלו ומפתח ראשי משלו. לאחר מכן תוכל להוסיף את המפתח הראשי מהטבלה Categories לטבלה Products כמפתח זר.

לטבלאות 'קטגוריות' ו'מוצרים' יש קשר גומלין של יחיד לרבים: קטגוריה יכולה לכלול יותר ממוצר אחד, אך מוצר יכול להשתייך לקטגוריה אחת בלבד.

בעת סקירת מבני הטבלה שלך, שים לב לקבוצות שחוזרות על עצמן. לדוגמה, חשוב על טבלה המכילה את העמודות הבאות:

• מזהה מוצר
• Name
• מזהה מוצר1
• שם1
• מזהה מוצר2
• שם2
• מזהה מוצר3
• שם3

כאן, כל מוצר הוא קבוצה חוזרת של עמודות ששונה מהאחרות רק על-ידי הוספת מספר לסוף שם העמודה. כאשר תראה עמודות ממוספרות באופן זה, עליך לבחון מחדש את העיצוב.

לעיצוב כזה יש כמה פגמים. בתור התחלה, זה מאלץ אותך להציב גבול עליון למספר המוצרים. ברגע שאתה חורג ממגבלה זו, עליך להוסיף קבוצה חדשה של עמודות למבנה הטבלה, המהווה משימה ניהולית חשובה.

בעיה נוספת היא שאותם ספקים שיש להם פחות ממספר המוצרים המרבי יבזבזו מקום מסוים, מכיוון שהעמודות הנוספות יהיו ריקות. הפגם החמור ביותר בעיצוב כזה הוא שהוא מקשה על ביצוע משימות רבות, כגון מיון או אינדקס של הטבלה לפי מזהה מוצר או שם.

בכל פעם שאתה רואה קבוצות חוזרות, סקור את העיצוב מקרוב תוך מחשבה על פיצול הטבלה לשניים. בדוגמה לעיל עדיף להשתמש בשתי טבלאות, אחת עבור ספקים ואחת עבור מוצרים, המקושרות באמצעות מזהה ספק.

לראש הדף

החלת כללי הנורמליזציה

באפשרותך להחיל את כללי הנורמליזציה של הנתונים (הנקראים לעתים פשוט כללי נרמול) כשלב הבא בעיצוב. השתמש בכללים אלה כדי לראות אם הטבלאות שלך בנויות כהלכה. תהליך החלת הכללים על עיצוב מסד הנתונים נקרא נרמול של מסד הנתונים, או פשוט נרמול.

נורמליזציה שימושית ביותר לאחר שייצגת את כל פריטי המידע והגעת לעיצוב ראשוני. הרעיון הוא לעזור לך לוודא שחילקת את פריטי המידע שלך לטבלאות המתאימות. מה שנורמליזציה לא יכולה לעשות הוא להבטיח שיש לך את כל פריטי הנתונים הנכונים מלכתחילה.

אתה מיישם את הכללים ברצף, בכל שלב מוודא שהעיצוב שלך יגיע לאחת ממה שמכונה "הצורות הנורמליות". חמש צורות נורמליות מקובלות - הצורה הנורמלית הראשונה עד הצורה הנורמלית החמישית. מאמר זה מרחיב את שלושת הראשונים, מכיוון שהם כל מה שנדרש עבור רוב עיצובי מסדי הנתונים.

הצורה הנורמלית הראשונה

הצורה הנורמלית הראשונה מציינת שבכל הצטלבות של שורה ועמודה בטבלה שם, קיים ערך יחיד, ולעולם לא רשימה של ערכים. לדוגמה, לא יכול להיות שדה בשם Price שבו אתה מציב יותר ממחיר אחד. אם אתה מחשיב כל הצטלבות של שורות ועמודות כתא, כל תא יכול להכיל ערך אחד בלבד.

צורה נורמלית שנייה

הצורה הרגילה השנייה דורשת שכל עמודה שאינה מפתח תהיה תלויה לחלוטין במפתח הראשי כולו, ולא רק בחלק מהמפתח. כלל זה חל כאשר יש לך מפתח ראשי המורכב מיותר מעמודה אחת. לדוגמה, נניח שיש לך טבלה המכילה את העמודות הבאות, שבה המפתח הראשי הוא 'מזהה הזמנה' ו'מזהה מוצר':

• מזהה הזמנה (מפתח ראשי)
• מזהה מוצר (מפתח ראשי)
• שם המוצר

עיצוב זה מפר את הצורה הנורמלית השנייה, מכיוון ששם המוצר תלוי במזהה מוצר, אך לא במזהה הזמנה, ולכן הוא אינו תלוי במפתח הראשי כולו. עליך להסיר את שם המוצר מהטבלה. הוא שייך לטבלה אחרת (Products).

הצורה הנורמלית השלישית

הצורה הנורמלית השלישית דורשת שלא רק שכל עמודה שאינה מפתח תהיה תלויה במפתח הראשי כולו, אלא שעמודות שאינן מפתחות יהיו בלתי תלויות זו בזו.

דרך אחרת לומר זאת היא שכל עמודה שאינה מפתח חייבת להיות תלויה במפתח הראשי ולא במפתח הראשי. לדוגמה, נניח שיש לך טבלה המכילה את העמודות הבאות:

• ProductID (מפתח ראשי)
• Name
• שלט שירות
• Discount

נניח שההנחה תלויה במחיר הקמעונאי המוצע (SRP). טבלה זו מפרה את הצורה הנורמלית השלישית מכיוון שעמודה שאינה מפתח, הנחה, תלויה בעמודה אחרת שאינה מפתח, SRP. אי-תלות בעמודה פירושה שתוכל לשנות כל עמודה שאינה עמודה מרכזית מבלי להשפיע על כל עמודה אחרת. אם תשנה ערך בשדה SRP, ההנחה תשתנה בהתאם, ותפר כלל זה. במקרה זה יש להעביר את ההנחה לטבלה אחרת שמקודדת ב- SRP.

לראש הדף