今回はDAMAインターナショナル日本支部会長にわざわざ東京からお越し頂いての勉強宴会となりました。本当にありがとうございました。生ビールサーバもありませんので、普通の勉強会になってしまった感はありますがご容赦下さい。環境に順応して華麗に変化する、しぶとく生き残る勉強宴会を目指しておりますので今後ともよろしくおつきあい願います。
参加者は14名、2次会は9名、3次会は5名だったのですが用事で勉強会に参加出来なかった方１名が合流されました。4次会は6名。ここでもまた何故か1人抜けて1人増えました(笑)上流工程設計をネタに明け方まで楽しく騒ぐ事が出来ました。ありがとうございました。
＜今回の勉強会資料＞
Kwansai-IT-Benkyo-Enkai_2012-03-19-matsumoto.pdf
＜フィールド間の整合性に関する「双方向性問題」を考える＞
ディービーコンセプト 渡辺幸三さんデータ項目の妥当性検査の事を、バリデーションチェックと言います。例えば「受注数は０より大きい事」というような入力規則の事です。このバリデーションチェックには、他の項目との関係で表現されるものもあります。
例えば、「a1はa2より小さい」「a2はb2の倍数」などです。後者はチェックするための項目が他のテーブルにある例です。
※勉強宴会内では、「10倍」でしたが導出項目と勘違いされないように変更しました。
これらの整合性は裏返しの制約とみることも出来ます。
「a1はa2より小さい」→「a2はa1より大きいか等しい」
「a2はb2の倍数」 →「b2はa2の約数」
b2を変更すると、b2とa2の整合性がくずれてしまいます。それを防ぐために、プログラムで煩雑なコードを書く事が多いでしょう。「仕様書で動く業務システム」であるXEAD Driverの機能追加を考えている時、これらのバリデーションを、データベースのテーブルに内臓する事を思いつきました。それを実装してみると、プログラミングとして残る部分が大変小さくなりました。
＜所感＞
このバリデーションには、「不変条件」のものと「入力時チェック」のものとがあります。この話は前者である時に問題になります。データ中心設計(DOA)では「データの正しさを守るために入力画面がある」と考えます。その「データの正しさ」の範囲を広げてフィールド間の整合性まで含めたという事なのだと受け取りました。
この問題は、渡辺さんのブログで何度か取り上げられているものです。そもそものきっかけは「動的参照関係」の一連の議論でした。
2011.12.20 動的参照関係を「宣言的」に扱えるか その他
http://watanabek.cocolog-nifty.com/blog/2011/12/post-63f9.html
年が明けて、今回説明された「双方向性問題」に発展されました。
2012.01.12 バリデーションの双方向性問題を解く
http://watanabek.cocolog-nifty.com/blog/2012/01/post-1498.html
プログラムとデータベースとの役割分担はDOA技術者なら必ず意識しますし、様々な提案をされている書籍も多いです。ただ、渡辺さんはXEAD Driverという実装系を自ら作って公開されている世界唯一のデータベース技術者です。議論のための議論ではなく実装されていますので説得力が違います。「双方向バリデーションの機能を実装したところ思いほのか便利でした」と言われて反論出来る人はいないでしょう。ぜひオープンソースのXEAD Driverを使ってみましょう。
http://homepage2.nifty.com/dbc/xeadDriver.html
＜DMBOK－データマネジメント知識体系のご紹介＞
DAMA-JAPAN 会長 松本聰さん１．DAMA Internationalとは
DAMA Internationalは完全ボランティアで活動している団体です。昨年末のカンファレンスに米国からスピーカーを招きましたが、彼らも基本的にボランティアです。
・データが企業の資産である事を認識する土壌を作る
・データマネジメントのプロを育成する
・特定のベンダーに頼らず、特定の技術に頼らず、特定の方法論を支持しない
中国とオーストラリア、インド、それに日本がAsian&Pacificとして活動しています。入会は原則個人です（年１万円）。法人会員も受け付けていますが、個人名としての登録としています。現在100名弱です。半数くらいが公式Facebookで情報交換を行っています。あわてずあせらず徐々にデータマネジメントを広げていきます。
日本では第1～第4の分科会が活動しています。
第１分科会：エンタープライズ（企業活動）での事例研究
第２分科会：データマネジメント用語の日本語訳
第３分科会：データマネジメント成熟度モデルの検討
第４分科会：意思決定に寄与するデータモデルの検討
２．Peterさん（協会トップ）のプレゼン
データマネジメントの広がりについて。日本はまだ米国の1980年ごろに見えます
1950～1970 DataBase Administration(DBA)
データベースデザイン
1970～1990 Data Administration（DA)
データ要求分析とデータモデル
1990～2000 Enterprise Data Administration(EDA)
データ統合
2000～ Data Management（DM)
データガバナンス、セキュリティ・・・
３．DMBOK（ディンボック）
データマネジメントを行うための１０の機能と７つの環境要素を解説したものです。何を行うべきか（WHAT)は書かれていますが、どうやれば良いのか（HOW)は書かれていません。特定の商品や方法論なども書かれていません。
DMBOKの中心はデータガバナンス（統治）です。データの品質を確保し維持するための活動です。例えば製造メーカーで品質管理を外注化している企業はいないように、ユーザ企業自らが行う必要があります。
データモデルは、10の機能の中の「データ開発管理」の一つの項目として出てきます。データ開発管理の原則の一つはこういうものです。
-----
8. データモデルは価値ある知識のリソースである（メタデータ）。データモデルの品
質と有効性の保証をライブラリ、形式、変更管理の面から注意深く管理しコントロールする
-----
４．その他
米国ではもうすぐDMBOKの次期バージョンが出る予定です。現バージョンはデータ統合が弱いので、マスタ統合を別項目として独立させると思われます。ERPのマスタの扱いについて、各社苦労されています。
たとえばSAPのマスタは色々癖がありますので、それを企業としてのマスタにする事は難しい。ある企業はSAPのマスタは捨てて全システムのマスタ統合を実施し、その統合マスタからSAPに渡すという仕掛けにされています。協和発酵キリンさんなどDOAをきっちりとやっておられる企業はそういう方向にされているようです。
アジャイル開発とデータモデリングの関係性については、米国でそういう発表を行う人が現れています。新規開発で、データモデルもなくアジャイル開発を行う事は現実的ではありませんし、逆にフラグ１つ追加するのにDAの承認が必要ならアジャイルにならないでしょう。これからのテーマだと思います。
＜所感＞
昔、高速開発の手法としてRADというものがありました。RADは実はDOAを前提としていました。アジャイルがもし本当にそちらの方向に行くなら先祖がえりだと思います。
システム設計としてのDOAは、ビジネスや業務をどう分析して整理するかという視点を持っています。DMBOKは各企業が「データを大切にしているか」という事を自ら検証してどこが弱くて注力するべきかを知るための道しるべとして利用するものだと思いました。
これを用いたコンサルティングは監査と変わらないでしょう。
DAMAは、企業にとって「データが大切」だという事を啓蒙する団体です。既にデータ中心でやっていてそれが競争優位につながっている企業にとっては敵に塩を送るような話ですから参加する意味はありません。逆にプロセス中心の企業は入ろうとするインセンティブがありません。そのためにアンテナの高い「個人」をターゲットにされているのだろうと思います。
今のところ大阪には支部がありませんが、名古屋には作る動きがあるそうです。この勉強宴会は日本でも珍しい上流工程の勉強会です。データモデリングが好きな人が集まっていますので、DAMAの動きには気を配りたいと思います。
以上
