3.1 ACIDの出現
ACID という略語は、 1983 年に Theo Haerder と Andreas Reuter による記事で初めて登場しました。文章を簡略化し、より説得力を持たせるために、この記事の一部を翻訳します（若干の縮小を加えて）。このスニペットでは、ある口座から別の口座に送金される銀行取引の例を使用しています。
$BEGIN_TRANSACTIONトランザクションの概念 (この例では、と の間のデータベースとのすべての対話が含まれます) では、すべての$COMMIT_TRANSACTIONアクションが不可分に実行されることが必要です。つまり、すべてのアクションがデータベースの状態に適切に反映されるか、何も起こらないかのどちらかです。ユーザーに連絡する前の任意の時点で、を含む$COMMIT_TRANSACTIONステートメントを入力した場合、変更はデータベースに反映されません。ERROR$RESTORE_TRANSACTION
この不可分性を実現するには、トランザクションに次の 4 つのプロパティが必要です。
アトミシティ（原子性）。トランザクションは上記の全か無かのタイプである必要があり、何が起こっても、ユーザーはトランザクションがどのような状態にあるのかを知らなければなりません。
一貫性（一貫性）。トランザクションは通常のトランザクション終了 (EOT) に達し、その結果をコミットしてデータベースの一貫性を維持します。つまり、成功したすべてのトランザクションは、定義上、有効な結果のみをコミットします。この条件は、4 番目の特性である耐久性をサポートするために必要です。
孤立（孤立）。トランザクション内で発生するイベントは、同時に実行されている他のトランザクションから隠蔽する必要があります。この条件が満たされない場合、上記の理由により、トランザクションを最初に戻すことは不可能になります。分離を実現するには、同期と呼ばれる方法が使用されます。
耐久性（耐久性）。トランザクションが完了し、その結果がデータベースにコミットされると、システムはそれらの結果が後続の障害に耐えられることを保証する必要があります。一連のトランザクションにまたがる制御範囲がないため、データベース管理システム (DBMS) はトランザクションの境界を越えて制御することはできません。
したがって、システムが何かが起こったことをユーザーに通知する場合、その「何か」は実際に起こったことをユーザーに保証する必要があります。定義上、（正常に完了した - S.K.）トランザクションは正しいため、必然的に現れる不正確なトランザクション（つまり、誤ったデータを含むトランザクション）の結果は、対応する「カウンター」トランザクション（カウンタートランザクション）によってのみ排除できます。
3.2 トランザクションの出現
これら 4 つのプロパティ (原子性、一貫性、分離性、耐久性 (ACID)) は、データベース システム設計の多くの側面に影響を与えるトランザクション パラダイムの中核機能を説明します。したがって、トランザクションをサポートするシステムの能力が、このシステムの品質の試金石 (ACID テスト) であると私たちは考えています。
ある口座から別の口座に資金を転送する単純な PL/1-SQL プログラム。
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */
このコードの例を示したのは、実際、ACID プロパティは、一方ではトランザクションをサポートすると主張する DBMS の要件として、他方では、トランザクションの定義として考えることができるということです。データベースシステム。この定義は、世俗的な慣習と完全に一致しています。たとえば、銀行取引を実行する顧客 (生身の窓口係の助けを借りて、またはインターネット バンキングを使用して) が、銀行が ACID のすべての特性を満たすことを期待していないことは想像しにくいです。取引で ACID プロパティをサポートしない銀行は、良くても顧客を失い、最悪の場合は破産することになります。
3.3 ACID 接続性
ACID プロパティが分離できないことが非常に重要であり、それらのいずれかを破棄すると、残りの組み合わせは無意味になります。特に、(上記の引用で使用された意味で) 一貫性プロパティを破棄すると、トランザクションの正確さの基準が失われます。データベース システムは、トランザクションのコミットを許可するかどうかを意味のある方法で決定することができず、データベースの現在の状態で実行される操作の正確性のチェックはすべてアプリケーション コードで実行する必要があります。
この場合、論理的な一貫性について話していることを理解する必要があります。銀行の顧客は、銀行が自ら確立し、顧客に知られているルールに従って機能することを必要とします。そのため、これらのルールに違反する取引を実行することは不可能であり、同じ顧客の次の取引は自動的に実行されます。これらの規則に従って環境が合意されました。
オンライン ストアの顧客は、注文して支払いを行った商品が (確立され、顧客に知られている) タイムリーに配達される必要があります。そうでないと彼はこの店を信用しないでしょう。同時に、銀行の顧客もインターネットストアの顧客も、企業の内部キッチン、つまり取引を完了するためにどのような内部アクションが取られるかについては気にしません。クライアントは、この企業の物理的な一貫性がどのように維持されるか、物理層で操作がどのように実行されるかなど気にしません。
DBMS がトランザクション (およびデータベース) の論理的一貫性の維持を担当する場合、アプリケーションはよりシンプルになり、より理解しやすく、より信頼性が高くなります。トランザクションに関するアプリケーション領域 (銀行、店舗、倉庫など) のすべてのロジックとデータの有効な状態は、データベース システムに入力されます。そして、このシステムの要件は非常に単純です。アプリケーションによってデータベースに提供される一貫性ルールを考慮した、ACID トランザクションのサポートです。私の観点からすると、ACID トランザクションの拒否は、アプリケーション開発者にとって大きな困難をもたらします。アプリケーション開発者は、好むと好まざるにかかわらず、顧客の当然のニーズを満たすために、同様のものを自分で実装する必要があります。
もう一度言いますが、実際には ACID プロパティがトランザクションの概念を定義します。私の意見では、トランザクションの一貫性という特性がサポートされていないトランザクション データ管理システムについて少なくともある程度の可能性を持たせるためには、この場合のトランザクションという用語が何を意味するのかを定義することが絶対に必要です。
残念ながら、今日では多くの場合 (特に、これは NoSQL の方向性の特徴です)、OLTP アプリケーションのサポートについて、それがどのような種類のトランザクションを意味するのかをまったく指定せずに話されています。したがって、この記事では、実際のトランザクションを指すために ACID トランザクションの組み合わせを使用し、非修飾用語トランザクションは、状況によって異なる非公式な意味で使用します。
ここで CAP の「定理」を扱い、Brewer の意味での一貫性が何を意味するかを理解してみましょう。
GO TO FULL VERSION