מדוע בסיסי נתונים והמודל היחסיות

המאמר ש-IBM לא רצה

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

הגישה המבוססת קבצים

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

שלוש תוכניות, שלושה העתקים של הלקוח

הגבולות

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

כיצד מסד נתונים יחסי עונה על כך

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

עותק אחד של הנתונים, שמרן אחד

המונחים: טבלאות, שורות ועמודות

• טבלה (יחס) היא רשת של שורות ועמודות; טבלה אחת עבור כל סוג של אובייקט, כלומר דבר עליו מאוחסנים נתונים: CUSTOMER, ORDER, PRODUCT.
• רשומה היא שורה אחת, כלומר instance אחת של האובייקט; המונח הרשמי הוא טופל.
• שדה הוא עמודה אחת, כלומר חלק מידע אחד על כל רשומה; המונח הרשמי הוא תכונה.

שורות הן רשומות, עמודות הן שדות, ועמודה אחת נמשכת לתוך הטבלה השנייה

המונחים: מקורות

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

CUSTOMER(CustomerID, Name, Phone)
ORDER(OrderID, CustomerID, OrderDate)   -- CustomerID is a foreign key → CUSTOMER

דוגמה פותרת: הזרם חלקים של מאגר נתונים של ספרייה

קשרים ושלימות הפניה

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

דוגמה פותרת: מה אינטגרציה ייחוסית מונעת

הגדרות שהבוחן מקבל

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

הבנתך מושלמת