Database Management System

מה זה מערכת בסיסי נתונים?

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

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

מערכת בסיס נתונים מבוססת רלציות RDBMS

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

Transactions

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

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

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

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

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

Query

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

ומתרגים אותו ל:

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

רכיב האחסון בשרת

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

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

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

כאשר היוזר שולח שאילתות או פקודות מסוג DML ו-DDL, הפקודות נשלחות לצד השרת ועוברות תהליך של עיבוד בתוך Execution -לאחר שהן עוברות לפורמט איתו השרת יודע לעסוק פיזית, הן יוצאות לעבר ה .Optimizer או Compiler Engine עם Query Execution Plan, כלומר עם תרגום של אותה שאילתה אבסטרקטית אותה שלח המשתמש לרצף פקודות קונקרטי שנבקש לבצע על בסיס הנתונים )לולאות For, סינונים וכדומה(. בעצם יש מספר דרכים לתרגם שאילתה אחת לרצף פקודות מעשיות, ואחד התפקידים של ה-Optimizer הוא להכין תכנית ביצוע יעילה ככל הניתן. ה- Execution Engine תפקידו להוציא בפועל את ה-Plan ששלחה אליו, תוך שיקולים וניהול של טרנסקציות שאולי רוצות לרוץ ״במקביל״ וכמו כן ניהול נכון של מצבי קיצון כמו Crashes ו-Recovery אליהן בסיס הנתונים יכול להיכנס. פעולות מסוג זה מוזנות
גם הן ל-Execution Engine על ידי רכיב שנקרא ה-Transaction Manager, במקרים בהם היוזר שולח טרנזקציות שמורכבות ממספר פקודות רצופות או שקורה כלשהו מקרה קיצוני מצד היוזר. מתחת ל-Execution Engine יושב ה-Index / Record Manager שאחראי לקבל את הפקודות ולהשתמש בתכונות כמו אינדקסים שהזכרנו בקצרה מוקדם יותר בקורס על מנת לשלוף לאחר מכן את המידע מהזיכרון בצורה יותר יעילה.