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

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

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

במאמר זה

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

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

תמונה שמתארת שלוש טבלאות בגליונות נתונים

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

לראש הדף

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

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

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

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

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

  • עוזר לתמוך ולהבטיח את הדיוק והתקינות של המידע שלך.

  • מתאים את צרכי עיבוד הנתונים והדיווח שלך.

לראש הדף

תהליך העיצוב

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

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

    פעולה זו עוזרת להכין אותך לשלבים הנותרים.

  • חיפוש וארגון של המידע הנדרש     

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

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

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

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

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

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

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

  • הגדרת קשרי הגומלין בין הטבלאות    

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

  • מקד את העיצוב שלך    

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

  • החלת כללי הנורמלית    

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

לראש הדף

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

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

לראש הדף

חיפוש וארגון של המידע הנדרש

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

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

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

אדם המדמיין דוח של מלאי מוצרים

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

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

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

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

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

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

לראש הדף

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

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

פריטי מידע בכתב יד המקובצים לנושאים

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

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

תמונה שמציגה טבלה המכילה הן מוצרים והן ספקים

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

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

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

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

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

לראש הדף

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

כדי לקבוע את העמודות בטבלה, החלט איזה מידע עליך לעקוב אחר הנושא המוקלט בטבלה. לדוגמה, עבור הטבלה Customers, Name, Address, City-State-Zip, Send e-mail, Salutation and E-mail address מורכבים מרשימת פתיחה טובה של עמודות. כל רשומה בטבלה מכילה את אותה קבוצת עמודות, כך שתוכל לאחסן מידע על שם, כתובת, עיר-מדינה-Zip, שליחת דואר אלקטרוני, ברכה וכתובת דואר אלקטרוני עבור כל רשומה. לדוגמה, עמודת הכתובת מכילה כתובות של לקוחות. כל רשומה מכילה נתונים אודות לקוח אחד, ושדה הכתובת מכיל את הכתובת של לקוח זה.

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

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

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

  • אל תכלול נתונים מחושבים    

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

  • אחסון מידע בחלקים הלוגיים קטן ביותר שלו    

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

תמונה המראה פריטי מידע במהלך תהליך העיצוב

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

לראש הדף

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

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

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

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

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

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

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

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

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

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

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

תמונה המראה פריטי מידע במהלך תהליך העיצוב

לראש הדף

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

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

טופס ההזמנות

1. המידע בטופס זה מגיע מהטבלה Customers...

2. ... הטבלה Employees...

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

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

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

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

לראש הדף

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

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

התפיסה של יחיד לרבים

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

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

תמונה המראה פריטי מידע במהלך תהליך העיצוב

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

לראש הדף

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

שקול את קשר הגומלין בין הטבלה Products לטבלה Orders.

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

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

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

קשרי גומלין של רבים לרבים

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

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

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

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

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

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

תמונה המראה פריטי מידע במהלך תהליך העיצוב

לראש הדף

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

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

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

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

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

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

לראש הדף

מיקוד העיצוב

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

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

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

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

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

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

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

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

  • האם כל עמודה מכילה עובדה לגבי נושא הטבלה? אם עמודה אינה מכילה מידע אודות נושא הטבלה, היא שייכת לטבלה אחרת.

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

מיקוד הטבלה Products

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

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

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

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

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

  • מזהה מוצר

  • Name

  • מזהה מוצר1

  • שם1

  • מזהה מוצר2

  • שם2

  • מזהה מוצר3

  • שם3

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

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

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

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

לראש הדף

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

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

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

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

טופס רגיל ראשון

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

צורה רגילה שניה

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

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

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

  • שם המוצר

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

צורה רגילה שלישית

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

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

  • ProductID (מפתח ראשי)

  • Name

  • SRP (SRP)

  • Discount

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

לראש הדף

זקוק לעזרה נוספת?

מעוניין באפשרויות נוספות?

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

קהילות עוזרות לך לשאול שאלות ולהשיב עליהן, לתת משוב ולשמוע ממומחים בעלי ידע עשיר.

האם מידע זה היה שימושי?

עד כמה אתם מרוצים מאיכות השפה?
מה השפיע על החוויה שלך?
בלחיצה על 'שלח', אתה מאפשר למשוב שלך לשפר מוצרים ושירותים של Microsoft. מנהל ה-IT שלך יוכל לאסוף נתונים אלה. הצהרת הפרטיות.

תודה על המשוב!

×