» 【139号】参照KEY−その2

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

■KEYかつ参照KEYによる1:1の表現
いま営業部は、
[顧客c]−(顧客名、口座#*、顧客ランク*、与信限度額)
のような顧客ファイル(注1)を使っており、

また購買部は
[仕入先c]−(仕入先名、口座#*、技術グレード*)
のような仕入先ファイルを使っているものとします。
また、両者はコード体系が違っており、
顧客c=A、B、・・と仕入先c=M1、M2、・・には、目下重なりがなく
別々の会社だとします。
(注1)正しくは顧客エンティティと呼ぶべきですが、現状の話としている
ため、分かりやすさのため顧客ファイルと言うことにします
(ファイル→エンティティは以下同様)。
しかし、経理システム再構築にあたり、両者とも取引先であり、将来を考えて
統合するものとします。
直ぐに全面再構築と言うわけにも行かないので、数年はこのファイルを使い続
けるアプリケーションが残る(注2)として、次のようなファイル構造とします。
[取引先c]−(取引先名、口座#*、取引先区分c*)
[顧客c]−[取引先c*]−(顧客ランク*、与信限度額)
[仕入先c]−[取引先c*]−(技術グレード*)
すなわち、顧客名、仕入先名は顧客名とし、口座#とともに取引先ファイルに
引き取らせ、顧客か仕入先かを判別するサブタイプコードとして、取引先区分
cを追加します。顧客ファイル、仕入先ファイルには代替KEYとして取引先
c*を追加します。この取引先c*はKEYかつ参照KEYの性質を持ちます。
参照KEYですが、通常のものと違って、1:nではなく常に1:1の関係を
表します。
(注2)このレガシーアプリケーションがなくなれば、
[顧客c]や[仕入先c]は消去します。

■排他の場合、共存の場合
そして、KEY値の対応は次のようになるとします。
 取引先c 顧客c 仕入先c
 11   A    −
 12   B    −
 21   −   M1
 22   −   M2
この場合、顧客と仕入先は排他的ですから、顧客および仕入先を取引先の排他
サブタイプとして表すため、図としては大略(テキストしか扱えないため)次
のように、矢印のない線で繋ぎます。
[取引先c]―・―――――――――――――――・
        |取引先区分c=顧客         |取引先区分c=仕入先
[顧客c]−[取引先c*]        [仕入先c]−[取引先c*]
いまここで、取引先c=21が顧客にもなったとします。すると顧客と仕入先
の関係は排他ではなく共存になりますから、先の取引先区分cの代わりに顧客
フラグ、仕入先フラグを用意し、図は次のように変わります。
[取引先c]―――――――――――――――――・
        ―・                     |
         |顧客フラグ=Y            |仕入先c=Y
[顧客c]−[取引先c*]         [仕入先c]−[取引先c*]
このように同じエンティティタイプ内のサブタイプを表すKEYは、排他・共
存にかかわらず、同時に参照KEYでもあり、1:1関係を表します。これは
意味的には、取引先、顧客、仕入先、がほぼ同じ粒度であることを意味します。
このためTHモデルでは線を横に出して図での上下のレベルがなるべく同じに
なるようにしています。
以上のように、THモデル図では「KEYと従属属性によって作られる1:n
の関係」と、「KEY同士によって作られるサブタイプにおける1:1の関係」
を峻別しますので、図上にカーディナリティは表示しません。n≦5などの規
定がある場合はデータ定義書に記述します。

■エンティティタイプとサブタイプ間の処理
いまあるエンティティタイプに着目していて、特定のサブタイプに絞ったアク
セスをしたい場合は、サブタイプcと値を指定して、抽出処理を行います。逆
にサブタイプ側から、エンティティタイプ全体をアクセスしたい時は、マージ
処理を行います。またサブタイプにおいて、エンティティタイプの属性にアク
セスしたい場合は、サブタイプ側のKEYかつ参照KEYにより、通常の結合
処理をすることができます。

■サブタイプ識別の基準
先回の事例
a.[受注#]−(受注品#*、顧客c*、届先c*、・・・)
における、届先c*がどのようなKEY項目と対応すべきかについて考えて見
ます。簡素なアプリケーションでは、上記[顧客c]−[取引先c*]と同一
とする場合があるでしょう。しかし複雑なアプリケーションでは、顧客は本社
を指し、届先は各地にある工場や店舗などであって、届先を物流に関する属性
を持つやや粒度の小さい顧客あるいは取引先のサブタイプとして定義する必要
がありそうです。
イベントにおける参照KEYの役割は、顧客c*は支払責任者、届先c*は納
入場所として「決まる問題」でありはっきりしているわけですが、KEYの果
たすべき役割をどこまで持たせるかは、設計者による判断の入る「決める問題」
になるため曖昧になります。社員なども、イベントごとにいろいろな役割を果
たし、それに対応した属性を持ちますので、これに着目してサブタイプcと値
を指定して、サブタイプを識別しても限がありません。一般にリソースをイベ
ントにおいて果たす役割ごとに精密に分析し、サブタイプを定義しても、実際
のメンテナンスが追いつかず却って品質劣化の原因となりますので、データ管
理負荷とのバランスを考慮して、サブタイプを定義する必要があります。

■粒度が異なる場合
以上のような事例とは反対に、同じエンティティタイプの中に粒度の異なった
ものが混在し、粒度の大きいものと小さいものとの間に、1:n関係がある場
合があります。たとえば、部、課、係を部署として一括した場合などです。こ
のときのファイル形式は
[部署c]−(部署名、親部署c*、レベルc)
のような再帰的な参照KEYである親部署c*が、粒度を表すレベルc(省略
されることも多い)とともに入ることになります。この場合レベルの異なる部
署は一種のサブタイプ、レベルcがこれを区分するサブタイプcと考えること
もできますが、一般に従属項目がほとんど同じため、サブタイプとして扱う意
味がないようです。またこの場合は原則として階層の数に制限がなくなります。

■複数個の参照KEYの組み合わせが作る参照KEY
以上1個の参照KEYの事例を見てきましたが、n個の参照KEYが組み合わ
さって1個の参照KEYとして働く場合があります。たとえば、
[品#*.届先c*]−(倉庫#*)
  ↓
[受注#]−(受注品#*、顧客c*、届先c*、・・・)
において、この受注の引当をどの倉庫の在庫に対して行うべきかを考えます。
ビジネスルールは品物と届先の組によって、出荷倉庫が決まるとしていますの
で、この組が参照KEYとなります。したがって正確には次のように書くべき
です。
[品#*.届先c*]−[<品届c>]−(倉庫#*)

[受注#]−(受注品#*、顧客c*、届先c*、<受注品届c>*・・・)
ここに[<品届c>]は品#*と届先c*を組合せて作った代替KEY、また
<受注品届c>*は、受注品#*と届先c*を組合せて作った参照KEYとする。
また<>は加工データを示すマーク。
これは、「参照制約の観点から、ひとつの意味の1:n関係は、ひとつのKE
Y−参照KEY関係によって表現されるべき」という原則に立つからです。た
だしデータモデル図を人間が見て活用している場合は、読み手がこれを補って
読めるので、一般にこの記述を省略することができます。この省略は、つぎの
ような出荷イベントをサマリして要約ファイルを作る場合にも良く使われます。
[品#*.顧客c*.年月*]−(<売上¥>)
  ↓
[出荷#]−(品#*、顧客c*、出荷年月日、倉庫c*、出荷担当c*、<出荷¥>)