2004年11月 1日 作成 エンティティ と テーブル >> 目次 (作成日順)
2008年12月 1日 補遺  


 
テーブル (table) と エンティティ (entity) は、ちがう概念である。

 コッド 関係 モデル は、「テーブル を、直接に操作できる人」──エンドユーザ もふくめて──が使うことを前提にしているのではないか、と私は思っています。

 コッド 関係 モデル では、個々の タプル (テーブル) は、まったく独立であり、「或る テーブル のなかの属性 a と、ほかの テーブル のなかの属性 b は、『現実の世界のなかで』 同じ エンティティ に帰属する」 という情報は、データ 構造のなかには、記述されていないのです。
 そういう情報は、「テーブル に対する操作」 としてしか示すことができない。つまり、複数の タプル にまたがる属性を合成して、情報を作るしかない。その合成の鍵が、reference-key であり、操作 (データ 演算) の join です。
 たとえば、書物という モノ に対して、以下の テーブル がある、とします。

  書物 テーブル { 書物番号、書物名称、出版年度、作者 コード (R) }.
  作者 テーブル { 作者 コード、作者名 }.

 
 データ 構造としての書物 テーブル は、「現実の世界のなかの エンティティ」 ではない。
 データ 構造としての書物 テーブル は、「現実の」 書物を記述してはいない。したがって、「現実の」 書物を記述しようとすれば──「現実の」 書物の情報を得ようとすれば──、作者 コード を使って、2つの テーブル を合成して、以下の テーブル を生成しなければならない。

  { 書物名称、作者名称、出版年度 }.

 
 同じように、受注伝票は──合計値をふくむ受注伝票は──、複数の テーブル を合成した テーブル として示さなければならない。

 
エンティティ (entity) を、すでに知っている人が、テーブル (table) を合成できる。

 コッド 関係 モデル の 「考えかた」 は、「論理 モデル」 として、構造の整合性を実現することが目的であって、操作そのものは、「概念」 を知っている人を前提にしているのではないか、と私は思います。

 「『概念』 を知っている人」 として、(「概念設計」 のなかで事業過程を調べた) 「システム・エンジニア」 を考えるか、あるいは、(エンドユーザ が SQL を習得して、) Dynamic SQL を使って テーブル 群を合成 (join) する──情報を生成する──「エンドユーザ」 を考えるか、、、。

 
 ちなみに、T字形 ER手法では、テーブル に近い集合を、エンティティ と云っています。
 その理由は、T字形 ER手法は、SDLC の 「溝」 を排除するために、概念設計と論理設計を、1つの手法で、同時に実現することを狙っているからです。

 



[ 補遺 ] (2008年12月 1日)

 4 年前に綴られた本文を今読み返してみて、論法が 「論点先取り」 に陥っていることに気付きました (苦笑)。
 というのは、本文のなかで 「エンティティ (entity) を、すでに知っている人が、テーブル (table) を合成できる」 と綴っていますが、システム を設計する段階で、テーブル のなかに、すでに、reference-key を指示しているので、デーブル 構成では、そもそも、テーブル 間の 「join の 道 (path)」 が確定されているので、entity を合成する道は あらかじめ示されています。

 そうだとすれば──設計段階において、「path」 が固定されるとすれば──、設計は エンドユーザ が実施すれば良いということになりますね (そして、私は、その やりかた を強く推奨します)。

 コッド 関係 モデル も TM (T字形 ER手法の改良版) も 「論理的意味論」 に属する モデル です。ふたつの モデル を説明する理論は、それぞれ、数学基礎論 (および、言語哲学) を知らないと理解できないのですが、それらの理論を前提にした 「設計の 『手続き』」 は、いずれの モデル も、とても単純な テクニック なので──そして、いずれの モデル の テクニック も、コンピュータ の知識がなければ使えないという テクニック ではないので──、エンドユーザ も使える テクニック です。とすれば、事業過程・管理過程を知っている──特に、データ のあいだに付帯した制約・束縛を知っている──エンドユーザ が設計すれば良いとふうに考えるのは当然でしょう。ただ、もし、エンドユーザ が、そうするための時間を割り振るのが困難であれば、かれらの代わりに システム・エンジニア が設計すれば良いということです。システム・エンジニア が設計するとしても、あくまで、「代行」 であって 「主役」 ではないという自覚がなければならないでしょうね──そういう自覚 (「事実」 を前提にした自覚) を持っていないと、システム・エンジニア が、事業過程・管理過程を知り尽くして設計できるなどと思い違いしてしまうので (あるいは、自惚れてしまうので)。

 本文のなかで、もうひとつ訂正しなければならない点は、「T字形 ER手法は、... 概念設計と論理設計を 1つの手法で同時に実現することを狙っているから」 としている点です。というのは、この点は、コッド 関係 モデル でも同じです。およそ、「論理的意味論」 であれば──言い換えれば、「モデル (modeling)」 であれば──、その接近法になるのが当然です。

 TM では、entity という語と object という語が使われています。
 Entity は、TM では、以下のように定義されています。

  Entity である = Df 個体指定子が付与された対象である。

 そして、個体指定子 (entity-setter) として、コード 体系のなかで記述されている管理番号 [ ××番号、×× コード ] を使います──たとえば、商品番号とか従業員番号とか受注番号とか契約書番号など。

 TM では、entity に対して 「関係」 文法を適用して 「形式的構成」 を作ります── TM は、実体主義的 「個体」 に対して関係主義的 「文法」 を適用するという体系になっています。そして、entity をもとにして構成された 「表 (リスト)」──すなわち、対応表、対照表および再帰表──は、object とされます。なお、object は、「集合 オブジェクト」 と 「組 オブジェクト」 という ふたつの クラス に類別されます。ただし、現時点では、「L-真」 の対照表 (「制約・束縛」 を示す対照表) ならびに アトリビュート・リスト の 「前提」 欄に記述される 「制約・束縛」 および 「計算式」 欄に記述される ロジック (アルゴリズム) を entity に対して カプセル 化しない。勿論、TM で構成された形式的構造に対して、オブジェクト 指向言語を使って アクセス するのであれば、データ と演算 (および、制約・束縛) を カプセル 化しても良いのですが、システム 作りで実地に使われている データベース が リレーショナル・データベース なので、現時点では、カプセル 化をしていない次第です。





  << もどる HOME すすむ >>
  ベーシックス