» 【140号】参照KEY−その3

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

■参照KEYの役割
参照KEYの主要な役割は、イベントの中での5W1Hと言えます。

たとえば
[受注#]−(受注品#*、顧客c*、届先c*、受注担当者#*、受注日*、・・・)
においては、参照KEYがWhat、Whom、Where、Who、Whenの順に並んでいると
言えます。これはイベントが出来事の記録ですから、これにかかわるリソース
を記述する必要上当然と言えます。
また
[出荷#]−(受注#*、出荷担当者#*、・・・)
の場合は、トリガーとなった、先行イベントを表す受注#*を経由して5W1
Hが分かるようになっています。銀行における入出金のイベントも
[入出金#]−(口座#*、年月日*、・・・)
の形式となっていますが、リソース的性質を持つ口座#を、口座開設時のイベ
ント番号と考えれば、上記出荷と同様に考えられます。
この参照KEYの役割は、属性が意味を表すための主役と言えますので、矢線
を重視するモデルでは、この役割を矢線に併記するものが少なくありません。
リソースにおける参照KEYの役割は、分類がほとんどです。前々回に挙げた
事例
 c.[品#]−(品種c*、・・・)
 d.[顧客c]−(住所c*、性別c*、・・・)
における、品種c*、住所c*、性別c*などその典型と言えます。この分類
もリソースですから、さらに粗い上位の分類を、何階層も持つ場合があります。
(注)この住所c*をWhereを表すもの、また社員#に従属する入社日*を
Whenを表すもの、とする見方もありえますが、リソースの属性ですから、やは
り前者はマーケット分類、後者は社員分類と考えるのが自然だと思われます。

■属性の役割
参照KEY以外の属性も役割を持っているわけですが、この属性の役割に関す
る研究は見当たりません。わたしも研究途上で、次の11個の大分類が設定で
きそうだ、と考えているところです。
                 事例
 1 識別(Identification) K [顧客c]、[受注#]
 2 分類(Classification) R 住所c*、性別c*
 3 状態(Status)    X 顧客化状態c、受注処理状態c
 4 先行(Antecedent) R  受注#*
 5 時点(Timing)    R  受注日*
 6 場所(Location)   R  届先c*
 7 担当(Party)     R  受注担当c*、顧客c*
 8 対象(Object)    R  受注商品c*
 9 方法(Means)    R  支払方法c*
10 数量(Quantity)   X  顧客年齢、受注数量
11 備考(Remarks)   X  顧客名、摘要
ここに、K:KEY、R:参照KEY、X:その他(数量やテキスト)が表す
ことを示す。
このように属性が意味を表す点に関して、参照KEYの果たす役割が大きいこ
とが分かります。この大分類に続く中・小分類はまだ研究中です。意味は人間
にしか判定できないため、定式化が難しい領域ですが、データモデルの効率的
な品質向上に有効活用できると考えています。

■整合性チェック
参照KEYの値はKEYとして定義されたものでなくてはなりません。これを
参照整合性の制約と言いますが、DQ(Data Quality)のための重要な条件に
なります。たとえば、品#*としてP01、P02、・・・が定義されていた
とき、受注品#の値はこの中になければなりません。しかしこのチェックは、
本来P01となるべきものがP02となっていても、その誤りは判定できませ
ん。形式のチェックであって意味のチェックではないからです。意味のチェッ
クは結局人間でなければできません。したがって、万全ではない形式チェック
の方式については、費用対効果を考えて、有効なチェックはどこまでかを考え
ることになります。
社員性別c*や顧客性別c*をわれわれは[性別c]に対する参照KEYと考
えますが、[性別c]を省略して、単にこれらを値(M、F)あるいは(1、
2)から成る定義域/ドメインに対応付けて考える人もいます。意味を考えず、
形式だけ考えれば良いという考え方かと思われます。エンティティの意味より
も形式の重要性の方が大きいという考え方から来るものかと思われます。
われわれもXXフラグ=(Y、N)または(1、0)となると、形式として扱
うことになります。意味を配慮したエンティティタイプとするか、形式のみの
ドメインとするかの基準については今後の検討に待つべきところかと思われま
す。
以上3回にわたって、データモデルの中核を形成する参照KEYについて述べ
ました。データモデルを扱う人は誰しもエンティティ間の1:n、1:1、あ
るいはn:mなどの関係を論ずるわけですが、それを実現している参照KEY
にまでは気をつかわず、DQ(Data Quality)に問題を残す場合が多いので要
注意です。とくに加工データと加工元データが別エンティティのしかも特定の
サブタイプに属する場合に、トレースを怠って整合性が甘くなるようです。こ
れらを紐付けている参照KEYを意識してトレースすることによって、品質が
上がり、プログラム設計時になっての項目追加などが防止できますので、心掛
けていただきたいと考えます。