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

2. איך נבדוק שהסכמה ב-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.
אביב-תשס"ז
DBMS, Design

3. 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 יחסית לתלויות הרלוונטיות לה (הגדרה מדויקת תינתן בהמשך).
אביב-תשס"ז
DBMS, Design

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

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

6. שימור מידע
הגדרה: תהי 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 שמקיים את התלויות אך מפר את התנאי של שימור מידע:
אביב-תשס"ז
DBMS, Design

7. דוגמה – המשך π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
אביב-תשס"ז
DBMS, Design

8. שימור מידע בפירוק לשתי סכמות
משפט: פירוק לשתי סכמות ρ = {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 ולכן, לפי המשפט, כן משמר מידע.
אביב-תשס"ז
DBMS, Design

9. פירוק ל-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.
אביב-תשס"ז
DBMS, Design

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

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

12. אלגוריתם יעיל למציאת כיסוי של π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, אלא כיסוי שלו (לאו דווקא מינימאלי).
אביב-תשס"ז
DBMS, Design

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

14. דוגמה - המשך
פירוק בשלבים: 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.
אביב-תשס"ז
DBMS, Design

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

16. פירוק ל-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 (ההגדרה מתקיימת באופן ריק).
ההערה רלוונטית לכל צורה נורמאלית.
אביב-תשס"ז
DBMS, Design

17. בדיקת קיום שימור מידע לכל תת-סכמה 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 שורה שהיא כולה ערכים ללא אינדקסים.
אביב-תשס"ז
DBMS, Design

18. דוגמה
דוגמה: נתונה הסכמה 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
אביב-תשס"ז
DBMS, Design

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

20. דוגמה נוספת מסקנה: הפירוק משמר מידע.
דוגמה: נתון 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
מסקנה: הפירוק משמר מידע.
אביב-תשס"ז
DBMS, Design

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

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

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

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

25. שימור תלויות – המשך
הגדרה: תהי 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 מתוך תלויות אחרות שנשמרות בפירוק.
אביב-תשס"ז
DBMS, Design

26. אלגוריתם לבדיקת שימור תלויות
בהינתן סכמה 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 מוכל בו.
אביב-תשס"ז
DBMS, Design

27. אלגוריתם לבדיקת שימור תלויות – דוגמה
בפירוק {(עיר, קדומת) 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 נשמרת (לפי האלגוריתם):
אביב-תשס"ז
DBMS, Design

28. אלגוריתם לבדיקת שימור תלויות – דוגמה
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 נשמרת בפירוק.
אביב-תשס"ז
DBMS, Design

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

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

31. צורה נורמלית שלישית - 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.
אביב-תשס"ז
DBMS, Design

32. איך נבדוק שהסכמה ב-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?
אביב-תשס"ז
DBMS, Design

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

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

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

36. פירוק ל-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), ולכן אין צורך להוסיף עוד סכמה.
אביב-תשס"ז
DBMS, Design