serializableとconsistent state
このポストはpapa本読書会第1回目で読んだ部分のうちのconsistent stateについてのメモです。p.8くらいまでの範囲です。
このポストではpapa本は以下の本のことです。
大学の図書館においてあったりします。研究目的なら大学等に所属していなくても図書館を利用できることが多いです。
Model
database
databaseは、entityの集合*1。
entityの取る値は変化していくので、変数という理解でよいと思う。 構文上は、変数の値を見ている場合と識別子として見ている場合に特に区別がなかったので文脈で判断する。
不可分とか互いに疎とかの条件が付いている。
domain
entityごとに定義された、entityの取りうる値の集合*2。
基本的には、DBのカラムのデータ型の取りうる範囲という認識でよいと思うが、アプリケーションに応じてさらに範囲が制限されたもの（ユーザ定義型）を指している可能性もある。
しかし後述のように、上記の違いはDBにとっては重要でない。
database state
すべてのentityのdomainの直積。
databaseの観点での取りうる状態の集合。
integrity constraints
database stateの部分集合。
アプリケーションとして正しい状態の集合。
状態がこの部分集合に含まれるとき、 consistent という。
transaction
トランザクションの実行が完了すれば、（かつ実行前の状態がconsistentであれば）、完了後の状態もconsistentである（ようにアプリケーションが責任をもってトランザクションを発行する必要がある）。
serializable と consistent state
このモデルでは、データベースの状態がconsistentであるかどうかの責任はすべてアプリケーションプログラムにある。
DBMS側は、与えられたトランザクションのconcurrency controlについては責任を持つが、何が正しい状態かについての知識は持っていない。
つまり、DBMSが常にserializableなスケジューリングを行うことと、アプリケーションプログラムが常にconsistentな状態からconsistentな状態へ遷移するようなトランザクションだけを発行することの両輪によって、データベース状態の正しさを維持していくという、完全に役割を分担した（美しい）モデルである。
この世界では、DBMSはデータベース状態に対する任意の制約を保証する機能を提供する必要はない。
つまり制約、例えば一意性制約や外部参照制約、を保証する機能をDBMSが提供しなくても、（スケジュールがserializableなら）アプリケーションプログラムはそれを自分で保証することができる。
DBMSが制約を提供する理由
しかし今の巷のDBMSは制約を保証する機能を持っているが、これは以下の理由ではないかと想像する。
- serializable分離レベルを提供していない、もしくは実用的でない
- アプリケーションプログラムで制約を保証することが可能だが、DBMSで行ったほうが実行効率が良い
- 一般的な制約（一意性等）を保証するためのロジックが共通になる結果、アプリケーションプログラムの共通機能がDBMS側にストアされるようになった
serializable分離レベルが実用的で当たり前の世界になった場合
上記の理由が正しければ、serializableが当たり前になったとしても、すべての制約の責任をアプリケーションが持つ世界には戻らなさそう。 （一度DBMSが面倒見てくれた仕事をアプリケーションは引き受けないのではないか）
所感
私は情報系DBをやっていたので、serializableの実現が厳しいならもう少し分離レベルを緩くすればいい、くらいの認識でしたが、アプリケーションとDBMSのきれいな役割分離を見て、serializableは良いものだなという思いがインクリメントされました。
制約については、正しい状態を保つことをもっとDBMSががんばったほうが良いのではと思っていたことがありましたが、そもそも理論上はすべてアプリケーションの責任だった（DBMSはアプリケーションロジックをすべて理解できないという位置に立っていた）ということで、がんばらなくてよいのだなと納得しました。
