צורה נורמלית – BCNF Boyce-Codd Normal Form מוטיבציה: תלות פונקציונלית בקבוצת אטריביוטים שאיננה מהווה על-מפתח יוצרת כפילויות. הגדרה: תהי R סכמה רלציונית, ותהי F קבוצת תלויות פונקציונליות מעל R. R היא ב-BCNF בהינתן F אם לכל תלות פונקציונלית לא טריוויאלית X→Y הנמצאת ב-F+, X הוא על-מפתח של R. אם קיימת תלות לא טריוויאלית בקבוצת אטריביוטים שאיננה על-מפתח, תכנון הסכמה הוא לקוי ובמסד הנתונים עלולות להיווצר כפילויות. אביב-תשס"ז 236363 - DBMS, Design

איך נבדוק שהסכמה ב-BCNF? על פי ההגדרה: יש לחשב את F+ עבור כלX→Y∈ F+ יש לבדוק כי X הינו על-מפתח. הבעיה: הגודל של F+ הוא אקספוננציאלי בגודל של R. משפט: אם סכמה רלציונית R,F איננה ב-BCNF, כלומר קיימת תלותX→Y∈ F+ שמפרה את תנאי ה-BCNF, אזי קיימת תלות Z→W∈ F שמפרה את תנאי ה-BCNF. למשל, עבור R(Cust_Id, Cust_Name,Room_Num) וקבוצת תלויות F={Cust_Id→Cust_Name, Cust_Id→Room_Num, Room_Num→Cust_Id} מספיק לבדוק רק את התלויות ב-F כדי להסיק כי R,F נמצאת ב-BCNF. אביב-תשס"ז 236363 - DBMS, Design

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

פירוקים של סכמות הגדרה: תהי R סכמה רלציונית. פירוק של R הוא קבוצת סכמות ρ = {R1, …,Rn} כך ש-in=1 Ri = R ⋃. דרישות מהפירוק: המסד המפורק חייב לבטא את אותו המידע (תכונת שימור מידע). אם כל אחת מתתי-סכמות מספקת את התלויות הרלוונטיות אליה, אז המסד המפורק מספק את כל התלויות הפונקציונאליות של F (תכונת שימור תלויות). אביב-תשס"ז 236363 - DBMS, Design

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

שימור מידע הגדרה: תהי R סכמה רלציונית, ותהי F קבוצת תלויות פונקציונלית, ויהי ρ = {R1, …,Rn} פירוק של R. ρ הוא משמר מידע בהינתן F אם לכל רלציה r מעל R המקיימת r ⊧ F מתקיים: ⋈in= 1 πRi(r) = r דוגמה: R(ID, NAME, ADDR), F = {ID → NAME, ID → ADDR} הפירוק ρ = {R1(ID, NAME), R2(NAME, ADDR)} אינו משמר מידע. נראה תוכן של R שמקיים את התלויות אך מפר את התנאי של שימור מידע: אביב-תשס"ז 236363 - DBMS, Design

דוגמה – המשך πR1(r) πR2(r) πR1(r) ⋈ πR2(r) ADDR NAME ID ת"א ראובן 1 חיפה 2 NAME ID ראובן 1 2 ADDR NAME ת"א ראובן חיפה πR1(r) ⋈ πR2(r) ADDR NAME ID ת"א ראובן 1 חיפה 2 לעומת זאת, הפירוק ρ’ = {R1’(ID, NAME), R2’(ID, ADDR)} משמר מידע: πR1’(r) ⋈ πR2’(r) = r אביב-תשס"ז 236363 - DBMS, Design

שימור מידע בפירוק לשתי סכמות משפט: פירוק לשתי סכמות ρ = {R1, R2} הוא משמר מידע אם ורק אם F ⊧ (R1 ∪ R2) → (R1 \ R2) או F ⊧ (R1 ∪ R2) → (R2 \ R1) בדוגמה האחרונה (עבור סכמה R(ID, NAME, ADDR)): הפירוק ρ = {R1(ID, NAME), R2(NAME, ADDR)} לא מקיים NAME→ ID, וגם לא NAME → ADDR, ולכן אינו משמר מידע לכל תוכן אפשרי של R. לעומת זאת, הפירוק ρ = {R1(ID, NAME), R2(ID, ADDR)} כן מקיים (למשל) ID → NAME ולכן, לפי המשפט, כן משמר מידע. אביב-תשס"ז 236363 - DBMS, Design

פירוק ל-BCNF הגדרה: תהי R סכמה רלציונית, תהי F קבוצת תלויות פונקציונליות מעל R, ויהיρ = {R1,…, Rn} פירוק של R. ρ הוא פירוק ל-BCNF אם כל תת-סכמה Ri היא ב-BCNF בהינתן πRiF. הגדרה: תהי R סכמה רלציונית, תהי F קבוצת תלויות פונקציונליות מעל R, ותהי S ⊆ R. ההיטל של F על תת-הסכמה S (סימון: πsF) הוא: πsF = {X → Y | X → Y ⊆ F+  X ⋃ Y ⊆ S} יש לשים לב לכך שהתלויות בהיטל נלקחות מתוך F+ ולא רק F. אביב-תשס"ז 236363 - DBMS, Design

פירוק משמר מידע ל-BCNF - הרעיון בהינתן סכמה R ותלות פונקציונלית X → Y, נוכל לפרק את R לשתי תתי-סכמות: {R1[X⋃Y],R2[R\(Y\X)]}. לפי המשפט, מובטח שהפירוק משמר מידע. נחזור על השלב הקודם כל עוד קיימות סכמות אשר אינן נמצאות ב-BCNF. הערה: כיוון שבכל צעד מבצעים פירוק משמר מידע (לשתי תתי-סכמות) , מובטח כי הפירוק המתקבל הוא גם משמר מידע. אביב-תשס"ז 236363 - DBMS, Design

פירוק משמר מידע ל-BCNF - האלגוריתם {R} ρ ← . אם כל הסכמות ב- ρ הן ב-BCNF – עצור. מצא סכמה S ⊆ ρ שאינה ב-BCNF, כלומר שקיימת תלות פונקציונלית X→Y ∈ πsF כך ש-X⋃Y ⊆ S, Y ⊈ X ו- X אינו על-מפתח של S. בצע: ρ  (ρ \ {S}) ⋃ {S\(Y\X)} ⋃ {X ⋃ Y} חזור ל-3. אביב-תשס"ז 236363 - DBMS, Design

אלגוריתם יעיל למציאת כיסוי של πsF האלגוריתם הפשוט לחישובπsF דורש חישוב של F+. להלן אלגוריתם למציאת כיסוי של πsF אשר אינו מצריך חישוב של :F+ Fs← ∅ for each X→Y∈F such that X⊆S do Z ← (X+F ∪ S)\X if Z  ∅ then Fs ← Fs ⋃ {X →Z} Return Fs הערה: האלגוריתם אינו מחזיר את πsF, אלא כיסוי שלו (לאו דווקא מינימאלי). אביב-תשס"ז 236363 - DBMS, Design

פירוק משמר מידע ל-BCNF - דוגמה דוגמה: נתונה הסכמה R (ציונים של סטודנטים), וקבוצת תלויות F: R(snumber, sname, cnumber, cname, grade) F = {snumber →sname, cnumber → cname, (snumber, cnumber) → grade} Snumber -- מס' סטודנט Sname -- שם סטודנט Cnumber -- מס' קורס Cname -- שם קורס Grade -- ציון אביב-תשס"ז 236363 - DBMS, Design

דוגמה - המשך פירוק בשלבים: F = {snumber → sname, cnumber → cname, (snumber, cnumber) → grade} R(snumber, sname, cnumber, cname, grade) snumber → sname R2(snumber, cnumber, cname, grade) R1(snumber, sname) cnumber → cname R3(snumber, cnumber, grade) R4(cnumber, cname) לפי הבנייה, הפירוק ל- {R1,R3,R4} הוא משמר מידע וב-BCNF. אביב-תשס"ז 236363 - DBMS, Design

פירוק ל-BCNF – הערה(1) יש לשים לב כי בפירוק של סכמה רלציונית R אנחנו בודקים אם הפירוק הוא ב-BCNF ע"י כך שבודקים שכל תת-סכמה Ri היא ב-BCNF מעל πRiF (ההיטל מחושב מעל F+). לא מספיק לבדוק האם Ri מקיימת את תנאי ה-BCNF מעל קבוצת התלויות ב-F שמכילות תכונות ב-Ri. ניתן לעשות בדיקה עבור πRiF ע"י כך שקודם מחשבים כיסוי של πRiF עם אלגוריתם יעיל ואז משתמשים במשפט המאפשר לבדוק שיוך ל-BCNF ישירות מהכיסוי. אביב-תשס"ז 236363 - DBMS, Design

פירוק ל-BCNF – הערה(2) דוגמא: R=(A,B,C,D), → C, C→ D} F={B, ρ = {(A,B,D), (B,C)} טענה: הפירוק איננו ב-BCNF. הסבר: R1∉BCNF כי D ∈ πR1F → B אולם B איננו על-מפתח של R1 אולם: אם היינו בודקים את R1 מעל קבוצת התלויות ב-F שמכילות תכונות ב-R1 (אשר שווה לקבוצה ריקה), אזי היינו מקבלים כי R1∈BCNF (ההגדרה מתקיימת באופן ריק). ההערה רלוונטית לכל צורה נורמאלית. אביב-תשס"ז 236363 - DBMS, Design

בדיקת קיום שימור מידע לכל תת-סכמה Ri נקצה ברלציה r שורה אחת ti אלגוריתם כללי לבדיקת שימור מידע בפירוק נתון (מס' תתי-סכמות כלשהו): צור רלציה r מעל הסכמה R. לכל תת-סכמה Ri נקצה ברלציה r שורה אחת ti ti מקבלת את הערך a לכל עמודה A ⊆ Ri ואת הערך bi לכל עמודה B∉Ri. כל עוד אין ב-r שורה שכולה ללא אינדקסים, ויש ב-r שתי שורות ti, tj כך ש- ti[X]=tj[X] עבור תלות פונקציונלית כלשהי (X → Y) ⊆ F, השווה את הערכים ב-tj[Y] וב-ti[Y], באופן הבא: לכל עמודה A∈ Y, אם אחד משני הערכים ti[A], tj[A] הוא a (ללא אינדקס), החלף את הערך האחר ב-a, ואחרת החלף את tj[A] ב-ti[A] או את ti[A] ב-tj[A], כרצונך. הפירוק משמר מידע אם ורק אם בסוף הריצה יש ב-r שורה שהיא כולה ערכים ללא אינדקסים. אביב-תשס"ז 236363 - DBMS, Design

דוגמה דוגמה: נתונה הסכמה R(A, B, C, D, E, F) וקבוצת תלויות F = {A → B, C → D, B → EF}. האם הפירוק ρ = {R1(A, B), R2(A, C, D), R3(B, E, F)} הוא משמר מידע? פתרון: נבנה את הרלציה r: F E D C B A f1 e1 d1 c1 b a f2 e2 d c b2 f e d3 c3 a3 t1 t2 t3 אביב-תשס"ז 236363 - DBMS, Design

דוגמה - המשך A → B (t1,t2) B → EF (t3,t2) F E D C B A f1 e1 d1 c1 b a אביב-תשס"ז 236363 - DBMS, Design

דוגמה נוספת מסקנה: הפירוק משמר מידע. דוגמה: נתון R(A,B,C,D,E), F = {A→B, B→C, C→D , DE→BC}. האם הפירוק ρ = {R1(A,D), R2(A,E), R3(B,C,D,E)} הוא משמר מידע? E D C B A e1 d c1 b1 a e d2 c2 b2 c b a3 E D C B A e1 d c1 b1 a e d2 c2 c b a3 E D C B A e1 d c1 b1 a e d2 c b a3 t1 A→B t1,t2 t1 B→C t1,t2 t1 t2 t2 t2 t3 t3 t3 E D C B A e1 d c1 b1 a e c b a3 E D C B A e1 d c1 b1 a e c b a3 t1 DE→BC t3,t2 C→D t1,t2 t1 t2 t2 t3 t3 מסקנה: הפירוק משמר מידע. אביב-תשס"ז 236363 - DBMS, Design

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

שימור תלויות – דוגמה דוגמה: נתונה הסכמה (עיר, קדומת, טלפון)R והתלויות הפונקציונליות {עיר  (טלפון, קדומת), קדומת  עיר} =F אותה קדומת יכולה להיות משותפת לכמה ערים, אך לכל עיר יש קדומת אחת בלבד. אותו מספר טלפון יכול להופיע בערים שונות, אך לא בערים עם אותה קדומת. שימור מידע: הפירוק {(עיר, קדומת)R2, (עיר, טלפון)R1}= ρ משמר מידע: R1 ∪ R2 = עיר, R2 \ R1 = קדומת, F ⊧ עיר →קדומת שאלה: האם הפירוק משמר תלויות? אביב-תשס"ז 236363 - DBMS, Design

דוגמה - המשך הפירוק אינו משמר תלויות, כי: כל אחת מהרלציות r1, r2 מקיימת את F. r1= עיר טלפון חיפה 1234 טבעון r2= עיר קדומת חיפה 04 טבעון אביב-תשס"ז 236363 - DBMS, Design

דוגמה - המשך אבל ה-join אינו מקיים את F : כאשר נרצה להוסיף או לשנות מספר טלפון ב- r1 נצטרך לבדוק גם ב- r2 כדי לוודא שהשינוי הוא חוקי. לא די שבאותה עיר לא יהיו שני טלפונים זהים - אסור שיהיו טלפונים זהים גם בערים שונות באותו אזור חיוג. עיר קדומת טלפון חיפה 04 1234 טבעון אביב-תשס"ז 236363 - DBMS, Design

שימור תלויות – המשך הגדרה: תהי R סכמה רלציונית, תהי F קבוצת תלויות פונקציונליות מעל R, ויהי ρ = {R1,…,Rn}. ρ הוא משמר תלויות (dependency preserving) בהינתן F אם לכל קבוצת רלציות {r1,…,rn} (מעל הסכמות {R1,…,Rn} בהתאמה) כך ש-ri ⊧ πRiF לכל i = 1,…,n מתקיים ⋈ ni=1 ri ⊧ F. הגדרה שקולה: ρ הוא משמר תלויות בהינתן F אם F ⊆ (⋃ni =1 πRiF)+ אינטואיטיבית: תלות פונקציונלית f נשמרת בפירוק אם קיימת תת-סכמה שמכילה את כל האטריביוטים המופיעים ב- f, או אם ניתן להסיק את f מתוך תלויות אחרות שנשמרות בפירוק. אביב-תשס"ז 236363 - DBMS, Design

אלגוריתם לבדיקת שימור תלויות בהינתן סכמה R, קבוצת תלויות פונקציונליות F ופירוק ρ = {R1, …,Rn}, האלגוריתם הבא בודק האם ρ משמר תלויות: For each f = ( Xf → Yf) in F do Zf ← Xf Repeat For i = 1 to n do Zf ← Zf ⋃ ((Zf ∪ Ri)+F ∪ Ri) Until no more changes to Zf ρ is dependency-preserving iff Yf ⊆ Zf for every f in F. אינטואיציה: לכל תלות Xf → Yf, נבנה מעין "סגור" של Xf, באמצעות תלויות שכבר הראינו שהן נשמרות בפירוק, ונבדוק האם Yf מוכל בו. אביב-תשס"ז 236363 - DBMS, Design

אלגוריתם לבדיקת שימור תלויות – דוגמה בפירוק {(עיר, קדומת) R2, (עיר, טלפון){R1 = ρ , התלות עיר →(טלפון, קדומת) = f אינה נשמרת: {טלפון, קדומת} = Zf דוגמה: נתונה הסכמה R(A, B, C, D), קבוצת תלויות F = {A → B, AC → D, BC → D}. האם הפירוק ρ = {R1(A, B), R2(B, C, D)} משמר תלויות? נבדוק לכל תלות האם היא נשמרת בפירוק. התלות A → B נשמרת כי AB ⊆ R1, התלות BC → D נשמרות כי BCD ⊆ R2 נותר לוודא שהתלות AC → D נשמרת (לפי האלגוריתם): אביב-תשס"ז 236363 - DBMS, Design

אלגוריתם לבדיקת שימור תלויות – דוגמה Zf ← {A,C} Zf ← {A,C}⋃( ({A,C}∪R1)+F ∪ R1) = {A,C} ⋃ ({A}+F ∪ {A,B}) = {A,C} ⋃({A,B}∪ {A,B}) = {A,B,C} Zf ← {A,B,C}⋃( ({A,B,C}∪R2)+F ∪ R2) = {A,B,C} ⋃( ({B,C}+F ∪ {B,C,D}) = {A,B,C} ⋃({B,C,D}∪ {B,C,D}) = {A,B,C,D} קיבלנו כי {D} = Yf ⊆ Zf ={A,B,C,D}לכן התלות AC→D נשמרת בפירוק. אביב-תשס"ז 236363 - DBMS, Design

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

BCNF לעומת שימור תלויות קריטריון לבחירה: אופן השימוש הצפוי במסד הנתונים: הרבה עדכונים של שדה עם כפילויות בסכמה המקורית (החלפת קידומת של עיר) ⇐ פירוק ל-BCNF (מונע כפילויות): (עיר, קידומת)R2,(עיר, טלפון)R1. הרבה הוספות/עדכונים של שדות המופיעים בתלות שלא נשמרת בפירוק (למשל, מס' טלפון) ⇐ ללא פירוק (שימור תלויות): (עיר, קידומת, טלפון)R אלטרנטיבה אחרת: צורה נורמלית 3NF אביב-תשס"ז 236363 - DBMS, Design

צורה נורמלית שלישית - 3NF הגדרה: תהי R סכמה רלציונית ותהי F קבוצת תלויות פונקציונליות מעל R. R היא ב-3NF בהינתן F אם לכל תלות פונקציונלית לא טריוויאלית X → A∈F+ מתקיים או ש-X הינו על-מפתח או ש-A שייך למפתח קביל של R,F. משפט: תהי F קבוצת תלויות פונקציונאליות שכולן בעלות אטריביוט אחד בצד ימין. אם סכמה רלציונית R,F איננה ב-3NF, כלומר קיימת תלותX→A∈ F+ שמפרה את תנאי ה-3NF, אזי קיימת תלות Y→B∈ F שמפרה את תנאי ה-3NF. אביב-תשס"ז 236363 - DBMS, Design

איך נבדוק שהסכמה ב-3NF? על פי המשפט: אם F לא מהצורה הנדרשת, ניצורF' כך ש- F'= { X → A | X → Y ∈ F  A ∈ Y} עבור כלX→A∈ F’ נבדוק כי X הינו על-מפתח או ש-A מוכל במפתח קביל של R,F. אם אין תלות ב-F’ המפרה את 3NF, נסיק כי R,F נמצאת ב-3NF. שאלה: מדוע היותה של R,F’ ב-3NF מבטיח כי גם R,F ב-3NF? אביב-תשס"ז 236363 - DBMS, Design

דוגמה הסכמה (עיר, קידומת, טלפון) R בהינתן התלויות הפונקציונליות: F = {עיר →קידומת, (קידומת, טלפון) →עיר} נמצאת ב-.3NF הסיבה: המפתחות הקבילים של הסכמה הם (עיר, טלפון) ו- (קידומת,טלפון). כל תלות מתוך F מקיימת את תנאי ה-3NF. לפי המשפט מספיק לבדוק רק את התלויות של F. אביב-תשס"ז 236363 - DBMS, Design

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

אלגוריתם לפירוק סכמה R ל-3NF אם קיימת ב-F תלות פונקציונלית שכוללת את כל התכונות ב-R, התשובה היא {R} - עצור. לכל קבוצת תלויות פונקציונליות X → An X → A2,…, X → A1, התלויות באותו X, צור סכמה } X ⋃ { A1A2 ...An. אם אין אף סכמה המכילה מפתח קביל של R, הוסף סכמה שהיא מפתח קביל כלשהו של R. הפירוק שאלגוריתם זה מוצא הוא משמר מידע ותלויות. אביב-תשס"ז 236363 - DBMS, Design

פירוק ל-3NF – דוגמה דוגמה: נתון: R1(dname, daddr) R(dname, daddr, id, pname, paddr, pres_no, date, med_name, qnt) F = {dname → daddr, id → pname, id → paddr, id → dname, pres_no → date, pres_no → id, (pres_no, med_name) → qnt} לא קיימת ב-F תלות פונקציונלית המכילה את כל התכונות ב-R. ניצור סכמות לפי התלויות הפונקציונליות: R1(dname, daddr) R2(id, pname, paddr, dname) R3(pres_no, date, id) R4(pres_no, med_name, qnt) R4 כוללת את המפתח הקביל (pres_no, med_name), ולכן אין צורך להוסיף עוד סכמה. אביב-תשס"ז 236363 - DBMS, Design