מערך שיעור: עיצוב בסיס נתונים

משך: 2.5 שעות אקדמיות (113 דקות).

מטרת השיעור: הסטודנטים יתכננו סכמת DB מנורמלת עם PK/FK נכונים, לפני שנוגעים ב-EF Core כלל.

בסוף השיעור הסטודנטים צריכים: לזהות כפילות נתונים ולפרק אותה לטבלאות מנורמלות, להסביר PK/FK/CASCADE, ולדעת מתי Index משתלם.

דגש קריטי: זהו שיעור עיצוב לפני קוד — עודדו חשיבה על נייר/דיאגרמה לפני SQL, לא רק “כתבו CREATE TABLE”.

מהלך השיעור#

דגשים להעברת השיעור#

• זהו שיעור התיאוריה החשוב ביותר ביחידת ה-DB — אם הסטודנטים מבינים נורמליזציה ו-FK כאן, EF Core (השיעור הבא) יהיה הרבה יותר קל, כי הוא רק “ממפה” את מה שתוכנן כאן.
• דוגמת “עדכון מייל בכמה מקומות” היא ההוכחה הקונקרטית ביותר לנזק שנורמליזציה מונעת — הדגימו אותה בפועל אם אפשר (2 UPDATE שונים על אותו תלמיד, תוצאה סותרת).
• ON DELETE CASCADE ראוי לדיון פתוח, לא רק הסבר — יש כאן שיקול דעת עסקי אמיתי (מחיקת מחבר: למחוק פוסטים שלו, או לא?).

מושגים#

ER Model — תרשים ישויות וקשרים. Primary Key (PK) — מזהה שורה ייחודי. Foreign Key (FK) — עמודה שמצביעה ל-PK בטבלה אחרת. Normalization — כל עובדה מאוחסנת פעם אחת. Index — מאיץ חיפוש, מאט כתיבה.

תרגיל חשיבה#

שאלת פתיחה: “אם מוחקים מחבר בלוג, מה צריך לקרות לפוסטים שלו — למחוק אותם, לחסום את המחיקה, או להשאיר אותם עם ‘מחבר לא ידוע’? מה ההשלכות של כל אפשרות?”

מהלך: תנו לסטודנטים לדון בזוגות — אין תשובה “נכונה” אחת, זו החלטת עיצוב עסקית. הובילו לכך ששלוש האפשרויות קיימות בפועל ב-SQL: ON DELETE CASCADE (מחיקה), ON DELETE RESTRICT/ברירת מחדל (חסימה), ON DELETE SET NULL (השארה עם FK ריק).

מה המרצה מראה בסוף: הריצו שלושה תרחישי מחיקה שונים (עם שלושת סוגי ה-CASCADE) על אותה סכמה, והראו את התוצאה השונה בכל אחד — הפיכת הדיון התיאורטי להתנהגות ממשית וניתנת-לבדיקה.