2005年05月31日

[ テクニカルエンジニア(データベース)/試験について ]

公式解答例@午後発表

H17年度 春期 以下の試験区分の午後I,IIの公式解答例が発表された。
 システム監査技術者試験(AU)
 テクニカルエンジニア(データベース)試験(DB)
 テクニカルエンジニア(システム管理)試験(SM)
 テクニカルエンジニア(エンベデッドシステム)試験(ES)
 ソフトウェア開発技術者試験(SW)

http://www.jitec.jp/1_05goukaku/kaitourei.html

Posted by g@kko at 2005/05/31 12:00 | 個別記事表示 | コメントを見る (22) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17午後II 問1設問3

H17午後II 問1
機械式駐車場設備メンテナンス業務

設問3(1)
 駐車場設備単位の点検実績は全件保持するが,点検結果項目別の点検結果については,異常時のものだけを保持するスキーマ設計にしている。この方法で,正常時及び異常時とも管理可能である理由について
 駐車場設備単位の点検実績は全件保持=「駐車場設備点検」はある。
 正常時は「部位装置点検結果」と「検出異常」がない。

解答例
駐車場設備点検の主キーを持つ部位装置点検結果・検出異常が存在しなければ,それぞれ部位・点検項目は正常と判断できるため。(59文字)

※異常時のものだけを保持するスキーマ設計にしているが,この方法でも正常時のデータ登録が可能である理由
 とも読めなくも無い。。属性@修理区分に“正常”を追加するとかw

設問3(2)(a)
同音異義語を指摘すれば良いかと。
解答例
部位装置点検項目の開始年月日と点検項目の開始年月日は同音意義語であるため参照関係を設定できない。(48文字)

設問3(2)(b)
解答例
テーブル“点検項目”の属性“開始年月日”をテーブル“部位装置点検項目”の“開始年月日”と同意にし,新たにテーブル“点検項目”に属性“正常条件開始年月日”を主キーの構成列として追加し,列として“正常条件終了年月日”を追加する。(112文字)

「“”」と“正常条件終了年月日”は文字数稼ぎ。

Posted by g@kko at 2005/05/31 10:36 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H17 ]

H17午後II 問1設問2(2),(3)

H17午後II 問1
機械式駐車場設備メンテナンス業務

設問2(2)
要件を整理し,出動目的と属性値の決定に関するデシジョンテーブルを完成させる。
出動目的は,表4 出動目的一覧の出動目的からそのまま引用する。

埋めやすいものから手を付ける。
f) 緊急呼出し年月日にXがあるのはこれだけなので,出動目的は「緊急呼出し」
g) よく分からず,とりあえず保留
h) 修理指示メーカ番号のXと完全に一致するので,出動目的は「メーカ指示修理」
i) 提案番号のXと完全に一致するので,出動目的は「提案修理」
j) 前回出動番号のXと完全に一致するので,出動目的は「継続出動」
残るは「定期点検」のみ。よって,g)は「定期点検」

解答例:設問2(2)
 f)緊急呼出し
 g)定期点検
 h)メーカ指示修理
 i)提案修理
 j)継続出動

設問2(3)
要件実現の検討(未対応指摘,対応方策記述)

要件1:出動目的別の出動回数の把握
 出動→出動内訳←出動目的
 特に問題なく,対応可能。
 (目的別の出動回数合計は,本当の出動回数の合計と一致しない点には注意が必要・・・問題には関係ないが)

要件2:出動目的別部位装置別修理実績の把握
確認すべき項目は
① 出動目的→出動内訳←出動→・?・→駐車場設備修理
② 「修理」と「出動」の業務的な関係

表3「メンテナンス作業における出動指示書と報告書提出の関係」と業務の説明より確認する。
・定期点検:定期点検の結果によって,必要な修理を実施する。
・自発的部品交換:修理報告書はないが交換部品を登録する。
・メーカ指示修理
・緊急呼出し:不具合箇所の特定と修理
・継続出動:定期点検結果による修理及び緊急呼出しによる修理の2日目の作業
・提案修理

疑問1:「修理」=「修理報告書」なのか,自発的部品交換を含むのか
疑問2:継続出動時のエンティティ「出動内訳」の扱い
     例)定期点検の場合
      1日目) 定期点検 1レコード
      2日目) 継続出動 1レコード
       なのか
      1日目) 定期点検 1レコード
      2日目) 定期点検,継続出動 2レコード
       なのか。。。
       デジョンテーブルに出動目的が「継続出動」のみのものがあるため,前者と思われる。
   
出動内訳←出動→・?・→駐車場設備修理
出動に対して,駐車場設備修理は一意に特定できる。
しかし,出動の出動内訳が複数ある場合は,どの出動内訳による修理なのか特定できない。
そもそも「どの出動内訳による修理」なのか特定する必要があるのか?
⇒表6のデジョンテーブルを見ると,修理作業がある出動目的の組合せが混在している。
 と,いうか全ての出動目的で修理作業が発生し得る。
 どの出動内訳なのか特定する必要があると思われる。

 さて,対応する方策だが,「属性の変更,追加だけで対応」という条件が付いているので,その範囲内で考える。
 一番手っ取り早いのは,エンティティ@駐車場設備修理に属性@出動目的番号を追加することではないだろうか。(安易過ぎるか?)

解答例①:要件2
対応できない理由
 出動目的が複数ある時に修理作業が発生した場合,どの出動目的による修理作業か特定できないため。(46文字)
対応するための方策
 部位装置別に出動目的が管理できるよう,エンティティ“駐車場設備修理”に属性“出動目的番号”を追加する。(50文字@禁則処理)
 

要件3:1日で完了しなかった修理作業の把握
疑問2:継続出動時のエンティティ「出動内訳」の扱い
が,また。。。
2日目の出動内訳は,「継続出動」だけと想定する。

疑問3:「修理作業」って何?定義は?
メーカ指示修理+提案修理? それとも 修理報告書を提出する作業? それとも 駐車場設備修理を行ったすべての作業?
疑問4:「提案修理」の2日目以降の「出動目的」は何?と,いういか2日目以降はデータ登録しているの?2日以上の場合,修理作業結果はどう登録するのさ? ・・・ 分からん事が多すぎる。

 1日で完了しなかった修理作業=継続出動で修理を行った作業であるが,提案修理の2日目以降の作業は「継続出動」と呼ばない。(「前回出動番号」も持っていない。)
 もうひとつ別の側面から考える。継続作業時に別の出動目的と重なり,別の出動目的で修理を行うとどうだろうか?ここが疑問2のミソなんだよなぁ。。。「継続作業時には継続作業のみを実施する。」とは書いていないし,『緊急呼出し→継続出動@修理+ついでに自発的部品交換@修理』なんてな(どのみち修理には変わりないか。。。)

 1日で完了しなかった(提案修理が何日かかろうが知らないということであれば)修理作業は,継続出動をカウントすれば把握できる?とも思ったが,提案修理は2日目以降の作業を「継続作業」と呼ばない。つまり,2日目は「継続作業」ではないので,これはNG。
 では,駐車場設備修理がない提案修理は1日目で完了しなかった作業か?
 疑問4が立ちはだかる。2日以上かかっても,最初の出動に修理結果を登録すると。。。NG。

解答例②:要件3
対応できない理由
 提案修理による作業は継続出動として管理されないため,何日で修理が完了したか把握できない。(44文字)
対応するための方策
 作業日数を把握するため,エンティティ“出動”に属性“作業完了年月日”を追加する。(40文字)


要件4:修理が発生しなかった緊急呼出し回数の把握
{出動内訳(緊急呼出し)→出動}
 -{出動内訳(緊急呼出し)→出動→・?・→駐車場設備修理}
 -{前回出動番号の出動目的が緊急呼出しの出動内訳(継続出動)→出動→・?・→駐車場設備修理}
差集合演算で求められる。(と,思う)

Posted by g@kko at 2005/05/31 09:54 | 個別記事表示 | コメントを見る (2) |
この記事をLicWikiに埋め込む: