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

 この文章は、クリス・デイトの "The Birth of the Relational Model - Thirty Years of Relational (3)" の要約です。第3部では、いよいよ関係モデルを世に知らしめた1970年の論文 "A Relational Model of Data for Large Shared Data Banks" が扱われます。

アドレスから遠くはなれて



 70年のこの論文が69年の論文と大きく異なる点が幾つかあります。そのうちの一つが、(主に物理的な)データ独立性がより前面に押し出されたことです。
 コッドが関係モデルを考案するまで、データベース・システムの主流なモデルは、木構造の階層モデルと網モデルの二つでした。どちらも、データの指定にインデックス(ポインタ)を使用する必要があり、データの格納順序をユーザが意識しなければならない、抽象度の低いものでした。それゆえ、コッドの第一目標は、ユーザをそのような無用の煩わしさから解放することでした。すると必然的に、「データベースはインデックスも順序付けられたフィールドも含まない」のです[1]。ひゅー!
 論文の序文から。

  • 端末やアプリケーションを使う大規模データ・バンクのユーザを、マシン上でデータがどう組織されているかを知らないと扱えない現状から守らねばならない。端末の前に座るユーザとアプリケーションの活動は、内部でデータの表現方法が変わったぐらいで影響を受けてはならない。

実に心強い言葉ではありませんか。そう、デイトが正しく指摘するように、この論文は、コッドが初めて、関係モデルから表現上ポインタを追放すべきであると明確に主張した、記念すべきマニュフェストなのです。インデックスによる呼び出しはデータの内容による呼び出しに、データの格納順序は SQL の ORDER BY句で指定する動的な順序に、それぞれ取って代わられることになります。ポインタの追放と言っても、あくまで「表現上」の追放にすぎず、「物理上」の追放にはなっていないではないか、という不満を抱く向きは「アドレス、この巨大な怪物」を読んで、コッドのリアリズムを再認識してください。

正規形



 70年の論文における重要な変化は、データ独立性の強調だけではありません。正規形の概念が登場するのもその一つです。コッドはこの論文で第1正規形のアイデアを提出しています(第2、第3正規形は後の論文で定義されます)。コッドが断りなしに「正規形」とか「正規化された」と言う場合、それは第1正規形を意味します。今となっては、全ての関係が第1正規形を満たしていることは私たちにとって当然の前提なので、コッドの力点の意味が少し実感湧かないでしょうけど、まだ関係モデルの定義から始めなければならない時代としては、これは当然の態度です。というのも、第2、第3正規形を満たしていなくても関係モデルのテーブルは作れますが(しょっちゅう見かけますよね)、第1正規形を満たしていなくては不可能です。つまり、全ての関係が第1正規化されているということは、関係モデルによるテーブルを作るための必要条件なのです。

  • [正規化された] 関係は、記憶装置の中で二次元の均質な列配列(column-homogeneous array)によって表現することができるが、 …… [正規化されていない] 関係を表現するにはもっと複雑なデータ構造が必要になる。

 「第1正規化された関係」を言い換えると「定義域に原子値(atomic value)のみを含む関係」(コッド)ということです。原子値は、今ではスカラ値と呼ばれています。それ以上分割できない最小単位のデータ構造のことで、具体的には普通の数値型や文字型の値を想像してください。
  
ところがですよ。

 誕生から30年を経て、なんと SQL-99 では第1正規形を満たさない「配列型」を定義できるようになってしまったのです。しかも Oracle はいち早くこれを取り入れてしまいました。そんなのより先に真理値型をサポートしてください。「ユーザや市場からの強い要求」により実現だそうですけど、私は複雑な気持ちです。

 複雑というのは、これを関係モデルにとって有意義な拡張と見るか、危険な逸脱と見るか、容易には判断しかねるからです[2]。実務的には、少なくとも、現時点で不用意にコレクション型のデータを使うことは危険だと思います。これを扱うための演算子や述語が整備されるまでは、使用を控えた方が良いでしょう。私自身も使ったことはありませんし、周囲にもそういう事例を知りませんが、どうでしょう、これを使った(使わせられた)方の感想は。

 一方、これまで関係モデルが非正規化データを扱えなかったことは、その限界の一端を示すものであると、しばしば言われてきました。それは正しい批判です。一般にホスト言語においては、そういうデータは配列、構造体、オブジェクトなどの柔軟なデータ型を駆使することで表現できますが、それをデータベースに登録するときは、全てスカラ値に分割して ―― つまり第1正規化して ―― 格納しなければなりません。皆さんも、ホスト言語と DB との間でデータの受け渡しをするときに、この許されるデータ構造の食い違いに頭を悩ませた経験があるでしょう。これは「インピーダンス・ミスマッチ」と呼ばれる問題の一つです。だから、ホスト言語で表現できるデータ型をデータベースの側でもサポートできるよう「拡張」したいという要求は、ごく自然なものではあるのです[3]

 …… しかし、その方向を突き進めて行くと、いつの日か関係モデルは、かつてコッドが捨てた一つの選択肢を復活させることになるのではないかという気が、私にはします。それは、二階述語論理です。一階述語論理が行(=命題)のみを量化できたのに対し、二階述語論理は、関係(=命題の集合)を量化することのできる、極めて強力な表現力を持つ論理です。例えば、一階述語論理の関係モデルにおいては、「業者 S1 は、『業者』テーブルのどこかのに存在するか?」 という一つのテーブル内で完結したクエリしか書くことができませんが、二階の論理を使うと、「業者 S1 は、どこかのテーブルに存在するか?」という、複数のテーブルを走査するクエリを表現できるようになります。「階(order)」という語が表す通り、SQL のレベルが一段上がります。

 ただし、強力な分、同時に実装もユーザが使いこなすことも難しくなります。仮に、もし将来、二階述語論理を実装した DBMS が要請されるなら、(少なくとも、4値論理を実装した DBMS に比べればはるかに)見てみたいという気持ちは、私にもあります。他方、デイトは「関係などのコレクション型を定義域に含められるよう拡張することは構わないが、その場合でも一階述語論理に踏みとどまった方がいい」という、折衷的な意見を述べています。あるいはそれが現実的な選択かもしれません。

 どうも歯切れの悪い文章で恐縮ですが、本当にこのあたりは何が最適解か、簡単には分からないのです。

その他もろもろ



 リレーショナル・データベース誕生史についての話は、前章で終わりです。最後に、大きな枠組みに入れにくい幾つかのテーマが取り上げられます。


 1.関係モデルの基礎は命題論理?
 もちろん、述語という道具立てを使っているので、その意味では間違いなく述語論理が基礎です。しかし、こと全称量化と存在量化の役割について見た場合、関係モデルで使われる述語論理は、一般に論理学で言われるところの「述語論理」よりも狭い範囲になります。というのは、量化される命題、つまり行の数が有限の場合、量化子を使った表現は命題論理の連言と選言に書き換えられるからです。そしてデータベースに存在しうるテーブルの行数は、どんなに巨大なテーブルであれ有限に決まってます。従って、関係モデルの使う論理は、少し範囲の狭い一階述語論理と言うことができます。


 2.パフォーマンス
 コッドは、パフォーマンスの問題についてはほとんど言及していません。現在ではパフォーマンス・チューニングは重要な技術として大きな発展を遂げていますが、彼は果たしてどの程度この状況を見通していたでしょうか。

 しかし、コッドのコメントは、短いながらも関係モデルの理念の一つを述べた重要なものです。それは、「効率的なレスポンスとスループットを提供する責任は、ユーザからデータ・システムに移る」という言葉です。まるで、オプティマイザの登場を予言したかのような言葉です。そう、ユーザがレスポンス低下やアクセス・パスの決定といった物理レベルに近い問題に煩わされることは、関係モデルの主義に反することなのです。

 残念ながら、現在のオプティマイザは、コッドの予言を完全に実現するほどの力を、まだ備えていません。しかし、オプティマイザが、リレーショナル・データベースの技術が本来目指すべき方向 ―― 抽象化によるユーザの利便性向上 ―― を体現するシステムであることは、間違いありません。


 3.コネクション・トラップ
 正規化して複数に分割されたテーブルを、結合によって復元しようと試みたとき、元のテーブルにはなかった余計なレコードが付加された結果が出てきてしまった、という経験はないでしょうか。結合キーを正しく把握できていなかったときに起こるこの現象が、コネクション・トラップです。正しく正規化と結合をしていれば、こんな幽霊のようなレコードが現れることはありません。

 このコネクション・トラップは、かつて網モデルや階層モデルのようにポインタを使って項目を結合させるシステムでは頻発していたエラーの一つでした。もちろん、上述のように関係モデルでも起こりえますし、それを根拠に関係モデルを批判する論者もいるそうですが、デイトの言葉を借りるなら、「そういう批判は、関係モデルについての悲しき無理解のゆえに、不適切なものであることは明白である。」


 4.関係の定義はあるのだけれど

 70年の論文のテーマは、関係モデルです。ところが、タイトルの一部にも含まれているにも関わらず、この論文のどこにも関係モデルについての明確な定義がありません(「関係」の定義はあるのですが)。コッドが関係モデルの明確な定義を提出するのは、1979年、"Extending the Database Relational Model to Capture More Meaning" においてです。

 ちなみに、そこでコッドが関係モデルに含まれるべき要素として挙げているのは、
  1. 時間変化する表形式の関係の集合(各関係はキーとドメインによる整合性を満たすこと)
  2. INSERT、UPDATE、DELETE のルール
  3. 関係代数
です。だから、「関係モデルは、結局のところフラット・ファイルに過ぎない」という、よく聞く定義に対して、デイトは「それは関係モデルの操作的側面と整合的側面を無視した間違いだ」と言って批判します。


 5.やっぱりコッドは偉かった
 デイトによると、「関係モデル」という概念を定義した論文が、コッドに先んじること1966年に発表されているそうです。ただその論文は、データベースの分野ではなく、自然言語処理についてのもので、そこで言われている関係も全て2項関係のことです。従って、同じ名前ではあるものの、コッドの関係モデルとは大きく異なります。それゆえ、デイトが結びの言葉としている「現在私たちが見知っている関係モデルを発明した名誉は、コッド一人に与えられるべきものである」という言葉が全くもって正当なものであることに、もちろん私も異存はありません。


 さて、これで全3回におよんだリレーショナル・データベース誕生史の話は終わりです。いかがだったでしょう。普段、データベースを道具として使っているとき、私たちは主に仕組みの観点から、つまり論理の観点から理解しています。しかし、たまには目線を変えて歴史の観点から理解してみることも、味のあるものではないでしょうか。そしてこの二つの理解の仕方が、決して無関係ではなく、相補うものであるということも、ここまで読んでいただいた皆さんには明らかであると思います。

 デイトの連載にはここから先の「発展史」もあります。興味ある方は、是非読んでみてください。



[1] この文章で言う「インデックス」は、パフォーマンス・チューニングのときに用いられるインデックスではなく、データを管理するためのアドレスのことです。(物理的には同じですが、機能的には違います。)

[2] 対照的に、明らかに危険な逸脱も存在します。その代表格は、オブジェクトへのポインタそのものである REF型です。デイトはこの REF型が大嫌いで、「何が悲しくて、せっかく追放したポインタをまた持ち込まなければならないのか」と猛批判しています。(参照:"Extending the Relational Model"(1999))
 その意味では、行ID の rowid(Oracle)や oid(PostgreSQL)もきわどい存在ですが、こちらは実際には主キーの代用ぐらいしか使い道がないので、私は無害で便利だと思ってます。当然というか、デイトが設計に関わった DB2 には、こういうユーザが直接利用できる行ポインタは実装されていません。ストイックです。デイト本人は、行ID については「全面禁止」とまでは言わずに、少しアンビヴァレントな立場です。以下を参照。

  • 行ID自体はリレーショナルモデルの一部ではないが、だからといって行IDをサポートすべきでないとは言えない。だが、余談ながら重要なので述べておくと、これらの行IDがオブジェクト指向の意味において何らかのオブジェクトIDと見なされるとしたら、行IDは間違いなく禁止されるのである。 ・・・・・・ オブジェクトIDは実質的にポインタであり、リレーショナルモデルではポインタを明示的に禁止している。(『C.J.Dateのデータベース実践講義』(2006) p.74)

[3] 扱えるデータを拡張する方向として、ここでデイトが論じるような、リレーショナル・データベースの範囲内での拡張のほかに、もう一つ、そもそもリレーショナルではないデータベースを模索する、という方向もあります。そのようなデータベースとしては、例えばオブジェクト・データベースなどが知られています。

 

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