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