データベースのACIDプロパティについて読んでいます。原子性と一貫性は非常に密接に関連しているようです。Atomicityをサポートするだけで、Consistencyをサポートする必要がない、またはその逆のシナリオがあるかどうか疑問に思います。例は本当に役に立ちます！
6414 次
5 に答える
23
それらは多少関連していますが、微妙な違いがあります。
原子性とは、トランザクションが発生するか発生しないかを意味します。
一貫性とは、参照整合性などが強制されることを意味します。
トランザクションを開始して 2 つの行 (単一の銀行トランザクションを形成するクレジットとデビット) を追加するとします。この原子性は、データベースの一貫性とは何の関係もありません。つまり、両方の行が追加されるか、どちらの行も追加されないということです。
orders一貫性の面で、外部キー制約 from toがあるとしましょうproducts。存在しない製品を参照する注文を追加しようとすると、それを防ぐために一貫性が発生します。
どちらもデータベースを実行可能な状態に維持することに関するものであるため、類似点があります。前者の例では、銀行がお金を失う (または盗む) ことがないようにします。後者の場合は、何も知らない製品の注文にアプリケーションが驚かないようにします。
于 2010-09-29T05:33:56.687 に答える
9
原子性:
アトミック トランザクションでは、一連のデータベース操作がすべて発生するか、何も発生しません。原子性が保証されているため、データベースへの更新が部分的にしか行われないため、シリーズ全体を完全に拒否するよりも大きな問題が発生する可能性があります。
一貫性：
データベース システムでは、一貫性のあるトランザクションとは、実行中に整合性制約に違反しないトランザクションです。トランザクションがデータベースを不正な状態のままにした場合、トランザクションは中止され、エラーが報告されます
原子性をサポートするが一貫性をサポートしないデータベースでは、トランザクションが正常に完了した場合、データベースを一貫性のない状態にする (つまり、参照またはその他の整合性チェックに違反する) トランザクションを許可します。たとえば、これを実行するトランザクションが正常に完了した場合、文字列を int 列に追加できます。
逆に、一貫性をサポートするがアトミック性をサポートしないデータベースでは、トランザクションの影響によって整合性チェックが中断されない限り (たとえば、外部キーが既存の ID と一致する必要がある)、部分的なトランザクションを完了できます。たとえば、string 値と int 値を含む新しい行を追加してみることができます。挿入が途中で失敗してデータの半分が失われたとしても、失われたデータが必要な列のものではなく、データがない場合は行が許可されます。が間違って入力された列に挿入されました。
そうは言っても、一貫性は、一貫性のないトランザクションを元に戻すための原子性に依存しています。
于 2010-09-29T05:35:17.823 に答える
2
確かに原子性と一貫性の間には強い関係がありますが、同じではありません。
DBMS は (理論的には) 一貫性をサポートできますが、アトミシティはサポートできません。たとえば、SQL 操作 O1、O2、および O3 で構成されるトランザクションを考えてみましょう。ここで、O1 と O2 の後、DB はすでに一貫した状態になっているとします。その後、DBMS は、O3 なしで O1 および O2 の後にトランザクションを停止でき、それでも一貫性を維持できます。明らかに、そのような DBMS はアトミック性をサポートしていません (O3 は O1 によって実行されず、O2 は実行されたため)。
DBMS は (理論的には) 一貫性ではなくアトミシティをサポートできます。これは、マルチユーザー シナリオで発生する可能性があります。この場合、アトミシティは、トランザクションのすべてのアクションが実行される (またはいずれも実行されない) ことのみを保証しますが、1 つのアクションが実行されることは保証しません。別のトランザクションと同時に行われたトランザクションは、一貫性のない状態になることはありません。
ただし、私が信じていること (正式には証明されていません) は、DMBS が原子性と分離の両方を保証する場合、一貫性も保証する必要があるということです。
于 2016-12-26T09:30:36.800 に答える
0
原子性と一貫性について読んでいるときにも混乱していました。account テーブルに 1000 レコードのバッチ挿入を行うシナリオがあるとします。
バッチの原子性は、1000 レコードすべてが挿入される場合、またはエラーが発生した場合にレコードがまったく挿入されない場合です。
アカウント レコード レベルで、データ型が一致しない場合でも挿入を成功させるロジックを配置し、関連するレコードが外部キー テーブルに挿入され、成功したアカウント レコードの後に削除された場合、バッチの一貫性が損なわれます。アップデート。
この例で混乱が解消されることを願っています。
于 2016-03-30T15:17:32.400 に答える
0
ACID コンテキストでの一貫性について、私は別の理解を持っています。
トランザクション内で、特定のデータ項目が取得され、同じトランザクション内で後で再度取得された場合、変更は見られません。つまり、トランザクション全体を通じて、データベースの一貫した状態がトランザクションに与えられます。トランザクションに表示されるデータを変更できる唯一の更新は、トランザクション自体によって行われる更新です。
私の考えでは、これは直列化可能性と同じです。
于 2010-09-29T17:38:50.547 に答える