データベーススペシャリスト 2017年 春期 午後II 問題

共通の文章

データベースの設計,実装に関する次の記述を読んで,設問1ご3に答えよ。 N社は,家具・日用雑貨の小売業を営む企業であり,全国に直営店舗を展開するほ か,Webサイトのオンラインショップでも販売を行っている。直営店舗における販 売(以下,店舗販売という)とオンラインショップにおける販売(以下,OL販売と WD)の各業務は,それぞれ運営する組織も,利用するシステムも異なっている。そ こでN社では,かねてからの課題であった相互の情報共有を実現するために,各シ ステムで保有する情報の一部を統合して,業務の改善を図ることにした。 現在の業務内容] 1.店舗販売業務 (1)運営組織 ①全国を20のエリアに分割し,各エリアの管理担当者が,担当地域内の複数 の倉庫,複数の店舗を管理している。 ②店舗の従業員は,一つの店舗に所属し,役職及び担当職務が定められている。 (2)商品 ①取扱商品は,約5万点である。商品は商品コードで一意に識別される。 ②商品分類は,大分類,中分類,小分類の3階層構成である。 3)会員 ①店舗で会員登録を行った顧客(以下,店舗会員という)に,店舗ごとに一意 な店舗会員番号を付与する。会員登録時に氏名,住所,電話番号を記録する。 店舗会員には,ポイントカードを発行する。ポイントカードには,発行した店 舗の店舗コードと店舗会員番号が印字されている。 ②ポイントカードの紛失時・不携帯時は,新たな店舗会員としてポイントカー ドが発行されるので,同一顧客が複数のポイントカードをもつこともある。 (4)販売 ①店舗のPOSレジで,精算ごとに販売,販売明細を記録する。 ②店舗会員がポイントカードを提示すると,購入金額に応じてポイントが付与 され,使用可能ポイントとして蓄積される。 ③ポイントは,取得した翌日以降の購入時の支払に使用できる。使用したポイ =* ントは,即座に使用可能ポイントから差し引かれる。 ④蓄積されたポイントは,取得した年の2年後の年末まで有効である。 (5)在庫 ①店舗では,商品ごとに実在庫数を店舗在庫として管理している。 ②エリアでは,倉庫ごと,商品ごとに実在庫数,引当済数を倉庫在庫として管 理している。 (⑥)店舗への出荷 QOエリアの管理担当者は,店舗在庫を定期的に調べて,実在庫数が一定水準を 下回る商品がある場合は,倉庫に対して店舗への出荷指示を行う。 ②倉庫は,出荷指示を受けると,店舗ごとに商品をまとめて出荷する。 (7)販売分析 エリアの管理担当者は,蓄積されている販売データを,専用の多次元分析ツー ルを用いて検索,集計し,その結果を販売促進,商品企画の参考にしている。 2.OL販売業務 (1)運営組織 ①オンライン事業部が,オンラインショップを運営している。 ②OL販売専用の倉庫が一つある。 (2)商品 ①上店舗での取扱商品の一部を販売する。商品は,店舗販売業務と同じ商品コー ドで識別される。 ②商品分類は,3て5階層構成である。 3)会員 ①オンラインショップの利用には,会員登録が必要である。Webサイトから 会員登録を行った顧客(以下,OL会員という)に,OL販売で一意な会員番 号を付与する。会員登録時に,氏名,住所,電話番号,生年月日,性別,メー ルアドレスを記録する。 ②会員登録時に,同一人の複数登録がなかいようにチェックする。 (4)販売 ①一つの注文で,複数商品の購入を受け付ける。商品の配送前であれば,注文 の取消しができる。 ーッー ②注文ごとに,購入金額に応じてポイントが付与され,使用可能ポイントとし て蓄積される。ポイント使用時の取扱い,ポイント有効期限は店舗販売業務と 同じである。 (5)配送 ①オンライン事業部は,注文に応じて,倉庫に配送指示を行う。 ②倉庫は,配送指示を受けると,商品を梱包し,外部の配送業者に委託して注 文者の指定場所に配送する。 (6)在庫 倉庫では,商品ごとの実在庫数,引当済数を倉庫在庫として管理している。 (⑦)販売分析 オンライン事業部の管理担当者は,蓄積されている注文データを直接参照して 検索,集計し,その結果を販売促進,商品企画の参考にしている。 [販売業務改善の要件) (1)共通情報の管理 ①店舗販売業務とOL販売業務を統括する販売統括部を新設し,両業務に共通 する商品情報及びそれに関連する商品分類情報を管理する。 ②店舗会員とOL会員の情報を統合し,会員区分で識別する。会員情報漏えい 防止対策として,参照者の範囲を限定する。 (2)ポイントの取扱い ①会員が所持している1枚又は複数のポイントカードのポイントと,OL販売 のポイントを,まとめて取り扱えるようにする。これをポイント統合という。 ②会員から申請があれば,ポイント統合を行う。MARIS,OL販売の会員番 号を正規の会員番号とし,ポイントを集約する。 @会員は,統合するポイントカードの店舗コードと店舗会員番号を指定する。 複数のポイントカードのうち,1枚だけを存続させ,その他は廃止する。 ④ポイント統合は申請の翌日以降に有効となり,店舗販売とOL販売のどちら でもポイントを使用できるようにする。ポイント統合の対象となつったポイント カードの統合申請日,統合対象ポイント(統合時点の使用可能ポイント)を記 録し,照会画面から確認できるようにする。 =f= (3)OL販売の取扱商品拡大と在庫回転率向上 ①全エリアの倉庫からの配送を可能にして,店舗販売業務の取扱商品の多くを OL販売で取り扱えるようにする。 ②エリアの倉庫在庫から他エリアの店舗へ出荷できるようにする。 @店舗で販売可能な商品とオンラインショップで販売可能な商品を区分する。 (4)販売分析 ①店舗販売とOL販売をチャネル区分で識別し,チャネル横断的に販売分析処 理を行えるようにする。販売分析処理の例を表1に示す。 ②会員の性別,居住地域(関東,東海など),年齢層(10代,20代など)を用 いて分析を行う。 表1販売分析処理の例 OL販売業務で用いている商品分類を第1て3階層の範囲内から選択し,過去3年間 処理例1|の商品分類別,チャネル別,年月別の販売金額集計値を時系列に比較して,販売傾 向の変化を分析する。 指定期間(開始日と終了日)内に,関東地域に居住する30代の女性が購入した,店 処理例2|舗販売の大分類コードが‘KOO’(キッチン用品)の件数を,購入曜日ごと,時間 帯ごとに集計し,商品紹介のタイミングを分析する。 [現行システムの概要)〕 N社では,現行店舗販売システムと現行OL販売システムを個別に運用し,両シス テム間のデータ連携はなく,マスタ情報もをそれぞれのシステムで管理している。 1.現行店舗販売システムのテーブル構造とCRUD 現行店舗販売システムのテーブル構造,CRUDを図1,表2に示す。 ー9一 エリア(エリアコード,エリア名,管理担当者) 倉庫(倉庫コード,エリアコード,倉庫名) 店舗(店舗コード,エリアコード,店舗名) 従業員(従業員ID,氏名,店舗コード,役職,担当職務) 大分類(大分類コード,大分類名) 中分類(中分類コード,中分類名,大分類コード) 小分類(小分類コード,小分類名,中分類コード) 商品(商品コード,商品名,型番,小分類コード,標準単価,商品説明,…) 会員(店舗コード,店舗会員番号,氏名,住所,電話番号,使用可能ポイント,本年ポイント, 前年ポイント,前々年ポイント) 店舗在庫(店舗コード,商品コード,実在庫数) 倉庫在庫(倉庫コード,商品コード,実在庫数,引当済数) 販売(伝票番号,店舗コード,POSレジ番号,従業員ID,販売日,販売時刻, 店舗会員店舗コード,店舗会員番号,取得ポイント,使用ポイント,…) 販売明細(伝票番号,伝票明細番号,商品コード,数量,単価) 出荷指示(出荷指示番号,出荷指示日,倉庫コード,店舗コード,出荷状態) 出荷指示明細(出荷指示番号,出荷指示明細番号,商品コード,数量) 販売ファクト(伝票番号,伝票明細番号,店舗軸ID,商品軸ID,時間軸TD,数量,金額) 店舗軸(店舗軸ID,店舗コード,エリアコード) 商品軸(商品軸ID,商品コード,大分類コード,中分類コード,小分類コード) 時間軸(時間軸TID,年月日,年,A,四半期,年週番号,曜日,時間帯) 図1現行店舗販売システムのテーブル構造(一部省略) 表2現行店舗販売システムのCRUD 倉エ|従|類大|商|会|店|倉|販|販|出|OR 庫り|業|・分|品|員|舗|庫|売]売|荷|荷|売|・舗 ・ア|員|小類在|在明|指|指|フ|時軸 ames。|CO|||||||||||| 従業員登録|RlcO||||||||||| オ|商品登録。|R||cRulCO|[cfc]|||||| ン|会員登録|R|||fet|||||||| ィ|POS入カ。|RIR||RIROlU||]clcl|||| ン|出荷手配|R|||R||RlRoul||clcl|| 出荷。|||||lulul|lul||| [wenn||||||||||||IRIR 人生EEE Aミーレーてで チ|分析データ作成|R|R|R|R||||RIR||lclcl 注記C:追加,R:参照,U:更新,D:削除 2.現行OL販売システムのテーブル構造とCRUD 現行OL販売システムのテーブル構造,CRUDを図2,表3に示す。 商品分類(分類コード,商品分類名,上位分類コード) 商品(商品コード,商品名,型番,分類コード,標準単価,商品説明,…) 商品画像(商品コード,画像番号,表示順,BA,ファイルパス) 関連商品(商品コード,関連商品コード,関連度数) 会員(会員番号,氏名,住所,電話番号,性別,生年月日,メールアドレス, 使用可能ポイント,本年ポイント,前年ポイント,前々年ポイント) 倉庫在庫(商品コード,実在庫数,引当済数). 注文(注文番号,BABS,注文年月日注文時分,取消フラグ,配送希望日,指定場所, 配送希望時間,決済情報,使用ポイント,取得ポイント) 注文明細(注文番号,注文明細番号,商品コード,数量,単価) |配送指示(配送指示番号,注文番号,状態コード,配送業者,出荷予定日,出荷日,配送番号 納品予定日,納品日) 配送指示明細(配送指示番号,配送指示明細番号,注文番号,注文明細番号,数量) 図2現行0L販売システムのテーブル構造(一部省略) 表3現行OL販売システムのCRUD 商|商|商|関|会|倉|注|注|配|配 品|品|品|連|員|庫|sc]se]KR]RK 分画|商在明|指|指 類像|品庫M|示|示 処理PA |商品登録。|cRulcu|||lcl|||| 商品追加情報登録||RlcCUlcU||||||| +|会員登録||||lcol|||| ン|商品検索|RIRIRIR||||||| 2注文受付||RIR|[Rufrufc[c]{|| ン|注文取当。||RIR||Roululul||| [配送手配|||||]R||IRIRlclcl 配送。|||||UIRIRIuU| |販売伯|RIR|||R||RIR||| バ|ポイント反映。||||ful|RIR||| チ|商品画像取込み|||cu|||||||| 注記C:追加,R:参照,U:BH,D:削除 [連携システムの概要)〕 N社では,販売業務改善に向けて,新たに連携システムを構築することにした。店 舗販売システムとOL販売システムの間で直接データ交換を行うのではなく,連携シ ステムに,両システムのデータの一部を統合,一部を複製した上で,連携システムを 介して双方の情報連携を行う。 (RDBMSの仕様] 店舗販売システム,OL販売システム及び連携システムに共通して用いられる RDBMSの仕様は,次のとおりである。 1.権限 (1)テーブル,ビューへのアクセスには,アクセス権限が必要である。 (2)ビューにアクセスする場合,そのビューが参照するテーブル又は他のビュー のアクセス権限は不要である。 (3)テーブル,ビューのアクセス権限は,ユーザID,ロールに付与される。ロー ルは,ユーザID及び他のロールに付与される。 2.トリガ テーブルに対する操作(追加・更新)を契機に.あらかじめ定義された処理を実 行する。実行タイミング(追加・更新の前又は後),列値による実行条件を定義す ることができる。 3.DB相互接続機能 同じネットワーク上にある異なるサーバ上のDBを,相互接続する機能である。 相互接続したDB上のテーブルは,一つのSQL文で操作することができる。 4.レプリケーション機能 (1)1か所のデータを複数か所に分散する機能,複数か所のデータを1か所に集約 する機能,及び両者を組み合わせて双方向に同期をとる機能がある。これらの機 能を使用すると,一方のテーブルへの追加・更新を他方に自動的に反映させ,デ ータの同期をとることができる。 (2)トランザクションログを用いて一定間隔でデータの同期をとるバッチ型と, レプリケーション元のトランザクションによってデータの同期をとるイベント型 とがある。 ①イベント型では,レプリケーション先への同期が失敗すると,レプリケーシ ョン元の更新はロールバックされる。 ー昌一 ②パッチ型では,テーブルごとに,レプリケーションの有効化,無効化をコマ ンドによって指示することができる。無効化したレプリケーションを有効化す るときには,蓄積されたトランザクションログを用いてデータの同期をとる。 (3)必要となる列の選択,必要となる行の選択及びその組合せによって,レプリ ケーション先のテーブルに必要とされるデータだけを同期することができる。 〔テーブル配置の検討 現行店舗販売システムと現行OL販売システム(以下,二つのシステムを合わせて 現行システムという)のテーブルを,表4の配置方法わて⑤のいずれかによって配置 することにし,表5に示すテーブル配置検討表を次の手順(i)こ(v)で作成した。以 下,現行システムのアプリケーションを現行AP,現行システムのDBを現行DB, 連携システムのDBを連携DB,連携システムのアプリケーションを連携APという。 (i)〔販売業務改善の要件}】から,店舗販売業務とOL販売業務に共通する情報を 保有していて,双方で情報の参照,追加更新が発生するテーブルには,情報共有 対象欄に“WO”を記入する。 (ii)情報共有対象でないテーブルのうち,情報共有対象のテーブルから参照される テーブルには,参照先欄に“〇"を記入する。 (ii)(1)又は(ii)に該当するテーブルについて,現行システムの処理で追加・更新さ れるものは現行APを,販売統括部によって追加・更新されるものは連携APを追 加・更新の起点欄に記入する。追加・更新されない場合は空欄にする。 (iv)追加・更新の起点が現行APであるテーブルについて,現行DB及び連携DB の両方にテーブルを配置した場合に,現行DBの一方での追加・更新を,他方にも 同期させる必要があれば双方向の同期欄に“〇"を記入する。 (v)(i)(ii)のいずれにも該当しなければ配置方法やとし,該当する場合は,次の ように配置方法を決める。 ・(損)において,追加・更新の起点が連携APの場合は,配置方法@とする。 ・(iv)において,双方向の同期が必要でない場合は,配置方法③とする。 ・(iv)において,双方向の同期が必要な場合は,配置方法おとする。ただし,テー ブルの主キーの値が等しい行に対する更新が同時に発生する可能性がある場合に は,配置方法6とする。 ー13一 表4テーブルの配置方法 配置方法 、・現行DBのテーブルをそのまま残し,連携DBには配置しない。 ACID|apy,現行DBを参照・追加・更新する。 ・現行DBのテーブルを,連携DBと現行DBの両方に配置する。 配置方法の・APは,連携DBを追加・更新し,現行DBを参照する。バッチ型で,1か所か ら複数か所にデータを分散Hするレプリケーションによって,現行DBに同期さ せる。 ・現行DBのテーブルを,連携DBと現行DBの両方に配置する。 配置方注③・APは,現行DBを追加・更新し,連携DBを参照する。バッチ型で,複数か所 のデータを1か所に集約するレプリケーションによって,連携DBに同期させ る。 ・現行DBのテーブルを,連携DBと現行DBの両方に配置する。 配置方法の・APは,現行DBを参照・追加・更新する。イベント型で,双方向に同期をとる レプリケーションによって,連携DBに同期させ,必要であれば他方の現行DB にも同期させる。 ・現行DBのテーブルを廃止して連携DBに配置する。新規のテーブルは,連携 配置方法⑥DBだけに配置する。 ・APは,DB相互接続機能によって連携DBを参照・追加・更新する。 表5テーブル配置検討表(未完成) _情報共有追加・更|双方向= —"参5 |モリアァst~é“‘t;*dSSC*é‘dLSC“COOSC‘S;*Saw a[|THR Ee KO scr D2 店舗。 。||〇BAP||CHRO ||※※||.| ||mmm回 商品。 。。|〇O||連携AP||配置方法② 商品画像・関連商品|||||配置法① 会。|O||夷和ml Oo|mM 店舗在庫eee eee|Lic| 入庫在庫eae eee)Lia) nae ee TT ee) 配送指示・配送指示明細|tT|配置方法⑤ 注記網掛け部分は表示していない。 [連携DBの設計・実装〕 1.連携DBのテーブル設計 表5のテーブル配置検討表に基づいて,情報共有対象のテーブル構造を検討した。 “Mim”,“BA”テーブルについては,データを統合した上で連携DBに配置する ことにして,図3のテーブル構造を作成した。 1)“商品"テーブルの統合では,現行DBの“商品”テーブルの全情報をもつ。 さらに,店舗販売区分,OL販売区分の列を追加し,各チャネルでの販売対象商 品か否かを表す値を設定する。 (2)“SR”テーブルの統合では,次のようにテーブルを作成する。 ①OL販売システムの“会員"′テーブルを連携DBに複製する。複製したテー ブルに店舗販売システムの“会員”テーブルの全行を追加する。追加の際,店 舗会員番号ごとに新たな会員番号を付与し,店舗会員とOL会員とを合わせて 一意に識別する。店舗会員番号はそのまま使用するので,店舗会員番号と新た な会員番号とを関連付ける。さらに,会員区分の列を追加し,店舗会員とOL 会員を識別する値を設定する。 ② 【販売業務改善の要件)】におけるポイントの取扱いが可能になるように,必 要な列を追加する。 SSH 会員(会員番号,氏名,住所,電話番号,性別,生年月日,メールアドレス, 店舗販売区分,OL販売区分,…) 使用可能ポイント,本年ポイント,前年ポイント,前々年ポイント,店舗コード, 図3情報共有対象のテーブル構造(未完成) 2.会員の個人情報漏えい防止対策 “会員”テーブルを表4の配置方法⑤とする場合,店舗の従業員が全情報を参照 することになり,情報漏えいのリスクが高まるので,次のアクセス制限を行う。 (1)アクセス制限の内容 ①会員番号,氏名,ポイントは,全従業員に全会員の情報参照を許す。それ以 外の情報(以下,機密情報という)の参照は,必要とする特定の役職及び特定 の担当職務の従業員に限定する。 ②機密情報の参照が認められた従業員であっても,参照できるのは従業員が所 属する店舗の登録会員の情報だけに限定する。 ー15一 (2)アクセス制限の実装 ①OL販売では,AP用のユーザIDとパスワードを用いてDBに接続する。ユ ーザIDとパスワードはAP内に隠ぺいする。 ②店舗販売では,従業員ごとのユーザIDとパスワードを用いてDBに接続す る。ユーザIDは従業員IDと同一で,パスワードは従業員が各自で管理する。 ③"従業員"テーブルは,表4の配置方法③とし,連携DBにも配置する。 ④図4,5のSQL文を使ってビューを作成し,テーブル及びビューへの適切な アクセス権限を付与する。機密情報へのアクセス制御には,認可役職ロール, 認可担当職務ロールを用いる。 ©図5のSQL文で作成したビューでは,従業員が所属する店舗の会員情報だ けにアクセスを限定する。ただし,ポイント統合後の店舗会員については,統 合先のOL会員情報も参照可能とする。 SELECT会員番号,氏名,使用可能ポイント,本年ポイント,前年ポイント,前々年ポイント FROM会員 図4“会員V1”ビュー作成SQL文 CREATE VIEW会員V2 AS SELECT A.*FROM会員A INNER JOIN B ON INNER JOIN C ON M5“会員V2”ビュー作成SQL文(未完成) 3.販売分析データの作成(バッチ処理) 現行DBの“販売",“販売明細",“注文",“注文明細"テーブルは,表4の配置 方法③とし,連携DBにも配置する。これらのテーブルのデータを元に連携DBの 販売ファクト,商品軸などの軸データをバッチ処理で作成する。 店舗販売業務,OL販売業務では,それぞれ,その日のうちに日締めを行ってい るが,日締時刻は日によって異なり,順序も決まっていない。バッチ処理中の元デ ータ更新を避けるため,両業務とも日締めが完了したときに,該当テーブルのレプ ー16一 リケーションを自動的に無効化する。そのために,図6のテーブルを,表4の配置 方法⑥として連携DBに配置し,日締め時に当該テーブルを更新する日締処理の追 加,及び当該テーブルへの操作によって実行するトリガの定義を行うことにした。 日締管理(処理年月日,店舗日締フラグ,OL日締フラグ) 注記店舗日締フラグ,OL日締フラグは,日締めの完了又は未完了の状態を表す。 図6“日締管理”"テーブルのテーブル構造 (ARSED AT) 1.販売分析業務のテーブル構造 現行店舗販売システムのテーブル構造(図1)を基に,連携DBに配置する販売 分析業務のテーブル構造を設計する。“"販売ファクト"”テーブルは,伝票番号及び 注文番号を一意に識別する販売IDを付与することにし,図7を作成した。 販売ファクト(販売ID,明細番号,店舗軸ID,商品軸TD,時間軸TD,数量,金額, 店舗軸(店舗軸TD,店舗コード,エリアコード,[」]]) 時間軸(時間軸ID,年月日,年,月,四半期,年週番号,曜日,時間帯) 図7連携DBに配置する販売分析業務のテーブル構造(未完成) 2.販売分析処理の検討 表1の処理例2について問合せの内容を整理し,表6を作成した。 表6処理例2の問合せ(KZA) ①販売ファクトに対する問合せ 中"で肖合ー ①の結果と時間軸IDで等結合し,年月日が開始 a②ReMRNC AS See日と終了日の間である行を選択 順|③[|ア]に対する問合せ|②の結果と 9レラ]ciramae|oi ©④に対する問合せ曜日,時間帯でグループ化 結果行から射影する列名及び演算曜日,時間帯,販売IDの件数

共通の文章

販売物流業務の概念データモデリングに関する次の記述を読んで,設問1こ3に答 えよ。 E社は,自動車用ケミカル製品メーカである。E社では,商品の販売物流システム を再構築することにし,業務分析の結果に基づいて概念データモデル及び関係スキー マを設計した。 業務分析の結果] 1.自社組織・得意先・商品 (1)自社組織 E社の販売物流業務に関わる拠点には,工場,物流センタ,営業所の3種類が ある。 ①拠点の種類は拠点種類区分で分類している。拠点は拠点コードで識別し,拠 点名を保持している。 ・工場は,3拠点ある。 ・物流センタは,18拠点ある。 ・営業所は,物流センタの配下に,76拠点ある。 ②工場っ物流センタ営業所の向きに商品が流れるので,個々の拠点から見 て上流を上位拠点,下流を下位拠点と呼ぶこともある。 ③本社には,幾つかの販売部がある。販売部と営業所を合わせて営業部門と 呼び,営業部門コードで識別している。営業部門が,販売部と営業所のどち らに該当するかは,営業部門区分で分類している。 (2)得意先 E社の得意先は,全国のカー用品店,自動車販売店,中古車店,自動車整備工 場,タイヤ店,石油販売店などである。 ①得意先は,店舗単位に登録し,得意先コードで識別している。 ②得意先の中には,請求書の送付先を集約させるところがあり,その場合の 請求書の送付先を請求得意先と呼ぶ。得意先が請求得意先に該当するか否か は,請求得意先フラグで識別する。請求得意先は,請求書を集約する対象の 得意先をもつ。 ー21一 ③得意先には,地域得意先と広域得意先があり,得意先区分で分類している。 地域得意先は,店舗が1~数店の規模のところであり,広域得意先は,店舗を 全国又は複数都道府県にわたって多数展開しているところである。 ・地域得意先に対する営業は,その地域得意先を受け持つ営業所が担当する。 ・地域得意先に対する納入も,同じ営業所が担当する。 ・広域得意先に対する営業は,いずれかの販売部が担当する。 ・広域得意先に対する納入は,取扱量が大きいので,物流センタから直納する。 ④広域得意先の中には,全店又は東日本と西日本のようにまとめて発注してく るところがあり,このような得意先を発注得意先と呼ぶ。得意先が発注得意先 に該当するか否かは,発注得意先フラグで識別する。まとめて発注される各広 域得意先は,どの発注得意先から発注されるか決められている。 (3)商品 E社の主な商品は,潤滑剤,整備用ケミカル用品,ガラス塗布剤などである。 ①商品は,商品コードで識別する。 ②商品には,販売期間を表す販売開始年月日・販売終了年月日,及び販売価格 を設定している。 ③商品ごとに生産する工場を決めており,生産する工場の拠点コード,生産ロ ットサイズを設定している。 ④商品には,計画生産品と補充生産品の2種類がある。 ・計画生産品は,電要予測に基づいて計画的な生産を適用する商品である。 ・補充生産品は,下位拠点から上位拠点に対する要求に基づいて生産・補充さ れる商品である。 2.業務の方式 (1)得意先への納入 ①得意先から注文を受けると,在庫を確認し,納入指示を行う。 ②注文に対して在庫が不足すると,得意先と調整して分納する。分納は,まず 納入可能な一部数量の納入指示を行う。不足分は,在庫が補充され次第,納入 指示を行う。ただし,同一の得意先からの別の注文に対してまとめて納入指示 を行うことはない。 (2)在庫保管 ー22一 ①計画生産品の在庫は,営業所及び物流センタにもたせる。 ②補充生産品の在庫は,営業所及び物流センタの他に工場にももたせる。 (3)在庫補充 ①在庫には,基準在庫数量と補充ロットサイズを設定している。 ②実在庫数量が基準在庫数量を下回った商品を対象に,1日に1回,下位拠点 から上位拠点に対して商品の要求(以下,補充要求という)を行い,上位拠点 から下位拠点に商品が補充される。 ③補充要求に対して,要求を受けた上位拠点で在庫が不足していた場合,不足 した商品を当日の補充対象から外す。翌日以降に,在庫が補充要求を満たした 時点で補充を行う。ただし,同一下位拠点からの,別の補充要求をまとめて補 充することはない。= (④)計画生産品の生産・物流 ①四半期ごとに,販売目標と販売実績から向こう12か月分の筑要を予測する。 ②予測した需要と工場の生産能力から,商品別物流センタ別に,向こう12か 月分の入庫数量を決め,月別商品別物流センタ別入庫計画を立てる。このとき, 前の四半期の計画は最新の計画に更新する。 ③月別商品別物流センタ別入庫計画は,立案時に計画値を設定し,生産入庫時 に実績値を累計する。 ④工場は,月別商品別物流センタ別入庫計画の計画値に対する実績値の割合が 低い商品について,入庫先物流センタを決めて生産し,その都度,生産入庫を 行う。 ©在庫補充の方式は,営業所だけに適用する。 (5)補充生産品の生産・物流 ①在庫補充の方式は,在庫をもつ全ての拠点に適用する。 ②物流センタでは,生産工場別に補充要求を行う。 ③工場は,上位拠点がないので,補充要求の代わりに生産要求を行う。 (6)在庫引当 ①在庫をもつ拠点では,欠品を防止するために,在庫引当を行う。 ②在庫引当ができた要求は,その要求分が出庫されるまで引当済数量に累積す る。 ー23一 3.業務の流れ 業務の流れは,計画生産品と補充生産品で異なる。 1)計画生産品の業務 計画生産品の業務には,計画立案,生産,営業所補充,地域得意先納入,広域 得意先直納の五つがある。各業務の流れを図1に示す。 —_—月別商品別物流センタ別 EF wie に 商品物流センタ別 |入庫計画生産生産入庫 生産生 sey)月別商品別物流センタ別i JY入庫計画 Papen 在庫補充要求補充出庫補充入庫。 A補充要求補充出庵|/補充入庫| (営業所)(物流センタ)(営業所)| IRO 注文納入指示納入 納入指示納入 aaa 注文納入指示納入 /納入指示納入 || sg 図1計画生産品の各業務の流れ ①計画立案 ・四半期ごと物流センタごとに,向こう12か月分の需要を予測する。 ・予測した需要と工場の生産能力から,月別商品別物流センタ別入庫計画を立 てる。 ②生産 ・工場は,月別商品別物流センタ別入庫計画の計画値に基づいて,入庫先物流 センタを決めて,商品ごとに生産し,配送する。 ・生産では,生産年月日,生産した商品,生産数量,生産した商品の入庫先物 流センタを記録する。 ・物流センタは,商品を入庫すると,月別商品別物流センタ別入庫計画の実績 値を更新し,入庫の実績を記録する。 ③営業所補充 ・営業所は,補充が必要な場合,物流センタに対して補充要求を行う。 ・補充要求では,要求年月日,要求元の拠点,要求した商品・数量を記録する。 ・補充出庫では,出庫年月日,実際の出庫数量を記録する。 ・商品を入庫した営業所は,入庫年月日,実際の入庫数量を記録する。 ③④地域得意先納入 ・営業所は,得意先から注文を受けると,納入指示を行う。 ・注文では,注文年月日,納入先の得意先,注文を受けた商品・数量を記録す る。 ・納入指示では,納入指示年月日,納入指示数量を記録する。 ・営業所は,納入指示に基づいて納入を行い,納入の実績を記録する。 ©広域得意先直納 ・販売部は,得意先から注文を受けると,納入する物流センタを決めて納入指 示を行う。 ・注文の記録は,地域得意先納入と同じである。 ・納入指示では,地域得意先納入の記録の他に,納入する物流センタを記録す る。 (2)補充生産品の業務 補充生産品の業務には,営業所補充,地域得意先納入,広域得意先直納,物流 センタ補充,生産の五つがある。このうち,営業所補充,地域得意先納入,広域 得意先直納は,計画生産品と同一業務なので,ここでは物流センタ補充,生産の 業務の流れだけを,図2に示す。 =B= の :在庫補充要求補充出庫補充入庫 as’ 在庫生産要求生産生産入庫 図2補充生産品の各業務の流れ D物流センタ補充 ・物流センタは,補充が必要な場合,工場に対して補充要求を行う。: ・補充要求では,要求年月日,要求元の物流センタ,要求した商品及び要求数 量を記録する。 -工場は,補充要求に対して補充出庫を行う。補充出庫では,出庫年月日, 実際の出庫数量を記録する。| ・商品を入庫した物流センタは,入庫の実績を記録する。補充入庫では,入庫 EAA,実際の入庫数量を記録する。 ②生産 ・工場は,補充が必要な場合,生産要求を行う。 ・生産要求では,要求年月日,要求時刻などを記録する。 ・生産要求に基づいて生産し,生産入庫を行う。生産では,生産年月日,生 産数量,生産完了時刻を記録する。生産入庫では,実際の入庫数量,入庫 完了時刻などを記録する。 ・要求時刻,生産完了時刻,入庫完了時刻は,正確なリードタイムを計測する ために記録するものである。 [概念データモデルと関係スキーマの設計〕 概念データモデル及び関係スキーマの設計を,次の手順及び方針で行った。 (1)はじめに,計画生産品を対象として設計する。 ①概念データモデルは,マスタ・在庫領域とトランザクション領域を明示して作 oR一 成する。設計した概念データモデルを図3に,関係スキーマを図4に示す。 ②認識する必要がないサブタイプは切り出さない。 (2)次に,補充生産品を対象に設計した場合のデータ構造を検討する。 ①マスタ・在庫領域について,認識すべきサブタイプ,属性を洗い出す。 ②図2に示した業務の範囲について,分析対象の属性を洗い出し,表1に示す エンティティタイプと属性の対応表を用いて整理する。 ③表1に基づいて,図5に示す補充生産品を対象に設計した場合のトランザク ション領域の概念データモデルを作成する。 (3)最後に,上記(①)と(②で設計したエンティティタイプの共通性を評価し,概念デ ータモデルを統合する。 ①同じ属性で構成される場合,同一のエンティティタイプとする。 ②共通でない属性が一方にだけ存在する場合,存在する方のエンティティタイプ を他方のサブタイプとする。 ③共通でない属性が双方に存在する場合,共通部分をスーパタイプとし,共通で ない部分をサブタイプとする。 ④概念データモデルを統合することで,統合前のエンティティタイプ名が不適切 になることがあるので,適切なかエンティティタイプ名を付与する。 a i —_S ee(a fa HE ーー 得意先 地域発注- 得意先得意先 物流センタ別 月別商品別 入庫計画 A A 地域 得意先 i注文 Ki ih 得意先ie 注文納入指示 トランザクション領域| 図3計画生産品を対象に設計した概念データモデル(未完成) |(マスタ・在庫領域)間汗押押 Me maーk[ーーー。で| |工場(拠点コード,生産ライン数)| !物流センタ(拠点コード,配送地区名)| |営業所(拠点コード,|b|)| |営業部門(営業部門コード,|<YY) |販売部(営業部門コード,販売部門名) |得意先(得意先コード,得意先名|qa|| |請求得意先(得意先コード,集約対象得意先数) |地域得意先(得意先コード,担当営業所拠点コード)| |広域得意先(得意先コード,発注得意先テラグ,|。。 |発注得意先(得意先コード,対象得意先数)| |商品(商品コード,商品名,|"””"f|販売開始年月日 販売終了年月日販売価格,生産ロコットサイズ,最終計画年月日)| |em uk,商品=-ド,|パgg !| |月別商品別物流センタ別入庫計画CEA,商品コード,物流センタ拠点コード,ate, 実績値) |注文(注文番号,注文年月日) |地域得意先注文(注文番号,地域得意先コード) |sve Ges,[On |注文明細(注文番号,注文明細番号,商品コード,注文数量) 納入指示(MARS,注文番号,納入指示年月日) |広域得意先納入指示MASS,[i| 納入指示明細(納入番号,納入明細番号,注文番号,注文明細番号,納入指示数量)| LWA(納入番号,納入年月日)| |納入明細(納入番号,納入明細番号,納入数量)| |補充要求(補充要求番号,補充要求年月日,|。」 |補充要求明細(HERES,補充要求明細番号,商品コード,補充要求数量) !補充出庫(補充番号,補充要求番号,補充出庫年月日) |補充出庫明細(補充番号,補充明細番号,AERIS,補売要求明細番号,補売出庫数量)| |補充入庫(補充番号,補充入庫年月日) |補充入庫明細(補充番号,補充明細番号,補充入庫数量) |生産(生産番号,生産年月日,生産数量,商品コード,|。k|): |生産入庫(生産番号,生産入庫年月日,生産入庫数量) 図4計画生産品を対象に設計した関係スキーマ(未完成) 表1補充生産品を対象に設計したエンティティタイプと属性の対応表(未完成) 補|営|物|補|補|補|補|補|生|生|生 Fi|S|ht||KH|||||ee] 要|所|セ|要|出|出|入|入|要入 求|補|ン|求|庫|庫|庫|庫|求庫 充|タ|BA明明 要fi細細細 属必x2 求 axures[x[xr]|||||||| 補充要求年月fal|||||||||] 営業所拠点コード|fart||||||||| |物流センタ拠点コード。||||||||||| |補y要求明細番号|||||||||||| |補充要求数量"|||||||||||]| |補充生産品商品コード||||||||Jarl|| janes=||||||||||] axumene|||||||||]||| |補放明細番号。。|||||||||]|| |補上数量。||||||||||] mame||||||||』|]| jamivcammce dT||||||||||| ames CT||||||||IKklsmlkrl emerene||||||||Jal|| |生産要求時刻。||||||||IAl|| |生産要求数量"||||||||laAl|| jemeae。|||||||||jaAl |和産数久"|||||||||la4l| emer|||||||||jAl| [Ed。||||||||||jal |生産和庫教生||||||||||Al |入上完了時刻。||||||||||IA 注記K:キキー履性 KF:主キー属性かつ外部キー属性 A:従属属性 AF:従属属性かつ外部キー属性 ハハハL\ EJ ra)EA Ea 地域ーー EX補充要求 図5補充生産品を対象に設計したトランザクション領域の概念データモデル(未完成) 解答に当たっては,次の7点に従うこと。 ①④巻頭の表記ルールに従う。ただし,エンティティタイプ間の対応関係にゼロを含 むか否かの表記は必要ない。 ②エンティティタイプ間のリレーションシップとして『多対多"のリレーションシ ップを用いない。 ③エンティティタイプ名及び属性名は,それぞれ意味を識別できる適切な名称とす る。 ④関係スキーマは第3正規形の条件を満たす。 ⑤リレーションシップが1対1の場合,意味的に後からインスタンスが発生する側 に外部キー属性を配置する。 ©サブタイプ固有の属性が認識可能な場合に,サブタイプを切り出す。 QDサブタイプを切り出した場合,外部キーは,スーパタイプ又はサブタイプのいず れか適切かがエンティティタイプに配置し,それに基づいて,リレーションシップも 適切ながエンティティタイプの間に引く。また,外部キー以外の従属属性についても, 適切なかエンティティタイプに配置する。