1. はじめに
ビュー（view）はリレーショナルデータベースの始祖コッド（E.F. Codd）がリレーショナルデータモデル[1]を世に問うてから 4 年後の 1974 年に彼自身により導入されました[2]．ビューは定義だけが存在し実体は伴わない仮想的なリレーションであるところがデータベースに格納されているリレーション，これを実リレーション（stored relation）という，と根本的に異なるところです．
増永教授のDB特論
増永教授のDB特論⑪「結果整合性」
1. はじめに
ビッグデータの管理・運用で注目を浴びることとなった結果整合性（eventual consistency）ですが，賛否両論あるようです．否定的な意見は，たとえば，クレップマン（Martin Kleppmann）[1]の
著作に見ることができます．この著作，結構多くの方々がお持ちかと思いますが，クレップマンは複
製を行うデータベースのほとんどは，少なくとも結果整合性を提供しているとしながらも，これは非
常に弱い保障であり，複製がいつ（最終値に）収束するのかについては何も語られていなく，収束す
るときまで，読取りの結果が何になるのか，あるいはそもそも何も返さないのかは分からない，とク
レームしています．さらに，CAP 定理の対象範囲は非常に狭く，考慮しているのは 1 つの一貫性モ
デルと 1 種類のフォールト（つまり，ネットワーク分断）だけで，ネットワークの遅延，落ちている
ノード，あるいは他のトレードオフについては何も語っていない．したがって，CAP 定理は歴史的
には大きな影響力があったものの，システムの設計における実際的な価値はほとんどない，と述べて
います（文献[1]の 9 章「一貫性と合意」）．
増永教授のDB特論⑩「GEQO」
1. はじめに
リレーショナル DBMS において質問処理の最適化はリレーショナル DBMS の開発が始まって以来，設計者が最も腐心するところでした．その嚆矢は 1970 年代に IBM San Jose 研究所で開発された System R で提案・実装されたコストベース（cost based approach）の最適化手法です[1]．System
R は PostgreSQL の前身である INGRES と共にリレーショナル DBMS のプロトタイプとして名高い
システムですが，そこで開発されたこの手法は現在もプロプライエタリや PostgreSQL を含む OSS
のリレーショナル DBMS の質問処理最適化技法の基本となっています．
増永教授のDB特論⑨「NULL」
1. はじめに
Null という語，データベースに携わっている人なら見たことないという人はいないと思いますが，なんと発音していますか？
「ヌル」って言うのだよ，と誰が教えたのでしょうか？結構，皆さん，ヌル，ヌル，って言っています．違うんですねー．「ナル」って発音するのです．英語の発音記号は nʌ’l です．英語の発音を日本語で書き表すのは難しいですが，決してヌルではありません．英語を母国語とする人にヌルと言ったら，多分首を傾げると思いますよ．ナルって言いましょう．
さて，ナル（null）は「値がない」（having no value）という意味ですね．これに異議ありという方は多分いないと思います．では，リレーショナルデータベースでナルはどのような時にどのように使われているのでしょうか？なんで今さらそんなことを聞いているの？といぶかしげな読者の顔が浮かびますが，ナルに関しては蘊蓄を傾ければきりがなく，理論面でも実践面でも不明確なところが多々あり，議論しだしたらきりがないのかなといった感じです．しばしナル談議に耽ってみたいと思います．
増永教授のDB特論⑧「MVCC」
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と は何かを改めて議論しておきたいと考えます．
増永教授のDB特論⑦
「 SQL とバッグ意味論 ―重複タップルの部分削除―」
1. はじめに
リレーショナルデータモデルの始祖コッド（E.F. Codd）はリレーション（relation）とは集合（set）であると定義しました．ここに，集合とは数学における「集合」を意味し，集合論の始祖カントール（G. Cantor）は「集合とは異なる元（element）の集まり」と定義しました．したがって，リレーションに重複したタップル（tuple）は出現しません．また，それが故にリレーションには必ず「キー」が定義できます．
一方，国際標準リレーショナルデータベース言語 SQL (以下，SQL) で定義されるテーブル (table，表) は集合ではありません．テーブルでは重複したタップルの出現が許されるからです．したがって，テーブルでは必ずしもキーを定義できるわけではありません．
テーブルは一般的にはバッグ（bag），数学ではマルチ集合（multiset）と呼ばれます．リレーションとテーブルの違いは，フォーマルには，リレーショナルデータモデルは集合意味論 (set semantics) に則り，SQL はバッグ意味論（bag semantics）に則った体系であると説明できます．意味論が違うので，当然のことながらリレーショナルデータモデルと実践のためのSQLではいろいろと違いが出てきます．本稿では，リレーションに対するデータ操作では起こり得ませんが，テーブルのデータ操作で発生する「重複タップルの部分削除」（partial delete of duplicate tuples）に焦点を当てて，少しく蘊蓄を傾けてみたいと思います．
続きを読む
増永教授のDB特論⑥
「RDB 設計のための分解的 vs. 合成的アプローチ」
増永教授のDB特論⑤「3NF 分解と関数従属性保存」
1. はじめに
リレーショナルデータベース（RDB）を設計するにあたり，「リレーションは第 3 正規形（3NF）にしましょう」とはよく言われることです．リレーションの正規化理論によると，3NF への分解が情報無損失であることは間違いのないことですが，その際，関数従属性は保存されるのか，されないのか？このことについて，どうも不確かな認識が流布しているのではないか？と思われる事例に遭遇したので，この記事を書く気になりました．
増永教授のDB特論④「候補キーの見つけ方」
1. はじめに
SQL でテーブルを定義するときに PRIMARY KEY や UNIQUE を指定すると思いますが，皆さんはリレーション（スキーマ）のキー（key）を一体どのようにして見つけていますか？
そもそも，「キーとはタップルの一意識別能力を有する属性の極小組」であることは，リレーショナルデータモデルを学んだ人ならばデータベースのイロハといった事項でしょうが，具体的にリレーション（スキーマ）と所与の関数従属性の集合が指定されたときに，キーを求めなさいと言われると，結構難儀する場合もあるのではないか，と思います．
本稿では，次に示す 3 つの問題について改めて論じてみます．
- 候補キーを 1 つ見つける．
- 候補キーをすべて見つける．
- 候補キーの数の上限は？
増永教授のDB特論③「SQL のビッグデータ対応」
12