‫בסיס נתונים‬

‫מודל ‪DSD‬‬
 ‫תרשים מבנה נתונים‬
‫נכיר תרשים הנקרא תרשים מבנה נתונים (‪ ,)Data Structure Diagram – DSD‬שהוא תרשים לוגי‪ ,‬המציג את‬
‫הטבלאות כפי שיופיעו במסד הנתונים‪ .‬בתרשים יופיעו הטבלאות‪ ,‬השדות‪ ,‬המפתחות והקשרים‪ .‬הוא מכונה גם לעיתים‬
‫"תרשים קשרי גומלין"‪.‬‬
‫•טבלה מסומנת בתרשים ‪ DSD‬בתור מלבן‪.‬‬
‫•השדות של הטבלה כתובים בתוך המלבן‪ ,‬אחת מתחת לשנייה‪.‬‬
‫•המפתח של המחלקה מסומן גם כן בתוך המלבן‪ ,‬אבל בחלקו העליון‪ ,‬מעל לקו מפריד או סימון מילולי‪.‬‬
‫•לדוגמא‪:‬‬
 ‫קשר‬
‫קשר בין טבלאות מיוצג על ידי קו המחבר את הטבלאות‪ ,‬הנוגע בשני הצדדים בשדות היוצרים את הקשר‪ .‬לדוגמא‪:‬‬
 ‫יחיד לרבים‬
‫•קו שנכנס לתוך טבלה ומתפצל ל‪ 3-‬חלקים מציין "רבים"‪ ,‬בעוד שקו רגיל שנכנס לתוך מחלקה מציין "יחיד"‪ .‬מכך אנו‬
‫לומדים שהקשר בין מגמות לתלמידים הוא יחיד לרבים (‪ .)N:1‬לעיתים מציינים זאת בצורה אחרת‪ ,‬על‪-‬ידי הוספת הסימן‬
‫"אינסוף" ליד הקו הנכנס לטבלה לציון "רבים"‪ ,‬והוספת הסימן "‪ "1‬ליד הקו הנכנס טבלה לציון "יחיד"‪.‬‬
‫•מדוע הוספנו לטבלת תלמידים את השדה "קוד מגמה"?‬
‫•תשובה ‪ :‬על מנת לאפשר למסד הנתונים ליצור את הקשר בין שתי הטבלאות‪ .‬שדה כמו "קוד מגמה" נקרא מפתח זר‬
‫(‪ .)Foreign Key‬מה הכוונה? הוא מהווה מפתח ראשי בטבלה אחת (טבלת מגמות) ושדה "רגיל" בטבלה שנייה (טבלת‬
‫תלמידים)‪.‬‬
 ‫יחיד לרבים ‪ -‬המשך‬
‫• מדוע בחרנו דווקא להוסיף את "קוד מגמה" לטבלת תלמידים‪ ,‬ולא להוסיף את "קוד תלמיד" לטבלת מגמות?‬
‫• נניח והיינו מוסיפים את השדה "קוד תלמיד" לטבלת מגמות‪ .‬איזו בעיה הייתה מתעוררת? לא היינו יודעים באיזה‬
‫תלמיד מדובר (מכיוון שיש תלמידים רבים הקשורים למגמה אחת)‪ ,‬ולכן היה עלינו להוסיף "קוד מגמה" לטבלת‬
‫תלמידים (כאן אין בעיה‪ ,‬מכיוון שכל תלמיד קשור למגמה אחת בלבד)‪.‬‬
‫•נסכם ‪ :‬כאשר אנחנו רוצים לממש קשר יחיד לרבים במסד נתונים טבלאי‪ ,‬מוסיפים את המפתח של הטבלה שהכניסה‬
‫אליה היא "יחיד"‪ ,‬אל תוך הטבלה שהכניסה אליה היא "רבים"‪.‬‬
 ‫יחיד ליחיד‬
‫•כיצד ננהג כאשר אנחנו רוצים לממש קשר ‪( 1:1‬יחיד ליחיד)? במקרה כזה‪ ,‬נבחר בצורה שרירותית את המפתח של‬
‫אחת הטבלאות‪ ,‬ונוסיף אותו לטבלה השנייה כמפתח זר (זה לא משנה באיזו טבלה בוחרים)‪.‬‬
 ‫רבים לרבים‬
‫•כעת‪ ,‬מה לגבי קשר רבים לרבים? (‪)M:N‬‬
‫• כאשר רוצים לממש קשר רבים לרבים בין שתי טבלאות‪ ,‬מוסיפים טבלה שלישית הנקראת טבלת קשר‪ .‬המפתח של‬
‫טבלת קשר מורכב מצירוף המפתח של שתי הטבלאות האחרות‪ ,‬וטבלת הקשר קשורה בקשרי "יחיד לרבים" אל שתי‬
‫הטבלאות האחרות‪.‬‬
 ‫דוגמא‬
‫• יש לתכנן מסד נתונים טבלאי המטפל במלאי מוצרים בחנות ובהזמנת מוצרים‪ .‬בהזמנה אחת ניתן להזמין פריטים רבים‪,‬‬
‫וכל פריט יכול להיות מוזמן פעמים רבות‪ .‬עבור כל פריט יש לשמור את קוד הפריט‪ ,‬המחיר ליחידה ואת הכמות‬
‫הנוכחית שלו במלאי‪ .‬עבור כל הזמנה יש לשמור את מספר ההזמנה‪ ,‬תאריך ההזמנה‪ ,‬קוד הספק (ממנו מזמינים את‬
‫ההזמנה)‪ ,‬וכן את הקודים והכמויות של כל הפריטים המופיעים בהזמנה ‪.0‬‬
 ‫תרגיל‬
‫נתונה טבלה בשם הזמנות המכילה את התכונות הבאות‪:‬‬
‫הזמנות (מספר הזמנה‪ ,‬מספר פריט‪ ,‬תאריך הזמנה‪ ,‬מספר ספק‪ ,‬שם ספק‪ ,‬כתובת הספק‪ ,‬קוד מחלקה מזמינה‪ ,‬שם‬
‫מחלקה מזמינה‪ ,‬תיאור פריט‪ ,‬כמות מוזמנת‪ ,‬מחיר פריט)‪.‬‬
‫נרמל את הטבלה ושרטט תרשים מבנה נתונים (‪ )DSD‬המתאימים לבעיה‪.‬‬
‫•פתרון‪ :‬המפתח העיקרי של הטבלה הוא הצירוף של השדות "מספר הזמנה" עם "מספר פריט"‪ .‬נשרטט את תרשים‬
‫התלויות הפונקציונליות המתאים‪:‬‬
‫תאריך‬ ‫שם‬
‫הזמנה‬ ‫ספק‬
 ‫המשך פתרון‬
‫• ניתן לראות בבירור שמחלקה זו אינה במצב תקין כיוון שלא כל השדות תלויים תלות פונקציונלית מלאה במפתח‪,‬‬
‫וישנם שדות שאינם כלולים במפתח ומגדירים בכל זאת שדות אחרים)‪ .‬לכן יש לפרקה למספר מחלקות‪:‬‬
‫•פריטים (מספר פריט‪ ,‬תיאור פריט)‬
‫•מחלקות (קוד מחלקה‪ ,‬שם מחלקה)‬
‫•ספקים (מספר ספק‪ ,‬שם ספק‪ ,‬כתובת ספק)‬
‫•הזמנות (מספר הזמנה‪ ,‬תאריך הזמנה‪ ,‬מספר ספק‪ ,‬קוד מחלקה)‬
‫•פריטים בהזמנה (מספר הזמנה‪ ,‬מספר פריט‪ ,‬כמות מוזמנת‪ ,‬מחיר פריט)‬
 ‫המשך פתרון‬
‫•כעת נשרטט תרשים מבנה נתונים (‪ )Data Structure Diagram – DSD‬המתאים לבעיה‪:‬‬

‫•הערה‪ :‬תרשים זה זהה ברובו לתרשים ‪.ERD‬‬

 ‫הקבצה (‪)Aggregation‬‬
‫הקבצה מאפשרת להשתמש בטיפוס קשרים כאילו הוא טיפוס ישויות‪.‬‬
 ‫סיכום‬
‫• תכונות ההקבצה הן כל תכונות הטיפוסים המשתתפים (הקשר והישויות)‪ .‬לכל קומבינציה של ישויות המקושרות ע"י‬
‫הקשר‪ ,‬תהיה ישות אחת בהקבצה‪ .‬ההלחם של המפתחות יחד יגרום לישות אחת‪.‬‬
‫• ברמת המימוש לא צריך לתחזק טבלה עבור ההקבצה עצמה ─ היא תוסק מהטבלאות עבור הטיפוסים המרכיבים אותה‪.‬‬
 ‫דוגמא – אוניברסיטה‬
‫אוניברסיטה מסוימת מעוניינת בניהול נתוני הסטודנטים‪ ,‬רישומם לקורסים וציוניהם‪.‬‬
‫זאת כדי להפיק דו"חות קורסים וציונים לסטודנטים ולמזכירויות החוגים‪ ,‬ודו"חות סטודנטים רשומים לכל קורס‪ .‬לא‬
‫קיימים מסלולים רב‪-‬חוגיים‪.‬‬
‫המשך דוגמא ‪DSD -‬‬
 ‫תרגיל מסכם‬
‫בנו תרשים ‪.DSD‬‬
‫• במערכת בית מרקחת של "מרפאת הרוקח" למטופלים (לקוחות) יש מרשמים ומקבלים שירות בהתאם‪.‬‬
‫•במערכת זו ידוע לכל מטופל עם תעודה מזהה ייחודית ומידע אישי לא ייחודי‪ :‬כתובת‪ ,‬שם פרטי‪ ,‬שם משפחה ומספר‬
‫טלפון‪.‬‬
‫•בכל מרשם (‪ )Prescription‬המטופל והרופא נקבעים באופן ייחודי עם תעודות הזהות שלהם ועם‪ .‬באופן דומה‪,‬‬
‫לרופאים יש טבלת מערך נתונים משלהם‪ ,‬הכוללת את המידע ואת המזהים הייחודיים שלהם‪ .‬למרשם יש תאריך‬
‫והערות‪.‬‬
‫•מידע לגבי תרופות (‪ )Medication‬שנקבעו נשמר בטבלה אחרת‪ .‬לכל תרופה יש מזהה ייחודי בנוסף למידע לא ייחודי‬
‫כמו שם‪ ,‬קוד‪ ,‬מחיר והערות לגבי התרופה‪.‬‬
‫•לכל רופא (‪ )Doctor‬יש תעודה מזהה ייחודית ומידע אישי לא ייחודי‪ :‬כתובת‪ ,‬שם פרטי‪ ,‬שם משפחה ומספר טלפון‪,‬‬
‫מייל והערות לגביו‪.‬‬
 ‫תרגיל מסכם ‪ -‬המשך‬
‫הקריטריונים הבאים נלקחים בחשבון בתכנון מסד הנתונים‪:‬‬
‫לכל מטופל (‪ ) patient‬יכולים להיות מרשמים שונים‪ ,‬כאשר כל מרשם שייך למטופל אחד בלבד‪.‬‬ ‫‪.1‬‬
‫כל מרשם (‪ ) Prescription‬שייך לרופא בלבד‪ .‬עם זאת‪ ,‬כל רופא יכול לרשום מרשמים רבים‪.‬‬ ‫‪.2‬‬
‫לכל מטופל או רופא יש כתובת (‪ ) Address‬ספציפית אחת‪ .‬עם זאת‪ ,‬למטופלים ולרופאים רבים יכולים להיות כתובות‬ ‫‪.3‬‬
‫דומות‪ .‬מה לגבי טבלת כתובת‪ ,‬מה יהיה מיוחד בה?‬
‫לאמצעי תשלום עבור מרשמים (‪ )Payment‬יש תעודות זהות ייחודיות ומידע אישי לא ייחודי‪ :‬שם והערות‪ .‬ניתן לשלם על‬ ‫‪.4‬‬
‫כל מרשם בשיטה אחת בלבד‪ .‬אבל‪ ,‬בתשלום ניתן לשלם על כמה מרשמים‪.‬‬
‫יכולות להיות תרופות שונות במרשם המטופל‪ .‬עם זאת‪ ,‬כל תרופה שנרשמה שייכת ספציפית למרשם אחד‪.‬‬ ‫‪.5‬‬
‫למרות שלכל תרופה יש תעודת זהות ספציפית במלאי‪ ,‬היא יכולה להשתייך למרשמים רבים‪.‬‬ ‫‪.6‬‬
‫• רמז‪ :‬צריך טבלת קשר בין ‪ Medication‬לבין ‪ Prescription‬שנקרא לה למשל פריטי_מרשם ובה יהיה המזהים של תרופות ושל‬
‫מרשמים‪ ,‬כמות והערות‪.‬‬
‫תרגיל מסכם ‪ -‬פתרון‬