The Entity-Relationship Model
HIGH-LEVEL DATABASE MODELS
בניית שרת זה לא משהו שנעשה בין רגע ויש לו מספר שלבים
בשלב העיצוב הראשוני נרצה לענות על מספר שאלות חשובות שקשורים לאופן שבו המידע שלנו יאוחסן ואיך מידע יהיה מקושר לפיסת מידע אחר, מהם האילוצים כמו מפתחות וכו.
כמו כן, נרצה שבשלב העיצוב הוא יהיה מספיק high-level כדי להתעלם מהעובדה של האם השרת הוא רלציוני או לא, רק לאחר שלב העיצוב אם נרצה נמיר את מה שבנינו לסכמה רלציונית.
ישנם מספר שיטות כדי לבנות עיצוב שכזה:
הראשונה ובה אתמקד בסיכום זה היא entity-relationship diagram.
השנייה שהיא יותר מוכרת היא UML basics שבמקור עוצבה עבור תכנות מונחה עצמים אבל אומצה גם לתיאור של סכמות .
השלישית והצעירה ביותר היא ODL , שנועדה במקור לתאר שרתים כאוסף של מחלקות ואובייקטים.
E-R model
המודל E/R הוא מודל שבו הבנייה של המידע מיוצגת באופן גרפי על ידי שימוש ב3 עקרונות פשוטים
Entity Sets
יישות הוא אובייקט אבסטרקטי מסוג כלשהי, אוסף של אובייקטים דומים שכאלה נקרא entity set.
יישות באופן מסויים מדמה אובייקט (בהקשר של מונחה עצמים). באופן דומה, entity set מקבילה למחלקה.
חשוב לשים לב ש E/R הוא מודל סטטי לתיאור מידע בלבד ולכן לא נראה דברים כמו מתודות בדיאגרמה הזאת.
דוגמה קלאסים היא טבלת סרטים שבה כל רשומה (שורה) היא אובייקט והקבוצה של כל הסרטים היא הטבלה שמכילה את כל הסרטים.
attributes
ל אוסף יישויות יש תכונות שמקושרות אליו, אלו הם המשתנים של היישות שיכולים להשתנות בין יישות ליישות.
למשל, לסרט יש שם,במאי, אורך, וכו....
בגרסאות שונות של מודל ה E/R הטיפוס של תכונה יכול להיות
- פרימיטיבי
- struct כמו ב C או tuple עם מספר קבוע של משתנים פרימיטיביים
relationships
חיבורים בין מספר entity sets. למשל החיבור בין טבלת סרטים לטבלת שחקנים יוכל להיות מחובר על ידי חיבור stars in.
למשל יישות של שחקן s ויישות של סרט m יהיו מחוברים כך:
נשים לב שrelationships מחברות בין יישויות.
Entity-Relationship Diagrams
דיגארמת E/R היא גרף שמייצג מספר entity sets , תכונות וקשרים.
כל אלמנט מהסוג הנ״ל הוא קודקוד בגרף ולכל סוג יש צורה מסויימת לקודקוד.
א) entity sets מיוצגים על ידי מלבנים
ב) תכונות מיוצגות על ידי אליפסה
ג) קשרים מיוצגים על ידי מעויין (יהלום)
קשתות מחברות בין entity-set לתכונות שלו וגם ל relationship למשל
נדבר על הכיוון של החץ בהמשך.
Multiplicity of Binary E/R Relationships
יחס בינארי יכול לחבר כל תכונה של קבוצת יישות לכל מספר של תכונות אחרות בקבוצת יישות אחרת. עם זאת, נפוץ להגביל את הריבוי של יחסים.
נניח ש
א) אם כל תכונה מ E יכולה להיות מחוברת על ידי
ב) אם
ג) אם
למשל עבור Studio ו Presidents אנחנו יודעים שנשיא יכול לנהל רק סטודיו אחד וכל סטודיו יש לו מנהל אחד ולכן מדובר ב one-one .
נשים לב שהחץ אומר לכל היותר אחד והוא לא מבטיח שיש בכלל יישות בקבוצה שאכן מצביע עליו.
סימון של ״בידיוק אחד״ יראה ככה
Multiway Relationships
נוח במודל הזה להגדיר יחסים שמקושרים ליותר מ 2 קבוצות יישויות. בפרקטיקה יחסים מדרגה הגבוהה מ2 נדירות, אך הכרחיות.
multiway relationship בדיאגרמת E/R מיוצגת על ידי קווים מהקודקוד שמייצג את היחס לכל אחד מהentitiy set.
חץ שכזה אומר שהיישויות האחרות שאינן סטודיו מקושרות לכל היותר ליישות אחת ב Studios.
באופן לא פורמלי אפשר לדמיין את זה כ FD כאשר נמצא בצד ימין והיישויות האחרות נמצאות בצד שמאל. כלומר בתמונה למעלה זה אומר שעבור שחקן וסרט מסויימים יש רק סטודיו שמולו השחקן חתם שהוא ישתתף בסרט. נשים לב שאין חצים לכיוון של Stars ו Movies כלומר שסטודיו יכול להחתים מספר כוכבים לאותו סרט וכוכב יכול לחתום עם סטודיו אחד על מספר סרטים.
Roles in Relationships
ישנה אפשרות שenrty set אחד יופיע פעמיים או יותר עבור relation יחיד. אם זה המצב נצייר מספר קווים מהrelationship ל entryset. כל קו מייצג תפקיד אחר שה entryset משחק ביחסים.
אם כן במצב הזה נצמיד לכל קו תווית או ״תפקיד״.
כאן למשל ניתן לראות שיש יחס בין יישויות מסויימות של סרטים שאחד הוא סרק מקורי והשני הוא סרט המשך. נשים לב שאחד מהם הוא ביחס של manyone כלומר יכול להיות רק סרט מקורי אחד ויכולים להיות מספר סרטי המשך.
נסתכל על דוגמה נוספת, שכוללת גם יחסים עם מספר כיוונים וגם entitiy set עם מספר תפקידים.
כעת contracts מערב שתי studios, סטודיו של שחקן וסטודיו של סרט. הכוונה היא שסטודיו מסויים שתחתיו חתום שחקן (באופן כללי בלי קשר לסרט) יכול לתת חוזה לסטודיו אחר להפיק סרט עם השחקן הזה.
כלומר ה relationship ממתואר על ידי רביעייה מהצורה
כאשר studio2 חתום עם studio1 על שימוש של כוכב מ studio1בשביל סרט מ studio2.
נשים לב שהחצים מופנים לstudios משני התפקידים שלו. למרות זאת, אין חצים שמופנים לentitiy sets האחרים. הרציונל הוא שבהינתם שחקן, סרט ואולפן שמפיק את הסרט, יכול להיות רק אולפן אחד שאחרי על השחקן. באופן דומה, רק אולפן אחד אחראי על הפקת סרט כלשהו.
Attributes on Relationships
לפעמים זה מועיל ואפילו הכרחי לחבר תכונה לrelationship במקום לentitiy sets שמחוברים על ידיו.
לדוגמה, אולי נרצה לעקוב אחרי משכורת שמשוייכת לחוזה כלשהו בין שחקן לאולפן עבור סרט מסויים. עם זאת, בעייתי לשייך את זה לשחקן כי שחקן יכול לקבל משכורת שונה לכל סרט. באופן דומה לא הגיוני שלייך משוכרת לאולפן כי אותו אולפן ישלם משכורת שונה לסרט אחר ושחקן אחר.
אבל, נוכל לשייך משכורת ייחודית עם השלישייה (star,movie,studio) עבור Contracts. הקשר יחזיק תכונה של משכורת והתכונות של קבוצת היישויות לא ייפגעו.
Converting Multiway Relationships to Binary
E/R בניגוד למודלים אחרים לא דורש שיחסים יהיו בינאריים, לכן כדאי לדעת שכל יחס שמחבר בין יותר משתי יישויות יכול להיות מומר לאוסף של קשרים שהם בינאריים ו many one.
כדי לעשות זאת, נצטרך לבנות entitiy set חדש שהיישויות שלו יהיו מכפלה קרטזית של כל מי שהיה ביחס הלא בינארי. זה נקרא connecting entity וזה ממש כמו טבלה מקשרת.
לאחר מכן נבנה many-one relationships מה יישות המחברת לכל אחד מהאחרים שנותן רכיב במכפלה הקרטזית.
למשל עבור הדיגאמה הבאה
נוכל להמיר אותה לבינארית כך
תתי מחלקות
כמו שאנחנו מכירים מתכונות תורשה של תכנות מונחה עצמים, יתכן ויהיה לנו סט שהוא Subclass של כלשהו Entity Set קיים. המשמעות של זה היא, מבחינה לוגית, היא שסט Subclass הוא תת מחלקה של Superclass אם מתקיים היחס:
כלומר כל אובייקט מהמחלקה היורשת הוא בעצמו סוג של אובייקט ממחלקת האב. כצפוי, עבור כל אובייקט מ-Entity Set שיורש מסט אב, יהיו את כל הרשומות שמאפיינות את סט האב בנוסף לרשומות שמאפיינות אותו ספציפית. נסמן זאת באמצעות משולש
Constraints
ישנם מספר הגבלות שניתן לשים על המודל הזה
א) מפתחות - יסומנו על ידי קו תחתון
ב) יחסים
ג) Referential integrity - ״חייב להתקיים״
ד) אחרים - ״קבוצה זו צריכה להכיל לכל היותר 10 איברים״
Referential Integrity
Constraint נוסף שניתן להגדיר עבור Relationships הוא ה-Referential Integrity- כלומר החיוב שלכל ערך מקבוצה אחת חייב להיות כלשהו ערך שמתאים לו מקבוצה אחרת.
סוג יותר חזק של Referential Integrity הוא ב-Weak Entity Set ובו המזהה של כל אובייקט בסט אחד מאופיין על ידי כלשהו אובייקט מסט אחר.
למשל בדוגמא זו לא סתם שלכל Product חייב להיות כלשהי התאמת Makes עם חברה אחת שמייצרת אותו, אלא בנוסף לכך יחס ה-Makes מאפיין כל מוצר ב-Product, באופן כזה שה-Key של כל מוצר ב-Product הוא לא רק הערך בשדה ה- .Makes-על ידי יחס ה Company-שמוקצה לו מטבלת ה Manufacturer-שבטבלה זו אלא גם שדה ה Name.
ניתן על ידי כתיבה על הקשתות בדיאגרמה להציג Constraints נוספים על יחסים, כמו למשל בדוגמה הבאה ובו אמנם לכל Team יכול להיות התאמה למספר אנשים מתוך Worker, אבל לא יותר מ-10:
המרה של ER Diagram ל-DB Scheme
כעת לאחר שתכננו באופן רעיוני דיאגרמת ER שתתאר את בסיס הנתונים שלנו, נרצה להמיר את זה לצורת סכימה של בסיס נתונים אמיתי- ובמקרה שלנו בסיס נתונים רלציוני. Entity Sets תמיד יתורגמו לטבלאות. באופן הכי אינטואיטיבי, לכל Entity Set נגדיר טבלה שמתאימה לו, ובה כל רשומה מתארת אובייקט שמייצג ה-Entity Set ויש לה את כל שדות ה-Attributes שמאפיינים סט זה.
Many-to-Many Relationships יתורגמו גם הם לטבלאות- כל טבלה מתארת יחס. לכל אחד מהצדדים של ה-Relationship תהיה טבלה נפרדת של ה-Entity Set שלו, והטבלה של ה-Relationship תהיה טבלה נוספת שמכילה מפתחות זרים לכל אחת מהטבלאות כך שכל רשומה שם תייצג צימוד בין אובייקט מטבלה אחת לטבלה אחרת, בלי שום הגבלה על הכמויות. השדות שמחייבת שיהיו בטבלה זו הן אותן שדות של Foreign Keys שיקשרו בינה לבין טבלאות ה-Entity Sets וגם השדות שמאפיינים את ה-Relationship הספציפי הזה.
One-to-Many Relationships לעומתם לא יתורגמו לטבלאות נפרדות, אלא ייוצגו בטבלה של הצד של ה-Many (כלומר בצד שיוצא ממנו החץ, ולכל אובייקט שם מותאם לכל היותר אובייקט אחר מהטבלה השנייה).
למשל בדוגמא זו אנחנו יודעים כי לכל Product מתאימה בדיוק חברה אחת שייצרה אותו ביחס ה-Make (ויתכן שלאותה חברה יהיו מספר מוצרים שהיא מייצרת). על כן בטבלה של ה-Product נוכל להוסיף שדה של Manufacturer שיהווה Foreign Key לטבלה של ה-Company, וכך לכל מוצר יהיה כתוב את החברה האחת שמייצרת אותו.
כאשר ניצור טבלה ל-Set Entity שהוא Subclass של Set Entry אחר, בטבלה מה שחיוני שיופיע זה השדות שמאפיינים את ה-Subclass הזה ואת השדה מתוך סט האב שהוא המפתח של עצמים בו. כל שאר השדות של סט האב לא יצטרכו להישמר בטבלה של סט הבן שכן באמצעות המפתח ניתן לקשר ישירות אובייקט מטבלת הבן לטבלת האב ולמצוא את ערכי השדות האלה שם.
כמו כן, ניתן להגדיר כל Constraint אחר מדיאגרמת ה-ER כפשוט Constraint על הטבלאות המתאימות- הגבלה של שדה שלא יוכל להיות NULL עבור Referential Integrity, הגבלות CHECK לשדות מסוימים וכדומה.
כאשר יהיה לנו Weak Entity Set ובו כל ערך של טבלה אחת מאופיין באופן יחיד ומחייב על ידי אובייקט של טבלה אחרת, נשים לב שבטבלה של ה-Weak Entity Set יהיה חייב להימצא גם שדה המפתח של הטבלה האחרת בה הוא תלוי, שישמש כ-Key נוסף בטבלה זו וכמובן כ-Foreign Key בין שניהם.
למשל בטבלה זו כל מוצר מ-Product מאופיין באופן מחייב על ידי החברה שמייצרת אותו מתוך Company. על כן, כשנבנה טבלה ל-Product יתחייב להיות שם השדה Manufacturer כמפתח, כי הוא המפתח של הטבלה שניצור ל-Company. כעת בטבלת Product כל מוצר יהיה מאופיין על ידי השם שלו וגם על ידי שם החברה שמייצרת אותו.
כמו כן אם נחזור לטבלאות שמייצגות יחסי Many-to-Many, בטבלאות אלו שדות המפתח יהיו חייבים להיות כל שדות המפתחות של כל הטבלאות משתתפות ביחס זה. אם יש לנו יחס Multi-Way יותר מורכב- ובו חלק מהסטים שמשתתפים הם Many-to-Many וחלק הם Many-to-One, נצטרך להכיל את כל המפתחות של כל הטבלאות שמשתתפות ביחס מלבד המפתחות של הטבלאות בצד ה-One (שנכנס אליהן החץ).
הסיבה לכך היא שבהינתן הערכים של כל שדות המפתח של הסטים האחרים, הערך של האובייקט המתאים מטבלת ה- Invoice (במקרה זה) נקבע ביחידות, ועל כן אין צורך לייצג אותו באמצעות מפתח גם כן- אנחנו יודעים את הערכים של כל שדות המפתח האחרים אז זה אוטומטית גורר אובייקט אחד נקודתי מתוך Invoice שמתאים להם.