» 【122号】参照KEYの意味論

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【122号】参照KEYの意味論

われわれのTHモデルの中では、参照KEYはきわめて重要な役割を占めてい
ます。リレーショナルモデルにおける外部KEYと同じものと理解されておら
れる方も少なくないと思われますが、このため多くは意味論的な問題から、こ
れに起因した誤解も発生するようです。そこで参照KEYについて整理してみ
ます。

■参照KEYは実装独立
参照KEYは実装独立の属性のひとつです。外部KEYはリレーショナルテー
ブルのカラムと解釈されていますから、実装従属であり、この点は大きく異な
ります。レガシーシステムにはまだIMSやADBSなどが残っており、この
アプリケーションのAsIs分析をすれば、1:n関係がポインターなどで実
現されているわけですが、その概念モデルは参照KEYによって表現すること
ができます。外部KEYはこの用途には不向きでしょう。P. P. Chenが指摘し
たように、外部KEYはやはり実装従属の部品と私は考えます。私はかつて
(30年ほど前)Codd Pointerと言う意味で、これをCPTRとして分類して
いました。
ひとつの参照KEYはKEYと対応させることによって、1:n関係を表現す
るわけですが、n:m 関係は2つの参照KEYによって表現できます。いま
次のようなエンティティレコード
[受注#]−(顧客#*、届先#*、品#*、数量、金額、受注担当者#*、
受注年月日、・・)
があったとすると、任意の二つの参照KEYの組、たとえば、顧客#*(#は
番号の意、*は参照KEYの意)と品#*、届先#*と品#*、顧客#*と受
注担当者#*、などはすべてn:m 関係を表すことになります。したがって
関係表現のための素材として、データモデルとしては参照KEYだけ用意すれ
ばよい、と判断しました。すなわち関係表現に関して、参照KEY一元論を主
張したことになります。一方、P. P. Chen は当初「関係は1:nもn:mも
すべて菱形で書く」という、いわば菱形一元論を主張していましたから、これ
に対比できるかと思います。
実装独立の概念モデルを考えるとき、到達点は同じでもこれを何から考えてい
くか人によって異なり、微妙な差が生ずるかに見えます。E. F. Codd はテー
ブル状の記憶媒体を前提にして、実装独立を拒否(少なくともある実装方式を
否定)したかに見えます。P. P. ChenはDBMS独立の記憶形式を意識して、
実装独立を考えたように見えます。筆者は実装独立の概念DBは、コンピュー
タ化以前から存在するものと考え、画面・帳票のレコード形式を正規化したも
のとして捉えようとしました。
■参照KEYの種類と意味
リソース系に現れる参照KEYは、ほとんど分類を表すものです。たとえば、
[顧客#]−(顧客名、性別c*、所属会社#*、・・)
における、性別c*(cはコードの意)、や所属会社#*は顧客の分類を表す
といえます。
一方イベント系に現れる参照KEYの多くは、
[受注#]−(顧客#*、届先#*、品#*、数量、金額、受注担当者#*、
受注年月日、・・)
における、顧客#*、届先#*、品#*、受注担当者#*などで、誰から、ど
こに、何を、誰が、などいわゆる5W1Hを表す、イベントにおけるリソース
の役割を表す参照KEYです。これを筆者は「関与のリソース」と呼んでいま
す。このほか
[出荷#]−(受注#*、出荷日、出荷数量、・・)
における受注#*のような「先行イベントを表す」参照KEY、後述する在庫
更新や要約のための参照KEYがあります。
■定義域との違い
上述受注エンティティの中の顧客#*や品#*は、正しくは受注顧客#*、受
注品#*と言うべきもので、KEYとしての顧客#や品#とは別物、別の属性と
考えます。これらを同一視する、すなわち顧客#と受注顧客#*は同じ、また
品#と受注品#*を同じとする考え方は、その形式と値のみを考えており、上
述した役割や意味を捨象した考え方になります。これはデータ項目を定義域と
してみる見方と言いますが、これは実装に携わる人に多い見方のように思われ
ます。われわれはデータモデルにおいて意味を把握する必要から、データ項目
を属性として扱うべきとしています。また、社員評価がA、B、Cであること
は公知でも、社員Sさんの評価がCであることは機密ですから、セキュリティ
の観点でも属性定義が必要と考えます。属性は必ずあるエンティティタイプに
属しますので、
 属性←→エンティティタイプ*定義域*役割
のような関係があります。
■参照KEYによる操作
1:nを表す参照KEYによって、結合(Join)、および要約(Sum、合計・
カウント・平均など、在庫更新もこれに含める)が行われます。矢線はKEY
側から参照KEY側に向かうので、結合は図の矢線の方向へ、また要約は矢線
とは逆向きに行われます。THモデル図では、エンティティタイプの箱を、矢
線が上から下に向かうようにレイアウトすることになっているため、結合は上
から下へ、要約は下から上へと行われることになります(統合図ではリソース
は別図になり、矢線が省略されますが、リソース図が上になるものと解釈しま
す)。さきの受注エンティティの場合ですと、届先#*によって、届先名、住
所を、また品#*によって品名、標準単価、などが結合されてきます。いわゆ
る「マスター参照」です。この場合届先#*と顧客#、また品#*と品#はD
B設計時にリンクされ、リポジトリ/ディレクトリに登録されているはずです
から、実行時にこれを結びつけるSQLの仕様は理解できません。
■複合的参照KEYによる操作
先の受注エンティティから、顧客別品#別月別受注数量を求める問題を考えま
す。答えは
[顧客#*.品#*.年月]−(受注数量)
の要約エンティティの形式をしていますから、受注エンティティの顧客#*、
品#*、受注年月日から、これらを連結した1個の複合的参照KEY、いわば
(顧客#・品#・受注年月)*をつくり、これをもとに要約操作を行って、受
注数量を求めることになります。
このような複合的参照KEYは複合的KEYと対応させるためにしばしば作ら
れます。たとえば、先の受注に基づいて引当をする場合を考えます。いま倉庫
がn個あり、届先と品#によって、出荷倉庫が決まるものとします。当然在庫
は倉庫別に管理されていますから、在庫エンティティのKEYは[品#*.倉
庫#]となります。したがってそのときの引当操作は
(1) 複合的参照KEY(届先#・品#)*によって倉庫#を結合する
(2) 複合的参照KEY(品#・倉庫#)*によって在庫更新し、在庫s
(sはステイタス、在庫切れか否かを表す)を計算する
(3) 複合的参照KEY(品#・倉庫#)*によって在庫ステイタスを結合
し、受注s(sはステイタス、引当可か否かを表す)を計算する
のようになりますが、データモデル図上では次のようになります。
[届先#*.品#*]−(倉庫#*) [品#*.倉庫#*]−(在庫数、在
庫s)
  | ↓(1)            | ↑(2) ↓(3)
  ↓                 ↓
[受注#]−(届先#*、品#、(届先#・品#)*、(倉庫#*)、(品#・
倉庫#)*
       受注数量、受注s、・・)
ここに、(倉庫#*)は(1)によって結合されてきた冗長項目を意味する
THモデルにおける参照KEYは、このようにデータモデル図上で、処理をト
レースする場合の主役を務めるわけですが、多くのデータモデリング手法にお
いて、在庫エンティティと入庫や出庫との関係線を描かないなど、結合や要約
処理に矢線を活用することが、まだ行われていないように見受けられます。デー
タモデルを単にRDBのテーブル設計の手段に終わらせるのでは非常にもった
いないもののように思われます。
(注)サブタイプやサブストラクチャのKEYは、KEY機能に合わせて参照
KEY機能を持ち、抽出、マージなどの操作と関係しますが、やや煩雑になる
ため、今回は省略しました。