מנרמל את מסד הנתונים: מעבר לטופס רגיל שני (2NF)

לשים מסד נתונים בטופס רגיל השני

במהלך החודש האחרון, בדקנו כמה היבטים של נורמליזציה של טבלת מסד נתונים. ראשית, דנו העקרונות הבסיסיים של נורמליזציה של מסד הנתונים. בפעם האחרונה, בחנו את הדרישות הבסיסיות שנקבעו על ידי הצורה הנורמלית הראשונה (1NF). עכשיו, בואו נמשיך את המסע שלנו לכסות את העקרונות של הצורה הנורמלית השנייה (2NF).

נזכיר את הדרישות הכלליות של 2NF:

כללים אלה ניתן לסכם בהצהרה פשוטה: 2NF מנסה לצמצם את כמות הנתונים מיותר בטבלה על ידי חילוץ אותו, הצבת אותו טבלאות חדשות ויצירת קשרים בין טבלאות אלה.

בואו נסתכל על דוגמה. תארו לעצמכם חנות מקוונת ששומרת מידע על לקוחות במסד נתונים. ייתכן שיש להם טבלה אחת בשם לקוחות עם האלמנטים הבאים:

מבט קצר על שולחן זה מגלה כמות קטנה של נתונים מיותרים. אנחנו שומרים את "ים קליף, ניו יורק 11579" ו "מיאמי, פלורידה 33157" ערכים פעמיים כל אחד. עכשיו, זה אולי לא נראה כמו אחסון מיותרים מדי בדוגמה הפשוטה שלנו, אבל לדמיין את החלל מבוזבז אם היו לנו אלפי שורות בטבלה שלנו. בנוסף, אם המיקוד עבור Sea Cliff היה לשנות, היינו צריכים לעשות את השינוי במקומות רבים ברחבי מסד הנתונים.

במבנה נתונים תואם 2NF, מידע זה מיותר מופק ומאוחסן בטבלה נפרדת. הטבלה החדשה שלנו (נקרא לזה ZIP) עשויה לכלול את השדות הבאים:

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

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

אנחנו כבר ממוזער את כמות המידע מיותרים המאוחסנים במסד הנתונים והמבנה שלנו הוא במצב נורמלי השני!

אם תרצה לוודא שמסד הנתונים שלך מנורמל, עיין במאמרים אחרים שלנו בסדרה זו: