業務システムはシステムのライフサイクルを考慮した全てのコスト、いわゆるTCO（総所有コスト）が重要とされます。TCOには、初期費用やランニング費用といった、わかりやすいコストのほかに、隠れコストとして「将来の変更コスト」が含まれます。
業務システムは業務ルールの変更や、使い勝手の見直しの必要性などから、長期間に渡り、変更が発生するものです。そのためこの「変更コスト」は総所有コストを大きく左右するのです。
この将来の変更コストを抑えるにはデータベースの構造の善し悪しが大きく影響します。

データベース構造が変更容易性を左右する

業務システムは一部の例外を除き、リレーショナルデータベース（以下データベースと表記します）にデータを保存します。データベースがシステムの中心に位置する構造です。画面から入力したデータはデータベースに保存しますし、画面に表示したり帳票に印字するデータはデータベースから取り出したデータ。何か情報を検索するときの操作対象もデータベースです。
そのため、データベース構造の変更はシステムの広い範囲に影響します。データベース構造に無理があると、データベースにアクセスする各種のプログラムにも無理が及ぶのです。
逆に将来の変更コストを抑えるためには、データベース構造が業務ルールに対して、自然な構造になるように設計すればよいことになります。例えば、「店舗」と「販売員」の関係が１：ｎ（販売員は１つの店舗に所属）ではなく、ｎ：ｍ（販売員は複数の店舗に勤務）であるなら、データベースの「店舗」と「販売員」の関係も同じように設計するのです。

データベース設計をレビューしよう

業務システムの基本設計では、画面や帳票は「業務のプロ」によって細かくレビューされることが多いのですが、データベース設計は技術的な専門性が高いことからレビューの対象外にされがちです。
しかし、暗黙の業務ルールや将来の業務ルールの変更見込みについては、業務のプロでないと理解が難しいものです。私はデータベース設計も、業務のプロの方がレビューすることを推奨します。
データベース設計に対して、将来の変更コストを抑えるために確認すべき事項は次の２点です。

• データがどのような種類に分類して保存されるか。（例えると販売システムでは、店舗、販売員、商品などが該当します。）
• 保存されるデータの関連はどうなっているか。（先ほどの「店舗と販売員はｎ：ｍ」などの関連性を確認してください。）

如何でしょうか。技術的な事項は解らなくてもかまいません。業務ルールに対して、データベース構造の想定が正しいかどうかを、ベンダーの説明を聞いたり質問しながら確認すればよいのです。この確認作業で将来の変更コストの肥大化を避ける事ができます。