<< October 2019 | 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 >>

データベーススペシャリスト 午後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)

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

設問1
図3に「主な」関数従属性とあるが、解答に当たって補わなければならない関数従属はない。

設問2
オブジェクト指向モデルとやらを知らなくても解ける。
ss2004 * データベーススペシャリスト * 12:31 * comments(0) * trackbacks(0)

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

帳票からのボトムアップとスーパータイプ・サブタイプ化がテーマ。

「機材を大別すると“機械”と“資材”があり、」から「機材」がスーパータイプ、「機械」・「資材」がサブタイプになると予想。図11にあてはまる。

<マスタ系>
図1を機材コード=712301のインスタンスに着目して正規化し、「号機」と「機械」を得る。
「機械」と図2の「資材」を比較して、共通部分をスーパータイプ化して「機材」とする。

<予約業務>
図3がほぼそのまま「機械貸出予約」になる。

<貸出業務>
図4を正規化し、「貸出」と「貸出明細」を得る。さらに、「機材」と「機械」・「資材」のスーパータイプ・サブタイプに倣い、「機械貸出明細」・「資材貸出明細」のサブタイプを作成。
機械を貸し出す場合には予約が必ず先行するので、「機械貸出明細」には「予約番号」は持つし、リレーションシップが引ける。ただし、「予約と違う号機を貸し出す」場合があるので、「貸出機番」を持ち、直接「号機」との間のリレーションシップを引く。

<返却業務>
図5を正規化し、「返却」と「返却明細」を得る。さらに、「機械返却明細」と「資材返却明細」を追加。

<移動業務>
図6から「機械移動」、図7から「資材移動」を得、2つのスーパータイプとして「移動」を得る。

<在庫管理系>
図8から、「号機」に属性「現在保管営業所コード」・「現在貸出中顧客コード」を追加。
図9から、連関エンティティ「営業所資材在庫」を得る。
図10から、連関エンティティ「顧客使用資材」を得る。
ss2004 * データベーススペシャリスト * 12:08 * comments(0) * trackbacks(0)

テクニカルエンジニア(データベース) H17 PM2-1 設問3

(1) 点検の結果は、「正常」「異常」「未完了」の3つの状態が考えられる。駐車場設備単位で点検終了が確認できるので、点検が終了しているのに「異常」の記録がなければ、正常であったと判断できる。

(2) 部位装置点検項目の開始年月日と、点検項目の開始年月日では意味が異なる。リレーションシップを張ることができない。

(3) (2)のとおり、開始年月日では支障があるので、点検項目に新たなレコードを追加し、点検項目番号で管理する。

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

テクニカルエンジニア(データベース) H17 PM2-1 設問2

(1) 現に「出動指示番号」をもつテーブルについて検討する。
 「駐車場設備点検」・「部位装置点検結果」・「検出異常」・「駐車場設備修理」・「交換部品明細」は、出動指示がない出動の場合でも発生しうるので、「出動指示」からでなく「出動」からリレーションシップを引くべきである。

(3)
要件番号1は、以下のSQLで実行可能。
SELECT 出動目的番号, COUNT(*)
 FROM 出動内訳 JOIN 出動 USING(出動番号)
 WHERE 出動年月日 BETWEEN 集計始期 AND 集計終期
 GROUP BY 出動目的番号
 ORDER BY 出動目的番号


同様に、要件番号4も実行可能。
SELECT COUNT(*)
 FROM 出動
  JOIN 駐車場設備修理 USING(出動番号)
  JOIN 出動内訳 USING(出動番号)
 WHERE 出動年月日 BETWEEN 集計始期 AND 集計終期
  AND 出動目的番号 = '04'


要件番号2 部位装置別の修理実績は把握でき、どの出動によるかも把握できるが、出動目的は一つの出動に対して複数設定できるため、どの出動目的による修理実績かは集計できない。

要件番号3 修理作業時間は把握できるが、翌日までにわたったかは分からない。
ss2004 * データベーススペシャリスト * 13:34 * comments(0) * trackbacks(0)

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

(1) aとc・dのスーパータイプ・サブタイプ関係に着目。aが「部品」、c・dが「基本部品」・「汎用部品」になるだろうと予想。
「部位装置汎用部品明細」と関連があるので、dは「汎用部品」に。また、「部位装置汎用部品明細」は「汎用部品」と「部位装置」の連関エンティティだからbは「部位装置」

(2) 「契約」は、緊急呼出し料金プラン、修理工賃料金プラン、修理部品費料金プランについて「料金プラン」と関連があるので、「料金プラン」から「契約」に3本矢線が引ける。
「契約明細」は「契約」の明細なので、「契約」→「契約明細」。また、「駐車場設備」と「個別サービスの」連関エンティティなので、「駐車場設備」→「契約明細」←「個別サービス」。
ss2004 * データベーススペシャリスト * 13:11 * comments(0) * trackbacks(0)
このページの先頭へ