מודל מסד נתונים יחסי: אלמנטים, איך לעשות זאת, דוגמה - טֶכנוֹלוֹגִיָה - 2025

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

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

מקור: pixabay.com

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

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

ניהול מסדי נתונים

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

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

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

מרבית בסיסי הנתונים ההתייחסותיים משתמשים בשפת SQL לצורך שאילתת נתונים והגדרתם. נכון לעכשיו קיימות מערכות רבות לניהול בסיסי נתונים של מערכות יחסים או RDBMS (מערכת ניהול יחסי נתונים רציונליים), כגון Oracle, IBM DB2 ו- Microsoft SQL Server.

תכונות ואלמנטים

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

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

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

-אלמנטים

באיור שלהלן מופיעה טבלה עם שמות האלמנטים הבסיסיים המרכיבים מבנה שלם.

טיפל

כל שורת נתונים היא טיפוס, המכונה גם רשומה. כל שורה היא t-tule, אך בדרך כלל "n-" מושלך.

טור

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

מַפְתֵחַ

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

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

כללי שלמות

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

שלמות מפתח

המפתח העיקרי חייב להיות ייחודי לכל הגפיים ולא יכול להיות בטל (NULL). אחרת לא תוכל לזהות את השורה באופן ייחודי.

עבור מפתח מרובה עמודות, אף אחת מהעמודות לא יכולה להכיל NULL.

שלמות קשרים

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

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

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

כיצד ליצור מודל יחסי?

-איסוף מידע

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

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

- הגדר מפתחות ראשוניים

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

- ליצור קשרים בין טבלאות

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

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

אחד לרבים

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

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

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

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

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

עיצוב שני שולחנות

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

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

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

עבור כל ערך Master_Id בטבלת המאסטר, יכולות להיות שורות אפס או יותר בטבלת המחלקות. עבור כל ערך Class_Id בטבלת המחלקות, יש רק שורה אחת בטבלת המורים.

רבים לרבים

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

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

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

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

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

עבור הטבלה OrderDetails, המפתח הראשי מורכב משתי עמודות: OrderID ו- ProductID, תוך זיהוי ייחודי של כל שורה.

העמודות OrderID ו- ProductID בטבלת OrderDetails משמשות להפניה לטבלאות הזמנות ומוצרים. לכן הם גם מפתחות זרים בטבלת OrderDetails.

אחד אחד

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

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

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

יתרון

עצמאות מבנית

במודל בסיס הנתונים היחסי, שינויים במבנה בסיס הנתונים אינם משפיעים על הגישה לנתונים.

כאשר ניתן לבצע שינויים במבנה בסיס הנתונים מבלי להשפיע על היכולת של ה- DBMS לגשת לנתונים, ניתן לומר כי הושגה עצמאות מבנית.

פשטות רעיונית

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

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

קלות תכנון, יישום, תחזוקה ושימוש

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

קיבולת שאילתה אד-הוק

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

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

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

חסרונות

הוצאות חומרה

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

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

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

קלות עיצוב יכולה להוביל לעיצוב לקוי

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

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

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

תופעה של «איי מידע»

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

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

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

דוגמא

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

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

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

הקשר בין טבלאות החלקים והמשלוחים ניתן על ידי משותף של שדה PNo (מספר חלק) והקשר בין ספקים ומשלוחים נוצר על ידי משותף של שדה SNo (מספר ספק).

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

באופן דומה, 1,100 ברגים בסך הכל נשלחו משלושה ספקים שונים. 500 ברגים כחולים נשלחו מספק הסונטה. אין משלוחים של ברגים אדומים.

הפניות

1. ויקיפדיה, האינציקלופדיה החופשית (2019). מודל יחסי. נלקח מ: en.wikipedia.org.
2. Techopedia (2019). מודל יחסי. לקוח מ: ceilingpedia.com.
3. דינש תאקור (2019). מודל יחסי. הערות מחשב אלקטרוני. נלקח מ: ecomputernotes.com.
4. Geeks for Geeks (2019). מודל יחסי. נלקח מ: geeksforgeeks.org.
5. האוניברסיטה הטכנולוגית של נניאנג (2019). מדריך להתחלה מהירה בנושא עיצוב מסדי נתונים יחסי. לקוח מ: ntu.edu.sg.
6. אדריאן וואט (2019). פרק 7 מודל הנתונים היחסי. ספרי לימוד פתוחים לפני הספירה. לקוח מ: opentextbc.ca.
7. Toppr (2019). מאגרי מידע וסכמות יחסים. נלקח מ: toppr.com.