ホームリレーショナル・データベースの世界

 この文章は、クリス・デイトの "The Birth of the Relational Model - Thirty Years of Relational (2)" の要約です。引き続きコッドの69年の論文の内容を追います。それでは第2章からです。

第2章 いくつかの言語的側面



 この章は、次の非常に重要な言明で始まります。

  •  データを関係としてみることによって、二階述語論理を基礎とする一般的なデータ問い合わせ用準言語を作ることが可能になる。

 「二階(second-ordered)」という言葉を頭の片隅に残しておいてください。というのも、70年の論文ではこの箇所がさり気無く「一階(first-ordered)」に置き換わるからです。この変化が意味するのは、コッドは69年の時点では、関係を要素に含む定義域を持つ関係(入れ子構造の「関係の関係」)を作ろうと考えていたが、70年には思い直して一階に留めた、ということだからです(二階述語論理の関係モデルについては「なぜ関係モデルという名前なの?」も参照)。
 続けてデイトは言います。「コッドの決定的に重要な洞察は、データを関係の集合として見ること、さらに関係を(真な)命題の集合として見なせば、述語論理に基づく言語を作ることで、それをデータアクセスの用途に直接適用できるだろう、ということであった。」 データを関係の集合とみなす、という前半部分は、すぐイメージできると思います。実装レベルで言えば、「データを格納するための表が複数ある」ということです。リレーショナル・データベースにおいてデータを扱おうと思ったら、兎にも角にもデータを表に格納しなければ始まらないのですから、これは当然です。しかし、「関係を命題の集合とみなす」という後半部分は、少し説明しましょう。例として、以下の関係Trickを見てください。

Trick
名前 職業 身体的特徴
山田奈緒子 手品師 貧乳
上田次郎 大学教授 巨○
矢部謙三 刑事 ヅラ
山田里見 書家 貧乳

 一つのタプルが、一つの事実を表す命題になっています[1]。ゆえに、3項命題関数をT(x,y,z)とすると、関係Trickはこう書き換えられます。

  T(山田奈緒子, 手品師,   貧乳)
  T(上田次郎,   大学教授, 巨○)
  T(矢部謙三,   刑事,     ヅラ)
  T(山田里見,   書家,     貧乳)

 こう書いてしまえば一目瞭然、まさに関係は命題の集合です。述語論理は命題の分析と操作に使う道具なのだから、命題の集合と見なせば、関係にもそのまま適用できるだろう、というのがコッドの洞察だったわけです。

 本章では、この問い合わせ言語(まだSQLという名前はない)を細部まで論じているわけではありませんが、その代表的な特徴が素描されます。デイトは以下の三つにまとめています。
  1. 集合レベルの操作が可能である。
  2. 更新より問い合わせを重視している。
  3. 計算完備である必要はない「データ準言語(data sublanguage)」である。従って必要な関数が不足する場合は、ホスト言語に埋め込んで使う必要がある。

 まず1番の「集合レベルの操作」について。集合と関係は同じものですから、これは「関係レベルの操作(複数行を一単位とする操作)が可能である」ということです。実際、SQLに実装されている全ての関係代数は、集合(関係)レベルの操作が可能です。これは、複数行を一度に扱うことのできないCOBOL、C言語、JAVAといった言語との大きな違いです。こうした言語との橋渡しのために、カーソルという道具が用意されているわけです。
 2番の「更新より問い合わせを重視している」というのは、そのままです。コッドも一応、UPDATE、INSERT、DELETEなどのDMLについて触れてはいるのですが、SELECTに比べればその扱いは非常に軽いものです。ただ、特筆すべき点として、コッドは69年の時点で既に参照制約による自動削除(今で言う「CASCADE ON DELETE」)の着想を得ていたことが挙げられます。
 3番目には、SQLの特徴を示す重要なキーワードが二つ出てきます。計算完備データ準言語(データ副言語とも言う)です。データ準言語とは、データベース管理専用の言語で、最低限データ定義、データ検索、挿入、更新、削除の機能を有するものを言います。計算能力が完全である必要はありませんし、現在のSQLも計算完備ではありません。従って、SQLの計算能力ではカバーしきれない計算を行いたいときは、計算完備なホスト言語(普通のプログラミング言語は計算完備です)の助けを借りる必要が生じます。いわゆる埋め込みSQLです。コッドは「SQLではやれない計算が必要なときは、ホスト言語の関数に任せよう」と述べています。彼としては、あまりSQLを機能豊富な大きい言語にはしたくない、という方針だったのでしょう。一から土台を作る立場ですから、最初は必要最低限な機能を実現可能な範囲で作ろう、いきなり大風呂敷は広げまい、という感覚は、理解できます。一方、デイトはこの見解に不服です。「埋め込みSQLは実際かなり長い間使われてきたのは確かだが」と、デイトは言います。「私はこの埋め込みSQLというアイデアに完全に納得したことはない。」
 しかし、です。デイトも指摘するように、最近SQLのこの側面に大きな変化が生じています。SQL-99の標準化の目的の一つは、まさにSQLを計算完備にすることにあります。SQLが計算完備になれば、埋め込みSQLは不要になり、SQLはホスト言語を全く必要としなくなります。そのための技術が1996年に標準に取り入れられたPSM(Persistent Stored Modules)です。「聞いたことない」と思うかもしれませんが、DBエンジニアならPSMを必ず使ったことがあるはずです。なぜならPSMとはストアド・プロシージャのことだからです。SQLの計算能力が不足する部分はこれでカバーしよう、というわけです。デイトも満足気に言います。「SQLは今やそれ単体で計算完備になった。つまり、もはやホスト言語は論理的には必要なくなったのである。」 もっとも、今のところ、ストアド・プロシージャはDBMSベンダごとに仕様がバラバラで、全く互換性がありませんし、デバッグ機能なども貧弱で、C言語やJAVAの代わりを果たすには力量が不足しています。これらの欠点が改善されたとき、SQLは「ホスト言語を現実的にも必要としなくなった」と言い切れる段階へ到達するでしょう。

第3章 関係に対する操作



 この章では、後に関係モデルの操作的側面と呼ばれる部分が定義されます。それはつまり、基本的な関係演算子の定義です。章の冒頭でコッドは「大半のユーザはこれらの演算に直接の関係は持たないだろう。しかしシステム設計者やデータベースの制御に関わる人は、これらに精通していなければならない」と、耳の痛い釘をさしています。さらにデイトが追い討ちをかけます。

  • 全くそのとおり! 私の経験上、これらの演算に精通していて然るべき人々があまりに頻繁にそうではないということは、まことに遺憾である。

 身が引き締まったところで、各演算の定義を見ていきましょう。69年の論文で述べられるのは、置換、射影、結合、連結、合成、それに70年の論文では制限が加わります。


交換(Permutation):属性の並び順番を変えることです。69年の論文では属性が左から右への順序を持っているために必要とされた機能です。一方、70年の論文では、交換は純粋に内部的な使用にとどまると言い換えられます。これは、SELECT句で順序を入れ替えられるのだから、実際にユーザがDBを使うときに属性の順番を意識する必要はないと考えられたからです。
 つまり、この演算は、今ではそれ専用の演算子が用意されているわけではなく、SELECT句で列の順番を入れ替えられる自由として実現されています。しかし、少し話のレベルがずれますが、私は時々この交換という機能がDDLとしてあったらいいなと感じるときがあります。確かにSELECT句で列を一つ一つ指定して選択するならば、順番を好きなように変えられますが、「SELECT *」として全ての列を選択する場合、その列の並びは固定されていて、変更できません。これを変えるにはテーブル本体の並び順を変えねばならないのですが、現在のDBMSにそういう機能はないようです。

射影(Projection):情報処理試験によく出てくる用語なので、よく知られているでしょう。関係AのX(XはAの属性)への射影を A{ X } と表記すると、これは関係Aから属性X以外の全ての属性を排除し、そこからさらに重複行を排除した部分集合を返します。いわば射影とは、与えられた関係の「垂直」部分集合を生成する演算です。空な関係が認められるのと同様、R{ } という形式の空射影(nullary projection)も認められます[2]。

連結(Tie):これも交換と同様、現在ではそれ用の演算子は用意されていません。関係 A{X, Y, ..., Z} が与えられたとすると、Aの連結は、A.Z = A.X を満たす行についてのAの部分集合です。いまこれを実現するには、単純にWHERE句で同一テーブルの2列について等号で結んでやるだけです。

合成(Compositon):二つの関係 A{X, Y} と B{Y, X} が与えられたとすると、AとBの合成は、AとBの結合からXとZについて射影をとったものです。それゆえ、AとBの自然合成はまた、AとBの自然結合についてXとZの射影をとったものです。

制限(Restriction):射影と同じぐらい馴染み深い演算でしょう。射影が「垂直」部分集合であるという言い方にならえば、制限は「水平」部分集合です(要するに普通の意味での部分集合ですが)。

結合(Join):コッドがこの論文で考えていた結合は、現在から見ると恐ろしく厳しい条件下でしか行えないものでした。すなわち、二つの関係 A{X, Y} と B{Y, X} が与えられたとすると、両者が結合可能であるのは、A{Y} とB{Y}が同一である場合に限る、という条件です。これは実務上ではまず満たされない条件ですし、そもそもそんな条件が満たされるなら最初から C{ X, Y, Z } という関係にしておけば済むことです。一体コッドは何を考えていたのでしょう?
 無論これには理由がある、とデイトは弁護を試みます。その理由とは、コッドが結合について考える際、最も重要なポイントと考えていたのが情報の保存であることに由来するものです。つまり彼は、結合においても正規化の場合と同じ原則――無損失な操作だけが許される――に従っていたのです。確かに、いま私たちが使う結合の多くは損失的です。そう考えれば、コッドの思考も納得がいきます。いわば彼は結合を「逆正規化」と捉えていたため、復元可能な結合のみが許されると結論したのです。
 デイトが感嘆まじりに指摘するように、このことは、既に当時、コッドが無損失分解(nonloss decompositon)と関数従属性の間には密接な関係があることに気付いていた証拠です。彼は、ある種の関係は二つの射影に分解すると損失が起こるが、三つの関係に射影すれば無損失であることを見抜いていました。既にお気づきでしょう。コッドは早くも正規化理論に先鞭を付けていたのです。

  • この事実が数年後に再発見されたとき、研究者コミュニティに驚きが走った。実際、ロナルド・フェイギンによる「最終」正規形、すなわち第5正規形(または射影結合正規形)の創出は、この再発見から導かれたものである。


第4章 表現可能な関係、名前をもつ関係、記憶関係



 コッドは関係を三つの種類に分類しています。しかし排他的な分類ではなく、それぞれ重なり合っています。名前をもつ関係とは、その名の通りユーザがその名前を指定することでアクセスできる関係です。表現可能な関係とは、データアクセス言語(今ならSQL)の式によって名前をもつ関係の集合から得られる関係です。全ての名前を持つ関係は表現可能な関係ですが、逆は真ではありません(SQLにおけるインライン・ビューを考えればすぐ分かるでしょう)。記憶関係とは何らかの「直接的な」方法で物理メモリに保持されている表現可能な関係です(「直接的」の定義は難しいので、ここでは深く考えないでください)。
 「この分類には少し文句を言いたい」とデイトは言います。「コッドが記憶関係という語をこういう意味で使ったのは少し不幸なことであった。個人的には、表現可能な関係を基底関係(base relation)と導出関係(derived relation)という二つにさらに分けたい。」 導出関係とは、別の関係から関係型の式によって表現可能な関係です。いわば、基底関係とは「最初から与えられた」関係、導出関係はそれ以外の全ての関係、と言うことができます。それよりも重要な区別は、基底関係と保存関係の区別である、とデイトは言います。コッドは基底関係と記憶関係を同じものと見なしましたし(彼は基底関係という語は使っていません)、現在の大抵のDBMSにおいても、この両者は同じものとして扱われています。それにも関わらずデイトが両者を区別することにこだわる理由は、その混同がデータ独立性を破壊してしまうからです。

  • 現在のDBMS製品の多くが提供するデータ独立性の程度は、関係モデルの理論が理論的に可能とするそれよりも低い。まさにこのために、私たちは、悪名高い非正規化の問題に悩む破目になる。もちろん、(パフォーマンス向上のための)非正規化は時には必要である。しかしそれは物理メモリのレベルで行なわれるべきであって、論理メモリのレベルまたは基底関係のレベルで行なわれるべきではない。

 非正規化が厄介な問題であることは、現場のDBエンジニアならば誰でも知っていることでしょう。最初から正規化なんて考えないという豪傑はさておき、まともなエンジニアなら最初は必ず正規化されたテーブル設計を考えます。非正規化とはその後でやむなく行なわれるものですが、デイトも言うように、「これさえやらなければきれいな論理設計だった」テーブル設計を台無しにしてしまう危険をはらみます。もし物理レベルでのみ行なわれるならば、非正規化は、テーブル設計を全くきれいなままを保ちつつパフォーマンスを向上させる夢の技術になっていたかもしれません。そんな技術あったら私だって諸手をあげて喜びます。デイトが悔恨の念を持つのもむべなるかな、です。

 非正規化の話は暗くなっていけません。最後に関係モデルが見事にデータ独立性を実現した明るい話でこの章を終わりましょう。すなわちそれは「ビュー」の技術です。コッドは「もし名前を持たない関係に対するアクセス頻度が非常に多くなったなら、それに名前を与えるべきである」と述べています。つまり、頻繁に使うクエリはビューにしろ! ということです。デイトはビューを「クエリの缶詰(canned queries)」と呼んでいますが、言い得て妙な、面白い表現です。保存がきくし開ければすぐ食べられる、というわけです。
 言うまでもなく、ビューは非正規化とは異なり、論理データの独立性を保持する技術です。ビューは元の基底関係を汚さないクリーンな技術です。非正規化をするときは熟考を要しますが、ビューならば軽い気持ちで幾ら作ってもかまいません。デイトはコッドが69年の時点で論理レベルと物理レベルを明確に区別している先見性に感嘆していますが、コッドが関係モデルを考案しようと思った最大の動機が、そもそも二つのレベルの区別をつけることだったこを思い出せば、むしろ当然のことと言えます(「アドレス、この巨大な怪物」を参照)。まあそれだけに、そのコッドが基底関係と保存関係を混同して論じたことは――次章で述べるような同情の余地はあるものの――惜しいことだったのです。

第5章 導出可能性、冗長性、一貫性



 この章で論じられるのは後にデータベースの整合的側面と呼ばれることになる部分です。コッドはここで「強い冗長性(strong redundancy)」と「弱い冗長性(weak redundancy)」という二つの概念をキーに議論を行います。この二つは、単一の関係が持つ性質ではなく、関係の集合が持つ性質です。ただ、弱い冗長性はあまり重要な概念ではなくその後の発展もなかったので、デイトの独断で割愛されています。
 ある関係の集合が強い冗長性を持つことの定義は、それが少なくとも一つの導出関係を含むことです。ただし、コッドの言う導出関係はデイトのそれとは異なります。というのも、コッドの定義は暗黙に基底関係を含むからです。すなわちコッドの導出関係は、前章における表現可能な関係を言い換えたもので、デイトの定義よりも広い範囲を持ちます。この点に注意が必要です。
 名前を持つ関係の集合が強い冗長性を持つことは、しばしばあるでしょう。なぜならその集合には基底関係のほかにビューも含まれるのが普通で、ビューはもちろん他の関係から導出されたものだからです。コッドは「強い冗長性はユーザのアクセサビリティを向上させるために役に立つ」と述べています。このあたり、ビューがあると結合しなくてすむから便利だ、という私たちが普通に抱く感想と同じです。
 一方、記憶関係(物理レベルの関係)は普通、この冗長性を持たない、とコッドは言います。その理由は70年の論文で詳しく述べられます。

  • 名前を持つ関係の集合が強い冗長性を持つからといって、それを直接に記憶関係の集合へ反映させれば、一般的に余計な記憶領域と更新時間を浪費することになる。

 「おいおい逆だろう」というのはデイトです。「個人的な見解としては、強い冗長性を持つべきでないのは基底関係の方で、記憶関係は別に冗長でもかまわない。」 私も同感です。さきほどの非正規化の議論と同じですが、基底関係(=論理レベルでの関係)は極力シンプルで、きれいな状態に保つべきです。もし冗長性を持たせたいならそれは物理レベルで実現すべきことです。
 とはいえ、時代背景の制約を考えたら、コッドの言い分にも同情の余地はあります。何しろ69年頃のコンピュータといえば、ハードディスクは何MB、メモリは何KBなんて時代です。CPUの計算速度も今からは比較できないほど遅いものでした。モデルの純粋性を保つためとはいえ、余計なメモリとCPUパワーを使うことが「もったいない」と感じられたとしても、無理からぬことでしょう。
 デイトはもう一点、コッドの冗長性理論に難点を指摘します。それはコッドの「強い冗長性」がカバーできていない冗長性の存在です。その冗長性は、特に名付けられてはいないのですが、関数従属による冗長性です。例えば簡単な反例として、人事{ 社員番号, 部署番号, 予算 } という関係を考えると、明らかに

  社員番号 → 部署番号
  部署番号 → 予算

 という(推移)関数従属性が存在します。ゆえにこの関係は冗長ですが、それは(コッドの言う)強い意味で冗長なのではありません。コッドの冗長性理論では、このような同一関係内における冗長性を扱うことができません。

第6章 データ・バンクの制御



 最終章では、もしデータの不整合が発見された場合、DBMSがどう対処すべきかのプロトコルがごく簡単に概略されます。それをまとめるなら、以下の二つになります。
  1. 不整合が発生したら、それを内部的なログに記録すること
  2. もし不整合がすぐに回復されなければ、システム管理者にそれを知らせること
 思わず「え、これだけ?」と言ってしまいそうな、実に単純極まりない記述です。現在のDBMSでは、データ不整合に対処するためのバックアップとリカバリの技術は大きな発展を遂げていますが、そういった便利な補助機能は、あくまで関係モデルにとっては「補助」であって中核ではない、ゆえにその理論の構築にあたって機能の実装まで気にかける必要はない、というのがコッドのスタンスだったのでしょう。



[1] 別の言い方をすると、関係の一つのタプルは、一つの原子式(atomic formula)になっています。原子式とは、∧、∨、∀などの論理記号を含まない論理式のことです。最小単位の命題、という意味で「原子」式と呼びます。通常、リレーショナル・データベースに含まれるタプルは、全て原子式です。
 また、デイトとよく共著の仕事をしているH.ダーウェンは、「データベースは公理の集合、クエリの結果は定理の集合だ」という名言を吐きました。これも、関係を命題の集合と捉える観点からの発言です。

[2] 『データベースシステム概論』p.168

 

作成者:ミック
作成日:2009/04/18
最終更新日:2017/06/22 b_entry.gif b_entry.gif