2005年02月19日

[ テクニカルエンジニア(データベース)/H11 ]

H11午後II 問1 vol.2

H11午後II 問1(ITEC 2005予想問題集 午後II 問5) vol.2 vol.1

2回目でまた悩む。。

設問1(1)
発送に発送先拠点コードは必要か?
 対応する出庫を見れば,出庫先拠点コード=発送先拠点コード
 と,追えるので冗長ではないだろうか。
 iTAC解答例には記載がない。

発送(発送番号、発送年月日)

 伝票にあるからといってモデルにも追加するのはボトムアップの悪い例では??

入庫に出庫元拠点コードは必要か?
  「出庫元の拠点,対応する出庫番号」とあるので,出庫業務がある拠点コードであれば出庫番号から追えるので冗長と言える。

 しかし,この出庫元拠点コードに「内作部品の入庫」「生産現場からの戻入」「購入部品の入庫」「加工業者からの入庫」時の入庫元の拠点コードが入るのであれば,出庫元拠点コードは必要と言える。
 だが問題文からはいまいち読み取れない。それは,“出庫元の拠点”としている点で,同じ拠点コードが入るとは言え,取る値の範囲が違うので,属性名は変えるべきだと思う。(出庫元拠点コードではなく,入庫元拠点コードとか)

設問1(2),(3)
 「業務上どのような場合」はどう表現して良いものやら。
 iTACの解答例は淡白に書いているなぁ・・・

(2)他の事業者の拠点に対して送る目的で出庫される場合
(3)ある拠点の倉庫などの管理場所から送られてきた場合

(2)の場合,発送を伴う出庫でも業務的に出庫しただけでは,まだ,出庫の発送番号はNULLで,発送先仕分けの後,発送伝票が起票された時点で,出庫の発送番号に値を入れないといけない。

何が言いたいのかというと,場合を示す時の「業務の粒度」をどう考えるのかという点である。
文字数が許せば,ピンポイントで押さえた方が良いと思うんだけどなぁ。。。

設問2(1)まる1
 iTAC解答例じゃないよね。あれって,「表4 物流事象一覧表」の説明を入れるってことだよな。。。
こっちが本題
 「物流事象を記録するトランザクション処理」というのは,「発送業務」を対象としているのか「時点在庫を更新する業務」を対象としているのかで若干,答えが変わると思う。
 せっかくチェックロジックを入れるのであれば,アイテック解答例の積置在庫数,輸送中在庫数だけでなく,倉庫内在庫数の更新もチェック対象とすべきではないかなと。
 gakko解答例「時点在庫の属性{倉庫内在庫数,積置在庫数,輸送中在庫数}を,どのように更新するのか処理が特定できるような意味であるべき」と書いてみた。
 「どのように」には「どれを」「増なのか減なのか」という意味を含ませている。「どれを」だけでも十分と思われる。

設問3(2)
vol.1でもいろいろ書いたけど,やはり,差分反映が正解。
 棚卸し作業中は営業時間外なので出庫はないが,論理在庫と実在庫の差が判明するのは,翌営業日の午前中となるため,翌営業日午前中の出庫業務の有無は判断が分かれる所であろう。

さて,時間的流れを考えると

月末の営業日の営業終了時~翌日の営業開始直前
実在庫:9個
A:■■■■■■■■■

月末の営業日の翌日午前中
論理在庫:10個(月末の営業日の営業終了後の時点在庫)
B:■■■■■■■■■■

この時はじめて,棚卸し時点で実在庫が論理在庫より,1個少ないことが判明
C:■■■■■■■■■□ ←1個少ない!

(出庫業務があるとすると)
ここで出庫業務が既に始まっていていて,朝イチで2個出庫されてしまっていたとすると
D:■■■■■■■■□□ ←2個出荷(論理在庫-2)

この状態で,倉庫内在庫数をBに設定してしまうと,在庫が増えてしまうので
 倉庫内在庫数=D-(B-C)=8-(10-9)=7
もしくは
 倉庫内在庫数=C-当日出庫数=9-2=7
となる。

 しかし,棚卸日の翌日に出庫業務をしているのか,していないのか明記がないため
倉庫内在庫数=D-(B-C)
=(現在の倉庫内在庫数)-((前日営業終了後の倉庫内在庫数)-(実在庫数))
とするのが無難だろう。
 出庫業務をしていなければ,単に現在の倉庫内在庫数と前日営業終了後の倉庫内在庫数の値が同じだけということだ。ただ,この場合は,「現在の倉庫内在庫数」が分かることが前提となる。

 ここで矛盾に気付く。

 現在の倉庫内在庫数が分かるのなら,前日営業終了後の時点在庫の一覧表が午前中に出力されるのっておかしくないか??
 きっとそれって,帳票印刷だから。と,勝手に納得してみたりして。。。。w

この問題なんかすっきりしないんだよな。。。

Posted by g@kko at 2005/02/19 16:49 | 個別記事表示 | コメントを見る (2) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/H14午前, データベース技術 ]

H14AM40: 示現塾 2005年02月19日(土) 本格版 286号 第4問

示現塾 2005年02月19日(土) 本格版 286号

第4問 データベース技術(DB向け)
分野-5-1-3/技術レベル-III/出題頻度-中/出典:DB14-40

 二つのトランザクション T1 と T2 を並列に実行した結果が,T1 の完了後にT2を実行した結果,又は T2 の完了後に T1 を実行した結果と等しい場合,このトランザクションスケジュールの性質を何と呼ぶか。

ア 一貫性    
イ 原子性    
ウ 耐久性    
エ 直列可能性

Posted by g@kko at 2005/02/19 09:36 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/システムの開発と運用 ]

示現塾 2005年02月19日(土) 本格版 286号 第2問

示現塾 2005年02月19日(土) 本格版 286号

第2問 システムの開発と運用(SW,DB,SM,AU,ES向け)
分野-3-2-1/技術レベル-II/出題頻度-中/出典:NW13-07

 キャパシティ管理におけるシステム性能の向上策に関する記述のうち,適切なものはどれか。


ア CPU のクロック周波数を 2 倍にしても,ジョブのスループットは必ずしも2倍にはならないので,周辺機器などと合わせてシステムを増強する。

イ 仮想記憶システムにおける,補助記憶装置の容量を拡大し,ジョブの平均CPU時間を短縮する。

ウ 単一サーバのシステムを M/M/1 の待ち行列モデルとすると,平均応答時間が正規分布のグラフとして表されるので,グラフの山の部分の分析結果を計画に反映する。

エ トランザクション処理システムでは,単位時間当たりのトランザクションの到着数が n 倍( n=2,3,…)になると,平均応答時間も n 倍になることを考慮して,機器を増強する。

Posted by g@kko at 2005/02/19 09:33 | 個別記事表示 | コメントを見る (0) |
この記事をLicWikiに埋め込む:
[ テクニカルエンジニア(データベース)/コンピュータシステム ]

示現塾 2005年02月19日(土) 本格版 286号 第1問

示現塾 2005年02月19日(土) 本格版 286号

第1問 コンピュータシステム(SW,DB,SM,AU,ES向け)
分野-2-3-3/技術レベル-II/出題頻度-中/出典:SS15-14

 システムの信頼性を表すMTBF の説明として,適切なものはどれか。
 
ア ある期間内に発生したシステム障害の平均時間を示す。
イ ある期間内に発生したシステムダウンの平均時間を示す。
ウ 故障が発生した時から修復完了までの1故障当たりの平均復旧時間を示す。
エ 故障が復旧してから,次の故障が発生するまでの平均時間を示す。

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

H13午後I 問1

H13午後I 問1(ITEC 2005予想問題集 午後I 問1-3)

設問1
 定番問題

設問2
 定番問題

設問3
 関数従属性の図を完成させる問題

 予約(物件番号,棟番号,予約番号,顧客番号,第1希望,第2希望,登録日,抽選日)
 (すでに,登録日,抽選日は図2に明記してある。)

 まずは,候補キー,非キー属性を見極める。
 予約なんで予約番号は当然,候補キーに絡むと推察する。
 表から意味と制約を調べる。

 売出単位の中で一意になるように振られた予約登録の番号。
  売出単位は,棟単位とする。
  物件は,一つ又は複数の棟から成る。
 そして,どう考えても,第1希望,第2希望は非キー属性。
 よって,{物件番号,棟番号,予約番号}は候補キーのようだ。

 同じ顧客に,同じ物件の同じ棟の予約番号を複数発行することはない。
  顧客番号:登録された顧客を一意に識別する番号
 {物件番号,棟番号,顧客番号}も候補キーとなる。

 予約は候補キーが2つあり,かつ{物件番号,棟番号}が重複する重複キーである第3正規形であることが分かる。

 非キー属性の第1希望,第2希望にが候補キーから矢印を引く。
 2つの候補キーから矢印を引くのは冗長という見解もあるが,間違いではないと思う。

 候補キー同士で,{物件番号,棟番号,予約番号}←→{物件番号,棟番号,顧客番号}が成り立つ
 よって
  {物件番号,棟番号,予約番号}→{物件番号,棟番号,顧客番号}→顧客番号
  {物件番号,棟番号,顧客番号}→{物件番号,棟番号,予約番号}→予約番号
 であるので, (これは,候補キー→候補キー→候補キーを構成する属性なので推移関数従属ではない)
  {物件番号,棟番号,予約番号}→顧客番号
  {物件番号,棟番号,顧客番号}→予約番号
 と,矢印を引く。

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

作業記録(~2/18)

スタイルシート,テンプレートをいじる
カレンダーに試験日までのカウントダウンが1日ずれていた!!(直す)
Google AdSenseを付けてみる(飽きたら外す予定)
トップページのみに,amazonの和書@データベースのトップセラーを表示
よく分からないが,track feedを付けてみる(意味を感じなければ外す予定)
サードバーに「関連用語」を追加。ページ内でe-Wordsにある単語をリストアップ。ブログとリンクが必ず入ってしまうのはご愛嬌。
カテゴリアーカイブのページ表示に「すべて」を追加

Posted by g@kko at 2005/02/19 00:00 | 個別記事表示 | コメントを見る (6) |
この記事をLicWikiに埋め込む: