7.1 論理設計で行うこと

方式設計の工程から、方式面から分析した、データベース要件に関して次の2つのドキュメントを参照します。
1つは、方式に関するユーザからの要件をまとめたもので、方式設計の要件定義書です。
これをもとに、データベースを含む、ユーザ要件を満たしたシステムを作成していきます。

方式要件定義書と、プロセス処理リスト、データフロー図を元に、データベースサーバの配置、サーバ、クライアントそれぞれの処理要件を考え、システム構成図の概略図を作成します。

これらのドキュメントから検討した結果、システム化および適切なデータベースシステムおよびアプリケーションの提案によって、次のような効果をあげることが明確になります。
システム化だけで可能な効果もありますが、システムを提案する側の工夫によって、可能となる部分もあります。
このような「システム化における付加価値を提案」できるか否かが設計者としての価値を決めるといっても過言ではありません。

営業所の処理業務の見直し

これまで、営業所で行っていた請求書の発行、入金確認などの処理は、システム化することによって、大幅に手作業の負荷を削減することができます。
請求以降の会計関係の処理は、営業所では確認のみできるようにしておき、実際の処理は経理部門で一括して行うように提案することができます。
営業所は営業活動に専念することができます。

そして、作業負荷が軽減された時間を使って、蓄積されたデータを分析し、地域特性を活かした販売予測、販売計画をたてることを提案します。
そのために必要な分析のための軸をヒアリングによって収集します。
たとえば、購買する人の性別や年齢層などは、意識して集めないと、販売と連動して分析することはできません。

会計処理の一元化

各部門で起票された仕訳伝票を受け取った経理部門が行っていた総勘定元帳への転記作業を、次のように変更することができます。

仕訳伝票を起票した部門で、その部門の業務処理を行うと、会計に関係する処理の場合、仕訳伝票が同時に作成され、システムの総勘定元帳に自動的に登録されるような仕組みを提案します。
また、これまで手計算で行っていた決算時の損益計算書や貸借対照表の作成処理も、システムでは総勘定元帳を元に四半期ごとに自動的に行うことができます。
これによって、経理部門の作業負荷が大幅に軽減され、誤転記などのミスもなくなります。
単調な転記や計算、誤処理の後処理などに割かれる時間を極力軽減できます。

受発注処理の連動

受注処理における在庫引当処理、発注処理による予定在庫数の管理、入出荷処理による実在庫数の管理がリアルタイムでできることによって、在庫が適正化されます。
在庫を適正に管理できるようになれば、欠損による販売機会の損失は大幅に軽減することができます。
また、在庫の適正化を行うことによって、倉庫のレイアウトも適切に管理することができるようになり、今まで扱うことができなかった商品を加えることもできる可能性があります。

将来日付の予定在庫数と実在庫数が、リアルタイムで管理できるようになるための設計（データベース設計、アプリケーション設計、方式設計）が、このシステムの特徴です。
今回のシステム構成のポイントの1つは、本社で集中管理しているデータベースが1つであることから在庫表も1箇所で管理でき、リアルタイムで最新情報を更新、取得することができる点です。

在庫引当時の部門間連携

受注時に在庫が不足していた場合には、すぐに仕入れ処理ができるように連携をとっています。
システム化によって、部門間連携を迅速に行うことができるようになります。
ただし、仕入れにより倉庫に入庫された商品が他の受注によって引き当てられないよう、データベースで紐付けを行っておく必要があります。
これを実現するためには、データベースの中で、適切なリレーションが設定されている必要があります。

それでは、具体的にアプリケーションで設計している受注画面を参考にしながら、受注に関するテーブル設計と索引の設計を考えてみましょう。
論理設計の範囲は、受注画面からわかる範囲で実施します。
他の部分は、論理設計に関しては、画面レイアウトや帳票レイアウトが決まらないと詳細には検討できないため、範囲を限定して紹介します。

解説トレーナー