- Conflict: 同じデータアイテムに対する、write-write,write-read, read-writeのいずれかの関係を持つ、2つの異なる[[トランザクション]]の関係 - CSR: 競合の仕方が同じSerial historyが存在するhistoryの集合 - Conflict graph: Txをノード、Conflictをエッジとしたグラフ - 非巡回 => [[Conflict Serializable|CSR]] - [[Serializable]] scheduleの真部分集合 - [[Serializable, CSR, VSR, MVSR, FSRの関係]] - [[2PL]]が生成するスケジュールがこれ # Conflict 2つのトランザクションが同じデータアイテムにアクセスし、異なるモードのロックを取得している場合をConflictという Conflictしている操作同士は、絶対に実行の順番を入れ替えてはいけない # トランザクションの先行関係 トランザクション$T_1$がアイテム$Q$に対してモード$A$のLockを取得し、その後別のトランザクション$T_j$が$Q$に対してモード$B$のロックを取得したとする。モード$A$とモード$B$が排他で、これらの操作がConflictしている場合、$T_i$は$T_j$に先行([[precedes]])する（$T_i \rightarrow T_j$）と定義する $T_i \rightarrow T_j$の場合、いかなる[[Serializable]]なスケジュールにおいても、必ず$T_i$のあとに$T_j$を実行した結果と等価でないといけない。 # Conflict Serializableなプロトコル Conflict Serializable: precedes graphに閉路がない ある[[Locking protocol]]がConflict Serializabilityを保証するといえるのは、そのプロトコルのルールに沿って生成される全てのスケジュール（[[legal schedule]]）が、Conflict serializableである場合のみ。つまり先行関係のグラフに閉路ができていない、ということ。