HOME»データベーススペシャリスト掲示板»ひっかけ問題:第●正規形ですか?
投稿する

[0312] ひっかけ問題:第●正規形ですか?

 logres_Fanさん(No.1) 
DB ブロンズマイスター
問題:下記テーブルは、第●正規形ですか?
会社テーブル(主キー:会社ID)
{会社ID},会社名
0001,会社A
0002,会社B

社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名,年齢
0001,0001,太郎,20
0001,0002,花子,30
0002,0001,浩二,40
2022.08.15 13:50
 logres_Fanさん(No.2) 
DB ブロンズマイスター
この投稿は投稿者により削除されました。(2022.08.15 14:03)
2022.08.15 14:03
 logres_Fanさん(No.3) 
DB ブロンズマイスター
この投稿は投稿者により削除されました。(2022.08.15 14:50)
2022.08.15 14:50
あきさん(No.4) 
名前が決まると年齢も決まるのですか?知りませんでした( ̄▽ ̄;)
2022.08.15 14:19
 logres_Fanさん(No.5) 
DB ブロンズマイスター
この投稿は投稿者により削除されました。(2022.08.16 00:19)
2022.08.16 00:19
 logres_Fanさん(No.6) 
DB ブロンズマイスター
この投稿は投稿者により削除されました。(2022.08.15 14:46)
2022.08.15 14:46
 logres_Fanさん(No.7) 
DB ブロンズマイスター
あきさんの指摘を受けて訂正しました。
問題:下記は、第●正規形ですか?
会社テーブル(主キー:会社ID)
{会社ID},会社名
0001,会社A
0002,会社B

社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名,生年月日
0001,0001,太郎,2000/10/10
0001,0002,花子,2000/11/11
0002,0001,浩二,2000/12/12

解答:第2正規形。
  成立すべき関数従属性として、{社員名}→生年月日が残っているので、第3正規形は次のようになります。
  うっかり引っかからないように注意して下さい。

会社テーブル(主キー:会社ID)
{会社ID},会社名
0001,会社A
0002,会社B

社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名
0001,0001,太郎
0001,0002,花子
0002,0001,浩二

社員名テーブル(主キー:社員名)
{社員名},生年月日
太郎,2000/10/10
花子,2000/11/11
浩二,2000/12/12
2022.08.15 14:49
かかさん(No.8) 
同じ社員名の方は存在しない設定なのでしょうか?
2022.08.15 16:42
 logres_Fanさん(No.9) 
DB ブロンズマイスター
かかさん、回答ありがとうございます。
おっしゃる通り、同性同名の問題が次の課題ですね。
ただ、今回は、問題と回答、どちらの場合も、同性同名が問題として残るので、論点になるとは考えていません。
2022.08.15 16:57
あたまさん(No.10) 
第2正規形となるのは、社員名が決まれば生年月日が一意に決まる場合(将来的にも名前が被ることがない場合)ですので、問題文に明示されていないと第2正規形とは解答できないと思います。
他方、一般的には社員名(氏名)は重複することが大いにあり得るので、問題文に明示されていないことも含めて、解答としては第3正規形が解答になる認識です。
2022.08.15 18:05
 logres_Fanさん(No.11) 
DB ブロンズマイスター
あたまさん、ご指摘ありがとうございます。

  同性同名を認めないと明示されていなければ成立しない。また、現実的ではない。
  例えば、次のように同性同名の別人物を登録した場合、奇妙な外部参照になるから不成立。
  太郎が参照先で合体している!

問題:同性同名の別人物を4レコード追加
社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名,生年月日
0003,0001,太郎,2000/10/10
0003,0002,太郎,2000/10/10
0003,0003,太郎,1999/10/10
0004,0001,太郎,1999/10/10
解答
社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名
0003,0001,太郎←←←☆
0003,0002,太郎←←←☆
0003,0003,太郎←←←★
0004,0001,太郎←←←★
社員名テーブル(主キー:社員名)
{社員名},生年月日
太郎,2000/10/10→→→☆
太郎,1999/10/10→→→★
2022.08.15 23:02
あたまさん(No.12) 
解答の箇所ですが、
社員名テーブルについて社員名が主キーですので、太郎 がキー重複となり、どちらか1レコードしか登録できません。
2022.08.15 23:34
Jさん(No.13) 
問題文に同姓同名について明記されてないですし、
どっからどう見ても、第3正規形ですかね…
2022.08.16 00:02
 logres_Fanさん(No.14) 
DB ブロンズマイスター
この投稿は投稿者により削除されました。(2022.08.16 00:21)
2022.08.16 00:21
 logres_Fanさん(No.15) 
DB ブロンズマイスター
>No12
失礼しました。
あたまさん、ご指摘ありがとうございます。

  同性同名を認めないと明示されていなければ成立しない。また、現実的ではない。
  例えば、次のように同性同名の別人物を登録した場合、解答テーブルでは主キー制約違反になる。

問題:同性同名の別人物を4レコード追加
社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名,生年月日
0003,0001,太郎,2000/10/10
0003,0002,太郎,2000/10/10
0003,0003,太郎,1999/10/10
0004,0001,太郎,1999/10/10
解答
社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名
0003,0001,太郎←←←★
0003,0002,太郎←←←★
0003,0003,太郎←外部参照不成立
0004,0001,太郎←外部参照不成立
社員名テーブル(主キー:社員名)
{社員名},生年月日
太郎,2000/10/10→→→★
太郎,2000/10/10←主キー制約違反
太郎,1999/10/10←主キー制約違反
太郎,1999/10/10←主キー制約違反
2022.08.16 00:32
 logres_Fanさん(No.16) 
DB ブロンズマイスター
この投稿は投稿者により削除されました。(2022.08.16 00:49)
2022.08.16 00:49
 logres_Fanさん(No.17) 
DB ブロンズマイスター
>No10,No15

私の回答は此方になります。
解答
社員テーブル:{会社ID,社員ID},社員名
社員名テーブル:{社員名},生年月日

問題点:同性同名の別人物を扱えない。
社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名
0003,0001,太郎(●)←←←★
0003,0002,太郎(☆)←←←★
0003,0003,太郎(▲)←外部参照不成立
0004,0001,太郎(■)←外部参照不成立
社員名テーブル(主キー:社員名)
{社員名},生年月日
太郎,2000/10/10→→→★
太郎,2000/10/10←主キー制約違反
太郎,1999/10/10←主キー制約違反
太郎,1999/10/10←主キー制約違反

次の課題:同性同名の別人物に対応するにはどうすればいいか?

解答:同性同名の別人物を区別する属性項目を追加。
社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名,顔認識データ
0003,0001,太郎,●
0003,0002,太郎,☆
0003,0003,太郎,▲
0004,0001,太郎,■

社員名テーブル(複合主キー:社員名,顔認識データ)
{社員名,顔認識データ},生年月日
太郎,●,2000/10/10
太郎,☆,2000/10/10
太郎,▲,1999/10/10
太郎,■,1999/10/10
2022.08.16 00:54
 logres_Fanさん(No.18) 
DB ブロンズマイスター
この投稿は投稿者により削除されました。(2022.08.16 01:33)
2022.08.16 01:33
 logres_Fanさん(No.19) 
DB ブロンズマイスター
>No15

  同性同名問題という命題があり、問題のテーブルを解答のように正規化すると、主キー制約違反や外部参照不成立となる。
  しかし、本来外部参照出来る項目を外部参照せずに何度も入力するのは正規化違反。
  
>No17

  関数従属性に従って正規化するという命題があり、問題のテーブルを正規化。次に、同性同名問題という命題があり、主キー制約違反や外部参照不成立となるのであれば、属性項目を追加するなどして対応。

  正規化する段階に関数従属性以外の課題を持ち込むと正解出来ません。まず、関数従属性に従って正規化、次に課題があれば対応。これを心懸けておかないと苦労します。

>あたまさん(No.10)
>第2正規形となるのは、社員名が決まれば生年月日が一意に決まる場合(将来的にも名前が被ることがない場合)ですので

  将来的に名前が被った場合、社員名が決まっても生年月日は一意に決まらないという事でしょうか?

 問題:同性同名の別人物を4レコード追加。(記号)は本来ありません。
社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名,生年月日
0003,0001,太郎(●),2000/10/10
0003,0002,太郎(☆),2000/10/10
0003,0003,太郎(▲),1999/10/10
0004,0001,太郎(■),1999/10/10

  社員名が決まっても生年月日は一意に決まらない、例えば、次のような場合だと思うのですが。

社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名,生年月日
0003,0001,太郎(●),2000/10/10
0003,0002,太郎(☆),2000/10/10
0003,0003,太郎(▲),1999/10/10
0004,0001,太郎(■),1999/10/10
0004,0002,太郎(●),2000/10/19
2022.08.16 01:34
 logres_Fanさん(No.20) 
DB ブロンズマイスター
Jさん、回答ありがとうございます。
皆様、ミス投稿が多くてすみません。またミスがあればご指摘下さい。
文字化けのミスで中身が予想できる場合は、流して下さい。
2022.08.16 01:40
通りすがりさん(No.21) 
IPAの過去問ですか?
2022.08.16 06:59
あたまさん(No.22) 
>将来的に名前が被った場合、社員名が決まっても生年月日は一意に決まらないという事でしょうか?

というよりは、登録できないということになります。
もし社員名テーブルから物理削除した場合は、社員テーブルも併せて削除するなどを実施する必要がありますね。
結局のところ、やりたいことはできないと思います。
2022.08.16 07:48
 logres_Fanさん(No.23) 
DB ブロンズマイスター
あたまさん、回答ありがとうございます。
 >将来的に名前が被った場合、社員名が決まっても生年月日は一意に決まらないという事でしょうか?
>というよりは、登録できないということになります。
>もし社員名テーブルから物理削除した場合は、社員テーブルも併せて削除するなどを実施する必要がありますね。

  社員名が決まると生年月日は一意に決まるが、登録出来ない。理由が物理削除という回答でしょうか?
  物理削除する為に、関連テーブルも併せてパージするのは通常作業ですよね。社員名に限らず、会社名、商品名などでも同じ事が言えます。
2022.08.16 08:39
 logres_Fanさん(No.24) 
DB ブロンズマイスター
通りすがりさん、回答ありがとうございます。
IPAの過去問や解説本を全て把握しているわけではありません。
関数従属性と正規化において、受験生、合格生の一助になると考えています。
不適切と判断された場合、サイト下のお問い合わせから質問して下さい。
2022.08.16 08:59
あたまさん(No.25) 
>社員名が決まると生年月日は一意に決まるが、登録出来ない。理由が物理削除という回答でしょうか?

いえ、そもそも社員名(氏名)を主キーとしているのが良くないという解答です。

会社名や商品名は、会社コードや商品コードを主キーにしますよね。
名称が変われば、非キー属性ですので変更できます。
社員名が主キーだと安易に氏名を変更できません。

例えばですが、結婚などで名字が変わった場合は社員テーブルの社員名も一緒に更新する想定ですか?
そうであれば、テーブル設計から誤っていると思います。
2022.08.16 08:59
 logres_Fanさん(No.26) 
DB ブロンズマイスター
あたまさん、回答ありがとうございます。

>いえ、そもそも社員名(氏名)を主キーとしているのが良くないという解答です。

  ご指摘の通り、値が変化し得る自然キーを主キーとするのはNGです。ですので、正規化した後、名字変更などの課題に対応する為に、代理キーを導入する形で正規化を崩します。勿論、非正規形の段階から代理キーを導入しても構いません。
  しかし、受験生「代理キーがないから関数従属性と正規化を判断できない。」、合格生「自然キーだけでは関数従属性と正規化を判断できない。」と言われたら、勿体無いとコメントします。ID、No、番号、コードを排除して、自然キーだけで関数従属性や正規化を考えるのは極々自然な事です。問題設定としても特に支障はないと回答します。
  No19についてもご意見を教えて頂ければ嬉しいです。

>あたまさん(No.10)
>第2正規形となるのは、社員名が決まれば生年月日が一意に決まる場合(将来的にも名前が被ることがない場合)ですので
 >将来的に名前が被った場合、社員名が決まっても生年月日は一意に決まらないという事でしょうか?
 >問題:同性同名の別人物を4レコード追加。(記号)は本来ありません。
>社員テーブル(複合主キー:会社ID,社員ID)
>{会社ID,社員ID},社員名,生年月日
>0003,0001,太郎(●),2000/10/10
>0003,0002,太郎(☆),2000/10/10
>0003,0003,太郎(▲),1999/10/10
>0004,0001,太郎(■),1999/10/10

 >社員名が決まっても生年月日は一意に決まらない、例えば、次のような場合だと思うのですが。

>社員テーブル(複合主キー:会社ID,社員ID)
>{会社ID,社員ID},社員名,生年月日
>0003,0001,太郎(●),2000/10/10
>0003,0002,太郎(☆),2000/10/10
>0003,0003,太郎(▲),1999/10/10
>0004,0001,太郎(■),1999/10/10
>0004,0002,太郎(●),2000/10/19
2022.08.16 09:52
あたまさん(No.27) 
どんな解答を期待していらっしゃるのか良く分からなくなってきました。

No.19だと、
(社員名、顔認識データ)をユニーク制約にしないといけないですね。
顔認識データだけで社員が判断できるなら、社員名はキーとして不要ですね。
顔認識データの代わりに一意になるコードを持たせると全て上手くいきますね。

勿体無いとコメントされていますが、考えが常に後出しで正直やりたいことが伝わってきていません。
一番最初に書いている問題は、IPAが出題するのではなく、logres_Fanさんが「柔軟な発想で考えましょう」という意図の命題なのですね。

試験とは全く関係ないので、自由な発想はとても良いとは思いますが、膨らませ過ぎたら試験では減点されるか、時間切れで終わってしまいますよ…。

また関係従属性を考える際、ある程度一般常識が必要だと思います。
2022.08.16 12:24
通りすがりさん(No.28) 
logres_Fanさん
IPAの過去問でないことを予め書き添えていただけると助かります。
2022.08.16 12:31
初心者さん(No.29) 
なんだこれ?
2022.08.16 14:08
 logres_Fanさん(No.30) 
DB ブロンズマイスター
  あたまさん、回答ありがとうございます。
  社員名や生年月日を複数回入力する仕組み(問題のテーブル)ではなく外部参照の仕組み(解答のテーブル)に賛同頂きたかったのですが、失敗しました。おっしゃる通り、膨らませ過ぎ、かつ、問題文に前提条件をつけるなど諸々検討不足でした。
  通りすがりさん、初心者さん、回答ありがとうございます。
  ご尤もです。受験生の皆様、お騒がせしてすみませんでした。回答者の皆様、お付き合いいただきありがとうございました。
2022.08.16 20:54

返信投稿用フォーム

スパム防止のためにスレッド作成日から30日経過したスレッドへの書込みはできません。
© 2016-2024 データベーススペシャリストドットコム All Rights Reserved.

Pagetop