Tech Racho エンジニアの「?」を「!」に。
  • IT Tips

DB勉強会レポート_2019年02月22日(金)実施分

こんにちは。

今回で午後Ⅱの問1は最後になります。
記事の分量で言えば3本、勉強会回数で言えば4週に渡りじっくりと取り組んできました。
その分、内容の濃い解説記事になると思いますので、問題集の解説で腑に落ちない場合は是非ともご覧下さい。

解説範囲

平成30年度 春期 データベーススペシャリスト試験 午後Ⅱ 問1 設問3

(2)

バッチ処理の性能について, ①, ②に答えよ。


ここでは表9の空欄が解答の対象となっています。
p.18の「2. サービスの評価 (1) 性能」の②を読むと、解答の根拠となる情報の在処が記述されています。

[業務の概要]及び表2を基に, (中略) バッチ処理の処理行数を表9にまとめた上で, 対策を検討することにした。


また、バッチPGMの詳細を把握するために、上記に加え、p.11の「表3 主な処理のCRUD」と「表4 バッチPGMの処理内容」を参照する必要があります。

表9中のj ~ nに入れる適切な数値を答えよ。


p.10の「表2 主なテーブルの見積行数・データ所要量」に目を転じて下さい。
解答の対象となる空欄は行数を入れますので、参照すべきは「テーブル名」と「見積行数」の列になります。

次に、表4を見て下さい。
表中のキーワードを抜粋すると、以下のようになります。

* すでに空所補充済みの「会計データ」は省略します。

処理名 対象処理年月 対象行
経費伝票作成 当月 旅費申請に対応する"旅費申請明細"テーブルの行
交通費申請に対応する"交通費申請明細"テーブルの行
"一般経費申請"テーブルの行
経費分析表作成 当月の12か月前から当月まで 経費伝票に対応する"経費予算"テーブルの行

まずはjから計算していきましょう。
対象行は、処理年月が「当月」に一致する行ですが、表2の情報はどのくらいの期間の見積行数なのでしょうか?

p.8「(1) 現行システムの概要」の③をご覧下さい。

経費予算, 申請に関する情報, 及び申請から派生する伝票などの情報は, 経費予算の年月又は申請の処理年月が60か月前から現在までのデータが全て保存されている。

以上より、表2は60か月分の見積行数だと分かります。
当月分は1か月なので、見積行数を60で除算すれば良いわけです。

対象行に注意して下さい。
"旅費申請明細"テーブルと交通費申請明細"テーブルは、それぞれ「旅費申請」と「交通費申請」に対応する行が対象です。
つまり、「旅費申請」と「交通費申請」を表探索して処理年月が当月の行を抽出します。
そして、それぞれ申請番号が一致する"旅費申請明細"テーブルと"交通費申請明細"テーブルの行、また"一般経費申請"テーブルの行をバッチPGM中に読み込む、という流れです。

すなわち、当月分の見積もり行数で「旅費申請 + 旅費申請明細 + 交通費申請 + 交通費申請明細 + 一般経費申請」を計算すれば良いわけです。
実際の見積行数に置き換えると、「(150,000 + 1,500,000 + 180,000 + 3,600,000 + 1,500,000) ÷ 60」となります。

よって、jには115,500行が入ります。


次にkです。
求める「サーバー間通信対象見積行数」について、p.18「2. サービスの評価 (1) ②」の最後の項目の説明を確認しておきましょう。

サーバー間通信対象見積行数は, 処理ごとに, 行の参照, 追加のためにDBサーバとAPサーバ間で転送される行数とする。

表3の経費伝票作成の行を確認すると、以下の情報を読み取れます。

テーブル名 CRUD
旅費申請
旅費申請明細
R
交通費申請
交通費申請明細
R
一般経費申請 R
経費伝票 C

経費伝票作成のサーバー間通信は以下のようなイメージになります。

「サーバー間通信対象見積行数」は、このRとCの行数の合計で求めることが出来ます。
参照・追加の対象となるのはいずれも"旅費申請明細"テーブルと"交通費申請明細"テーブル及び"一般経費申請"テーブルの行ですので、「(1,500,000 + 3,600,000 + 1,500,000) × 2」で求めることが出来ます。

よって、kには220,000が入ります。

j115,500行を2倍した方がいらっしゃるかも知れませんが、旅費申請と交通費申請のテーブルが探索されるのはあくまでそれぞれ申請番号が一致する明細テーブルの当月の行を抽出する時です。
サーバ間の通信はあくまで結果行数の110,000行のみが対象となります。


次にlです。
対象処理年月は「当月の12か月前から当月まで」ですが、数え方によって12か月もしくは13か月と揺れが生じますもで、この問は除算する数によって2通りの解答があります。

表2は60か月分の見積行数ですので、12か月分の場合の行数は「60 ÷ 12 = 5」、つまり見積行数を5で除算すると求めることが出来ます。
もしくは、13か月分の場合の行数は「60 ÷ 13 = 4.615384615384615」、つまり見積行数を4.615384615384615で除算すると求めることが出来ます。
あとは、jと同じ発想です。

よって、lには以下の2通りの解答が入ります。

  • 「(12,000 + 6,600,000) ÷ 5」で計算した場合: 1,322,400
  • 「(12,000 + 6,600,000) ÷ 4.615384615384615」で計算した場合: 1,432,600

次にmです。
結果行数は、p.11の表4を見ると以下の通り求めることが分かります。

"経費予算"テーブルの行ごとに, 対応する"経費伝票"テーブルの金額を, GROUP BY句を用いて事業部, 科目, 年月ごとに集計して実績金額を求め, 予算金額との対比表をファイルに出力する。

集計は以下のようなイメージです。

事業部 科目 年月
事業部01 科目01 201801
事業部01 科目01 201802






事業部01 科目20 201801
事業部01 科目20 201802






事業部10 科目01 201801
事業部10 科目02 201802






事業部10 科目20 201812
事業部10 科目20 201901

このように、年月が一巡すると次の科目が、年月と科目が一巡すると次の事業部が、というようにGROUP BY句で集計されます。
p.6の「(1) 組織」を見ると、事業部数は「10」、「(2) 科目」を見ると科目数は「20」だと分かります。

"経費予算"テーブルの行ごとに, 対応する"経費伝票"テーブルの金額を, GROUP BY句を用いて事業部, 科目, 年月ごとに集計して実績金額を求め, 予算金額との対比表をファイルに出力する。

以上の要件より、探索行数を「事業部数 × 科目数 × 年月数」で除算すると結果行数を求めることが出来ます。
実際の数字に置き換えると、「1,322,400 ÷ (10 × 20 × 12)」となります。
もしくは、「1,432,600 ÷ (10 × 20 × 12)」となります。

よって、mには2,400行、もしくは2,600行が入ります。


最後にnです。
表3を見ると、経費分析表作成の「経費伝票」はRで参照のみを行います。
サーバ間通信の図で考えると、R分の行数のみを通信対象としていることになります。

よって、nにも結果行数と同数の2,400行、もしくは2,600行が入ります。

表9中の処理について, サーバ間通信対象行数の削減対策による効果が最も大きい処理を一つ挙げ, その対策内容を具体的に40字以内で述べよ。


設問3 (2) ①で得た解答を基に表9を完成させると、以下の通りになります。

処理名 探索対象行数 結果行数 サーバ間通信対象行数
経費伝票作成 115,500 110,000 220,000
会計データ作成 110,000 110,000 110,000
経費分析表作成 1,432,600 or 1,322,400 2,600 or 2,400 2,600 or 2,400

サーバ間通信対象行数が一番多い処理は「経費伝票作成」であると分かります。

このバッチPGMは、クラウドサービスではDBサーバ、APサーバのどちらで実行されるでしょうか?
pp.18 - 19「1. サービスの選定」の(4)を見ると、以下の説明があります。

(4) DBサーバ上でバッチPGMを実行することができないので, バッチPGMはAPサーバ上で実行する。


バッチPGMの「参照」「追加」をするAPサーバで、それらをされるのがDBサーバです。
そのため、サーバ間通信対象行数は、「参照」「追加」が増えれば増えるほど比例して増加します。
では、どうすればサーバ間通信対象行数を減らせるか。
それは、「参照」「追加」をDBサーバ自身が行えば良いのです。

DBサーバ上でバッチPGMを実行することが出来ませんので、バッチPGMと同等の機能を別の方法で実装する必要があります。
勘の良い方はもうお分かりだと思います。
ストアドプロシージャをDB上に作成すれば良いのです。

ただし、処理はDBサーバ側で行われますが、呼び出しはAPサーバ側で行う必要があります。

よって、解答は以下の通りです。

  • 処理名: 経費伝票作成
  • 対策内容: バッチPGMと同じ処理を行うストアドプロシージャを作成し, APから呼び出す

(3)

クラウドサービスの利用料金を低減できるジョブスケジュールの設定内容を, 具体的に30字以内で述べよ。


p.16の「1. サービス概要・利用料金」の(3)を見ると、DBの専用サーバは「データベース利用時間 × 基本サービス利用料金」で料金が決定します。
このうち、基本サービス利用料金はすでに決定しているので、コスト削減のために対策出来るのはデータベース利用時間となります。

p.18の「(3) コスト」を見ると、以下の記事があります。

ジョブスケジュールを適切に設定することによって, クラウドサービスの利用料金を大幅に低減できることが分かった。


つまり、データベース利用時間を必要最低限に抑えれば良いわけです。
そのためには、「必要最低限の時間に起動し、必要最低限の時間に停止する」ようにジョブスケジュールを設定する必要があります。

それでは、その「必要最低限の時間」とはいつでしょうか?
p.8「(1) 現行システムの概要」の④をご覧下さい。

④ 旅費交通費精算機能の運用時間帯は, 平日の8時 ~ 23時であり(以下省略


この「平日の8時 ~ 23時」が必要最低限の時間です。

よって、解答は「データベースを平日の8時に起動し, 23時に停止する。」となります。
このように、設問に「具体的に」とあるので、「いつ」「何を」するかを数字を示して解答する必要があります。

今回の設問の解答

  • 設問3
    • (2)
        • j. 115,500
        • k. 220,000
        • l. 1,432,600 (1,322,400も可)
        • m. 2,600 (2,400も可)
        • n. 2,600 (2,400も可)
        • 処理名: 経費伝票作成
        • 対策内容: バッチPGMと同じ処理を行うストアドプロシージャを作成し, APから呼び出す
    • (3) データベースを平日の8時に起動し, 23時に停止する。

参考ページ

次回解説予定範囲

平成30年度 春期 データベーススペシャリスト試験 午後Ⅱ 問2

関連記事

DB勉強会レポート_2019年01月08日(火)実施分

DB勉強会レポート_2019年01月15日(火)実施分【前編】

DB勉強会レポート_2019年01月15日(火)実施分【後編】

DB勉強会レポート_2019年01月22日(火)実施分

DB勉強会レポート_2019年01月29日(火) & 02月05日(火)実施分

DB勉強会レポート_2019年02月13日(水)実施分

DB勉強会レポート_2019年02月22日(金)実施分


CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。