【令和元年度秋期】ＩＴサービスマネージャ試験
昨日10月20日（日）にＩＴサービスマネージャ試験を受験しました。
受験は初めて。初めての論文区分試験です。
先ほど、午前Ⅱ試験を自己採点したところ、２１問正解（84点）でした。
次の記事に、私の午後Ⅰの復元解答を掲載しました。iTECとTACの解答速報が出たら、順次自己採点しながらコメントを入れていれていきたいと思います。
【平成31年度春期】データベーススペシャリスト試験 合格発表
４月２１日に受験したデータベーススペシャリスト試験の合格発表がありました。
公式解答による自己採点では、今年も午後Ⅰで不合格（自己採点52点）と思っていましたが、なんともぎりぎりの通過でした。。午後Ⅱも合格点にはとても届いていない（自己採点54点）と思っていましたが、これもまたぎりぎりでした。
午後Ⅰ問２のトリガの問題などについては、全く理解ができていないまま解答していたので、今後も精進が必要です。運用管理がメインの仕事なので、データベースの概念設計や物理設計を行うことはほとんど無い（構成管理データベースのメンテやデプロイ作業はたまにある）のですが、この２年間で多少はデータベースシステムのことについて理解を深めることができたと思います。
秋はＩＴサービスマネージャを受験予定。初めての論文区分への挑戦です。
【平成31年度春期】データベーススペシャリスト試験 公式解答との答え合わせ
公式解答が出ましたので、大雑把に答え合わせと採点してみました。配点はTACの配点を参考にしています。結果、残念ですが午後Ⅰで不合格のようです。。
問１ 自己採点 37／50
設問１
（１） a 正 b 正 c 正 d 正 e 正 f 正 g 正 （2×7＝14／14点）
（２） 11箇所中10箇所 正 （1×10=10点／11点）
設問２ 列単位に見て、6列中5列 正 （2×5=10／12点）
設問３
（１） ① 正 ② 誤 ③ 誤 （3×1=3／9点）
（２） 誤 （4×0=0／4点）
問２ 自己採点 15／50
設問１
（１） ア 誤 イ 誤 ウ 正 エ 誤 オ 誤 カ 誤 （2×1=2／14点）
（２） （a） 誤 ※具体的にBEFOREトリガとAFTERトリガを明記すべきでした
（b） 誤 ※具体的にFOR UPDATE句について言及すべきでした
（5×0=0／10点）
設問２
（１） a 誤 b 誤 c 誤 d 正 （2×1=2／8点）
（２） あ 誤 い 正 う 誤 え 正 （2×2=4／8点）
設問３
（１） 正 （2／2点）
（２） ① 正 ② 誤 （5×1=5／10点）
採点されないでしょうが、一応午後Ⅱも答え合わせと自己採点（TAC配点を参考）。
仮に午後Ⅰが通過していたとしても、午後Ⅱで不合格でした。。
問２ 自己採点 54／100
設問１
（１） 13箇所中6箇所 正 （2×6=12／26点）
（２） 6箇所中5箇所 正 （2×5=10／12点）
（３）a 正 b 正 c 正 d 正 e 正 f 誤 g 正 h 誤 i 誤 j 誤 k 正 （3×7=21／33点）
設問２
（１）① 誤 ② 正 ③ 誤 （4×1=4／12点）
（２） 4箇所中2箇所 正 （2×2=4／8点）
（３）l 正 m 誤 n 誤 （3×1=3／9点）
【平成31年度春期】データベーススペシャリスト試験 午後Ⅱ問２（設問１）
設問１
（１）太線が解答したもの
（２）太線が解答したもの
（３）※属性は主キー（実線）を（PK）、外部キー（破線）を（FK）で記しています。
a 要求先焼成部門コード(FK)
b 調達内製区分、貯蔵区分フラグ
c 代替外注成型材料品目コード(FK)
d 内製成型材料品目コード(FK)
e 生地材料品目コード(PK)、原材料品目コード(PK)、使用量
f 内製成型材料品目コード(PK)、原材料品目コード(FK)、生地材料品目コード(FK)、原材料使用量、生地材料使用量
g 供給番号(PK)、供給明細番号(PK)、焼成実績製造番号(PK)、引当数
h 成型材料製造依頼番号(FK)
i 生地材料補充要求番号(PK)、要求先Mix部門コード(FK)
j 調達品目補充要求番号(PK)、食材業者コード(FK)
k 調達品目補充要求番号(FK)
【平成31年度春期】データベーススペシャリスト試験 午後Ⅰ問２
自己採点結果 iTEC 15/50 TAC 20/50
設問１
（１） ア 在庫 イ 更新 ウ 部品番号 エ 出庫要求明細 オ 出庫要求番号
カ 部品番号
【コメント】
トリガーの基本動作を問う問題でしたが、私はこのトリガーの動作を全く理解していないまま解答していました。
BEFOREトリガ：在庫引当処理を行うにあたって、トリガーとなるのは「出庫要求」が行われたとき、つまり「出庫要求」テーブル及び「出庫要求明細」テーブルに行が追加されたときに発動する。そのときに挿入された"部品番号"の値をキーにして「在庫」テーブルから「実在庫数量」と「引当済数量」を参照し、出庫要求数量と比較して引当可能か否かを判定する。「部品番号」をキーにするから、アは「出庫要求明細」、イは「挿入」、エは「在庫」
AFTERトリガ：（引当可能な場合）「在庫」テーブルの「引当済数量」を更新する。よって、オは「実在庫数量」、カは「引当済数量」
（２）
(a) 先行する出庫要求が在庫テーブルのある部品番号の行を参照し、引当処理による更新が完了する前に、後続の出庫要求が同じ部品番号の行を参照して引当処理を行った。
(b) 参照した行単位に専有ロックを掛ける。
【コメント】
(a) 隔離水準がREAD COMMITTED（ダーティリードは発生しないが、ノンリピータブルリード及びファントムリードは発生する）の場合、先行する「出庫要求」トランザクションが短期ロック（参照）している中で、後続の「出庫要求」トランザクションが長期ロック（更新）すると、先行のトランザクションは後続のトランザクションで更新された結果に対して更新をかけてしまうため問題が生じてしまう。ここでいう問題は、参照時に”実在庫数量"－"引当済数量"≦"基準在庫数量"のチェックが働かないまま更新ができてしまうこと。そこまでは何となく読めてましたが、私は部品番号（行）について解答していましたが、ここでは具体的に"引当済数量"の不正を答えるべきでした。
(b) 上記(a)の問題を解決するには、参照時にその行に対して専有ロックを掛ければよく、問題文の1.ISORATIONレベルに「データ参照時にFOR UPDATE句を指定すると、対象行に専有ロックを掛け、トランザクション終了時に開放する」とあるので、FOR UPDATE句を指定する旨を解答すべきでした。
設問２
（１） a ウ b ア c エ d キ
（２） あ 入庫 い 在庫 う 実在庫数量 え 発注済フラグ
【コメント】
（１）トリガについてのSQL文は全く知りませんでした。勉強不足。「在庫」テーブルの"引当済数量"を更新する（UPDATE OF 引当済数量 ON 在庫）のはAFTERトリガであるため、空欄aにはAFTER、その際に発動契機となるのは新規に「在庫」テーブルに行が挿入された場合だから空欄bにはNEW、その際に発動する処理は行単位で行うから、空欄cにはFOR EACH ROW、その処理内容は、新規挿入された行（ASで定義したCHKROWで受けている）に対して”実在庫数量"－"引当済数量"≦"基準在庫数量"を満たすとき、（空欄d はWHEN）ストアドプロシジャーを呼び出す、という処理のようでした。
（２）このAFTERトリガは、「在庫」テーブルの"引当済数量"を更新する際に発動することを狙いとしていたが、この発動条件では"引当済数量"を更新する「出庫」でも発動してしまう。（空欄あ「出庫」）。「出庫」では、(6)にあるように「在庫」テーブル（空欄い「在庫」）の"引当済数量"（空欄う「引当済数量」を更新されるため、このAFTERトリガは「出庫」ごとに発動することになってしまう。これを繰り返さないようにするため、「在庫」テーブルの"発注済フラグ"（空欄え「発注済フラグ」）の状態をトリガ発動の判定条件に加えておく必要がある。具体的には"発注済フラグ"がオフであることをトリガ発動条件に含めるようにする。
設問３
（１） 在庫テーブル
（２）
① 出庫要求及び入庫で発生するトランザクションを部品番号単位とし、ロック粒度を小さくする
② 発注済フラグがオンの部品は出庫要求を受け付けないようにし、出庫要求と入庫の発生時期をずらす。
【コメント】
（１）「出庫要求」と「入庫」で参照されるのは「在庫」テーブルである。
（２）デッドロックは、異なるトランザクションが異なるタイミングで同じ対象を専有ロックしてしまうことにより、互いの処理が進まず処理が永遠に終わらない状態となること。これを回避するためには、①ロックを掛ける対象を「出庫要求」と「入庫」でタイミングをずらす、②ロックを掛ける対象の範囲を小さくして同時にロックする状況を少なくする（ロック粒度を小さくする）、ということが考えられました。iTECは突然ISOLATIONレベルがREPEATABLE READと定義し、この隔離水準を下げる解答を出してきましたが、FOR UPDATE句を用いていることからすると、問題で問うているISOLATIONレベルはREAD COMMITTEDが前提なのでは？と思っています。iTECとTAC両者で共通する解答には、部品番号順に更新処理を行うことにより、索引から読み込んだ行だけをロック対象としてロック粒度を抑えることが挙げられています。私の解答①では「複数の部品を１つのトランザクションに載せている」ことがロック粒度を大きくしていると思い、部品単位のトランザクション発生を解答したのですが、これはちょっと強引だったかもしれません。また②のトランザクション発生時期をずらすにしても、基準在庫が下回って入荷待ち（"発注済フラグ”がオン）の場合は出庫要求を受け付けないというのでは、業務に支障が出てしまうでしょう。
【平成31年度春期】データベーススペシャリスト試験 午後Ⅰ問１
自己採点結果 iTEC 32/50 TAC 36/50
設問１
以前は「候補キーを全て挙げよ」や「第３正規化せよ」という問題がありましたが、昨年から姿を消し、今年も午後Ⅱ問２のモデリング問題の簡易版となってました。前半はそこそこでしたが後半はいろいろ失点しています。
（１） ※属性の解答は、主キー（実線）を（PK）、外部キー（破線）を（FK）と表記します。
a 種目分類コード（FK） b 主催者番号（FK） c 種目コード（FK） d 大会番号（PK）
e 会員番号（PK） f 入金年月日 g 使用ポイント数
【コメント】
a 2(2)「種目は、種目コードで識別し、"種目分類コード"で、・・分類する」
b 3「大会は・・"主催者番号"を登録する」
c 5(1) 「エントリ枠は・・"種目コード"・・などを登録する」
d、e 2(3)「参加申込みは"大会番号","会員番号"で識別し、」
f 4(2) 「会員の参加費用の支払を確認して"入金年月日"を登録し、」
g 4(4)「会員はポイントを使用する場合、"使用ポイント"を登録し、」
（２）
【コメント】
①空欄a"種目分類コード"が外部キー
②空欄b"主催者番号"が外部キー
③"運営サービスコード"が主キーかつ外部キー
④"大会番号"が主キーかつ外部キー
⑤"アイテムコード"が主キーかつ外部キー
⑥"大会番号"が主キーかつ外部キー
⑦"大会番号"が主キーかつ外部キー
⑧空欄c"種目コード"が外部キー
⑨"会員番号"が主キーかつ外部キー
⑩"大会番号"が主キーかつ外部キー、そのうち"エントリ枠番号"はただの外部キーであるからこれは[エントリ枠]：[参加申込み]=１：多とすべきでした。
⑪iTECは１：１、TACはサブタイプを解答している。会員が大会申込をする時点では、ポイントを付与されていない（入金完了していない）会員が存在するから、[会員ポイント]⊆[会員]が正解かと思います。
設問２
【コメント】
iTECとTACで割れているのが、「参加申込数」の最後の列（iTECは"超過"、TACは"－"）、「抽選年月日に対する本日」（iTECは３列目まで”前"、TACは"－"）のようです。「参加申込数」の行については、評価時点が「日付が変わった時点及び参加申込受付時点」とあるので、募集期間後で抽選が行われた後でも「参加申込数」が”超過”状態が続いていると思われ、私の解答では誤答と思います。「抽選年月日に対する本日」の行については、募集期間前、募集期間中、募集期間後で参加申込数が定員以下の場合は決定表では考慮されない項目”－”と考えてました。
設問３
（１）
① 関係名：抽選エントリ枠、属性：後続エントリ枠番号
② 関係名：参加申込み、属性：エントリ枠番号
③ 参加申込みエントリ枠（大会番号(PK)、エントリ枠番号(PK)、会員番号(PK)、後続エントリ枠番号(FK)）
【コメント】
①多段階抽選に対応するには「抽選エントリ枠」に"後続エントリ枠番号"がないと成立しないと思い解答しました。iTEC、TACともこの通りでした。
②「参加申込み」と「エントリ枠」が直接関連を持ってしまうと多段階抽選を実現できないと思い、「参加申込み」で「エントリ枠」と連関する属性を削除し、「抽選エントリ枠」と関連を持たせればよいと考えていました。しかし、これでは"抽選結果"を保持することができません。多段階抽選の結果を「抽選エントリ枠」に持たせることで、１つの「参加申込み」について複数の「抽選エントリ枠」の結果を保持できるようにする必要があります。私の解答は誤答でした。
③「エントリ枠」と「参加申込み」は１：多の関連（リレーションは誤っていましたが）で、上記②を考慮すると、多段階抽選を導入すると「抽選エントリ枠」と「参加申込み」は多：多となります。そこで、両者には連関エンティティを持たせる必要があります。その主キーには「抽選エントリ枠」の主キー｛大会番号、エントリ枠番号｝と「参加申込み」の主キー｛大会番号、会員番号｝の複合キーとして｛大会番号、エントリ枠番号、会員番号｝となる、というところまでは分かりましたが、非キーにはその抽選結果を保持する必要がありました。ちょっと残念な誤答です。
（２） 会員番号（PK）、ポイント有効年月日（PK）、有効ポイント数
【コメント】
「会員」と「会員ポイント」が１：多になり、有効期間（年月日）と複合キーを構成するところまでは分かったのですが、非キー属性は元のスキーマが"ポイント残高"となっているため、素直にそれに合わせるべきでした。私の解答は誤答と思います。これもちょっと残念。
