המצגת נטענת. אנא המתן

המצגת נטענת. אנא המתן

תכנון סכמות רלציוניות איזה תכנון טוב יותר? Customer Ordered CustOrders

מצגות קשורות


מצגת בנושא: "תכנון סכמות רלציוניות איזה תכנון טוב יותר? Customer Ordered CustOrders"— תמליל מצגת:

1 תכנון סכמות רלציוניות איזה תכנון טוב יותר? Customer Ordered CustOrders
Track Faculty Cust_Id Software CS 12345 Hardware EE 45678 IS IE 11111 Accounting 22222 Book_Name Cust_Id Database Systems 12345 Anatomy 45678 Database And Knowledge 11111 Intro. To Economy 22222 איזה תכנון טוב יותר? CustOrders Book_Name Track Faculty Cust_Id Database Systems Software CS 12345 Anatomy Hardware EE 45678 Database And Knowledge IS IE 11111 Intro. To Economy Accounting 22222 אביב-תשס"ז DBMS, תכנון סכמות, Design

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

3 - 236363 DBMS, תכנון סכמות, Design
תכנון – כללי (המשך) תכנון טוב: מונע כפילויות. מאפשר עדכונים יעילים. פשוט ככל האפשר. בלי יותר מדי טבלאות. כלי אחד לתכנון – בניית מודל ישויות-קשרים (ERD). כלי נוסף – תלויות פונקציונליות. אביב-תשס"ז DBMS, תכנון סכמות, Design

4 תלויות פונקציונליות Functional Dependency
תלויות פונקציונליות: הכלי הבסיסי בתכנון סכמות רלציוניות. אינטואיציה: תלויות מבטאות את העובדה שלא כל צרוף של ערכים הוא חוקי והגיוני במסד הנתונים. למשל בתכנון מסד נתונים של ספרייה, לא נרצה לאפשר שני לקוחות עם אותו Cust_Id ופקולטה שונה. בנוסף, תלויות מסוימות מצביעות על אפשרות לכפילויות במסד. למשל, התלות של פקולטה ב-Cust_Id גורמת לכפילויות ב-CustOrders. אביב-תשס"ז DBMS, תכנון סכמות, Design

5 - 236363 DBMS, תכנון סכמות, Design
תלויות – הגדרות (המשך) הגדרה: תהי R(A1,…,An) סכמה רלציונית, תהי r רלציה מעל הסכמה R, ויהיו X, Y ⊆ R קבוצות אטריביוטים. רלציה r מקיימת את התלות הפונקציונאלית X  Y (סימון: r ⊨ XY) אם לכל שתי n-יות t1, t2r כך ש- t1[X]=t2[X] מתקיים t1[Y]=t2[Y]. באופן כללי לא נדבר על תלויות שמתקיימות עבור r ספציפי, אלא על תלויות שנובעות מהתכנון של המסד לכל r אפשרי. דוגמה: מהן התלויות ש-CustOrders מקיימת? הגדרה: תהי R(A1,…,An) סכמה רלציונית, תהי F קבוצה של תלויות פונקציונליות מעל R, ותהי f תלות פונקציונלית מעל R. תלות פונקציונלית f נובעת מ- F (סימון: F ⊨ f) אם לכל רלציה r מעל הסכמה R שמקיימת r ⊨ F, מתקיים r ⊨ f (r ⊨ F ↔ r ⊨ f). אביב-תשס"ז DBMS, תכנון סכמות, Design

6 - 236363 DBMS, תכנון סכמות, Design
מוסכמות סימון אטריביוטים בודדים נסמן באותיות לועזיות מתחילת הא"ב: A,B…. קבוצות של אטריביוטים נסמן באותיות מסוף הא"ב: X,Y…. לפעמים נקצר ונרשום A במקום {A}, או AB במקום {A,B}. סכמות של רלציות נסמן באותיות גדולות: ...,R,T,S. למשל R={A,B,C} או R(A,B,C) או R[A,B,C]. את תוכן הרלציות נסמן באותיות קטנות: r,t,s,…. למשל r={(1,2,3),(2,1,4)} אביב-תשס"ז DBMS, תכנון סכמות, Design

7 - 236363 DBMS, תכנון סכמות, Design
תלויות – הגדרות (המשך) הגדרה: תהי F קבוצת תלויות פונקציונליות. הסגור של F (סימון: F+) הוא: {X  Y | F ⊨ X  Y}. דוגמה: R(A, B, C), F = {A  B, B  C} ב- F+ יהיו התלויות הפונקציונליות הבאות: A  C, AB  C, AC  C, B  B, A  B, אביב-תשס"ז DBMS, תכנון סכמות, Design

8 - 236363 DBMS, תכנון סכמות, Design
אקסיומות ארמסטרונג מטרה: לבנות מערכת הוכחה פורמלית לתלויות פונקציונליות. אקסיומות ארמסטרונג: (A1) רפליקסיביות: אם Y⊆X⊆R אז X  Y (A2) הכללה: אם X  Y ו- Z⊆R אז X⋃Z  Y⋃Z (A3) טרנזיטיביות: אם X  Y ו- Y  Z אז X  Z אביב-תשס"ז DBMS, תכנון סכמות, Design

9 - 236363 DBMS, תכנון סכמות, Design
הוכחות פורמליות באמצעות אקסיומות ארמסטרונג ניתן לכתוב הוכחות פורמליות. הוכחה פורמלית היא סידרה של שורות, שבכל אחת מהן רשומה טענה (תלות פונקציונלית). כל שורה ממוספרת, ומנומקת ע"י התייחסות לשורות קודמות ולכלל ההיסק המתאים. הגדרה: תהי F קבוצה של תלויות פונקציונליות ותהי f תלות פונקציונלית. מ-F ניתן להוכיח את f (סימון:F ⊦ f ) אם אפשר להסיק את f מ-F באמצעות אקסיומות ארמסטרונג. אביב-תשס"ז DBMS, תכנון סכמות, Design

10 - 236363 DBMS, תכנון סכמות, Design
הוכחות פורמליות - המשך דוגמה: נתון F={Cust_IdTrack,TrackFaculty} נראה ש- F ⊦ Cust_Id {Track,Faculty}: Track  Faculty ⊆ F Track  {Track,Faculty} 1, A2 Cust_Id  Track ⊆ F Cust_Id  {Track,Faculty} 3, 2, A3 אביב-תשס"ז DBMS, תכנון סכמות, Design

11 - 236363 DBMS, תכנון סכמות, Design
הוכחות פורמליות - המשך שימו לב: "⊦" מבטא "ניתן להוכחה" (לפי המערכת של ארמסטרונג). " ⊨ " מבטא "נובע" (במובן של קיום התלויות ע"י כל הרלציות האפשריות המתאימות). משפט: לכל תלות פונקציונלית f וקבוצת תלויות פונקציונלית F, מתקיים: F ⊦ f אם ורק אם F ⊨ f. במילים אחרות: אקסיומות ארמסטרונג הן נאותות ושלמות: שלמות: אפשר להוכיח באמצעותן כל דבר נכון. נאותות: אפשר להוכיח באמצעותן רק דברים נכונים. אביב-תשס"ז DBMS, תכנון סכמות, Design

12 - 236363 DBMS, תכנון סכמות, Design
כללי היסק נוספים כללי היסק נוספים: איחוד: אם X  Y ו- X  Z אז X  Y⋃Z. פרוק: אם X  Y ו- Z ⊃ Y אז X  Z. טרנזיטיביות למחצה: אם X  Y ו- W⋃YZ אז W⋃XZ. אפשר להשתמש בכללים הנוספים כדי לקצר הוכחות פורמליות. כל אחד מהכללים מחליף סידרה של צעדי היסק המשתמשים רק באקסיומות ארמסטרונג. אביב-תשס"ז DBMS, תכנון סכמות, Design

13 - 236363 DBMS, תכנון סכמות, Design
כללי היסק - דוגמה דוגמה: את כלל הטרנזיטיביות למחצה אפשר להחליף בסדרת הצעדים הבאה: X  Y נתון W⋃X  W⋃Y 1, A2 W⋃YZ נתון W⋃XZ 2, 3, A3 אביב-תשס"ז DBMS, תכנון סכמות, Design

14 - 236363 DBMS, תכנון סכמות, Design
תלויות – הגדרות (המשך) הגדרה: תהי X קבוצת אטריביוטים ותהי F קבוצת תלויות פונקציונליות. הסגור של X בהינתן F (סימון: XF+) הוא {A | F ⊦ X  A}. אלגוריתם לחישוב XF+: W ← X Repeat For each (Y  Z) ⊆ F If Y ⊆ W then W ← W ⋃ Z Until no more changes to W Output W = (XF+) אביב-תשס"ז DBMS, תכנון סכמות, Design

15 - 236363 DBMS, תכנון סכמות, Design
חישוב XF+ - דוגמה נתון F = {AB,A E,BCD,EC}, R(A, B, C, D, E). נחשב את A+F: {A}= W ABF, {A}W, W=W{B}={A,B} AEF, {A}W, W=W{E}={A,B,E} ECF, {E}W, W=W{C}={A,B,C,E} BCDF, {B,C}W, W=W{D}={A,B,C,D,E} פלט: A+F={A,B,C,D,E} אביב-תשס"ז DBMS, תכנון סכמות, Design

16 - 236363 DBMS, תכנון סכמות, Design
כיסוי מינימלי בקבוצת תלויות פונקציונליות יכול להיות מידע עם חזרות. דוגמה: שתי הקבוצות ,G={AB, BC,AC} F={AB,BC} הן "שקולות", במובן ש- F+ = G+. מטרה: להביא את כל קבוצות התלויות פונקציונליות לצורה אחידה. צורה זו נקראת הכיסוי המינימלי (minimal cover) של קבוצת התלויות. שימו לב כי ייתכנו מספר כיסויים מינימאליים שונים עבור אותה קבוצת תלויות. אביב-תשס"ז DBMS, תכנון סכמות, Design

17 - 236363 DBMS, תכנון סכמות, Design
כיסוי מינימלי - הגדרה הגדרה: תהי F קבוצת תלויות פונקציונליות. F היא מינימלית אם לכל תלות X  Y ∈ F מתקיימות שלוש הדרישות הבאות: |Y| = 1 F+ ≠ (F \ {X  Y})+ – אין ב-F תלויות "מיותרות". לכל Z ⊊ X מתקיים F+ ≠ (F \ {X  Y}  {Z  Y})+ – אין ב-F תלות A  X שבה X מכילה תכונות "מיותרות". אביב-תשס"ז DBMS, תכנון סכמות, Design

18 - 236363 DBMS, תכנון סכמות, Design
כיסוי מינימלי - המשך במקום לחשב את F+ כדי לבדוק אם קבוצת תלויות F היא מינימלית, אפשר לבצע את הבדיקות הבאות: עבור תנאי 2: נבדוק ש- F\ {X  Y} ⊬ X  Y, או באופן שקול ש- Y ⊈ X+F\ {X  Y} . עבור תנאי 3: נבדוק שלכל BX מתקיים F ⊬ (X \ B)  Y, או באופן שקול ש- Y ⊈ (X \ B)+F הגדרה: תהי F קבוצת תלויות פונקציונליות. כיסוי מינימלי (minimal cover) של F הוא קבוצת תלויות פונקציונליות FC כך ש-FC מינימלית ו- F+ = FC+. הכיסוי המינימלי אינו בהכרח יחיד. אביב-תשס"ז DBMS, תכנון סכמות, Design

19 אלגוריתם למציאת כיסוי מינימלי
תהי F קבוצת תלויות פונקציונליות: G ← {(X  A) | Y ((X  Y) ∈ F  A ∈ Y)}; Repeat For each f = X  A ∈ G do if A ∈ X+G\ {f} then G ← G\ {f}; For each f = X  A ∈ G and B ∈ X do if A∈(X\{B})+G then G←G\{XA}  {X\{B}A}; until no more changes to G אביב-תשס"ז DBMS, תכנון סכמות, Design

20 מציאת כיסוי מינימאלי - דוגמה
נתון R(A,B,C,D), F={A  B, BC  A, ABC  D, D  A} יש למצוא כיסוי מינימאלי של F. בצעד ראשון נקבל G=F. נפעיל את שלב 1 – אין שינוי נפעיל את שלב 2 – נוריד A מ-  D ABC, מכיוון ש- D ∈ ({A,B,C}\{A})+G . קיבלנו: G={A  B, BC  A, BC  D, D  A} נפעיל את שלב 1 – נוריד את התלות BC  A, מכיוון ש- A ∈ BC+G\ {BC A}, קיבלנו: G={A  B, BC  D, D  A} אין יותר שינויים, ולכן G הנ"ל הוא כיסוי מינימאלי של F. אביב-תשס"ז DBMS, תכנון סכמות, Design

21 - 236363 DBMS, תכנון סכמות, Design
מפתחות הגדרה: תהי R סכמה רלציונית (קבוצת אטריביוטים), תהי X תת-קבוצה של R, ותהי F קבוצת תלויות פונקציונליות. X הוא על-מפתח של R אם F ⊨ XR. במילים אחרות, X הוא על-מפתח של R אם X  R ⊆ F+. בגלל הוכחת הנאותות והשלמות של אקסיומות ארמסטרונג, X הוא על-מפתח של R אם ורק אם R= XF+ אביב-תשס"ז DBMS, תכנון סכמות, Design

22 - 236363 DBMS, תכנון סכמות, Design
מפתחות – המשך מוטיבציה: תלות במסד שהצד השמאלי שלה גורר את כל האטריביוטים במסד, לא תגרום לכפילויות. במסד קיימים אטריביוטים מיוחדים שמקשרים בין רלציות. למשל ב-ERD, המפתחות של טיפוסי הישות המקושרים ליחס מתווספים לטיפוס היחס. למשל, במסד לקוחות והזמנת ספרים, התכנון שלנו היה כולל את התלות Cust_Id{Faculty,Track}, ולכן תלות זו מעידה על כפילויות בטבלה CustOrders אבל לא מעידה על כפילויות בטבלה Customers. אביב-תשס"ז DBMS, תכנון סכמות, Design

23 - 236363 DBMS, תכנון סכמות, Design
מפתחות - המשך דוגמה: נתון: R(A, B, C, D), F = {A  C, B  D}. ABC הוא על-מפתח של R, אך איננו העל-מפתח היחיד וגם לא המינימלי. הגדרה: תהי R סכמה רלציונית (קבוצת אטריביוטים), תהי X תת-קבוצה של R, ותהי F קבוצת תלויות פונקציונליות. X הוא מפתח קביל של R אם הוא על-מפתח של R, ולא קיים Y ⊊ X, כך ש-Y הוא גם על-מפתח של R. אביב-תשס"ז DBMS, תכנון סכמות, Design

24 - 236363 DBMS, תכנון סכמות, Design
דוגמה נתון: R(Cust_Id, Faculty, Track, Book_Name), F={Cust_Id{Faculty,Track}, TrackFaculty} הקבוצה {Cust_Id, Track, Book_Name} אינה מפתח קביל כי {Cust_Id,Book_Name} מוכלת בה והיא על-מפתח. {Cust_Id, Book_Name} הוא מפתח קביל: קל להראות ש- {Cust_Id, Book_Name}  R. כדי להראות ש- {Cust_Id} ו- {Book_Name} בפני עצמם אינם מפתחות, נחשב את הסגור של כל אחד ונראה שהוא שונה מ-R. אביב-תשס"ז DBMS, תכנון סכמות, Design


הורד את "ppt "תכנון סכמות רלציוניות איזה תכנון טוב יותר? Customer Ordered CustOrders

מצגות קשורות


מודעות Google