» 【第108号】属性の意味

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

百日紅の紅が夏の終わりを告げ、朝夕すこししのぎやすくなりました。私は
鳥海山に行って、無理をして腰を痛めて帰ってきましたが、皆様この夏は
いかがでしたでしょうか。
このところ、学生やプログラム開発しか経験のない、データに関しては素人
の方にデータモデリングの説明をする機会が多く、これを自分の課題として
おります。そのとき、「システムとはプログラムの寄せ集めではない、むしろ
属性と属性間の関係の集まりである」という気持ちを伝えるために、次の
ような式を書いています。うまく通じますかね。
 SY≠ΣPG
 SY=ΣD*D (Dは属性/データ項目、*は関係のつもり)
なお、法政大学・イノベーションマネジメント科の公開講座(無料・18時30分
―20時)[データ中心アプローチによる情報システム分析・設計]後期は、
10月4日から1月17日まで12回行うことになりました。お申し込みは同科
の溝口教授のホームページhttps://www.hosei.org/kouza/S059001.php
をご参照ください。
(追記:既に申し込みは締め切っております。ありがとうございました。)


■A2Aでのデータ流通
先の107号で、「データ流通は、P2P(Program to Program)、A2A
(Application to Application)、B2B(Business to Business)に分けて考えら
れ、かつA2Aのデータ流通が孤島システムとして大きな問題となっている」
と述べました。P2Pは同じアプリケーションの中なので、コミュニケーション
がとりやすく、また歴史が長く、パッケージの活用も可能となっており、一方
B2Bは、A2Aに問題を抱えている企業にとっては、まだ取り組みにくい、
などが理由です。
この業務横断のA2A問題を解決する鍵は、異なった文化の間のコミュニケ
ーションにおける「やりとりされるメッセージ(トランザクション、イベントレコー
ドに同じ)に含まれる属性の意味の確定である」と考えられますので、以下
事例を用いて考察いたします。

■事例研究
n個のアプリケーション・システムがA2Aの汎用的通信場(DB)によって、
コミュニケーションすることを想定しますが、事例としては生産系のSYS1と
営業系のSYS2の2つが生産完成のメッセージをやり取りするものとします。
SYS1は最近購入したパッケージであり、SYS2は20年来のレガシーシス
テムを想定します。それぞれ異なった文化のもとに開発されていますから、
エンティティ、属性、属性値などに関する規則が異なっています。このメッセ
ージを素直に書き下すと次のようになるものとします。ただし、説明のしやす
さのために、メッセージをXMLの形式で記述します。
SYS1.生産 SYS2.営業  
<完成>103 <生産>A103
 <品>P15</> <商品>Q015</>
 <数>20</> <数>20</>
 <日付>20050831</> <製造日>20050831</>   
 <工場>A</> <生産拠点>A</>
 <倉庫>3</> <流通拠点>S3</>
</> </>
タグ名の違いは属性の違い、値の違いはコード体系などの違いを表している
ものとします。SYS1とSYS2だけのデータ流通を解決するのならば、安直な
変換でよいのでしょうが、今は、n個のアプリケーション・システムが汎用的
通信場−これをSYS.A2Aとします−を介してコミュニケーションするために、
次のようなメッセージに変換されるものとします。
SYS.A2A
<イベント>生産A103 ←イベント一般を扱うため
 <品>RA015</> ←n事業部の部品を含めて扱うため
 <数量>20</> ←KG単位も扱うため
 <単位>ケース</> ←同上
 <発生日>20050831</> ←他の日付と区別するため
 <自組織>FA</> ←イベント一般を扱うため
 <至組織>S3J</> ←同上
</>

■必要な規定
このような変換が可能になるためには、上記「←」による説明のほか、SYS.
A2Aのエンティティ、属性、および属性値に関して次のような規定が必要に
なります。
・ エンティティ「イベント」として生産、受注、引当、出荷、購買などが含まれる
こと、そしてこれらを区分するコード、また番号体系。
・ 品の当該メッセージにおける役割(「・・を」など)、および参照先のリソース
エンティティのKEY属性識別子([品番]など)、その粒度(色や包装仕様
まで含むかなど)や範囲(スペアパーツやサービスまで含むかなど)。
・ 自組織や至組織の当該メッセージにおける役割(「・・が」、「・・へ」など)、
および参照先のリソースエンティティのKEY識別子([取引先コード]、
[組織コード]など)、その粒度(法人レベル/事業所レベル/個人レベル
など)や範囲(関東、国内、海外など)
逆にこのような規定/標準があり、これへの変換が行われるならば、パッケ
ージやレガシーがどのような文化−属性や属性値/コード体系、この前提
となったデータモデルや各種DOAやOOの開発方法論−に基づくかに頓着
することなく、必要なデータ流通を実現することができます。
ここで注意しておきたいことは、メッセージの意味を正しく伝えるには、これに
関連するリソースエンティティが何か、粒度や範囲を含めた規定の重要性です。
従来はコミュニケーションの相手がほぼ固定的であったため、「いつものあれ」
として属性名さえ分かれば誤解は生じなかったわけですが、ビジネスの変化
はコミュニケーション相手の変化を招来しますので、これに迅速対応するため
の配慮が、最近とくに必要とされるようになってきたことです。
なおこの事例には加工データが含まれていませんでした。生産A103により
品RA015が数量20ケース作られ、至組織S3Jに送られるならば、在庫は
20個増えることになります。この加工データ「在庫数量」はSYS.A2Aの通信
場で更新されることになりますので、これと「数量」との関係はSYS.A2Aの
属性定義として規定される必要があります。ただしメッセージとして送られて
くる加工データ、たとえば生産A103に製造原価が含まれていたとしても、
これはSYS1内の加工データとしてSYS.A2Aは関知しないことになります。

■まとめ
こうしてA2Aにおけるメッセージ(P2Pにおけるロウレベルメッセージに対して、
これをハイレベルメッセージと言う)および、これから導出される在庫や要約に
含まれる属性の意味が確定すれば、各アプリケーションシステムは、適宜必要
な変換を施して、自由にコミュニケーションできることになります。そのとき個々
のアプリケーションが、どのようなモデルや方法論で開発されたかを問題にする
必要はありません。それはちょうどわれわれ人間が、お互いその生い立ちや
価値観・文化を知らなくても、取引を含む種々の社会生活を支障なく行うことが
できるようなものと考えられます。