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

共通の文章

運用に関する次の記述を読んで,設問に答えよ。 A社は,バーコードを用いたキャッシュレスの決済サービス,及び商品購入などに 応じて一定のポイントを付与するポイントサービスを提供している。A社では,ポイ ントサービス利用件数の急増を受けて,システムの変更を検討している。 [業務・現行システムの概要〕 1.サービスの概要 (1)決済サービス ①決済サービスを利用する人(以下,決済会員という)は,決済会員登録を 行い,金融機関などから一定の金額を決済サービスに入金した上で,物品購 入などの支払に充てる。人入金及び支払に伴う残高を決済残高という。 ②決済サービスに加盟する事業者(以下,決済加盟店という)は,決済サー ビスへの加盟申請,審査を経て決済加盟店登録を受ける。 ③決済会員は,スマートフォンなどの携帯端末,決済加盟店の店舗に設置さ れたPC,POSなどの端末(これらをまとめて,以下,端末という)を使用し て,バーコードを読み取ることで支払を行う。同じ決済会員が同時に複数の 支払を行うことはない。 ④決済は,決済会員の決済残高から支払金額を差し引くことで完了する。 ©A社は,月に1回まとめて決済金額を決済加盟店に支払う。 (2)ポイントサービス ①ポイントサービスを利用する人(以下,ポイント会員という)は,ポイン ト会員登録を行ってポイントサービスを利用する。 ②ポイントサービスに加盟する事業者(以下,ポイント加盟店という)は, ポイントサービスへの加盟申請,審査を経てポイント加盟店登録を受ける。 ③ポイント会員は,ポイント加盟店での支払,くじ引き,イベント参加など によってポイントを獲得する。 ④獲得したポイントには,有効期限の年月が決まっている。獲得したポイン トはポイント残高として貯めておき,支払に充てることができる。 ー7ーー ©獲得したポイントは,すぐにポイント残高に反映されることもあれば,B 日以降になる場合もある。 (3)サービス間の連携 決済金額の一部をポイントで支払い,残りを決済残高から支払う場合など, 両方のサービスを連携した決済を行うことがある。 2.システム構成 現行システムのシステム構成を図1に示す。決済サービス,ポイントサービスそ れぞれに専用のサーバ及びRDBMSを用いている。サーバ上ではサービスに用いるア プリケーションプログラム(LAF,APという)が稼働している。両サービスを連 携した処理は,決済APを介して決済DB,ポイントDBの両方にアクセスする。 — ee しーーwpトド |ere|ーー Nee H 1 図1現行システムのシステム構成 3.テーブル構造 決済サービス,ポイントサービスのテーブル構造をそれぞれ図2,3に,ERB 性の意味・制約を表1に示す。なお,属性名の#は番号,Cはコード,Fはフラグを 略した記号である。 決済加盟店(決済加盟店#ポイント加盟店#名称,支払先口座,…) 店舗(決済加盟店#店舗4決済方式,所在地,…) 決済会員(決済会員!ポイント会員#表示名,BRASH,認証,…) 決済残高(決済会員#,BS) 入金履歴(決済会員#ASH,ASA,入金金額,入金方法) 決済履歴(履歴決済加盟店#店舗#決済会員#決済日,決済金額,使用ポイント数) 加盟店支払(決済加盟店#支払年月,MOA,支払予定日,支払予定金額) 図2決済サービスのテーブル構造(一部省略) な8 ms ポイント会員ランク(ポイント会員ランクC,名称,達成ポイント数) ポイント獲得方法(ポイント獲得方法C,名称) ポイント付与率(ポイント獲得方法C,ポイント会員ランクC,付与倍率) ポイント加盟店(ポイント加盟店記名称,所在地,…) ポイント会員(ポイント会員#4ポイント会員ランクC,氏名,生年月日,住所,認証,…) ポイント残高(ポイント会員#有効期限年月,FER,有効F) 会員ランク履歴(ポイント会員#,変更日,ポイント会員ランクC) ポイント獲得履歴(履歴れポイント会員ポイント加盟店#ポイント獲得方法C,獲得日, 有効期限年月,獲得ポイント数,残高反映F) ポイント使用履歴(履歴#ポイント会員#ポイント加盟店#使用日,使用ポイント数) 図3ポイントサービスのテーブル構造(一部省略) |表1主な属性の意味・制約 意味・制約 決済方式バーコードの読取りを利用者の端末,店舗の端末のどちらで行うかを表す区分 決済会員ごとに決済残高への入金の都度払い出す連番 入金方法入金時に使用した銀行口座,クレジットカードなどの情報 ポイント獲得方[ポイント加盟店での支払,くじ引き,イベント参加などポイント獲得の方法を表 法Cすコード 有効期限年月ポイントが有効な期間は,獲得方法によって異なる。"ポイント獲得履歴"テー mab"|ブルには獲得したポイントの有効期限年月を設定し,"ポイント残高"テーブル には有効期限年月どとにポイントの残数を記録する。 履歴#“決済履歴","ポイント獲得履歴",“ポイント使用履歴"テーブルの履歴# には,それぞれに一意な番号を自動的に設定する。 有効Fに 有効期限年月が現在の年月以降の場合はTRUE,それよりも前のものはFALSEを設 定する。 残高反映F獲得ポイント数を“ポイント残高"テーブルの残数に加算済みの場合はTRUE,未 om加算の場合はFALSEを設定する。 4.主な処理 各サービスの主な処理の内容を表2に,表2中のS1,S2,P2,P3の処理概要とSQL 文を表3て6に示す。各処理はーつ以上のステップから成る。表2一6中の二重引用符 で囲んだ名前は,M2,3中のテーブル名である。 guess 9‘a 表2主な処理の内容 $1決済残高入|決済会員の指示によって金融機関からの入金実行を記録し, 決済サービ金処理“決済残高"の残高に反映する。 ス52決済残高消|決済会員の決済指示を受けて,“決済残高"の残高を消費し 費処理て,内容を“決済履歴に記録する。 P1ポイント獲|ポイント会員がポイントを獲得する都度,獲得したポイント数 得処理を“ポイント獲得履歴"に記録する。 ポイントサP2獲得ポイン|任意のタイミングで,ポイント会員のポイント獲得履歴を"ポ ービスト反映処理|イント残高"の有効期限年月該当行に反映する。 P3ポイント消|ポイント使用指示を受けて,“ポイント残高"の残数を消費し 費処理て,内容を“ポイント使用履歴"に記録する。 表3 S1の処理概要とSQL文 処理概要(上段)とSQL文(下段) gia,RRO"決済残高の壮高に入金金額を加算して更新するuh 5 os UPDATE決済残高SET残高=残高+:hv3 WHERE決済会員#=:hv1 sg REの最終入金#を完新するSu UPDATE決済会員SET最終入金#=最終入金#+1 WHERE決済会員#=:hv1 人金履歴"の入金衣に更新後の最終入金#を設定して行を追加する。 51-3 INSERT INTO入金履歴(決済会員AGH,ABA,入金金額,入金方法) SELECT決済会員#れ最終入金れ:hv2,:hv3,:hv4 FROM決済会員 WHERE決済会員#=:hv1 注記ホスト変数hv1てhv4には,決済会員#ABA,入金金額,入金方法をそれぞれ設定する。 表4 S2の処理概要とSQL文 処理概要(上段)とSQL文(下段) 決済会員の"決済残高"の残高が決済金額以上であることを確認し,残高が不足して S2-1いれば,戻り値に残高不足エラーを設定して処理を終了する。ーー_| SELECT残高FROM決済残高WHERE決済会員#=:hv1 AND残高>=:hv5 FOR UPDATE co-。|決済会員の決済華高の残高から決済金額を減算して更新する。 UPDATE決済残高SET残高=残高-:hv5 WHERE決済会員#=:hv1 決済履歴の各列に対応するホスト変数の値を設定して行を追加する。 S2-3 IINSERT INTO決済履歴(決済加盟店店舗決済会員#決済日,決済金額, 使用ポイント数)VALUES(:hv2,:hv3,:hv1,:hv4,:hv5,:hv6) 注記ホスト変数hv1てhv6には,決済会員#決済加盟店店舗#決済日,決済金額:使用ポイ ント数をそれぞれ設定する。 表5 P2の処理概要とSQL文(未完成) 指定されたポイント会員級について“ポイント獲得履歴"からポイント残高未反映の行 の獲得ポイント数を有効期限年月どとにまとめて,“ポイント残高"の該当行があれ ば残数に獲得ポイント数を加算して更新し,行がなければ残数に獲得ポイント数を設 定して行を追加するPTPOUUCCYTPTTTYTPTTTTTETPULUULULLLLUULLLULTLLLTITT RE a et Ca 。。[USING(SELECTポイント会員aannasetea,a|AS加算ポイント雪 FROMポイント獲得履歴WHEREポイント会員#=chvi AND|b| GROUP BYポイント会員#有効期限年月)B ON(A.ポイント会員#=B.ポイント会員#AND A.有効期限年月=B.有効期限年月) WHEN MATCHED THEN UPDATE SET WHEN NOT MATCHED THEN INSERT(ポイント会員有効期限年月,残数,有効F) VALUES([dg|,TRUE) "ポイント獲得履歴"の該当行の残高反映Fの値を更新する。 cos(PEGE ae生生ie WHEREポイント会員#=:hv1 AND残高反映F IS FALSE 注記ホスト変数hylにはポイント会員#を設定する。 表6 P3の処理概要とSQL文 指定されたポイント会員#について“ポイント残高"から有効期限内の残数を集計して 求めた使用可能ポイント数が使用ポイント数に満たない場合は,戻り値にポイント不 P3-1足エ7.を設定して処理をia fするbe eee vecvereerrerecsceseecescessecnnctecstocbececcccvocccstuassesccsccsscesceeoences SELECT SUM(残数)AS使用可能ポイント数FROMポイント残高 WHEREポイント会員#=:hv1 AND有効F IS TRUE ①のSQL文に基づくカーソルによって,“ポイント残高"からポイントが有効な行を有 効期限年月の昇順に読み込み,行ごとに残数を使用ポイント数に合わせて消し込む。 ホスト変数lv1に消し込むポイント数(以下,消込ポイント数という)を,lv2に有効 pag|凌限年月を設定して②の更新を行い,使用ポイント数を全て消し込むまで繰り返す。 ①SELECT有効期限年月,残数FROMポイント残高WHEREポイント会員#=:hv1 AND 有効F IS TRUE ORDER BY有効期限年月ASC @UPDATEポイント残高SET残数=FRR-:lv1 WHEREポイント会員#=:hv1 AND 有効期限年月=:lv2 js fis>Fame 2 LEROR ENE-CORENTS.__.. 使用ポイント数)VALUES(:hv1,:hv2,:hv3,:hv4) .ポイント使用履歴"の各列に対応するホスト変数の値を設定して行を追加する。 注記ホスト変数hv1てhv4には,ポイント会員ポイント加盟店#,使用日,使用ポイント数をそ れぞれ設定する。 5.現行システムで使用するRDBMSの排他制御機能 (1)トランザクションのISOLATIONレベルごとの排他制御は,次のとおりである。 ①READ COMMITTEDでは,行の参照時に対象行の共有ロックを取得し,SRR 了時に解放する。行の更新時に対象行の専有ロックを取得し,トランザクシ ョン終了時に解放する。 @REPEATABLE READでは,行の参照時に対象行の共有[ロックを,行の更新時 に対象行の専有ロックを取得し,トランザクション終了時に解放する。 ③SERIALIZABLEは,行の参照時又は更新時に表単位の専有ロックを取得し, トランザクション終了時に解放する。 (2)READ COMMITTED及びREPEATABLE READでは,SELECT文にFOR UPDATE句を指 定すると,行の参照時に対象行の専有ロックを取得し,トランザクション終了 時に解放する。 [現行システムの決済処理〕 決済処理では,表2中の処理S2及びP3を-つのトランザクションとして実行する ために,2相コミットプロトコルを用いている。 1.決済処理の流れ‘ 決済処理の正常実行時のシーケンス図を図4に示す。図中の①~て⑬は実行の順番 を,時点A,Bは実行の流れにおける特定の時点を表している。 ①決済指示aomme=7 3 @P3実行指示 ⑥コミット準備指示 iM ⑧コミット準備指示 —= ⑩コミット実行指示 ⑪コミット完了__ ~⑫コミット実行指示 しGasy bet||ee 図4決済処理の正常実行時のシーケンス図(未完成) 2.障害からの回復 決済処理の実行中に障害によってポイントDBが異常終了する状況を想定した障 害・回復の事例を表7にまとめた。表中の時点A,Blt,図4中の時点A,Bに対応 Ls TiNSs 表7決済処理中の障害・回復の事例(未完成) 事例 決済処理中の時点AでポイントDBが障害によって異常終了した。障害除去後に再始動し 事例11の寺態となった。決済APは,ポイントDBに状態を問い合わせ。決済DB及びポイントDB ||たところ,ポイントDBにはコミット準備のログがあり,トランザクションは未コミット に[|e|を行った。 決済処理中の時点AでポイントDBが障害によって異常終了した。障害除去後に再始動し 事例2たところ,ポイントDBにはコミット準備のログがなく,トランザクションはロールバッ クされた。決済APは,ポイントDBに状態を問い合わせ,決済DBに|Ff eae た。 決済処理中の時点BでポイントDBが障害によって異常終了した。障害除去後に再始動し 事例3|たところ,ポイントDBはロールフォワードによってデータベースを回復した。決済AP lt,ポイントDBに状態を問い合わせ,Lo|した。 決済処理中の時点AでポイントDBが障害によって異常終了した。⑦復旧までの時間が長 事例4|に全ることで,業務上の不都合が生じたので,決済DBにおいて仕掛り中のトランザクシ ョンをヒューリスティックな決定によって全てコミットした。障害除去後の再始動におい て,ポイントDBは未コミットのトランザクションをロールバックした。 [システム変更案の検討] ポイントサービスでは,ECサイトを運営する加盟店の増加によって,サービス利 用件数が急増し,ポイントDBの応答性能,可用性の低下が問題になっている。その 対策として,次のシステム変更案を検討している。 1.システムの構成変更 検討中のシステム構成を図5に示す。業務機能別に会員サービス,決済サービス, ポイントサービスに分け,サービスごとに専用のサーバとデータベースを配置す る。各サービスには独立した疎結合のAP及びデータベースを用いて,サービス内 部の実装は隠蔽する。サービスに連携するアプリケーションプログラミングイン タフェース(LAF,APIという)だけを公開し,APIを呼び出すごとに単一のトラ ンザクションとして処理する。端末からのアクセス時には,会員サービスを入り 口にして他のサービスに連携する。 ーー13ーー Smyパ||As|下デ Te Nae ーー_NGS] 図5検討中のシステム構成 (1)会員サービス ①決済会員、ポイント会員の会員情報の登録,端末からの接続認証など会員 に関わる機能をもつAP,及び後述する複数サービスが関与する処理の実行制 御を担うAPを配置する。 ②会員DBには,現行システムと同じRDBMSを使用する。"決済会員",“ポイ ント会員ランク”及び“ポイント会員テーブルを配置し,登録,認証に使 用する。会員情報の登録,変更は他のサービスにも連携する。 (2)決済サービス QD決済APは,ポイントサービスと連携する処理を無効にすることを除いて変 更せず,APIを決済APに連携することで,特定の機能を呼び出して実行する 方式に変更する。 ②決済DBは,BT RDBMSのデータベースをそのまま使用する。 (3)ポイントサービス ①ポイントAPは応答性能,可用性を高めるために再構築する。APIをポイン トAPに連携することで,特定の機能を呼び出して実行する方式に変更する。 ②ポイントDBをNoSQLに分類されるデータベースに変更し,図3中の全ての テーブルのデータを移行する。新しいポイントDBは,次の特徴をもつ。 ・ワイドカラムデータストアをもち,複数ノードにデータを分散して配置す ることで,高速性,高可用性を実現している。 ・RDBMSにおけるテーブルと同様に,列及び主キーを定義できる。外部キー は定義できない。CRUD操作命令を行う言語をサポートしていて,表3一6の SQL文と同様の操作を記述できる。 ・複数のCRU操作命令をまとめて一つのトランザクションとして実行する機 能はなく,CRUD操作命令の終了時点でデータへの操作が確定する。 ー14一 ・2相コミットを実現する機能はない。 2.処理方式の設計 現行の2相コミットに替えて,次の処理方式を検討している。検討に当たって, ポイントDBに格納するデータの設計には,RDBMSのテーブル構造を用いる。 (1)処理方式 ①複数サービスが関与する処理の実行制御を担うAP(以下、オーケストレー ターという)を会員サーバに配置する。 ②端末からの要求"とにオーケストレーターを割り当て,他サービスへの要 求送信と結果受信とを同期的に行うことで,処理を順に実行していく。 ③オーケストレーターは,ワークフローの機能をもち,登録した処理を状態 に応じて実行していく。タイムアウトなどの例外によって処理が異常終了し た場合には,処理が成功するまで一定回数のリトライを行う。 ④リトライを経ても処理が失敗した場合,オーケストレーターは,それ以前 に終了した処理について,ワークフローの逆方向に取消処理を順に実行する。 取消処理では,データの変更を伴う場合に,そのデータ変更を取り消すトラ ンザクション(以下,補償トランザクションという)を実行する。 (2)実行制御テーブルの追加 会員DBに“決済指示"テーブルを追加し,オーケストレーターによるトラン ザクションの実行状態の記録,実行の制御に用いる。追加するテーブルのテー ブル構造を図6に示す。“決済指示”テーブルの決済指示#は,決済指示ごとに 一意な番号を自動採番し,トランザクションの識別子として使用する。オーケ ストレーターは,処理実行の指示及び補償トランザクション実行の指示に合わ せて,“決済指示”テーブルに対応する行の全列の値を他サービスに連携する。 使用ポイント数,決済指示日時,処理ID,ステップ,モード,状態) 注記1処理ID,ステップには仕掛り中の処理について表2~6 OMB ID,ステップのいずれかを 設定する。モードには通常モード,取消モードのいずれか,状態には進行中,BT,失敗の いずれかを表す値を設定する。 注記2外部キーは会員DBに配置するテーブルとの間にだけ設定する。 図6追力するテーブルのテーブル構造 ー15一 (3)決済処理の流れ 決済処理を次のように実行することにした。 OQ決済サービスでは,S2を一つのAPIとして実行する。 @ポイントサービスでは,P3のステップP3-1~P3-3のそれぞれに対応する APIを用意し,会員サービスはAPIを順番に実行する。 ③会員サービスでは,他のサービスへの実行指示に対する処理結果を"決済 指示テーブルの状態に記録していく。 検討中の決済処理の正常実行時のシーケンス図を図7に示す。図7 POO~ ⑯⑮は実行の順番を,時点CEは実行の流れにおける特定の時点を表している。 L__owmen| 決済指示登録: @$2実行指示 の3完了 Me siTiiR[ の1夫了|し條Ne 4) ⑧決済指示更新|@ro-2 serie _oo O27____|La ⑪決済指示更新rsa徐行 3完了|し但RE To(⑬決済指示更新|[ 図7検討中の決済処理の正常実行時のシーケンス図 3.テーブル構造及び処理の変更 (1)リトライへの対応 図7中の実行指示に対応する処理の中には,リトライによる実行指示を受け たときに,重複更新の発生が懸念されるものがある。これを避けるためのテー ブル構造及び処理の変更を行う。①決済サービスでは,対策として図2中の一 つのテーブルに列を一つ追加し,処理S2の先頭にステップを一つ追加する。ポ イントサービスでも同様の対策を行う。 ーRm (2)ポイントDBの整合性確保 表6の処理P8は,ステップごとにデータ操作が確定するので,ステップ実行 の合間に他のトランザクションから同じ会員のデータ更新があると,ポイント DB内のデータに不整合が生じるおそれがある。これを防ぐために“ポイント会 B”テーブルに更新中Fの列を追加してTRUE又はFALSEを設定した上で,©P2 及びP3に,それぞれ同じ内容の処理を行うステップを追加する。 4.補償トランザクションの設計 ここまでの検討結果を踏まえて,決済処理の補償トランザクションを表8にまと めた。表8中の処理IDは表2の処理ID,表8中のステップは表4,。6のステップに 対応し,補償トランザクションは,図7中の実行指示と同じ単位で実行するものと する。 表8決済処理の補償トランザクション(未完成) 処理|_補償-説明 |1[ae|-|だけでデータの変更がない。| rst|不要|-|参照だけでデータの変更がない。 7.⑤使用ポイント数を有効期限ごとの残数から消費した消込 (33|ま|oF pee ee 注記1補償要否には変更の取消しが必要ならば『要"を,それ以外は“不要”を記入する。 注記2補償可否には,現行システムのテーブル構造を前提に変更の取消しが可能ならば『可"を, 可能でなければ“不可”を,補償が不要であれば“-"を記入する。 注記3説明には,補償不要の場合は不要の理由を,補償不可の場合は取消しができない理由を, それ以外は,補償処理の概要を記入する。 注記4網掛け部分は表示していない。 5.障害からの回復 表8の補償要否が“B’のステップは,全て補償可否が“可”となるように対策 を行った上で,決済処理実行中にポイントサービスが障害によって停止する状況 を想定した障害・回復の事例を表9にまとめた。表中の時点CEは,図7中の時 AC~TEに対応する。 ーー17= 表9決済処理中の障害・回復の事例 指示を一定回数リトライ後,S2の取消実行指示を行った。 指示を一定回数のリトライ後,P3-1,S2の取消実行指示を順に行った。 指示を一定回数のリトライ後,P3-2からS2までの取消実行指示を順に行った。

共通の文章

る次の記述を読んで,設問に答えよ。 B社は,宅配ピザチェーンである。B社では,店舗資材配送システムの再構築を進 めており,業務分析を行い,概念データモデル及び関係スキーマを設計した。 現状の業務分析の結果] 1.社内外の組織に関連する資源 (1)全国を対象に,人口分布及び道路状況を考慮して幾つかの郵便番号の指す区 域を東ねて地区として設定している。地区は地区コードで識別する。 (2)首都圏及び地方中核都市のベッドタウンに重点的に店舗を展開しており,約 500店がある。店舗は店舗コードで識別し,いずれかの地区に立地する。 (3)物流センター(以下,DCという)は全国に12あり,DCコードで識別する。 ①DCは,幾つかの地区を東ねて,それらにある店舗を配送対象にしている。 ②DCは,店舗への資材の配送及び調達先からの資材の受入れを行う。 ③DC内の倉庫には86一1290程度の区画があり,DCごとに区画番号で識別する。 区画のほとんどは冷蔵保管の機能で,残りの一部が常温保管と冷凍保管の機 能となっている。区画がいずれの機能かは,機能区分で分類する。 ④区画は,幾つかの棚に仕切られており,棚が幾つあるかの棚数をもつ。 ©Mit,区画ごとに棚番号で識別する。 (4)DCから店舗へ配送するトラックのルートを整備している。ルートはDCごと のルート番号で識別し,車両番号をもつ。 ①ルートの店舗への納入は13~16時の間に終わるように設定している。 ②ルートごとに店舗への納入順を決めている。 (5)資材の調達先をベンダーと呼び.ベンダーコードで識別する。 2.商品及び資材に関連する資源 (1)店舗で販売する商品は,商品コードで識別し,商品名をもつ。 ①商品の種類には,EV,追加トッピング,サイドメニュー,ドリンクがあ り,商品種類区分で分類する。 ②商品には,ピザであればマルゲリータ,ハワイアンなど,サイドメニュー であればフライドチキン,サラダなどがある。 ー20一 ③ピザ及び追加トッピングには,SM,Lの3サイズがある。 ④ドリンクには,MサイズとLサイズの2サイズがある。 ©全てのサイドメニューはMサイズの1サイズだけである。複数のサイドメ ニューの組合せ及び入れる個数の違うものは,別の商品としている。 ©ピザのようにサイズのある商品もあるが,商品はサイズ別には登録しない。 商品には,その商品に幾つサイズがあるかのサイズ数をもつ。 QDハーフ&ハーフなどの組合せ商品は,マルゲリータ&ハワイアンのように 商品名を付けてあらかじめ全ての組合せを登録する。 ⑧商品の販売には,定番商品,期間限定商品,新商品があり,商品販売区分 で分類する。 ・定番商品は,その商品の前年日販数をもつ。 ・期間限定商品は,販売期間の開始と終了の年月日をもつ。 ・新商品は,3か月の評価期間の売れ行きで判断し,定番化するか否か決め るもので,販売開始の年月日と定番化判断の結果をもつ。 (2)資材は資材コードで識別し,資材名,調達先ベンダーコードなどをもつ。 ①資材には,食材と梱包材がある。梱包材は,調理したビザやサイドメニュ ーの梱包に用いる。資材がいずれであるかは食材梱包材区分で分類する。 ②資材が,冷蔵保管,常温保管,冷凍保管のいずれの対象かを保管温度帯区 分で分類する。 ③定番商品に用いる食材及び梱包材を共通資材と呼ぶ。共通資材には,食材 であればピザ台,チーズ,サラミ,Nb,カット野菜,食用油などがあり, 梱包材であれば商品共通の和やポリ袋などがある。3か月平均単価をもつ。 ④期間限定商品と新商品に固有で用いる食材及び梱包材を企画資材と呼ぶ。 企画期間単価をもつ。 ©資材が,共通資材であるか企画資材であるかは,共通企画区分で分類する。 ©資材には計量単位を設定する。枚,FIA,個.,ミリリットルなどがある。 (3)資材をベンダーから購入する荷姿を購入荷姿と呼ぶ。主に容量が59リットル 程度の段ボール箱である。 (4)DCから資材を店舗に配送する荷姿を配送荷姿と呼ぶ。配送の最小単位であり, 購入荷族の段ボール箱を開梱した小箱,袋,ボトルなどである。DCでは,この ー21一 単位で保管するので保管荷次とも呼ぶ。 (5)資材には,MAR ROAMCAIEMAOARZ EO.DCから店舗への配送は, Bciz ta AOAR ORBLE C179. (6)資材を調達するベンダーは,資材ごとに1社に決めている。 3.資源の組合せで定める資源及び在庫 (1)商品とサイズの組合せで,資材ごとの使用量をレシピとして登録している。 使用量は調理時のロスを考慮している。 (2)DCごとに資材の在庫をもつ。 4.商品企画のやり方 (1)商品企画の対象は期間限定商品と新商品である。期間限定商品と新商品で商 品企画のやり方は同じである。 (2)期間限定商品のレシピ及び販売期間はB社の本部が定める。 (3)本部は,新商品の評価期間後に定番商品にするかが廃番にするかを決める。新 商品を定番商品にする場合,新たに定番商品として登録する。 5.DCからベンダーへの発注のやり方 定量発注と計画発注がある。どちらも1日に高々1回行う。 (1)定量発注のやり方 ①共通資材を対象として,定量発注を実施している。 ②B社が採用している定量発注は,DCごと資材ごとに発注ロットサイズ,発 注リードタイムを調達条件として取り決めておき,DCの実在庫数が,DCごと 資材ごとに設定した基準在庫数を下回ったときに,発注ロットサイズ分の発 注を日次で行う方式である。発注ロットサイズは購入荷変の入数の整数倍に FS.調達条件は必要に応じてベンダーと協議する。 ③定量発注では,確かに在庫を確認して発注したものか否かを表す在庫確認 サイン及び発注年月日を記録する。 (2)計画発注のやり方 ①企画資材を対象として,計画発注を実施している。 ②計画発注では,全販売期間にわたって週次の調達量をあらかじめ発注する。 発注年月日,発注数及び希望納期年月日を記録する。 ー22一 6.DCでの在庫保管のやり方 (1)倉庫内の資材の保管は,固定ロケーション方式を採用している。 ①倉庫の区画に対して一つ又は複数の資材を割り当てるが,一つの資材は一 つの区画だけに収めている。DCごと資材ごとに保管区画を決めている。 ②資材はーつ又は複数の棚に割り当てるが,一つの棚には一つの資材だけを 割り当てる。 (2)同じ資材は,先に入庫したものから先に出庫する先入先出を行う。 ①資材に割り当てた棚には,次に入庫する棚を示す後続棚番号をもたせ,同 じ資材に割り当てた棚の中で後続棚番号が一巡するように設定する。棚には, 同じことが目視で判別できるように,MBS,後続棚番号,割り当てている 資材コードと資材名を記載したプレートを掲示する。 ②最後に入庫した棚番号を最終入庫棚番号として記録する。最後に出庫した 棚番号を最終出庫棚番号として記録する。最終入庫棚番号と最終出庫棚番号 は,DCの資材在庫にもつ。これによって,次の入庫又は出庫をどの棚番号か ら行えばよいかを知ることができる。 7.入荷及び入庫のやり方 (1)入荷では,ベンダーの納品を受けて資材ごとに現物を確認し,入荷年月日, 検品サイン,どの発注に基づく入荷かの対応を記録する。 ①定量発注による入荷では,入荷時分を記録する。 ②計画発注による入荷はベンダーの都合で分納され得る。入荷数を記録する。 (2)入荷した段ボール箱を開梱して保管荷変の現品を入庫する。入庫は入荷の単 位に行い,入庫時分を記録する。 (3)保管荷姿の現品には,資材の情報を記したバーコードラベルを貼付する。 8.DCでの出庫のやり方 (1)DCでは毎営業日の8一11時に出庫を行う。出庫は摘取方式で行う。RAN とは,店舗ごとの出庫要求に従って倉庫を回って資材を出庫し,店舗ごとに用 意したかご台車に積むやり方である。 (2)出庫に先立って出庫要求をまとめる。出庫要求では,共通資材の補充要求, 企画資材の計画要求,店舗の追加要求の3種類の資材要求を作り,資材要求か ら店舗ごと資材ごとに対象の配送年月日の出庫要求を導く。3種類の資材要求 ー23一 は要求区分で分類する。 (3)共通資材の補充要求は,各店舗の販売実績から求めることのできる共通資材 ごとの使用量を必要量として,配送の1営業日前に次の手順で求めたものであ る。共通資材の補充要求は,算出時分をもつ。 OQ店舗の営業終了時に,各店舗から当日の販売実績として,販売年月日,店 舗コード,商品コード,販売サイズ,販売数を連携してもらう。 ②連携された販売実績とレシピを基に,全ての資材の使用量を求める。 ③②の結果のうち共通資材だけを対象に,店舗ごと資材ごとに集計して共通 資材の使用量を求め,配送荷姿の入数で除して四捨五入することで配送荷次 での必要数とし,資材要求数を導く。 (4)企画資材の計画要求は,販売期間及び各店舗の販売実績を勘案して求めた営 業日ごと企画資材ごとの必要量をDCが事前に登録したものである。登録年月日 を記録する。 (5)店舗の追加要求は,店舗責任者が事前に登録してある共通資材の補充要求と 企画資材の計画要求を前提に判断し,全ての資材について追加で必要な資材を 要求する。登録年月日時分を記録する。 (6)出庫は,導いた出庫要求に基づいて行う。店舗ごとに出庫すべき資材を全て 出庫し終わったら出庫完了時分を記録し,内訳の出庫実績数を記録する。 9.DCでの出荷のやり方 (1)店舗への出荷を毎営業日に1回,13時から実施する。 (2)出荷では,配送車が出発するごとに配送年月日,出荷時分を記録する。 (3)出荷の店舗ごとの内訳では対象店舗を記録する。 (4)出荷の店舗ごと資材ごとの内訳として出荷店舗資材明細を作り,どの出庫の 内訳を対応させたかと出荷実績数を記録する。 19.店舗への納入のやり方 (1)ルートの納入順に店舗へ納入を行う。納入は,かご台車のまま納品書を添え て店舗に引き渡し,店舗が確認することで完了する。 (2)納入は,出荷店舗明細と対応付け,納入時分と店舗の確認サインを記録する。 (3)店舗からは,前回の納入で用いたかご台車を回収する。かご台車の回収は特 に記録しない。 ー24一 [再構築における店舗への出庫及び出荷のやり方の変更〕 1.変更の背景 B社は,創業以来DCでの出庫は摘取方式で行ってきたが,DC当たりの店舗数が 増えてきたので,作業効率を上げるために種まき方式に変更することにした。 2.変更する出庫のやり方 (1)種まき方式とは,資材ごとに全ての店舗分をまとめて一度に出庫し,出庫し た資材を各店舗向けのかご台車に種まきをするように仕分けるやり方である。 (2)共通資材の補充要求の求め方,企画資材の計画要求の登録の仕方,店舗の追 加要求の仕方の3種類の資材要求数の導き方は変えず,資材要求からDCごと資 材ごとに対象配送年月日の出庫要求を導くように変更する。 (3)出庫要求とは別に,出荷の段取りとして資材要求から店舗ごと資材ごとに対 象配送年月日の出荷予定明細を導き,出荷予定数をもつ。 (4)出庫は区画ごとに実施し,出庫明細で区画内の資材を出庫要求に基づいて出 BIS.出庫では配送年月日と出庫完了時分を記録し,出庫明細で出庫要求と の対応と出庫実績数を記録する。 3.出庫のやり方の変更に伴う出荷のやり方の変更 (1)出荷の店舗ごと資材ごとの内訳で,どの出荷予定明細に基づいたか,どの出 庫明細と対応付けたかを記録する。 (2)出荷店舗資材明細に出荷実績数を記録する。 〔概念データモデルと関係スキーマの設計〕 1.概念データモデル及び関係スキーマの設計方針 (1)関係スキーマは第3正規形にし,多対多のリレーションシップは用いない。 (2)リレーションシップが1対1 OWA,意味的に後からインスタンスが発生す る側に外部キー属性を配置する。 (3)概念データモデルでは,リレーションシップについて,対応関係にゼロを含 むか否かを表す“〇"又は“@”は記述しない。 (4)実体の部分集合が認識できる場合,その部分集合の関係に固有の属性がある ときは部分集合をサブタイプとして切り出す。 (5)サブタイプが存在する場合,他のエンティティタイプとのリレーションシッ as Bi a プは,スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する。 (6)概念データモデル及び関係スキーマは,マスター及び在庫領域とトランザ クション領域を分けて作成し,マスターとトランザクションの間のリレーショ ンシップは記述しない。 (7)関係スキーマでは,可読性を重視するので自然キー(ナチュラルキー)だけ を用い,代理キー(サロゲートキー)は用いない。 (8)自然キーを参照する外部キーには冗長な属性が必要になる場合がある。この BS,属性名の前後を“[”と“]”で挟んで明示する。結合して求まる冗長な 属性を明示する例を図1に示す。また,スーパータイプからサブタイプに継承 した冗長な属性を明示する例を図2に示す。 概念データモデルの例関係スキーマの例 作業種類作業種類(作業コード,作業種類名) 部門(部門コード,部門名) 従業遇|[部内会議]oe(部門コード,会議番号,SMS,開催日時) HRA(従業員番号,氏名,部門コード) 作業実績(HERBS,作業年月日,作業開始時刻,作業コード, 作業実績[部門コード],会議番号,作業時間) 注記関係"作業実績"における属性"部門コード"”は,関係“部内会議"を参照するために関係"従業員" と結合して求めた属性である。 図1結合して求まる冗長な属性を明示する例 概念データモデルの例関係スキーマの例 部門予算|sg(部門コード,年度,予算額.…) 顧客(顧客コード,顧客名、…) |A一般受注(受注番号,顧客コード,…) 受注(受注番号,受注区分,受注年度,受注額,…) 社内受注(受注番号,部門コード,[受注年度],…) 注記関係"社内受注”における属性"受注年度"は,関係“部門予算"を参照するために関係“BE”OR 性"受注年度"を継承した属性である。 図2継承して冗長な属性を明示する例 2.設計した概念データモデル及び関係スキーマ (1)[現状の業務分析の結果〕を基に設計した現状のマスター及び在庫領域の概 念データモデルを図3に,現状のトランザクション領域の概念データモデルを 図4に,現状のマスター及び在庫領域の関係スキーマを図5に,現状のトラン ザクション領域の関係スキーマを図6に示す。 (2)[〔再構築における店舗への出庫及び出荷のやり方の変更]を基に,トランザ クション領域の概念データモデルと関係スキーマの一部を変更した。図4に対 して変更を検討する範囲を示した概念データモデルを図7に,変更した概念デ ータモデルを図8に,変更した関係スキーマを図9に示す。 Aハ name Tr 期間限定 商品 |資材在庫|[ieee新商品 DC共通資材2 図3現状のマスター及び在庫領域の概念データモデル(未完成) 資材要求||出大要求||出庫明細||[SEEM ハハ EE A " 使用量所加入荷 要:=5 M4現状のトランザクション領域の概念データモデル(未完成) DC(DCコード,DC名) 地区(地区コード,地区名, 郵便番号(郵便番号) ルート(|ゥ) 店舗(店舗コード,店舗名) 区画(|ォ]) 棚([ヵ|]) ベンダー(ベンダーコード,ベンダー名) 資材(資材コード,資材名,調達先ベンダーコード,食材杉包材区分,RERRBRD,HEC, 計量単位購入荷姿入数,REAR 共通資材(資材コード,3か月平均単価) 企画資材(資材コード,企画期間単価) 共通資材調達条件(資材コード, 商品(商品コード,商品種類区分,商品名,サイズ数,商品販売区分) 定番商品(商品コード,前年日販数) 期間限定商品(商品コード,販売開始年月日,販売終了年月日 新商品(商品コード,販売開始年月日,定番化判断結果) レシピ(資材コード,) DC資材在庫(DCコード,資材コード,) 図5現状のマスター及び在庫領域の関係スキーマ(未完成) 販売実績(販売年月日,店舗コード,商品コード,販売サイズ,販売数) 商品資材使用量(販売年月日,店舗コード,商品コード,販売サイズ,資材コード,資材使用量) 資材要求(|コ|,資材要求数 共通資材補充要求(|コ|,算出時分) 企画資材計画要求(|a),登録年月日) 店舗追加要求(|コ|,登録年月日時分) 出庫要求(|サ|,出庫要求数) 出庫(|シ|,出庫完了時分) 出庫明細(|ス|,出庫実績数) 出荷(|セ|,出荷時分) 出荷店舗明細(|ソ]) 出荷店舗資材明細(|タ|,出荷実績数) 納入(|チ|,納入時分,店舗確認サイン) 発注(|ツ|,共通企画区分) 定量発注(|ツ|,在庫確認サイン) 計画発注(|ツ|,発注数希望納期年朋日) 入荷(DCコード,入荷年月日,資材コード,|テ|,共通企画区分,検品サイン) 定量発注入荷(0Cコード,入荷年月日,資材コード,|ト|,入荷時分) 計画発注入荷(DCコード,入荷年月日,資材コード,,入荷数 入庫([ナ|,入庫時分) 6現状のトランザクション領域の関係スキーマ(未完成) (RRSRHT 26H —ot |[ |1 !Ease]| [: ! Aヘニーニーーーニーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 時a as 使用量店舗追加Asi 要求ーーーー =>計画発注 図7変更を検討する範囲を示した概念データモデル(図4の再掲,未完成) 出荷店舗 明細 出荷店舗 図8変更した概念データモデル(未完成) 資材要求(|ニニ|,資材要求数) 出荷((EL).出荷時分) waren(7)) 出荷店舗資材明細(|ヌ|,出荷実績数) 注記Mateo 2).には,tnenmeol_t_],と同じ宇句が 入る。 図9変更した関係スキーマ(未完成) 解答に当たっては,巻頭の表記ルールに従うこと。また,エンティティタイプ名, 関係名,属性名は,本文中の字句を用いて適切な名称とすること。関係スキーマに 入れる属性名を答える場合,主キーを表す下線,外部キーを表す破線の下線につい ても答えるとと。