- 問1
- 問2
公式サイトの問題冊子はこちら。
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000fzx1-att/2017h29h_db_pm2_qs.pdf
問1-設問1-(1)
①
配置方法④とした場合、会員テーブルに双方向の同期が必要となるのは、業務上どのような場合か。具体的に30字以内で述べよ
| 属性名 | 店舗販売 | OL販売 |
|---|---|---|
| 氏名 | ◯ | ◯ |
| 住所 | ◯ | ◯ |
| 電話番号 | ◯ | ◯ |
| 使用可能ポイント | ◯ | ◯ |
| 本年ポイント | ◯ | ◯ |
| 前年ポイント | ◯ | ◯ |
| 前々年ポイント | ◯ | ◯ |
| 性別 | ◯ | |
| 生年月日 | ◯ | |
| メールアドレス | ◯ |
- 「会員から申請があれば、ポイント統合を行う。統合後は、OL販売の会員番号を正規の会員番号とし、ポイントを集約する。」
- 統合しない会員も混在することになるので現行の店舗販売とOL販売は残す必要がある
- 「ポイントは、取得した翌日以降の購入時の支払に使用できる。使用したポイントは、即座に使用可能ポイントから差し引かれる」
- 統合後の使用可能ポイントは店舗販売、OL販売の合算値なので、購入時の支払いのため一方の会員テーブルから差し引かれた使用可能ポイントは他方にも反映する必要がある
ポイント統合後の支払いの際に使用可能ポイントを利用する場合
②
②配置方法④とした場合、OL販売システムの現行DBへの同期が失敗した場合に更新がロールバックされる店舗販売システムの処理がある。該当する処理名を表2の中から全て答えよ
- 「会員」列を更新する処理は表2より
- 会員登録
- POS入力
- ポイント反映
問1-設問1-(2)
表5中のa～eに入れる適切な配置方法を答えよ
(i) 店舗販売業務とOL販売業務に共通する情報を保有していて、双方で情報の参照、追加、更新が発生するテーブルには、情報共有対象欄に◯を記入する」
- 「全エリアの倉庫からの配送を可能にして、店舗販売業務の取扱商品の多くをOL販売で取り扱えるようにする」
- 倉庫在庫を共通にする必要があり、双方で使用するテーブルなので情報共有対象に◯
(ii) 情報共有対象でないテーブルのうち、情報共有対象のテーブルから参照されるテーブルには、参照先欄に◯を記入する
- 図1と図3より、店舗販売の小分類は、情報共有対象テーブルから参照されるので、参照先に◯
- 図2と図3より、OL販売の商品分類は、情報共有対象テーブルの商品から参照されるので、参照先に◯
(iii) (i)又は(ii)に該当するテーブルについて、現行システムの処理で追加・更新されるものは現行APを、販売統括部によって追加・更新されるものは連携APを追加・更新の起点欄に記入する。
- 図3のテーブル以外は全て現行AP
(iv) 追加・更新の起点が現行APであるテーブルについて、現行DB及び連携DBの両方にテーブルを配置した場合に、現行DBの一方での追加・更新を、他方にも同期させる必要があれば双方向の同期欄に◯を記入する
- 双方の倉庫在庫の追加更新を同期する必要があるので双方向の同期に◯
(v) (i),(ii)のいずれにも該当しなければ配置方法①とし、該当する場合は、次のように配置方法を決める
- (iii)において、追加・更新の起点が連携APの場合は、配置方法②
- (iv)において、双方向の同期が必要でない場合は、配置方法③
- 小分類、商品分類は片方にしかないテーブルなので同期不要
- (iv)において、双方向の同期が必要な場合は、配置方法④とする。ただし、テーブルの主キーの値が等しい行に対する更新が同時に発生する可能性がある場合には、配置方法⑤
- 現行の店舗販売、OL販売共に同じ商品への更新が同時に発生する場合が考えられるので、倉庫在庫は⑤
| テーブル名 | 情報共有対象 | 参照先 | 追加・更新の起点 | 双方向の同期 | 配置方法 |
|---|---|---|---|---|---|
| 大分類・中分類・小分類 | ◯ | 現行AP | ③ | ||
| 商品分類 | ◯ | 現行AP | ③ | ||
| 店舗在庫 | ① | ||||
| 倉庫在庫 | ◯ | 現行AP | ◯ | ⑤ | |
| 出荷指示・出荷指示明細 | ① |
a: 配置方法③
b: 配置方法③
c: 配置方法①
d: 配置方法⑤
e: 配置方法①
問1-設問2-(1)
図3中のfに追加する列名と列値の内容を表7にまとめた。記入済みの例に倣って空欄を埋め、表を完成させよ
- 「統合後は、OL販売の会員番号を正規の会員番号とし、ポイントを集約する」ので、集約先の会員番号が必要
- 「複数のポイントカードのうち、1枚だけを存続させ、その他は廃止する」ので、廃止したかどうかの記録が必要
- 「ポイント統合の対象となったポイントカードの統合申請日、統合対象ポイント(統合時点の使用可能ポイント)を記録し、照会画面から確認できるようにする」
| 列名 | 列値の内容 |
|---|---|
| 統合区分 | ポイント統合の有無を表す値 |
| 集約先会員番号 | 統合後のポイント集約先の会員番号 |
| 廃止区分 | ポイントカード廃止の有無を表す値 |
| 統合申請日 | ポイントカードの統合申請日 |
| 統合対象ポイント | 統合時点の使用可能ポイント |
会員テーブルの統合で追加した列間の検査制約を一つ挙げ、その内容を次の例に倣って40字以内で述べよ
| 属性名 | 店舗販売 | OL販売 |
|---|---|---|
| 氏名 | ◯ | ◯ |
| 住所 | ◯ | ◯ |
| 電話番号 | ◯ | ◯ |
| 性別 | × | ◯ |
| 生年月日 | × | ◯ |
| メールアドレス | × | ◯ |
| 使用可能ポイント | ◯ | ◯ |
| 本年ポイント | ◯ | ◯ |
| 前年ポイント | ◯ | ◯ |
| 前々年ポイント | ◯ | ◯ |
| 店舗コード | 外部キー | × |
| 店舗会員番号 | 外部キー | × |
| 会員区分 | 店舗販売 | OL販売 |
- 店舗販売の場合、店舗コードと店舗会員番号が、現行店舗販売への外部キーになる
会員区分が店舗販売の場合、店舗コードと店舗会員番号はNULLでない
問1-設問2-(2)
会員V1ビュー、会員V2ビューの具体的なアクセス権限付与先を答えよ
- 「会員番号、氏名、ポイントは、全従業員に全会員の情報参照を許す」
- 会員V1が該当する
- 「それ以外の情報の参照は、必要とする特定の役職及び特定の担当職務の従業員に限定する」
- 「機密情報へのアクセス制御には、認可役職ロール、認可担当職務ロールを用いる」
- 会員V2が該当する
会員V1: 全従業員
会員V2: 認可役職ロール、認可担当職務ロール
図5中のg～jに入れる適切な字句を答えよ
- 「図5のSQL文で作成したビューでは、従業員が所属する店舗の会員情報だけにアクセスを限定する」ので、従業員の店舗コードと会員の店舗コードが同一のものを抽出する
- 「ポイント統合後の店舗会員については、統合先のOL会員番号も参照可能とする」ので、集約先会員番号と同一の会員番号の会員も抽出する
- 「DB接続に用いられたユーザIDはCURRENT_USERで参照されるものとする」
SELECT A.* FROM 会員 A INNER JOIN 従業員 B ON A.店舗コード=B.店舗コード AND B.従業員ID=CURRENT_USER
UNION
SELECT A.* FROM 会員 A INNER JOIN 会員 B ON A.会員番号=B.集約先会員番号
INNER JOIN 従業員 C ON B.店舗コード=C.店舗コード AND C.従業員ID=CURRENT_USER
g: 従業員
h: A.店舗コード=B.店舗コード AND B.従業員ID=CURRENT_USER
i: A.会員番号=B.集約先会員番号
j: B.店舗コード=C.店舗コード AND C.従業員ID=CURRENT_USER
問1-設問2-(3)
各業務の日締処理で行う操作を具体的に60字以内で述べよ
- 「店舗販売業務、OL販売業務では、それぞれ、その日のうちに日締めを行っているが、日締め時刻は日によって異なり、順序も決まっていない。」
- 日締は、店舗販売業務→OL販売業務の場合と、OL販売業務→店舗販売業務の場合がある。
- 「バッチ処理中の元データ更新を避けるため、両業務とも日締めが完了したときに、該当テーブルのレプリケーションを自動的に無効化する」
- 図6のとおり両業務のフラグをまとめて1レコードとしている
- 先に行う日締めではフラグを完了にした状態で行追加が必要
- 後になった業務の日締めは行更新
先に日締めする契機では、一方の業務の日締フラグを完了にした行を追加し、他方の業務を日締めする契機では、行更新を行う
トリガの定義内容について、①実行の契機となる操作、②実行条件、③実行する処理の内容を答えよ
- 「バッチ処理中の元データ更新を避けるため、両業務とも日締めが完了したときに、該当テーブルのレプリケーションを自動的に無効化する」
- レプリケーションを無効化する契機は日締め処理が完了したとき。つまり、日締管理テーブルを更新し、両フラグが完了になったとき。
①: 日締管理テーブルの更新
②: 店舗日締フラグとOL日締フラグが完了であること
③: レプリケーションを無効化する
問1-設問3-(1)
表1の販売分析処理が可能となるように、図7に追加すべきテーブル名を一つ挙げ、テーブル構造を答えよ
- 「会員の性別、居住地域、年齢層を用いて分析を行う」ために、会員テーブルの性別、住所、生年月日から計算された新たな会員軸テーブルが必要
会員軸(会員軸ID、性別、居住地域、年齢層)
図7中のk～mに入れる列名を、それぞれ一つ又は複数答えよ
- 販売分析に必要なものは販売ファクトに紐付けられている必要があるから会員軸も追加
- 「店舗販売とOL販売をチャネル区分で識別し、チャネル横断的に販売分析処理を行えるようにする」→店舗軸にチャネル区分を追加
- 表1処理例1「OL販売業務で用いている商品分類を第1～3階層の範囲内から選択」→商品軸に分類コードを3階層分追加する。店舗販売の大中小分類コードとは別物
k: 会員軸ID
l: チャネル区分
m: 分類コードL1、分類コードL2、分類コードL3
問1-設問3-(2)
表6中のア～エに入れる適切なテーブル名又は内容を答えよ
- 「指定期間内に、関東地域に居住する30代の女性が購入した、店舗販売の大分類コードがK001の件数を、購入曜日ごと、時間ごとに集計し、商品紹介のタイミングを分析する」
- 「関東地域に居住する30代の女性」は会員軸に対して、居住地域が関東地域かつ、年齢層が30代かつ、性別が女性
- 「店舗販売の大分類コードがK001」は商品軸に対して、大分類コードがK001
ア: 会員軸
イ: 会員軸IDで等結合し、居住地域が関東地域かつ、年齢層が30代かつ、性別が女性である行を選択
ウ: 商品軸
エ: 商品軸IDで等結合し、大分類コードがK001である行を選択
問2-設問1-(1)
図3には欠落しているリレーションシップがある。マスタ・在庫領域のエンティティタイプについて、マスタ・在庫領域内及びマスタ・在庫領域とトランザクション領域間のリレーションシップを補って、図を完成させよ
マスタ・在庫領域内
- 図4より、工場、物流センタ、営業所は拠点のサブタイプ
- 図4より、請求得意先は得意先のサブタイプ
- 図4より、発注得意先は広域得意先のサブタイプ
- 「販売部と営業所を合わせて営業部門と呼び、営業部門コードで識別している」
- 「請求得意先は、請求書を集約する対象の得意先をもつ」
- 「地域得意先に対する営業は、その地域得意先を受け持つ営業所が担当する」ので、営業所と地域得意先は1対多
- 「まとめて発注される各広域得意先は、どの発注得意先から発注されるか決められている」ので、発注得意先と広域得意先は1対多
マスタ・在庫領域とトランザクション領域間
- 図4「月別商品別物流センタ別入庫計画(年月、商品コード、物流センタ拠点コード、計画値、実績値)」とあるので、物流センタと月別商品別物流センタ別入庫計画は1対多
- ②生産「生産では、生産年月日、生産した商品、数量、生産した商品の入庫先物流センタを記録する」
- ③営業所補充「補充要求では、要求年月日、要求元の拠点、要求した商品・数量を記録する」
- 営業所補充の要求元は営業所
- ④地域得意先納入「注文では、注文年月日、納入先の得意先、注文を受けた商品・数量を記録する」
- 地域得意先納入の納入先は地域得意先
- ⑤広域得意先納入「注文の記録は地域得意先と同じ」
- 広域得意先納入の納入先は広域得意先
- ⑤広域得意先納入「納入指示では、地域得意先納入の記録の他に、納入する物流センタを記録する」
問2-設問1-(2)
図4中のa～kに入れる一つ又は複数の属性名を答えよ
a
- 「拠点の種類は拠点種類区分で分類している。拠点は拠点コードで識別し、拠点名を保持している」
a: 拠点種類区分、拠点名
b
- 「営業所は、物流センタの配下に、76拠点ある」
- 図3から物流センタと営業所は1対多
- 「販売部と営業所を合わせて営業部門と呼び、営業部門コードで識別している」
b: 物流センタ拠点コード(FK)、営業部門コード(FK)
c
- 「営業部門が、販売部と営業所のどちらに該当するかは、営業部門区分で分類している」
c: 営業部門区分
d
- 「得意先が請求得意先に該当するか否かは、請求得意先フラグで識別する」
- 「得意先には、地域得意先と広域得意先があり、得意先区分で分類している」
- 「請求得意先は、請求書を集約する対象の得意先をもつ」
- 請求得意先と得意先は1対多
d: 請求得意先フラグ、得意先フラグ、請求得意先コード(FK)
e
- 「広域得意先に対する営業は、いずれかの販売部が担当する」
- 「まとめて発注される広域得意先は、どの発注得意先から発注されるか決められている」
- 発注得意先と広域得意先は1対多
e: 販売部営業部門コード(FK)、発注得意先コード(FK)
f
- 「商品ごとに生産する工場を決めており、生産する工場の拠点コード、生産ロットサイズを設定している」
f: 工場拠点コード
g
- 「在庫には、基準在庫数量と補充ロットサイズを設定している」
- 「実在庫数量が基準在庫数量を下回った商品を対象に1日に1回、下位拠点から上位拠点に対して商品の要求を行い、上位拠点から下位拠点に商品が補充される」
- 在庫には実在庫数量も必要
- 「在庫引当ができた要求は、その要求分が出庫されるまで引当済数量に累積する」
g: 基準在庫数量、補充ロットサイズ、実在庫数量、引当済数量
h
- ⑤広域得意先納入「注文の記録は地域得意先と同じ」
- 広域得意先納入の納入先は広域得意先
h: 広域得意先コード(FK)
i
- ⑤広域得意先納入「納入指示では、地域得意先納入の記録の他に、納入する物流センタを記録する」
i: 納入物流センタ拠点コード(FK)
j
- ③営業所補充「補充要求では、要求年月日、要求元の拠点、要求した商品・数量を記録する」
j: 要求元営業所拠点コード(FK)
k
- ②生産「工場は、月別商品別物流センタ別入庫計画の計画値に基づいて、入庫先物流センタを決めて、商品ごとに生産し、配送する」
k: 入庫先物流センタ拠点コード(FK)
問2-設問2-(1)
表1は、太枠で示した部分が未完成である。太枠外の例に倣って表を完成させよ
物流センタ補充要求
- 表1より、物流センタ補充要求は、営業所補充要求と同様に補充要求のサブタイプだと考えられるので、補充要求番号はKF
- 営業所拠点コードの代わりに物流センタ拠点コードがAF
補充要求明細
- 補充要求番号と補充要求明細番号は、補充要求明細の主キー
- ③営業所補充「補充要求では、要求年月日、要求元の拠点、要求した商品・数量を記録する」
- 要求年月日は補充要求の、要求元の拠点は営業所補充要求の属性なので、それ以外の補充生産品商品コード、補充要求数量は補充要求明細の属性になる
- 補充生産品商品コードは外部キー
補充出庫、補充出庫明細
- ①物流センタ補充「工場は、補充要求に対して補充出庫を行う」
- 「補充要求に対して、要求を受けた上位拠点で在庫が不足していた場合、不足した商品を当日の補充対象から外す」ので、補充出庫が複数に分割される場合がある
- 補充要求と補充出庫が1対多なので、補充要求番号を外部キーにもつ
- 計画生産品と同様、補充出庫の主キーは補充番号、属性に補充出庫年月日をもつ
- 補充出庫明細の主キーについても同様に、補充番号と補充明細番号からなる
- ①物流センタ補充「補充出庫では、出庫年月日、実際の出庫数量を記録する」のは補充要求明細ごとなので、補充出庫明細の属性
補充入庫、補充入庫明細
- ①物流センタ補充「商品を入庫した物流センタは、入庫の実績を記録する」
- 補充出庫と補充入庫が1対1なので、主キーは補充番号、属性に補充入庫年月日をもつ
- 補充入庫明細の主キーについても同様に、補充番号と補充明細番号からなる
- ①物流センタ補充「補充入庫では、入庫年月日、実際の入庫数量を記録する」のは補充要求明細ごとなので、補充出庫明細の属性
| 属性 | 物流センタ補充要求 | 補充要求明細 | 補充出庫 | 補充出庫明細 | 補充入庫 | 補充入庫明細 |
|---|---|---|---|---|---|---|
| 補充要求番号 | KF | KF | AF | AF | ||
| 補充要求年月日 | A | |||||
| 営業所拠点コード | ||||||
| 物流センタ拠点コード | ||||||
| 補充要求明細番号 | K | AF | ||||
| 補充要求数量 | A | |||||
| 補充生産品商品コード | AF | |||||
| 補充番号 | K | KF | KF | KF | ||
| 補充出庫年月日 | A | |||||
| 補充明細番号 | K | KF | ||||
| 補充出庫数量 | A | |||||
| 補充入庫年月日 | A | |||||
| 補充入庫数量 | A | |||||
| 生産番号 | ||||||
| 生産要求年月日 | ||||||
| 生産要求時刻 | ||||||
| 生産要求数量 | ||||||
| 生産年月日 | ||||||
| 生産数量 | ||||||
| 生産完了時刻 | ||||||
| 生産入庫年月日 | ||||||
| 生産入庫数量 | ||||||
| 入庫完了時刻 |
問2-設問2-(2)
図5中の欠落しているリレーションシップを補って、図を完成させよ
- 補充出庫明細は、補充出庫を商品ごとに分割しているので、補充出庫と補充出庫明細は1対多
- ①物流センタ補充「工場は、補充要求に対して補充出庫を行う」
- 「補充要求に対して、要求を受けた上位拠点で在庫が不足していた場合、不足した商品を当日の補充対象から外す」ので、補充出庫が複数に分割される場合がある
- 補充要求と補充出庫が1対多
- 「翌日以降に、在庫が補充要求を満たした時点で補充を行う。ただし、同一下位拠点からの、別の補充要求をまとめて補充することはない」
- 補充要求された商品はいずれ全て出庫されるが、他の補充要求と集約されることはない
- 補充要求明細と補充出庫明細は、いずれも商品コードごとに分割されており、かつ、不足による分割の影響を受けないので1対1
- 図2より、補充出庫と補充入庫が対応するが、出庫に対して入庫が分割される記述は無いので、1対1
- 前問の表より、補充出庫明細と補充入庫明細は主キーが同一なので1対1
問2-設問3-(1)
統合前のエンティティタイプの属性が、統合後のどのエンティティタイプの属性が、統合後のどのエンティティタイプの属性に対応するか、対応する全ての欄に◯印を入れ、表を完成させよ
- ①同じ属性で構成される場合、同一のエンティティとする
- ②共通でない属性が一方にだけ存在する場合、存在する方のエンティティタイプを他方のサブタイプとする
- ③共通でない属性が双方に存在する場合、共通部分をスーパータイプとし、共通でない部分をサブタイプとする
- ④概念データモデルを統合することで、統合前のエンティティタイプ名が不適切になるこがあるので、適切なエンティティ名を付与する
計画生産品:補充要求
- (4)計画生産品の生産・物流⑤「在庫補充の方式は、営業所だけに適用する」
- 補充生産品:営業所補充要求と同じ営業所拠点コードをもつので、①により、補充要求に加えてサブタイプの営業所補充要求にも◯
計画生産品:補充要求明細
- ③より、補充生産品との共通部分を統合後の補充要求明細に、共通でない部分を計画生産品補充要求明細に含める
補充生産品:補充要求明細
- ③より、計画生産品との共通部分を統合後の補充要求明細に、共通でない部分を補充生産品補充要求明細に含める
| 属性 | 補充要求 | 補充要求明細 | 補充要求 | 営業所補充要求 | 物流センタ補充要求 | 補充要求明細 |
|---|---|---|---|---|---|---|
| 補充要求 | ◯ | ◯ | ||||
| _営業所補充要求 | ◯ | ◯ | ||||
| _物流センタ補充要求 | ◯ | |||||
| 補充要求明細 | ◯ | ◯ | ||||
| _計画生産品補充要求明細 | ◯ | |||||
| _補充生産品補充要求明細 | ◯ |
問2-設問3-(2)
図8中のア～カに入れる一つ又は複数の属性名を答えよ
ア
- 表1より、生産要求(生産番号、補充生産品商品コード(FK)、生産要求年月日、生産要求時刻、生産要求数量)
ア: 補充生産品商品コード(FK)、生産要求年月日、生産要求時刻、生産要求数量)
イウエ
- 表1より、生産(生産番号、生産年月日、生産完了時刻、生産数量)
- 図4より、計画生産品の生産にも生産年月日、生産数量が含まれているので、これらは共通属性として生産の属性
- 生産完了時刻はサブタイプ補充生産品の属性
- 図4より、商品コード(FK)、物流センタ拠点コード(FK)は計画生産品だけの属性
イ: 生産年月日、生産数量
ウ: 生産完了時刻
エ: 商品コード(FK)、物流センタ拠点コード(FK)
オカ
- 表1より、生産入庫(生産番号、生産入庫年月日、生産入庫数量、入庫完了時刻)
- 図4より、計画生産品の生産にも生産入庫年月日、生産入庫数量が含まれているので、これらは共通属性として生産入庫の属性
- 入庫完了時刻はサブタイプ補充生産品の属性
オ: 生産入庫年月日、生産入庫数量
カ: 入庫完了時刻