福士有二
日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部

 データ設計の肝になるのは,データの最小単位であるデータ項目と,データ項目のまとまりと関連を示した論理データ・モデルである。画面設計や業務プロセス設計より先に設計作業を進め,追加や変更がある場合は速やかに対処することが肝心である。

 図6に示したのが,データ設計で作成する設計書とその関係である。大きく分けて「(1)設計基準作成」「(2)データ項目設計」「(3)データベース論理設計」という三つのステップがあり,全部で8種類の設計書を作成する。要件定義で作成した「業務用語集」「概念データ・モデル」「データフロー図(DFD)」を用意しておこう。図7と照らし合わせて読んでほしい。

図6●データ設計の成果物とその関係<br>まずネーミング基準や単語辞書などを決定する「設計基準作成」を実施し,その上でエンティティで利用するデータ項目を定義する「データ項目設計」,論理データ・モデル(E-R図)を作成する「データベース論理設計」を実施する
図6●データ設計の成果物とその関係
まずネーミング基準や単語辞書などを決定する「設計基準作成」を実施し,その上でエンティティで利用するデータ項目を定義する「データ項目設計」,論理データ・モデル(E-R図)を作成する「データベース論理設計」を実施する
[画像のクリックで拡大表示]
図7●データ設計で作成する設計書の例と記述のポイント
図7●データ設計で作成する設計書の例と記述のポイント
[画像のクリックで拡大表示]

CRUD図の作成を忘れずに

 画面設計と同様,最初にメンバーが従うべきルールを明確にしておく((1)設計基準作成)。ルールには「ネーミング基準」「単語辞書」「ドメイン一覧」がある。これらは要件定義の成果物や,他システムの事例などから洗い出す。

 設計基準を明確にしたら,(2)データ項目設計に入る。データ項目は,画面や帳票,業務処理,データベースなど,あらゆる成果物上に登場し,それらを関連付けるキーワードとなる。様々なデータ項目をまとめた設計書が「データ項目辞書」だ。

 データ項目を厳格に管理できるか否かで,設計書の品質が決まると言っても過言ではない。現行システムがある場合,その仕様から確実にデータ項目を探し出す。画面設計で新たなデータ項目が発生した場合は,漏れなく追加する。データ項目辞書を早期にメンバーに公開すれば,同音異義語や異音同義語のはんらんを避けられる。

 洗い出したデータ項目は,同音異義語や異音同義語をはじめ,業務に関係しない項目(ページ番号や制御用の項目など)を除外する。その上で,整理したデータ項目に単語辞書や業務用語集などを参照して名前を付ける。

 データ項目辞書に記述する際には,ドメイン分析と呼ぶ作業も実施する。ドメインとは,特定のルール(型やけた,制約条件など)でグループ化した単位のこと。洗い出したデータ項目はいずれかのドメインに所属させる。一見面倒な作業に思えるかもしれないが,特に大規模システムの開発では,これをやっておくとデータ項目の管理が楽になる。

 なお,データ項目の中には,データのロジックや構造が規定されていたり,取り得る値の範囲が決まっていたりするものがある。前者は「コード仕様」,後者は「コード一覧」としてまとめ,一覧性を高めるとよい。

 (3)データベース論理設計では「論理データ・モデル(E-R図)」と「CRUD図」を作成する。作成のポイントは,リソース系エンティティ(マスター系)とイベント系エンティティ(更新系)を分けること。両者のうち,全体への影響が大きいリソース系エンティティの方を先に抽出する。要件定義の各種成果物や既存システムを参照して探すとよい。

 イベント系エンティティの方は,業務プロセス設計や画面設計の各種成果物から抽出する。画面設計の成果物からは,主キーや属性,リレーション(1:n,m:n)などが洗い出せる。

 機能とエンティティの関係は,C(追加),R(参照),U(更新),D(削除)という四つのアルファベットで表すCRUD図に記述する。CRUD図は機能の抜けや漏れのチェック,機能の共通化などを検討するのに便利だ。CRUD図をタテ方向に見て,Uが複数ある場合,正規化に問題がある恐れがある。CとDが複数あるときには,機能を共通化できる可能性がある。