データベースの設計

投稿日:2007年05月07日作成者:yasunaka

システムを設計する際に非常に気を使ってきた事として、このデータベースの設計があります。システムの中身（作り）についてはユーザ側では理解できないことが多いので、ユーザ側の注文は「外部仕様」に集中しがちですが、ことデータベースについてはユーザ側でもある程度容易に理解ができるということもあり、いろいろと突っ込まれやすい部分です。

確かにデータベースの設計においてはユーザ側の要件を明確にするために、ユーザ側にいろいろと確認しなければならないことが多々あります。例えば、こんなものです。

１．データ間の関係。１対１なのか１対多なのか、多対多なのか
２．データは変更・削除履歴を保持すべきか
３．データの発生する量
４．コード体系（単にどのコードを使うということだけでなく、どこの誰がいつ、どのようにコードを発番し、どのようにメンテナンスするのかなど）

変更・削除履歴というのはデータモデリング上は気にされにくい、機能に関する部分なのですが、もし必要となると結構厄介なものです。操作内容を操作履歴として保持すれば良いだけなのか、それとも対象のデータそのものを履歴データとして保持しなければならないのかなど、要件によっても構造が変わってきますし、もし対象のデータそのものを履歴データとして保持しなければならない場合にはユニークキーをどう設計するのか、履歴データ間の紐付けをどうするのか、実際のデータ容量を考えた場合、それは十分なパフォーマンスを確保できるのか、過去データの修正入力は可能とすべきか、など頭の痛い問題が多い機能です。

コードの一貫性なども設計上頭の痛い問題の１つです。私の出身の金融系の世界では様々なコードが存在しているのですが、困ったことにそれらのコードにはたまに変わったりするのが多々あります。もしそのような一貫性に欠けるコードをデータの主キーに使ってしまうと、コードが変わったときにそのコードを使っている全データのメンテナンスが発生する、といううれしくない事態になってしまいます。

これを避けるためにいちいちコードに対応する別なキーを機械的に付与して、これを主キーとして設計するという手法が良く使われるのですが、こんなのはなかなか説明しても理解してもらえる部分ではありません。またこうしたからといってすべてOKというわけでもなく、様々な事象について具体的に検討を重ねておかないと、運用し始めてから対応できないことに遭遇する、なんて最悪な事態を迎えかねません。

１つ言えることとして、こういった業務に直結した部分にノウハウを有しているシステム開発会社は、ユーザに対して強い立場になれるということがあります。単に言われたとおりに作るのではなく、対象の業務領域について、どういうデータ構造であるべきかがわかっていて、その方式についていくつかのやり方をメニューとして提案できる、そんなシステム開発会社は明らかに高い競争力を保持することができるのではないでしょうか。