חומצה מגינה על הנתונים של מסד הנתונים
מודל ACID של עיצוב מסד נתונים הוא אחד המושגים הוותיקים והחשובים ביותר של תיאוריית מסד הנתונים. היא קובעת ארבעה יעדים שכל מערכת ניהול מסדי נתונים חייבת לשאוף להשיג: אטומיות, עקביות, בידוד ועמידות. מסד נתונים יחסיים שאינו עומד בכל אחת מארבע המטרות הללו אינו יכול להיחשב אמין. מסד נתונים בעל מאפיינים אלה נחשב ACID תואם.
חומצה מוגדרת
בואו ניקח רגע כדי לבחון כל אחד מהמאפיינים האלה בפירוט:
- אטומית קובעת כי שינויים במסד הנתונים חייבים לפעול לפי כלל "הכל או לא כלום". כל עסקה אמורה להיות "אטומית". אם חלק אחד מהעסקה נכשל, העסקה כולה נכשלת. זה קריטי כי מערכת ניהול מסדי נתונים שומרת על אופי אטומי של עסקאות למרות כל DBMS, מערכת ההפעלה או כשל חומרה.
- עקביות קובע כי רק נתונים תקפים יירשמו למאגר. אם, מסיבה כלשהי, מתבצעת עסקה המפרה את כללי העקביות של מסד הנתונים, העסקה כולה תוחזר חזרה, ומסד הנתונים ישוחזר למצב המתאים לכללים אלה. מצד שני, אם ביצוע עסקה מוצלח, ייקח את מסד הנתונים ממדינה אחת, כי הוא עולה בקנה אחד עם הכללים למדינה אחרת, כי הוא גם בקנה אחד עם הכללים.
- בידוד דורש עסקאות מרובות המתרחשות באותו זמן לא להשפיע על ביצוע של זה. לדוגמה, אם ג 'ו בעיות עסקה נגד מסד נתונים באותו זמן כי מרי בעיות עסקה אחרת, הן עסקאות צריך לפעול על מסד הנתונים באופן מבודד. מסד הנתונים צריך לבצע את כל העסקה של ג 'ו לפני ביצוע של מרי, או להיפך. זה מונע את העסקה של ג'ו מקריאת נתונים ביניים המיוצרים כתוצר לוואי של חלק מהעסקה של מרי שלא תתחייב בסופו של דבר למסד הנתונים. שימו לב כי נכס הבידוד אינו מבטיח איזו עסקה תבוצע תחילה - רק שהעסקאות לא יפריעו זו לזו
- עמידות מבטיחה שכל עסקה שתבוצע למאגר לא תאבד. עמידות מובטחת באמצעות שימוש בגיבויים של מסדי נתונים וביומני עסקאות המאפשרים שחזור של עסקאות שבוצעו על אף כל כשל תוכנה או חומרה לאחר מכן.
איך חומצה עובד בפועל
מנהלי מסד נתונים משתמשים במספר אסטרטגיות לאכיפת ACID.
אחד המשמש לאכיפת אטומי ועמידות הוא רישום מראש רישום (WAL) שבו כל פרט העסקה הוא הראשון שנכתב יומן שכולל גם לעשות מחדש או לבטל מידע. זה מבטיח כי, נתון כשל מסד נתונים מכל סוג שהוא, מסד הנתונים יכול לבדוק את יומן ולהשוות את תוכנו למצב של מסד הנתונים.
שיטה נוספת המשמשת לטיפול באטומיות ועמידות היא הצללת צללים שבהם נוצר דף צל כאשר הנתונים ישונו. העדכונים של השאילתה נכתבים לדף הצל ולא לנתונים האמיתיים במסד הנתונים. מסד הנתונים עצמו משתנה רק כאשר העריכה הושלמה.
אסטרטגיה נוספת נקראת פרוטוקול ביצוע דו-שלבי , שימושי במיוחד במערכות נתונים מבוזרות. פרוטוקול זה מפריד בקשה לשינוי נתונים לשני שלבים: שלב להתחייב לבקשת שלב להתחייב. בשלב הבקשה, כל DBMS ברשת שהושפעו מהעסקה חייבים לאשר שהם קיבלו את זה ויש להם את היכולת לבצע את העסקה. לאחר קבלת אישור מכל DBMSs רלוונטיים, שלב התחייבות משלים שבו הנתונים הוא למעשה שונה.