関係データベース (RDB) の基礎理論である関係モデル (リレーショナル・モデル) は、きちんと理解されていないと専門家によって指摘されることがあります。 たとえば、クリス・デイトの データベース実践講義 では、つぎのように述べられています。
データベース・コミュニティにおいて、 リレーショナル・モデルがあまりよく理解されていない、 あるいはあまり広く理解されていないことは明らかである。
関係モデルは、SQL データベースの形で、 30 年以上、利用されてきているにもかかわらず、 その理解が十分な水準に到達していないのはなぜなのでしょうか。 その要因として、このノートでは、SQL と E/R モデル を取り上げ、 文章を短かくするため、理由をひとつだけ説明します。 おそらく、SQL と E/R モデルが、関係モデルとどのように違うかを意識することで、 それらをよりうまく使えるようになるのではないでしょうか。
SQL は RDB の標準言語です。 しかし、RDB の機能を十分に実現していないため、 RDB の代わりに SQLDB ともよばれます。 このことは、データベースの専門家には認識されており、 SQL の用語は RDB とは異なる用語が採用さています。 代表的なところでは、relation (関係) の代わりに table (表) が使われており、 このような命名は、RDB とは異なるデータベースであることを含意しています。
関係と表の違いのひとつとして、行の重複に差異をみとめるかどうかがあります。
SQL の言語要素では distinct の役割に関係しており、
つぎのふたつの select 文は、一般には、異なる結果になります。
(select all は、通常、単に select と書かれます)
select all a, c from T -- 重複する行がそのまま残る
select distinct a, c from T -- 重複する行がひとつにまとめられる
しかし、表ではなく関係の場合には、同じ結果になります。
というのは、項目 a と項目 c の間にある関係が成立するかどうかに着目すると、
a = 'A1' と c = 'C5' の間に関係が成立すれば、
当然、同じ a = 'A1' と c = 'C5' の間にも成立するからです。
関係の成立・不成立に依拠すれば、同じ行がいつくあっても差異は生じないため、
必然的に distinct され、all は不要であるということになります。
ブドウが 5 房あり、各房から実を 2 粒残して食べてしまっても、
依然としてブドウが 5 房あることには代わりないように、
SQL の select all では、
5 行のデータを 2 項目にしたら、つねに 5 行のデータになります。
これは、表の行をモノのように扱っているといえます。
このような言語機能によって、
項目間に成立する関係として情報を把握する
という関係モデルの中心的な考え方が希薄になり、
結果として、その理解にゆがみが生じることにつながります。
E/R モデル (実体関連モデル、entity/relationship model) は、 SQLDB と組み合わせて使われることがあります。 たとえば、IPA (情報処理推進機構) が実施している データベース・スペシャリスト試験の平成 24 年版のシラバスには、 要求される技能のひとつとして、概念データモデルから 論理データモデルに変換する能力をあげており、 概念データモデルとして、E/R 図や UML、 論理データモデルとして、関係スキーマ、テーブル設計を想定してます。 このように、E/R モデルで設計し、関係モデル (実際には SQLDB) に変換することがよく行われます。
E/R モデルは実体 (E: entity) を基本要素として情報体系を把握し、 実体間に関連 (R: relationship) を定義して実体の集合を組織化します。 この実体と関連は、ともに、SQLDB の表に変換されますが、 関係モデルでは、(表の) 項目間の関係として情報を把握するため、 E/R モデルでは定義されていないさまざまな操作が可能になります。
たとえば、つぎの 4 つの項目
/取引先コード /相手商品コード /相手商品コード体系 /自社商品コード
の間に成立する関係 商品変換 が、つぎのようなデータ解釈をもつとします。
(項目名の先頭に / をつけ、データ解釈を <<< と >>> で囲みます)
<<< /取引先コード の取引先で使われている /相手商品コード は /自社商品コード に相当する。
その /相手商品コード のコード体系は /相手商品コード体系 に属す。 >>>
このデータは、取引先からの注文を受けるとき、取引先ごとに違う可能性がある
/相手商品コード を /自社商品コード に変換するために使われます。
/相手商品コード が JAN や GTIN などのどの体系のコードであるかを
/相手商品コード体系 であらわします。このデータから
<<< /取引先コード の商品は /相手商品コード体系 で記述されている。 >>>
というデータ解釈をみたす関係を得るには、 つぎの問い合わせを使えばよいでしょう。
select distinct 取引先コード, 相手商品コード体系
from 商品変換
E/R モデルでは 商品変換 という実体が情報の単位として存在するため、
それを /取引先コード /相手商品コード体系 だけに分割するという操作はありません。
しかし、関係モデルでは正式の操作として定義されています。
この例のように、E/R モデルでは実体より小さな単位を導出できないけれども、
関係モデルではそれが可能になっている理由は、
/取引先コード や /相手商品コード体系 が実体の属性という考え方ではなく、
項目間の関係として情報の意味を把握していることにあります。
そのため、一般に、E/R モデルよりも関係モデルの方が、
情報の意味を細かく扱え、意味の部分化や合成というような
データ解釈の導出が無制限に可能 になります。
無理に E/R モデルをあてはめようとすると、データ解釈の導出が不自然になったり、
実体単位で情報を把握するため、意味の粒度があらくなったりすることで、
関係モデルの能力を十分に引き出せなくなることがあります。