» 【138号】参照KEY:その1

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

■参照KEYひとつで関係表現
THデータモデルで参照KEYないしRKEYと呼んでいるデータ項目は、リ
レーショナルモデルで外部キーと呼ばれるもので、たとえば

 a.[受注#]−(受注品#*、顧客c*、届先c*、・・・)
 b.[発注#]−(発注品#*、メーカーc*、発注先c*、・・・)
 c.[品#]−(品種c*、・・・)
 d.[顧客c]−(住所c*、性別c*、・・・)
 e.[品#*.倉庫#*]−(在庫数量、・・・)
において、*をつけたものです。なおこの*はTHモデルでの記法であって、
ERWinなどでは(FK)と書きます。また[ ]内はKEYを( )内は
従属項目を示します。#は番号、cはコードと読んでください。
参照KEYは必ずKEYと対応付けられていて、これによってn対1の関係が
つけられています。たとえばa.の受注品#*は[品#]と、また顧客c*は
[顧客c]と対応づけられ、「品#=P101がn個の受注レコードに登場す
る」、また「顧客c=12345がn個の受注レコードに現れる」、のように
解釈されます。
したがって、参照KEYの組合せ、たとえば在庫エンティティを表すe.[品
#*.倉庫#*]は、[品#]と[倉庫#]の間のn:m関係を表すことにな
りますので、一般的なエンティティ間の関係(1:nおよびn:m)は、参照
KEYひとつですべて表現できると言うことになります。
■参照KEY対応の矢線
一般に人間にとって、関係の表現は図が最も分かり易いといえます。そこでT
Hモデルでは上記の関係を次のように図示します。
        [品#]    [顧客c]
         ↓        ↓
[受注#]−(受注品#*、顧客c*、受注数量・・・)
および
[品#]  [倉庫#]
  ↓     ↓
[品#*.倉庫#*]−(在庫数量、・・)
すなわち、この矢線によってKEY−参照KEYの関係およびその1:n関係
を表現するわけです。この関係情報は、リポジトリ上において参照KEY対応
に記述されたKEY情報、および図上で付加された*によってすでに表現され
ているので、矢線は図を見る人間の便宜のためだけの冗長記述と言えます。し
たがって、データモデル図を扱うツールとしてはこれを扱いますが、エンティ
ティを表す箱の位置(XY座標)などと同様に、正規のメタ情報ではないと考
えることができます。なお、この矢線はTHモデルの記法で、他のモデルでは
鳥の足と言われる書き方などいろいろありますが、いずれも有向線であり本質
は変わりません。
また、ここで注意しておきたいことがあります。それは、参照KEYは実装独
立の属性であるということです。RDBを実装する場合は90%以上、外部キー
として実装されるかと思われますが、それに限定しているわけではありません。
とくに現状分析で、IMSやCODASYL系のDBを対象にすれば、その1:n関
係は参照KEYで表現することになります。
■矢線重視のモデル
われわれは参照KEYこそメタ情報と考えるわけですが、次のように、逆にこ
の矢線相当のものをメタ情報として、参照KEYを書かないというモデルもあ
ります。
 [品#]  [顧客c]
   ↓     ↓
[受注#]−(受注数量・・・)
その場合は矢線相当が切れると、参照関係が失われてしまうので、関連するエ
ンティティタイプは常時一群としてコロニーを作っていなければなりません。
そこには通常いくつかのリソース(上例では[品#]や[顧客c])が含まれま
すが、これは他のコロニーとの共用となるため、この統合のためマージする場
合、操作が煩雑になります。
このモデルは元来、「エンティティタイプとその関係だけを把握したい、属性
には当面興味がない」とする、いわば「エンティティ原理主義的アプローチ」
を採っています(この場合THモデルは「アトリビュート原理主義的アプロー
チ」と言われます)。そして必要に応じてKEY側エンティティの役割を矢線
上に記載します。したがって、これはモデルの骨格を把握するためだけのモデ
ル図として使うべきものかもしれませんが、一般にはRDB設計のベースとす
るために、属性を追加していくことが多いように見えます。
このモデルによると、リソースがこれを参照するエンティティに従属する形式
で表現されるためか、それがリソースを独立させ一元化する動きを妨げ、孤島
システムをつくる原因となっているように見えます。
また参照KEYを書くけれども、矢線相当も必ず書くべし、というモデルもあ
ります。この場合も、コロニーを保つためマージの操作が煩雑、孤島システム
を作り易い、などの傾向は同様のように見えます。
■リソースとイベントを結ぶ矢線の省略と配置規則
受注、発注、生産などのイベントエンティティはビジネスにおける出来事を記
述し、またこれらに使われる品#、顧客c、メーカーc、などのリソースエン
ティティはその出来事を記述するための用語として位置づけられます。RDB
に実装される場合、いずれもテーブルとなるため、実装の観点でかかわるシス
テム屋にはあまり意識されないように見えますが、イベントとリソースの情報
システムにおける役割、位置づけは非常に違ったものといえます。「イベント
は個別アプリを作る、リソースは共用インフラを作る」、と言うのが最大の違
いかと思われます。
このため、最終的な統合図においては、THモデルではイベント系は個別アプ
リごとにリソースを除いてまとめ、リソース系はリソースだけを集めてデータ
モデル図を作ります。イベントの参照KEYとリソースを結ぶ矢線が記載され
なくなりますので、リソースとイベントの参照関係をトレースしやすくするた
めの配置規則をリソース図に設けます。すなわち、c.,d.の場合は
       [品種c]           [住所c]   [性別c]
         ↓               ↓      ↓
[品#]−(品種c*、・・・) [顧客c]−(住所c*、性別c*、・・・)
のように、上下に関しては、矢線が下に向かう−すなわち粒度の粗いものが上、
細かいものが下になる−ように配置します。また左右に関しては左から社内、
社外、品物、その他とするわけです。これによってリソースエンティティの配
置は、ほとんど個人差なく決まり、イベント図の参照KEYがどのリソースと
つながるかは、一般に錯綜した矢線を辿るより効率的に分かります。
配置規則は、リソース系だけでなくイベント系にも設けています。上下関係は
リソースと同様ですが、左右に関しては先行イベントが左、後続イベントが右
となるようにします。
一般の多くのデータモデル図は、「関係するエンティティタイプを近くに配置
する、空きスペースを作らない」、などを重視するものの、配置は作図者に任
せるため、同じアプリケーションを扱っても、見た目異なった成果物が作られ
ます。THモデルでは、上記の配置規則を設けるため空きスペースが生じ、図
が大きくなる欠点が発生しますが、個人差は極めて小さく、エンティティの粒
度や役割(リソースの場合)、時系列(イベントの場合)など、配置に意味が
表現されます。このため、設計者は作図において、意味を把握する必要があり、
これが却って設計者のシステム理解を助長し、結果として成果物の品質向上を
生むように思われます。
■参照KEYによる処理のトレース
データモデル図の基本は、所属するエンティティタイプを配置し、その1:n
関係を参照KEYによって記述したものと言えます。この参照KEY、したがっ
て対応する矢線相当は、エンティティタイプ間の関係という意味を表すわけで
すが、その具体的な使い道は次の2つの処理
・KEY側の従属データを結合する(上から下へ)
・参照KEY側の数量データを要約(合計/カウント/平均など)する(下から上へ)
と言えるでしょう。ここで、入庫や出庫による在庫の更新もこの要約のなかに
入れて考えることにします。
(注)この2つの処理は、11種のSPF(Schema Process Flow)処理の
うちの2つです。これ以外のものは別途解説することになります。
このような処理をデータモデル図上でトレースすることによって、加工データ
と加工元データの間の過不足・不整合が追跡でき、モデルの品質を大幅に上げ
ることができます。このような「加工元データ→加工データ」のトレースをガ
イドするデータモデル方法論は、THモデルのほかには見当たりません。
「処理はSQLを発行して、プログラム設計時に考えればよい、RDB設計時に
処理は考えなくて良い」といった理解からくるものと思われますが、いかがで
しょうか。
このような「加工元データ→加工データ」のトレースを行うと、DBに実装さ
れないデータを扱わなければならない場合がありますが、THモデルの対象は、
実装独立の概念モデルですから、これを問題にしません。実装のRDB設計に
先立って、ユーザの要求するIO上のデータ、およびこれを導出するための全
データを−DB上にストアされないものも含めて−対象に整合性をとります。
この整合性を取る際、多くの結合・要約処理が行われますが、そこで参照KE
Yが活躍することになります。
こうして、高品質の概念DB構造が得られるわけですが、これを妨げるものと
してサブタイプ問題があります。これらについては次回考察したいと思います。