このウインドウを閉じる

  ● QUESTION   テーフ゛ル のなかの カラム (フィールト゛) が null 値であってはいけないのは、どうしてか。
  ▼ ANSWER   RDB の理論 (セット・アット・ア・タイム 法) が成立しなくなるから。


 

 セット・アット・ア・タイム 法は (数学の) 直積集合を根底にした 「データ・アクセス の技術」 である。
 E. F. コッド 博士が提示した 「数理 モデル」 である。
 それぞれの セット (あるいは、domain) から 1つの メンバー を選んで並べた集合のことを 「tuple (集合)」 という。この点については、前回 (176 ページ) の ベーシックス 「整列定理と選択公理」 のなかで述べた。
 直積集合の一般式は以下の式として記述される。

 R = { s1, s2, ..., sn | s1 ∈ X1, s2 ∈ X2, ・・・ , sn ∈ Xn }.

 (s1, s2, ・・・ , sn) が 「tuple (集合)」 である。
 つまり、relation (関係) のなかから、関数 [ tuple (整列集合)] を生成する。

 さて、従業員番号の セット (集合) と従業員名称の セット を使った直積集合を以下に記述する。

  R = { 001 ∈ 従業員番号, A ∈ 従業員名称}.
  R = { 002 ∈ 従業員番号, B ∈ 従業員名称}.
  R = { 003 ∈ 従業員番号, C ∈ 従業員名称}.

 直積集合では (それぞれの セット から 1つずつ メンバー を選んで並べるので) セット は 「縦列」 として記述されている。
 RDB は、データ の定義および データ の操作に対して、SQL という言語を使う。
 SQL は 「I/O 言語」 である。4世代言語のような簡易言語ではない。

[ 参考 ]
 データ を定義するための言語を DDL (Data Definition Language) という。
 (SQL では、典型的には、「CREATE」 文の記述のことをいう。)
 データ を操作するための言語を DML (Data Manupulation Language) という。
 (SQL では、典型的には、「SELECT」 文の記述のことをいう。)

 直積集合を使って 「縦列」 に セット が記述されているので、「I/O 言語」 である SQL を使った データ・アクセス は 「縦列 (column 単位)」 の アクセス となる。SQL (つまり、RDB) は、一度に 1つの セット (あるいは、view として複数の セット) を走査するので、「セット・アット・ア・タイム (set-at-a-time) 法」 という。

 ただ、セット・アット・ア・タイム 法では、以下の 2点が弱点となっている。
 (1) 順序対
 (2) null

 直積集合では、主体は記号化されている、という前提に立っている。たとえば、「従業員」 の集合の代わりに、従業員番号の集合、「部門」 の集合の代わりに部門 コード の集合というふうに考える。属性値集合は アトム 的 (atomic) でなければならないとされ、属性値として、値のみが対象となる。
 ただ、「関係 (ファイル)」-- tuple (レコード) の集まり(テーブル)--は、事業のなかでの 「並び」 が論点になる。コッド 関係 モデル では、テーブル のあいだの関係は 「包摂関係」 として考えられている (A ⊃ B、あるいは A ⇒ B)。
 たとえば、「従業員」 の テーブル と 「部門」 の テーブル を考えてみれば ] 以下の 「並び」 には、「意味的な」 相違点はない(つまり、同じ意味である)。

 (従業員, 部門) (部門, 従業員)

 いずれも、「配属」 という同じ意味として解釈できる。
 しかし、以下の例では 「並び」 が相違すれば 「意味」 も相違する。

 (出荷, 請求) (請求, 出荷)

 (出荷, 請求) は 「出荷してから代金を回収する (後払い)」 ことを意味して、(請求, 出荷) は 「入金を確認した後、出荷する (前払い)」 ことを意味している。1つの 「数理 モデル」 として データ 構造を提示した セット・アット・ア・タイム では、(実際の 事業過程・管理過程 のなかで使われている データ を代入値としたら、) 関係 (テーブル) の 「順序対」 が論点になる。

 さて、もう 1つの弱点である 「null」 は、以下のような例を提示できる。

 R = { 004 ∈ 従業員番号, null ∈ 退職日}.

 従業員 (従業員番号、004) は退職していないので、退職日は null になるが、null は、退職日の集合の メンバー ではない──なぜなら、退職日の集合は空集合ではないから。
 コッド 関係 モデル では、null は、「値が成立しない」 という意味で使われるが、現実の指示関係から判断すれば、null は、unknown と undefined の 2つの意味が成立して、「多義」 になる。そのために、コッド 関係 モデル では、(null に対応するために) 4値 ロジック を使う。4値 ロジック を使えば、null を、意味論上、対応できるが、はたして、4値 ロジック が実地の演算として使いやすいかどうかは、争点になる。

 以上のようにして、「数理 モデル」 の セット・アット・ア・タイム 法を実地に使おうとするのなら、関係の 「順序対」 と属性値の 「null」 に対して、対応策を用意しなければならない。T字形 ER手法では、「順序対」 に対する配慮として 「resource と event」 という概念を導入して、「null」 に対しては、2値 ロジック を前提にして、「相違の サブセット」 という概念を用意した。

[ 参考 ]
 多価関数は数学では一般に考えない。x ∈ X1 について、X2 の メンバー y1, y2, ・・・, yn を対応するのなら、f: X1 → P (X2) として、X1 から P (X2) への一価関数を考える。つまり、部門 コード は従属関数である。以上の考えかたを セット として記述すれば、{ 従業員番号、従業員名称、 ・・・, 部門 コード (R)、...} となる。
 T字形 ER手法が、従属関数を 「個体と関係は同一 レベル にある」 と考えて 「対照表」 を使って記述する理由は、T字形 ER手法は (述語論理の公理系ではなくて) 命題論理を使った体系になっているからである。
 述語論理の公理系も命題論理の公理系も、いずれも、無矛盾性と完全性を証明されているので、いずれを使っても良い。
 ただ、少なくとも、直積集合を使うなら、「順序対」 と 「null」 は、なんらかの対応をしなければならない。

 




  このウインドウを閉じる