<< 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 PM2-2 | main | テクニカルエンジニア(データベース) H19 PM1-2 解いてみた >>

テクニカルエンジニア(データベース) H19 PM1-1 解いてみた

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

設問1
(1) 関数従属図
2007年4月21日11:00 修正。関数従属が既約でなかったので、冗長な関数従属を削除。
・{車台番号, 査定日} → {販売開始日, 販売終了日}
・{車台番号, 販売開始日} → {販売終了日, 査定日}
・{車台番号, 販売終了日} → {査定日, 販売開始日}
の関数従属は維持。
(2)
(誤っている関数従属性) 〔2〕
(理由) 担当者は、別の販売店の担当を兼務することがあるから。

設問2
(1) {車台番号, 販売開始日}
(2) 第3正規形

  • 関係「販売車」には、繰り返し属性がなく、全属性がスカラ属性である。
  • 関係「販売車」には、候補キーから非キー属性への部分関数従属がない。
  • 関係「販売車」には、候補キーから非キー属性への推移関数従属がない。

設問3
(1) 査定を行うごとに、年式、モデル等の情報を重複して登録する必要があり、冗長である。
(2)

  • 査定車(車台番号, 査定日, 販売店番号, 走行距離, 主要装備, 登録番号, 車検, 車体色)
  • 車台(車台番号, モデル, 年式, 車名, 新車価格, 製造元, 排気量)

設問4
(1) {車台番号, 販売日}, {車台番号, 査定日}, {車台番号, 買取日}
(2)
a 分割されている
b タプルが現れる
c {車台番号, 販売日} → {買取日, 査定日}
(3) 買取日, 査定日

【感想】
めちゃくちゃ難しいとは思わないが、時間はかかる。
設問1は、図3から取り組むのでなく、図1の「査定車」「販売車」を見て取り組む方が攻略しやすいと思われる。
ss2004 * テクニカルエンジニア(データベース) * 19:53 * comments(11) * trackbacks(0)

コメント

設問1(2)
関数従属性の矢印は、
関係“査定者”の属性同士の関数従属、
関係“販売車”の属性同士の関数従属のみではないでしょうか。

設問2(2)根拠を3つ挙げさせる問題
私自身、あまりの愚かさに笑いがとまりませんw

設問4は情報無損失分解の問題ですかね。
設問4(3)ですが、
関係“買取”に査定日を保持しているので
関係“売約”には査定日のみを保持すれば
{車台番号、販売日} → {査定日}の関係は維持され、
{車台番号、販売日} → {買取日}の関係も間接的に維持
されるかと思いました。勘違いでしたらごめんなさい。



Comment by Miny @ 2007/04/18 12:52 AM
設問1(2)
図4を見る限り、関係を超えての関数従属の矢印も引かれてますので良いのでは?
関数従属を関係内に限定する理由はないと思います。
>図1の「査定車」「販売車」を見て取り組む方が攻略しやすい
と書きましたが、当然、図3上で追加した関数従属もあります。

設問4(3)
私も同様に査定日、買取日のどちらかを追加すれば良いと思いましたが、一つだけ追加するのは不合理だと直感的に思い、両方を追加することとしました。なので、深い意味はありません。
冷静に考えれば、より時期が近い「買取日」を持つのが妥当かもしれません。

【追加】
設問3は、モデル(モデル, 車名, 新車価格, 製造元, 排気量)を分割する方が、更新時異状の例がすっきりするかもしれません(「査定日が決まらないとモデル、年式等が登録できない」のは、「商談が成立してから登録」する今回のビジネスルールでは問題とならないため)。
いずれにしても、更新時異状を指摘させ、分割させたにもかかわらず第3正規形にならないのは、どうにも気持ちが悪いです。
Comment by ss2004 @ 2007/04/18 1:34 AM
レスありがとうございます。

設問1(2)
>図4を見る限り、関係を超えての関数従属の矢印も引かれてますので良いのでは?
買取顧客番号→{氏名、顧客住所、顧客電話番号}
販売顧客番号→{氏名、顧客住所、顧客電話番号}でしょうか。関係を超えていると言えますね。

設問3
先ほど指摘しませんでしたが、私も
モデル(モデル, 車名, 新車価格, 製造元, 排気量)で分割しました。
>いずれにしても、更新時異状を指摘させ、分割させたにもかかわらず第3正規形にならないのは、どうにも気持ちが悪いです。

このモヤモヤ感、何となく昔の過去問を解いてるような感覚をおぼえます。

設問4(3)
実務では「査定日、買取日」を両方持つ方が
やさしい設計のような気がしますね。
アイテック・TAC解答例が気になります。
Comment by Miny @ 2007/04/18 2:22 AM
設問3
冷静に考えると、JITECの想定している答えは、モデルを分割することのような気がします。
私の解答でも必ずしも間違いとはいえないと思いますが、バツかも知れません。

もう少し、問題を精査して欲しいと思います。
Comment by ss2004 @ 2007/04/18 6:10 PM
設問3
[中古車販売情報の関係スキーマ]に
「車種ごとの新車価格などの車情報を事前に収集し」とあり
設問に「車情報の登録に際して不都合が生じる」とあります。車情報には、年式も含まれると思います。
よく分からなくなったので改めて関係スキーマをまとめてみました。

回答案
車情報(車台番号、年式、モデル、車名、製造元、新車価格、排気量)
査定車(車台番号、査定日、販売店番号、登録番号、車検、車体色、走行距離、主要装備)

・車情報が明確に分離できている。
・車一台ごとに車情報が管理できる。
・モデル情報も管理できる。
・車情報の登録時に制約機能を使ってモデル情報の整合性を監視することは可能。
・一度登録したモデル情報は変更されることはない。

回答案
モデル(モデル、車名、製造元、新車価格、排気量)
査定車(車台番号、査定日、販売店番号、登録番号、車検、車体色、走行距離、主要装備、年式、モデル)

・車情報が明確に分離できていない。
・車一台ごとの車情報が管理できていない。
・年式に登録ミスが生じる可能性がある。

以上から、回答案(ss2004さんの回答、アイテック解答例)が妥当だと思いますが、あとはjitecの解答を待つことにします。
本当にどうもありがとうございます。
Comment by Miny @ 2007/04/19 2:23 AM
「車情報の登録に際して不都合が生じる」と設問にありますが、この車を個体と考えるのはどうかと思います。

車台番号で分割して防げる更新異状は、「まさにその車を再度査定することになった場合(つまり、誰かが一度買いさらに中古車として出された場合)に重複して登録しなければならない」です。恩恵を受けるのは非常に稀です。

モデルで分割して防げる更新異状は、「そのモデルの車を再度査定することになった場合、重複して登録しなければならない」です。こちらは、結構あると思います。人気のモデルなら事前に登録しておくこともできると思います。

したがって、Minyさんの解答の方が正しいと思います。

P.S. アイテック、解答例が出たのですね。
Comment by ss2004 @ 2007/04/19 7:02 AM
アイテックの解答例、リレーションシップの弾き方がおかしいと思う。
・親会員と会員の間にリレーションシップを引いているが、これでは循環を防げない。
・顧客と会員の間にリレーションシップを引いているが、顧客と親会員の間にもリレーションシップを引いているので冗長。顧客と子会員の間に直接リレーションシップが引かれることはないので、顧客−親会員だけでよい。
Comment by ss2004 @ 2007/04/19 7:33 AM
設問1(1)の解答を図にしました。
Comment by ss2004 @ 2007/04/20 7:51 AM
ありがとうございます。
秋に向けてAN受験予告でしょうか。>RECOMMEND
Comment by Miny @ 2007/04/21 12:49 AM
関数従属図、修正しました。
シスアナを受験はします。
Comment by ss2004 @ 2007/04/21 11:12 AM
上の方のコメントで、
>関数従属を関係内に限定する理由はないと思います。
と書きましたが、訂正します。

関数従属は関係内に限定されます。
関数従属を断ち切るように関係を分割してはいけないので、関係が正しいものとして与えられている以上、関係スキーマから関数従属を考える場合には、関係をまたがる関数従属を考えてはいけません。
Comment by ss2004 @ 2007/04/21 10:40 PM
コメントする









トラックバック

このページの先頭へ