حامض

Transactions are often composed of multiple statements. Atomicity guarantees that each transaction is treated as a single "unit", which either succeeds completely or fails completely: if any of the statements constituting a transaction fails to complete, the entire transaction fails and the database is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors, and crashes.^[6] A guarantee of atomicity prevents updates to the database from occurring only partially, which can cause greater problems than rejecting the whole series outright. As a consequence, the transaction cannot be observed to be in progress by another database client. At one moment in time, it has not yet happened, and at the next, it has already occurred in whole (or nothing happened if the transaction was cancelled in progress).

Consistency ensures that a transaction can only bring the database from one consistent state to another, preserving database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction. An example of a database invariant is referential integrity, which guarantees the primary key–foreign key relationship.^[7]

Transactions are often executed concurrently (e.g., multiple transactions reading and writing to a table at the same time). Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially. Isolation is the main goal of concurrency control; depending on the isolation level used, the effects of an incomplete transaction might not be visible to other transactions.^[8]

Durability guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure (e.g., power outage or crash). This usually means that completed transactions (or their effects) are recorded in non-volatile memory.^[9]

الذرية هي ضمانة أن سلسلة عمليات قاعدة البيانات في معاملة ذرية ستُنفذ جميعها (عملية ناجحة)، أو لن تُنفذ أي منها (عملية فاشلة). لا يمكن فصل سلسلة العمليات بحيث يُنفذ جزء منها فقط، مما يجعلها "غير قابلة للتجزئة". يضمن مبدأ الذرية عدم إمكانية تحديث قاعدة البيانات جزئيًا، وهو ما قد يُسبب مشاكل أكبر من رفض السلسلة بأكملها. بعبارة أخرى، الذرية تعني عدم قابلية التجزئة وعدم قابلية الاختزال. ^{[ 10 ]} وبعبارة أخرى، يمكن القول إن المعاملة المنطقية قد تتكون من عدة معاملات فيزيائية. ولن تُعتبر المعاملة المنطقية قد تمت إلا بعد تنفيذ جميع المعاملات الفيزيائية المكونة لها.

من أمثلة المعاملات الذرية تحويل الأموال من الحساب المصرفي (أ) إلى الحساب (ب). تتكون هذه المعاملة من عمليتين: سحب الأموال من الحساب (أ) وإيداعها في الحساب (ب). لا نرغب برؤية المبلغ المسحوب من الحساب (أ) قبل التأكد من تحويله إلى الحساب (ب). يضمن تنفيذ هاتين العمليتين في معاملة ذرية بقاء قاعدة البيانات في حالة متسقة ، أي لا يتم خصم الأموال أو إضافتها إذا فشلت أي من هاتين العمليتين. ^{[ 11 ]}

الاتساق مصطلح عام جدًا، ويشترط أن تستوفي البيانات جميع قواعد التحقق. في المثال السابق، كان التحقق هو أن يكون مجموع A و B يساوي 100. يجب فحص جميع قواعد التحقق لضمان الاتساق. لنفترض أن عملية ما تحاول طرح 10 من A دون تغيير B. نظرًا لفحص الاتساق بعد كل عملية، فمن المعروف أن A + B = 100 قبل بدء العملية. إذا نجحت العملية في طرح 10 من A ، فسيتم تحقيق الذرية. مع ذلك، سيُظهر فحص التحقق أن A + B = 90 ، وهو ما يتعارض مع قواعد قاعدة البيانات. يجب إلغاء العملية بالكامل وإعادة الصفوف المتأثرة إلى حالتها قبل العملية. لو كانت هناك قيود أو محفزات أو تسلسلات أخرى، لكان تم فحص كل عملية تغيير بنفس الطريقة المذكورة أعلاه قبل إتمام العملية. قد تنشأ مشكلات مماثلة مع قيود أخرى. على سبيل المثال، قد نشترط أن تكون أنواع بيانات كل من A و B أعدادًا صحيحة. إذا أدخلنا، على سبيل المثال، القيمة 13.5 للمتغير A ، فسيتم إلغاء العملية، أو قد يُصدر النظام تنبيهًا على شكل مُشغّل (إذا كان هذا المُشغّل مُعدًا لهذا الغرض). مثال آخر هو قيود التكامل، التي لا تسمح لنا بحذف صف في جدول ما إذا كان مفتاحه الأساسي مُشارًا إليه بواسطة مفتاح خارجي واحد على الأقل في جداول أخرى.

لإثبات العزل، نفترض أن عمليتين تُنفذان في الوقت نفسه، وتحاول كل منهما تعديل البيانات نفسها. يجب على إحدى العمليتين الانتظار حتى تكتمل الأخرى للحفاظ على العزل.

لنفترض وجود معاملتين:

• ينقل T ₁ الرقم 10 من A إلى B.
• ينقل T ₂ الرقم 20 من B إلى A.

بمجموعها، هناك أربعة إجراءات:

1. T ₁ يطرح 10 من A.
2. T ₁ يضيف 10 إلى B.
3. T ₂ يطرح 20 من B.
4. T ₂ يضيف 20 إلى A.

إذا نُفذت هذه العمليات بالتسلسل، يُحافظ على العزل، مع أن العملية T2 _يجب أن تنتظر. تخيّل ماذا يحدث إذا فشلت العملية T1 _في منتصفها. ستتخلص قاعدة البيانات من آثار T1، ولن ترى T2 _سوى البيانات الصحيحة _.

من خلال دمج المعاملات، قد يكون الترتيب الفعلي للإجراءات كما يلي:

1. T ₁ يطرح 10 من A.
2. T ₂ يطرح 20 من B.
3. T ₂ يضيف 20 إلى A.
4. T ₁ يضيف 10 إلى B.

مرة أخرى، لنفترض أن العملية T1 _فشلت أثناء تعديل الحقل B في الخطوة 4. عند فشل T1، تكون العملية T2 _{قد عدّلت} الحقل A بالفعل؛ ولا يمكن استعادته إلى قيمته السابقة قبل T1 _دون ترك قاعدة بيانات غير صالحة. يُعرف هذا بتنازع الكتابة المتبادلة ^{[ 12 ]،} لأن عمليتين حاولتا الكتابة إلى نفس حقل البيانات. في نظام نموذجي، تُحل المشكلة بالعودة إلى آخر حالة سليمة معروفة، وإلغاء العملية الفاشلة T1 _، وإعادة تشغيل العملية المتوقفة T2 _من الحالة السليمة.

لنفترض عملية نقل بيانات بقيمة 10 من الجهاز A إلى الجهاز B. أولًا، يتم حذف 10 من A، ثم يتم إضافة 10 إلى B. عند هذه النقطة، يُبلغ المستخدم بنجاح العملية. مع ذلك، تبقى التغييرات مخزنة مؤقتًا في القرص بانتظار حفظها. ينقطع التيار الكهربائي وتُفقد التغييرات، لكن المستخدم يفترض (بشكل مفهوم) أنها ستبقى محفوظة.

تعتمد العديد من قواعد البيانات على التأمين لتوفير خصائص ACID. يعني التأمين أن العملية تُعلّم البيانات التي تصل إليها، بحيث يعرف نظام إدارة قواعد البيانات أنه لا يسمح للعمليات الأخرى بتعديلها حتى تنجح العملية الأولى أو تفشل. يجب الحصول على التأمين دائمًا قبل معالجة البيانات، بما في ذلك البيانات التي تُقرأ دون تعديل. تتطلب العمليات المعقدة عادةً عددًا كبيرًا من التأمينات، مما يؤدي إلى زيادة كبيرة في الحمل الزائد، بالإضافة إلى حظر العمليات الأخرى. على سبيل المثال، إذا كان المستخدم (أ) يُشغّل عملية قراءة صف من البيانات التي يريد المستخدم (ب) تعديلها، فيجب على المستخدم (ب) الانتظار حتى تكتمل عملية المستخدم (أ). غالبًا ما يُطبّق التأمين ثنائي المرحلة لضمان العزل الكامل.

يُعدّ التحكم في التزامن متعدد الإصدارات بديلاً عن التأمين ، حيث تُزوّد ​​قاعدة البيانات كل عملية قراءة بالنسخة السابقة غير المُعدّلة من البيانات التي تُعدّلها عملية نشطة أخرى. يسمح هذا للقراء بالعمل دون الحاجة إلى تأمين، أي أن عمليات الكتابة لا تُعيق عمليات القراءة، والقراء لا يُعيقون عمليات الكتابة. بالعودة إلى المثال، عندما تطلب معاملة المستخدم (أ) بيانات يُعدّلها المستخدم (ب)، تُزوّد ​​قاعدة البيانات (أ) بنسخة تلك البيانات التي كانت موجودة عندما بدأ المستخدم (ب) معاملته. يحصل المستخدم (أ) على رؤية متسقة لقاعدة البيانات حتى لو كان مستخدمون آخرون يُغيّرون البيانات. يُخفّف أحد التطبيقات، وهو عزل اللقطة ، من خاصية العزل.

يُضيف ضمان خصائص ACID في المعاملات الموزعة عبر قواعد البيانات الموزعة ، حيث لا تتحمل أي عقدة مسؤولية جميع البيانات المؤثرة على المعاملة، تعقيدات إضافية. فقد تتعطل اتصالات الشبكة، أو قد تُكمل إحدى العقد بنجاح جزءها من المعاملة ثم تُضطر إلى التراجع عن تغييراتها بسبب عطل في عقدة أخرى. يوفر بروتوكول الالتزام ثنائي المرحلة (لا يُخلط بينه وبين القفل ثنائي المرحلة ) خاصية الذرية للمعاملات الموزعة لضمان موافقة كل مشارك في المعاملة على ما إذا كان ينبغي الالتزام بها أم لا. ^{[ 13 ]} باختصار، في المرحلة الأولى، تستعلم إحدى العقد (المنسق) من العقد الأخرى (المشاركين)، وعندما تُجيب جميعها بأنها جاهزة، يقوم المنسق، في المرحلة الثانية، بإضفاء الطابع الرسمي على المعاملة.