H17午後II 問1
機械式駐車場設備メンテナンス業務
設問２（２）
要件を整理し，出動目的と属性値の決定に関するデシジョンテーブルを完成させる。
出動目的は，表４ 出動目的一覧の出動目的からそのまま引用する。
埋めやすいものから手を付ける。
ｆ） 緊急呼出し年月日にＸがあるのはこれだけなので，出動目的は「緊急呼出し」
ｇ） よく分からず，とりあえず保留
ｈ） 修理指示メーカ番号のＸと完全に一致するので，出動目的は「メーカ指示修理」
ｉ） 提案番号のＸと完全に一致するので，出動目的は「提案修理」
ｊ） 前回出動番号のＸと完全に一致するので，出動目的は「継続出動」
残るは「定期点検」のみ。よって，ｇ）は「定期点検」
解答例：設問２（２）
ｆ）緊急呼出し
ｇ）定期点検
ｈ）メーカ指示修理
ｉ）提案修理
ｊ）継続出動
設問２（３）
要件実現の検討（未対応指摘，対応方策記述）
要件１：出動目的別の出動回数の把握
出動→出動内訳←出動目的
特に問題なく，対応可能。
（目的別の出動回数合計は，本当の出動回数の合計と一致しない点には注意が必要・・・問題には関係ないが）
要件２：出動目的別部位装置別修理実績の把握
確認すべき項目は
① 出動目的→出動内訳←出動→・？・→駐車場設備修理
② 「修理」と「出動」の業務的な関係
表3「メンテナンス作業における出動指示書と報告書提出の関係」と業務の説明より確認する。
・定期点検：定期点検の結果によって，必要な修理を実施する。
・自発的部品交換：修理報告書はないが交換部品を登録する。
・メーカ指示修理
・緊急呼出し：不具合箇所の特定と修理
・継続出動：定期点検結果による修理及び緊急呼出しによる修理の2日目の作業
・提案修理
疑問１：「修理」＝「修理報告書」なのか，自発的部品交換を含むのか
疑問２：継続出動時のエンティティ「出動内訳」の扱い
例）定期点検の場合
１日目） 定期点検 １レコード
２日目） 継続出動 １レコード
なのか
１日目） 定期点検 １レコード
２日目） 定期点検，継続出動 ２レコード
なのか。。。
デジョンテーブルに出動目的が「継続出動」のみのものがあるため，前者と思われる。
出動内訳←出動→・？・→駐車場設備修理
出動に対して，駐車場設備修理は一意に特定できる。
しかし，出動の出動内訳が複数ある場合は，どの出動内訳による修理なのか特定できない。
そもそも「どの出動内訳による修理」なのか特定する必要があるのか？
⇒表６のデジョンテーブルを見ると，修理作業がある出動目的の組合せが混在している。
と，いうか全ての出動目的で修理作業が発生し得る。
どの出動内訳なのか特定する必要があると思われる。
さて，対応する方策だが，「属性の変更，追加だけで対応」という条件が付いているので，その範囲内で考える。
一番手っ取り早いのは，エンティティ＠駐車場設備修理に属性＠出動目的番号を追加することではないだろうか。（安易過ぎるか？）
解答例①：要件２
対応できない理由
出動目的が複数ある時に修理作業が発生した場合，どの出動目的による修理作業か特定できないため。（４６文字）
対応するための方策
部位装置別に出動目的が管理できるよう，エンティティ“駐車場設備修理”に属性“出動目的番号”を追加する。（５０文字＠禁則処理）
要件３：１日で完了しなかった修理作業の把握
疑問２：継続出動時のエンティティ「出動内訳」の扱い
が，また。。。
２日目の出動内訳は，「継続出動」だけと想定する。
疑問３：「修理作業」って何？定義は？
メーカ指示修理＋提案修理？ それとも 修理報告書を提出する作業？ それとも 駐車場設備修理を行ったすべての作業？
疑問４：「提案修理」の２日目以降の「出動目的」は何？と，いういか２日目以降はデータ登録しているの？２日以上の場合，修理作業結果はどう登録するのさ？ ・・・ 分からん事が多すぎる。
１日で完了しなかった修理作業＝継続出動で修理を行った作業であるが，提案修理の２日目以降の作業は「継続出動」と呼ばない。（「前回出動番号」も持っていない。）
もうひとつ別の側面から考える。継続作業時に別の出動目的と重なり，別の出動目的で修理を行うとどうだろうか？ここが疑問２のミソなんだよなぁ。。。「継続作業時には継続作業のみを実施する。」とは書いていないし，『緊急呼出し→継続出動＠修理＋ついでに自発的部品交換＠修理』なんてな（どのみち修理には変わりないか。。。）
１日で完了しなかった（提案修理が何日かかろうが知らないということであれば）修理作業は，継続出動をカウントすれば把握できる？とも思ったが，提案修理は２日目以降の作業を「継続作業」と呼ばない。つまり，２日目は「継続作業」ではないので，これはＮＧ。
では，駐車場設備修理がない提案修理は１日目で完了しなかった作業か？
疑問４が立ちはだかる。２日以上かかっても，最初の出動に修理結果を登録すると。。。ＮＧ。
解答例②：要件３
対応できない理由
提案修理による作業は継続出動として管理されないため，何日で修理が完了したか把握できない。（４４文字）
対応するための方策
作業日数を把握するため，エンティティ“出動”に属性“作業完了年月日”を追加する。（４０文字）
要件４：修理が発生しなかった緊急呼出し回数の把握
｛出動内訳（緊急呼出し）→出動｝
－｛出動内訳（緊急呼出し）→出動→・？・→駐車場設備修理｝
－｛前回出動番号の出動目的が緊急呼出しの出動内訳（継続出動）→出動→・？・→駐車場設備修理｝
差集合演算で求められる。（と，思う）
