<< May 2017 | 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 >>

データベーススペシャリスト 合格のまとめ

延期になったこともあり、なかなかモチベーションが上がらなかったが、全区分90点以上の好成績で合格できた。
以前のテクニカルエンジニア(データベース)受験のときに、徹底的に勉強したせいだろう。

今回の合格により、
・合格13区分目
・高度区分試験7連勝(発熱棄権を除けば11連勝)
・現スペシャリスト4区分中、3つを獲得。残りはネットワークのみ。
となった。

次は、ネットワークスペシャリスト。
ss2004 * データベーススペシャリスト * 11:42 * comments(0) * trackbacks(0)

データベーススペシャリスト 合格

平成23年度 特別 データベーススペシャリスト試験 成績照会
受験番号 DB305-0118 の方は,合格 です
午前菊静 ***.**点
午前尭静 96.00点
午後菊静 93点
午後尭静 92点
ss2004 * データベーススペシャリスト * 19:21 * comments(0) * trackbacks(0)

公式解答例 発表

jitecから、公式解答例が発表された。

おおむね、予想どおりの解答だった。
午後2問2で、「部材」と「部品」・「部品生産用部材」のスーパータイプ・サブタイプ関係が別の切り口になるのはあり得るとして、「取引先」と「部材メーカ」がサブタイプが一つしかないスーパータイプ・サブタイプ関係になるのは意外だった(ネットでもこういう解答はお目にかかったことがない)。
どのように考えればいいのかが難しいが、それぞれのエンティティのインスタンス数(レコード数)を考慮するのがいいだろうか。
「部材メーカ」でない「取引先」もいるため、
「取引先」のインスタンス数 > 「部材メーカ」のインスタンス数
である。=なら、通常のリレーションシップになるだろう。
また、
「部材」のインスタンス数 < 「部品」のインスタンス数 + 「部品生産用部材」のインスタンス数
である。これが=であれば、「部品」と「部品生産用部材」は一つの切り口のサブタイプ達になっただろう。

ともかくも合格は確定的。
予想得点は午後1・午後2とも、80点台後半くらい。
ss2004 * データベーススペシャリスト * 00:23 * comments(0) * trackbacks(0)

データベーススペシャリスト 午後1 アイテック・わくすたの解答例

アイテックとわく☆すたの午後1の解答例と比べてみる。

問1
設問1 まあ、同じ。
設問2
(1) 自己記録の候補キー、わく☆すたでは、会員IDとなっているが、ケアレスミスだろう。
(2) 同じ。
設問3
(1) 俺の解答では、クラスが第4正規形でないがゆえの更新異状を指摘してしまっている(わく☆すたも?)。予約枠ID→{予定日時, メニューID}という部分関数従属の問題を指摘しているアイテックが妥当か。
(2) わく☆すたの右側の表は単なるケアレスミスだろう。

問2
設問1
(1) 同じ。
(2) アイテックのはやはりまずい。図1を見る限り、店舗が変わっても利用可能時間や対象商品は同じなのだから、それを反映してなければいけないだろう。
設問2
(1)(a) 同じ。
(b)
・上から2,NULL,2の場合、単品か一括商品で、かつ単品商品で、かつ複合商品の意だから、そのような商品は存在しない(わく☆すた間違い)。
・上からNULL,1,2の場合、「ただのセット商品」だから、「セット商品と一括商品は、商品別に、提供する曜日、時間帯を限定している」ので、商品提供時間を参照する(アイテック間違い)。
・上からNULL,2の場合、セット商品で、かつ一括商品だから、そのような商品は存在しない(わく☆すた間違い)。
・上からNULL,NULLの場合、セット商品で、かつ単品商品だから、そのような商品は存在しない(わく☆すた間違い)。
この設問は落ち着いて考えれば確実に解けるので、解答例として発表するものが間違っているのは考えられない。
設問3
1点は、俺もアイテックもわく☆すたもあげるように、セット取扱いによる注文取消しと客からの取消しとの区別がつかない点で間違いないと思う。
もう1点は、アイテックの解答が正解だろう。
図4を見る限り、卵焼きが2レコードに存在し、明らかに図3のテーブル構造に反している。「一つの注文伺いの中で、一つの商品が注文された後その場で取り消された場合は、注文がなかったものとする」という説明も合致する。つまり、「注文がなかったものとする」ルールなら図3のテーブル構造で問題がないが、セット取扱いを導入する以上、図3のテーブル構造では問題が生じるので、これは指摘するべきである。追加列を問うのでなく、列を追加した後のテーブル構造を問うという形も納得。
試験中に「一つの注文伺いの中で、一つの商品が注文された後その場で取り消された場合は、注文がなかったものとする」という説明に着目はしたが、解答にたどり着けなかったことに反省。


ss2004 * データベーススペシャリスト * 01:03 * comments(0) * trackbacks(0)

データベーススペシャリスト 午後2終了

20110626100931.jpg
午後2終了。
問2を選択。

予想はしていたが書く量が半端ない。

俺の解答

(1) 表6

物流事象物流元拠点物流先拠点物流対象出庫入庫発送
部品生産用部材払出しパーツセンタ部品生産現場部品生産用部材
部品完成部品生産現場パーツセンタ部品
通常支給パーツセンタ組立工場倉庫部品
部品払出し倉庫製品組立現場部品
横持ち組立工場倉庫組立工場倉庫部品
余剰戻し生産現場倉庫部材
余剰返送組立工場倉庫パーツセンタ部品
廃版廃棄パーツセンタ部材


【以下、スーパータイプ・サブタイプを、「スーパータイプ −△− サブタイプ1/サブタイプ2」と示す】

(2) 図3
事業所 → 拠点
拠点 −△− 生産現場/倉庫/部材メーカ
部門 → 生産現場
部門 → 倉庫
取引先 → 部材メーカ
生産現場 −△− 部品生産現場/製品組立工場
倉庫 −△− パーツセンタ/組立工場倉庫
部材品目 → 部材
部材 −△− 部品/部品生産用部材
部材 → 在庫 ← 倉庫

(3) 図4
出庫 −△− 部品生産用部材払出し出庫/通常支給出庫/部品払出し出庫/横持ち出庫/余剰返送出庫/廃版廃棄出庫
発送 − 通常支給出庫
発送 − 横持ち出庫
発送 − 余剰返送出庫
入庫 −△− 購入部材受入れ入庫/部品完成入庫/通常支給入庫/横持ち入庫/余剰戻し入庫/余剰返送入庫

(4) 図5
a 拠点コード, 事業所コード
b 生産現場(生産現場拠点コード, 現場区分, 部門コード)
c 部品生産現場(部品生産現場拠点コード, 部品払出要求時間)
d 製品組立現場(製品組立現場拠点コード, 部品投入時間)
e 倉庫(倉庫拠点コード, 倉庫区分, 部門コード)
f パーツセンタ(パーツセンタ拠点コード, 棚卸実施日入出庫終了時間)
g 組立工場倉庫(組立工場倉庫拠点コード, 入出庫可能コンテナサイズ)
h 部材メーカ(部材メーカ拠点コード, 取引先コード, 物流費負担率)
i 部材品目番号, 部材品目名
j 部材(部材番号, 部材品目番号, 部材名, 部材単価)
k 部品(部品部材番号, 製品組立投入ロットサイズ)
l 部品生産用部材(部品生産用部材番号, 部品生産投入ロットサイズ)
m 倉庫拠点コード, 部材番号, 在庫数量)
n 部品生産用部材払出し出庫(出庫番号, 出庫元パーツセンタ拠点コード, 出庫先部品生産現場拠点コード, 部品生産用部材番号)
o 通常支給出庫(出庫番号, 出庫元パーツセンタ拠点コード, 出庫先組立工場倉庫拠点コード, 部品番号, 発送番号)
p 部品払出し出庫(出庫番号, 出庫元倉庫拠点コード, 出庫先製品組立現場拠点コード, 部品番号)
q 横持ち出庫(出庫番号, 出庫元組立工場倉庫拠点コード, 出庫先組立工場倉庫拠点コード, 部品番号, 発送番号)
r 余剰返送出庫(出庫番号, 出庫元組立工場倉庫拠点コード, 出庫先パーツセンタ拠点コード, 部品番号, 発送番号)
s 廃版廃棄出庫(出庫番号, 出庫元パーツセンタ拠点コード, 部材番号)
t 購入部材受入れ入庫(入庫番号, 入庫元部材メーカ拠点コード, 入庫パーツセンタ拠点コード, 部材番号)
u 部品完成入庫(入庫番号, 入庫元部品生産現場拠点コード, 入庫パーツセンタ拠点コード, 部品番号)
v 通常支給入庫(入庫番号, 入庫元パーツセンタ拠点番号, 入庫組立工場倉庫拠点コード, 部品番号)
w 横持ち入庫(入庫番号, 入庫元組立工場倉庫拠点コード, 入庫組立工場倉庫拠点コード, 部品番号)
x 余剰戻し入庫(入庫番号, 入庫元生産現場拠点コード, 入庫倉庫拠点コード, 部材番号)
y 余剰返送入庫(入庫番号, 入庫元組立工場倉庫拠点コード, 入庫パーツセンタ拠点コード, 部品番号)
z 棚卸数量, 補正前倉庫内在庫数量, 補正数量

※1 上記解答は、ほぼ記憶に基づく。
※2 とりあえず現時点で気づいた間違い。
・「発送」と「通常支給出庫」・「横持ち出庫」・「余剰返送出庫」間のリレーションシップは1:nになるだろう。
・「出庫」サブタイプと「入庫」サブタイプで対応するものの間には1:1のリレーションシップが引けるだろう(入庫側に出庫番号を持つ、部品(等)番号は持たない)。
ss2004 * データベーススペシャリスト * 16:36 * comments(0) * trackbacks(0)

データベーススペシャリスト 午後1終了

問1と問2を選択。

問1が解答欄の大きさの割りに早く終わったので余裕こいてたら、意外と問2で苦戦。
まあ全部埋められたし、午後2には進めるだろう。

俺の解答

問1
設問1
(1) 単一の属性値を持たない「有料メニュー選択」を属性として持つから。
(2) (左上から)入会金、月会費、メニューID、オプション名、追加月額、メニュー名、標準時間
 会員種別ID → {入会金, 月会費, 利用可能日, 利用可能時間}
 オプションID → {オプション名, 追加月額}
 メニューID → {メニュー名, 標準時間, 料金, 定員}
(3) {スタッフID, 更新日, 担当可能日時}
設問2
(1)
自己記録 {会員ID, 記録日}・第3正規形・なし・なし
目標 {会員ID, 経過日数, 設定日}・第1正規形・あり・なし (部分関数従属){会員ID, 設定日} → {スタッフID, 基準日}
測定 {会員ID, 測定日時}・第3正規形・なし・なし
(2) 目標
目標 (会員ID, スタッフID, 基準日, 設定日)
経過日数別目標 (会員ID, 経過日数, 設定日, 体脂肪率, 筋肉量, 体重, 腹囲)
設問3
(1) 予約枠R4に参加する会員や担当スタッフが変更になった場合、複数の行を変更しなければならず、変更漏れが起こる恐れがある。
(2)
a 予約枠ID
b 会員ID
c スタッフID
(3)

予約枠ID会員ID
R1A1
R2B1
R2B2
R3A1
R4C1
R4C2
R4C3


予約枠IDスタッフID
R1S1
R2S2
R3S1
R4S2
R4S3


問2
設問1
(1) {クーポン番号, 商品番号, 曜日, 時間帯番号, 店舗番号}
(2)
クーポン(クーポン番号, 開始年月日, 終了年月日, 割引額)
クーポン利用可能商品(クーポン番号, 商品番号)
クーポン利用可能時間(クーポン番号, 曜日, 時間帯番号)
クーポン利用可能店舗(クーポン番号, 店舗番号)
設問2
(1)(a)
a ③
b ②
c ①
(b)
商品提供時間   X---X----
単品商品変動単価 -X-------
一括商品変動単価 X--------
(2)
d 曜日, 時間帯番号
e 店舗番号, 曜日, 時間帯番号, 変動単価
f 店舗番号, 曜日, 変動単価
設問3
(1)
・利用客からの注文によるセットとセット商品扱いを区別できない。
・取消しが利用客からの取消しによるかセット商品扱いのためか区別できない。
(2)
売上明細(店舗番号, 売上伝票番号, 注文伺時分秒, 商品番号, 数量, 販売単価, クーポン番号, セット扱い区分, 取消し区分)
セット扱い区分 ・・・ 利用客からの注文によるセットかセット商品扱いかを示す。
取消し区分 ・・・ 取消しが利用客からの取消しによるかを示す。
ss2004 * データベーススペシャリスト * 14:10 * comments(0) * trackbacks(1)

データベーススペシャリスト 午前2終了

俺の解答
イイイイウ
ウイエエエ
ウイアアエ
エアアイエ
アイウウエ
ss2004 * データベーススペシャリスト * 11:42 * comments(0) * trackbacks(0)

データベーススペシャリスト 午前1は免除

今回、午前1は免除。
ss2004 * データベーススペシャリスト * 09:42 * comments(0) * trackbacks(0)

テクニカルエンジニア(データベース) H18 PM1-3

設問1
(1) 被参照テーブルの行削除時の動作としては、「削除されると困るので削除させない」「参照テーブル側のレコードも削除する」「かまわず削除させる」の3種類が考えられる。
 「削除させない」が「NO ACTION」、「参照側も削除」が「CASCADE」、「かまわず削除」が「SET NULL」又は「SET DEFAULT」である。
 「クラスを中止する場合は、そのクラスに対する部署別申込み及び受講申込みを取り消す」とあるので、aはCASCADE。
 b・cもCASCADEなので「クラス」の列を参照すると考えられるが、「部署別申込み」が存在して初めて申込みを受けることができるのだし、クラスが中止になるときは部署別申込みも含めてCASCADEされるので、「部署別申込み」の列を参照する。

(2) CONSTRAINT!

設問2
(1) 「ある期間の受講履歴を受講時の部署ごとに集計し」が実現できない。「受講履歴」と「受講申込み」を結合しても受講時の部署は分からない。

(2)
1・3 部署テーブルからレコードは削除しないので、「NO ACTION」が課されていても問題ない。
2 従業員が退職するときは、その従業員が行った「受講申込み」は取り消されても問題ない。
4 従業員が退職するときに、その従業員に「受講履歴」があると、「在職従業員」から削除することができない。従業員管理システムのルールに反する。

ss2004 * データベーススペシャリスト * 22:10 * comments(0) * trackbacks(0)

テクニカルエンジニア(データベース) H18 PM1-2

設問2
(1) 「第2正規形でない理由」だから、候補キーから非キー属性への部分関数従属を指摘する。従業員は、同じ日に2つの勤務コードを勤務することがあるので、シフト勤務表の主キーは{店舗番号, 従業員番号, 年月日, 勤務コード}である。非キー属性の{日休憩時間, 日労働時間}は、その日の合計の休憩時間、労働時間を表す属性だから、{店舗番号, 従業員番号, 年月日}に関数従属する。
(2) シフト勤務表から、部分関数従属を排除({店舗番号, 従業員番号, 年月日}に関数従属する属性を分離)する。

設問3
(1) 従業員の所属部門・雇用区分は変更があるが、その履歴が管理されていないため、更新前後のシフト調整に支障が生じる。
(2) 雇用契約年月日ごとに決まる属性と、その従業員に固有の属性でテーブルを分割する。
ss2004 * データベーススペシャリスト * 21:50 * comments(0) * trackbacks(0)
このページの先頭へ