<< January 2018 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>
<< テクニカルエンジニア(データベース) H19 PM1-1 設問3 | main | テクニカルエンジニア(データベース) H19 PM2-2 >>

テクニカルエンジニア(データベース) H19 PM2-1

テクニカルエンジニア(データベース)午後2問1を解いてみた。
所要時間 2時間

設問1
(1)

  • プロジェクト担当部(プロジェクト番号, 担当部コード, PL社員番号, 割当見積工数, 割当契約金額)
  • プロジェクト別人件費予算(プロジェクト番号, 年度, 年月, 職務ランクコード, 要員数)
  • 職務ランク別人件費(職務ランクコード, 年度, 予算単価)
  • 人件費以外コスト予算(プロジェクト番号, 部コード, 年度, 年月, 費目コード, 予算金額)
  • 売上予算(プロジェクト番号, 部コード, 年度, 売上予算金額)


(2) 社員の職務ランクの変更後に、変更前の稼働実績が訂正された場合
(テーブル) 月別勤務実績
(列) 適用職務ランクコード

設問2
(1)
 稼働実績訂正入力月間稼働実績承認月間勤務実績承認
社員RRR
所属R R
プロジェクトRR 
月別勤務実績 URU
日別勤務実績  R
稼働実績明細RURU 

(2)
a 勤務実績/稼働実績入力機能を分割せず、稼働実績訂正入力機能と統合する方がよい。
b プロジェクト登録が間に合わなかった時を除き、勤務実績と稼働実績の合計が合致することをチェックすることができ、入力者の負担軽減となる。また、訂正入力時もインタフェースが統一された方が入力が容易である。

設問3
(1) 勤務実績エントリはレコード数が少ないことから入力時のレスポンスが改善される。また、勤務実績履歴の嗅覚文頭にインデックスを追加しても影響が出ない。
(2)
【月別勤務状況推移表出力について】
(対策) (c)
(対策内容) テーブル「部別月別勤務状況」を追加し、列「総超過勤務時間」「総深夜勤務時間」「総休日勤務時間」「総休日出勤日数」「所属社員数」を格納する。
(理由) 集計時に、社員別・日別に導出項目を計算する必要がなくなり、テーブル「所属」との結合も不要となるため。
(影響) なし
(処理の内容) 月締め処理の際に集計を行い、部別月別勤務状況にレコードを追加する。
【プロジェクト予算/実績管理表出力について】
(対策) (a)
(対策内容) テーブル「稼働実績明細」に、列「勤務ランクレコード」を追加する。
(理由) 月別の人件費の実績工数の集計に当たり、「稼働実績明細」と他のテーブルとの結合が不要になる。
(影響) なし
(処理の内容) なし

【感想】午後1の傾向も併せると、「出題分野の広い範囲を勉強して欲しい」と出題者が考えているのではないかと感じる。データベーススペシャリスト時代の出題に近いような気がする。
ss2004 * テクニカルエンジニア(データベース) * 14:16 * comments(15) * trackbacks(0)

コメント

設問3(2)の「プロジェクト予算/実績管理表出力」の方は、「任意に対策を選び、」とあるので、あえて(a)にしてみた。
Comment by ss2004 @ 2007/04/28 2:19 PM
DB19PM2-2-(1) 勤務・稼動実績管理システム
CRUD表の穴埋めの小問ですが、これに関して
出題文中に下記の主旨の記述があります。
 部長による勤務実績承認時に、
 勤務合計と稼動合計が不一致だと
 エラー表示で承認できない
この判定のためには、稼動実績のRead(いちばん右下)で
締め月の集計が必要だと思うのですが、
私が見たIPAと完全教本はともにnogさんと同じで
空白です。
今のところ納得が行きません。勘違いでしょうか。
Comment by @ 2008/03/19 8:53 PM
ちょうどその問題に関するエントリがありましたので、コメントを移動しました。

さて、私が、御指摘の箇所にRを入れなかった理由は、「気がついていなかった」の一言です。この部分を解くときには、「6.月間勤務実績承認」の部分しか見ていませんでした。

そして、IPAの解答の件ですが、おそらく、「稼働時間の合計」と「勤務実績の合計」の整合性のチェックは、アプリケーションでチェックするのではなく、ASSERTION(表明定義)で行うからではないでしょうか。

DBMSを使用して業務アプリケーションを作成するメリットは、データインテグリティの確保を、テーブル設計(正規化)やDBMSに委ねることが出来るという点ですので、こうしたチェックの仕方は適切だと思います。
CRUD分析でいうReadは、アプリケーションがSELECT文を発行するという意味だと思いますので(http://ja.wikipedia.org/wiki/CRUD参照)、ここにはRを記述しなくていいと思います。
Comment by ss2004 @ 2008/03/19 9:07 PM
返事ありがとうございます(別の記事に書き込んでましたか?)
assertionは仕事で見たことも本で読んだこともないです・・・500円の完全教本に一言だけ書いてあった以外は。少なくともこの三日間では自発的に思い当たりませんでした。
一方でビジネスロジックで充分に行けることを知っているだけに、誤答扱いならば簡単には承服しかねます。assertion自体には罪も害もないので勉強はしますが。
Comment by @ 2008/03/20 1:42 AM
ずいぶんと昔の問題になりますが、平成10年度(データベーススペシャリスト時代)の午後2問2に、各種の制約定義を利用してインテグリティを確保する考えが出てきます(ASSERTIONも出てきます)。
問題作成者側の意識としては、そういう一貫した流れがあるのかも知れません。
Comment by ss2004 @ 2008/03/20 9:49 AM
返事ありがとうございます。いくらか勉強してきました。
assertion とは概ね、複数の表を対象にできる
check制約だと解してました。
とすると

従業員が日々入力する時のinsert自体の可否なら分かります
が、この問は、日々の入力時にはノーチェックで登録させ
部長による閲覧時にエラー表示をするというものです。
その処理をassertion形態にするのは適切でしょうか??
Comment by @ 2008/03/21 7:30 PM
よく確認してみました。
ASSERTIONのチェックを遅延することはできるが、コミット時にはチェックされるとのことなので、今回のように、月締め時の整合性を確認するのは無理のようです。
この問題では、勤務実績だけを毎日登録して、稼働実績は後からでも良いというルールなので、いずれにしても、ASSERTIONではチェックできないということですね。

確かに、〔稼働実績/稼働実績管理システムの概要設計〕の3(3)の説明を読むと、稼働実績明細を参照する必要があるとしか思えなくなってきました。
出題者のミスでしょうか。
Comment by ss2004 @ 2008/03/21 10:00 PM
返事ありがとうございます。
他の出版物も調べたところ
合格教本のみ R 付きでした。
今でも譲れませんねこれは。

この件は打ち切って下さってかまいません。
正直言いますと
他にもっとお聞きしたいモンダイを抱えていますので。
Comment by @ 2008/03/23 12:03 AM
お役に立てずすみません。

合格教本には、何か説明はありましたか?

私自身は、月間稼働実績承認で、所属を参照する意味が分かりません。
Comment by ss2004 @ 2008/03/23 8:17 AM
お返事ありがとうございます。
説明としては私が上で書いたのと同じ内容だけだったと
思います(承認画面表示時にエラー判定云々)

所属 は画面上部、社員の所属部名の表示だけを目的として
読み込むのではないでしょうか。
Comment by @ 2008/03/23 2:27 PM
部名は、設問1で作成した「プロジェクト担当部門」から「部コード」で「部」を引いているのではないかと思ったんですが、どうなんでしょう。
画面の構成も、斉藤洋子の所属が金融システム部という意味ではなく、Y社収益管理システムの金融システム部のPLが斉藤洋子という意味にとれるのですが。
Comment by @ 2008/03/23 3:09 PM
(2:27 PM の回答は不適当でしたね)
 ・・・
それでしたら、その部だけの所属社員を
画面表示するためには 所属 の参照が必要ではないですか。
稼動の承認者はPLで、PLは部毎ですから。
(PMはプロジェクト全体に一人)
Comment by @ 2008/03/23 4:35 PM
〔組織と業務の概要〕3.プロジェクト予算/実績管理(3)プロジェクト管理に、「PLは、担当プロジェクトメンバ全員の稼働実績を確認して、承認する。」とありますけど、ここは、当然、「自部内の」を補って考えるべきでしょうか。

実は、よく考えるとPLを併任しない場合のPMの稼働実績承認をどのように行うのかも謎です。
Comment by ss2004 @ 2008/03/23 4:54 PM
5(1)以降にも 部ごとに作業する とは
文章には書いてないわけですか。
自分は図3から明らかと判断しました。
もしももしも他部社員分の承認もできるとしても、
画面上部に自分の部名を表示するためには
マスタの参照が必要ですよね。
コードから名称に翻訳するだけでも R でしょう。

後半の疑問については「PMとPLは自分で承認する」と5(1)に。
Comment by @ 2008/03/23 11:36 PM
画面上部に表示する部名については、

>部名は、設問1で作成した「プロジェクト担当部門」から「部コード」で「部」を引いているのではないかと思ったんですが、どうなんでしょう。
>画面の構成も、斉藤洋子の所属が金融システム部という意味ではなく、Y社収益管理システムの金融システム部のPLが斉藤洋子という意味にとれるのですが。
>Comment by @ 2008/03/23 3:09 PM
に戻ります。

PLだけに入力が許される以上、画面入力するユーザがPLかどうか確認する必要があり、「プロジェクト担当部門」を参照して確認する必要があります。そうすると、必然的に部コードは引けます。

「PMとPLは自分で承認する」とありますが、PMはどうやって入力するのかが判然としません。その時PL氏名とかはどうなっているのでしょう。
Comment by ss2004 @ 2008/03/24 4:19 AM
コメントする









トラックバック

このページの先頭へ