リレーショナルモデル(其の壱)

遅くなりましたが、2016年の初ブログです。今年は今までと趣向を変え、DBネタを中心に提供しようと思います。

昨年を振り返ると多くの出会いがありましたが、エンジニアとしてもっともインパクトがあった出会いは、リレーショナルモデル*1との遭遇です。

わたしはもっぱらクライアント側の開発者ですが、それでもSQLをひととおり学び、幾つもの現場を経て経験を重ね、複数のRDBMS製品*2を弄ってきたため、それなりにデータベースを理解した気になってましたが、それを根底から打ち砕いてくれたのが、奥野幹也さんの著書 「理論から学ぶデータベース実践入門」 でした。


この一年、本書を繰り返し読むだけでなく、読書会や勉強会、さらに著者本人にお会いして直接質問したりと勉強重ねるうち、少しずつリレーショナルモデルにつき理解を深めてきました。またその背後にある集合論や述語論理等の数学的理論についても関心が湧いてきたものです。そこでリレーショナルモデルについて、いままで学んできたことの整理も含め、ブログで少しずつ公開したいと思います。

概要

リレーショナルモデルは、エドガー・F・コッド博士が発明した、集合論述語論理 に基づくデータモデルです。リレーショナルデータベースシステム(RDBMS) は、このリレーショナルモデル理論を基に開発されました。この功績により、コッド博士は 1981年、チューリング賞を受賞しています。

歴史

コッド博士が1970年に発表した論文、「A Relational Model of Data for Large Shared Data Banks」 (大規模共有データバンクのデータ関係モデル) に於いて、初めてリレーショナルモデルの概念が発表されました。以下リンク先でレポート全文(英語)が閲覧できます。

A Relational Model of Data for Large Shared Data Banks


ただしこの論文は、当時彼が勤めていたIBM では階層型データベースの開発に注力していたため社内では大して評価されず、1977年、この論文に着目したオラクルの創業者ラリー・エリソンにより、世界初のリレーショナルデータベース「Oracle」の商業化に成功します。

後塵を喫した IBM は 1981年、リレーショナルデータベース 「DB2」 を開発。その後、IBM におけるコッドの同僚 クリス.J.デイトの書籍 「An Introduction to Database Systems」 (データベース概論*3)により、リレーショナルモデルは広く普及するに至ります。

その間、リレーショナルモデルを操作する言語として SQL という宣言型言語が開発されましたが、リレーショナルモデルの制約を大きく逸脱した仕様に発展し、現在に至ってます。どのように逸脱してるかについては、後日解説したいと思います。

ありがちな誤解

まず、よくありがちな誤解ですが、RDB・・・リレーショナルデータベースの 「リレーショナル」 とは、テーブル間のリレーションシップではなく、リレーショナルモデル理論に基づくデータベースという意味です。
リレーショナルモデルの 「リレーショナル」 (関係) につき、「テーブル同士の関連」 として捉えているケースがありますが、それは大きな誤りで、テーブル間のリレーションシップとリレーショナルモデルは、まったく異なる概念です。

リレーショナルモデル ≠ リレーションシップ

リレーショナルモデルにおけるリレーション(関係)とは、複数の 「属性」 と複数の 「組」 で構成された、SQLでいうところの TABLE に相当する存在です。ただしあくまで相当する存在であって、TABLE = リレーションではなく、当然 「表」 でもありません。

なぜリレーション(関係)というのか

リレーショナルモデルの 「リレーション」 とは、実は集合の 「2項関係」 から発展?した 「n項関係」*4 という概念から考案された、極めて数学的なデータモデルです。これも後日機会をみて解説します。

リレーション(関係)の構造

リレーション(関係) は、1個以上の属性(アトリビュート)の集合である 「見出し」 と、0個以上の組(タプル)の集合である 「本体」 で構成されており、属性や組に順序は存在せず、また属性や組に重複はありません。その存在はあくまで一位(ユニーク)です。リレーションは SQL の TABLE に相当し、属性は TABLE の列、組は TABLE の行(レコード)に相当しますが、その概念は似て非なるものです。
概念図を以下に示します。


属性は「名前」と「型」*5の二つで構成されており、組の値は属性の型のインスタンスが格納されます。つまり見出しをテンプレートと捉えるなら、組はその実体と言えるでしょう。上の図の場合、「氏名」「住所」「性別」は文字列、「年齢」は整数であり、組である各レコードには、その実値が格納されています。


さて、理解を深めるために、ここで問題です。以下二つの表を見比べてください。これを SQL のテーブルとして見た場合、同じテーブルといえるでしょうか?


答えは、この二つの表を同じテーブルと認めることはできません。なぜなら、二つの表を比べると、列と行(レコード) の順序が異なっています。二つのテーブルを生成する CREATE TABLE 文は異なる文になる筈です。


では、この二つの表をリレーションとしてみた場合、同一のリレーションと捉えることはできるでしょうか?
答えは YES です。リレーションの見出しを構成する属性と本体を構成する組に順序はありません。そもそも論ですが、集合は各要素に順序なぞ存在しません。よって構成する属性と組の集合が同一なら、同じリレーションと認識することができます。


ここまでの説明では、リレーションを表で表現しました。ただし 「理論から学ぶデータベース実践入門」 では、リレーションは表ではない!ということを読者に認識してもらうため、リレーションを楕円形で表現しています。徹底してますねw
ちなみに上のリレーションを奥野流に表現するとこうなります。


次回も引き続き、リレーションは二次元の表ではなく、集合論に基づいた、極めて数学的なモデルということを強調していきたいと思います。

(続く)


エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

  

*1:関係モデルともいう

*2:InterBase・FireBid・SQL ServerMySQL・etc・・・・

*3:現在8版まで出版されてるが、和訳版は絶番、英語版も1万円近いっ!

*4:多項関係ともいう

*5:ドメインとも言われる