2018年 春期 応用情報技術者試験 問6
備品購買システムの設計と実装
R社は、ソフトウェアパッケージの開発及び販売を行う中堅企業である。これまで備品の購買は、総務部が表計算ソフトを用いて管理し、行っていた。このため、見積依頼や発注、納品された備品の確認などを円滑に行うために、備品購買システムを構築することになった。
備品購買の処理の流れとシステム化対象を表1に示す。
No. | 処理名 | 概要 |
---|---|---|
1 | 購買依頼 | 利用部門が総務部に、備品の調達を依頼する。 |
2 | 見積依頼 | 総務部が依頼された調達の内容を確認し、在庫がない場合は取引先に見積りを依頼する。 その際、取引先のカタログを使って依頼された備品の商品番号と商品名を調べ、数量及び希望回答日と一緒に入力する。 |
3 | 見積登録 | 総務部が取引先から回答された見積りの内容を登録する。 その際、見積有効期限や価格情報などを入力する。 |
4 | 発注 | 総務部が取引先に、見積りに対して発注する。 その際、発注する商品の数量や希望納品日を入力する。 |
5 | 納品 | 総務部が取引先から届いた商品を登録する。 その際、届いた商品の数量などを入力する。取引先の在庫状況によっては、複数回に分けて商品が届くことがある。 |
6 | 検収 | 総務部が発注した商品が全て納品されたことを確認する。 |
7 | 請求 | 総務部が取引先から送られてきた請求書の情報を登録する。 |
8 | 支払依頼 | 総務部が経理部に、請求書に対する支払を依頼する。 |
この処理の流れから検討した、備品購買システムのデータベースのE-R図を図1に示す。
このデータベースでは、E-R図のエンティティ名を表名にし、属性名を列名にして、適切なデータ型で表定義した関係データベースによって、データを管理する。
主キーの実線が付いている属性名には、外部キーの破線を付けない。
【相見積り機能の検討】
備品購買システムに相見積り機能を追加することを検討する。相見積り機能とは、複数の取引先へ同じ内容の見積依頼を出す機能である。これによって、より安い価格を提示した取引先へ発注を行うことができるようになる。見積依頼を一度に複数の取引先へ出すために、見積依頼エンティティを二つのエンティティに分けることを考える。
一つ目のエンティティは、複数の取引先への見積依頼を束ねるエンティティとして、主キーに見積依頼番号、属性に見積依頼日と見積依頼者、aをもたせる。
二つ目のエンティティは、各取引先への見積依頼を管理するエンティティとして、主キーにdとe、属性に取引先担当者をもたせる。
この変更に伴い、fエンティティにも変更を加えることで、この機能を実装することができた。
【検収機能の作成】
検収のために、発注した各商品の数量と納品された数量を、商品番号の昇順に一覧表示するSQL文を図2に示す。ここで、":発注番号"は、指定された発注番号を格納する埋込み変数である。
なお、関数COALESCE(A, B)は、AがNULLでないときはAを、AがNULLのときはBを返す。
SELECT ORD.発注番号, ORD.商品番号, ORD.商品名, ORD.発注数量, COALESCE(g, 0) FROM (SELECT OD.発注番号, OT.商品番号, OT.商品名, OT.発注数量 FROM 発注 OD INNER JOIN 発注明細 OT ON OD.発注番号 = OT.発注番号 WHERE h ) ORD LEFT OUTER JOIN (SELECT DE.発注番号, DD.商品番号, SUM(DD.納品数量) AS 納品数量計 FROM 納品 DE INNER JOIN 納品明細 DD ON DE.納品番号 = DD.納品番号 WHERE DE.発注番号 = :発注番号 i ) DLI ON ORD.発注番号 = DLI.発注番号 AND ORD.商品番号 = DLI.商品番号 j
【返品対応】
備品購買システムが完成し、運用が開始されてから数か月後、総務部から問合せがあった。取引先から納品された商品を登録した後、利用部門から商品の一部に問題があったので返品したが、その際の情報を記録したい、とのことであった。
納品登録したレコード中の納品数量から返品した数を減らす方法をまず考えたが、その方法では、納品された商品数量や返品したという事実を記録することができない。そこで、データベースの定義や納品登録した際のレコードには変更を加えずに、①納品表と納品明細表にそれぞれ新しいレコードを追加することで、返品に関する情報を記録することができた。