1. はじめに

 ビュー（view）はリレーショナルデータベースの始祖コッド（E.F. Codd）がリレーショナルデータモデル[1]を世に問うてから 4 年後の 1974 年に彼自身により導入されました[2]．ビューは定義だけが存在し実体は伴わない仮想的なリレーションであるところがデータベースに格納されているリレーション，これを実リレーション（stored relation）という，と根本的に異なるところです．

 ビューは質問変形（query modification）と呼ばれる手法[3]により，ビューに対するいかなる「質問」（query，問合せ）も常に実行可能です．これは理論でも実践（=SQL）でもその通りです．つまり，ビューへの問合せは常にサポートされているということです．しかしながら，ビューを「更新」（update）しようとすると一筋縄ではいかなくなります．つまり，更新できるビューもあれば更新できないビューもあります．その理由は「ビューは実リレーションではなくあくまでも仮想的なリレーションであるから」です．では，一体どのような条件を満たすときに，ビューは更新可能となるのでしょうか？これはビュー更新問題（view update problem）と呼ばれ，コッドがビューを提案した当初からさまざまな研究がなされて現在に至っています．
さて，ビュー更新問題は理論的にはビュー定義の逆関数を一意に不都合なく決定できるか否かという問題として定式化できますが，一意性には意味論（semantics）が関わってくること，逆関数の存在をタップルの重複出現を許さない集合意味論のもとで論じるのか，そうではなく（SQL テーブルのように）タップルの重複出現を許すバッグ意味論のもとで論じるのかという立場の違い，あるいは逆関数の存在を従来のようにリレーションスキーマレベルで問うのか，そうではなくインスタンスレベルで問うのか，などさまざまな観点があり，それによりビューの更新可能性に大きな変化が生じることともなり，今なお，ビュー更新問題は解決済みとは言い難い状況です．
このような認識のもと，本稿では「ビューサポートの基礎理論」と題して，ビューとその更新可能性の概念，ビューの更新可能性をスキーマレベルで論じることとインスタンスレベルで論じることとの違い，スキーマレベルにおけるリレーショナルビューとバッグビューの更新可能性の違いなど，ビューサポートに関するさまざまな観点を念頭に置きつつ諸概念を整理しながら議論することで，そこから見えてくるビューサポートの全貌を報告してみたいと思います．

2. ビューとその更新可能性

2.1 ビューとは

 ビューとその更新可能性をリレーショナルデータモデルの観点から論じるとき，その基礎となるのはリレーショナル代数（relational algebra）です．一方，SQL のテーブルを念頭においてビューとその更新可能性を考えると，SQL ではタップルの重複出現を許すテーブル，これをバッグ（bag）という，の存在を前提としているので，その基礎となるのはバッグ代数（bag algebra）です．そこで，本稿ではリレーショナル代数で定義されるビューをリレーショナルビュー，バッグ代数で定義されるビューをバッグビューと呼び両者を区別します．

 さて，リレーション R(A₁, A₂, _…, A_n) は dom(R)=dom(A₁)✕dom(A₂)✕・・・✕dom(A_n) の有限部分集合として定義されます．ここに dom(A_i) は属性 A_i がとりうる値の全集合を表します．では，ビューは一体どのように定義されるのでしょうか？その詳細な定義は 3.1 節で与えますが，たとえば，リレーション R(A₁, A₂, _…, A_n) の選択ビューV は V=σ_φ(R(A₁, A₂, _…, A_n)) と定義されます．ここに，φ は dom(R) の元を引数とする述語で，σ_φ はリレーショナル代数演算で選択（selection）を表します．バッグビューの定義は 4.1 節で与えますが，たとえば R(A, B) と S(A, B) を和両立なバッグとした時，
R と S の加法和ビュー V は V(A, B)＝S(A, B)⨄R(A, B) と定義されるということです．ここに，⨄ は
加法和を表すバッグ代数演算で，これはリレーショナル代数にはないバッグ代数に特有の演算です．

 理論上，リレーショナルビューはバッグビューの特殊な場合となるのですが，まずリレーショナルビューの更新可能性を論じ，それが拡張される形でバッグビューの更新可能性を論じる方がビューサポート理論の全貌を見通しやすいと考えられるのでそのような展開とします．本章では引き続きビューとその更新可能性について論じ，続く第 3 章でリレーショナルビューの更新可能性を，第 4 章でバッグビューの更新可能性を論じます．

2.2 ビューの更新とは

 ビューの更新（update）とは，ビューは仮想的な構成体（construct）であるにも関わらず， SQL の用語を借りればビュー表（viewed table）として，あたかも実リレーションや実バッグであるかのように捉えてビューを更新しようとすることをいいます．しかしながら，ビューには実体がないことから更新できる場合もあればできない場合もあります．

 更新には，削除（delete），挿入（insert），書換（rewrite）があります．まず，削除と挿入を定義します．ここに dom(V) はビュー V のドメインを表します．

   削除（d）：delete σ_φ(V) from V; ここに φ は dom(V) の元を引数とする述語である．
挿入（i）：insert X into V; ここに X⊆dom(V) とする．

 リレーショナルビューの削除と挿入の定義は次の通りです（バッグビューの削除と挿入の定義は 4.2 節で与えます）．

● 削除（d）は，リレーショナル代数表現で表せば d: V←V－σ_φ(V) と定義するということです．
ここに－は差，φ は V に対する選択条件で，←はリレーションの置換を表します．
● 挿入（i）は，リレーショナル代数表現で表せば i: V←V∪Xと定義するということです．
ここに∪は和を表します．

ここで，ビューのドメインと書換について補足説明を行います．

■ ビューのドメインについて

 ビュー V(A_1’, A_2’, _…, A_r’) のドメイン dom(V) は，一般に dom(A_1’)×dom(A_2’)×・・・×dom(A_r’) そのものではなく，ビュー定義を満たすその部分集合として定義されます．

 たとえば，リレーション R(A, B) の選択ビューを V(A, B)=σ_B≦b(R(A, B)) とした場合，
dom(V)=dom(A)×dom(B) ではなく， dom(V)=dom(A)×σ_B≦b(dom(B))となります．具体的には，リレーション社員(社員番号，給与)を実リレーションとし，ビューを貧乏社員=σ_給与≦20(社員) とした時，dom(貧乏社員)= dom(社員番号)×σ_給与≦20 (dom(給与)) と定義されます．その結果，ビュー貧乏社員に対して，挿入 insert {(100, 10), (101, 15)} into 貧乏社員; は受け付けられてその更新可能性が検証の対象となりますが，insert {(100, 10), (101, 40)} into 貧乏社員; は (101, 40) の存在により {(100, 10), (101, 40)}⊆dom(貧乏社員) とはならないのでビュー貧乏社員に対して発行できる挿入ではないということです．つまり，上記の dom(V) の定義はビューの持つ意味に抵触するような挿入をあらかじめ排除する意図があります．これにより，リレーショナル DBMS は発行された挿入がビュー定義に抵触しないか否かの検証，これはインスタンスレベルの検証となります，を行わなくて済むので大いに助かりますが，一方でクライアントにはビューの定義に抵触しない挿入を発行しなければならないことが求められます．この条件はビュー更新を（本稿では）スキーマレベルで論じたいから課せられた条件ということです．
dom(V) の他の基本的な例としては，V＝R ならば dom(V)=dom(R) です．R と S を和両立とするとき和ビュー V=R∪S や差ビュー V=R－S のドメインは dom(V)=dom(R)=dom(S) です．直積ビュー V=R×S のドメインは dom(V)=dom(R)×dom(S) です．リレーション R(A₁, A₂, _…, A_n) の属性集合 X（⊆Ω_R），ここに Ω_R ={A₁, A₂, _…, A_n}，上の射影ビュー V=π_X(R) のドメインは，X={A_1’, A_2’, _…, A_r’}，ここに 1≦1’≦2’≦…≦r’≦n として，dom(V)=dom(A_1’)×dom(A_2’)×･･･×dom(A_r’) となります．選択ビューについては上記の通りです．R(A, B) と S(B,C) の等結合ビュー V(A, R.B, S.B, C)=
R⨝_R.B=S.BS のドメインは dom(V)=σ_R.B=S.B(dom(A)×dom(R.B)×dom(S.B)×dom(C)) となります．
R(A, B) と S(B,C) の自然結合ビュー V(A, R.B, C)=R⨝S のドメインは dom(V)=π_{{A, R.B, C}}(σ_R.B=S.B
(dom(A)×dom(R.B)×dom(S.B)×dom(C))) となります．リレーショナル代数演算を複合して適用して定義される一般的ビュー，たとえば，リレーション R(A, B, C)の選択と射影で定義されるビュー V=π_{{A, B}}(σ_C=c(R)) のドメインは dom(V)=dom(A)×dom(B) です．これは，中間ビュー V₁=σ_C=c(R) のドメインは dom(V₁)= dom(A)×dom(B)×σ_C=c(dom(C))ですが，V のドメインは dom(V₁) の {A, B} 上の射影をとって定義されているのでそうなります．このようにビューのドメインはいずれもビュー定義と表裏一体の関係で定義されます．

■ 書換について

本稿では書換を削除と挿入の系列とみなします．このとき，ビューの削除は可能であったとしても，続く挿入には注意を払う必要があります．どういうことかを上記のビュー貧乏社員=σ_給与≦20(社員)を例にすれば次の通りです．たとえば，社員番号 200 の社員の給与が 15 であったとすると，タップル (200, 15) がビュー貧乏社員に出現します．給与倍増ということで，社員番号=200 の給与を 30 に書換えるとします．このとき，書換は削除と挿入の系列とみなしているので，まずビュー貧乏社員から (200, 15) を削除して，続いて (200, 30) が挿入されるということです．3.2 節[11]項で示される通り，選択ビューは削除可能なのでビュー貧乏社員からの (200, 15) の削除は基底リレーション社員からの (200, 15) の削除に変換できます．しかしながら，続く，ビュー貧乏社員への (200, 30) の挿入は挿入の条件である {(200, 30)}⊆dom(貧乏社員)，ここに dom(貧乏社員)=dom(社員番号)×σ_給与≦20 (dom(給与))，とはならないので許されません．これは社員番号が 200 の社員は給与が 30 なのでもはや貧乏社員ではないので当然のことです．つまり，給与が倍増されたこの社員はビュー貧乏社員に挿入されるべきではなく，基底リレーション社員に直接挿入されるべきなわけです．つまり，(200, 30) をビュー貧乏社員に挿入するすべがないのではなく，それはリレーション社員に挿入され，その結果として社員番号 200 の社員はビュー貧乏社員には現れなくなる，それがビューの更新を考察する場合の「書換は削除と挿入の系列とみなす」の意味と処理です．

2.3 ビューの更新可能性

 一般にビューは仮想的な構成体なので，実リレーションや実バッグと異なりすべてのビューが更新可能とは限りません．ビューはどのようなときに更新可能となるのか，それをダヤール（U. Dayal）ら [4] が与えた定義を参考にして規定すると次のようになります． ここにデータベーススキーマを S，時刻 τ におけるデータベース状態を S_τ（つまり，S_τ は時刻 τ における S のインスタンス），ビュー定義を V で表すと，時刻 τ におけるビュー（状態）は V_τ（=V(S_τ)）です．

【定義１】（ビューの更新可能性）
時刻 τ におけるビュー V_τ への更新 u が変換可能（translatable）であるとは，u の V_τ から S_τ への変換（translation）T が存在して，次の条件を満たすときをいう．

 (a)

変換 T は一意（unique）である．

 (b)

V_τ に副作用がない（no side effect）．

 (c)

T(u) には S_τ に対する余計な更新がない（no extraneous update）．

 (d)

T(u) はデータベーススキーマ S の一貫性制約に抵触しない．

以下，定義 1 を補足します．

 (a)

一意性

 更新可能性の大前提である変換に「一意性」を課したことは，変換 T に代替案があった時にその選択基準を設けられないためです．たとえば，リレーション R(A, B)={(1, 2)} と S(B, C)={(2, 3)} の自然結合ビュー V=R⨝S が定義されていて，V に対して削除 d=delete {(1, 2, 3)} from V; が発行されたとします．このとき，この削除を実現できる d の変換は次に示す 3 つ考えられます．
T₁(d)= delete {(1, 2)} from R;
T₂(d)= delete {(2, 3)} from S;
T₃(d)= begin; delete {(1, 2)} from R; delete {(2, 3)} from S; end;
注意するべきは，T₁(d)～T₃(d) の持つ削除の意味がそれぞれ異なるということです．意味が異なるということは勝手な選択はデータベースの一貫性に問題を生じさせかねないということです．サイコロを振ってどれかにするというようなことは許されないということです．「一意性」はデータベースの一貫性維持のために必要な制約です．

 (b)

副作用がない

 「副作用がない」とは図 1 に示す可換図式が成立することをいいます．副作用が生じる例としては，2 つのリレーションを R(A, B)={(1, 1)}, S(C, D)={(1, 1)} として，V=R×S={(1, 1, 1, 1)} を直積ビューとします．このとき，V に対して挿入 i=insert {(2, 2, 2, 2)} into V; が発行されたとします．i を R と S への挿入の系列 T(i)=begin; insert {(2, 2)} into R; insert {(2, 2,)} into S; end; に変換すれば，確かに (2, 2, 2, 2) が V に挿入されますが，同時に (1, 1, 2, 2) と (2, 2, 1, 1) が V に出現してしまいます．これを副作用といい，それは意図した更新ではなかったので，その発生の源となった挿入 i を上記のように変換することは許されないということです．

 (c)

余計な変換がない

 S_τに対する「余計な変換がない」とは，たとえば，リレーション社員(社員番号, 社員名, 給与, 部門)={(001, 山田太郎，50，K55)，(002，鈴木花子，40，K41)，(003，田中桃子，60，K41)，(004，佐藤一郎，40，K55)}，ここに社員番号は社員の主キーとする，の射影ビュー V=π_{{社員番号，社員名}}社員={ (001, 山田太郎)，(002，鈴木花子)，(003，田中桃子)，(004，佐藤一郎)} に挿入 i=insert {(007，ボンド)} into V; が発行されたとき，i をリレーション社員に対する挿入 T(i)= insert {(007，ボンド，null，
null)} into 社員; ここに null は属性に値がないことを表す，に変換すれば問題は生じませんが，そうではなく，たとえば，T’(i)= insert {(007，ボンド，100，null)} into 社員;とすると，これで確かに射影ビュー V に (007，ボンド) が挿入されますが，基底リレーション社員にはボンドの給与が 100 であるという余計な値が挿入されることになり，これは許さないということです．

 (d)

データベーススキーマの一貫性制約に抵触しない

 「データベーススキーマの一貫性制約に抵触しない」ですが，その意味するところは次の通りです．時刻 τ でビュー V に対して発行された更新 u に対して，条件 (a)～(c) を満たす更新変換 T(u) が存在したとします．このとき，時刻 τ におけるデータベース状態を S_τ で表すと，S_τ は T(u) で更新されないといけないわけですが，この更新がデータベーススキーマ S に課せられている一貫性制約に抵触してはならないということです．
一貫性制約は多様です．キー制約はすべてのリレーションに課せられている一貫性制約ですが，データベース化の対象となった実世界に存在する意味的制約を反映した一貫性制約もあります．たとえば，リレーションスキーマ社員(社員番号, 社員名, 給与, 部門)について，「各部門には最低 2 名の社員が所属していなければならない」という一貫性制約が課せられていたとします．そして，ビュー「K55 社員」を K55 社員=σ_部門=K55(社員)と定義したとします．このとき，ビュー K55 社員に対して一名の K55 社員を削除する操作が発行されたとします．ビュー K55 社員は選択ビューなので，それに対して発行された削除はそのまま基底リレーションであるリレーション社員の削除に変換可能です（3.2 項【11】項）．しかしながら，もし K55 社員が 2 名しかいなかった場合，この削除は「各部門には最低 2 名の社員が所属していなければならない」というリレーションスキーマ社員の一貫性制約に抵触するので受け付けてはなりません．これが条件 (d) の意味するところです．
しかしながら，条件 (d) はビューに特有の条件ではないことに注意する必要があります．たとえば，上記のリレーションスキーマ社員に上記と同じ一貫性制約が課せられていれば，この制約は社員のいかなるインスタンスとしてのリレーション社員に（ビューを通してではなく）直接更新がかけられたときにもそれに抵触してはならない制約です．したがって，条件 (d) を特段にビューの更新可能性の条件として課するべきではないと捉え，本稿ではビューへの更新は定義 1 の条件 (a)～(c) を満たすとき，変換可能とすることにします（関連した議論を 3.1.2 項でも行っています）．
なお，ビュー V_τ への更新 u が変換可能（translatable）であるとき，ビュー V_τ は更新可能（updatable）であるともいいます．

2.4　スキーマレベル vs. インスタンスレベルアプローチ

 リレーショナルデータモデルにはリレーションスキーマとそのインスタンスという概念区分があります．時間的に不変なリレーションの構造がリレーションスキーマ（relation schema）で，一般に時間と共に変化するコンテンツとしてのリレーションがリレーションスキーマのインスタンス（instance）です．そして，両者の関係性は次の通りです[10]．
「リレーションスキーマ R である性質 P が成り立つということは，R のすべての
インスタンス R に対してその性質 P が成り立つとき，およびそのときのみである」

 たとえば，リレーションスキーマ社員(社員番号, 社員名, 給与, 部門)があったとき「社員番号が社員のキーである」という性質は，リレーションスキーマ社員のすべてのインスタンス社員に対して次が成立することです．ここに t[社員番号]はタップル t の属性である社員番号がとる値を表します（⇒は含意を表す）．
(∀t, t’∈社員)(t[社員番号]=t’[社員番号]⇒t=t’)

さて，先に与えた定義 1 はビューの更新可能性をインスタンスレベルで規定しています．しかしながら上記の観点から定義 1 で与えられたビューの更新可能性の定義を見直すと，ビューの更新可能性を定義通りにインスタンスレベルで規定することは勿論できますが，スキーマレベルで規定することも可能であることが分かります．どちらのアプローチをとるべきなのでしょうか，素朴な疑問に直面してしまいます．
しかしながら，これまで行われてきたビューの更新可能性の議論に目を向けてみると，この問題は理論的にも実践的にもスキーマレベルで議論されてきました．なぜでしょうか？その理由は，スキーマレベルで規定することにより，与えられたビューの更新可能性をリレーショナル DBMS が検証するにあたり，検証をテーブル参照（table lookup）で行えるからです．つまり，ビューの更新可能性をスキーマレベルで規定しておくと，基本的ビューの更新可能性を予あらかじめメタデータとしてカタログに登録しておけば，一般的ビューが与えられた時，それが更新可能かどうかは，そのビュー定義を構文解析して，その構文解析木のノードに一つでも更新不可能とされる基本的ビュー定義があれば，その時点でその一般的ビューは更新不可能と判定できるからです．たとえば，「直積ビューは削除不可能」とカタログに登録されていれば，一般的ビューの定義に直積が用いられていることを見つけた時点で，このビューは削除不可能と判定できるわけです．これはビュー更新をサポートしようとするリレーショナル DBMS にとっては負荷が少なくとても嬉しく映るはずです．実際，現在のプロプライエタリあるいは OSS のリレーショナル DBMS のすべてはこのアプローチに基づいています．
一方，もしビューの更新可能性をインスタンスレベルで判定すると状況は一変します．何が変わるのかといえば，スキーマレベルで更新不可能とされるビューがインスタンスレベルでは状況により更新可能となるということです．たとえば，リレーション R(A, B) と S(B, C) の自然結合ビュー定義 V=R⨝S の更新可能性は，スキーマレベルのアプローチでは「押し並なべて結合ビューは更新不可能だから V は更新不可能」となってしまいますが，インスタンスレベルのアプローチではそうはならず，「この・・自然結合ビュー V に対して発行されたこの・・更新 u は変換可能か否か」をケースバイケースで検証していくということです．したがって，インスタンスレベルのアプローチを採るとリレーショナル DBMS の負荷は増大するのですがクライアントにとっては更新できるビューが却下されてしまうことが少なくなるので福音となります．つまり，ビューの更新可能性をスキーマレベルで規定するのかインスタンスレベルで規定するのかは処理コストと更新可能性のトレードオフということになります．筆者らが考案した「更新意図の外形的推測に基づいたビューの更新可能性」[6, 7] はインスタンスレベルの考え方に基づいたビュー更新の新しいアプローチです．興味を抱いた方は是非，拙著論文にあたってみてください．

3. リレーショナルビューの更新可能性（スキーマレベル）

3.1 リレーショナルビューの定義

3.1.1 リレーショナル代数

 リレーショナルビューはリレーショナル代数を使って定義されます．リレーショナル代数はコッドがリレーショナルデータモデルの一環として導入しましたが，以下に示す演算からなります [1]．
【定義２】（リレーショナル代数演算）
● 和（∪），差（－），共通（∩）
● 直積（×）
● 射影（π_X(R)，ここに X⊆Ω_R）
● 選択（σ_φ (R)，ここに φ は dom(R)上の選択条件）
● θ-結合（R⨝_AiθBjS，ここに A_i∈Ω_R，B_j∈Ω_S で A_i と B_j は θ-比較可能）
● 商（÷）

 これら 8 つの演算の定義を表 1 に示します．

補足をすれば次の通りです．

 ●

リレーション R の全属性集合を Ω_R={A₁, A₂, _…, A_n}としたとき，R はdom(R)=dom(A₁)×dom(A₂)×・・・×dom(A_n) の有限部分集合と定義されます．

 ●

述語 R(t) はタップル t がリレーション R の元であるとき，つまり t∈R のとき及びそのときのみ真（true）となります．

 ●

∨，∧，¬，⇒，⇔ はそれぞれ論理和，論理積，論理否定，含意，必要かつ十分，を表す命題結合子です．

 ●

タップルを結合する演算子* は (a₁, a₂, _…, a_n)*( b₁, b₂, _…, b_m)=(a₁, a₂, _…, a_n, b₁, b₂, _…, b_m) と定義されます．

 ●

R(A₁, A₂, _…, A_n) と S(B₁, B₂, _…, B_m) をリレーションとするとき，それらが和両立（union compatible）であるとは n=m∧∀_i(dom(A_i)=dom(B_i)) が成立しているときをいいます．

 ●

t =(a₁, a₂, _…, a_n) をリレーション R(A₁, A₂, _…, A_n) のタップル，Ω_R の部分集合を X={ A_1’, A_2’, _…, A_ℓ’}，1≦1’≦2’≦・・・≦ℓ’≦n としたとき，t の X 上の射影は t[X]=(a_1’, a_2’, _…, a_ℓ’) と定義されます．

 ●

比較演算子を θ∈{＜, ≦，≠，＝,＞，≧} とします．

 ●

A_i∈Ω_R，B_j∈Ω_S で A_i と B_j が θ-比較可能とは A_iθB_j の真，偽が常に決まることをいいます（3 値論理の場合は，真，偽，不定となります）．

 ●

選択を定義する際に使用される選択条件 φ は次のように再帰的に定義されます．ここに A_i や A_j はリレーション R(A₁, A₂, _…, A_n) の属性で，A_i と A_j は θ-比較可能，c を定数，θ を比較演算子とします．

【定義３】（選択条件 φ）
(i) A_iθc，A_iθA_j は選択条件である．
(ii) α と β を選択条件としたとき，¬α，α∨β，α∧β は選択条件である．
(iii) (i) と (ii) で定義されるもののみが選択条件である．

選択条件は合成可能です．つまり，リレーション R に対して選択条件 φ を施した結果である σ_φ(R) に対して，新たな選択条件 ψ を施すと，その結果は σ_ψ(σ_φ(R))となりますが，質問変形[3] により，
σ_ψ(σ_φ(R))=σ_ψ∧φ(R) が成立します．したがって，σ_ψ(σ_φ(R))=σ_φ(σ_ψ(R)) や σ_φ(σ_φ(R))=
σ_φ(R) などが成立します．また，選択条件とリレーショナル代数演算との最も基本的な関係は次の通りです．ここに，R, S をリレーション，ψ，φ は述語を表します．

 ●

σ_ψ∨φ(R)=σ_ψ(R)∪σ_φ(R)

 ●

σ_ψ∧φ(R)=σ_ψ(R)∩σ_φ(R)

 ●

σ_¬φ(R)=R－σ_φ(R)

なお，コッドはリレーショナル代数演算として上記のごとく 8 つの演算を導入しましたが，演算の
独立性に着目すると，たとえば，和，差，直積，射影，選択の 5 つはお互いに独立した演算であり，
共通，結合，商やその他の演算をそれらを使って表せることはよく知られていることです．たとえば
次の通りです．

 ●

共通：R∩S=R－(R－S)

 ●

θ-結合：R⨝_AiθBjS=σ_R.AiθS.Bj(R×S)

 ●

自然結合：R⨝S=π_ΩR∪ΩS (_{σR.C1=S.C1∧R.C2=S.C2∧．．．∧R.Cr=S.Cr}(R×S))，ここに
{C₁, C₂, _…, C_r}=Ω_R∩Ω_S

 ●

左外結合：R⟕S= (R⨝S)∪(R –π_ΩR(R⨝S))×{(null, _…, null)}

 ●

右外結合：R⟖S= (R⨝S)∪{(null, _…, null)}×(S –π_ΩS(R⨝S))

 ●

完全外結合：R⟗S= (R⨝S)∪(R –π_ΩR(R⨝S))×{(null, _…, null)}∪{(null, _…, null)}×
(S –π_ΩS(R⨝S))

さらに補足をすると，リレーショナルデータモデルが提案された当初，選択は θ-選択として定義されていました．その定義は次の通りです．

つまり，θ-選択は選択条件 φ の定義 3 の (i) 項の A_iθA_j は選択条件であるという定義から直接導けます．また，上で記しましたが，選択条件は合成可能ですから θ-選択を合成した演算が選択ということになります．したがって，両者をいたずらに区別する必要はなく，特に φ=A_iθA_j を強調したい場合に θ-選択という，と使い分けをすることとします．
結合演算には上記のようにさまざまな結合形態があり，それらを峻別するために最も基本的な結合を θ-結合としたと理解すればよいと思います．他の結合は θ-結合を合成していくことで得られます．

■ Null と 3 値論理

コッドが初めてリレーショナルデータモデルを提案したとき，リレーションの属性が null（空，値がないことを表す）をとることは想定されていませんでした [1]．そこでは，リレーション R(A₁, A₂, _…, A_n) は dom(R)=dom(A₁)×dom(A₂)×・・・×dom(A_n) の有限部分集合と定義されますが，各ドメイン dom(A_i) は単純（simple）である，つまり，integer あるいは文字列からなる集合で，それが null を含むことは想定されていませんでした．したがって，リレーショナル代数演算は 2 値論理に基づいて定義できました．
リレーショナルデータモデルに null が導入されたのは，より多くの意味をリレーショナルデータモデルに取り込もうとレーショナルデータモデルを拡張したコッドの 1979 年の論文で，そこで初めて 3 値論理に基づくリレーショナル代数が導入されました [5]．
一方，ビューの更新可能性を論じるときには，リレーションやビューの属性が null をとらざるを得ない状況が発生します．たとえば，リレーション R(A, B, C)，ここに A は主キー，の属性集合 {A, B} 上の射影ビュー V=π_{{A, B}}(R) はキー保存なので，V に対する挿入は変換可能です（3.2 節【10】項）．たとえば，i=insert (a, b) into V; は R への挿入 T(i)=insert (a, b, null) into R; に変換可能です．つまり，リレーション R に当初は属性が null となるタップルが存在しなかったとしても，いずれはそのようなタップルが存在する可能性があるわけです．
したがって，ビューサポートの理論ではリレーショナル代数演算は 3 値論理を導入した拡張が前提となります．この導入により影響を受ける演算は選択や θ-結合で，それらは推量 θ-選択（maybe θ-selection）や推量 θ-結合（maybe θ-join）の導入に繋がります．定義 3 の (i) 項で与えたようにA_iθc，A_iθA_j は選択条件であるので，これらの述語の値は A_i や A_j が null でなければ真か偽をとりますが，そうでない場合には「不定」（unknown）をとります．たとえば，「2＞3=偽」ですが「2＞null=不定」となります．そうすると，リレーション R(A₁, A₂, _…, A_n) の推量 θ-選択は σ_AiθωAj(R)={t|R(t)∧t[A_i]θ[A_j] IS UNKNOWN} と定義されます．ここで t[A_i]θ[A_j] IS UNKNOWN の真理値は表 2 に示される「3 値論理の IS ブール演算子真理値表」で規定されます．たとえば，属性に null を許容したリレーションを R(A, B, C)={(1, 5, 3), (2, 3, 8), (3, 2, null), (4, null, 6), (5, null, null)} とすれば，
σ_B＞C(R)={(1, 5, 3)} ですが，σ_B＞ωC (R)={(3, 2, null), (4, null, 6), (5, null, null)} となります．なお，
推量 θ-結合は推量 θ-選択を用いて，推量 θ-結合は R⨝_AiθωBjS=σ_R.AiθωS.Bj(R×S) と定義できます [10]．
このように，ビューサポートでは null を導入した 3 値論理に基づいた論理展開が必要なのですが，表 1 のリレーショナル代数演算の選択や θ-結合の定義には推量 θ-選択や推量 θ-結合が陽には表れていません．もちろんそれらを許すように表 1 を拡張できますが，表 1 にそれらを明示していないのは，もっぱら 2 値論理のリレーショナル代数演算の下でビューの更新可能性を論じることで，ビューサポートの議論全体の見通しをよくしようと考えたからです．null を扱わないといけない状況に直面したときには，3 値論理に従って思考してください．たとえば，リレーション R(A₁, A₂, _…, A_n) の属性 A_i と A_j 上の θ-選択ビュー V は 3 値論理では V=σ_AiθAj(R)={t|R(t)∧t[A_i]θ[A_j] IS TRUE} と定義されますが，これは 2 値論理での V=σ_AiθAj(R)={t|R(t)∧t[A_i]θ[A_j]} と同値です．一方，R の属性 A_i と A_j 上の推量 θ-選択ビュー V は V=σ_AiθωAj(R)={t|R(t)∧t[A_i]θ[A_j] IS UNKNOWN} と定義され，3 値論理に従います．より具体的には，上記のリレーションR(A, B, C)={(1, 5, 3), (2, 3, 8), (3, 2, null), (4, null, 6), (5, null, null)} の属性 B と C 上の「推量大なり（＞）選択ビューV」は V=σ_B＞ωC (R)={(3, 2, null), (4, null, 6), (5, null, null)} となりますが，B 上の「推量以下（≦）演算」を使った削除 d=delete σ_B≦ω10 (V) from V; が発行されたとすると，d は T(d)= delete σ_B≦ω10 (R) from R; と基底リレーション R に変換可能で，R から {(4, null, 6), (5, null, null)} が削除され，その結果 V={(3, 2, null)} となり，所望の削除が実現されていることがわかります．このような拡張はバッグ代数についても同様です．

3.1.2 リレーショナル代数表現としてのリレーショナルビュー

 リレーショナルデータベースに対する問合せ（query）はリレーショナル代数表現（relational algebra expression）として記述できますが，ビューは問合せによって定義される仮想的リレーションなので，リレーショナルビューはレーショナル代数表現を使って再帰的に定義することができます．それを定義 4 に与えます．リレーショナル代数演算の独立性から，和，差，直積，射影，選択の 5 つの演算を使ってビューを定義しています．実リレーションとはデータベースに格納されているリレーショナルのことをいいます．なお，本来はリレーショナルビューと書くべきなのですが，ここでは特段の混乱は生じないと考えられるので，単にビューと記しています．
【定義４】（ビュー）

 (1)

実リレーション R はビューである．

 (2)

V₁ と V₂ を和両立なビューとするとき，それらの和 V₁∪V₂ はビューである（和ビュー）．

 (3)

V₁ と V₂ を和両立なビューとするとき，それらの差 V₁－V₂ をはビューである（差ビュー）．

 (4)

V₁ と V₂ をビューとするとき，それらの直積 V₁×V₂ はビューである（直積ビュー）．

 (5)

V をビューとするとき，その射影 πx(V) はビューである（射影ビュー）．

 (6)

V をビューとするとき，その選択 σ_φ(V) はビューである（選択ビュー）．

 (7)

(1)～(6) で定義されるもののみがビューである．

ビューを定義するときに使われる実リレーションをそのビューの基底リレーション（underlying base relation）といいます．基底リレーションを使って (1)～(6) 項のいずれかの演算を 1 度だけ使用して定義されるビューを基本的ビュー（basic view），定義4 の (1)～(6) 項で定義された演算を再帰的に適用して定義されるビューを一般的ビュー（general view）ということにします．この定義に従えば，（定義 4 には陽には出現しなかった）共通ビュー，結合ビュー，商ビュー，外結合ビューなどは一般的ビューとして定義されることになります．ちなみに，R(A, B, C)，S(B, D) をリレーション（アンダーバーは主キーを表す）としたとき，連言問合せ（conjunctive query）として定義されるビュー V=
π_{{R.A, R.B}}(σ_C=c(R)⨝_R.B=S.Bσ_D=d(S)) は一般的ビューの典型です．なお，テーブルにタップルの重複
出現を許している SQL では avg, sum, max, min, count といった集約（aggregation）が有効ですが，リレーションは重複タップルの出現を許していないので SQL ほどの有効性はないと考えて，リレーショナル代数表現としてビューを定義する際には集約関数は特段に考慮していません．

■ ビューと一貫性制約

リレーショナル代数を使ってビューを定義しているということは，リレーショナルデータベースに対する問合せの結果をビューと称し，それらを再帰的にリレーショナル代数演算のオペランドに使用することで，あらゆる問合せの結果をビューとすることができるという意味です．ここで注意しないといけないことは，たとえば，定義 4 の (1) 項より「実リレーション R はビュー V である」と定義できますが，V と R は同一ではなく，SQL の表現を用いれば，問合せ SELECT * FROM R の結果リレーションをビュー V と定義したということです．どういうことかというと，R(A₁, A₂, _…, A_n) としたとき V(A₁, A₂, …, A_n) と書けて，インスタンスとしての R と V は同一ではあるものの，R をインスタンスとするリレーションスキーマ R(A₁, A₂, _…, A_n) に定義されている一貫性制約は V では定義されていないということです．あくまで，V は SQL で表現すれば CREATE VIEW V AS SELECT * FROM R と定義されるように，単に SELECT * FROM R の結果リレーションでしかないからです．実リレーションとビューとのこの差異は大きいと認識するべきで，すでに関連した議論を 2.3 節 (d) 項で行っていますが，ビューはあくまで更新の窓口であって，それが更新可能である場合，その更新がデータベースの一貫性制約に抵触するかしないかの検証はそのビューを定義するために使われた基底リレーションで行うということです．なお，更新時の一貫性制約の検証はビューに特有ではなく，一般にリレーショナルデータベースの実リレーションを更新した場合でも必ず行われないといけないわけで，これがビューの更新可能性を規定した定義1の条件から (d) 項を外した理由となったことは前述の通りです．
以下，実リレーション R がビュー V であることを V=R と表示したり，実リレーション R と S の和ビュー V を V=R∪Sと 表示したりしますが，「=」（等号）の意味は上記のごとく，単に右辺での問合せの結果リレーションを左辺（＝ビュー）としたということで，リレーションスキーマとしての同一性を表現しているものではありません．この議論はバッグビューに対しても全く同様に成立します．

3.2 基本的リレーショナルビューの更新可能性（スキーマレベル）

 表 3 に「基本的リレーショナルビューの更新可能性（スキーマレベル）」の結果を示します（ここでは，コッドの定義した 8 つのリレーショナル代数演算で定義されるビューを基本的ビューとしています）．行列値の 〇 は更新可能，× は更新不可能を表します．†はキー保存という条件を表しています．

以下，表 3 が得られた論拠を示します．要点は，ビューの更新可能性をスキーマレベルで論じているので，更新可能であることを示すにはすべてのインスタンスに対して更新可能であることを示す必要があること，一方で更新不可能を示すにはそのようなインスタンスと更新の組合せを 1 例示せばよいということです．

【1】和ビューは削除可能

 R と S を和両立なリレーション，V=R∪S を和ビューとする．
V に対して削除 d=deleteσ_φ(V) from V; が発行されたとする．ここに φ は探索条件である．削除の定義は V←V－σ_φ(V) なので，この削除を表す論理式は次の通りである．
∀t(t∈σ_φ(V)⇒¬V(t))
つまり，φ(t)=真となる V のタップル，つまり σ_φ(V) のタップル，は（削除後は）V のタップルであってはいけないと言っている．
一方，V=R∪S なので t∈σ_φ(V)⇔t∈σ_φ(R∪S)⇔t∈σ_φ(R)∨t∈σ_φ(S) である．したがって，
t∉σ_φ(V)⇔t∉σ_φ(R)∧t∉σ_φ(S) である．
つまり，「d を実現するためには，R から探索条件 φ を満たすタップルをすべて削除しかつ S からも探索条件 φ を満たすタップルをすべて削除することが必要かつ十分である」と言っている．このとき，(R－σ_φ(R))∪(S－σ_φ(S))=(R∪S)－(σ_φ(R)∪σ_φ(S)) =V－σ_φ(R∪S)=V－σ_φ(V) が成り立つ．したがって，d を実現するための必要かつ十分条件は d を T(d) に変換することである．
T(d)=begin; deleteσ_φ(R) from R; deleteσ_φ(S) from S; end;
このことは，特定のR，S，φ に依存することなく成立するので，「和ビューは削除可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

【例題１】R(A, B), S(A, B), dom(A)=dom(B)={i|Integer(i)}, R={(1, 1), (2, 2)}, S={(2, 2), (3, 3)}, V=R∪S={(1, 1), (2, 2), (3, 3)}, φ=(A=2∧B=2) とする．このとき，σ_φ(V)={(2, 2)} なので，V－σ_φ(V)={(1, 1), (3, 3)} であり, 一方，R－σ_φ(R)={(1, 1)}, S－σ_φ(S)={(3, 3)} なので (R－σ_φ(R))∪(S－σ_φ(S))= {(1, 1)}∪{(3, 3)}={(1, 1), (3, 3)} となり，d=deleteσ_φ(V) from V; が T(d)=begin; deleteσ_φ(R) from R; deleteσ_φ(S) from S; end; により実現できていることが確認できる．

【2】和ビューは挿入不可能

 和ビューは挿入不可能であるインスタンスレベルの反例を一つ示せばよい．たとえば，和両立な 2 つのリレーションを R(A, B)=∅, S(A, B)= ∅（ここに ∅ は空集合を表す）とすると，V=R∪S=∅ である．このとき，V に対する挿入 i=insert {(1, 1)} into V; が発行されたとする．挿入の定義は V←V∪{(1, 1)} なので，この挿入を表す論理式は次の通りである．
∀t(t∈{(1, 1)}⇒V(t))
一方，∀t(V(t)⇔R(t)∨S(t)) なので，i を実現する変換 T は 3 つ存在することが分かる．
T₁(i)= insert {(1, 1)} into R;
T₂(i)= insert {(1, 1)} into S;
T₃(i)= begin; insert {(1, 1)} into R; insert {(1, 1)} into S; end;
しかしながら，これら 3 つの変換の存在は変換の一意性に反するので，定義 1 より V への挿入 i は変換不可能である．したがって，「和ビューは挿入不可能である」という命題がスキーマレベルで成立する．

したがって，「和ビューは書換不可能である」という命題がスキーマレベルで成立する．

【3】差ビューは削除不可能

 差ビューは削除不可能であるインスタンスレベルの反例を一つ示せばよい．たとえば，和両立な 2 つのリレーションを R(A, B)={(1, 1), (2, 2)}, S(A, B)={(1, 1), (3, 3)} とする．このとき，差ビュー V=R－S={(2, 2)} である．
そこで，V に対する削除 d=deleteσ_φ(V) from V; ここに φ=(A=2∧B=2)，つまり σ_φ(V)= {(2, 2)}，が発行されたとする．
削除の定義は V←V－σ_φ(V) なので，この削除を表す論理式は次の通りである．
∀t(t∈σ_φ(V)⇒¬V(t))
一方，¬V(t)⇔t∉V⇔t∉(R－S)⇔t∉R∨t∈S である．
したがって，d を実現する変換 T が 3 つ存在することが分かる．
T₁(d)= delete {(2, 2)} from R;
T₂(d)= insert {(2, 2)} into S;
T₃(d)= begin; delete {(2, 2)} from R; insert {(2, 2)} into S; end;
この 3 つの変換の存在は変換の一意性に反するので，定義 1 より V への削除 d は変換不可能である．したがって，「差ビューは削除不可能である」という命題がスキーマレベルで成立する．

【4】差ビューは挿入可能

 R と S を和両立なリレーション，V=R－S を差ビューとする．
V に対して挿入 i=insert X into V;　ここに X⊆dom(R)，が発行されたとする．挿入の定義は V←V∪X なので，この挿入を表す論理式は次の通りである．
∀t(X(t)⇒V(t))
一方，差ビューの定義より，∀t(V(t)⇔R(t)∧¬S(t)) である．
したがって，挿入に関して次に示す論理式を得る．
∀t(X(t)⇒R(t)∧¬S(t))
つまり，「V に X を挿入するためには，R に X を挿入し S から X を削除しなさい」と言っている．このとき，(R∪X)－(S－X)=(R－S)∪X=V∪X が成り立つ．したがって，i を実現するための必要かつ十分条件は i を T(i) に変換することである．
T(i)=begin; insert X into R; delete X from S; end;
このことは，特定の R，S，X に依存することなく成立するので，「差ビューは挿入可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

したがって，「差ビューは書換不可能である」という命題がスキーマレベルで成立する．

【5】共通ビューは削除不可能

 和両立なリレーション R と S の共通は R∩S=R－(R－S) であるので，一般的ビューとなる「差ビューは削除不可能である」という命題がスキーマレベルで成立しているので，「共通ビューは削除不可能である」という命題がスキーマレベルで成立する．

【6】共通ビューは挿入可能

 R と S を和両立なリレーション，V=R∩S を共通ビューとするとき，それは次のように定義される．
∀t(V(t)⇔(R(t)∧S(t)))
そこで，V に対して挿入 i=insert X into V; ここに X⊆dom(R) が発行されたとする．挿入の定義はV←V∪Xなので，この挿入を表す論理式は次の通りである．
∀t(X(t)⇒V(t))
したがって，挿入に関して次に示す論理式を得る．
∀t(X(t)⇒(R(t)∧S(t)))
つまり，「V に X を挿入するためには，R に X を挿入しかつ S に X を挿入しなさい」と言っている．このとき，(R∪X)∩(S∪X)=(R∩S)∪X=V∪X である．したがって，i を実現するための必要かつ十分条件は i を T(i) に変換することである．
T(i)=begin; insert X into R; insert X into S; end;
このことは，特定の R，S，X に依存することなく成立するので，「共通ビューは挿入可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

したがって，「共通ビューは書換不可能である」という命題がスキーマレベルで成立する．

【7】直積ビューは削除不可能

 インスタンスレベルでの反例を一つ示す．2 つのリレーションを R(A, B)={(1, 1)}, S(C, D)={(1, 1)}，直積ビューを V=R×S={(1, 1, 1, 1)} とする．このとき，V に対して削除 d=delete σ_φ(V) from V; ここに φ=(A=1∧B=1∧C=1∧D=1) が発行されたとする．
削除の定義は V←V－σ_φ(V) なので，この削除を表す論理式は次の通りである．
∀t(t∈σ_φ(V)⇒¬V(t))
V=R×S={u*v|u∈R∧v∈S} なので，¬V(t)⇔t∉(R×S)⇔u∉R∨v∉S，ここに t=u*v とする，である．
一方，σ_φ(V)⇔σ_φ(R×S)⇔σ_φ1(R)×σ_φ2(S)，ここに φ はΩ_R×S=Ω_R×Ω_S 上の選択条件で，φ₁=φ|Ω_r と φ₂=φ|Ω_S はそれぞれ φ を Ω_R とΩ_S 上に制限した探索条件を表す．この例では φ₁=(A=1∧B=1)，φ₂=(C=1∧D=1) である．
したがって，d を実現する変換 T が 3 つ存在することが分かる．
T₁(d)= delete σ_φ1(R) from R; ここに φ₁=(A=1∧B=1)
T₂(d)= delete σ_φ2(S) from S; ここに φ₂=(C=1∧D=1)
T₃(d)= begin; delete σ_φ1(R) from R; delete σ_φ2(S) from S; end;
これは，変換の一意性に反するので，定義 1 より V への削除 d は変換不可能である．したがって，「直積ビューは削除不可能である」という命題がスキーマレベルで成立する．

【8】直積ビューは挿入不可能

 インスタンスレベルで反例を一つ示す．2 つのリレーションを R(A, B)={(1, 1)}, S(C, D)={(1, 1)} とする．このとき，V=R×S={(1, 1, 1, 1)} を直積ビューとする．このとき，V に対して挿入 i=insert {(2, 2, 2, 2) } into V; が発行されたとする．このとき，i を実現するためには R に (2, 2) を挿入し S には (2, 2) を挿入しないといけない．しかしながら，それにより V={(1, 1, 1, 1), (2, 2, 2, 2), (1, 1, 2, 2), (2, 2, 1, 1) } となり副作用が生じる．したがって，「直積ビューは挿入不可能である」という命題がスキーマレベルで成立する．

したがって，「直積ビューは書換不可能である」という命題がスキーマレベルで成立する．

【9】射影ビューは削除可能

 リレーション R の属性集合 X（X⊆Ω_R）上の射影ビューを V=π_X(R) とする．V に対して削除 d=delete σ_φ(V) from V; が発行されたとする． ここに選択条件 φ は dom(V)（=dom(X)）の元を引数とする述語であるが，X⊆Ω_R なのでdom(R) の元を引数とする述語ともなっている．
このとき，σ_φ(V)=σ_φ(π_X(R))= π_X(σ_φ(R)) である．
d の定義は V←V－σ_φ(V) であるので，V－σ_φ(V)= π_X(R)－π_X(σ_φ(R))=π_X(R－σ_φ(R)) となる．
つまり，d を実現するためには，「R から σ_φ(R) を削除して，その結果を X 上で射影しなさい」と言っている．このとき，φ は dom(R) の元を引数とする述語ともなっているので，
π_X(R－σ_φ(R))=π_X(R)－π_X (σ_φ(R))=π_X(R)－σ_φ(π_X(R))=V－σ_φ(V) が成立する．
したがって，d が変換可能であるための必要かつ十分条件は d を T(d) に変換することである．
T(d)=deleteσ_φ(R) from R;
このことは R と X と φ がどのような場合でも成り立つ．よって，「射影ビューは削除可能である」という命題はスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

【例題２】R(A, B)={(1, 1), (1, 2), (2, 1)}, V=π_{B}(R)={(1), (2)} とし, V に対して削除 d=delete _σB=1∨B=3(V) from V; が発行されたとする．T(d)=delete _σB=1∨B=3(R) from R; に変換されるが，T(d) により B=1 の R のタップル (1, 1) と (2, 1) は R から削除される．B=3 のタップルは R に存在しないので R から削除されるタップルはない．したがって，R={(1, 2)} となるから，π_{B}(R)={(2)}と 所望の結果となっている．

【10】射影ビューはキー保存ならば挿入可能
リレーション R の属性集合 X⊆Ω_R 上の射影ビューを V=π_X(R) とするとき，射影ビュー V がキー保存（key preservation）であるとは，X がリレーション R の主キー K を含むときをいう．
そこで，リレーション R の属性集合 X 上の射影ビューを V=π_X(R) とすると，V の定義から次が成立する．
∀u(V(u)⇔∃t(R(t)∧u=t[X]))
V に対して挿入 i=insert W into V; ここに W⊆dom(V) が発行されたとする．この挿入を表す論理式は次の通りである．
∀v(W(v)⇒V(v))
したがって，次が成立する．
∀v(W(v)⇒∃t(R(t)∧v=t[X]))
このとき，挿入 i=insert W into V; の R への変換 T を次のように定義する．
T(i)=insert W～ into R;
ここに W～ は W から次のように定義されるタップル w~ の集合で，w∈W とした時，タップル w~ は次のように定義される．
w~[X]=w∧w~[Ω_R－X]=(null, null, _…, null)
さて，射影ビュー V がキー保存であるとすると，K を R の主キーとしたとき，K⊆X であるので，∀w, w’(W(w)∧W(w’)∧(w[K]≠w’[K]⇒w≠w’))が成立する．加えて，K は（候補キーではなく）主キーなので，キー制約からその属性が null をとることはないから，W と W～ の間には ww~ という 1 対 1 の対応が成立する．
このとき，π_X(R∪W～)=π_X(R)∪π_X(W～)=π_X(R)∪W=V∪W が成立するので，i を実現するための必要かつ十分条件は i を T(i) に変換することであることが分かる．
T(i)=insert W～ into R;
したがって，「射影ビューはキー保存であれば挿入可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

したがって，「射影ビューはキー保存ならば書換可能である」という命題がスキーマレベルで成立する．

なお，「キー保存」という条件自体は属性集合 X が主キー K を含んでいるかどうかという判定なのでスキーマレベルの検証であるので，定義 1 の条件 (a)～(c) をクリアして「射影ビューはキー保存ならば挿入可能である」という命題はスキーマレベルで成立することとなった．
ただし，変換可能ならば基底リレーション R に W～ が挿入されることになるが，その挿入が R のキー制約に抵触するのかしないのかのチェックが必ず必要となってくることに注意したい．

【例題３】R(A, B)={(1, 1), (2, 2), (3, 3)}, V=π_{A}(R)={(1), (2), (3)}, i=insert {(4)} into V; が発行されたとする．i の変換 T(i)= insert {(4, null)} into R; とする．その結果，R(A, B)={(1, 1), (2, 2), (3, 3), (4, null)} となり，改めて π_{A}(R)= {(1), (2), (3), (4)} となりなって，所望の挿入が実現していることがわかる．

【11】選択ビューは削除可能
リレーション R の選択ビューを V=σ_φ(R) とする．V に対して削除 d=deleteσ_ψ(V) from V; が発行されたとする．d の定義は V←V－σ_φ(V) であるが，V－σ_φ(V)=σ_φ(R)－σ_ψ(σ_φ(R))=σ_φ(R)－σ_φ(σ_ψ(R))=σ_φ(R－σ_ψ(R)) となる．
つまり，d を実現するためには，「R から σ_ψ(R) を削除して，その結果に φ を施しなさい」，つまり，d を T(d) に変換しなさいと言っている．
T(d)=deleteσ_ψ(R) from R;
このとき，上記のごとく σ_φ (R－σ_ψ(R))= V－σ_φ(V) であるので，この変換は d が変換可能であるための必要かつ十分条件になっている．この性質は R と φ と ψ がどのような場合でも成り立つので，「選択ビューは削除可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

【例題４】社員(社員番号，給与)={(1, 10), (2, 20), (3, 30)} を実リレーション，ビューを貧乏社員=σ_給与≦20(社員)={(1, 10), (2, 20)} とし，削除 d=delete σ_給与≧10 (貧乏社員) from 貧乏社員; が発行されたとする．d は変換可能で次の通りである．
T(d)=deleteσ_{給与≧10∧給与≦20}(社員) from 社員;

【12】選択ビューは挿入可能
リレーション R の選択ビューを V=σ_φ(R)とする．V に対して挿入 i=insert X into V; が発行されたとする．i の定義は V←V∪X なので，この挿入を表す論理式は次の通りである．
∀t(X(t)⇒V(t))
一方，選択ビューの定義より，∀t(V(t)⇔R(t)∧_φ(t)) である．したがって，次に示す論理式を得る．
∀t(X(t)⇒(R(t)∧φ(t)))
ところで，X⊆dom(V)=σ_φ(dom(R)) なので，∀t(X(t)⇒_φ(t))，つまり ∀t(t∉X(t)∨_φ(t)) が成立している．したがって，
∀t(X(t)⇒(R(t)∧φ(t)))⇔∀t(t∉X(t)∨(R(t)∧_φ(t)))⇔∀t((t∉X(t)∨(R(t))∧(t∉X(t)∨_φ(t)))⇔∀t(t∉X(t)∨(R(t)) ⇔∀t(X(t)⇒R(t)) となる．
つまり，「iを実現するためには，R に X を挿入しなさい」と言っている．このとき，X⊆σ_φ(dom(R))なので σ_φ(X)=X となり，σ_φ(R∪X) =σ_φ(R)∪σ_φ(X)=V∪X である．したがって，i を実現するための必要かつ十分条件は iを T(i) に変換することである．
T(i)= insert X into R;
このことは，特定の R，φ，X に依存することなく成立するので，「選択ビューは挿入可能」であるという命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

したがって，「選択ビューは書換可能である」という命題がスキーマレベルで成立する．

【例題５】社員(社員番号，給与)={(1, 10), (2, 20), (3, 30)} を実リレーション，貧乏社員=σ_給与≦20(社員)={(1, 10), (2, 20)} をビューとし，挿入 i=insert {(100, 10), (101, 15)} into 貧乏社員; が発行されたとする．i は変換可能で，その変換は次の通りである．
T(i)=insert {(100, 10), (101, 15)} into社員;

【13】結合ビューや商ビューは共に削除不可能，挿入不可能，書換不可能
これらを定義するためには直積演算が使われるので，それらの更新可能性に則して，共にスキーマレベルで削除不可能，挿入不可能，書換不可能である．

3.3 一般的リレーショナルビューの更新可能性（スキーマレベル）

 一般にリレーショナルビューはリレーショナル代数演算を「再帰的」に適用して定義されます．このようなビューを「一般的リレーショナルビュー」といいますが，そのようなビューの更新可能性はそのビュー定義に使われたリレーショナル代数演算で定義される中間ビューの更新可能性に依存することになります（このことは，後述する一般的バッグビューについても同様です）．
ここではリレーショナルデータベースで最も典型的であるといわれている連言問合せ（conjunctive query）で定義されるビューを例として説明します．
【例題６】（一般的リレーショナルビューの更新可能性判定）
R(A, B, C)，S(B, D) をリレーション（アンダーバーは主キーを表す），V=π_{{R.A, R.B}}(σ_C=c(R)
⨝_R.B=S.Bσ_D=d(S)) を連言問合せビュー定義とする．このビューの定義木（＝構文解析木）を図 2 に示す．
このとき，V へ更新 u が発行されると，V=π_{{R.A, R.B}} 中間ビュー₁ なので，射影ビューに対する u の変換可能性をチェックする．表 3 を参照すると（table lookup），u が削除ならば変換可能，u が挿入ならばキー保存という条件付きで変換可能であることを知る．ともに，（挿入には条件が付くが）変換可能なので，V への更新 u の変換可能性は，中間ビュー₁ に対する更新の変換可能性のチェック結果に依ることとなる．ところが，中間ビュー₁ は結合ビューである．そこで，再び表 3 を参照すると，結合ビューは削除不可能，挿入不可能，書換不可能であることを知る．したがって，u は押し並べて変換不可能であることを知る．この時点で，ビュー V への更新 u が変換不可能であると判定される．

このように，一般的リレーショナルビューの更新可能性はそのビューの定義木をトップダウンに，たとえば幅優先探索（breadth first）で走査しながら，ノードごとでその更新可能性を表 3「基本的リレーショナルビューの更新可能性（スキーマレベル）」に参照していけば，その更新可能性をスキーマレベルで検証することができます．

4. バッグビューの更新可能性（スキーマレベル）

4.1 バッグビューの定義

4.1.1 バッグ

 SQL のテーブルはリレーションと異なりタップルの重複出現を許します．タップルの重複出現を許すことで問合せの結果から重複タップルを削除する手間が省けるので（つまりソートや突合せなどの処理を省ける），問合せ処理がリレーションの場合に比べて高速になります．また，タップルの重複出現を許容することで集約関数を駆使できるという利点もあります．反面，SQL のテーブルを格納しておくためにはリレーションに比べて余計に記憶領域を必要とすることは明らかです．
さて，一般に元（element）の重複出現を許す元の集まりをマルチ集合（multiset）あるいはバッグ（bag）といいます．数学ではマルチ集合，SQL ではバッグを用いることが多いので本稿ではバッグとします．タップルの重複出現を許さないリレーションとそれを許すバッグではデータの表現・操作・管理などで違いを生じますが，それはリレーショナルデータモデルは集合意味論（set semantics）に立脚し，SQL はバッグ意味論（bag semantics）に立脚しているからだと表現します．リレーショナルデータモデルでリレーショナル代数（relational algebra）が定義されたと同様に，バッグに対してはバッグ代数（bag algebra）が定義されます [8]．リレーショナル代数表現と同様にバッグ代数表現（bag algebra expression）を定義でき，リレーショナルビューがリレーショナル代数表現で定義されたのと同様に，バッグビュー（bag view）はバッグ代数表現として定義されます．まずはバッグを定義することから始めます．
【定義５】（バッグ）

 バッグ R(A₁, A₂, _…, A_n) は潜在リレーション（concealed relation）R(A₁, A₂, _…, A_n)と重複度関数 m: dom(R)→Z⁺（Z⁺ は正の整数）の組である．ここに dom(R)=dom(A₁)×dom(A₂)×・・・×dom(A_n)とする．

つまり，バッグは R(A₁, A₂, _…, A_n)=(R(A₁, A₂, _…, An), m) と定義されるということです．たとえば，バッグ R(A₁, A₂, _…, A_n) の潜在リレーションを R(A₁, A₂, _…, A_n)= {t₁, t₂, _…, t_p}，重複度関数を m(t_i)=k_i（k_i≧1）とするとき，バッグ R(A₁, A₂, _…, A_n)={t₁(k₁), t₂(k₂), _…, t_p(k_p)} となります．ここに t_i(k_i) はタップル t_i が丁度 k_i 本あることを表すための記法で，k_i はバッグ R 中に生起するタップル t_i の重複度（multiplicity）です．t(k)∈R で重複度 k のタップル t がバッグ R の元であることを表すことにすると，t(k)∈R⇔t∈R∧k=m(t) ということです．バッグ R(A₁, A₂, _…, A_n) ={t₁(k₁), t₂(k₂), _…, t_p(k_p)} は (∀i=1,_..,p)(k_i=1) のときリレーション(＝集合)です．k_i=1 のとき，t_i(1) と書かずに，単に t_i と書くことも多く，また t_i(0) は t_i が存在していないことを意味します．
バッグ R(A₁, A₂, _…, A_n) のドメイン dom(R) は次のように定義されます．dom(R)=dom(R)×
{k|PositiveInteger(k)}=dom(A₁)×dom(A₂)×・・・×dom(A_n)×{k|PositiveInteger(k)}，ここに
PositiveInteger(k) は k が正整数であるとき真となる命題です．ちなみに，(a₁, a₂, _…, a_n, k)∈
dom(R)⇔(a₁, a₂, _…, a_n)(k)∈R と解釈します．

■ 潜在キーと潜在キー制約

バッグはリレーションと違って重複タップルの出現を許すので，バッグの全属性の組をとってきてもタップルの一意識別能力はなく，したがってリレーションのキー（key）に相当する概念はありません．しかしながら，バッグ　R(A₁, A₂, _…, A_n) を定義するために潜在リレーション R(A₁, A₂, _…, A_n) を導入しましたが，R は正真正銘のリレーションなので，R にはキーが存在します．そこで，R のキーを K とし，K をバッグ R の潜在キー（concealed key）と呼ぶことにします．リレーションの主キーと候補キーに対応して潜在主キーと潜在候補キーが定義できます．
潜在キーは一見無秩序に重複タップルの出現を許しているように見えるバッグに「秩序」をもたらしていることになります．換言すれば，潜在キーが K であるバッグ R={t₁(k₁), t₂(k₂), _…, t_p(k_p)} に重複行除去（δ）を施して得られるリレーション δ(R)={t₁, t₂, _…, t_p} のキーは K なので次が成り立ちます．
∀t, t’(t∈δ(R)∧t’∈δ(R)∧t[K]=t’[K]⇒t=t’)
つまり，バッグで重複して出現しているタップル同士のキー値が等しいならばタップルとしては同一だということになります．マルチ集合論では「重複元の識別不可能性」という原理が知られていますが [9]，上記はその原理のデータベース的解釈といえます．
したがって，たとえば，潜在リレーションを社員(社員番号，氏名，所属，給与)，ここに社員番号が主キー，とするバッグ社員(社員番号，氏名，所属，給与) に (007, 山田太郎，K55，50) というタップルは何本出現しても構いませんが，たとえば，(007, 佐藤一郎，K41，50) というタップルがバッグ社員に (007, 山田太郎，K55，50) と共に出現するということはない，ということです．この制約を潜在キー制約（concealed key constraint）と呼ぶことにしますが，これはリレーションでのキー制約に相当する概念で，バッグあるいはバッグビュー更新時の一貫性制約の一つになります．

4.1.2 バッグ代数

 バッグのデータ操作言語であるバッグ代数を定義しますが，以下に示す演算からなります．
【定義６】（バッグ代数）

 一般に，R(A₁, A₂, _…, A_n)={t₁(k₁), t₂(k₂), _…, t_p(k_p)} とS(B₁, B₂, _…, B_m)={u₁(ℓ₁), u₂(ℓ₂), _…, u_q(ℓ_q)} をバッグとするとき，バッグ代数は次に示す演算子からなる．加法和（additive union），モーナス（monus），共通を定義するにあたり R と S は和両立とする．
● 重複行除去（δ）
● 加法和（⨄），モーナス（∸），共通（∩）
● 直積（×）
● 射影（π_X(R)，ここに Ｘ⊆Ω_R）
● 選択（σ_φ (R)，ここに φ は dom(R) 上の選択条件）
● θ-結合（R⨝_AiθBjS，ここに R.A_i と S.B_j は θ-比較可能）

これらの演算子の定義を表 4 で与えます．

補足すれば，バッグ代数に特有な演算として，重複行削除演算（δ），モーナス（∸），加法和（⨄）をあげられます．モーナス（∸）はリレーショナル代数演算の差（－）に対応した演算ですが，タップルの重複度を考慮しています．マルチ集合論では和には加法和とは別に最大和（maximum union，∪）を定義することもできます．その定義は R∪S={t(k)|∃t(k_i)∈R∧∃t(ℓ_j)∈S∧k= max(k_i, ℓ_j)} で，リレーショナル代数の和（∪）はバッグ代数の最大和と両立する演算です．しかしながら，
一般にタップルの重複出現を許す SQL のテーブルの UNION ALLを念頭においている和は加法和です．
SQL との対応付けをすると，重複行削除演算は SQL の SELECT DISTINCT * FROM R に相当します．加法和，モーナス，共通はそれぞれ SQL の UNION ALL，EXCEPT ALL，INTERSECT ALL に相当します．直積，選択，射影，θ-結合の演算結果から重複行は削除されず SQL の SELECT ALL の意味を持っています．上記の演算はお互いに独立ではなく，たとえば，重複行除去，加法和，差，直積，射影，選択の 6 つの演算は互いに独立です．独立でない演算子を許容しているのはその有用性によります．
なお，R, S をバッグ，ψ, φ を述語としたとき，次の性質が成り立ちます [8]．このような性質はバッグ代数で成り立つので，リレーショナル代数でも成り立ちます．
● σ_ψ∨φ(R)=σ_ψ(R) ⨄σ_φ(R)
● σ_ψ∧φ(R)=σ_ψ(R)∩σ_φ(R)
● σ_¬φ(R)=R∸σ_φ(R)
● δ(σ_φ(R))=σ_φ(δ(R))

バッグ代数でもバッグのタップルの属性が null をとることがありうるので，バッグ代数演算もリレーショナル代数の時と同じように（3.1.1 項），3 値論理に拡張されて，推量 θ-選択や推量 θ-結合が定義できます．

4.1.3 バッグ代数表現としてのバッグビュー

 リレーショナルデータベースに対する問合せがリレーショナル代数表現として記述できたのと同様に，バッグデータベースに対する問合せはバッグ代数表現として記述できます．したがって，定義 4 でリレーショナルビューを定義したのと同様に，バッグビューはバッグ代数表現として次のように定義できます．データベースに格納されているバッグを実バッグといいます．
【定義７】（バッグビュー）

 (1)

実バッグはバッグビューである．

 (2)

V をバッグビューとし，δを重複行除去とするとき，δ(V) はバッグビューである（重複行除去ビュー）．

 (3)

V₁ と V₂ を和両立なバッグビューとするとき，それらの加法和 V₁⨄V₂ はバッグビューである（加法和ビュー）．

 (4)

V₁ と V₂ を和両立なバッグビューとするとき，それらのモーナス V₁∸V₂ はバッグビューである（モーナスビュー）．

 (5)

V₁ と V₂ をバッグビューとするとき，それらの直積 V₁×V₂ はバッグビューである（バッグ直積ビュー）．

 (6)

V をバッグビューとするとき，その射影 π_X(V) はバッグビューである（バッグ射影ビュー）．

 (7)

V をバッグビューとするとき，その選択 σ_φ(V) はバッグビューである（バッグ選択ビュー）．

 (8)

(1)～(6) で定義されるもののみがバッグビューである．

基本的バッグビューと一般的バッグビューという用語も基本的リレーショナルビューと一般的リレーショナルビューに準じて使用します．以下，特に混乱が生じないと考えられる場合にはバッグビューを単にビューと記すこともあります．

4.2 バッグビューの更新

 バッグビュー V に対する削除や挿入に対する形式や考え方はリレーショナルビューに対する削除や挿入と基本的には同一ですが，削除では差に代わりモーナスが，挿入では和に代わり加法和がその定義に用いられるところが異なります．書換を削除と挿入の系列と定義することや注意点はリレーショナルビューに対する場合と同様です．
削除（d）：deleteσ_φ(V) from V; ここに φ は dom(V) の元を引数とする述語である．
挿入（i）：insert X into V; ここに X⊆dom(V) とする．
● 削除の定義は V←V∸σ_φ(V) です．モーナスが使われているとことに注意します．
● 挿入の定義は V←V⨄X です．加法和が使われているとことに注意します．

ここで，バッグビューのドメインについて補足をします．

■ バッグビューのドメインについて

4.1.1 項で，バッグ R(A₁, A₂, _…, A_n) のドメインは dom(R)=dom(A₁)×dom(A₂)×・・・×dom(A_n)×{k|PositiveInteger(k)} と定義されました．バッグビューのドメインもその延長線上にありますが，（リレーショナルビューのときと同様に）ビュー定義が勘案されます．つまり，バッグビューを V(A_1’, A_2’, _…, A_r’) としたとき，V のドメインは一般には dom(V)=dom(A_1’)×dom(A_2’)×・・・×dom(A_r’)×{k|PositiveInteger(k)} とはならず，ビュー定義を満たすその部分集合になります．幾つか例題で見ていくと次の通りです．
まず，バッグ R(A₁, A₂, _…, A_n) の重複行削除ビュー V=δ(R) のドメインは dom(V)= dom(A₁)×
dom(A₂)×・・・×dom(A_n)×{1} です．R と S を和両立とするとき加法和ビュー V=R⨄S やモーナスビュー V=R∸S のドメインは dom(V)=dom(R)×{k|PositiveInteger(k)} です．バッグ R と S の直積ビュー V=R×S のドメインは dom(V)=dom(R)×dom(S)×{k|PositiveInteger(k)} です．バッグ R(A₁, A₂, _…, A_n) の属性集合 X（⊆Ω_R），ここに Ω_R={A₁, A₂, _…, A_n}，上の射影ビュー V=π_X(R) のドメインは，X={A_1’, A_2’, _…, A_r’}，ここに 1≦1’≦2’≦…≦r’≦n，として dom(V)=dom(A_1’)×dom(A_2’)×･･･×dom(A_r’)×{k|PositiveInteger(k)} となります．バッグ R(A, B) のバッグ選択ビューを V=σ_B≦b(R) としたとき，dom(V)=dom(A)×σ_B≦b(dom(B))×{k|PositiveInteger(k)} となります．バッグ R(A, B) と S(B,C) の等結合ビュー V(A, R.B, S.B, C)=R⨝_R.B=S.BS のドメインは dom(V)=σ_R.B=S.B(dom(A)×
dom(R.B)×dom(S.B)×dom(C))×{k|PositiveInteger(k)} となります．このようにビューのドメインはいずれもビュー定義が勘案されて定義されます．なお，クライアントにはビューの定義を考慮したうえでそれに抵触しない挿入を発行しなければならないという負担がかかることはリレーショナルビューの場合と同じです．

4.3 基本的バッグビューの更新可能性（スキーマレベル）

 リレーショナルビューが集合意味論に立脚し，バッグビューはバッグ意味論に立脚している点は異なりますが，ビューの更新可能性は定義 1 で与えた通りです．つまり，バッグビュー V への更新 u は，(a) 一意で，(b) 副作用がなく，(c) 余計な更新がない変換 T が存在するとき更新可能であること定義されます．ただ，上述のように，削除にはモーナスが，挿入には加法和が用いられるところが異なります．また，バッグにはそれを定義するための潜在リレーションが存在する点もバッグビューの更新可能性に影響を与えます．なお，本稿ではスキーマレベルでビューの更新可能性を論じているので，リレーショナルビューの場合と同様な理由で，定義 1 の条件 (d) は不問に付しています．

さて，基本的バッグビューの更新可能性（スキーマレベル）をリレーショナル代数の場合と同様なアプローチで解明していきますが，ここで大事なことは次の命題が成立することです．

「リレーション（＝集合）はバッグの特殊な場合なので，バッグで成り立つ性質はリレーションでも成り立つが，リレーションで成り立つ性質が必ずしもバッグで成り立つとは限らない」

したがって，表 3 で〇（更新可能）となっている場合でも，それはリレーショナルビューに対する結果なので，それに対応するバッグ代数でのビューの更新可能性がまた〇になるかどうかは分かりません．一方，表3で×（更新不可能）となっている性質がバッグビューで〇となることはないわけですから，バッグビューの更新可能性はリレーショナルビューのそれに比べて限定的となります．
以下，表 5 にバッグビューの更新可能性を検証した結果を示すと共に，その論拠を示します．

【1】重複行削除ビューは削除可能

 一般にバッグ R={t₁(k₁), t₂(k₂), _…, t_p(k_p)} の重複行除去ビュー δ(R)={t₁, t₂, _…, t_p} に対して，削除 d=delete σ_φ(δ(R)) from δ(R); が発行されたとする．
そこで，σ_φ(δ(R)) ={t_1’, t_2’, _…, t_q’}，1≦1’＜2’＜_…＜q’≦pとするとき，削除 d を R への削除 T(d)=delete {t_1’(k_1’), t_2’(k_2’), _…, t_q’(k_q’)} from R; 変換する．このとき，δ(R∸{t_1’(k_1’), t_2’(k_2’), _…, t_q’(k_q’)})=δ(R) ∸{t_1’, t_2’, _…, t_q’}=δ(R)∸σ_φ(δ(R)) である．これはすべてのバッグ R と任意の削除 d に対して成立するので，「重複行削除ビューは削除可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

【2】重複行削除ビューは挿入不可能

 挿入不可能な重複行削除ビューの例を示す．たとえば，バッグ R={(1)(3)} の重複行除去ビュー δ(R)={(1)} に対して，挿入 i=insert {(2)} into δ(R) が発行されたとする．すると，i の R への変換は次のように無数に存在し一意ではない．したがって，「重複行削除ビューは挿入不可能である」という命題がスキーマレベルで成立する．
T_k(i)=insert {(2)(k)} into R; ここに k=1, 2, 3, _…

したがって，「重複行削除ビューは書換不可能である」という命題がスキーマレベルで成立する．

【3】加法和（⨄）ビューは削除可能

 加法和ビューを V=R⨄S とし，削除 d=deleteσ_φ(V) from V; が発行されたとき，削除の定義から次が成り立つ．
V∸σ_φ(V)= (R⨄S)∸σ_φ(R⨄S)=σ_¬φ(R⨄S)=σ_¬φ(R)⨄σ_¬φ(S) = (R∸σ_φ(R)) ⨄ (S∸σ_φ(S))．
したがって，削除 d= deleteσ_φ(V) from V; を実現するための必要かつ十分条件は d を T(d)に変換することである．
T(d)=begin; deleteσ_φ(R) from R; deleteσ_φ(S) from S; end;
このことはすべてのバッグ R, S, φ と任意の削除 d に対して成立するので，「加法和ビューは削除可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

なお，σ_φ(R⨄S)=σ_φ(R) ⨄σ_φ(S) の証明は次の通りである．
【命題１】σ_φ(R⨄S)=σ_φ(R) ⨄σ_φ(S) が成立する．
（証明）t(k)∈σ_φ(R⨄S) とすると，∃t(k_i)∈R∧∃t(ℓ_j)∈S∧k=k_i＋ℓ_j∧φ(t) が成り立つ．φ(t)=φ(t)∧φ(t) なので，(∃t(k_i)∈R∧φ(t))∧(∃t(ℓ_j)∈S∧φ(t))∧k= k_i＋ℓ_j が成り立つ．すなわち，∃t(k_i)∈σ_φ(R)∧∃t(ℓ_j)∈σ_φ(S)∧k= k_i＋ℓ_j が成り立つ．したがって，⨄ の定義により，
t(k)∈σ_φ(R) ⨄σ_φ(S) が成り立つ．逆に t(k)∈σ_φ(R) ⨄σ_φ(S) とすると，上記の逆の推論をたどることで t(k)∈σ_φ(R⨄S) であることを示せる．

Q.E.D.

【4】加法和（⨄）ビューは挿入不可能

 加法和ビューとそれに対して発行された挿入が変換不可能な一例を示す．
たとえば，和両立なバッグ R と S を R={(1)(3)}, S={(1)(2)} とするとき，加法和ビュー V=R⨄SはV={(1)(5)} である．このとき，V に対して挿入 i=insert {(2)(1)} into V; が発行されたとする．すると，i の変換は次の 2 通り考えられる．
T₁(i)=insert {(2)(1)} into R;
T₂(i)=insert {(2)(1)} into S;
このように変換に一意性がないので，「加法和ビューは挿入不可能である」という命題がスキーマレベルで成立する．

したがって，「加法和（⨄）ビューは書換不可能である」という命題がスキーマレベルで成立する．

【5】モーナス（∸）ビューは挿入不可能

 モーナスビューとそれに対して発行された挿入が変換不可能な一例を示す．
和両立なバッグ R と S を，たとえば R={(1)(3)}, S={(1)(2)} とするとき，モーナスビュー V=R∸S は V={(1)(1)} である．このとき，V に対して挿入 i=insert {(1)(2)} into V; が発行されたとする．すると，i の変換は次のように無数にあり一意ではない．
T_k(i)=begin; insert {(1)(2+k)} into R; insert {(1)(k)} into S; end; ここに k=0, 1, 2, 3, _…
したがって，i は変換可能ではない．このように反例を示せるので，「モーナスビューは挿入不可能である」という命題がスキーマレベルで成立する．

したがって，「モーナスビューは書換不可能である」という命題がスキーマレベルで成立する．

【6】バッグ共通ビューは挿入不可能

 バッグ共通ビューとそれに対して発行された挿入が変換不可能な一例を示す．
和両立なバッグ R と S を，たとえば R={(1)(3)}, S={(1)(2)} とするとき，V=R∩S={(1)(2)} である．このとき，V に対して挿入 i=insert {(1)(1)} into V; が発行されたとすると，i の変換は次の 2 通り考えられる．
T₁(i)=insert {(1)(1)} into S;
T₂(i)=begin; insert {(1)(1)} into R; insert {(1)(1)} into S; end;
つまり，変換は一意ではなく i は変換可能ではない．このように反例を示せるので，「バッグ共通ビューは挿入不可能である」という命題がスキーマレベルで成立する．

したがって，「バッグ共通ビューは書換不可能である」という命題がスキーマレベルで成立する．

【7】バッグ射影ビューは削除可能

 バッグ R の属性集合 X 上のバッグ射影ビューを V=π_X(R) とし，V へ削除 d= deleteσ_φ(V) from V; が発行されたとする．このとき σ_φ(V)=σ_φ(π_X(R)) である．
ところで，σ_φ(π_X(R))= π_X(σ_φ(R)) が成立する．
d: V←V∸σ_φ(V) であるから，V=V∸σ_φ(V)= π_X(R)∸π_X(σ_φ(R))= π_X(R∸σ_φ(R)) が成立する．したがって，d を実現するための必要かつ十分条件はそれを T(d) に変換することである．
T(d)=deleteσ_φ(R) from R;
このことはすべてのバッグ R, S, φ と任意の削除 d に対して成立するので，「バッグ射影ビューは削除可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

バッグ射影ビューとそれに対して発行された削除が変換可能な一例を示す．
【例題７】
バッグ　R(A, B)={(1, 1), (1, 2), (1, 3), (2, 1), (2, 2)}　とし，V=π_{A}(R)={(1)(3), (2)(2)} を R の {A} 上のバッグ射影ビューとする．このとき，V へ削除 d=delete σ_φ(V) from V; ここに φ=(A=1)，が発行されたとするとき，一意で副作用がなく余分な更新をしない d の変換は次の通りである．
T(d)=delete σ_A=1(R) from R;

【8】バッグ射影ビューは潜在キー保存ならば挿入可能

 バッグ R の属性集合 X 上のバッグ射影ビューを V=π_X(R) とするとき，バッグ射影ビュー V が潜在キー保存（concealed key preservation）であるとは，X がバッグ R の潜在主キー K を含むときをいう．
バッグ R の属性集合 X 上のバッグ射影ビューを V=π_X(R) とする．V への挿入 i=insert W into V; が発行されたとする．ここに W={w₁(k₁), w₂(k₂), _…, w_m(k_m)}，∀i((w_i, k_i)∈dom(V)) とする．
このとき，W からバッグ W～ を次のように生成する．ここに null は空を表す．
W～={w~₁(k₁), w~₂(k₂), _…, w~_m(k_m)}，ここに w~_i[X]=w_i かつ w~_i[ Ω_R－X]=(null, null, _…, null) とする．
このとき，V が潜在キー保存であるとすると，X は R の潜在主キー K を含み，潜在主キー属性が null をとることはないから，W と W～ の間には w(k)w~(k) という 1 対 1 の関係性が成立する．
また，π_X(R⨄W～)=π_X(R) ⨄π_X(W～)=π_X(R) ⨄W=V⨄W が成立するので，i を実現するための必要かつ十分条件は i を T(i)に変換することであることが分かる．
T(i)=insert W～ into R;
これは全てのバッグ射影ビュー V と挿入 i に対して成立するので，「バッグ射影ビューは潜在キー保存であれば挿入可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

したがって，「バッグ射影ビューは潜在キー保存ならば書換可能である」という命題がスキーマレベルで成立する．

なお，「潜在キー保存」という条件自体はスキーマレベルの検証であるが，この検証を通過しただけでは「潜在キー制約」に抵触してしまう可能性がある．そのためにはインスタンスレベルの検証が必須となることは，3.2 節【10】項「射影ビューはキー保存ならば更新可能」のところで指摘したことと同様である．

【9】バッグ選択ビューは削除可能

 バッグ R のバッグ選択ビューを V=σ_φ (R) とし，V への削除 d=deleteσ_ψ(V) from V; が発行されたとする．ここに ψ は探索条件である．X=σ_ψ(V) とすると，V=σ_φ (R) なので，X=σ_ψ(V)=σ_ψ(σ_φ (R))=σ_ψ∧φ (R)となる．
そこで，d を次に示す T(d) に変換する．
T(d)=deleteσ_ψ∧φ(R) from R;
このとき，
σ_φ(R∸σ_ψ∧φ(R))=σ_φ(R)∸σ_φ(σ_ψ∧φ(R)))=σ_φ(R)∸σ_ψ∧φ(R)=σ_φ(R)∸σ_ψ(σ_φ(R))=V∸σ_ψ(V) が成立する．
この性質は全てのバッグ選択ビュー V と削除 d に対して成立するので，「バッグ選択ビューは削除可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

【10】バッグ選択ビューは挿入可能

 バッグ R のバッグ選択ビューを V=σ_φ (R) とし，V への挿入 i=insert X into V; ここに X⊆dom(V) が発行されたとする．dom(V)= dom(σ_φ(R))=σ_φ(dom(R)) なので，X⊆σ_φ(dom(R)) である．このとき，σ_φ(σ_φ(dom(R)))=σ_φ(dom(R)) なので，σ_φ (X)=X である．
そこで，i を T(i) に変換する．
T(i)=insert X into R;
このとき，σ_φ (R ⨄X)=σ_φ (R) ⨄σ_φ (X)=V ⨄X が成立する．
この性質は全てのバッグ選択ビュー V と挿入 i に対して成立するので，「バッグ選択ビューは挿入可能である」という命題がスキーマレベルで成立する．なお，T が定義 1 の条件 (a)～(c) を満たしていることはその定義から明らかである．

したがって，「バッグ選択ビューは書換可能である」という命題がスキーマレベルで成立する．

【11】バッグ θ-結合ビューは削除・挿入・書換不可能

 バッグ θ-結合ビューの更新可能性については，リレーショナル代数での θ-結合ビューの更新可能性がスキーマレベルで削除，挿入，いずれも不可能なので，バッグビューのそれについても不可能となる．

4.4 一般的バッグビューの更新可能性（スキーマレベル）

 表 5「基本的バッグビューの更新可能性（スキーマレベル）」は 4.3 節の議論の結果をまとめたものです．一般的バッグビューの更新可能性の判定は，3.3 節で論じた一般的リレーショナルビューの更新判定と全く同じように，作成した一般的バッグビューの定義木をトップダウンに，たとえば幅優先探索で走査しながら，ノードごとでその更新可能性を表 5 に参照していけば，その更新可能性をスキーマレベルで検証することができます．

5．おわりに

 本稿ではリレーショナルビューとバッグビューの更新可能性をスキーマレベルで論じその全貌を明らかにしました．集合であればバッグですが，逆は成立しないので，当然のこととして，リレーショナルビューが更新可能であっても，それを潜在リレーションとするバッグビューが更新可能となる保証はありません．その違いは表 3 と表 5 を比較することで一目瞭然かと思います．
末筆ながら，理論と実践のはざまに言及しておくと次のとおりです．SQL はバッグ意味論に基づいたリレーショナルデータベース言語なので，SQL でのビューの更新可能性は本稿の表 5 に示したバッグビューの更新可能性に基づき規格化されてしかるべきす．しかしながら，現実には SQL が理論に先行してしまいました．それには歴史的理由があって，バッグビューの更新可能性の理論的研究は 1990 年代に入ってから盛んになったのですが，ビューとその更新可能性の重要性をいち早く認識していた SQL はその初めての国際標準規格である SQL-87 を制定した 1987 年時点でその規格化の第一歩を踏み出していました．そこでの原則は極めて現実的で，SQL-87 を改正した SQL-92 に見るように「更新が可能なビューは，実表から選択または射影だけを行っており，ビュー表の行および列が基となる実表の行および列と 1 対 1 に対応している場合である」というものでした．SQL-87 は SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2011 等を経て最新規格の SQL:2016 まで改正され続け，少しでも多様なビューを更新可能にしようとビューとその更新可能性の規格も改正され続けてきましたが，「1 対 1 の対応」という基本的考え方に変更はないようです．本稿で論じたように，バッグビューの更新可能性はあくまで理論的であってそのような呪縛とは無縁です．SQL:2023 が近々発表されるようですが，何か変化はあるのでしょうか，注目したいと思います．
なお，本稿ではビューの更新可能性をスキーマレベルで論じましたが，その対極にある「インスタンスレベルアプローチ」や「SQL のビューサポート」については機会を得て報告できればと思います．

【文献】

[1]

Edgar F. Codd. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, Vol.13, No.6, pp.377-387, 1970.

[2]

Edgar F. Codd. Recent Investigations in Relational Database Systems. Information Processing 74, pp. 1017-1021, North-Holland, 1974.

[3]

Michael Stonebraker, Eugene Wong, Peter Kreps, and Gerald Held. The Design and Implementation of INGRES. ACM Transactions on Database Systems, Vol. 1, No. 3, pp. 189-222, September 1976.

[4]

Umeshwar Dayal and Philip A. Bernstein. On the Updatability of Relational Views. Proceeding of VLDB 1978, pp.368-377, 1978.

[5]

Edgar F. Codd. Extending the Database Relational Model to Capture More Meaning. ACM TODS, Vol.4, No.4, pp.397-434, 1979.

[6]

増永 良文，長田 悠吾，石井 達夫. 更新意図の外形的推測に基づいたビューの更新可能性とその PostgreSQL 上での実現可能性検証. 日本データベース学会和文論文誌 Vol.18-J, Article No.1, 2020 年 3 月．

[7]

増永 良文，長田 悠吾，石井 達夫. 整合ラベリング問題としてのクロス結合ビューの更新可能性. 日本データベース学会和文論文誌 Vol.19-J, Article No.1, 2021 年 3 月．

[8]

Joseph Albert. Algebraic Properties of Bag Data Types. Proceedings of the 17th International Conference on Very Large Databases, pp.211-219, 1991．

[9]

Wayne D. Blizard. Multiset Thoery. Notre Dame Journal of Formal Logic, Vol.30, No.1. pp.36-66, Winter 1989.

[10]

増永良文．リレーショナルデータベース入門[第3版]，サイエンス社，2017．

1. はじめに

 ビッグデータの管理・運用で注目を浴びることとなった結果整合性（eventual consistency）ですが，賛否両論あるようです．否定的な意見は，たとえば，クレップマン（Martin Kleppmann）[1]の
著作に見ることができます．この著作，結構多くの方々がお持ちかと思いますが，クレップマンは複
製を行うデータベースのほとんどは，少なくとも結果整合性を提供しているとしながらも，これは非
常に弱い保障であり，複製がいつ（最終値に）収束するのかについては何も語られていなく，収束す
るときまで，読取りの結果が何になるのか，あるいはそもそも何も返さないのかは分からない，とク
レームしています．さらに，CAP 定理の対象範囲は非常に狭く，考慮しているのは 1 つの一貫性モ
デルと 1 種類のフォールト（つまり，ネットワーク分断）だけで，ネットワークの遅延，落ちている
ノード，あるいは他のトレードオフについては何も語っていない．したがって，CAP 定理は歴史的
には大きな影響力があったものの，システムの設計における実際的な価値はほとんどない，と述べて
います（文献[1]の 9 章「一貫性と合意」）．

 このクレップマンの否定的意見は，読取りの結果が何であるのか分からない，CAP 定理に実際的
価値はない，の 2 つに集約されると思いますが，まず，最初のクレームについて考えてみましょう．
確かに，結果整合性は，「非常に」かどうかは別にして，「弱い保証である」ことに間違いはあり
ません．整合性には強い整合性と弱い整合性があり，結果整合性は弱い整合性の一種であることは，
結果整合性の提案者であるフォーゲルス（Werner Vogels）自身も述べている通りです[2]．結果整
合性は Amazon.com, Inc.（以下，Amazon）が開発した「高可用キー・バリューストア」Dynamo[3]
で初めて実装されましたが，フォーゲルスはその開発プロジェクトの中心人物でした（この Dynamo
は Amazon の自社用で，AWS の一環として提供されている Amazon DynamoDB とは別物）．複製
が最終値に収束するまでの時間を不整合窓（inconsistent window）といいますが，フォーゲルスに
よれば，不整合窓の最大サイズは，通信の遅延，システムの負荷，レプリケーションスキームに含ま
れる複製の数などの要因に基づいて決定できるとのことです．したがって，これはシステムの負荷や
ネットワーク環境が安定しているときは一定の値を保つかもしれませんが，それらが変動すれば当然
変動するだろうことは想像に難くなく，クレップマンの最初のクレームを理不尽と決めつけるわけに
はいきません．
 では，実際に結果整合性を実装したシステムでは不整合窓の長さについてどのような評価がなされ
ているのでしょうか？これに関して，次のような見解を見ることができます．
 まず，N，W，R を次のように定めます．
   N：データの複製を格納しているノードの数（＝複製数）
   W：更新完了の返事を返してくるべき複製の数
   R：検索結果を返してくるべき複製の数
 N，W，R はいかようにも定められますが，結果整合性を念頭に，N=3，W=1，R=1 と設定したシステムでは，可用性と一貫性が共に満たされているとの報告が見受けられます．つまり，W=1，R=1 なので高可用性の実現はその通りですが，一貫性も評価される原因としては，N=3 と複製数が小さいことや，新鮮でないデータでもそんなに腐臭が漂っているわけではないとの見解です．また，不整合窓の長さについては，実測で数 ms（millisecond）という報告もあれば，数 1,000ms という報告も見受けられます．これらの値が許容範囲にあるのかそうでないのかは定かではありませんが，不整合窓が長くてシステムが稼働しないといった報告は見つかりません．したがって，クレップマンが「読取りの結果が何であるのか分からない」としたクレームは，観念的にはそうなのだけれども実際にはその非難は当たっていないのではないか，と言えそうです．
 次に，クレップマンが「CAP 定理に実際的価値はない」とクレームしている点についてですが，
CAP 定理の主張する CP あるいは AP の選択で（詳細は 4 章），可用性（A）とネットワークの分断
耐性（P）を選択した Amazon の Dynamo が顧客から間断なく舞い込む注文をこれまで処理し続けてこられたという実績はクレップマンの否定的な意見を覆すに十分な反証となっているのではないかと思います．最近の統計によれば，Amazon 本体（サードパーティの販売者によるマーケットプレイスは除くという意味）が扱っている商品数は約 1,200 万，毎月の顧客数は約 1 億，1 分あたりに売れる商品の数は約 4,000 という状況のようです．それを結果整合性のもとで，Amazon の Dynamo は always-on で処理し続けているわけです．
 本稿は，以上のような観点から，結果整合性の意義を ACIDアシッド vs. BASEベース という論点とも絡めながら再検討しておきたいと思います．

2. 結果整合性誕生は時代の必然

 筆者は結果整合性という概念の誕生は，分散型データベースシステムの概念がウェブそしてビッグデータの到来で根底から変化することになった所産だと捉えています．
 歴史的には，分散型データベースシステムは 1970 年代後半から 1980 年代にかけて IBM Sanサン Joseホゼ 研究所で研究・開発された System R * アールスター[4]をもってその嚆矢とすると認識しています．この時代の分散型データベースシステムの使命は遠隔地に散在するビジネスデータをコンピュータネットワークを介して相互アクセスし，いかにして「単一サイトイメージ」を実現するかが設計指針でした．言い換えれば「分散の透明性」の達成です．したがって，分散型データベースシステムはトランザクション処理に関してもあたかも単一サイトのイメージでそれを処理するわけですから，結果整合性などという発想は一切湧かず，単一サイトのデータベースシステムと同様に ACID 特性を堅持することが大前提となっていたわけです．
 しかしながら，ウェブの誕生以降状況は徐々に変化していきます．ウェブは 1991 年をもってその元年としますが，その後進化をとげて 2005 年にオライリー（Tim O’Reilly）により Web 2.0 が提唱されました[5]．これには経緯があって，その背景には「ドットコムバブルの崩壊」があります．つまり，ウェブ誕生後数年を経た 1995 年頃から 2000 年頃にかけて米国の株式市場はドットコムバブルに沸き返っていました．ドットコム（.com）とは営利企業を表す分野別トップレベルドメイン（generic TLD）で，（ハイテク中心の）ドットコムカンパニーの NASDAQ 指数は 2000 年 4 月 10 日に 5,048 で史上最高となったわけです．インターネット関連ベンチャー企業が株式を上場すれば，期待感から高値で取引されたといわれています．しかし，2000 年に入ると，次第にこれらのベンチャー企業の優勝劣敗が明らかになり，見込みのないベンチャー企業が次々と破たんするようになり，熱狂は一挙に冷めて株価は大暴落し，2001 年秋にバブルは崩壊しました．ドットコムバブルがはじけて，多くのウェブ関連ベンチャー企業が泡沫のごとくこの世から消え去ったのですが，その洗礼を受けつつもその後も成長し続けたベンチャー企業がありました．それらは泡沫のごとく消え去ったベンチャー企業とどこが違っていたのか？オライリーのチームは両者のビジネスモデルの違いに着目して，ブレインストーミングを重ね，その結果が Web 2.0 としてまとめられたというわけですが，ドットコムバブルの荒波を越えて生き残った代表格が Amazon や Google というわけです．
 その Amazon が自社のビジネスモデルを達成せんがために構築した分散型データストア（distributed data store, DDS）が Dynamo で，そこで実装されたトランザクション管理の原理が従来の ACID 特性ではなく，結果整合性に基づいた BASE 特性であったということです．いみじくも，Dynamo の開発責任者であったフォーゲルは “Building reliable distributed systems at a worldwide scale demands trade-offs—between consistency and availability.”[2]と結果整合性の意義を述べていますが，この一文が従来の分散型データベースシステムとビッグデータ時代の分散型データベースシステムの構築原理の違いを端的に表していると思います．

3. 分散型データストア

 3V（volume, velocity, variety）の性質を有するビッグデータをリレーショナル DBMS で管理・運用しようとすると，たとえばリレーションがとても疎（sparse）になるとか，さまざまな問題が生じて限界があることはよく知られているところです．したがってそのようなデータはビッグデータを扱う各組織体のビジネスモデルに一番合うような形で管理・運用されることが常となりました．たとえば，
Amazon はキー・バリューデータストアを，Google は列ファミリデータストアを，大量の JSON 文書を管理・運用したい組織は文書データストアを，そして，たとえば大規模なソーシャルネットワークを管理・運用したい組織はグラフデータベースを開発するといった具合です．その具体例が，Amazon
の Dymano や Google の BigTable[6]ということになるわけですが，NoSQL（Not only SQL の意）とはこのようなシステムの総称です．
 さて，いわゆる NoSQL を標榜するシステムですが，スケーラビリティを（スケールアップではなく）スケールアウトで達成すること，システムは大規模となり個々のコンポーネントにあまりお金は掛けられないこと，システムが大規模になっても可用性は損ないたくないことなどを勘案すると，図 1 に示されるような疎結合クラスタ（shared nothing cluster）構成をとる分散型データストアとするのが一般的です．
 少しく説明を加えると，1 台のマスタが複数のクライアントとスレーブを管理します．クライアントからの問合せ（query）や更新要求（insert, delete, update）はマスタに届けられ，マスタはマスタの判断でそれらをスレーブに配信し，その結果をクライアントに届けます．疎結合クラスタ構成をとっているので，データ量が増大するにつれてスレーブを増設していけばシステムのスケーラビリティを台数効果に基づきスケールアウトで達成できます．また，可用性やネットワークの分断耐性を向上させるためにデータは複製（replica，レプリカ）を作成してそれをスレーブに分散配置します．しかしながら，データが重複してスレーブに分散配置されることで，データの一貫性をどのようにして達成するのかが問われることになります．本稿で取り上げている結果整合性はそのために考案されたトランザクション管理のための新しい原理ということです．なお，図 1 ではクライアントがマスタやスレーブと同じネットワークに結合されているので，ネットワーク分断が発生したときにクライアントとマスタが通信できなくなりますが，ここではそれは何らかの手段で確保されていることとします．論点は，ネットワーク分断が発生した場合にマスタと一部のスレーブとの間の通信が不可能となりますが，それがデータベースの可用性と一貫性にどのような影響を与えるのかにあります．

4. CAP 定理

 分散型コンピューティングの強靭きょうじん性に関して，Inktomi 社の創設者であったブルーワ（Eric Brewer）は次のような経験則を 2000 年に開催された国際会議で発表しました[8]．

  「一貫性，可用性，そしてネットワークの分断耐性の間には基本的にトレードオフがある」

 改めて記しますが，一貫性（consistency）とは，書込み操作が完了したのちに読取り操作を発行すれば，その書込みの結果が返されないといけないということで，もしデータを複製して管理している場合には，複製間で更新の同期がとられていて，どの複製を読もうとも，同じ値が返ってこないといけないことを意味します．可用性（availability）とは，クライアントが依頼した読取りや書込みに対して，それが無視されることはなく，いづれ応答があるということをいいます．ネットワークの分断耐性（tolerance to network partitions あるいは partition tolerance）とは，サーバ間でやり取りするメッセージがいくらでも失われうることを意味します．つまり，本来ネットワークは分断されてしまうかもしれないという性質を有するので，ネットワーク分断が発生した状況の中にあっても分散型コンピューティングはそれなりに機能しないといけないということを謳うたっているものです．そして，ブルーワはこのトレードオフの意味するところを CAP 定理（CAP theorem）と名付けました．ここに，CAP の C は Consistency，A は Availability，P は Partition tolerance の頭文字です．この定理は，発表当初はあくまで推測（conjecture）にしか過ぎなかったのですが，2 年後にその証明が与えられました[9]．証明は拙著[7]でも与えられているので興味があれば参照してください．

【定理１】（CAP 定理）^[8]
 共有データシステムにおいては，一貫性，可用性，分断耐性という 3 つの性質のうち，高々 2 つしか両立させることが出来ない．

 CAP 定理を図示すると図 2 のように描けます．

 ネットワークは分断するものですから，つまりネットワークが絶対に故障しないという保証を与えることはできないので，共有データシステムはネットワーク分断を前提に，システムとして一貫性（C）の実現を選択しますか？それとも可用性（A）の実現を選択しますか？どちらを採りますか？という選択を迫られることになります．つまり，次に示す二者択一となるわけです．
   ●　CP：一貫性と分断耐性を実現する．
   ●　AP：可用性と分断耐性を実現する．
 なお，念のために，両選択の違いを例題で見ておくと次の通りです（AP については第 6 章でさらに議論します）．

【例題１】（CP vs. AP）
 図 1 に示した構成でスレーブ _i とスレーブ _i+1 間のネットワークが分断されてしまったとき，CP と AP のもとでシステムがどのように振舞うのかを検証する（ここに，i≦n－1）．
 ●　CP を採用した場合

そのようなネットワークの分断が発生すると，スレーブ 1 ～スレーブ i 群とスレーブ i+1 ～スレーブ n 群は通信不可となる，つまり両群にまたがり存在する同一データの複製間の一貫性を保証する手段がなくなるので，システムはネットワーク分断を検知した時点で停止し，読取り要求も書込み要求も受け付けず，ネットワーク分断の回復を待つ．

 ●　AP を採用した場合

マスタはスレーブ １ ～スレーブ i にアクセスし，N（データの複製数），R（検索結果を返してくるべき複製の数）や W（更新完了の返事を返してくるべき複製の数）が定める定足数に従い行動する．読取り要求の場合，検索されたデータがスレーブ １ ～スレーブ i にあり，その数が R 以上であればそれをクライアントに返す（複数見つかれば時刻印が最新のデータを返す）．書込み要求の場合，マスタはスレーブ １ ～スレーブ i にその書込み要求を発行する．もし，書込み完了の返事の数が W 以上となれば書込みが完了した旨をクライアントに報告する．そうでなければ，書込み失敗をクライアントに報告する．前者の場合，複製の数は N（≧W）なので，報告時点で書込みが完了していない複製がスレーブ 1 ～スレーブ i 群とスレーブ i+1 ～スレーブ n 群に存在する可能性がある．これらの複製の書込みは遅延複製（lazy replication）[2, 10]で行う．つまり，書込みが可能となり次第，順次更新していく．

 このように，どちらを選択するかで，システムの振舞はがらりと変わってきます．具体的には，先述の通り，CP の選択肢を採ったのが Google の Bigtable であり，AP の選択肢を採ったのが Amazon の Dynamo ということです．Bigtable では分散したデータの複製の更新同期をとり一貫性を実現するために Paxos アルゴリズムが使われています．では，Dynamo は AP を実現するためにどのようなシステムアーキテクチャを開発したのでしょうか？それを以下に見てみます．

5. BASE 特性

 CAP 定理により，ネットワークの分断が発生しても，可用性を採るとマスタはアクセスできるスレーブから所望のデータを読み書きできます．しかしながら，読み書きの対象となったデータが最新のデータであるかどうか，つまり一貫性のあるデータであるか否かの保証はありません．つまり，可用性を採ると，ネットワーク分断によりデータには更新されて新値を採るデータと旧値のままのデータが混在することとなり，データベースが一貫している保証はありません．つまり，この状況下では従来のトランザクション管理が金科玉条のごとく信奉してきた ACID 特性という概念が無意味化しているといえます．
 では，可用性とネットワークの分断耐性（AP）を採ったシステムは一体どういう特性を満たしているといえるのでしょうか？それが，結果整合性に基づいた BASE 特性であるわけです．ちなみに，
BASE とは次の語群の頭文字です．

• Basically Available
• Soft-state
• Eventual consistency

 ここに，Basically Available（基本的に可用）とは，共有データシステムは CAP 定理のいう AP の下で可用ということです．Soft-state（ソフト状態）とは，システムの状態は入力が無くても時間の経過と共に変遷していくであろうということです．Eventual consistency（結果整合性）とは，現時点では一貫性のないデータでもそれに対して何の更新要求も無ければ，何時いつかは一貫するであろうということです．
 なお，BASE という用語ですが，ACID vs. BASE という対比を際立たせるために特に考えられたとのことです．すなわち，ACID の英語での意味は「酸」ですが，BASE は「塩基」（＝アルカリ）を意味し，酸とアルカリで世界を 2 分するという意味を込めて，わざわざ BASE と命名されたという逸話が残っています．
 では，BASE 特性の基となっている結果整合性をどのように実装するのか，次に見てみます．

6. 結果整合性の実装

 BASE 特性を裏打ちする結果整合性はどのようにして実装できるのでしょうか？それを見てみることにします[2]．
 まず，整合性（一貫性と同義）には 2 つの観点があります．一つはクライアント側から見た場合の整合性です．これは，クライアントにとってデータ更新がどう見えるかということです．もう一つはサーバ側から見た場合で，どのように更新処理がなされるのか，更新する際にシステムとして何を保証することができるかという観点です．
 まず，クライアント側から見れば，整合性は次のように大別されます．

    ● 強い整合性
    ● 弱い整合性
      ○ 結果整合性
 まず，強い整合性（strong consistency）は，データの更新が完了すると，その後どの複製にアクセスしても更新された値を返してくることをいいます．強い整合性でない場合を弱い整合性（weak consistency）といいます．弱い整合性では，データの更新が完了したとしても，その後のアクセスが更新された値を返すことを保証しません．値が返されるにあたっては，いくつかの条件を満たす必要があります．更新から，クライアントが更新された値を常に見ることが保証される瞬間までの期間を不整合窓（inconsistent window）といいます．
 結果整合性（eventual consistency）は弱い整合性の一種です．ストレージシステムは，オブジェクトに対して新しい更新が行われない場合，最終的にすべてのアクセスが最後に更新された値を返すことを保証します．障害が発生しない場合，不整合窓の最大サイズは，通信の遅延，システムの負荷，レプリケーションスキームに含まれるレプリカの数などの要因に基づいて決定できるとされています．
 次に，サーバ側から見た場合，結果整合性は次のように形式化することができます．そのために，
N，W，R を次のように定めます．
 → N：データの複製を格納しているノードの数（＝複製数）
 → W：更新完了の返事を返してくるべき複製の数
 → R：検索結果を返してくるべき複製の数
 つまり，マスタはクライアントからデータの更新要求を受け付けると，そのデータの複製を格納している N 個のスレーブにその更新要求を発送し更新が完了したかどうか，返事を待ちます．もし，少なくとも W 個のスレーブから更新完了の返事が来たら，その時点でマスタはクライアントに更新完了の返事を送ります．一方，クライアントからマスタにデータ検索要求が来たら，マスタはその複製を格納している N 個のスレーブにその検索要求を発送して結果を待ちます．もし少なくとも R 個のスレーブから結果が返ってくれば，その中から最新の結果を選択して（そのために，データには時刻印やバージョンを付けておく），それをクライアントに返します．つまり，W や R はマスタがアクションをとれるための定足数（quorum）を定めていることになります．まとめると次のようになります．
    (1)  W+R＞N の場合：強い整合性で対処する．
    (2)  W+R≦N の場合：結果整合性で対処する．
 若干説明を追加すると，W+R＞N の場合，書込み集合と読取り集合の「共通集合」（intersection）
は非空，つまり 2 つの集合は重なり合った部分があるということですから，強い整合性を保証できる
ということです．一方，W+R≦N の場合，共通集合が空となりうるので，強い整合性は保証できず，
この場合には結果整合性で対応しようということです．したがって，結果整合性を実装するというこ
とは，上記（2）の状況となるようなＮ，Ｗ，R を設定して検索や更新要求に対処するということです．
 第 1 章での説明と重複しますが，N=3，W=1，R=1 と設定することで可用性と一貫性が共に満た
されているとの報告が見られます．W=1，R=1 なので高可用性の実現はその通りですが，一貫性も
評価される原因としては，N=3 と複製の数が小さいことや，新鮮でないデータでもそんなに腐臭が
漂っているわけではない，という見解も見られます．不整合窓の長さについては，実測で数 ms
（millisecond）という報告もあれば，数 1,000ms という報告もあります．これらの値が許容範囲に
あるのかそうでないのかは定かではありませんが，不整合窓が長くてシステムが稼働しないといった
報告は見つかりません．
 なお，N，W，R の設定の仕方でシステムの振る舞いは相当に変わってきます．N=2, W=1, R=1 では強い整合性とはならないので一貫性は保証されないことに注意します．高性能で高可用な分散型データストアでは通常 N≧３ といわれています．一方，耐故障性（fault tolerance）を謳うシステムは，強い整合性を実現できる N=3, W=2, R=2 をとることが多いとのことです．組合せはさまざまで，興味のある者は論文[2]にあたってみてください．
 DNS (Domain Name System)は結果整合性を実装する最も一般的なシステムとして知られていますが，Dynamo がキー・バリューデータモデルの考案と共に，結果整合性を実装してトランザクション管理を行うことで，Amazon の顧客はいつでも待たされることなく（always-on），ショッピングカートに入れた商品の注文を確定することができているという事実の説得性をここで改めて強調しておきたいと思います．

7．おわりに

 分散型データストアを構築しようとしたとき，「ACID 特性 vs. BASE 特性」，あるいは「CP vs. AP」，あるいは「強い整合性 vs. 結果整合性」はきっと永遠のテーマだと思いますが，BASE・AP・結果整合性の採用は高可用性やスケーラビリティを達成したい分散型データストアの設計指針として，大変理に適かなっている発想だと思います．結果整合性が世に出て早くも十数年の月日が流れました．改めて，結果整合性の意義を回顧する報告が出ています[11, 12, 13]．興味のある方には一読を勧めますが，いずれも結果整合性を肯定的に捉えています．
 分散コンピューティングをデータベースの視点で捉えると，単一サイトイメージの達成が至上命令であった時代から数十年を経て，分散型データ管理は結果整合性で対応していこうという時代の流れになりました．この背景には，ビッグデータの管理・運用こそがビジネスモデルとする巨大な IT企業の誕生がありました．従来は基幹システムと称して OLTP がデータ処理の中核で，そこでは金科玉条のごとく ACID 特性への順守が叫ばれました．これは単一サイト，分散型を問わずということです．しかし，
ACID 特性は 3V の特徴を有するビッグデータの管理．運用が求める原理・原則ではなかったということです．そして，その要求に応えるべく必然的に生まれたのが BASE 特性であり結果整合性であったということです．
 筆者はかつて IBM San Jose 研究所の客員研究員として，分散型リレーショナルデータベース管理システム開発の草分けであった System R* プロジェクトのメンバーとしてそのアクティビティを 1 年間にわたり目の当たりにしましたが，隔世の感を禁じ得ません．

【文献】

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

1. はじめに

 リレーショナル DBMS において質問処理の最適化はリレーショナル DBMS の開発が始まって以来，設計者が最も腐心するところでした．その嚆矢は 1970 年代に IBM Sanサン Joseホゼ 研究所で開発された System R で提案・実装されたコストベース（cost based approach）の最適化手法です[1]．System
R は PostgreSQL の前身である INGRES と共にリレーショナル DBMS のプロトタイプとして名高い
システムですが，そこで開発されたこの手法は現在もプロプライエタリや PostgreSQL を含む OSS
のリレーショナル DBMS の質問処理最適化技法の基本となっています．

 この手法は問合せの実行プランを策定するにあたり，問合せ最適化器（query optimizer, 単にオプティマイザ，あるいはプランナ）は，まず単一のリレーションについてコスト最小のアクセスプランを推定し，つぎに，その結果を使って 2 つのリレーションを結合する場合のコスト最小プランを推定し，さらに，3 つのリレーションの結合コストをコスト最小と推定された 2 つのリレーションの結合を使って推定していくので，動的計画法（dynamic programming, DP）の一つとも位置付けられています．
 さて，人工知能の一分野である機械学習はさまざまな分野で取り入れられていますが，データベース分野も例外ではありません．データベース分野での機械学習の適用を考えてみると，まずはデータ活用への機械学習の適用でしょう．これに対しては，Oracle Database に一日の長の感があり，「Oracle Database で高性能の機械学習モデルを構築する」といったウェブページが立ち上がっています．データサイエンティストへの支援です（ https://www.oracle.com/jp/artificial-intelligence/database-machine-learning/ ）．
 もう一つは機械学習をオプティマイザに適用する研究・開発でしょう．PostgreSQL には早くからその動きがあり，PostgreSQL 6.1（1997 年 6 月リリース）で GEQO のサポートが始まり現在に至っています．GEQO はユーティッシュ（M. Utesch）[2]の考案により実装されましたが，GEQO はその名前の由来が GEnetic Query Optimization にあることから分かるように，遺伝的アルゴリズム（genetic algorithm, GA）を用いた結合質問処理最適化のための手法です．PostgreSQL に対する問合せ処理最適化への機械学習の適用を見てみると，PostgreSQL の世界会議である PGCon 2007 で Kovarik ら[3]が機械学習と質問処理最適化を論じています．PGCon 2010 では Urbański[4]が結合質問処理の最適化について GEQO に代わる手法として「焼きなまし法」（simulated annealing）を用いた提案をしています．また，PGCon 2017 では Ivanov[5]が Postgres Pro Enterprise の拡張機能として AQO (adaptive query optimization) を報告しています．AQO はコストベースの問合せ最適化のために，機械学習の手法として知られている「k-近傍法」を使用してカーディナリティ推定を改善することで実行計画を最適化しているとのことで，PostgreSQL 9.6 以降で稼働するとのことです．ここに，カーディナリティ推定とはサブプラン作成のために中間結果のリレーションのサイズを推定することをいい，強力なオプティマイザ設計のために欠かせない技術です．PGCon 以外では，オートマトン理論を基にして結合質問処理の最適化を行い GEQO と比較検証した結果が報告されています[6]．

また，機械学習で注目を集めている深層学習（deep learning）を質問処理の最適化に適用しようとする研究も報告されており，そこでは PostgreSQL が性能評価のために使用されています[7]．
 本稿では GA をいち早く質問処理の最適化に導入した GEQO に着目をして，その基本的考え方やその効果を見てみたいと思います．

2. 遺伝的アルゴリズム（GA）とは

 GEQO を理解するにあたって，遺伝的アルゴリズム（GA）を理解しておくことが大前提となるので，その説明から始めます．
 GA は 1975 年にミシガン大学のホーランド（J. H. Holland）により提案されました[8]．GA をフローチャートで図 1 に示します[9]．このアルゴリズムの概略は次の通りです．

【GA のアルゴリズム】
 ステップ1.

 ステップ2.

 ステップ3.

 ステップ4.

 ステップ5.

 ステップ6.

 ステップ7.

 いくつか補足すると次の通りです．

 ●　

 ●　

 ●　

 ●　

 さらに，交叉，突然異変，エッジ再結合交叉について，もう少し詳しく補足すると次のようです．

■　交叉（crossover）
 たとえば，1, 2, 3, 4, 5, 6 はリレーション R₁, R₂, _…, R₆ を表すとする．この時，親個体 A=1-2-3-4-5-6，親個体 B＝2-4-6-1-3-5 とした時（数字の並び順は対応するリレーションの結合順を表している），「一点交叉」により，子個体 C₁=1-2-3-1-3-5，子個体 C₂=2-4-6-4-5-6 が生まれる（この例では，交叉は中央で起こるとした）．しかしながら，子個体の遺伝子もリレーション R₁, R₂, _…, R₆ の結合順を表しているとするならば，C₁ には 1 と 3 が 2 度出現し，4，6 が出現していないので，R₁, R₂, _…, R₆ の結合プランとはなりえない．このような遺伝子を致死遺伝子という．C₂ も同じである．このような場合，「適応度は 0」ということになる．

■　突然異変（mutation）
 通常の GA では，交叉と並び突然変異を利用して進化する．しかしながら，突然変異はそれだけでも最適解を探索し得る強力なオペレーションであり， GA の挙動に大きく影響を与えるため，状況によっては提案手法の有用性ないしは問題点を確認しにくくすると考えられる．したがって，そのような場合は突然変異は利用しないという選択肢がありうる．実際，GEQO では突然異変は考慮しないこととしている．

 続けて，GEQO の実装で採用されたエッジ再結合交叉(edge recombination crossover, ERC)を例題と共に示しておきます．

■　エッジ再結合交叉（ERC）
 エッジ再結合交叉とは，頂点ではなくエッジを見ることで，既存のパス（path, 経路）のセットに類似したパスを作成する演算子で，1989 年にホイットリー（D. Whitley）ら[10]によって導入され，
GENITOR アルゴリズムと名付けられました．ちなみに，GENITOR とは GENetic ImplemenTOR の略称です．巡回セールスマン問題（travelling salesman problem, TSP）に対して他の手法よりも優れた手法であるとされています[11]．なお，TSP とは巡回セールスマンの最短ルートを見つける問題です．この際，巡回セールスマンは，本拠地から始めて，指定されたリストのすべての都市を正確に 1 回訪れ，その後本拠地に戻る必要があります．この問題の難しいところは，可能なツアーの数が非常に多いことで，n 都市に対して (n－1)!/2 となり，TSP は NP 困難な問題として知られています．

 さて，ERC は子個体生成のために現在の要素の次の要素を決める際、2 つの親個体においてその要素の両側に隣接した 4 つの要素を候補とする手法です．それを例題で説明します．

【例題１】（エッジ再結合交叉，ERC）
 ERC を，たとえば上述の「交叉」と同じ例を用いて説明すると次のようになる．1, 2, 3, 4, 5, 6 は
リレーション R₁, R₂, _…, R₆ を表すとする．同様に，親個体 A=1-2-3-4-5-6，親個体 B＝2-4-6-1-3-5
とする．このとき，A では 6-1 とつながり，B では 5-2 とつながり巡回するとする．そこで，A と B
の隣接行列（adjacency matrix）を作ると次のようである．

  A　　　　　　　　　　　　　　　　　　B
  1: 2, 6　　　　　　　　　　　　　　　　1: 3, 6
  2: 3, 1　　　　　　　　　　　　　　　　2: 4, 5
  3: 4, 2　　　　　　　　　　　　　　　　3: 5, 1
  4: 5, 3　　　　　　　　　　　　　　　　4: 6, 2
  5: 6, 4　　　　　　　　　　　　　　　　5: 2, 3
  6: 1, 5　　　　　　　　　　　　　　　　6: 1, 4

 続いて，A と B の隣接行列の和（union）をとる（重複は除去）と次のようである．
  A∪B
  1: 2, 3, 6
  2: 1, 3, 4, 5
  3: 1, 2, 4, 5
  4: 2, 3, 5, 6
  5: 2, 3, 4, 6
  6: 1, 4, 5

 このとき，交叉による新しい個体（＝遺伝子）を次のように生成する．
 (1) 1～6 の数字をランダムに 1 つ選ぶ．ここでは，1 を選んだとする．
 (2) 隣接集合から 1 を削除する．その結果，次の隣接行列を得る．
  A∪B
  2: 3, 4, 5
  3: 2, 4, 5
  4: 2, 3, 5, 6
  5: 2, 3, 4, 6
  6: 4, 5
 (3) 1: 2, 3, 6 であったから，2, 3, 6 のうち，最も小さい集合を持つ 6: 4, 5 を選択する．
   1-6 となる．
 (4) 隣接集合から 6 を削除する．その結果，次の隣接行列を得る．
  A∪B
  2: 3, 4, 5
  3: 2, 4, 5
  4: 2, 3, 5
  5: 2, 3, 4
 (5) 6: 4, 5 であったが，4 も 5，どちらの隣接点の数も同じなので，ランダムにどちらかを選択
   する．ここでは，4 を選んだとする．1-6-4 となる．
 (6) 隣接集合から 4 を削除する．その結果，次の隣接行列を得る．
  A∪B
  2: 3, 5
  3: 2, 5
  5: 2, 3
 (7) 4: 2, 3, 5 であったが，いずれも隣接点の数が 2 と同じなので，ランダムにどれかを選択する．
   ここでは，3 を選んだとする．1-6-4-3 となる．
 (8) 隣接集合から 3 を削除する．その結果，次の隣接行列を得る．
  A∪B
  2: 5
  5: 2
 (9) 3: 2, 5 あったが，いずれも隣接点の数が 1 と同じなので，ランダムにどれかを選択する．
   ここでは，5を選んだとする．1-6-4-3-5となる．
 (10)隣接集合から 5 を削除する．その結果，次の隣接行列を得る．
  A∪B
  2: φ
 (11)したがって，1-6-4-3-5-2 が親個体 A と B のエッジ再結合交叉により作成された子個体となる．
 上記のアルゴリズムから「交叉」の項の説明で見られたような致死遺伝子は子個体として発生しないことが分かる．

3. GEQO

3.1 結合質問処理の最適化と GA

 ユーティッシュが GEQO を発想した根底には，結合質問処理の最適化は，それを忠実に行えば，そのための処理に指数時間かかる扱いづらい問題であるとの認識があったと考えられます．このことは，多くのことを語らなくても，すぐに実感できます．一般に，n 個のリレーションの自然結合 R₁⋈R₂⋈ _… ⋈R_n をとるとき，それらの結合を，たとえば (_….((R₁⋈R₂)⋈R₃)⋈_…⋈ R_n-1)⋈R_n) という具合に結合を左から右へ順番にとっていくとしただけでもリレーションの並び順は n!（n の階乗）通りあります．n!が n の増加と共に，どれほど大きくなるかを図 2 に示される通りですが，見ての通り n が大きくなるにつれて n! は爆発的に大きくなります．たとえば n=10 では 360 万通りを越え，n=15 では 1 兆 3 千万通りを超えています．多数のリレーションの結合質問処理の最適プランを馬鹿正直に見つけようとすると，大変なことになるだろうとは容易に想像がつきます．
 次に指摘しておきたいことは，ユーティッシュは最適なリレーションの結合順を見つける問題と巡回セールスマン問題（travelling salesman problem, TSP）とが同根であることに着眼したことです．GA は TSP のような NP 困難な「組合せ最適化問題の準最適解を与える」ために大変有効な手法であることが知られています．最適解ではなく準最適解になることは，得られる解が初期集団（＝初期個体群）をどう選ぶかによるということです．上述のエッジ再結合交叉（edge recombination crossover, ERC）は TSP の準最適解を求めるのに特に適していることが知られていますが，ユーティッシュが GA を PostgreSQL に実装するにあたって ERC を採用したことは十分に理解できることです．

3.2 左深層木
 結合質問処理の最適化に GA を適用しようと考えると，結合質問の処理に一つ大きな制約が課せられます．それが，リレーションの結合は左深層木（left-deep tree）で示される順番で行われなくてはならないということです．
 これはどういうことかを例題で見てみます．そこで，リレーションを R₁(A, B)，R₂(B, C, D)，R₃(C, E)，R₄(D, F)，R₅(E, G) とし，それらの自然結合（natural join）をとる問合せを考えてみます．

 この結合質問(1)の結合グラフ（join graph）は図 3 に示される通りです．

 さて，この結合質問(1)を処理するための {R₁, R₂, R₃, R₄, R₅} の結合順はさまざまです．たとえば，
R₁⋈((R₂⋈R₄)⋈(R₃⋈R₅)) という結合順で結合をとることもできますが，(((R₁⋈R₂)⋈R₃)⋈R₄)⋈R₅ という結合順で結合をとることもできます．それらを木（tree）で表現してみると，前者は図 4(a)のように，後者は同図(b)に示されるようになります．このとき，図 4(a)のように表される木を低木（bushy tree）といい，同図 (b) のように表される木を左深層木といいます．GEQO は結合質問処理の最適化
問題をあたかもよく知られている巡回セールスマン問題（TSP）のように扱うので，候補となった
{R₁, R₂, R₃, R₄, R₅} の結合順は 1’-2’-3’-4’-5’ ，つまり (((R_1’⋈R_2’)⋈R_3’)⋈R_4’)⋈R_5’ と表され，これすなわち左深層木ということです（ここに，i’∈{1, 2, 3, 4, 5}∧1’≠2’≠3’≠4’≠5’）．
 なお，結合順は左深層木となったことにより，最適プランは本当は低木で表される結合順であった
かもしれないが，GEQO ではそれは仕方のないことということです．

3.3 GEQO の実装
 GA に基づく GEQO 実装の基本方針は次のようです．

 ①

 ②

 ③

 少しばかり補うと，① は 2 章で述べた一般的な GA の適応度の概念に同じです．②は実装に「TSP 用に設計された GA アルゴリズム」として知られる GENITOR を使用しているので，交叉を「エッジ再結合交叉」を用いて行うということです．③ は「突然異変」の項で述べたことに通じる判断と考えられますが，GEQO では突然異変は考えないということです．

 この基本方針の下での，GEQO の実装は，基本的に図 2 に示した GA のアルゴリズムの流れに沿ってなされていますが，より細かくは次の通りです．

 (a)

 (b)

 (c)

 (d)

 (e)

 (f)

 (g)

 (h)

 (i)

3.4 GEQO のパラメタ

 GEQO のパラメタは PostgreSQL 14.5 Documentation[12]に基づけば表 1 の通りです．

 なお，PostgreSQL 14.5 Documentation に「GEQO は，ヒューリスティック検索を使用して問合せプランニングを行うアルゴリズムです．これにより，複雑な問合せ（多くのリレーションを結合する問合せ）のプラニング時間（planning time）が短縮されますが，作成されるプランは，通常の網羅的検索アルゴリズムによって検出されるプランよりも劣ることがあります」との記載があります．これは（突然異変は考えていないので）geqo_seed パラメタの値の設定によっては，GEQO を使わない通常の場合より悪いプランを出力してしまう可能性のあることを言っているのだと考えられます．

4. GEQO の評価

4.1 GEQO の評価の観点

 GEQO は PostgreSQL 6.1 以降，現在に至るまでサポートされていますが，上記の qeqo パラメタを見るとき，GEQO の性能評価について，様々な観点が浮かび上がってきます．たとえば，次の通りです．

 (a)

 (b)

 (c)

 (d)

 なお，geqo_threshold については，「FULL OUTER JOIN の生成子は，1 つの FROM 項目として計算することに注意してください」との注意書きが添えられています．これは， T1 FULL OUTER JOIN T2 を，まず T1 と T2 の内部結合を行い，その後，T2 のどの行の結合条件も満たさない T1 の各行については，T2 の列を NULL 値として結合行を追加し，さらに，T1 のどの行でも結合条件を満たさない T2 の各行に対して，T1 の列を NULL 値として結合行を追加して求めているという PostgreSQL の内部処理の事情を反映してのことでしょう．

4.2 GEQO の性能評価
 かつて Petković[13]により GEQO の性能評価が報告されています．この報告は 2010 年になされており，性能評価に使用された PostgreSQL の version も 8.4 と古いので，最近の PostgreSQL の GEQO の性能を評価する参考になるのか不安になり調査したところ，次に示すように，当時の GEQO がほぼそのまま PostgreSQL 14 でも稼働しているようなので，Petković による報告には一顧の価値があると考え，それを紹介することとします．
 その古き GEQO と最新の GEQO の比較調査の結果ですが，まず，PostgreSQL 8.4.22 文書（documentation）[14]にあたってみると，「49.3.2. PostgreSQL GEQO の今後の実装作業」という項目に“遺伝的アルゴリズムのパラメータ設定を改善するためにはまだ課題が残っています”として当時の実装の問題点を記載しています．一方，最新の PostgreSQL 14.5 文書[12]にあたってみると，そこにも「60.3.2. PostgreSQL GEQO の今後の実装作業」という項目があり， PostgreSQL 8.4 当時と一字一句変わらぬ文が記載されています．つまり，（プランナ本体にはこれまで幾つか改善がなされてきたのでしょうが）GEQO 自体に PostgreSQL 8.4 で指摘された改善点がこれまで施された様子は見受けられません．なお，GEQO について PostgreSQL 8.4 と PostgreSQL 14.5 で唯一記述に変更のあった部分は，
PostgreSQL 8.4 文書の「49.3.1. Generating Possible Plans with GEQO」の末尾の文 “Hence different plans may be selected from one run to the next, resulting in varying run time and varying output row order.” が，PostgreSQL 14.5 文書の「60.3.1. Generating Possible Plans with GEQO」では，“To avoid surprising changes of the selected plan, each run of the GEQO algorithm restarts its random number generator with the current geqo_seed parameter setting. As long as geqo_seed and the other GEQO parameters are kept fixed, the same plan will be generated for a given query (and other planner inputs such as statistics). To experiment with different search paths, try changing geqo_seed.” と変更になっているだけです．ただ，これは上記 4.1 節の(c)項に関する記述変更で，
GEQO 本体レベルの変更ではないと推察され，GEQO の実装は現在も当時のままのようです．
 さて，その報告では，2 つの実験結果が示されており，それらは 4.1 節の(a)項と(b)項に対応して
いるようです．一つは，geqo パラメタで，GEQO を有効としたときと無効としたときの結合質問の
実行時間の比較です．PostgreSQL 8.4 では実行時間は total run time を意味するので，プランナが
消費した時間と最適プランをエグゼキュータがその実行に消費した時間を個別に評価することは
できず，2 つを足し合わせた時間です．もう一つは，GEQO を有効としたとき，GEQO アルゴリズムの反復数（geqo_generations），つまり世代数の変化が結合質問の処理時間に与える効果です．これは，世代数を大きくすれば，結合プランの質が高まり，その結果，結合質問の処理速度が向上するだろうことを期待した検証といえます．
 まず，実験を行うには，結合数が 10 を超えるような結合質問を多数用意する必要がありますが，
PostgreSQL 8.4 の元々のサンプルデータは 6 枚のテーブルしか持っていないので，大きな結合を試せず，MS SQL Server システムのサンプルデータである Adventure Works 2008 を PostgreSQL にインポートして使用したと報告しています．そこには 60 枚以上のテーブルがあるとのことで，そのうちの幾つかを表 2 に示します．評価にどのようなテーブルが使われたのか，それをイメージしていただければよいかと思います．

 テストのための問合せは表 3 に示される “generic query”（一般的問合せ）を考え，それから他の問合せを導出し，最大 14 個の結合演算を含む 18 個の問合せを作成して走らせたと報告しています．

 この内結合質問は 13 個のテーブルを使い，そこでは 12 個の結合演算が定義されています．ちなみに，この問合せの「結合グラフ」を作成してみると図 5 のように描けます．

 GEQO はこの結合グラフを基に，左深層木で表される線形順序の結合プランを幾つかランダムに生成して初期集団を作成し，GENITOR に入力しているということになります．幾つもの左深層木が定義できます．興味を抱いた読者は試してみてください．

 続いて，実験結果を紹介します．

【実験結果１】GEQO モジュール vs. 全数探索
 PostgreSQL が GEQO を無効にして，つまり全数探索（exhausted search）にて結合質問処理の最適化を行った場合の問合せの実行時間と GEQO モジュールを有効にして結合質問処理の最適化を行った場合の問合せの実行時間の比較を行います．なお，全数探索（exhausted search）という用語を PostgreSQL 14.5 文書[12]も Petković[13]も用いていますが，プランナは n 個のテーブルの結合の
コスト最小プランを見つけるために n! 個の結合順すべてにあたっているわけではなく，コストベー
スアプローチ（＝DP アプローチ）でそれを行っているので，全数検索というよりはコストベース
アプローチと表現するほうが適切でしょう．
 さて，比較の対象とした問合せは，11，12，13，14 個のテーブル結合を有します．図 6 はそれら
の問合せ全てに対する平均実行時間を結合するべきテーブルの数でまとめています．各結合数に対し
て，左側の縦棒は GEQO が有効，右側が無効のときを表します．図から分かるように，両者は結合
演算の数が 12 までは互角です．しかしながら，12 を超えると，GEQO はコストベースアプローチ
（＝GEQO が無効）に比べて約 15% 越えの効果を発揮しています．実験では，14 を超える場合を
検証していませんが，同様な効果が期待できると報告しています．つまり，テーブルの結合数が 13
以上の場合，GEQO を有効にすると，無効にしていた時と比べて少なくとも 15% 速く結合質問が
処理されるであろう，ということです．PostgreSQL 14.5 文書は geqo_threshold=12 で GEQO に
切り替わるとしていますが，geqo_threshold=13 でよいということになります．なお，この実験で
は，世代数 geqo_generation を幾つに設定したのか記載がありませんが，もしデフォルトで実験を
行ったとすれば geqo_generation=0 なので，その場合，表 1 に記されたように，geqo_pool_size
に基づいて適切な値が選択されているということになります．

【実験結果２】世代数を増していった時の効果
 GEQO を有効とした場合，結合質問の実行時間を GEQO アルゴリズムの反復数（geqo_generations），つまり世代数をパラメタに比較しています．geqo_generation パラメタを 1，すなわち世代数を 1 から始めて，13 まで検証した結果が図 7 です．図が示しているように，世代数を大きくするにつれて，オプティマイザはより最適な実行プランを求めることができて，結合質問の実行時間は減少していくことを示しています．geqo_generation=1 では問合せ 1 個当たりの平均実行は最適の場合に比べて約 25％ 余計にかかっていることが示されています．世代数を 9 世代，すなわちgeqo_generation=9 で最適値に収束するようです．したがって，そのように設定しておくとよいのかもしれません．

5．おわりに

 PostgreSQL の結合質問処理の最適化モジュールである GEQO を概観しました．PostgreSQL 14.5 では geqo_threshold パラメタで GEQO を発動するリレーションの結合の数のデフォルトは 12 と定めていますが，紹介した実験結果によればその数は 13 のようです．あまり大した差ではありませんが，そこら辺が目安ということなのでしょう．
 改めて言うまでもありませんが，リレーショナルデータベースの最大の特徴はデータベース言語 SQL が非手続き的（non-procedural）であるところにあり，それが故に質問処理の最適化は永遠の課題でもあります．質問処理最適化の研究・開発は機械学習の適用で一段と深まりを見せ，佳境に入った感があります．今後の理論展開と実践に注目し続けたいと思います．

【文献】

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

1. はじめに

 Null という語，データベースに携わっている人なら見たことないという人はいないと思いますが，なんと発音していますか？
 「ヌル」って言うのだよ，と誰が教えたのでしょうか？結構，皆さん，ヌル，ヌル，って言っています．違うんですねー．「ナル」って発音するのです．英語の発音記号は nʌ’l です．英語の発音を日本語で書き表すのは難しいですが，決してヌルではありません．英語を母国語とする人にヌルと言ったら，多分首を傾げると思いますよ．ナルって言いましょう．
 さて，ナル（null）は「値がない」（having no value）という意味ですね．これに異議ありという方は多分いないと思います．では，リレーショナルデータベースでナルはどのような時にどのように使われているのでしょうか？なんで今さらそんなことを聞いているの？といぶかしげな読者の顔が浮かびますが，ナルに関しては蘊蓄うんちくを傾ければきりがなく，理論面でも実践面でも不明確なところが多々あり，議論しだしたらきりがないのかなといった感じです．しばしナル談議に耽ふけってみたいと思います．

2. NULL とは

2.1　ANSI/X3/SPARC によるナルの顕現
 皆さん，ANSIアンシー/X3/SPARCスパークはご存じでしょうか？American National Standards Institute/Committee on Computers and Information Processing/Standards Planning And Requirements Committee の略称です．米国国家規格協会（ANSI）の下にあるこの委員会は 1975 年に DBMS の標準アーキテクチャとして名高い「3 層スキーマ構造」を提案した報告書[1]を世に出した団体としてとても有名ですが，その報告書の中で概念スキーマレベルのドメイン関連事項として，ナルの意味は 14 種に上るという報告をしています．このように，ナルはデータベースに係る諸活動の極めて初期から関心が高かったわけです．原義を損ないたくないので，ナルの 14 種の意味を原文のまま引用すると下記の通りです．目を通してみると分かると思いますが，ナルが出現する状況を実にさまざまな観点からピックアップしています．興味を持った方はぜひ一つひとつにあたってみてください．最後の (14)項で，“Derived from null conceptual data (any of the above)”と締め括っているので，トータル 14 種ということです．

Manifestation of null（ナルの顕現）

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

(12)

(13)

(14)

2.2　E.F. Codd によるナルと 3 値論理の導入
 では，リレーショナルデータモデルではナルはどのように定義されているのでしょうか？それはリレーショナルデータモデルの始祖コッド（Edgar F. Codd）の 1979 年の論文[2]に見ることができます．そこでは，ナルとナル値（null value）という用語が出現しますが，それらは次のように与えられています．
 まず，主キーの値はナルであってはいけないというルールの提唱があります．これはキー制約として知られていることで，もっともなことです．続いて，ナル値の最も重要なタイプは 2 つあって，それらは “value at present unknown”（値は現時点で未知）と“property inapplicable”（不適当なプロパティ）という意味を持つと述べています．そのうえで，ナル値を許すとリレーショナル代数を拡張しなければならないが，拡張のためには前者の “value at present unknown” に関心があるとし，それを “ω” で表して，いわゆる 3 値論理を展開しました．
 本稿は，コッドは「ナル」をどう捉えたのかに焦点を当てて議論することが狙いなので 3 値論理や
一般に多値論理の議論には深入りしませんが，リレーショナル代数を 3 値論理に拡張するにあたり，
value at present unknown，すなわちナル（ω）を許したときに，リレーショナル代数を構成する 8 つの演算，つまり 4 つの集合演算（和，差，共通，直積）とリレーショナル代数に特有な 4 つの演算（射影，選択，結合，商）をどのように定義し直すべきかという問題だけは復習しておきたいと思います．これについて，まず，4 つの集合演算と射影は集合意味論のもとで素直に拡張できます．問題は，選択演算です．選択演算での “ω” の扱いが決まれば，結合は直積と選択，商は直積と射影と差を用いて定義できるので特段の問題は生じません．そこで，属性が ω をとる場合に選択演算がどのように拡張されることになるのか，それを見てみましょう．
 そこで，値式 x, y に対して，述語 xθy，ここに θ は比較演算子（＝，＜，≦，＞，≧，≠），がどのような真理値をとるかを見ていきます．従来のリレーショナルデータモデルの 2 値論理の場合と同じく，x と y が共にナルでなければそれは真（true，T）か偽（false，F）をとります．では x または y ，あるいはその両方がナルとなる場合，述語 xθy はどのような真理値をとるのでしょうか？これに対してコッドは，不定（unknown）をとるとしました．そして，述語 xθy の真理値表（3 値論理）を表 1 に示したように定義しました．表示されているように，コッドは，ω を「値は現時点で未知」を表すだけでなく「不定」という真理値を表すためにも使用しました．こうすることで，「不定」という真理値をデータベースに格納することができ，かつすべての「不定」や「値は現時点で未知」の処理を統一的に行えるとしました．

 では，真（T）か偽（F）か不定（ω）をとる 3 値論理はどのような真理値表を有するのでしょうか？それが表 2 に示される 3 値論理の真理値表（NOT ブール演算子のための真理値表，AND ブー
ル演算子のための真理値表，OR ブール演算子のための真理値表）です．一般に 3 値論理の定義は
ただ一つというわけではありませんが，表 2 で与えられた定義はクリーネ（S. C. Kleene）の 3 値
論理の真理値表と同一となっています．

 以上の結果を使うと，NOT，AND，OR で結合された一般的な述語の真理値を求めることができます．たとえば， 5≦2 OR 5=ω の真理値は，述語 5≦2 の真理値が F，述語 5=ω の真理値が ω なので，OR ブール演算子のための真理値表を見ることで，5≦2 OR 5=ω の真理値は ω であることが分
かります．
 そうすると，表 3 に示す IS ブール演算子真理値表を定義することができ，それにより探索条件が TRUE であるのか，FALSE であるのか，UNKNOWN であるのかを決定することが可能となります．
たとえば，5≦2 OR 5=ω IS UNKNOWN という述語，すなわち探索条件，の真理値は 5≦2 AND 5=ω
の真理値が ω なので真であるという具合です．

 以上の枠組みのもとで，コッドは従来のリレーショナルデータモデルが依って立つ 2 値論理のと
きの θ -選択演算や θ -結合演算の自然な拡張として，3 値論理のための推量 θ-選択演算（maybe θ-selection operation）と推量 θ-結合演算（maybe θ-join operation）を定義しました（従来の
演算は推量演算と区別するために真正（true）という接頭辞を付けられて区別されます）．ここに，
maybe（推量）は「真理値が真でもなく偽でもなく，おそらく真でありおそらく偽であるのだが，
DBMS はどちらが成立するのかは知らない」を意味します．推量 θ -選択演算の定義は次の通りで
す．なお，推量 θ -結合演算の定義は直積と推量θ-選択演算の定義を使って与えることができますが，詳細に関心のある者は文献[2]や拙著[3]を参照してください．

【定義１】（推量 θ -選択演算）
 R(A₁, A₂, _…, A_n) をリレーションとする．A_i と A_j を θ-比較可能とするとき，R の属性 A_i と A_j 上の推量 θ-選択，これを R[A_iθω A_j] と表す，は次にように定義されるリレーションである．
 R[A_iθω A_j]={t|t∈R∧t[A_i]θt[A_j] IS UNKNOWN}

【例題１】（推量 θ -選択演算）
 リレーション R(A, B, C)={(1, 5, 3), (2, 3, 8), (3, 2, null), (4, null, 6), (5, null, null)} としたときの，
R の B，C 上の真正大なり -選択 R[B＞C] と推量大なり -選択 R[B＞_ωC] の結果は次のようになる．
R[B＞_ωC]の結果が下記のようになることは，5＞3=真（T），3＞8=偽（F），2＞null=不定（ω），
null＞6=不定（ω），null＞null=不定（ω）であるので，2＞null，null＞6，null＞null の場合
でのみ t[B] θ t[C] IS UNKNOW が真となることから分かる．
 R[B＞C]={(1, 5, 3)}
 R[B＞_ωC]={(3, 2, null), (4, null,6), (5, null, null)}

 なお，この 3 値論理の議論で興味深いことは，コッドが value at present unknown を表す ω は
いつでも非ナル値（nonnull value）をとれるプレースホルダ（placeholder）と考えるのがよいだ
ろうとも述べていることです．ナルはあくまでナルであってナル値という概念はないのだよと日頃
から言っている筆者にとっては，ここが大変微妙に感じられるところです．つまり，ω はナル値・だ
と言いながら一方でプレースホルダ，つまり値ではなく・・単なる「標識」だと言っているわけで，
コッドがオックスフォード大学の数学科出身であることを考えるとき，数学的厳密さからは，
彼自身，「ナルは値なの？そうではないの？」と，この相反する概念規定にいささかの葛藤が
あったのではないか，と想像するわけです．

2.3　E.F. Codd によるナルと 4 値論理の導入
 3 値論理の導入後，コッドはナルの意味をより豊富に捉えて，それをリレーショナル DBMS は
サポートするべきであるとし，4 値論理を提案[4, 5]したことはよく知られている通りです．ただ，
4 値論理の議論は時期尚早としてそれ以上の議論は行いませんでしたが，そこでは，真理値として，
t (true)，i (missing and inapplicable)，a (missing and applicable)，f (false)の 4 つを導入し，
表 4 に示される 4 値論理の真理値表を与えています[5]．

 この真理値表は一見すると表 2 に示した T，F，ω を擁する3値論理の真理値表の素直な拡張になっているように見えますが，注意深く見てみると OR ブール演算子のための真理値表の f 行 i 列，つまり f OR i の真理値が i ではなく f となっています（対称的に，i 行 f 列，つまり i OR f についても同様です）．このことについて，論文[5]に 4 値論理の真理値表を表 4 のように定義した論拠は一切示されていないのでその理由を知ることはできませんが，この真理値表の直下に，次のような注意書きを与えています（原義を損なわないために原文のママ引用します ）．

 TRI/EFC-4 とはコッドが立ち上げた研究機関 The Relational Institute (TRI) で E.F. Codd (EFC) が
書いた 4 番目の論文 “Missing Information in Relational Databases: Applicable and Inapplicable”, February 21, 1986 を指しています．コッドはこの注意書きで，i と a を共に m に置き換えると，
表 2 に示した 3 値論理の真理値表が得られるというのですが，実際それを行ってみると，3 値論
理の NOT ブール演算子のための真理値表と AND ブール演算子のための真理値表は得られますが，
OR ブール演算子のための真理値表は得られません（読者の皆さんも容易に確かめることができる
と思います）．OR ブール演算子のための真理値表が i と a を共に m に置き換えることで得られる
ためには，f 行 i 列，つまり f OR i の真理値は f ではなく i でないといけません（対称的に，i 行
f 列，つまり i OR f についても同様です）．ただ，一般に多値論理の定義には多様性があり，たと
えばベルナップ（Nuel D. Belnap, Jr.）の定義した 4 値論理 A4 や L4 の真理値表はコッドの定義
した真理値表（表 4）とは異なります． 筆者は「i と a を共に m に置き換えると，云々」という
箇所にこだわり，表 4 に疑問符を投げかけましたが，それにこだわらなければ表 4 でよいのかも
しれません．コッドが没してしまった今となっては，本人にその真意を問うことはできませんが，
もし 4 値論理をリレーショナルデータベースに実装しようとするのであれば，解決を迫られる避け
ては通れない問題だろうと考えられます．

2.4　SQL でのナル
 国際標準リレーショナルデータベース言語 SQL でのナルに対する立ち位置はどのようでしょうか？メルトン（J. Melton）らの著書[6]に次のような説明があります．ちなみに，メルトンは SQL-92 や SQL:1999 の編集者（editor）で，SQL の策定に多大な影響力を持っている人として知られています．ここで述べるナルに対する SQL のスタンスは最新規格SQL:2016[7]でも変わっていません．

 若干補足すると，SQL ではデータ項目は非ナル値（non-null value）かナル値をとります．ナル値
は “not available”（入手不可），“not applicable”（適用不可）,“unknown”（未知）を表すために使用
され，キーワード NULL を導入してナル値を表します．ナル値はいかなるデータ型の値でもないので，
もし NULL にあるデータ型を関連付けたいのであれば CAST(NULL AS datatype) 句で明示的にデータ
型と関連付けます．
 つまり，SQL ではデータ項目が現実値を持たないことを NULL で表すとしているわけですが，それをナル値・と言ってしまったので，あたかもナルという値があるかのような表現になっています．したがって，ここでもコッドが直面したであろう葛藤が読み取れて，現実値がない・・のにあたかも「ナルという値」がある・・かのように言ってしまう．．．この可笑おかしさについては SQL を策定した当事者自身もどうも気にしていたようで，メルトンらは上記の著書[6]で次のように釈明しています．言うまでもありませんが，this phrase とは上記の説明文のことです．

 こんな釈明をするぐらいならば，次のような一貫した姿勢をとった方がどれだけすっきりした体系となっただろうにと，筆者は常々思うわけです．

3. ナルの意味の体系化

 前章で示したごとく，ANSI/X3/SPARC はナルに対して 14 種の意味を，コッドはナル値に “value
at present unknown” と “property inapplicable” という 2 つの意味を，SQL はナルに “not available”
（入手不可），“not applicable”（適用不可）,“unknown”（未知）という 3 つの意味を与えています．
 問題は，それぞれがそれぞれの思惑からナル（値）の定義を与えていますが，データベースでナルを中途半端ではなくきちんと・・・・取り扱うためには，ナルの意味の健全かつ完全な体系化が必要となります．ここに，健全（sound）であるとは，その体系において構文論的に証明できる命題は意味論的に成り立つことをいい，完全（complete）であるとは意味論的に成り立つ命題は構文論的に証明できることを
意味します．以下で議論するように，この意味で，ANSI/X3/SPARC，コッド，そして SQL のナルの
取り扱いは不十分だということです．

3.1　コッドによるナルの意味の体系
 さて，コッドが 4 値論理の議論で与えたナルの分類が完全なように見えるかもしれません．しかし，以下に示すようにそうではありません．コッドは，ナル値の最も重要なタイプは 2 つあって，それら
は value at present unknown と property inapplicable であり，それに基づき，値がない場合，つま
り missing の場合を missing and applicable と missing and inapplicable の 2 つに分類しました．
Applicable と inapplicable で二律背反ですから，この分類に限れば完全です．しかしながら，コッド
の分類で問題があると考えられるところは，そもそも値があるのかないのか，それが分からないとい
う理由で missing の場合がフォーマライズされていないことです．確かに，コッドの論文[4]を丁寧に
見ると，そこに掲載されている Fig.1 で missing values を分類して，applicable と inapplicable に
加えて other という枝分かれを確認することができます（その結果，missing values は 3 種類という
ことになります）．この other ですが，本文中に説明は見当たらず，Fig.1 中に記載があるだけなの
ですが，その図を拠り所にしてコッドが考えた missing value の概念を分類木（classification tree）
で表してみると図 1 のように描けます．しかし，other がこのような位置づけでは，3.3 節の議論で
明らかになるように，ナルの健全かつ完全な分類とはなっていないのです．

3.2　SQL によるナルの意味の体系
 SQL は，2.4 節で述べた通り，ナル値には次の3つがあるとしています[6]．

 “not available” は何らかの理由で属性値が入手不可，“not applicable” はこのタップルがその属性で現実値をとることはありえず適用不可，“unknown” は属性値は存在するはずだが未知，を表しています．この分類ですが，コッドが与えた “missing and applicable”，“missing and inapplicable”，“other” という 3 分類とは異なるようです．個人的な感覚レベルでは，“not applicable” と “missing and inapplicable” が対応しているのだろうとは思いますが，他は漠然としていてよく分かりません．多分，対応付けしようとする方がおかしいのだろうと思います．SQL のナルの分類は属性が現実値をとれないと考えられる場合を3つピックアップしただけという感じで，場当たり的な分類の感はぬぐえず，ナルの健全かつ完全な分類からは遠い気がします．
 なお，SQL はナル値には 3 つの意味があるとはしましたが，一律に NULL で表してしまうので，意味の違いを表現することはできません．

3.3　SQL ナルの意味の健全かつ完全な体系化
 ナルの意味の体系化に対して何かすっきりした解決策はないものかと思案していたとき，かつて筆者の目に留まったのが，ナルの持つ「3 つの意味」に着目してそれを分類する考え方です[8]．ここに，ナルの持つ3つの意味とは次のとおりです．

このナルの意味付けは，対象とした属性がとりうる値の存在の有無に視点を置き，その可能性を分類すると，次に示す 4 つの場合になることに理論的根拠を置いています．

 確かに，属性値の存在を問うたときに，属性値が存在する，属性値が存在しない，属性値が存在するのかしないのか分からない，この 3 つに分類されますね，と言われればその通りです．さらに，属性値が存在するとしても，現時点で分かっている場合もあれば，分かっていない場合もありますね，と言われればそれも確かにその通りです．この分類則を分類木で表してみると図 2 のようになります．この分類木の作り方から，属性値の存在に関してこの分類が健全かつ完全であることはほぼ明らかでしょう．

 補足ですが，この分類の下で，現実値，unk, dne, ni の違いをそれらが担っている情報量の違いで
説明することができます．つまり，ナルを受け取る側からみると，ni は unk や dne に比べて情報量
が少なく（less informative），unk は現実値が与えられることに比べれば情報量は少ないと言えま
す．また，現実値と dne の情報量の多寡は less informative とも more informative とも言えないでしょう．同様なことが異なる 2 つの現実値同士についても言えると考えられます．したがって，現実
値を d_i（i=1, 2, …, n）とするとき，集合 {d₁, d₂, …, dn, unk, dne, ni} は情報量の多寡を半順序関係（partial order relation）とする下半束（lower semilattice）をなしていると表現することができます．その様子を図 3 に示します．

【例題２】（unk，dne，ni の具体例）
 リレーション 社員(社員名＿姓，社員名＿名，配偶者名) を想定する．

• unk の例：社員の属性として配偶者名があるとき，配偶者がいることは分かっているのだが，現時点でその名が分からないとき配偶者名欄に unk を記入する．
• dne の例：社員の属性として配偶者名があるとき，配偶者がいない社員の配偶者名欄に dne を記入する．
• ni の例：社員の属性として配偶者名があるとき，配偶者がいるのかいないのか分からない社員の配偶者名欄に ni を記入する．

 ただし，次の注意が必要です．たしかに，上記の分類でナルの意味は過不足なく表現することができました．しかしながら，これは言わずもがなですが，もし unk，dne，ni すべてを一律に null で表してしまうとこの分類体系は無意味になってしまいます．たとえば，リレーション社員(社員名＿姓，社員名＿名，配偶者名)にタップル(鈴木，太郎，null)が存在した場合，null が unk を表しているのか，dne を表しているのか，あるいは ni を表しているのかは分からないということです．このようなことにならないためには，リレーショナル DBMS は unk，dne，ni をいかなるドメインにも属さない特別なプレースホルダとして扱える機能を備えていないといけないということになります．ただ，これも言わずもがなですが，現行のプロプライエタリあるいは OSS のリレーショナル DBMS に unk，dne，ni を個別にサポートするような機能は備わっていません．これは，SQL が not available，not applicable，
unknown を一律に NULL と表し処理していることと同じです．

4．NULL と空文字列

 ナルとは別に空文字列（zero-length string, ZLS，”で表す）という概念があります．これは長さが 0 の文字列を「値」として持つということで，ナルとは異なります．相違点は，理論上，ナルはいかなるドメインの元ではありませんが，空文字列はすべてのドメインの元であるということです．
 さて，空文字列の意味ですが，どう考えたらよいのでしょうか？たとえば，リレーション 友人(氏名，住所，携帯電話番号)があり，タップル (鈴木太郎，横浜，” )があったとします．これは，もしタッ
プルが(鈴木太郎，横浜，null)であった場合と何がどう違うのでしょうか，それを説明してほしいという問題です．もちろん，SQL で問合せを書き下すにあたって，空文字列と null ではその取扱いに違いのあることは十分に承知してのことです．つまり，ここでの関心事は意味の違いです．繰り返しますが，(鈴木太郎，横浜，” )と(鈴木太郎，横浜，null)では一体何がどのように違うのでしょうか？
 もし，空文字列（”）で鈴木太郎が携帯電話を持っていないということを表したいというのであれば，携帯電話番号欄は null，正確には dne でしょう．もし，持っているのは分かっているのだけれど
その番号が分からないというのであれば null，正確には unk でしょう．もし持っているのかいないの
か分からないのでということであれば null，正確には ni を記録するべきであって，空文字列ではないでしょう．そうすると，唯一考えられるのは，鈴木太郎の携帯番号が現実値として空文字列（”）であるということになってしまいますが，こんな携帯電話の番号ってありますか？マジ理解に苦しむ世界に落ち込んでしまいました．．．

 ということでしょうか，奥深いことです．

5．PostgreSQL と NULL および空文字列

 OSS のリレーショナルDBMSとして普及している PostgreSQL では用語集（glossary）でナルを次のように定義しています[9]．

『Null－リレーショナルデータベース理論の中心的な信条である non-existence
（存在しない）という概念．明確な値がないことを表します』

 「明確な値がないことを表します」，原文では “It represents the absence of a definite value.” と書かれているわけですが「明確な値がない」とはどういうことか，ナルはナル値という “値”（value）であるのか単なる標識なのか，それについてはなにも言及されていません．なお，空文字列については特段の定義が与えられているわけではありません．

 そこで，念のため，null や空文字列が PostgreSQL で一体どのようにサポートされているのか，
PostgreSQL 14 で検証しつつ気が付いたところを記してみたいと思います．

【検証】（PostgreSQL 14 での NULL と空文字列の扱い）
 テーブル test(name char(10), spouse char(10)) を作成し，タップル (‘taro’, ‘hanako’), (‘jiro’, ”), (‘saburo’, null) を挿入して，SQL で空文字列 ” とナル値を表すキーワード null に関する問合せを発行して，PostgreSQL 14 はどのように振舞うのか，その結果を見てみます．なお，PostgreSQL の問合せでのナル値と空文字列の概念の違いはモムジャン（B. Momjian）の著書[10]で平易に説明されているので参考になるかもしれません．

・　検証事項１
 上記の select 文の結果ですが，jiro の spouse（配偶者）値は空文字列 ” のはずですが，空白として表示されています．空文字列だからそうなのでしょう．一方，saburo の spouse 欄は 空文字列ではなく null のはずですが，これまた空白です．したがって，この問合せの結果からは，ユーザは jiro のタップルの spouse 値が空文字列 ” でsaburo のタップルの spouse 欄は null であることを知ることはできません．筆者としては，この問合せに対する導出表は（2）式のように表示されるべきだと思います．導出表をなぜ（2）式のように表示してくれないのでしょか？筆者には謎です．

・　検証事項２
 上記の結果を受けて以下の 2 つの問合せを発行してみます．

 この問合せの結果から，spouse 値が空文字列のタップルは jiro のタップルであることが分かります．つまり，空文字列を PostgreSQL は内部的にはちゃんと認識し，述語「 ” = ” 」は T（真）（表 1　述語 xθy の真理値（3 値論理））と認識しています．

 一方，次を発行してみます．

 この問合せの結果から，spouse 欄が null のタップルは saburo のタップルであること，すなわち，null is null=T（真）（表 3　IS ブール演算子真理値表（3 値論理））と PostgreSQL はちゃんと認識しています．
 （3）と（4）から分かるように，PostgreSQL は問合せの結果（1）からはユーザには見えませんでしたが，内部的には空文字列と null をきちんと認識しているわけです．決してごっちゃになっているわけではありません

・　検証事項３
 ここでは，理論上，「spouse is null」は許されたが「spouse is ”」は許されないこと，および「spouse = null」の処理を念のために検証することにします．

 まず，「spouse is ”」 は許されないことは次のように確認されます．is true, is null, is false は IS ブール演算子として許されるが，is ” は IS ブール演算子として許されていないので納得です．

 では，「spouse = null」はどうでしょうか？

 導出表は 0 行という表示ですから，リレーション test には探索条件 spouse = null にヒットするタップルがなかったというわけです．この問合せ処理にあたっては，探索条件 spouse = null に対して，具体的には 3 つの述語 ‘hanako’=null，”=null，null=null を検証しないといけないわけですが
（= は比較演算子），表 1 に示した「述語 xθy の真理値（3 値論理）」から，’hanako’=null の真
理値は ω，”=null の真理値も（ ” が空文字列という現実値なので）その真理値は ω，null=null の
真理値も ω ということで，いずれも真（T）ではないので，ヒットした行はなかったということです．
なお，(‘saburo’, null)∈test なので，’saburo’ が導出表に現れるかと思うかもしれませんが，そのためには “spouse=null” ではなく，“spouse is null” を指定しなさいということです（検証事項 2）．

・　検証事項４
 update 文では set 句で spouse=null という表現が許されますが，この場合は述語ではなく「代入」を表し，その簡単な例は次の通りです．ただ，更新結果を確認するためにselect文を発行しても，検証事項1でクレームしたと同様に，導出表からは，taro の spouse が空文字列（”）と更新されたのか，
null と更新されたのかを読み解くことはできません．

 なお，null や空文字列の扱いはプロプライエタリや OSS のリレーショナル DBMS ごとに異なっているようです．上で見たように PostgreSQL ではそれらを区別して扱っていましたが，Oracle Database では自動的に空文字列を null に変換するとの記事をよく見かけます．空文字列とナルの違いを意識したユースケースを Oracle Database は想定していないということなのでしょう．

6．おわりに

 ナル（null）に係わる話題をいくつか披露いたしました．ナルの意味の健全かつ完全な体系化には，属性は「現実値」に加えて，3 種類の意味の異なるナル，すなわち，unk（未知），ni（情報がない），dne（存在しない），をサポートする必要があることを論じました．そのためには，リレーショナルデータモデルとリレーショナル DBMS は 3 値論理を超える多値論理をモデル化し実装していくことが必要になりますが，一筋縄ではいかない難問と考えられます．機会があれば論じてみたいですね．
 繰り返すまでもありませんが，本稿をお読みいただいた方々，これをご縁に以下のことお約束ください．

   ● ヌルとは言わない，必ずナルと言う．
   ● ナル値とか空値とは言わない，必ずナルあるいは空と言う．

【文献】

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

1. はじめに

 トランザクションの同時実行制御は障害時回復とならんでトランザクション管理には欠かせない機能であることは言うまでもないことです．そのために 2 相ロッキング（two phase locking, 2PL）プロトコルが考案され，伝統的に 2PL が多くのデータベース管理システム（DBMS）で実装されてきました．しかし，2PLでは同時実行されているトランザクションの直列化可能性を保証するために，トランザクションは読取りや更新の対象となるオブジェクトをロック（lock，施錠）することが必要で，それによる同時実行性（concurrency）の制約は古くから認識されるところでした．
 多版同時実行制御（multiversion concurrency control, MVCC）は 2PL とは異なり，競合しているトランザクションの実行終了を待つのではなく，同じデータ項目の異なる版（version）を用意することによって，トランザクションの隔離性を向上させ，同時実行性を高めようとするアプローチです．データ項目の版という概念の導入は 1978 年に遡りますが[1]，その考え方はデータベース分野に直ちに入り込み，1980 年代初頭には MVCC の理論の礎が築かれました[2]．MVCC と一口に言ってもその実現法は MVTO（multiversion timestamp ordering），MV2PL，MVMM，MVOCC，SI（snapshot isolation，スナップショット隔離性），SSI（serializable snapshot isolation，直列化可能スナップショット隔離性）など多様です．現在 MVCC はこのようなさまざまな実現法を包括した用語として用いられると同時に，狭義には MVCC の原点である MVTO を指す言葉としても用いられます．現在，多くのプロプラィエタリ（proprietary）あるいは OSS のリレーショナル DBMS で MVCC が実装されています．
 2PL と MVCC ではトランザクションの同時持実行制御の考え方が根本的に異なるので，2PL を念頭に制定された国際標準リレーショナルデータベース言語 SQL が定めた隔離性水準（isolation level）と MVCC の提供する隔離性水準との間には齟齬そごが出ます．現在 PostgreSQL や Oracle で実装されている SI は ANSI SQL の隔離性水準を論評する過程で考案され，1995 年に公表されました[5]．
 本稿では，MVTO と SI を中心において，MVCCと は何かを改めて議論しておきたいと考えます．

2. MVCC

2.1 MVCC とは
 MVCC という用語はとても一般的になっていますが，そもそも MVCC という概念は「更新可能なオブジェクトを不変な版（version）の系列と見なす」と発想した Reed の博士論文 “Naming and Synchronization in a Decentralized Computer Systems”[1] に見ることができます（1978 年 9 月にマサチューセッツ工科大学（MIT）に提出した学位請求論文）．この考え方は 1981 年に InterBase で実装されたということです（その後，Firebird としてオープンソース化されました）．
 データベース分野で MVCC が本格的に論じられたのは Bernstein と Goodman が 1981 年に発表した論文 “Concurrency Control in Distributed Database Systems”[2]と考えられます．彼らはその論文で Reed の手法を “Multiversion Timestamp Ordering (MVTO)” として形式化し，その正当性の証明を与えて MVCC によるトランザクションの同時実行制御の時代の幕を切って落としました．MVCC の実現法はざまざまに考えられ，彼らはその論文で MVTO に加えて，従来の2PLに版の概念を導入して拡張した MV2PL，読みのみを発行するトランザクションを同期させるためには MVTO を使用し読み書きを行うトランザクションの同期には厳密な 2PL（strict 2PL）を使うMVMM（multiversion mixed method）を提案し，それらの正当性を証明しています．これら，初期の MVCC の手法は Bernstein らの一連の論文と著書に詳しく記載されています[2, 3, 4]．その後，MVCC の手法として Larson ら[6]により MVOCC が提案されています．これは，トランザクションの同時実行制御法として知られている楽観的同時実行制御法（optimistic concurrency control, OCC）[7]に多版（multiversion）の概念を導入した手法です．そして，ANSI SQL の隔離性水準を論評する過程でスナップショット隔離性（snapshot isolation， SI）が提案されました[5]．1995 年のことです．SI やそれを直列化可能とした直列化可能スナップショット隔離性（Serializable snapshot isolation，SSI）はシドニー大学（University of Sydney）の Fekete や Cahill ら[8, 9, 10]によりその性質や実装法が明らかにされましたが，それらも MVCC の一種です．このように MVCC は，広義には SI や SSI を含む多くの異形をカバーする用語ですが，狭義には MVTO を表す用語と理解するのが理にかなっているかと考えます．

2.2 2PL vs. MVCC
 2PL ではなく，MVCC でトランザクションの同時実行を行うと何が嬉しいのか，それを単純ですが典型的な例で確認しておきたいと思います．以下，ここで想定している MVCC は，この概念の基礎となった MVTO をフォーマルに記述したものとします．なお，トランザクションの同時実行スケジュール，スケジュールのビュー等価（view equivalence）や相反等価（conflict equivalence）などの説明は省略しますが，参照されたい向きには拙著[11]を薦めます．
 まず具体的に MVCC の意味するところを直観することにします．そこで，S₁ をトランザクション T₁ と T₂ の同時実行スケジュールとし，図 1(a)に示す通りとしましょう．すると，S₁ は相反直列化可能でない（従ってビュー直列化可能でもない）ことが確かめられますから，S₁ は 2PL では正しい実行を保証されないスケジュールであることが分かります．
 ところが，MVCC のもとではこのスケジュールでトランザクションを実行しても正しい結果が得られます．それはどうしてでしょうか？そうなる仕組みはどのようなものなのでしょうか？それを見てみましょう．
 まず，具体的に，なぜスケジュール S₁ は正しい結果を保証しないのでしょうか？それは，時刻5で発行された T₁のデータ項目 y の読み，T₁:read(y) は，T₂ が時刻 4 で y に書き出した T₂:write(y) の結果を読んでしまうが，（トランザクションの隔離性という観点から考えれば）本来はデータ項目 y の初期値，これを y₀ と書く，を読みたかったはずなのに，スケジュール S₁ ではそれが叶わなかったということです．
 しかし，もし T₁ と T₂ の同時実行スケジュールが図 1(b)に示した S₂ であったらどうでしょうか？このときは，容易に確かめられるように，S₂ は相反直列化可能スケジュールとなり，このスケジュールで T₁ と T₂ を同時実行すれば正しい結果が保証されます．

 さて，実は，MVCC のもとでは，スケジュール S₁ に従ってトランザクション T₁ と T₂ を同時実行しても，正しい結果を保証してくれます．これはどうしてかというと，MVCC では版の概念があるので，たとえスケジュール S₁ に従って T₁ と T₂ を同時実行しても，実質的にはスケジュール S₂ で T₁ と T₂ を実行したことになるからです．それが正まさしく MVCC の意図するところです．
 そこで， MVCC アルゴリズムに従いトランザクションの同時実行をスケジュールする多版スケジューラ（mulitiversion scheduler）がどのようにトランザクションステップの実行を制御していくのか，そのアルゴリズムを示しますが，それを理解するための助けとなるかと考え，いくつか補足的説明を行います．

(1)

(2)

(3)

【MVCC アルゴリズム】
 MVCC アルゴリズムは次の規則に則り，トランザクションの読みや書きを版（version）への読込みや書込みに変換する．
　(1)　T_i:read(x) を r_i[x_k] に変換する．このとき x_k は ts(T_i) 以下で最大の時刻印を持つ x の
　　　版を表す．
　(2)　T_i:write(x) は次の 2 つに場合分けされる．
　　　　(i) もし，ts(T_k)＜ts(T_i)＜ts(T_j)を満たす i, j, k に対して，r_j[x_k]なる処理が行われてい
　　　　　 たならば，T_i:write(x) は棄却される（従って，T_i はアボートされる．）．
　　　　(ii) そうでなければ，T_i:write(x)をw_i[x_i] に変換する．

 補足すると，(2)(i) の言っていることは，自分（T_i）より後発のトランザクション（T_j）が自分より先発のトランザクション（T_k）が書き出した結果を読んでしまっている（r_j[x_k]）なら，自分がそのデータ項目 x を書き換えるとことは許されない，ということである．

 さて，MVCC アルゴリズムに従った多版スケジューラが出力したスケジュールを多版スケジュールといいますが，この MVCC アルゴリズムに従って，図 1 (a) に示したスケジュール S₁ でトランザクション T₁ と T₂ を同時実行して得られた多版スケジュールを図 2 に示します（←は代入を表す）．特に注目するべきところは，時刻 5 で，T₁:read(x) は MVCC のもとでは，T₂ が直前に書き出した y₂ を読むのではなく，MVCC アルゴリズムの (1) により，y の初期値 y₀ を読んでいるところです．その結果，
MVCC に従うとスケジュール S₁ で T₁ と T₂ を同時実行しても，その実行結果としての多版スケジュールは従来の相反直列化可能なスケジュール S₂ での実行と同じになっていて，従って，正しい実行であると考えることができるわけです．

 このように，2PL の同時実行制御の考え方では相反直列化可能ではないスケジュール S₁ が，MVCC アルゴリズムのもとでは正しい実行を保証してくれるスケジュールと考えてよいことを示しましたが，この根底には MVCC アルゴリズムの正当性が示されていないといけません．つまり，このアルゴリズムに則って多版スケジューラが出力する多版スケジュールでトランザクションを同時実行することによってデータベースの一貫性が損なわれることはない，ということの証明が必要ということです．この証明の道筋は，多版スケジュールを単一版（single version, 1V）スケジュールに変換して（単一版とは版が 1 つしかないということだから，従来型のスケジュールということで，従って，従来型の同時実行制御の考え方が適用できる），その直列化可能性から多版スケジュールの正当性を示すのですが，この証明はいささか複雑すぎます．どうしてもそれを知りたいという読者は，文献[4]の第 5 章で与えられていますので，それに当たってください．ここでは，これ以上立ち入らず，MVCC アルゴリズムは正しいという結果を述べるに留めたいと思います．

3. SI と SSI

3.1 SI の提案
 さて，1995 年に “A Critique of ANSI SQL Isolation Levels” と題した論文[5]が発表されました．この論文は，題目の通りANSI（American National Standards Institute，米国国家規格協会）が制定した SQL のトランザクションの隔離性水準の不備を指摘するとともに，「直列化可能ではないものの，
ANSI SQL が指摘した現象，つまり汚読（dirty read），反復不可能な読み（unrepeatable read），幽霊（phantom）が発生しない多版同時実行メカニズム」を定義して，それをスナップショット隔離性（Snapshot Isolation，SI）と名付けました．そこでは，SI は MVMM（multiversion mixed method）の拡張であると紹介され，SI は ANSI の定義した READ COMMITTED よりは強く，
REPEATABLE READ とは強弱が言えないことが述べられています．また，直列化可能ではないことの理由として書込みスキュー異状（write skew anomaly）の発生を挙げています．
 SI は MVTO や MV2PL などと違ってトランザクションの同時実行の正しさ，つまりトランザクションの直列化可能性を保証するプロトコルではなく，書込みスキュー異状に加えて読取り専用トランザクション異状（read-only transaction anomaly）[8]の発生も許してしまうのですが，その特性はシドニー大学（University of Sydney）の研究者により深く研究されその性質や実装法が明らかにされました[8, 9, 10]．Fekete ら[9]は SI の下で TPC-C ベンチマークが異状を発生することなく実行可能であったことを実験的に示して，直列化可能性を保証できない SI ではあるが，ほとんどのトランザクションを問題なく同時実行できるのではないかということを強調しました．Cahill ら[10]は SI を直列化可能とする SSI（serializable snapshot isolation，直列化可能 SI）のアルゴリズムとその実装，ならびにその性能については様々なケースで 2PL より大幅に改善し，往々にして SI と同程度であったと報告しています．ただ，SSI では，現実的な実装法の制約から，本来は直列化可能なスケジュールなのにその実行が棄却されてしまうという擬陽性（false positive）が発生することは避けられないことには注意が必要です．これらの現象については，以下でより詳しく例題を挙げて説明します．
 現在，SI は PostgreSQL，Oracle Database，MS SQL Server などで実装されています．SI は汚読，反復不可能な読み，幽霊を引き起こさないので，それを実装すれば SQL の隔離性水準である SERIALIZABLE を実現していることになります．Oracle Database はそれでもって SERIALIZABLE を実現，と謳うたっているのですが，2PL に基づいた SERIALIZABLE の実現と違って SI では書込みスキュー異状や読取り専用トランザクション異状が発生するので，トランザクションの同時実行制御の理論が謳うところの真の意味での（あるいは完全な）直列化可能性を達成しているわけではないわけで，
SERIALIZABLE と謳うのはいかがなものかと，この点で物議を醸かもしてきたことは本稿の読者であればどこかで耳にしていることでしょう．一方，PostgreSQL では REPEATABLE READ を SI で，
SERIALIZABLE を SSI で，READ COMMITTED は SI を緩める，つまり，各読み毎ごとにスナップショット（snapshot）を取り直す，ことで実装しています（READ UNCOMMITTED は実装されていなく，その隔離性水準を指定すると default の READ COMMITTED となります）．この詳細は Ports と Grittner [12]により報告されています．したがって，PostgreSQL では Oracle Database のような物議は醸かもしませんが，前述のように SERIALIZABLE では擬陽性が発生することがあるので，それに注意する必要があります．

3.2 SI
 さて，SI の定義を見てみることから始めましょう．
【定義 1】(SI)
 SI の下で実行されるトランザクション T₁ は，それが開始された論理時刻，これを開始時刻印（start-timestamp）と呼ぶ，の時点で有効なコミット済みデータからなるスナップショットから常にデータを読み取る．T₁ の開始後にアクティブな他のトランザクションの更新は T₁ には見えない．T₁ がコミットの準備ができると，コミット時刻印（commit-timestamp）が割り当てられ，他の同時トランザクション T₂（つまり，アクティブ期間 [開始時刻印, コミット時刻印] が T₁ の期間と重複するトランザクション）がすでに T₁ が書き込むことを意図しているデータに書込みをしていない場合にコミットが許可される．これは，遺失更新（lost update）を阻止するためで，First-Committer-Wins ルールと呼ばれる．

 実際には，ほとんどの実装では，更新された行に排他ロックが使用されるため，First-Committer-Wins の代わりに，First-Updater-Wins ルールが適用されています．共に，同時実行されている 2 つのトランザクションが同じデータ項目を更新することはできないというためのルールで，その差異は重要ではありません．これは遺失更新異状が発生しないことを意味しているわけです．同様に，トランザクション T のすべての読みは T が開始する前にコミットしたトランザクションの結果を見るので，不完全なトランザクションの影響がなく，これは SI では汚読の異状が発生しないことを意味します．
 SI の定義と補足説明でほぼ明らかかと思われますが，トランザクションはその開始時点でのスナップショットを読み続けるので，汚読，反復不可能な読み，幽霊は発生のしようがなく，その結果として SI は SQL の規定している隔離性水準 SERIALIZABLE でのトランザクションの同時実行を保証してくれます．
 しかしながら，トランザクションの同時実行制御の理論が謳うところの「真」の意味での直列化可能性（serializability）は満たしていないわけです．なぜならば，SI では書込みスキュー異状や読取り専用トランザクション異状が発生してしまうからです．このことを例題で説明しましょう．

【書込みスキュー異状】（write skew anomaly）
 たとえば，データ項目 x，y の初期状態を，x₀=50, y₀=50 とします.また，データベースには一貫性制約が課せられていて，それは x+y≧0 であったとします．
 このとき，SI のもとでトランザクション T₁ と T₂ が同時実行され，そのスケジュールが図 3 に示されたようであったとします．論理時間は縦軸の上から下の方へ流れていっているとします．T₁ の読んだ x と y の初期値 _x0 と _y0 はそれぞれ 50 で，両者を足して 100 となります．このとき，T₁が xを －20
に書換えて x₁=－20 としても（つまり，x₀－70 を実行したということ），y₀=50 なので，x₁+y₀=30
となり一貫性制約には抵触しなく，T₂ はまだコミットしていないので，First Committer Wins ルールでコミットできます（それを c₁ で表しています）．一方，T₁ と同時実行されている T₂ は x₀ と y₀ を読み，y₂=－30 と y を更新したとします．この更新も一貫性制約に抵触しないので許されます．さらに，T₂ は y を更新したのであって，x を更新したのではないので，First Committer Wins ルールによりコミットできます（これを c₂ で表しています）．
 さて，T₁ と T₂ の同時実行により，データベースの状態はどのようになったでしょうか？データ項目 x の値は －20 となりました．一方，データ項目yの値は －30 となりました．両方を足すと，x+y の値は －50 になり，これはデータベースの一貫性制約 x+y≧0 に抵触していることになります．この問題は First-Committer-Wins ルールの適用時には検出されませんでした．なぜならば，2 つの異なるデータ項目は，それぞれが他方の状態が変化することなく元のままであることを前提として更新されているためです．それが，「ずれた書込み」（write skew）と名付けられた所以ゆえんです．なお，図中，rw は rw-dependency （rw-従属性）の存在を示しています（rw-従属性の説明は 3.3 節）．

【読取り専用トランザクション異状】(read-only transaction anomaly)
 3 つのトランザクション間に生起する異状で，そのうちの 2 つは更新トランザクションですが，1 つは読取り専用トランザクションで，この読取り専用トランザクションで発生する異状です．そこで，T₁, T₂ を更新トランザクション, T₃ を読取り専用トランザクションとし，それらが SI の下で，図 4 に示されたように同時実行されたとします．

 First-Committer-Wins ルールに従い，T₁ は y₁=20 として問題なくコミットします（c₁）．同様に T₂ は x₂=－11 として問題なくコミットします（c₂）．T₃ は読取り専用トランザクションなので，問題なくコミットします（c₃）．
 さて，このトランザクションの同時実行に問題はなかったのでしょうか？いや，実は，大きな問題があるのです．T₃ が返すデータ項目 x，y の値はそれぞれ 0 と 20 です．しかし，x=0, y=20 という結果は，T₁, T₂, T₃ をどのように直列実行しても得られる結果ではなく，意味不明です．このことについて付加的な説明を加えると，トランザクションが同時実行されたときに，その結果が正しいとはトランザクション群のある直列実行が存在して，その時に得られる結果になる，ということです．実際，T₁, T₂, T₃ の直列実行の仕方は3! (=6) 通りありますが，それらが返す x と y の値は次の通りです．ここで，例えば，T₁→T₂→T₃ はトランザクションが T₁，T₂，T₃ の順に直列実行されたことを表します．

3.3 SII
 書込みスキュー異状や読込み専用トランザクション異状が発生するので，SI では真の意味での直列化可能性を保証できないということで，「SI を真の意味での直列化可能にする」ための研究が行われ，直列化可能スナップショット隔離性（serializable snapshot isolation，SSI）が Fekete ら[9]によって提案されました．まず，その定義を見てみたいと思いますが，鍵となる概念は SI の下でのデータ項目への書きや読みの間に観察される rw-従属性（rw-dependency）です．このような従属関係を基に直列化グラフ（serialization graph）を作成すると，SI の下で実行されるトランザクションの直列化可能性を規定することができ，SSI を定義できます．このことを，シドニー大学の研究者の論文 [8, 9, 10]を参考にして，少し詳しく見ていきましょう．
 まず，一般に，MVCC や SI といった多版同時実行制御のもとで生成される多版スケジュールの直列化可能性は，多版直列化グラフ（multiversion serialization graph, MVSG）を用いて説明することができます．First-Committer-Wins ルールが，x の版を生成する 2 つのトランザクションの間では，一方が開始する前に他方がコミットしていることを保証している SI の下では，データ項目 x の版はそれらの版を作成したトランザクションの時系列に従って順序付けられるので，それに基づき MVSG を次のように定義できます．つまり，MVSG では，次の状況 (i)～(iii) のときに，あるコミット済みトランザクション T₁ から別のコミット済みトランザクション T₂ にエッジ（edge，辺）を設定します．

　(i)

 (ii)

 (iii)

 図 5 に図 3 に示した書込みスキュー異状が生じたトランザクション T₁ と T₂ の同時実行の MVSG を示します．rw-従属性が点線の矢印で示されています．

 さて，トランザクション理論で知られているように[4]，一般に MVSG にサイクルがないことは，トランザクションの同時実行が直列化可能であることを保証します．したがって，同時実行制御に SI を使用するシステムでどのような種類の MVSG が発生する可能性があるかを理解することが重要になります．
 このことについて，Fekete ら[9, 10]は，「どのサイクルにも隣接して発生する 2 つの rw-従属性エッジがあり，さらに，これらのエッジのそれぞれが 2 つの同時実行されているトランザクションの間にあること」を示しました．そこで，同時実行されているトランザクション間の rw-従属性を脆弱なエッジ（vulnerable edge）と呼ぶことにし，サイクル内で 2 つの連続した脆弱なエッジが発生する状況を危険な構造（dangerous structure）と呼ぶことにします．これを図 6 に示します．2 つの連続する脆弱なエッジの接合部のトランザクションをピボット（pivot）トランザクションと呼びます．図 6 では T₁ がピボットです．そのうえで，SI のもとで直列化可能とならない同時実行の MVSG には必ずピボットがあることを示しました．

■　SI で書込みスキュー異状が発生することの説明
 図 3 を使って説明します．図 3 では rw-従属性を 2 つ確認できます．一つは T₂ がデータ項目 x を読んだ後に T₁ がデータ項目 x を更新しています．もう一つは，T₁ がデータ項目 y を読んだ後に T₂ がデータ項目 y を更新しています．では，これらのことは SI というトランザクションの同時実行環境下ではどういう意味を持つのでしょうか？
 まず，前者の場合ですが，SI の定義を思い出してください，次のようになります．「T₂ は，それが開始された時点で有効なコミット済みデータからなるスナップショットから常にデータを読み取る．T₂ の開始後にアクティブな他のトランザクションの更新は，T₂ には見えない」ということです．これは何を意味するのでしょうか？明らかです．T₁ が T₂ より先に実行され T₁ が開始される以前にコミットされては困る，ということを表しています．（First-Committer-Wins ルールの場合．もし，First-Updater-Wins ルールの場合は，T₁ が開始される以前にデータ項目 x を更新されては困る，となります）つまり，このことを回避するには，T₂ の実行を T₁ に先行させればよいわけです．このことを rw-従属性 T₂ ⇢rw T₁ で表したわけです．データ項目 y に関する後者の場合も同様で，rw-従属性 T₁ ⇢rw T₂ が得られます．この 2 つの rw-従属性から図 5 に示した書込みスキュー異状の MVSG が得られたわけです．明らかに，このグラフには「危険な構造」があります．したがって，T₁ と T₂ のこのスケジュールでの同時実行は直列化可能ではなかったことが分かります．

■　SI で読取り専用トランザクション異状が発生することの説明
 図 4 で示した読取り専用トランザクション異状の同時実行から MVSG を作成すると図 7 のようになります．明らかにこのグラフには「危険な構造」があります．したがって，図 4 に示した同時実行のスケジュールは直列化可能でないことが分かります．

 さて，ここまで議論すると，SI の下で直列化可能を実現するための考え方は，ほぼ明らかになったと言えます．トランザクションを同時実行していく過程で MVSG を作り，そこに「危険な構造」を見つけたら，それを解消するために何らかのトランザクションをアボート（abort）すればよいわけです．しかしながら，危険な構造は「サイクル・・・・内で 2 つの連続した脆弱なエッジが発生する状況」であったのですが，そのためには同時実行されているすべてのトランザクションの実行を監視してそれら間の rw/wr/ww-従属性からサイクルが発生していないかを見つけなければなりません．Cahill ら[10]はそのコストは尋常ではないと考え，サイクルが形成されているかどうかは無視して，2 つの連続した脆弱なエッジが発生する状況を検知することだけにしました．その代償として，SSI では擬陽性（false positive）が発生してしまうのです．

【定義 2】(SSI)
 SI の下で実行されるトランザクションの同時実行において，「2 つの連続した脆弱なエッジが発生する状況」を検知した場合は，直列化可能ではないと判定する．そうでなければ，SI の下で，直列化可能なトランザクションの同時実行が保証される．

 この定義に基づく SSI の実装は，まず，T を同時実行しているトランザクションとして，2 つのブールフラッグ（boolean flag）T.inConflict と T.outConflict を定義します．T.inConflict は同時実行されている何らかのトランザクションから T に rw-従属性があるか否かを示します．一方，T.outConflict はTから同時実行している何らかのトランザクションに rw-従属性があるか否かを示します．さらに，これらの情報を繋いで「2 つの連続した脆弱なエッジが発生する状況」を検知するために，通常の WRITE ロックとこのために特別に用意した SIREAD ロックを導入して行います．詳細に興味のある読者は Cahill らの論文[10]にあたってください．

【擬陽性】
 擬陽性を呈するトランザクションの同時実行例を図 8 に示します．

 ちなみに，図 8 で示されたトランザクションの同時実行の MVSG を描くと図 9 に示すとおりです．明らかに，そこには「危険な構造」があります．したがって，トランザクションの直列化可能性を損なう恐れがあるということで，ピボットの T₁ あるいは T₂ でも T₃ でも構いませんが，いずれかのトランザクションをアボートすることを SSI スケジューラは行うということです．

 では，何が，問題だったのでしょうか？この原因は明らかです．図 6 に示したように，本来は危険な構造をその一部とする rw/wr/ww-従属性の「サイクル」が存在するときに初めて直列化可能ではないと言えるのですが，SSI ではサイクル検出には膨大なコストが掛かることを懸念して，「危険な構造」ではなく「2 つの連続した脆弱なエッジが発生する状況」を検出したら，それだけで直列化可能ではないと判定してしまったということです．ただ，これに関しては，擬陽性はめったに起こらないと釈明しています[10]．

4. おわりに

 MVCC とは多版の概念を持ち込むことによりトランザクションの同時実行性の向上を目指した技術です．本稿では，MVCC の原型であるMVTO にまず焦点を当てて，2PL では同時実行できないトランザクションが MVCC では同時実行できることを示して，その考え方の基本を示しました．続いて，MVCC の考え方に則った SI に焦点を当てて，その考え方と，それが SQL の隔離性水準である SERIALIZABLE を実現するが，書込みスキュー異状や読取り専用トランザクション異状が発生し，理論的な意味での真の直列化可能性を実現するものではないことに言及しました．SI は真の直列化可能性を実現できる SSI に進化しましたが，SSI の現実的な実装では擬陽性という異状が発生してしまう可能性のあることも紹介しました．SI 並びに SSI の性能評価については先に紹介した通り，SI の下で TPC-C ベンチマークが異状を発生することなく実行可能であること，SSI の性能は様々なケースで 2PL より大幅に改善し，往々にして SI と同程度であったとの報告があることを紹介しました．
 PostgreSQL では隔離性水準を REPETABLE READ に設定すると SI が，SERIALIZABLE に設定すると SSI が駆動するように実装されています．また，PostgreSQL 14.1 Documentation（Chapter 13. Concurrency Control. 13.1 Introduction）[13] には次のような記載があります（アンダーラインは筆者による）．“Table- and row-level locking facilities are also available in PostgreSQL for applications which don’t generally need full transaction isolation and prefer to explicitly manage particular points of conflict. However, proper use of MVCC will generally provide better performance than locks.”このように，PostgreSQL はロック法ではなく MVCC の使用を推奨しているようです．
 このような状況ですが，隔離性水準を READ COMMITTED に設定して（このレベルでは lost update，すなわち ww-conflict が発生することがある），表レベル及び行レベルのロック機能を使って特定の競合ポイントを明示的に管理することで，ちゃんとアプリケーション開発を行っている事例のあることは筆者の耳にするところです．ベンチマークテストの結果はもちろん参考になるとは思いますが，2PL vs. MVCC の議論の要かなめは，データベースアプリケーション開発の現場で発生するトランザクション群の同時実行制御にどちらが適しているのか，雰囲気や時代に流されるのではなく，それを見極める「力」が現場に求められているということではないでしょうか．

【文献】

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

1. はじめに

 リレーショナルデータベース（RDB）設計には分解的アプローチと合成的アプローチの 2 つがあることは皆さんよくご存じのことと思います．
 分解的アプローチ（decomposition approach）はリレーショナルデータモデルを考案したコッド（E.F. Codd）により導入された「リレーションの正規化理論」[1, 2]に依って立つ RDBの設計法で，これまで多くの説明がなされているのでその認知度は大変高いと思います．このアプローチでは更新時異状（update anomaly）を解消するために，リレーションを関数従属性（FD）や多値従属性（MVD），
あるいは結合従属性（JD）を使って情報無損失分解して，第 1 正規形（1NF）から第 2 正規形（2NF），第 3 正規形（3NF），ボイス‐コッド正規形（BCNF），第 4 正規形（4NF），第 5 正規形（5NF）へと正規度を高めていきます．しかしながら，情報無損失分解と関数従属性保存は独立した概念なので，正規化により関数従属性が保存されない場合が生じることに十分注意する必要があります[3]．
 一方，合成的アプローチ（synthetic approach）はバーンシュタイン（P.A. Bernstein）によって提案された RDB の設計法 [4] で，RDB を設計するにあたり，データベース化の対象となった世界をリレーションスキーマ R(A₁, A₂, _…, A_n)と所与の FD 集合 F を指定して，それを基に「関数従属性保存・3NF・情報無損失分解」と三拍子揃った RDB を設計する手法です．このアプローチでは，F を構成している FD は必ず設計された RDB を構成するいずれかのリレーションスキーマの FD として定義されるので，関数従属性保存となります．

 以下で見るように，データベース化の対象となった世界は同一でも，分解的アプローチにより設計された RDB と合成的アプローチにより設計された RDB は一般的には異なった構成となります．では，どう違うのでしょうか？また，その差異はどのように説明されるのでしょうか？本稿では，この 2 つに焦点を当てて蘊蓄うんちくを傾けてみたいと思います．

2. 基礎的事項

 RDB 設計の分解的アプローチとそれに係る基礎的事項は本稿の読者には改めて説明する必要はないと考えられるので省略します．ここでは，合成的アプローチの理解に必要な事項のみを掻い摘んで説明します．

 まず，リレーションスキーマの定義とそれに関連する定義を示します．
【定義 1】（リレーションスキーマ）
 リレーションスキーマ R とはリレーション名 R と属性集合 Ω_R={A₁, A₂, _…n} からなり，R(A₁, A₂, _…, A_n)と表される．リレーションスキーマ R に所与の FD 集合 F={f₁, f₂, _…, f_p}を指定することができる．リレーションスキーマ R(A₁, A₂, _…, A_n)に所与の FD 集合 F_R が指定されていることを明示したいとき，R=(Ω_R, F_R)と表すこととする．ここに，Ω_R ={A₁, A₂, _…, A_n}，F_R={f₁, f₂, _…, f_p}である．

【定義 2】（リレーションスキーマタの等価）
 R₁=(Ω_R1, F_R1)とR₂=(Ω_R2, F_R2)をリレーションスキーマタとする．R₁ と R₂ が等価（equivalent，同値ともいう）とは次の条件が成立するときとし，R₁≡R₂ と表すこととする．ここに，∧は論理積，F_R1⁺ は F_R1 の閉包（定義 3 参照）を表す（F_R2⁺ についても同様）．iff は if and only if を表す．
   R₁≡R₂ iff Ω_R1=Ω_R2 ∧ F_R1⁺= F_R2⁺

【例題 1】
 例えば，R₁=({A, B, C}, {A→B, B→C})，R₂=({A, B, C}, {A→B, B→C, A→C})，R₃=({A, B, C}, {A→B, A→C})があった時，R₁ と R₂ は属性集合が同じでかつ{A→B, B→C}⁺={A→B, B→C, A→C}⁺ なので等価である（ R₁≡R₂ ）が，R₁ と R₃ は属性集合は同じであるものの{A→B, B→C}⁺≠{A→B, A→C}⁺なので等価でない（R₁≢R₃）．

 この等価関係は反射律，推移律，対称律を満たします．リレーションスキーマタの等価関係に言及したのは，後段で，設計された RDB の関数従属性保存を議論するときに必用となるからです．

■　関数従属性の集合 F の極小被覆
 関数従属性の集合 F が与えられたとき，その極小被覆（minimal cover）G を求めるアルゴリズムを示します．このアルゴリズムの時間計算量は多項式時間であり，扱いやすい（tractable）問題です．この証明に興味を抱いた者は拙著 [5] を参照してください．
 まず，FD の集合 F の閉包 F⁺ を定義する必要があります．
【定義 3】（FD 集合の閉包）
 リレーションスキーマ R(A₁, A₂, _…, A_n) に所与の FD 集合 F が指定されているとする．このとき，　F の閉包 F⁺ は次のように定義される．ここに，F ⊨ X→Y は X→Y がアームストロングの公理系のもとで F から導出されることを表す．

   F⁺={X→Y | X, Y⊆Ω_R ∧ F ⊨ X→Y}

 続いて，極小被覆を定義します．
【定義 4】（FD 集合の極小被覆）
 関数従属性の集合 G が関数従属性の集合 F の極小被覆（minimal cover）であるとは，次の条件を満たすときをいう．
  (a)　G と F は等価（equivalent，同値ともいう），すなわち，G^＋＝F⁺ である．
  (b)　G の全ての関数従属性は X→A，ここに A は単一の属性，の形をしている．
  (c)　G に，ある関数従属性 X→A と X の真部分集合 Z（Z⊂X）が存在して，
     G−{X→A}∪{Z→A} と G が等価になることはない．ここに，− は差集合演算である．
  (d)　G に，ある関数従属性 g が存在して，G−{g} と G が等価になることはない．

 極小被覆を求めるアルゴリズムは次の通りです．
【FD 集合 F の極小被覆 G を求めるアルゴリズム】
  (ステップ 1)　G = F とおく．
  (ステップ 2)　G 中の各関数従属性で右辺（＝被決定子（resultant））が単一の属性で
        ないものがあれば（これを X→{ A₁, A₂, · · ·, A_p } とする），右辺が単一
        の属性である p 個の関数従属性 X→A₁, X→A₂, · · ·, X→A_p で置き換える．
  (ステップ 3)　G 中の各関数従属性 X→A に対して，X を構成する各属性 B に対して，
        G−{X→A}∪{{X−B}→A} と G が等価ならば，G の X→A を {X−B}→A
        で置き換える．
  (ステップ 4)　G の各関数従属性 X→A に対して，G−{X→A} が G と等価ならば，
        G から X→A を取り除く．

 ステップ 3 とステップ 4 はこの順番で行う必要があります．例えば，リレーションスキーマ R(A, B, C)に所与の FD 集合 F={AB→C, C→B, A→B} が指定されているとき，もし，まずステップ 4 を，続いてステップ 3 を適用すると，結果として極小被覆もどきの集合 H= {A→C, C→B, A→B} が得られますが，これは I= H－{ A→B } とすると，A→B は A→C と C→B に推移律を適用すると得られる関数従属性であることから分かるように，H⁺ = I⁺ であり，H は極小被覆にはなっていません．

 ここで，極小被覆を求める簡単な例を示します．
【例題 2】（極小被覆を求める）
 リレーションスキーマ R(A, B, C, D)に所与の FD 集合 F = {AB→CD, C→D} が指定されているとする．F の極小被覆を求めなさい．
(解答)
 F にステップ 1 とステップ 2 を適用することにより G ={AB→C, AB→D, C→D} となる．ステップ 3 を行う．まず，AB→C の左辺に注目し，A あるいは B が余分ではないか検証する．そこで，A が余分であるかどうかを検証するために，H = G−{AB→C}∪{B→C} とし，H⁺= G⁺ かどうかをチェックする．H⁺ ⊇ G⁺ は明らかなので，H⁺⊆G⁺ かどうかをチェックする．そのため H にあり G にない関数従属性 B→C が G⁺ の元かチェックするが，B の G に関する閉包 B⁺ を求めれば，適用する G 中の関数従属性がないので B⁺= {B} である．明らかに，C⊆{B} ではないので，H⁺⊆G⁺ ではなく，よって H⁺≠G⁺ である．以下同様な論理でステップ 3 を実行した結果，置き換えられる G の関数従属性はないことが分かる．続いてステップ 4 を行う．I = G−{AB→D} とし，I⁺ = G⁺ をチェックする．G の関数従属性 AB→D について，{A, B} の I に関する閉包を求めると，X⁽⁰⁾ ={A, B}, X⁽¹⁾ = X⁽⁰⁾∪{C}, X⁽²⁾ = X⁽¹⁾∪{D} (= {A, B, C, D}) = X⁽³⁾となり，D∈X⁽³⁾ である．したがって，I = {AB→C, C→D} が F の極小被覆となる．この例では I 以外に F の極小被覆はない．

(解答終)

 なお，一般に F の極小被覆 G はただ 1 つとは限りません．したがって，最小（minimum）とは言わずに極小（minimal）というわけです．一般に極小被覆が複数個ある簡単な例を示しておきます．

【例題 3】（一般に極小被覆は複数個ある）
 リレーションスキーマ R(A, B, C)に所与の FD 集合 F = {A→BC, B→AC, C→AB} が指定されているとする．F の極小被覆を求めなさい．
(解答)
 G={A→B, A→C, B→A, B→C, C→A, C→B} として，極小被覆を求めるアルゴリズムを稼働すると次の 5 つを得る．
  ①　A→B, A→C, B→A, C→A
  ②　B→A, B→C, A→B, C→B
  ③　C→A, C→B, A→C, B→C
  ④　A→B, B→C, C→A
  ⑤　A→C, B→A, C→B

(解答終)

■　関数従属性保存
 リレーションスキーマ R が情報無損失分解されたとき，R 上で成立していた FD が定義できなくなくなることはない，つまり保存されているという概念が関数従属性保存です．そのためには，まず FD 集合の閉包の射影を定義することが必要です．

【定義 5】（FD 集合の閉包の射影）
 リレーションスキーマ R に所与の関数従属性の集合 F が指定されているとする．このとき，一般に Z⊆Ω_R として，F⁺の Z 上の射影 F⁺[Z]は次のように定義される．
   F⁺[Z]={X→Y|X→Y∈F⁺ ∧ X∪Y⊆Z}

  この定義を用いて関数従属性保存の定義を与えることができます．
【定義 6】(関数従属性保存)
 リレーションスキーマ R に所与の関数従属性の集合 F が指定されているとする．X→Y∈F⁺として，X→Yによる R の R[X, Y]と R[Ω_R－Y]への情報無損失分解が関数従属性保存であるとは，次が成立するときをいう．
   (F⁺[X∪Y]∪F⁺[Ω_R－Y])⁺=F⁺

 以上で，基礎的事項の説明は終了です．F⁺ を求める具体例や，リレーションスキーマを FD で情報無損失分解した場合に，どのようなときに関数従属性が保存されない状況が発生するのかなどの例題は SRA OSS Tech Blog に収録されている拙稿 [3]に掲載されているので，参照してください．
 続いて，RDB 設計の合成的アプローチの説明に移りましょう．

3. RDB 設計の合成的アプローチ

 1976 年にバーンシュタイン（P.A. Bernstein）が提案した RDB 設計の合成的アプローチ（synthetic approach）[4] は，データベース化の対象となった世界を表すリレーションスキーマ R(A₁, A₂, _…, A_n)に所与の FD 集合 F が指定されているとして，それを基に「関数従属性保存・3NF・情報無損失分解」と三拍子揃った RDB を設計するという手法です．そのアルゴリズムは次の通りです．
【合成的アプローチによる RDB 設計アルゴリズム】
  リレーションスキーマ R に所与の関数従属性の集合 F が指定されているとする．このとき，合成的アプローチによる RDB 設計のアルゴリズムは次の通りである．

(ステップ 1)　F の極小被覆 G を一つ見つける．
(ステップ 2)　X を決定子（determinant）に持つ G の全ての関数従属性 X→B₁, X→B₂, · · ·, X→B_k
       に対して（G が極小だから各 B_i は単一属性），Y = {B₁, B₂, …, B_k} とし，リレー
       ションスキーマ R(X, Y) を作る．この操作を G の全ての関数従属性に対して行う．
       その結果，リレーションスキーマタ R₁(X₁, Y₁), R₂(X₂, Y₂), · · · , R_m(X_m, Y_m) を得る．
(ステップ 3)　もし，ステップ 2 で作ったリレーションスキーマタ R₁, R₂, · · · , R_m の中に，R の
       候補キーを含むリレーションスキーマが存在すれば，{ R₁, R₂, · · · , R_m } が所望の
       分解であり，もしそうでなければ R の候補キーのひとつを K として R^’ (K) を作る
       と（作り方から，R^’ 上には自明でない関数従属性は存在していない），{R^’ (K), R₁,
       R₂, · · · , R_m} が所望の分解である．

 前述の通り，一般に F の極小被覆 G はただ 1 つとは限らないので，求められた G の違いで，得られる RDB が異なってくる可能性があることに注意します．
 また，このアルゴリズムの正しさ，つまりこのアルゴリズムにより R の関数従属性保存で情報無損失な 3NF への分解が得られることは，ステップ 2 とステップ 3 で行った R の分解が，(1) 関数従属性保存であること，続いて，(2) （各成分リレーションスキーマが）3NFであること，そして，(3) 情報無損失分解であることを証明することで示されます．特に(3)の証明は結構難易度が高いので，ここでは立ち入らないことにしますが，アルゴリズムの正しさの証明は拙著 [5] でも与えられているので，興味を抱いた読者はご参照ください．
 なお，この手法が合成的と呼ばれるのは，ステップ 2 で同じ決定子を持つ関数従属性がまとめ上げられて 1 つの候補キーが合成されて（synthesized），その結果，1 つのリレーションスキーマが合成されることからきています．

■　実は，3NF より正規度の高い BCNF であること
 1993年にビンセント（M.W. Vincent）らにより「重複する候補キーのペアがない 3NF リレーションスキーマは BCNF であること」が証明されました[6]．上記，合成的アプローチによる RDB 設計アルゴリズムのステップ 2 を見て分かるように，得られるリレーションスキーマ R(X, Y)では X のみが候補キーで，R に重複する候補キーのペアはあり得ません．したがって，合成的アプローチで設計された RDB は BCNF のリレーションスキーマタからなると言えます（もちろん，3NF です）．よって，合成的アプローチは「関数従属性保存・BCNF・情報無損失分解」と三拍子揃った RDB を設計する手法と言い換えた方が正確でしょう．3NF ではなく BCNF となっていることで，3NF ではあるが BCNF ではないリレーションで発生する更新時異状を合成的アプローチで RDB を設計することで抑制することが可能となってきます．このことについては，例題 6 でより具体的に論じます．なお，以下ではこのことを十分に承知したうえで「関数従属性保存・3NF・情報無損失分解」という伝統的な表現を使用します．

 次章では，上記のアルゴリズムの下で RDB がどのように設計されていくかについてその感触をつかんでいただくと共に，分解的アプローチと合成的アプローチでは，たとえ最初に与えられたリレーションスキーマが同一でも得られた RDB は一般には異なることを観察してみたいと思います．

4. 分解的 vs. 合成的アプローチ―その差異の本質は？―

 本章では，RDB を分解的アプローチと合成的アプローチで設計してみて，両アプローチの違いを観察することによって，特に合成的アプローチの持っている意味合いについて検証してみたいと思います．合成的アプローチの目標は「情報無損失・3NF・関数従属性保存」の RDB を設計することなので，それに合わせて分解的アプローチでの RDB 設計のゴールは「情報無損失・3NF」のリレーションスキーマタからなる RDB を設計することとします．分解的アプローチでは一般に関数従属性は保存されませんから[3]，両者を比較するには妥当な条件設定と考えられます．
 それでは，幾つかの例題を通して両アプローチで得られた結果を比較し，その差異を検討してみましょう．

【例題 4】
 リレーションスキーマ R(A, B, C, D)に所与の FD 集合 F={A→B,B→C} が指定されているとする．RDB を合成的アプローチと分解的アプローチで設計してみなさい．
(解答)
 (1) 分解的アプローチで設計した RDB
   R の候補キーは{A, D}で，R の非キー属性は B と C であり，B と C は A に関数従属している，
   つまり{A, D}には完全関数従属していないので R は 2NF ではない．そこで，B→C を使って
   R を R[B,C] と R[A, B, D] に情報無損失分解すると，R[A, B, D]も 2NF ではないので，それを
   A→B で R[A, B]と R[A, D]に情報無損失分解する．その結果，{R[A, B], R[B,C], R[A, D]}が
   所望の RDB となる．この場合，関数従属性保存であることは A→B が R[A, B]で，B→C が
   R[B,C]で定義されていることから分かる．
 (2) 合成的アプローチで設計した RDB
   F 自体が F の極小被覆である(ステップ 1)．A→B の決定子 A と B→C の決定子 B は異
   なるので，リレーションスキーマタ R₁(A, B), R₂(B, C) を得る（ステップ 2）．ところで，
   R の候補キーは {A, D} であるが，これは R₁ にも R₂ にも含まれないので，R^’(A, D) を作
   る(ステップ 3)．その結果，{R₁(A, B), R₂(B, C), R^’(A, D)}が所望の RDB である．

(解答終)

 この例では，どちらのアプローチをとっても，設計された RDB は同一で，共に「情報無損失分解・3NF・関数従属性保存」となっていることが分かります．

【例題 5】
 リレーションスキーマ R(A, B, C, D)に所与の FD 集合 F={A→B, B→C, A→D, D→C}が指定されているとする．RDB を分解的アプローチと合成的アプローチで設計してみなさい．
(解答)
 (1) 分解的アプローチで設計した RDB
   R の候補キーは A で，R の非キー属性 B, C, D は A に完全関数従属しているので，R は 2NF
   である．しかし，A→B→C と A→D→Cという推移的関数従属性が存在するので 3NF ではない．
   そこで，A→B→C を解消するべく，R を B→C を使って R[B, C] と R[A, B, D] に情報無損失
   分解すると，それらは 3NF になるが D→C を保存できなく，この情報無損失分解は関数従属性
   保存ではないことが分かる．同様に，A→D→C を解消するべく，R を D→C を使って R[D, C]
   と R[A, B, D] に情報無損失分解すると，それらは 3NF になるが B→C を保存できなく，この
   情報無損失分解も関数従属性保存ではないことが分かる[3]．したがって，設計された RDB
   {R[B, C], R[A, B, D]} と {R[D, C], R[A, B, D]} はいずれも「情報無損失分解・3NF」ではある
   ものの関数従属性保存ではない．
 (2) 合成的アプローチで設計した RDB
   F 自体が F の極小被覆である(ステップ 1)．A→B，A→D であり，B→C，D→C であるので，
   リレーションスキーマタ R₁(A, B, D), R₂(B, C), R₃(D, C) を得る（ステップ 2）ところで，R
   の候補キーは A であるが，A は R₁ に含まれているので，{R₁(A, B, D), R₂(B, C) , R₃(D, C)}
   が所望の RDB である(ステップ 3)．合成的アプローチをとったことにより，得られた RDB
   は「情報無損失分解・3NF・関数従属性保存」である．

(解答終)

 では，この例で、もう少し詳しく両アプローチを比較・検討してみましょう．両アプローチの下で設計された RDB は次のようでした．

  分解的アプローチ：{R[B, C], R[A, B, D]}，あるいは{R[D, C], R[A, B, D]}
  合成的アプローチ：{R₁(A, B, D), R₂(B, C), R₃(D, C)}

 以下，一般性を失うことなく，分解的アプローチで設計された RDB は{R[B, C], R[A, B, D]} であるとして議論を進めます．
 そこで，両者の違いを理解するために，具体的にリレーション R へのタップルの挿入を想定して，その時に観察される現象を見てみることにします．分かり易さのため，R のインスタンス R は単純に 1 本のタップル (a, b, c, d) からなっている，すなわち R={(a, b, c, d)}，とします．すると，(a, b, c, d) は分解的アプローチでは R[B, C] ={(b, c)}, R[A, B, D] ={(a, b, d)}} と格納され，合成的アプローチでは R₁(A, B, D) ={(a, b, d)}, R₂(B, C) ={(b, c)}, R₃(D, C) ={(d, c)} と格納されます．そこで，R に D→C に抵触するタップル(a’, b’, c’, d)，ここに a’≠a, b≠’b, c≠’c，を挿入しようと目論もくろくんだ場合，何が起こるのか観察してみます（もちろん，R では D→C が成立していますから (a’, b’, c’, d) を挿入することはできません）．両アプローチの下で設計された RDB で発生する現象は次の通りです．
 (1) 分解的アプローチで観察される現象

R[B, C] への (b’, c’) の挿入は既存の (b, c) と抵触しないので行えます．また，R[A, B, D] への (a’, b’, d) の挿入は既存の (a, b, d) と抵触しないので行えます．したがって，R[B, C]={(b, c), (b’, c’)}，R[A, B, D]={(a, b, d), (a’, b’, d)} となります．そこで，R[B, C]*R[A, B, D] をとってみると，R[B, C]*R[A, B, D]={(a, b, c, d), (a’, b’, c’, d)} となります．R[B, C] と R[A, B, D] は R の B→C による情報無損失分解なので，これは R= R[B, C]*R[A, B, D]={(a, b, c, d), (a’, b’, c’, d)} を意味することになりますが，R に所与の D→C に抵触することは明らかです．これが B→C による R の{R[B, C], R[A, B, D]} への情報無損失分解が関数従属性保存でないことによる結果なわけです．  この現象はよりフォーマルに次のように説明できるでしょう．  まず，リレーションスキーマ R(A, B, C, D) の B→C による分解は情報無損失分解ですが，それは次式を意味します．ここに，(∀R∈R)は R は R の任意のインスタンスを表します．  (∀R∈R)(R=R[B, C]*R[A, B, D])  次に，リレーションスキーマ R の定義は次の通りです．  R=(ΩR, FR)，ここに，ΩR ={A, B, C, D}，FR={A→B, B→C, A→D, D→C}．  一方，R[B, C]*R[A, B, D] のリレーションスキーマとしての定義は次の通りとなります．  R’=R[B, C]*R[A, B, D]= (ΩR’, FR’)，ここに，ΩR’ ={A, B, C, D}，FR’ ={A→B, B→C, A→D}．  そこで，R=(ΩR, FR) と R’ =(ΩR’, FR’)を比較してみると，ΩR=ΩR’ ですが，FR+≠FR’+です．つまり，R と R’ はリレーションスキーマとして等価でないことが分かります．  従って，分解的アプローチで得られた RDB については，次が成立しているといえます．    (∀R∈R)(R=R[B, C]*R[A, B, C]) ∧    R ≢R[B, C]*R[A, B, D]      ・・・・・・・・・・(1)

 (2) 合成的アプローチで観察される現象

R2(B, C) への (b’, c’) の挿入は既存の (b, c) と抵触しないので行えます．また，R1(A, B, D) への (a’, b’, d) の挿入は既存の (a, b, d) と抵触しないので行えます．これらは分解的アプローチでの R[B, C] への (b’, c’) の挿入と R[A, B, D] への (a’, b’, d) の挿入に対応しています．しかし， R3(D,C)への (d, c’) の挿入は R3 (D,C) で D→C が成立しているので既存の (d, c) と抵触しそれを行えません．したがって，よしんば R2 と R1 へそれぞれ (b’, c’) と (a’, b’, d) が挿入され，R2(B, C)={(b, c), (b’, c’)}，R1(A, B, D)={(a, b, d), (a’, b’, d)}となったとしても，R3 には (d, c’) の挿入は許されずに R3(D, C)={(d, c)}のままなので，R=R2(B, C)*R1(A, B, D)*R3(D, C)={(a, b, c, d)}となり，R に D→C に抵触するようなタップルの挿入は許されない仕組みとなっています．つまり，R の {R1(A, B, D), R2(B, C), R3(D, C)}への分解は情報無損失でかつ関数従属性保存の分解となっています．そして，この現象はよりフォーマルに次のように説明できます．  R”=R2(B, C)*R1(A, B, D)*R3(D, C)= (ΩR”, FR”) とすると，ΩR”={A, B, C, D}，FR”={A→B, B→C, A→D, D→C} となり，R と R” は等価です．つまり，合成的アプローチで得られた RDB については，次が成立していることとなります．    (∀R∈R)( R=R1(A, B, D)* R2(B, C)*R3(D, C)) ∧    R≡R1(A, B, D)*R2(B, C)*R3(D, C) ・・・・・・・・・・(2)

 (1)式と(2)式は分解的アプローチと合成的アプローチの差異をフォーマルに表現していることになります．繰り返しになりますが，両アプローチで設計された RDB は共に情報無損失分解であることは保証されてはいますが，(1)式により分解的アプローチで設計された RDB はリレーションスキーマタの等価関係の不成立により関数従属性保存ではないことを，一方，(2)式により合成的アプローチで設計された RDB はリレーションスキーマタの等価関係の成立により関数従属性保存であることが明確に読み取れます．

 さて，分解的アプローチで設計された RDB と合成的アプローチで設計された RDB を見比べると，R[B, C]≡R₂(B, C), R[A, B, D]≡R₁(A, B, D) なので，合成的アプローチで設計された RDB では，分解的アプローチにより設計された RDB と比べて R₃(D, C) だけ余計（？）に設計されている，と感じるかもしれません．実際，リレーションを RDB に格納するとなると，その分だけ余計にメモリを食うことになります．しかし，上で見た通り，これが関数従属性保存を保証する代償であったわけです．

 RDB の設計にあたっては，設計者は分解的アプローチを採用するべきか，合成的アプローチを採用するべきか，その選択を迫られます．少し乱暴な表現をすれば，「（データを格納するための）メモリは食わないが関数従属性保存の確約はない分解的アプローチ」を選ぶか，「分解的アプローチに比べれば，一般にはメモリを食うものの関数従属性保存を保証してくれる合成的アプローチ」を選ぶか，その決断を RDB 設計者は行わなくてはならないということです．これが分解的 vs. 合成的アプローチのpros and cons（利点と問題点）の一面です．

■　合成的アプローチでは BCNF にまでなっていることの恩恵
 ところで，3 章で述べた通り，合成的アプローチで設計された RDB のリレーションスキーマタは 3NF より正規度の高い BCNF となっています．このことが，両アプローチの pros and cons と大いに関係することになります．議論は RDB の更新時異状と絡みます．例題を挙げて論じてみましょう．

【例題 6】
 ある学校での，学生（学生名で一意識別），学生が履修する科目（科目名で一意識別），そしてその科目を教授する教員（教員名で一意識別）の関係を表すリレーションスキーマを SCT=(Ω_SCT, F_SCT)，ここに，Ω_SCT ={学生，科目名，教員名}，F_SCT ={{学生名, 科目名}→教員名，教員名→科目名}とする．RDB を分解的アプローチと合成的アプローチで設計してみなさい．
(解答)
 (1) 分解的アプローチで設計した RDB
   リレーションスキーマ SCT の候補キーは{学生名, 科目名}と{学生名, 教員名} と 2 つある．
   したがって，非キー属性は存在しないので 3NF である．そこで，一般性を失うことなく，
   たとえば，{学生名, 科目名} を主キーとすれば，SCT(学生名, 科目名，教員名)が所望の
   RDB である．
 (2) 合成的アプローチで設計した RDB
   F_SCT 自体がその極小被覆である(ステップ 1)．{学生名, 科目名}→教員名，教員名→科目名
   なので，R₁(学生名, 科目名，教員名)と R₂ (教員名，科目名)が得られる(ステップ 2)．SCT
   の候補キーは{学生名, 科目名}と{学生名, 教員名}であるが，R₁ は候補キー{学生名, 科目名}
   を含んでいるので，R₁(学生名, 科目名，教員名)と R₂(教員名，科目名)が所望の RDB の
   設計結果となる(ステップ 3)．

(解答終)

 さて，両アプローチを比較・検討してみましょう．両アプローチの下で設計された RDB は次のようです．

   分解的アプローチ：SCT(学生名, 科目名，教員名)
   合成的アプローチ：R₁(学生名, 科目名，教員名), R₂(教員名，科目名)

この結果で注意しておくべき点は，SCT と R₁ の属性集合は等しいものの，リレーションスキーマとしてきちんと表現すれば，SCT=({学生名, 科目名，教員名}, {{学生名, 科目名}→教員名，教員名→科目名})，R₁=({学生名, 科目名，教員名}, {{学生名, 科目名}→教員名})であり，{{学生名, 科目名}→教員名，教員名→科目名}⁺≠{{学生名, 科目名}→教員名}⁺なので，SCT ≢R₁ であること，もう一つは，R₁ では定義されていない 教員名→科目名 が R₂ で定義されていることです．

 さて，分解的アプローチではリレーションスキーマ SCT そのものが RDB の設計ゴールとなり，この場合「情報無損失分解・3NF・関数従属性保存」となっています．一見，めでたしめでたし，と映りますが，よく知られているように，SCT は 3NF であるが BCNF ではありません．なぜならば，重複する候補キーのペア {学生名, 科目名} と {学生名, 教員名} が存在するからです．したがって，BCNF ではないことによる「更新時異状が発生する」ことになります[5]．これらの異状は，「タップル挿入時異状」，「タップル削除時異状」，「タップル修正時異状」として現れますが，たとえばリレーション SCT が図 1 に示すようであったとすると，以下に示すような現象として観察されます．

         SCT

 タップル挿入時異状：たとえば，新任教員の佐藤が赴任しプログラミングを担当することになったとします．まだ，佐藤先生のプログラミングを履修登録した学生がいないと，タップル(―，プログラミング，佐藤)はキー制約に抵触するので，リレーション SCT には挿入できません．ここに ― はナル（null）を表します．
 タップル削除時異状：たとえば，学生の伊藤が西川先生の教えるソフトウェアが難しそうなので履修を取りやめたとすると，タップル(伊藤，ソフトウェア，西川)を削除することになりますが，西川先生の教えるソフトウェアを履修している学生が伊藤一人だったので，西川先生がソフトウェアを教えているという事実を SCT に保存できなくなります．もちろん，(―，ソフトウェア，西川)はキー制約に抵触するので挿入できません．
 タップル修正時異状：たとえば，学生の伊藤がソフトウェアではなく北川先生のハードウェアに履修を変更すると，タップル(伊藤，ソフトウェア，西川)を(伊藤，ハードウェア，北川)に修正するのは良いが，同時に西川先生がソフトウェアを教えているという事実を SCT に保存できなくなります．この更新時異状を解消するために，分解的アプローチでは，SCT を SCT[教員名，科目名]と SCT[学生名，教員名]に情報無損失分解することになりますが，そうすると関数従属性 {学生名, 科目名}→教員名 が保存できなくなるという新たな異状に直面することになります．

 一方，合成的アプローチではどのような現象が観察されるのか見てみましょう．図 2 に合成的アプローチにより得られた RDB を示します．

         R₁

              R₂

 この場合，分解的アプローチで指摘された更新時異状は発生しません．たとえば，新任教員の佐藤が赴任しプログラミングを担当することになったとすれば，R₂ にタップル（佐藤，プログラミング）を挿入すればそれで済みます．したがって，タップル挿入時異状は発生しません．学生の伊藤が西川先生の教えるソフトウェアが難しそうなので履修を取りやめたとすると，R₁ からタップル(伊藤，ソフトウェア，西川)を削除することになりますが，西川先生がソフトウェアを教えているという事実は R₂ にしっかり保存されています．したがって，タップル削除時異状は観察されません．たとえば，学生の伊藤がソフトウェアではなく北川先生のハードウェアに履修を変更すると，R₁ のタップル(伊藤，ソフトウェア，西川)を(伊藤，ハードウェア，北川)に修正するだけでよく，西川先生がソフトウェアを教えているという事実は R₂ に保存されており，タップル修正時異状は発生しません．

 フォーマルに上記の議論をまとめておくと，次のようです．
 分解的アプローチで得られた RDB については，次が成立しています．

      (∀R∈R)(R=R) ∧ R≡R      ・・・・・・・・・・・・・(3)

 一方，合成的アプローチで得られた RDB については，次が成立していいます．

      (∀R∈R)( R=R₁(学生名, 科目名，教員名)*R₂(教員名，科目名)) ∧
      R≡R₁(学生名, 科目名，教員名)*R₂(教員名，科目名)  ・・・・・(4)

 分解的アプローチ，合成的アプローチ，共に情報無損失分解とリレーションスキーマタの等価関係が肯定的に示されましたが，分解的アプローチでは R が 3NF ではあるものの BCNF ではありませんでした．一方，合成的アプローチで得られた R₁ と R₂ は共に BCNF です．この差が，分解的アプローチで RDB を設計した場合に，更新時異状発生の原因となったわけです．

 さて，上に示した現象は，RDB を設計するに当たり，分解的アプローチを採るのか合成的アプローチを採るのかという意思決定に際して，関数従属性保存を保証するために必要となるリレーションを格納するために「メモリ」が増加するという視点に加えて，3NF ではあるが BCNF ではないために発生する「更新時異状」という視点も勘案したうえで，どちらのアプローチを採るかを決定しないといけないということを主張しているということで，この 2 軸を勘案すると，これまた少し乱暴な表現となりますが，その選択は次のようにまとめられると思います．
 選択 1 :（データを格納するための）メモリは食わないが，設計された RDB が関数従属性保存であ
     るという確約はなく，また，RDB を構成するリレーションスキーマが 3NF ではあるものの
     BCNF の確約はないので，そのことにより更新時異状が発生するかもしれないというリスク
     のある分解的アプローチ
 選択 2 : 分解的アプローチに比べれば一般にメモリを食うものの，設計された RDB が関数従属性保
     存で，また，RDB を構成するリレーションスキーマが BCNF であるので，3NF ではあるが
     BCNF ではないことによる更新時異状は発生しないことが約束されている合成的アプローチ

5. おわりに

 本稿では，RDB 設計のための「分解的アプローチ」と「合成的アプローチ」を俎上に上げて蘊蓄うんちくを傾けました．RDB 設計にあたり与えられたリレーションスキーマと指定された所与の関数従属性の集合が同一でも，分解的アプローチと合成的アプローチでは一般に RDB の設計結果は異なります．分解的アプローチは設計された RDB が「情報無損失分解・3NF」であることは保障してくれますが，一般には関数従属性保存は保証してくれません．一方，合成的アプローチは「情報無損失分解・3NF・関数従属性保存」という 3 拍子揃った RDB 設計を保証してくれます．加えて，合成的アプローチでは作られたリレーションスキーマは厳密には BCNF まで正規度が上がっているので，いわゆるリレーションが 3NF ではあるが BCNF ではないために発生してしまう更新時異状も回避することができます．ただ，合成的アプローチは関数従属性保存を担保する代償として，分解的アプローチに比べて格納するべきデータ量は多くなり，メモリを食うことになります．
 さて，この二者択一，貴方ならどちらを選択しますか？

【文献】

[1]

[2]

[3]

[4]

[5]

[6]

 リレーショナルデータベース（RDB）を設計するにあたり，「リレーションは第 3 正規形（3NF）にしましょう」とはよく言われることです．リレーションの正規化理論によると，3NF への分解が情報無損失であることは間違いのないことですが，その際，関数従属性は保存されるのか，されないのか？このことについて，どうも不確かな認識が流布しているのではないか？と思われる事例に遭遇したので，この記事を書く気になりました．

 その事例とは，何気なく過去の「データベーススペシャリスト試験問題」を眺めていた時に目に留まった次の設問と解答です．

　問 4

  ア　第 2 正規形から第 3 正規形への変換
  イ　第 3 正規形からボイスコッド正規形への変換
  ウ　非正規形から第 1 正規形への変換
  エ　ボイスコッド正規形から第 4 正規形への変換

 この問題の正解は「ア」とされています[2]．

 さて，この設問と正解を眺めていて釈然としない点が 2 つありました．
 一つは，情報無損失分解の定義は与えられていますが，「関数従属性保存」の定義が与えられていません．果たして，どういう意味でこの用語を使っているのでしょうか？
 もう一つは，「情報無損失分解ができ，かつ，関数従属性保存が成り立つ変換が必ず存在するもの」を問うていますが，「必ず」とは一体どのような意味で使っているのでしょうか？「ア」を正解とするということなので，「リレーションの第 2 正規形から第 3 正規形への変換は必ず情報無損失分解かつ関数従属性保存である」が出題者の意図ではないかと推察されますが，本当にそうなのでしょうか？
 そこで，本稿では，この問題を少しばかり深堀してみることとしました．

2. 基礎的事項

 議論を進めるために必要な概念を整理しておきます．
【定義 1】（リレーションスキーマとリレーション）
 リレーションスキーマ R とはリレーション名 R と属性のリスト A₁, A₂, _…, A_n からなり，R(A₁, A₂, _…, A_n) と表される．dom をドメイン関数とするとき，R⊆dom(A₁)×dom(A₂)×_…×dom(A_n) をリレーションスキーマ R のインスタンス，あるいは dom(A₁)，dom(A₂)，_…，dom(A_n) 上のリレーション R という．
 リレーションスキーマ R である性質 P が成立するとは R のすべてのインスタンス R で P が成立するときおよびその時のみをいう．

【定義 3】（所与の関数従属性集合）
 リレーションスキーマ R に所与の（given）関数従属性の集合 F＝{f₁, f₂, _…, f_p}，ここに(∀i= 1, 2, …, p)(f_i=X_i→Y_i ∧ X_i, Y_i⊆Ω_R)，を指定できる．ここで，Ω_R は R の全属性集合 {A₁, A₂, _…, A_n} を表し，一般に X, Y を集合とするとき，X⊆Y は X が Y の部分集合であることを，X⊂Y は X が Y の真部分集合（proper subset）であることを表す．

【定義 4】（関数従属性集合の閉包）
 リレーションスキーマ R に所与の関数従属性の集合 F が指定されているとする．このとき， F の閉包 F⁺ は次のように定義される．ここに，F ⊨ X→Y は X→Y がアームストロングの公理系のもとで F から導出されることを表す．
    F⁺={X→Y | X, Y⊆Ω_R ∧ F ⊨ X→Y}

 つまり，F⁺ は F が与えられたとき， F を基にして R 上で成立するすべての FD からなる集合を表します．F⁺ を求めるアルゴリズムを示しますが，その前に，次が成立することに注目します．ここに，　X⁺ は F に関する X の閉包を表し，iff は if and only if，すなわち必要かつ十分条件を表します．
    (∀X, Y⊆Ω_R)(X→Y∈F⁺ iff Y⊆X⁺)

 なお，X⁺ を求めるアルゴリズムは次のとおりです．このアルゴリズムの時間計算量は多項式時間であり，扱いやすい（tractable）問題です．

【X⁺ を求めるアルゴリズム】
 1． X⁽⁰⁾=Xとおく．
 2． X⁽ⁱ⁾= X^(i－1)∪{A|A∈Z ∧ Y→Z∈F ∧ Y⊆X^(i－1)} (i≧1)とする．
 3． もし，X⁽ⁱ⁾= X^(i－1) ならX⁺= X^(i－1) とおく．そうでなければステップ 2 にいく．

【例題1】
 リレーションスキーマ R(A, B, C) に所与の FD 集合 F={A→B, B→C}が指定されているとする．たとえば，X={A} としてX⁺ を求めると，ステップ 1 で X⁽⁰⁾={A}, ステップ 2 と 3 を繰り返して，X⁽¹⁾= X⁽⁰⁾∪{B}, X⁽²⁾= X⁽¹⁾∪{C} (={A, B, C}), X⁽³⁾= X⁽²⁾ となり, X⁺={A, B, C}を得る．

 さて，F⁺ を求めるアルゴリズムは次のとおりです．

【F⁺ を求めるアルゴリズム】
 1． F⁺=Φ とおく．
 2． 2^ΩR－Φ の各元 X に対してその閉包 X⁺を求め，F⁺ = F⁺∪{X→X⁺} とする．
 3． ステップ 2 の操作が全て終了すれば，その時の F⁺ が求める結果である．

 ステップ 2 で，2^ΩR－Φ の各元 X に対してその閉包 X^＋ を求めていることから明らかなように，このアルゴリズムの時間計算量は O(2^|ΩR|)，ここに O はオーダー関数，|Ω_R |は Ω_R の濃度を表す，と指数時間となり，扱いにくい（intractable）問題であることが分かります．つまり，上記のアルゴリズムは|Ω_R |が小さいときは問題なく動きますが，それが大きくなるにつれてとんでもない時間を要することになります．
 なお，リレーションの情報無損失分解に係る関数従属性保存を論じるためには，F⁺ の属性集合Z（⊆Ω_R）上の射影 F⁺[Z] を定義する必要がありますが（定義 5），それを端的に行うためにはステップ 3 をステップ 3’ に置き換えておくと都合がよいのでそのようにします（射影と関わらない議論はステップ 3 で得られた F⁺ を念頭に置いて行っています）．
 3’． ステップ 2 の操作が全て終了すれば，その時の F⁺ が求める結果であるが，もし
   F⁺ の元 X→X⁺ の被決定子が X⁺=A₁A_2…A_q（A_i∈Ω_R, q≧2）のように単一の属性で
   でなければ，X→X⁺ をX→A₁, X→A₂, …, X→A_q置き換えた F⁺ を求める結果とする
   （この置換えは，X→YZ iff X→Y ∧ X→Z が成立することによる）．
   ここに，一般に A₁A_2…A_q は集合{A₁, A₂, _… , A_q} の簡略表現とする（以下，同様）．
   したがって，たとえば AB={A, B}={B, A}=BA である．

【例題2】
 リレーションスキーマ R(A, B, C)に所与の FD 集合 F={A→B, B→C} が指定されているとする．このとき，F⁺ を求めると，2^ΩR={Φ, A, B, C, AB, AC, BC, ABC} であるので，ステップ 1 で F⁺=Φ，ステップ 2 と 3 を繰り返して，A⁺=ABC, B⁺=BC, C⁺=C, AB⁺=ABC, AC⁺=ABC, BC⁺=BC, ABC⁺=ABC なので，ステップ 3 で F⁺ は次のようになる．
 F⁺={A→ABC, B→BC, C→C, AB→ABC, AC→ABC, BC→BC, ABC→ABC}
F⁺をステップ 3 ではなくステップ 3’ を用いて求めた場合，それは次のようになる．
 F⁺={A→A, A→B, A→C, B→B, B→C, C→C, AB→A, AB→B, AB→C, AC→A,
   AC→B, AC→C, BC→B, BC→C, ABC→A, ABC→B, ABC→C}
なお，一般に F⁺ には A→A や AB→A など自明な FD も含まれているが，F⁺ はそれらも含めて R 上で成り立つ関数従属性の全てからなる集合を表しているということである．

【定義5】（関数従属性集合の閉包の射影）
 リレーションスキーマ R に所与の関数従属性の集合 F が指定されているとする．このとき，一般に Z⊆Ω_R として，F⁺ の Z 上の射影 F⁺[Z]は次のように定義される．ここに F⁺ はステップ 3’ を用いて求められており，A∈Ω_R である．
   F⁺[Z]={X→A|X→A∈F⁺ ∧ X∪A⊆Z}

【例題3】
 リレーションスキーマ R(A, B, C)に所与の FD 集合 F={A→B, B→C} が指定されているとする．このとき，F⁺ の {B, C} 上の射影，F⁺[B, C] は次のようになる．
 F⁺[B, C]= {B→B, B→C, C→C, BC→B, BC→C }

 なお，B, C∈Ω_R としたとき，F⁺[B, C]は本来は F⁺[{B, C}]あるいは F⁺[BC]と書くべきであるが，慣習的に F⁺[B, C]と書くことも多く，本稿でもそれに倣っている．

【定義6】（リレーションスキーマの情報無損失分解）
 リレーションスキーマ R の情報無損失分解は F⁺ の元 X→Y （X，Y⊆Ω_R）を使って R を 2 つの射影 R[X∪Y]と R[Ω_R－Y]，ここに － は差集合演算を表す，に分解することをいう．

 FD による分解はリレーションスキーマが 2 つの射影に情報無損失分解されるための十分条件なので，この分解は情報無損失，すなわち R=R[X∪Y]*R[Ω_R－Y]が成立することは改めて言うまでもないことです．ここに * は自然結合演算を表しています．

 ここで，念のためにリレーションスキーマが第 2 正規形（2NF），第 3 正規形（3NF）そしてボイス‐コッド正規形（BCNF）であることの定義を確認しておきます．「リレーションスキーマ R が第 2 正規形（2NF）であるとは，R は 1NF であって，R の全ての非キー属性は R の各候補キーに完全関数従属している」こと，「リレーションスキーマ R が第 3 正規形（3NF）であるとは，R は 2NF であって，R の全ての非キー属性は R のいかなる候補キーにも推移的に関数従属しない」こと，そして，リレーションスキーマ R がボイス‐コッド正規形（BCNF）であるとは，「X→Yを R の関数従属性とするとき，X→Y は自明な FD であるか，あるいは X は R のスーパーキーである」ことです．
 なお，リレーショナルデータモデルと正規化理論の原典に立ち戻って RDB 設計の分解的手法を今一度整理しておきたい向きには文献[3, 4]を，本稿では立ち入らないが分解的手法と対極をなす RDB 設計の合成的手法の原典にあたりたい向きには文献[5]を，そしてそれらをカバーした書籍として拙著[6]を薦めます．

3. 関数従属性保存とは

 まず，リレーションスキーマの情報無損失分解に係る関数従属性保存の定義を与えます．
【定義7】(関数従属性保存)
 リレーションスキーマ R に所与の関数従属性の集合 F が指定されているとする．X→Y∈F⁺ として，X→Y による R の R[X∪Y] と R[Ω_R－Y]への情報無損失分解が関数従属性保存とは，次が成立するときをいう．
   (F⁺[X∪Y]∪F⁺[Ω_R－Y])⁺=F⁺

 つまり，F の閉包 F⁺ の X∪Y 上の射影 F⁺[X∪Y] とその Ω_R－Y 上の射影 F⁺[Ω_R－Y]の和集合の閉包 (F⁺[X∪Y]∪F⁺[Ω_R－Y])⁺ が F⁺ と等しいかどうかを問うていて，両者が等しいときに，関数従属性保存と言います．決して F[X∪Y]∪F[Ω_R－Y]=F を問うているわけではないことに注意してください．あくまで，閉包レベルの概念です．

 なお，一般にリレーションスキーマ R を X→Y でR[X∪Y]と R[Ω_R－Y]へ情報無損失分解したとき，もし R[Ω_R－Y]に Z→W∈F⁺（ここに，Z∪W⊂Ω_R－Y）が存在していると，R[Ω_R－Y]は R[Z∪W]と R[Ω_R－Y－W]へ情報無損失分解可能で，結果として R は R[X∪Y]と R[Z∪W]と R[Ω_R－Y－W]に情報無損失分解できます．このとき，上記の関数従属性保存の定義は素直に次のように拡張されます（この拡張はより一般的な形で可能です）．
   (F⁺[X∪Y]∪F⁺[Z∪W]∪F⁺[Ω_R－Y－W])⁺=F⁺

 以上で準備は整いました．ここからは 2NF ではあるが 3NF ではないリレーションスキーマの 3NF への情報無損失分解が関数従属性保存か否かを検証していきます．3 つのパターンが示されますが，それらの結果は大変興味深いものです．

4. 3NF 分解が関数従属性保存である例

【例題4】
 リレーションスキーマ R(A, B, C) に所与の FD 集合 F={A→B, B→C} が指定されているとする．このとき，R は 2NF ではあるが 3NF ではない．R の 3NF への情報無損失分解が関数従属性保存であるかどうかを検証してみよ．なお，図 1 に本例題での所与の FD 集合の様子を示す．
(解答)
 例題 2 で示したように，F⁺={A→A, A→B, A→C, B→B, B→C, C→C, AB→A, AB→B, AB→C, AC→A, AC→B, AC→C, BC→B, BC→C, ABC→A, ABC→B, ABC→C} である．
 まず，確認すれば R は 2NF ではあるが 3NF ではない．なぜならば，推移的関数従属性 A→B→C が存在するからである．そこで，A→B→C の解消を図るため，B→C を用いて，R を R[B, C]と R[A, B] に情報無損失分解する．このとき，F⁺[B, C]= {B→B, B→C, C→C, BC→B, BC→C}，F⁺[A, B]= {A→A, A→B, B→B, AB→A, AB→B}となる．
 さて，G=F⁺[B, C]∪F⁺[A, B]と置いて，F⁺と G の元を見比べてみると，F⁺ の元 A→C，AB→C，　AC→A，AC→B，AC→C，ABC→A，ABC→B，ABC→C が G に入っていない．そこで，これらの元で自明でないA→C，AB→C， AC→B について，それらが G⁺ の元であるかどうかを検証する．
 まず，A→C は，(A→B∈F⁺[A, B])∧(B→C∈F⁺[B, C])なので，アームストロングの公理系の推移律から A→C∈G⁺ であることが分かる（つまり，G ⊨ A→C である）．AB→C は，(AB→B∈F⁺[A, B])　∧(B→C∈F⁺[B, C])なので，アームストロングの公理系の推移律から AB→C∈G⁺ であることが分かる（G ⊨ AB→C）．AC→B については，A→B∈F⁺[A, B]なので，アームストロングの公理系の添加律から AC→BC で，BC→B∈F⁺[B, C] なので，アームストロングの公理系の推移律から AC→B∈G⁺ であることが分かる（G ⊨ AC→B）．したがって，G⁺=F⁺ となり，この情報無損失分解は関数従属性保存である．

 前述の平成 26 年度 春季 データベーススペシャリスト試験 午前Ⅱ 問題 問 4 が（ア）を正解としたのは，例題 4 のような状況を想定しての設問だったのかもしれませんが，そのような但し書きは一切ありません，しかしながら，3NF 分解と関数従属性保存の関係性は常にこのように単純というわけではなく，以下に見るように，その出題意図に反した例を多々示すことができます．

5. いかなる 3NF 分解も関数従属性保存でない例

【例題5】
 リレーションスキーマ R(A, B, C, D) に所与の FD 集合 F={A→B, B→C, A→D, D→C} が指定されているとする．このとき，R は 2NF ではあるが 3NF ではない．R の 3NF への情報無損失分解が関数従属性保存であるかどうかを検証してみよ．なお，図 2 に本例題での所与の FD 集合の様子を示す．
(解答)
 このとき，A⁺=ABCD, B⁺=BC, C⁺=C, D⁺=CD, AB⁺=AC⁺=AD⁺=ABCD, BC⁺=BC, BD⁺=BCD, CD⁺=CD, ABC⁺=ABD⁺=ACD⁺=ABCD, BCD⁺=BCD, ABCD⁺=ABCD なので，F⁺={A→A, A→B, A→C, A→D, B→B, B→C, C→C, D→C, D→D, AB→A, AB→B, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→A, AD→B, AD→C, AD→D, BC→B, BC→C, BD→B, BD→C, BD→D, CD→C, CD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D}となる．R の候補キーはAのみなので 2NF である．一方，R にはA→B→C，A→D→Cという 2 つの推移的関数従属性が存在し 3NF ではないので R を情報無損失分解する．

(場合1) A→B→C の解消を図る．
 R を A→B→C を構成する B→C を使って R[B, C] と R[A, B, D]に情報無損失分解すると，次が成立する．このときは R[A, B, D] も 3NF となっている．
 F⁺[B, C]= {B→B, B→C, C→C, BC→B, BC→C}
 F⁺[A, B, D]= {A→A, A→B, A→D, B→B, D→D, AB→A, AB→B, AB→D, AD→A, AD→B, AD→D, BD→B, BD→D, ABD→A, ABD→B, ABD→D}
 そこで，G=F⁺[B, C]∪F⁺[A, B, D] と置き，G⁺=F⁺ かどうかを検証する．F⁺ と G の元を見比べてみると， F⁺ の元 A→C, D→C, AB→C, AC→A, AC→B, AC→C, AC→D, AD→C, BD→C, CD→C, CD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→C, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D が G に入っていない．これらの中の自明でない FD である A→C, D→C, AB→C, AC→B, AC→D, AD→C, BD→C, ABC→D, ACD→B が G⁺ の元か否かを検証すると，D→C が G の下では導出されないことが分かる（￢(G ⊨ D→C)，ここに￢は否定を表す）．したがって，この情報無損失分解は関数従属性保存ではない．

(場合2) A→D→C の解消を図る．
 R を A→D→C を構成する D→C を使って R[D, C] と R[A, B, D] に情報無損失分解したときには，(場合1)と同様な展開で B→C が保存されず，この情報無損失分解も関数従属性保存ではないない．

 つまり，リレーションスキーマ R(A, B, C, D) に所与の FD 集合 F={A→B, B→C, A→D, D→C} が指定されているとき，R を 3NF に正規化しようとする何れの情報無損失分解も関数従属性保存ではないことが示されました．これが，前述の午前 Ⅱ 問題 問 4 とその正解を(ア)とする解答への端的な反証となります．

6. 3NF 分解が関数従属性保存となるか否かが，場合による 3 例

【例題6】
 リレーションスキーマ R(A, B, C, D)に所与の FD 集合 F={A→B, B→C, C→D} が指定されているとする．このとき，R は 2NF ではあるが 3NF ではない．R の 3NF への情報無損失分解が関数従属性保存であるかどうかを検証してみよ．なお，図 3 に本例題での所与の FD 集合の様子を示す．
(解答)
 このとき，F⁺={A→A, A→B, A→C, A→D, B→B, B→C, B→D, C→C, C→D, D→D, AB→A, AB→B, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→A, AD→B, AD→C, AD→D, BC→B, BC→C, BC→D, BD→B, BD→C, BD→D, CD→C, CD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D}
 R の候補キーは A のみなので 2NF である．一方，R には A→B→C，A→B→D，B→C→D，A→C→D という 4 つの推移的関数従属性が存在し 3NF ではないので R を情報無損失分解する．

(場合1) A→B→C の解消を図る．
 R を A→B→C を構成する B→C を使って R[B, C] と R[A, B, D] に情報無損失分解すると，A→B→D により，R[A, B, D] も 3NF ではないので，それを B→D を使って R[B, D] と R[A, B]に情報無損失分解すると次が成立する．
 F⁺[B, C]= {B→B, B→C, C→C, BC→B, BC→C}
 F⁺[B, D]= {B→B, B→D, D→D, BD→B, BD→D}
 F⁺[A, B]= {A→A, A→B, B→B, AB→A, AB→B}
 そこで，G=F⁺[B, C]∪F⁺[B, D]∪F⁺[A, B] と置き，G⁺=F⁺ かどうかを検証する．そのために，F⁺ の元であって G の元でない FD について，それが G⁺ の元であるか否かを検証する．そのような元は，
A→C, A→D, C→D, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→A,AD→B, AD→C, AD→D, BC→D, BD→C, CD→C, CD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→Dである．これらのうち，自明でない FD である A→C, A→D, AB→C, AB→C, AB→D, AC→B, AC→D, AD→B, AD→C, BC→D, BD→C, ABC→D, ABD→C, ACD→B, BCD→A について，それらが G⁺ の元か否かを検証すると，C→D が F⁺ の元ではないことが分かる（￢(G ⊨ C→D)）．したがって，この情報無損失分解は関数従属性保存ではない．

(場合2) A→B→D の解消を図る．
 R を A→B→D を構成する B→D を使って R[B, D] と R[A, B, C] に情報無損失分解すると，A→B→C により，R[A, B, C] も 3NF ではないので，それを B→C を使って R[B, C] と R[A, B] に情報無損失分解すると次が成立する．その結果，R は R[B, D] と R[B, C] と R[A, B] に情報無損失分解されるが，検証しないといけないことは (場合1)と同様となる．したがって，この情報無損失分解は関数従属性保存ではない．

(場合3) B→C→D の解消を図る．
 R を B→C→D を構成する C→D を使って R[C, D] と R[A, B, C] に情報無損失分解すると，A→B→C により，R[A, B, C] も 3NF ではないので，それを B→C を使って R[B, C] と R[A, B]に情報無損失分解すると次が成立する．
 F⁺[C, D]= {C→C, C→D, D→D, CD→C, CD→D}
 F⁺[B, C]= {B→B, B→C, C→C, BC→B, BC→C}
 F⁺[A, B]= {A→A, A→B, B→B, AB→A, AB→B}
 そこで，G=F⁺[C, D]∪F⁺[B, C]∪F⁺[A, B] と置き，G⁺=F⁺ かどうかを検証する．そのために，F⁺ の元であって G の元でない FD について，それが G⁺ の元であるか否かを検証する．そのような元は，
A→C, A→D, B→D, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→A, AD→B, AD→C, AD→D, BC→D, BD→B, BD→C, BD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D である．これらのうち，自明でない FD である A→C, A→D, B→D, AB→C, AB→D, AC→B, AC→D, AD→B, AD→C, BC→D, BD→C, ABC→D, ABD→C, ACD→B について，それらが G⁺ の元か否かを検証すると，すべてが G⁺ の元であることが分かる．したがって，この情報無損失分解は関数従属性保存である．

(場合4) A→C→D の解消を図る．
 R を A→C→D を構成する C→D を使って R[C, D] と R[A, B, C]に情報無損失分解する．このとき，行わなくてはならない検証は(場合3)と同じとなり，したがって，この情報無損失分解は関数従属性保存である．

 以上，例題 6 では，関数従属性保存か否かは情報無損失分解の仕方による，ということが示されました．

【例題7】
 リレーションスキーマ R(A, B, C, D) に所与の FD 集合 F={A→B, B→C, A→D, D→B} が指定されているとする．このとき，R は 2NF ではあるが 3NF ではない．R の 3NF への情報無損失分解が関数従属性保存であるかどうかを検証してみよ．なお，図 4 に本例題での所与の FD 集合の様子を示す．
(解答)
 このとき，A⁺=ABCD, B⁺=BC, C⁺=C, D⁺=BCD, AB⁺=AC⁺=AD⁺=ABCD, BC⁺=BC, BD⁺=BCD, CD⁺=BCD, ABC⁺=ABD⁺=ACD⁺=ABCD, BCD⁺=BCD, ABCD⁺=ABCD なので，F⁺ は次の通りとなる．
 F⁺={A→A, A→B, A→C, A→D, B→B, B→C, C→C, D→B, D→C, D→D, AB→A, AB→B, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→A, AD→B, AD→C, AD→D, BC→B, BC→C, BD→B, BD→C, BD→D, CD→B, CD→C, CD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D}
 R の候補キーは A のみで，2NF である．一方，R には A→B→C, A→D→B, D→B→C, A→D→C という 4 つの推移的関数従属性が存在し 3NF ではない．そこで，R を 3NF に情報無損失分解する．

(場合1) A→B→C の解消を図る．
 R を A→B→C を構成する B→C を使って R[B, C] と R[A, B, D] に情報無損失分解すると，A→D, D→B∈F⁺ なので，R[A, B, D] は 3NF ではなく，それを D→B で情報無損失分解して 3NF にするとき，次が成立する．
 F⁺[B, C]= {B→B, B→C, C→C, BC→B, BC→C}
 F⁺[A, D]= {A→A, A→D, D→D, AD→A, AD→D}
 F⁺[B, D]= {B→B, D→B, D→D, BD→B, BD→D}
 そこで，G=F⁺[B, C]∪F⁺[A, D]∪F⁺[B, D] と置き，G⁺=F⁺ かどうかを検証する．そのために，F⁺ の元であって G の元でない FD について，それが G⁺ の元であるか否かを検証する．そのような元は，
A→B, A→C, D→C, AB→A, AB→B, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→B, AD→C, BD→C, CD→B, CD→C, CD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D である．これらのうち，自明でない FD である A→B, A→C, D→C, AB→C, AB→D, AC→B, AC→D, AD→B, AD→C, BD→C, CD→B, ABC→D, ABD→C, ACD→B について，それらが G⁺ の元か否かを検証すると，すべてが G⁺ の元であることが分かる．したがって，この情報無損失分解は関数従属性保存である．

(場合2) A→D→B の解消を図る．
 R を A→D→B を構成する D→B を使って R[D, B] と R[A, C, D] に情報無損失分解すると，A→D, D→C∈F⁺ なので，R[A, C, D] は 3NF ではなく，それを D→C で情報無損失分解して 3NF にするとき，次が成立する．
 F⁺[D, B]= {B→B, D→B, D→D, BD→B, BD→D}
 F⁺[C, D]= {C→C, D→C, D→D, CD→C, CD→D}
 F⁺[A, D]= {A→A, A→D, D→D, AD→A, AD→D}
 そこで，G=F⁺[D, B]∪F⁺[C, D]∪F⁺[A, D] と置き，G⁺=F⁺ かどうかを検証する．そのために，F⁺ の元であって G の元でない FD について，それが G⁺ の元であるか否かを検証する．そのような元は，
A→B, A→C, B→C, AB→A, AB→B, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→B, AD→C, BC→B, BC→C, BD→C, CD→B, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D となる．これらのうち，自明でない FD である A→B, A→C, B→C, AB→C, AB→D, AC→B, AC→D, AD→B, AD→C, BD→C, CD→B, ABD→C, ACD→B について，G⁺ の元であるか否かを検証すると，B→C が G⁺ の元ではないことが分かる（￢(G ⊨ B→C)）．したがって，この情報無損失分解は関数従属性保存ではない．

(場合3) D→B→C の解消を図る．
 R を D→B→C を構成する B→C を使って情報無損失分解することとなるが，このとき，行わなくてはならない検証は(場合1)と同じとなり，したがって，この情報無損失分解は関数従属性保存である．

(場合4) A→D→C の解消を図る．
 R を A→D→C を構成する D→C を使って R[D, C] と R[A, B, D] に情報無損失分解すると，A→D, D→B∈F⁺ かつ ¬(D→A∈F⁺) なので，R[A, B, D]は 3NF ではなく，それを D→B で情報無損失分解して 3NF にするとき，次が成立する．
 F⁺[D, C]= {C→C, D→C, D→D, CD→C, CD→D}
 F⁺[D, B]= {B→B, D→B, D→D, BD→B, BD→D}
 F⁺[A, D]= {A→A, A→D, D→D, AD→A, AD→D}
 そこで，G=F⁺[D, C]∪F⁺[D, B]∪F⁺[A, D] と置き，G⁺=F⁺ かどうかを検証する．そのために，F⁺ の元であって G の元でない FD について，それが G⁺ の元であるか否かを検証する．そのような元は，
A→B, A→C, B→C, AB→A, AB→B, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→B, AD→C, BC→B, BC→C, BD→C, CD→B, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D となる．
 これらのうち，自明でない FD である A→B, A→C, B→C, AB→A, AB→B, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→B, AD→C, BC→B, BC→C, BD→C, CD→B, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D について，G⁺ の元であるか否かを検証すると，B→C が G⁺ の元ではないことが分かる（￢(G ⊨ B→C)）．したがって，この情報無損失分解は関数従属性保存ではない．

 以上，例題 7 では，関数従属性保存か否かは情報無損失分解の仕方による，ということが示されました．

【例題8】
 リレーションスキーマ R(A, B, C, D) に所与の FD 集合 F={A→B, B→C, B→D, D→C} が指定されているとする．このとき，R は 2NF ではあるが 3NF ではない．R の 3NF への情報無損失分解が関数従属性保存であるかどうかを検証してみよ．なお，図 5 に本例題での所与の FD 集合の様子を示す．
(解答)
 このとき，A⁺=ABCD, B⁺=BCD, C⁺=C, D⁺=CD, AB⁺=AC⁺=AD⁺=ABCD, BC⁺=BCD, BD⁺=BCD, CD⁺=CD, ABC⁺=ABD⁺=ACD⁺=ABCD, BCD⁺=BCD, ABCD⁺=ABCD なので，F⁺ は次の通りとなる．
 F⁺={A→A, A→B, A→C, A→D, B→B, B→C, B→D, C→C, D→C, D→D, AB→A, AB→B, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→A, AD→B, AD→C, AD→D, BC→B,BC→C, BC→D, BD→B, BD→C, BD→D, CD→C, CD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D}
 R の候補キーは A のみで，2NF である．一方，R には A→B→C，A→B→D, B→D→C，A→D→C という 4 つの推移的関数従属性が存在し 3NF ではない．そこで，R を情報無損失分解する．

(場合1) A→B→C の解消を図る．
 この場合，B→C を使って R を R[B, C] と R[A, B, D] に情報無損失分解する．R[A, B, D] では A→B→D が成立していて 3NF ではないので，B→D でそれを R[B, D] と R[A, B] に情報無損失分解する．このとき，次が成立する．
 F⁺[B, C]= {B→B, B→C, C→C, BC→B, BC→C }
 F⁺[B, D]= {B→B, B→D, D→D, BD→B, BD→D}
 F⁺[A, B]= {A→A, A→B, B→B, AB→A, AB→B}
 そこで，G=F⁺[B, C]∪F⁺[B, D]∪F⁺[A, B] と置いて，G⁺=F⁺ かどうかを検証する．そのために，F⁺ の元であって G の元でない FD について，それが G⁺ の元であるか否かを検証する．
 そのような元は，A→C, A→D, D→C, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→A, AD→B, AD→C, AD→D, BC→D, BD→C, CD→C, CD→D, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D となる．これらのうち，自明でない FD である A→C, A→D, D→C, AB→C, AB→D, AC→B, AC→D, AD→B, AD→C, BC→D, BD→C, ABC→D, ABD→C, ACD→B について，G⁺ の元であるか否かを検証すると，唯一，D→C が G の下では導出されない,つまり，D→C は G⁺ の元ではないことが分かる（￢(G ⊨ D→C)）．したがって，この情報無損失分解は関数従属性保存ではない．

(場合2) A→B→D の解消を図る．
 この場合，B→D を使って R を R[B, D] と R[A, B, C] に情報無損失分解する．R[A, B, C] は 3NF ではないので，B→C でそれを R[B, C] と R[A, B] に情報無損失分解する．このとき，行わなくてはならない検証は(場合1)と同じとなり，したがって，この情報無損失分解は関数従属性保存ではない．

(場合3) B→D→C の解消を図る．
 この場合，D→C を使って R を R[D, C] と R[A, B, D] に情報無損失分解する．R[A, B, D] は A→B→D の存在により 3NF ではないので，B→D でそれを R[B, D] と R[A, B] に情報無損失分解する．このとき，次が成立する．
 F⁺[C, D]= {C→C, D→C, D→D, CD→C, CD→D }
 F⁺[B, D]= {B→B, B→D, D→D, BD→B, BD→D}
 F⁺[A, B]= {A→A, A→B, B→B, AB→A, AB→B}

 そこで，G=F⁺[C, D]∪F⁺[B, D]∪F⁺[A, B] と置いて，G⁺=F⁺ かどうかを検証する．そのために，F⁺ の元であって G の元でない FD について，それが G⁺ の元であるか否かを検証する．そのような元は，
A→C, A→D, B→C, AB→C, AB→D, AC→A, AC→B, AC→C, AC→D, AD→A, AD→B, AD→C, AD→D, BC→B, BC→C, BC→D, BD→C, ABC→A, ABC→B, ABC→C, ABC→D, ABD→A, ABD→B, ABD→C, ABD→D, ACD→A, ACD→B, ACD→C, ACD→D, BCD→B, BCD→C, BCD→D, ABCD→A, ABCD→B, ABCD→C, ABCD→D となる．これらのうち，自明でない FD である A→C, A→D, B→C, AB→C, AB→D, AC→B, AC→D, AD→B, AD→C, BC→D, BD→C, ABC→D, ABD→C, ACD→B について，G⁺ の元であるか否かを検証すると，すべてが G の下で導出されることが分かる．したがって，この情報無損失分解は関数従属性保存である．

(場合4) A→D→C の解消を図る．
 この場合，D→C を使って R を R[D, C] と R[A, B, D] に情報無損失分解する．このとき，行わなくてはならない検証は(場合3)と同じとなり，したがって，この情報無損失分解は関数従属性保存である．
 以上，例題 8 でも，関数従属性保存か否かは情報無損失分解の仕方による，ということが示されました．

 以上，例題 4～8 を通して確認できたように，「情報無損失分解ができ，かつ，関数従属性保存が成り立つ変換が必ず存在するものは，第 2 正規形から第3正規形への変換である」（午前 Ⅱ 問題 問 4 の出題意図）とは言い切れないことが分かりました．関数従属性保存が成り立つか否かは場合によるということです．

7. おわりに

 筆者は，平成 26 年度 春季 データベーススペシャリスト試験 午前 Ⅱ 問題 問 4 とその正解を「出題ミス」として簡単に片付けてしまう気にはなれず，この問題をもう少し重く受け止めています．その理由は，なぜこのような認識がなされてしまったのだろうかと考えるとき，どうもその背景には RDB 設計の現場に，RDB 設計のための「分解的手法」と「合成的手法」について，特に，その差異について十分な理解がなされていないのではないかと思うからです．
 そもそも，分解的手法とはコッドのリレーショナルデータモデルとその正規化理論に基づく RDB の設計手法で，FD や多値従属性や結合従属性によるリレーションの情報無損失分解がすべてを取り仕切ります．その時，FD が保存されるか否かは，情報無損失分解とは独立した概念であり，本稿で示したように，FD が保存される場合もあれば，保存されない場合もあるわけです．
 一方，バーンシュタイン（P.A. Bernstein）により提案された RDB 設計の「合成的手法」[5] は，データベース化の対象となった実世界で成り立つ FD をリストアップし，それを所与の FD 集合と指定することで，それから「関数従属性保存・3NF・情報無損失分解」と三拍子そろった RDB を設計することができます．
 つまり，3NF のリレーションスキーマを設計するにあたり，分解的手法では情報無損失分解と関数従属性保存はセットではありませんが，合成的手法では情報無損失分解と関数従属性保存はセットです．ここで，セットという言葉は共に成り立つ，という意味で使っています．これはとても大きな違いなのですが，このことがひょっとして RDB 設計の現場で十分認識されないまま，いつしか分解的手法でも 3NF までならば「関数従属性保存・3NF・情報無損失分解」と三拍子そろった RDB を設計することができるやに誤認識されて今日に至っているのではないか，筆者はそれをとても危惧してこの記事を書いたということです．本稿をお読みいただいた方の中には RDB 設計の最前線に立たれている方も大勢いらっしゃるのではないかと思いますが，機会があれば現場の声を是非お聞かせ願いたく思います．

【文献】

[1]

[2]

[3]

[4]

[5]

[6]

 SQL でテーブルを定義するときに PRIMARY KEY や UNIQUE を指定すると思いますが，皆さんはリレーション（スキーマ）のキー（key）を一体どのようにして見つけていますか？
 そもそも，「キーとはタップルの一意識別能力を有する属性の極・小・組」であることは，リレーショナルデータモデルを学んだ人ならばデータベースのイロハといった事項でしょうが，具体的にリレーション（スキーマ）と所与の関数従属性の集合が指定されたときに，キーを求めなさいと言われると，結構難儀する場合もあるのではないか，と思います．
 本稿では，次に示す 3 つの問題について改めて論じてみます．

• 候補キーを 1 つ見つける．
• 候補キーをすべて見つける．
• 候補キーの数の上限は？

2. 基礎的事項

 リレーションスキーマ R とはリレーション名 R と属性のリスト A₁, A₂, _…, A_n からなり，R(A₁, A₂, _…, A_n)と表されます．Ω_R (= { A₁, A₂, _…, A_n })で R の全属性集合を表すことにします．R をリレーションスキーマとするとき，R に所与の（given）関数従属性の集合 F＝{f₁, f₂, _…, f_p}，ここに (∀_i= 1, 2, _…, p)(f_i=X_i→Y_i ∧ X_i, Y_i⊆Ω_R)，を指定できます．なお，一般に X, Y を集合とするとき，X⊆Y は X が Y の部分集合であることを，X⊂Y は X が Y の真部分集合（proper subset）であることを表します．

【定義 1】（候補キー）
 K⊆Ω_R がリレーションスキーマ R の候補キー（candidate key）と言われるのは，次が成立するときをいう．ここに，∀R∈R は「R の任意のインスタンス R に対して」を表す．

(∀R∈R)((∀t, t’∈R)(t[K]=t’[K] ⇒ t=t’) ∧

(∀H⊂K)(∃R∈R) ((∃t, t’∈R)(t[H]=t’[H] ∧ t≠t’)))

 リレーションは有限個のドメインの直積の有限部分集合と定義されているので ，いかなるリレーションにも候補キーがないということはなく，最も極端なケースはリレーションスキーマ R の全属性集合 Ω_R が候補キーとなることも皆さんにとっては常識でしょう．
 組織体管理者（enterprise administrator, すなわち組織のデータベース設計に責任を有する個人またはグループ）は，候補キーが一つしかなければそれを，複数ある場合にはデータベース構築の目的に合っていると考えられるものを一つを選んで主キー（primary key）とします．主キーとされなかった候補キーと主キーとの違いは，主キーにはキー制約（key constraint）が課せられることにあることもよくご存じのことでしょう．また，何らかの候補キーを含む属性集合をスーパーキー（super key）と言います．

【定義 2】（キー制約）
 K がリレーションスキーマ R の主キーであるならば，次が成立しなければならない．ここに，NULLは空（すなわち，値がないこと）を表す．

(∀R∈R) (∀t∈R)((∀A∈K)(t[A] IS NOT NULL))

 簡単な例を示すと，リレーションスキーマ 社員(社員番号，社員名，所属，給与，マイナンバー)では，社員番号 や マイナンバー は候補キーでしょうが，もし 社員番号 を主キーと選べば リレーション 社員 のいかなるタップルの社員番号がNULLとなってはいけないというデータベースの一貫性制約が「キー制約」です．このとき，勿論，マイナンバー にも社員を一意識別する力はあるものの，主キーと指定されなかったので，NULLであってもよいということです．主キーとそう指定されなかった候補キーとの違いはこの一点です．
 なお，主キーか否かを問わず，候補キーを構成している属性をキー属性と言い，キー属性でない属性を非キー属性と言います．候補キーと主キーを特段に区別する必要を感じないときには単にキーということも多く，また特段に混乱をきたさないと考えられる場合には本来リレーションスキーマと書くべきところをリレーションと書いているところもあるのであらかじめ断っておきます．

 さて，定義1で候補キーの定義を与えましたが，その定義を関数従属性（functional dependency, FD）を使って表現し直すことができます．多少くどいかもしれませんが，その定義を記しておきます．

【定義 3】（関数従属性，FD）
 X，Y をリレーションスキーマ R の属性集合 Ω_R の部分集合とするとき，X から Y への FD がある，このことを X→Y と書く，とは次が成立するときをいう．ここに，iff は if and only if（必要かつ十分）を，⇒ は論理的含意を表し，X→Y の X を決定子（determinant），Y を被決定子（resultant）という．

X→Y iff (∀R∈R)(∀t, t’∈R)( t[X]=t’[X] ⇒ t[Y]=t’[Y])

 また，FD については，Armstrong の公理系が成立することも皆さん，よくご存じのことと思います．

【公理 1】（Armstrong の公理系）
 A1. Y⊆X ならば，X→Y である（反射律）．
 A2. X→Y かつ Z⊆W ならば，X∪W→Y∪Z である（添加律）．
 A3. X→Y かつ Y→Z ならば，X→Z である（推移律）．

 さて，定義 1 で候補キーの定義を与えましたが，FD を使ってこの定義を表現し直してみると，次のようになります．

【定義 4】（FD を用いた候補キーの定義）
 K⊆Ω_R がリレーションスキーマ R の候補キーと言われるのは，次が成立するときをいう．ここに，↛ は FD が成立しないことを表す．

(K→Ω_R) ∧ (∀H⊂K)(H↛Ω_R)

 さらに，この定義はリレーションスキーマ R に所与の関数従属性の集合 F が指定されたとき，属性集合 X の閉包（closure），これを X⁺ と記す，を用いて以下のように書き直せます．

 まず，リレーションスキーマ R に所与の関数従属性の集合 F が指定されたとき，R の属性集合 X の閉包の求め方を示しておきます．このアルゴリズムの時間計算量（time complexity）はO(n×p)，ここにn=|Ω_R|，p=|F|，と多項式オーダーであり扱いやすい問題（tractable problem）です．したがって X⁺ は問題なく求められます．

 【X⁺ を求めるアルゴリズム】

ステップ 1　X⁽⁰⁾=X とおく．

ステップ 2　X⁽ⁱ⁾=X^(i-1)∪{Z | Y→Z∈F ∧ Y⊆X^(i-1) } (i≧1)

ステップ 3　もし X⁽ⁱ⁾=X^(i-1) なら X^＋=X^(i-1) とおく．そうでなければステップ 2 に行く．

 ここで，関数従属性と閉包の関係性について記します．

【命題 1】
 リレーションスキーマ R に所与の関数従属性の集合 F が指定されているとする．X, Y⊆Ω_R とするとき，次が成立する．

X→Y iff Y⊆X⁺

（証明）
 X⁺ を求めるアルゴリズムでは，一般に X⁽ⁱ⁾=X^(i-1)∪{Z | Y→Z∈F ∧ Y⊆X^(i-1)} であるので，X⁽⁰⁾={X}としたとき X→Y∈F ならば Y はX⁽¹⁾の元となり，結果的にY⊆X⁺である．逆に，Y⊆X⁺ならば，X⁺の元は X に関数従属した属性からなるので，X→X⁺である．Y⊆X⁺なので反射律から X⁺→Y が成立する．従って，推移律から X→Y である．

 そうすると，定義 4で与えた FD を用いた候補キーの定義は閉包の概念を用いて定義 5 のように書き直せます．これは，命題 1 より，K→Ω_R iff K⁺=Ω_R が成立することから明らかでしょう．

【定義 5】（閉包の概念を用いた候補キーの定義）
 リレーションスキーマ R に所与の関数従属性の集合 F が指定されているとする．K⊆Ω_R が R の候補キーと言われるのは，次が成立するときをいう．

(K⁺=Ω_R) ∧ (∀H⊂K)(H⁺≠Ω_R)

 ここまで準備完了です．では，続けて，リレーションスキーマの候補キーを求める問題を考えてみましょう．2 つの立場から考察していきます．

3. 候補キーを 1 つ見つける

【問題 1】（候補キーを 1 つ見つける）
 リレーションスキーマ R に所与の関数従属性の集合 F＝{f₁, f₂, _…, f_p}が指定されているとき，R の候補キーを（何でもよいので）1 つ求めなさい．
（解答）
 リレーションスキーマ R の全属性集合 Ω_R は R のスーパーキーであることに着眼する．すると，次に示すアルゴリズムで候補キーが 1 つ見つかる．

 【候補キーを 1 つ見つけるアルゴリズム】

 このアルゴリズムの正当性は明らかでしょう．注意するべき点は，どのような候補キーが返されるかはステップ 2 で取り除かれた属性 A の選択のされ方によることです．このような曖昧性はありますが，必ず候補キーは 1 つ返ってきます．このアルゴリズムの時間計算量は閉包を計算するアルゴリズムの時間計算量に依存し，それは多項式オーダーとなり扱いやすい問題です．

4. 候補キーをすべて見つける

【問題 2】（候補キーをすべて見つける）
 リレーションスキーマ R に所与の関数従属性の集合 F＝{f₁, f₂, _…, f_p}が指定されているとき，R の候補キーをすべて求めなさい．

（解答）
 R の候補キーをすべて求めるアルゴリズムを以下に示します．

【候補キーをすべて見つけるアルゴリズム】

 このアルゴリズムは Ω_R のすべての部分集合（空集合を除く）について，その濃度の小さい方から大きい方の順，すなわちS₁，S₂，…, S_|ΩR| の順に，S_i の各元が候補キーとなっているか否かを総当たりで検証していくこと（S_iの任意の 2元 X_i,j と X_i,k が包含関係になることはないのでどちらかが他方のスーパーキーになることはないことに注目すること），そして S_kを再編成することでスーパーキーを除外していることから，その正当性は明らかでしょう．しかし，それが故に，その時間計算量は指数オーダーとなり，扱いにくい問題（intractable problem）となります．

 さて，復習がてらに上述のアルゴリズムを使って，候補キーをすべて求める問題と解を 2 つ例示しましょう．

【例題 1】（データベーススペシャリスト平成29年春期 午前Ⅱ 問4）
関係 R(A，B，C，D，E)において，
 関数従属 {A，B}→C，{B，C}→D，D→{A，E}
が成立する．これらから決定できるRの候補キーを全て挙げたものはどれか．
 {A，B，C}
 {A，B}，{B，C}
 {A，B}，{B，C}，{B，D}
 {B，C}，{C，D}

（解答）
 {A，B}，{B，C}，{B，D} が正解である．
 これを本稿に示した「候補キーをすべて見つけるアルゴリズム」に則り示すと次の通りである．なお，見やすさのために，{A，B} を AB，{A，B}→C を AB→C という具合に表現し直している．
 まず，ステップ 1 の処理をする．
 Ω_R={ A，B，C，D，E }なので，|Ω_R|=5，Ω_R の冪べき集合 2^Ω_R の元を構成要素数で類別して，S_i，i=0～5を作ると， S₀=Φ（空集合），S₁={A，B，C，D，E}，S₂={AB, AC, AD, AE, BC, BD, BE, CD, CE, DE, ABC}，S₃={ABD, ABE, ACD, ACE, ADE, BCD, BCE, BDE, CDE}，S₄={ABCD, ABCE, ABDE, ACDE, BCDE}，S₅={ABCDE}となる．すなわち，2^Ω_R = S₀∪S₁∪S₂∪S₃∪S₄∪S₅である．
 続いて，ステップ 2 の処理をする．
 まず，S₁ に対してステップ 2 の処理をすると，結果は次のとおりである．
 A⁺=A，B⁺=B，C⁺=C，D⁺=ADE，E⁺=E．つまり，候補キーはない．
 続いて，S₂ に対しての処理結果は次のとおりである．
 AB⁺=ABCDE, AC⁺=AC, AD+=ADE, AE⁺=AE, BC⁺=ABCDE, BD⁺=ABCDE, BE⁺=BE, CD⁺=ACDE, CE⁺=CE, DE⁺=ADE．つまり，AB，BC，BD が候補キーであることが分かった．そこで，S₃～S₅ の再編作業を行う．まず，S₃ については，AB，BC，BD を含む要素を S₃から除外して改めて S₃ を作成すると次のとおりである．S₃={ACD, ACE, ADE, CDE}．S₄ と S₅ に対しても同様な操作を行い，S₄={ACDE}, S₅=Φ となる．
 続いて，再編成された S₃ に対してステップ 2 の処理をすると次のとおりである．
 ACD⁺=ACDE, ACE⁺=ACE, ADE⁺=ADE, CDE⁺=ACDE．つまり，候補キーはない．
 続いて，S₄ の処理を行うと，ACDE⁺=ACDE であり，候補キーはない．
 S₅=Φ なので候補キーはない．
 よって，AB，BC，BD が R の候補キーの全てであることが分かる．

【例題 2】（2 の冪べき乗個の候補キーが見つかる例）
 リレーションスキーマ R(A₁, A₂, B₁, B₂)に所与の関数従属性 A_i→B_i，B_i→A_i (i=1, 2)が指定されているとする．R の候補キーをすべて求めなさい．

（解答）
 Ω_R={A₁, A₂, B₁, B₂}とすると，S₀=Φ，S₁={A₁, A₂, B₁, B₂}，S₂={ A₁A₂, A₁B₁, A₁B₂, A₂B₁, A₂B₂, B₁B₂}，S₃={A₁A₂B₁, A₁A₂B₂, A₁B₁B₂, A₂B₁B₂}，S₄={ A₁A₂B₁B₂}となる．
 そこで，S₁ の各元に対してその閉包を計算する．A_i⁺=A_iB_i (i=1,2)，B_i⁺=A_iB_i (i=1,2)であり，候補キーではない．そこで，S₂ の各元に対してその閉包を計算する．A₁A₂⁺=A₁A₂B₁B₂, A₁B₁⁺=A₁B₁, A₁B₂⁺=A₁A₂B₁B₂, A₂B₁⁺=A₁A₂B₁B₂, A₂B₂⁺=A₂B₂, B₁B₂⁺=A₁A₂B₁B₂となる．従って，A₁A₂, A₁B₂, A₂B₁, B₁B₂ が候補キーであることが分かる．S₃ の再編作業を行うと S₃ は Φ となるので，ここで処理が終了する．

 例題 2 を一般化してすべての候補キーを求める問題の時間計算量について補足説明を行います．リレーションスキーマ R(A₁, A₂, ···, A_n, B₁, B₂, ・・・, B_n)に所与の関数従属性集合 F = {A_i→B_i, B_i→A_i|i∈{1, 2, _…, n}}が指定された場合，R は，A₁A₂・・・A_n, B₁A₂・・・A_n, A₁B₂A₃・・・A_n, ・・・, B₁B₂・・・B_nと 2ⁿ個の候補キーを有することになるので，n が大きくなると実用的でなくなります．つまり，例題 2 では n=2 なので候補キーの数は 2²=4 で済みましたが，このようなタイプの関数従属性集合 F を指定されたリレーションスキーマ R の候補キーの数は 2ⁿなので，n が大きくなるにつれて，それ数え上げるには指数時間かかり，一般にすべての候補キーを求める問題は扱いにくい問題であることが直感できると思います．

5. 候補キーの数の上限は？

 1 つのリレーションスキーマには幾つ候補キーが存在しうるのか，その上限について次の結果[2, 3]が示されているので，紹介しておきたいと思います．

【命題 2】（候補キーの数の上限）
 リレーションスキーマ R の候補キーの数は高々 _nC_⌊n/2⌋である．ここに，C は組合せ，⌊r⌋ は r を越えない最大の自然数を表し，|Ω_R|=n とする．
（証明）
 濃度 n の集合 S において，候補キーの集合はお互いが集合の包含関係にないという意味でスパナー族（Sperner family）をなし，従って，比較不可能な S の部分集合の数は高々 _nC_⌊n/2⌋ となる．

 例えば，n=2 なら _nC_⌊n/2⌋=2 であるので，候補キーの数は高々 2 です．R(A, B)とすれば，もし上限の 2 個の候補キーがあった場合には，それらは {A} と {B} です．n=3 なら _nC_⌊n/2⌋=3 であるので，R(A, B, C)とすれば，もし上限の 3 個の候補キーがあった場合には，それらは {A, B}，{A, C}，{B, C} です．n=4 なら _nC_⌊n/2⌋=6 であるので，R(A, B, C, D)とすれば，もし上限の 6 個の候補キーがあったとすれば，それらは {A, B}，{A, C}，{A, D}，{B, C}，{B, D}，{C, D}です．R(A, B, C, D, E)とすれば，n=5 で ₅C_⌊5/2⌋=10 であるので，もし上限の 10 個の候補キーがあったとすれば，それらは {A, B}，{A, C}，{A, D}，{A, E}, {B, C}，{B, D}，{B, E}, {C, D}, {C, E}, {D, E} です．例題 2 の候補キーの数は 4 でしたが，2²＜₄C₂=6 とこの結果に符合しています．

6. おわりに

 リレーションの候補キーを求める問題を論じました．リレーションスキーマに所与の関数従属性集合が指定されたとき，候補キーを 1 つ見つけるためのアルゴリズムと，候補キーをすべて見つけるアルゴリズムを提示しました．上に見たように，同じく候補キーを求める問題ではあるのですが，「候補キーを 1 つ見つける問題」の時間計算量は多項式オーダーなので扱いやすい問題ですが，「候補キーをすべて見つける問題」の時間計算量は指数オーダーとなり扱いにくい問題であることを示しました．つまり，すべての候補キーを求めようとすると，リレーションスキーマの全属性数が小さいときには問題となりませんが，それが大きくなるととてつもない時間を要することとなり，現実的ではなくなるということです．とりあえず，候補キーが「1 つ」見つかればよいというなら話は簡単そうですが，「すべて」と言われると気長に根気よく見つけていくしか術すべはなさそうですね．

【文献】

[1]

[2]

[3]

データベース設計に関心のある方なら，6NF って用語，どこかで目にしたり耳にしたりしたことありませんか？リレーションの第 6 正規形（sixth normal form）のことです．一体何なんでしょうか？
　これまでリレーショナルデータベースの正規化理論では，リレーションを幾つかの射影に分解して，得られた結果を自然結合演算で再合成して元に戻ることができる（情報無損失分解）か否かで正規化の体系を創り上げてきました．関数従属性（FD）や多値従属性（MVD）は 2 分解，つまり 1 枚のリレーションを 2 つの射影に分解する考え方でリレーションの情報無損失分解を規定します．FDにより第 2 正規形，第 3 正規形，Boyce-Codd 正規形（BCNF）が規定されました．FD を概念拡張した MVD により第 4 正規形（4NF）が規定されました．FD や MVD はリレーションを 2 分解しますが，MVD をさらに概念拡張して結合従属性（JD）が導入されると，JD は一般にリレーションが n（n≧2）個の射影に情報無損失分解されるための必要かつ十分条件となり，第 5 正規形（5NF）が明らかとなりました．JD は n を 2 に限定しないので，与えられたリレーションを幾つかの射影に情報無損失分解して更新時異状を解消しようというリレーションの正規化理論の枠組みは，JD が規定する 5NF で打ち止めとなり，6NF という正規形は「ない」と理解されています．これは皆さんも納得済みのことでしょう．
　ところが，第 6 正規形（6NF）という言葉が聞こえてくるわけです．一体何なんでしょうか？これは C. J. Date が言い出した正規形で，彼は 5NF が従来の枠組みでは最も高い正規度であると認識しているといいながらも，6NF を主張しているのです．まず，彼の与えた 6NF の定義を見てみましょう[1]．
【定義1】（Sixth normal form for regular data by C.J. Date）
Relvar R is in sixth normal form (6NF) if and only if the only JDs that hold in R are trivial ones.¹
　では，これは何を意味しているのでしょうか？そのためには，少し寄り道をする必要があります．次に，彼の与えた JD の定義を確認します．

¹ “regular data” は temporal data と区別しての言い方で，”relvar”はリレーションと読み替えてよい． Trivial については脚注4 の意味に同じ．

【定義2】（結合従属性（JD）by Date）
Let X₁, …, X_n be subsets of the heading H of relvar R²; then the join dependency (JD) { X₁ , … , X_n } holds in R if and only if R can be nonloss decomposed into its projections on X₁, … , X_n.
　この定義は，表現こそ異なりますが，次に示す従来知られている結合従属性（JD）の定義と同じです³．

² the heading H of relvar R とは，従来の言葉で表せば H がリレーション R の全属性集合という意味です．従来，結合従属性は*{}と書いてきましたが， Date は*の対象がリレーションではなく属性集合なので，それはおかしいと異議を唱え，*を使わず（星印）を使うとしています．表現の違いだけで中身は同じです．ここでは特別に留意しない限り，*を使います．
³ 従来の定義や関連する事項は拙著[2]を参照して下さい．

【定義3】（JD）
R(A, B, …, C)をリレーションスキーマ，ここに H={A, B, …, C}，とするとき，R の任意のインスタンス R がその n 個の射影 R[X₁]，R[X₂]，… ，R[X_n]に情報無損失分解される，つまり R=R[X₁]*R[X₂]* … *R[X_n]が成立するとき，R に JD *(X₁, X₂… , X_n)が存在するという．
　そして，このとき，JD を使って 5NF は次のように定義されます．
【定義4】（5NF）
リレーション R が 5NF であるとは，*(X₁, X₂, … , X_n)を R の JD とするとき，次のいずれかが成立するときをいう．
　(1) *(X₁, X₂, …, X_n)は自明な結合従属性である⁴．
　(2) 各 X_i は R のスーパキーである．
　一方，Date が与えた 5NF の定義は次の通りです．

⁴ JD *(X₁, X₂, … , X_n が trivial （自明）とは X₁, X₂, …, X_n のうちの一つが R の全属性集合に等しいときをいいます．

【定義5】（5NF by Date）
Relvar R is in fifth normal form (5NF) if and only if every JD of R is implied by the keys of R.
　さて，定義4 と定義5 を見比べてみると，微妙な差に気づきますね．即ち，Date の 5NF の定義は従来の 5NF の定義の（2）項の条件を満たしているときと定義しているというわけです．
　では，従来の 5NF の定義の（1）項に相当する場合の 5NF リレーションは，Date では一体どこでどのように定義されているのでしょうか？定義1 を見直してください．それはまさしく従来の 5NF の定義の（1）項のことです．つまり，Date の定義した 6NF は従来の 5NF の定義の（1）項の条件が成立するときの 5NF を言っているということになります．
　では，なぜそれを特に 6NF ということにしたのでしょうか？Date の真意は測りかねますが，できるだけ彼の立場に立って考えてみましょう．そこで，Date の著書[1]に記載されている例を引用して，そこで定義されているリレーションの正規度を考察してみます．3 つのリレーション S，P，SP があるとします．ここに，S は suppliers，P は parts，そして SP は shipments を表すリレーションで，SNO は supplier number，PNO は part number，STATUS は status value，CITY は location，QTY は quantity などを表します．アンダーラインが引かれている属性が主キーです．また，S には関数従属性 CITY→STATUS があるとします．
　S(SNO, SNAME, STATUS, CITY)
　P(PNO, PNAME, COLOR, WEIGHT, CITY)
　SP(SNO, PNO, QTY)
そうすると，S は第 3 正規形にもなっていなく，P は 5NF であるが 6NF ではなく，SP は 6NF となります．なぜでしょうか？
　まず，S が第 3 正規形にもなっていないことは遷移的関数従属性 SNO→CITY→STATUS の存在で明らかでしょう．P には *({ PNO, PNAME }, { PNO, COLOR, WEIGHT, CITY }), *({PNO, COLOR}, {PNO, PNAME, WEIGHT, CITY }), *({PNO, PNAME, COLOR}, {PNO, EIGHT, CITY }), … , *({PNO, PNAME}, {PNO, COLOR}, {PNO, WEIGHT}, {PNO, CITY}) など多数の JD があることが分かりますが，これらすべての JD は P の自明でない情報無損失分解を誘引し定義4（5NF）の（2）項の条件を満たすので 5NF であり，かつこれらの JD は自明ではないので 6NF ではないことが分かります．一方，SP では { SNO, PNO}→QTY なので，この FD を用いて SP を情報無損失分解しても SP そのものにしかならず，これを JD で表せば *({SNO, PNO, QTY})となり，定義4（5NF）の（1）項の条件を満たす，つまり定義1 を満たすので，従って 6NF ということになります．
　そこで，6NF の意味ですが，5NF である P を JD *({PNO, PNAME}, {PNO, COLOR}, {PNO, WEIGHT}, {PNO, CITY}) を使って情報無損失分解すると，P[PNO, PNAME], P[PNO, COLOR], P[PNO, WEIGHT], P[PNO, CITY] とそれぞれが 6NF のリレーションに情報無損失分解できることになります．言い換えると，P の場合，P 自体では parts の PNAME, COLOR, WEIGHT, CITY という 4 つの属性を合わせて一つの意味を持つリレーションとして設計されたのですが，それを 5NF ではあるが 6NF ではないという理由で 4 つに情報無損失分解すると，例えば P[PNO, PNAME] という成分は parts の NAME のみを属性として持つリレーションということになります．
　つまり，Date の主張したいことは，データベースを設計するにあたり，リレーション P を例にとれば，P のままでは「この part の名前は P₁で，色は L₁で，重さは W₁で，その part の保管場所は C₁ である」という 4 つの事象を一括して格納するリレーションを定義したことになりますが，それは望ましくなく，5NF ではあっても 6NF でなければ，「この part の名前は P₁ である」，「この part の色は L₁ である」，「この part の重さは W₁ である」，「この part の保管場所は C₁ である」という具合に，4 つの事象を個別に格納する 4 つのリレーションを定義するべきだと Date は主張したかったということになります．
　みなさん，いかがでしょう？ここまで細分化したリレーショナルデータベース設計をやりますか？やるとしたら，どのような時？もしあったら是非教えてください．
　結びですが，6NF ってなんだか tricky だな，と筆者は感じています．なぜならば，Date は従来の 5NF の定義を「定義4（5NF）」ではなく「定義5（5NF by Date）」で与えることによって，その間隙を埋めるべく 6NF を持ち出しているからです．確かに，5NF を定義5 のように定義する文献も見受けられますが，FD が自明であることや MVD が自明であることは，リレーションがそれぞれ BCNF や 4NF であるための条件となっています．したがって，5NF の定義は定義4（5NF）でよいのではないかと思うわけです．そうすれば，6NF を言い出す隙はありません．そのようなわけで，6NF に直面したら（ギョッとするのではなく）あくまで 5NF の一つという認識で臨むのが正解かなと考える次第です．

【文献】
[1] C.J. Date. Database Design and Relational Theory. O’Reilly Media, Inc., 2012.
[2] 増永良文．リレーショナルデータベース入門[第3版]，サイエンス社，2017．