この文章はデータベース・セミナー用の原稿です。 スライドは Prezi をみてください。
Oracle や PostgreSQL などのデータベース製品は、 RDB とよばれるタイプのデータベース管理システムです。 RDB の「R」は「リレーショナル」(relational) という言葉に対応しています。 もちろん、「DB」は「データベース」(database) に対応しています。 日本語になおすと、「リレーショナル」は「関係」という言葉になります。 つまり、「RDB」は「関係データベース」、あるいは、 より形容詞らしくいうと、「関係型データベース」という日本語になります。 それでは 関係データベースとは、本質的には、何でしょうか。 あるいは、関係データベースが立脚するところの理論である 関係モデルとは、本質的には、何なのでしょうか。
結論を先にいうと、関係モデルとは、「判断することの計算体系である」 といえます。関係モデルをこのように捉えることで、 理論の形式と機能が、より明快に理解できるようになります。
(目安時間 5 分)
データベース言語の SQL は、1979 年に Oracle の前身 Relational Software Inc から最初の商用製品が発売されて以降、 データベースの標準として広く使われています。
SQL は関係モデルにもとづくデータベース言語のひとつです。 そのため、SQL データベースは関係データベース (RDB) として紹介されます。 しかし、そのもとづき方をよく見ていくと、 「おおよそ、もとづく」というものにすぎず、 厳密には、「準関係型」データベース言語とよぶべきものであることがわかります。 データベースの専門家のなかには、「疑似関係型」とよぶ人もいます。
Wikipedia の 関係モデル のページをみてみると、 SQL が、どのような点で、関係モデルに準拠していないかが説明されています。 「関係」の代わりに「表」を使うという基本的違いを始め、 つぎのような違いがあります。
- 行の重複
- 名前のない列
- 列名の重複
- 列に順序がある
- 予想外の更新結果になるビュー
- 表はひとつ以上の列をもつ
- NULL
現在、関係モデルにまつわる技術的状況は、 SQL を通すと関係モデルはぼやけてしまうという状況にあり、 関係モデルの理論を知るには、特別の努力が必要であるといえます。 理論の本来のすがたを知らなければ、 理論を実践へ応用することも、実践を理論へ還元することも、十分に行えず、 結果として、関係モデルの潜在能力を発揮できないことにつながります。
(8 分 + 質問 2 分)
E/R モデルは、おもに、データ・モデリングの分野で使われる理論です。 「E」は「実体」(entity) を意味し、 「R」は実体間の「関連」(relationship) を意味します。 関係モデルと E/R モデルは、まったく、別の理論なので、 「関係」と「関連」というよく似た用語は、別の意味をもちます。
実体は、モデリングしようとする世界内の存在者です。 たとえば、「作品」「監督」「俳優」などは実体とみなせるし、 「監督する」「出演する」「公開する」などは実体間の関連とみなせるでしょう。
現在、E/R モデルは、データベース設計でよく使われており、 E/R モデルで表現した設計結果を、SQL データベースに変換して実装する という方法が採用されることがあります。 この方法は十分な実績がありますが、同時に、問題点も残されたままです。 問題点とは、世界内の存在構造に注目する E/R モデルと、 言葉を通して世界を分節化しようとする関係モデルとでは、 世界の見方が大きく異なるため、いわゆる、 実体・関係インピーダンス・ミスマッチが大きいことです。
E/R モデルと関係モデルのどちらかを残して、 このミスマッチを解消するには、大きく分けて、 ふたつの方針があります。
- E/R モデルで設計して、E/R モデルと相性のよいデータベースに実装する。
- 関係モデルに相性のよい方法で設計して、関係データベースに実装する。
このうち、より簡単と思われる 2 の方法を考えましょう。
(8 分 + 4 分)
E/R モデルで設計し、関係データベースに実装するとき、 実体のクラスを関係に対応させることになります。 実体のクラスと関係は、その性質にさまざまな違いがあるため、 問題が生じることがあります。 関係と相性のよい方法として、実体のクラスの代わりに、 判断の集合を取り上げましょう。
実体のクラス → 関係 ← 判断の集合
ここでの判断とは、正しいか間違っているかが決まっている文のことです。 たとえば、「チャップリンは世界の三大喜劇王のひとりである」という文は判断です。 この文は、実際に、正しく、より正確にいえば、 世界を認識する主体であるわたしたちの心が正しいと判断します。
判断の一部を空欄にした「○○○○○ は世界の三大喜劇王のひとりである」 という文を考えると、「○○○○○」になにか具体的な名前を入れない限り、 判断としては未確定であるといえます。 この判断が正しくなるような「○○○○○」を集めてくると、
- チャップリン
- キートン
- ロイド
の 3 人が当てはまります。この例はとても小さいですが、
三大喜劇王のデータベースにほかなりません。
「○○○○○」の部分を項目とよぶことにし、項目名 /actor を割り当てると、
「/actor は世界の三大喜劇王のひとりである」という項目化された文が得られます。
このような情報の表現方法をコンピュータが扱いやすくするために、
文のパターンに対して「三大喜劇王」のような名前を割り当て、
文の内容が正しいと判断する行為に |-- という記号を当てると、
三大喜劇王についての 3 つの判断は、つぎのように書けます。
|-- 三大喜劇王 /actor チャップリン
|-- 三大喜劇王 /actor キートン
|-- 三大喜劇王 /actor ロイド
ほかに、「○○○○○ という作品に ○○○○○ が出演している」
というパターンの文で、項目名を /title と /cast にすれば、
つぎのような判断として出演情報を表現できます。
|-- 出演 /title ライムライト /cast チャップリン
|-- 出演 /title ライムライト /cast ブルーム
|-- 出演 /title ライムライト /cast キートン
|-- 出演 /title モダンタイムス /cast チャップリン
|-- 出演 /title うり二つ /cast キートン
この先頭の記号 |-- のたて棒 | は、「フレーゲ・ストローク」あるいは
「フレーゲの判断線」(Frege's judgement stroke) とよばれています。
わたしたちが、○○○○○ が正しいので、○○○○○ も正しいというような
論理的推論を行うときの、前提の判断や結論の判断をあらわすときに
使えるように考案された記号です。
データベースの検索も、正しい情報から、正しい情報をつくり出す という枠組みでとらえられます。 たとえば、三大喜劇王のチャップリン、キートン、ロイドが 共演したことがあるかどうかを調べたいならば、 上の「三大喜劇王」と「出演」の判断を材料として、 「○○○○○ と ○○○○○ は作品 ○○○○○ で共演している」 という合成された判断をつくり出すことになるでしょう。
前提となる判断集合から、結論となる判断集合をつくるには、 情報を組み合わせる計算が必要になります。 この計算のための道具として関係モデルを使います。 前提となる判断集合を関係に変換し、 関係モデルの演算を使って関係から関係へと変換し、 最終的に得られた関係を結論となる判断集合にもどします。
判断集合 (前提) → 関係
↓
判断集合 (結論) ← 関係
この観点からは、関係モデルとは、判断集合から判断集合をみちびくときに使う 計算体系であるということになります。
(12 分 + 5 分)
三大喜劇王の共演に関する情報を「三大喜劇王」と「出演」という 判断の集合から計算してみましょう。
判断に関する計算を行うには、まず、判断の集合を関係に変換します。 つまり、判断集合
|-- 三大喜劇王 /actor チャップリン
|-- 三大喜劇王 /actor キートン
|-- 三大喜劇王 /actor ロイド
|-- 出演 /title ライムライト /cast チャップリン
|-- 出演 /title ライムライト /cast ブルーム
|-- 出演 /title ライムライト /cast キートン
|-- 出演 /title モダンタイムス /cast チャップリン
|-- 出演 /title うり二つ /cast キートン
が、つぎのふたつの関係に変換されます。 関係をコロン区切りの表形式であらわしましょう。
star
/actor
チャップリン
キートン
ロイド
cast
/title : /cast
ライムライト : チャップリン
ライムライト : ブルーム
ライムライト : キートン
モダンタイムス : チャップリン
うり二つ : キートン
このふたつの情報を組み合わせたいので、
/actor を /cast という名前に変更します。
star-2
/cast
チャップリン
キートン
ロイド
ふたつの関係 star-2 と cast の交わりを計算すると、
喜劇王の出演情報が得られます。
star-cast
/title : /cast
ライムライト : チャップリン
ライムライト : キートン
モダンタイムス : チャップリン
うり二つ : キートン
誰と誰が共演したかを計算したいので、
/cast という項目名を /cast-1 と
/cast-2 に変更します。
cast-1
/title : /cast-1
ライムライト : チャップリン
ライムライト : キートン
モダンタイムス : チャップリン
うり二つ : キートン
cast-2
/title : /cast-2
ライムライト : チャップリン
ライムライト : キートン
モダンタイムス : チャップリン
うり二つ : キートン
このふたつの関係の交わりを計算し、
/cast-1 = /cast-2 となる組を除外します。
co-star-both
/title : /cast-1 : /cast-2
ライムライト : チャップリン : キートン
ライムライト : キートン : チャップリン
/cast-1 と /cast-2 が反対になった組が冗長なので、
/cast-1 < /cast-2 という条件を入れて、片方だけにしましょう。
co-star
/title : /cast-1 : /cast-2
ライムライト : キートン : チャップリン
これを判断として書き出すと、「ライムライトでキートンとチャップリンが共演している」 という意味の情報が得られます。
|-- 共演 /title ライムライト /cast-1 キートン /cast-2 チャップリン
いま、判断集合を関係に変換し、関係から関係への計算を行い、 結果の関係を判断集合にもどすという処理を行いました。 関係と判断集合は、ほとんど同じものといえますが、 関係は計算用途に特化した抽象的な記号であるのに対して、 判断はデータを解釈するための要素が含まれているという違いがあります。 これは、ちょうど、数が計算用途に特化した抽象的な記号であるのに対して、 その数でいろいろなものを数えられることに似ています。 いわば、数えることの計算体系として、数と四則演算があるように、 判断することの計算体系として、関係と関係演算の体系である 関係モデルがあるといえます。
(12 分 + 6 分)
関係モデルにおける関係とは、つまるところ、何なのでしょうか。 関係の機能、構造、用途をみていくことで、その本来の姿を描き出してみましょう。
関係は判断集合と対応しています。 関係は、その項目集合が固定なので、 同種の判断の集合としか対応しません。
関係と判断集合は、互いに変換できます。 判断集合から関係を得るには、判断をあらわす地の文を取り除き、 項目のみを取り出すことで、意味を捨象します。 逆に、関係を判断集合に変換するには、 関係の項目内容を地の文に埋め込み、その意味を復元します。
関係は計算用途の記号法です。 ちょうど、数と数をかけ算して、合成された数が得られるように、 関係と関係から合成した関係が得られます。 1 週間は 7 日で、4 週間なら 28 日と計算するとき、 週や日というもとの意味を捨象して、 7 × 4 = 28 という計算をしたのち、28 を日数として解釈するように、 関係も、もとの意味を考慮しなくても、計算できるという特徴があります。
関係は組の集合で、組は項目の連想集合です。 ひとつの関係内のすべての組は、 同じ項目集合になっている必要があります。 組は、項目間に成立する関係の具体例です。 連想集合とは、項目名からその内容を参照 (連想) できるような構造のことです。
関係データベースは、項目間の関係として表現された情報を保存でき、 関係から関係への計算能力を提供します。 正しい情報が保存されていれば、必要な計算を正しく行うことで、 正しい検索結果が得られます。 関係を直接保存する方式でも、判断集合を保存して、 計算時に関係に変換する方式でも、どちらでもデータベースとして実現できます。
関係はデータベースだけのものではなく、 正しい情報から正しい情報を計算したいときに使える汎用的な記号法です。 数の計算と同じように、関係の計算は、幅広い応用が見込まれます。
(8 分 + 4 分)
ここまで、関係モデルとは「判断することの計算体系である」という考え方が、 どのような内容であるかを紹介してきました。これは、データベースの利用 という文脈で、どのように役立つのでしょうか。
SQL データベースのテーブルの行をみたら、 それを判断というカテゴリの日本語の文章に対応させてみましょう。 つまり、正しいか間違っているかのどちらかになるような 日本語に翻訳するということです。できれば、そのときに、 フレーゲ・ストロークを頭に思い浮べてください。 フレーゲ・ストロークを思い浮べるとは、データベースには、 正しい情報が入っていると思うことです。 こうすることで、データの意味がはっきりとして、 ほかの人にも伝えやすくなります。 絵では伝わらない内容を、言葉で伝えましょう。
データベースを検索することは、正しい情報から、 合成された正しい情報をつくり出すことです。 これは、判断の集合から、合成された判断の集合をつくり出すということです。 データベースへのクエリは、判断集合が入力されて、 判断集合が出力される装置とみなせます。
より正確には、判断集合から意味を取り除いて、 計算に適した記号体である関係をつくっています。 クエリの内部では、関係から関係へと変換されていきますが、 そのステップごとの関係は、すべて判断集合へ戻せることに注意しましょう。 それは、各ステップごとに、なんらかの意味に対応しているということです。
これらのことが、無意識にできるほど馴染めれば、 データベース設計にも、クエリの組み立てにも、 情報の意思疎通にも、判断と関係が役立つことでしょう。
(6 分 + 3 分、合計目安時間 59 分 + 24 分)