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