教科書的ではなく、現場にあったデータベース設計のコツ

受注エンティティに合計金額を持つか

   図4の「受注」エンティティには、「受注金額合計」のような受注合計額をあらわす項目はありません。そのため受注一覧などで受注金額を表示する場合には、次のような計算によって受注明細の金額を集計しなければなりません。

---

   伝票合計金額を表示するのに、毎回受注明細金額の集計計算をするのはちょっと面倒ですし、パフォーマンスにも少し影響を与えます。

   また消費税計算には、「受注明細消費税の積み上げ方式」と「伝票合計金額に消費税率をかける方式」の2つの方法がありますが、いずれにしても消費税計算の度に計算するのはやっかいです。そのため筆者は図4のような正規化ではなく、「受注」エンティティに合計金額を持たせるようにしています。

受注エンティティに顧客名、受注明細エンティティに商品名を持つか

   「『受注』エンティティに『顧客名』、『受注明細』エンティティに『商品名』という項目を持つ」なんていうと、「正規化をまったく知らない人だ」と思いっきり笑われてしまうのがオチです。でも実際の基幹業務システムでは、このようにトランザクションテーブルに名称を持つことも少なからずあります。

   その理由の1つとして「名称変更への対応」があげられます。ビジネス環境が激変する今日では、企業の合併やCI（コーポレートアイデンティティ）活動により企業名が変わることは珍しいことではありません。企業名変更の際には、顧客マスタテーブルの顧客名を変更することになります。

   もしこの時図4のような正規化構造の場合であるならば、顧客エンティティの顧客名を変えるとともに、過去の受注伝票の顧客名も自動に変わってしまいます。その時点の取引はあくまでその時点の企業名で記録しておくべきなので、受注エンティティにも顧客名を用意しておくシンプルな方法も有望でしょう。

   もう1つの理由は「雑コード対応」です。一般に顧客や商品などは、きちんとマスタ登録してから使うのが基本です。しかしケースによっては、マスタ登録を省略して業務処理を済ませたい場合もあります。この例として、見積伝票を入力する際、その場限りと思われる顧客や手配品に対しては顧客マスタや商品マスタを登録せずに処理したい場合があげられます。

   そのようなケースでは画面上でコードだけでなく、顧客名や商品名を入力しますので、値はトランザクションに格納されます。そのようなケースも想定する場合は、受注や受注明細に顧客名や商品名というような項目が必要となるのです。

最後に

   本連載では5回に渡ってデータモデリングやデータベース設計について解説してきました。前半は「Object Browser ER」というツールを使った効率的なデータモデリング、中盤はデータベース設計の基本的考え方、後半は業務システムのデータベース設計で迷うポイントを取りあげました。よくある教科書的な内容ではなく、筆者独自の考え方を述べてきたつもりですが、いかがでしたでしょうか。

   本連載を読んで、データモデリングをデータベース設計に役立てることの意義を理解していただけたらと思います。また、設計で迷うようなポイントについて、考えるきっかけとなれば幸いです。

   まだまだお伝えしたい設計ノウハウがたくさんあるので、またいつか別の機会にお話できればと思っています。最後までお付き合いいただきまして、感謝しています。