» 【第107号】データモデリングと標準化

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

台風が通り過ぎて、本格的な夏ですね。皆様お元気ですか。
7月14日のDOA+第3分科会には150人の参加をいただきました。当初
の目的「初心者にRDBについての正しい理解を持っていただく」も、アンケ
ートにおいて多数の「DOA+の手法を試してみたい」との回答をいただく
など、一応達成できた模様でした。7月25日の第1分科会では、DOA高度
化として、システム間で、やり取りされるメッセージの意味の流通を保証す
るために、メタモデルを議論していますが、もう少しこれまでの成果を調べ
ましょうということになりました。


■DBも当初は特定プログラム専用
情報システムを語るときデータベースは、いまや不可欠の課題となっており、
知らない人を探す方が難しい状態となっているわけですが、データベース
についてのイメージや意味するところは人によってかなり異なっているか
に思われます。データベースの登場は、DBMSの登場した35年以上前に
遡りますが、その機能として、
 ・直接アクセス
 ・構造表現
 ・大量データ記憶
 ・共用
が評価され、受け入れられていきました。構造表現のためにディレクトリが
用意され、それまで難しかった、受注―受注明細といった階層データの表\n現やBOM(部品表)などに適用されました。また大量データ記憶は、共用
のためのレコードごとの排他制御機能とあいまって、大量のトランザクション
処理に応用されました。
しかし、多くは特定のプログラム専用の記憶媒体としてであって、共用記憶
媒体としての利用はあまり進みませんでした。ひとつには特定のアプリケー
ション向けのデータ構造になっていたり、またSEやプログラマが、それまで
のPOA(Process Oriented Approach)的バケツリレー方式のファイル処理
の考え方から、脱しきれなかったからかと思われます。
1980年代になって、RDBMSが登場し、これは徐々に解消していくわけで
すが、共用記憶媒体としての認識、すなわち「DBはプログラムが通信する
場である」、とか「DBによってコンピュータを通信手段として使う」としての認
識は、非常に遅々としてしか進んでいかなかったように思われます。DBに
アクセスするプログラム/プログラマは必ずディレクトリを参照します。これ
によって、E. F. Coddの主張したデータ独立性が得られ、共用が実現します。
ディレクトリはDB設計、したがってデータモデリングの結果として作られます
から、アクセスするプログラム/プログラマの、あるいはさらにこれを使う全
ユーザの情報要求を調整/標準化した結果として作られるものです。しかし
多くは、当面のアプリケーションがうまく動けばよいといった観点が優先し、
「DB設計とはテーブル設計」のように考えられ、「DB設計とはデータの標準
化である」との認識は希薄だったように思われます。

■データの標準化
データの標準化は、
・既存データをベースとして調整する
・適切な有限の範囲で行う
といった特性を持っています。ユーザニーズを表す既存データを収集し、
データの相互関係を調査分析し調整するわけですが、その素材としては、
現行画面・帳票が、ユーザとのコミュニケーションもとりやすく一番分かり
やすいため、われわれは原則として現行画面・帳票を分析します(注)。
データの意味は人間でなければ分かりませんので機械化はできません。
標準化の範囲は、データにより異なりますが、有限です。品番、組織、顧客
などに関するデータは、最低限全社レベルで標準化しなければなりません
が、営業システム内、生産管理システム内で標準化すればよいといった
データもあります。
(注)作業効率を上げるために、テンプレートを使用する場合があります。
現行物理ファイルはテンプレートの1種として位置づけられます。しかしこれ
は上級者向けの方法で、初心者教育には現行画面・帳票が最適のように
思われます。
データ(属性)の標準化の内容としては、
・ 識別子、仕様、意味、形式(データ型や桁数など)の標準化
・ 値の標準化
があります。品種、品番、品目、部品、商品などの関係や、顧客、得意先、
届け先、取引先、拠点、協力会社などの関係は、レコード1件1件調べない
と、その粒度やスコープがちがっているなど、はっきりしない場合が多々
あります。
また、コード体系の規定と実際発行されているコード値の違いなど、データ
1件1件調べないと発見できない場合もあります。

■データモデリングは概念DBへの写像作業
このようにして、現行画面・帳票(必要に応じて物理ファイルも参照)から分
析されたものが、AsIsデータモデルということになります。これは、基本的
には個々のユーザの世界のデータを、共通の概念DBの世界に写像した
結果ですが、相互に矛盾がある場合は、通常この解消までを含みます。
同様に、新規画面・帳票を分析すればToBeデータモデルが得られます。
これが新規システムの骨格と品質を決めますので、新規開発に当たっては、
経営ニーズを反映した新規画面・帳票をいかに設計するかが課題になります。
しかし、これは非常に重要ではありますが、KPIなどを考慮する、データモデ
リングとは観点の異なる別工程の作業と考えます。
このように、データモデリングとは、ある業務領域の画面・帳票と、これを支
える共用データ通信場としてのDBを矛盾なく繋ぐ工程の作業であり、内容
は標準化にほかなりません。現状のDBMSのディレクトリは物理的なデータ
の出し入れに必要なデータしか受け入れませんので、データモデリングの結
果は、別途リポジトリ(システム開発者用のDB、メタDBとも呼ぶ)を用意し、
これにストアすることになります。また共用範囲が1アプリケーションの範囲を
超えるコード値は、別途リソースDBをつくりこれにストアすべきと、われわれ
は主張しております。

■3レベルの通信場での標準化
前述のように、標準化という人間作業は有限の範囲でしかできません。
そこで一般には、生産、販売、会計、人事など、個別業務領域対応にDB/
システム構築が行われてきたわけです。しかしこれらの業務アプリケーション
を横断流通すべきデータ(トランザクション/メッセージ、特に業務アプリ内の
ロウレベルメッセージに対比させて、ハイレベルメッセージとも言う)があり、
孤島システム解消のため、その標準化ニーズが高まってきました。
先の個別業務領域内の標準化をP2P(Program to Program)の標準化と呼ぶ
ならば、この個別業務領域横断の標準化はA2A(Application to Application)
の標準化と呼ぶことができるかと思います。これはXML登場とともに話題と
なった、B2B(Business to Business)の下位の標準化に位置づけられます。
ベンダーはSOAによる解決を提案していますが、コンテンツにかかわるA2A
の標準化とあいまって実現するものと考えます。
P2P、A2A、B2BいずれもDB通信場を活用して、コミュニケーション問題を
解決しようというもので、データ標準化が鍵となります。個々の処理(プロセス)
はDB通信場を介してコミュニケーションしますので、これらはあたかも太陽の
周りに惑星が配置される地動説のアーキテクチャになります。これは自分の
担当する処理中心の、POAの自己中心的天動説のアーキテクチャからの
脱却を必要とします。
P2Pの標準化は、システム部門長の手の届く範囲にあり、またパッケージに
よる解決もありえます。しかも20年を越えるDB化の歴史もあって、P2Pでの
地動説はほぼ理解されたかに見えます。したがって、いまや課題の本命は、
孤島システムの解消にかかわるA2Aでの地動説のように思われます。スコー
プが企業全体となるため、一般にシステム部門長の手に負えずCIOの登場が
期待されるわけですが、人間の本能に基づく天動説からの脱却はなかなか難
しく、企業格差が大きく出始めているように見えます。