データ・モデルは、作りっぱなしにしない

多方面にわたって活用可能なデータ・モデルですが、せっかく手間暇かけて作成しても、作りっぱなしの状態にしていては、システム変更時に迅速な対応ができません。当然、コミュニケーション・ツールとしても、浸透しないでしょう。

ここで、データ・モデリングとITコストの関係に、注目してください（図6）。

まず、図6の中の、2本の実線に注目してください。右に行くほど上に向かう線は、従来型のファイル設計技法（POA^*1: プログラム中心アプローチ）を採用した場合のコストを示しています。一方、もう一方の、下側にある線は、データ・モデリングを採用した場合のコストを示しています。

[*1] POA: プログラムを中心としているため、最適化されたデータがプログラムごとに複数存在する。データに重複があるため、システムのムダも複数存在する。また、システム統合時には、どれが正しいデータなのか、どれが最新なのかが判断できず、データ統合に難点あり。

データ・モデリングの初動時は、データの意味や内容を確認する時間がかかるため、従来型と比べてコスト曲線は大幅に高くなります。しかし、システムがカット・オーバー（稼働開始）するあたりから、従来型のファイル設計技法のコストが急速に上昇し、データ・モデリングの曲線を越えてしまいます。

ケースごとに曲線の角度に違いはあるものの、データ・モデリングは「仕様変更の影響を受けにくいデータに注目して設計する」という特徴があるため、従来型に比べて冗長性が低く安定性が高いデータ構造を構築できます。仕様変更への対応コストを抑制する効果があります。

とはいえ、ここで注目して欲しいのは、従来型のファイル設計技法との違いではなく、データ・モデリングを採用した場合の、実線とカット・オーバー以降の点線です。この点線が意味しているのは、「一度作成したデータ・モデルを保守していかなければ、データ・モデリングを採用しても、コスト削減効果は薄い」ということです。

図6: データ・モデリングとITコスト（クリックで拡大）

せっかく手間暇かけて作成したデータ・モデルなのですから、その後も維持していかなければ、意味がありません。また、データ・モデリングで得た知識や経験が企業内に蓄積され、変化への対応力の糧となることで初めて、データが企業の経営資源となるのです。逆にいえば、ヒト・モノ・カネは企業で管理されています。企業で管理されていないのは、データぐらいのものです。

人的管理と物的管理の両方でデータ・モデルを維持、管理する

上記の問題は、管理体制（マネジメント・システム）によって解決するしかありません。マネジメント・システムとは、リポジトリと呼ぶデータベースでデータ・モデルを一元管理し、人的管理と物的管理の2つの面から維持、管理していく仕組みのことです。

図7: データ・モデルのマネジメント・システム

（1）人的管理

管理すべき対象は、ER図、データ定義、コード設計書、用語辞書、の4つです。

データ定義には、「アトリビュート」や「カラム」の意味、内容、属性、データ例なども含まれます。コード設計書には、取引先コードや注文番号など、企業で管理しているコード体系や付番ルールが含まれます。用語辞書には、標準化されたデータ名称が含まれる辞書と、名称の標準化ルールが含まれます。データベース・セキュリティに関する定義を包含する場合もあります。

これらの管理対象は、メタデータ（データのデータという意味。例えば、データの属性を示すデータなどが該当）としてリポジトリで一元管理します。複数の関係者が、データ・モデルを同時に参照、更新できる状態が理想です。また、維持管理にあたっては、Oracle Databaseなどを管理するデータベース管理者（DBA）ではなく、全社のデータを管理するデータ管理者（DA）の設置が必要です。