מהי הצורה השלישית הרגילה? (מאגרי מידע) - טֶכנוֹלוֹגִיָה - 2025

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

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

מקור: pixabay.com

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

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

זה מתחיל בבחינת הקשר התפקודי או התלות בין התכונות. אלה מתארים מאפיין כלשהו של הנתונים או את הקשר ביניהם.

צורות רגילות

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

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

צורה נורמלית ראשונה (1FN)

אומרים שטבלה נמצאת ב- 1FN אם כל התכונות או השדות בתוכה מכילים רק ערכים ייחודיים. כלומר, כל ערך לכל תכונה חייב להיות בלתי ניתן לחלוקה.

בהגדרה, מסד נתונים יחסי תמיד יהיה מנורמל לצורה הרגילה הראשונה, מכיוון שערכי התכונה הם תמיד אטומיים. כל מערכות היחסים בבסיס הנתונים נמצאות ב- 1FN.

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

צורה נורמלית שנייה (2FN)

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

מאפיין שאינו מפתח הוא כל תכונה שאינה חלק מהמפתח העיקרי לזוגיות.

צורה נורמלית שלישית (3FN)

זה עוסק בחיסול תלות טרנזיטיביות מהטבלה. כלומר, הסר את התכונות שאינן מפתחות שאינן תלויות במפתח הראשי, אלא בתכונה אחרת.

תלות מעבר היא סוג של תלות פונקציונלית שבה הערך של שדה או תכונה שאינם מפתח נקבע על פי הערך של שדה אחר שאף הוא אינו מפתח.

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

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

לפיכך, על מנת שמערכת יחסים במאגר תהיה במצב השלישי הרגיל, עליה לציית ל:

- כל הדרישות של 2FN.

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

דוגמאות לצורה נורמלית שלישית

דוגמא 1

תן לטבלה להיות STUDENT, שהמפתח העיקרי שלה הוא הזיהוי של התלמיד (STUDENT_ID) והוא מורכב מהתכונות הבאות: STUDENT_NAME, STREET, CITY ו- POST_CODE, תוך מילוי התנאים להיות 2FN.

במקרה זה, ל- STREET ו- CITY אין קשר ישיר עם המפתח הראשי STUDENT_ID, מכיוון שהם אינם קשורים ישירות לתלמיד, אך הם תלויים לחלוטין במיקוד המיקוד.

מכיוון שהתלמיד נמצא באתר שנקבע על ידי CODE_POSTAL, STREET ו- CITY קשורים לתכונה זו. בשל תואר שני זה של תלות, אין הכרח לאחסן תכונות אלה בטבלת הסטודנטים.

צור טבלה חדשה

נניח שישנם סטודנטים מרובים שנמצאים באותו מיקוד, כאשר בטבלת הסטודנטים יש כמות אדירה של רשומות, והיא נדרשת לשנות את שם הרחוב או העיר, אז יש למצוא את הרחוב או העיר הזו ולעדכן בטבלה כולה. סטוּדֶנט.

לדוגמה, אם אתה צריך לשנות את הרחוב "El Limón" ל- "El Limón II", תצטרך לחפש את "El Limón" בכל טבלת הסטודנטים ואז לעדכן אותו ל "El Limón II".

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

במקום זאת, ניתן לשמור את הפרטים האלה בטבלה נפרדת (POSTCARD) הקשורה לטבלת ה- STUDENT באמצעות התכונה POST_CODE.

לטבלת POST יהיו פחות רשומות יחסית וטבלת POST זו תצטרך לעדכן רק פעם אחת. זה יבוא לידי ביטוי באופן אוטומטי בטבלת ה- STUDENT, ופשט את בסיס הנתונים והשאילתות. אז הטבלאות יהיו ב- 3FN:

דוגמא 2

אפשר לטבלה הבאה להשתמש בשדה Project_Num כמפתח הראשי ועם ערכים חוזרים ונשנים בתכונות שאינן מפתחות.

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

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

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

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

הפניות

1. Teradata (2019). טפסים ראשונים, שני ושלישי רגילים. נלקח מ: docs.teradata.com.
2. גביע ההדרכה (2019). טופס רגיל שלישי (3NF). נלקח מ: tutorialcup.com.
3. מאגר מסדי נתונים (2015). טופס רגיל שלישי (3NF) - נורמליזציה של מסד הנתונים. נלקח מ: databasedev.co.uk.
4. עיצוב יחסי DB (2019). מבוא לטופס הרגיל השלישי. נלקח מ: relationaldbdesign.com.
5. בובות (2019). SQL טפסים ראשונים, שני ושלישי רגילים. נלקח מ: dummies.com.