正規形についての質問
- 質問内容は、データベースの正規形についての疑問です。
- 具体的には、第二正規形に関して、関数従属関係についての疑問があります。
- また、第三正規形に関して、主キーと非候補キーの関数従属についても疑問があります。
- ベストアンサー
また正規形について。
http://www.techscore.com/tech/sql/16_02.html のURLの下の方の表 受注番号、商品番号、納入業者 12345 001 業者 A 12345 002 業者 B 12346 001 業者 A 12347 001 業者 D において、 ****以下引用**** このとき、非主キー列「納入業者」は「受注番号」と「商品番号」から決まりますので、(受注番号、商品番号) →納入業者は関数従属の関係が成立しています。よって、このテーブルは第二正規形の条件を満たしていると言えます。(中略) ****引用終わり**** とありますが、私には 商品番号→納入業者 という関数従属関係があるきがするのですが違うのでしょうか?なので第二正規形の時点で、 (商品番号、納入業者)という表が新たに分離される気がするのですが… さらに、 http://www.st.rim.or.jp/~ryoma/tips/seikika.htm のURLの同じくボイスコッド正規形で扱われ表、 商品コード、仕入先コード、担当者コード 000120001 111 401 000120001 112 402 000120002 111 401 000120002 150 403 仕入先コード、仕入先名 001 東京商店 002 大阪商会 003 名古屋流通 で、 *引用* 商品コード、仕入先コード、担当者コードを属性とする上の表は、繰り返し部分を持たず、また商品コード+仕入先コード、あるいは商品コード+担当者コードをキーとすることができ、かつ推移従属の関係が存在しないため、第三正規形です。 *終* とありますが、主キーを【商品コード、仕入先コード】と決めたとき、非候補キーである担当者コードは仕入先コードに関数従属している気が(私は)してしまうので第二正規形へ変形した時点で(仕入先コード、担当者コード)という表が分離されていると思うのですが。 以上の解釈で間違っている考えがあればご指摘ください。
- arcsin
- お礼率46% (194/417)
- MySQL
- 回答数1
- ありがとう数5
- みんなの回答 (1)
- 専門家の回答
質問者が選んだベストアンサー
最初の第二正規形の問題ですが、商品番号001の商品は、業者Aの場合(受注番号12345,12346)と業者D(受注番号12347)の場合が有るようですので、納入業者は商品番号のみでは特定できず、主キーである受注番号と商品番号の組合せによってのみ特定される(主キーに完全関数従属している)様です。 したがって、第二正規形の条件は満たしているかと。 2つ目のボイス・コッド正規形の問題ですが、 > 主キーを【商品コード、仕入先コード】と決めたとき、非候補キーである担当者コードは・・・ 主キーを決定しても、他の候補キーが候補キーでなくなる訳ではないので、{ 商品コード, 担当者コード }も主キーでなくとも候補キーではある訳です。 したがって、第二正規形で、【仕入先コード、担当者コード】という表が分離されている必要は有りません。 それから、【商品コード、仕入先コード、担当者コード】の表には、下記の2つの関数従属性が含まれていますが、一つ目の関数従属性は全ての項目に関係していますので、表を分割すると、この情報は失われることになります。 {商品コード, 担当者コード} → 仕入先コード 仕入先コード → 担当者コード この様にボイス・コッド正規形では、関数従属性が保存されない場合があります。
関連するQ&A
- ボイスコッド正規形
http://www.techscore.com/tech/sql/16_02.html を参考に勉強しているのですが、ここのサイトでの疑問点です。 ボイスコッド正規形の説明の一番最後のほうに、 --引用-- 受注番号を主キーとし、下のテーブルでは納入業者を主キーとします。それぞれ、受注番号→商品番号、納入業者→商品番号という完全関数従属関係が成立しています。これらのテーブルは、ボイスコッド正規形の条件を満たしています。 --引用終わり-- ココの点で、受注番号→商品番号の関数従属はなりたっているのでしょうか?? 12345は商品番号001,002の二つを指している気がするのですが。
- ベストアンサー
- MySQL
- 第3正規化とは何でしょうか
データベースの第三正規化がよく分かりません。 第二正規化との違いがよく分かりません。 第2→主キーの一部に従属する項目を分離 第3→主キーに従属しない項目を分離 という説明があったり (このテキストでは、主キーを常に複合キーとしているようであり、その複合キーの(2つとして)どちらかを主キーとする表をつくるのが2で、その複合キーのどちらとも関係しない列を主キーとする表を3としているようなのですが、そもそも主キーは複合キーとは限らないはずだと思うのですが・・) 別のテキストでは(ある基本情報技術者試験のテキスト) 第2→関数従属 第3→推移的関数従属 という説明があったりします(推移的関数従属というのをネットで調べてみましたが、その概念がここでどう当てはまるのか分かりません) このへん教えていただけませんでしょうか? あるいは、分かりやすくある程度体系的に教えているページや本があれば教えてください。
- 締切済み
- 情報処理技術者
- データベースの正規化について質問です><
データベースの正規化について質問です><教えて下さい。 伝票を正規化していく問題なのですが、 受注番号 受注日 得意先コード 得意先名 得意先住所 {商品コード 商品名 販売単価 受注数量 受注金額} {}は繰り返しを表します。 これをまず自分で第一正規化してみて//*は主キーを表す。 *受注番号 受注日 得意先コード 得意先名 得意先住所 *商品コード 商品名 販売単価 受注数量 受注金額 になり次に第二正規化してみて *受注番号 受注日 得意先コード 得意先名 得意先住所 *商品コード 商品名 販売単価 *受注番号 *商品コード 受注数量 受注金額 になり最後に第三正規化をして *受注番号 受注日 得意先コード *得意先コード 得意先名 得意先住所 *商品コード 商品名 *商品名 販売単価 //ココです。 *受注番号 *商品コード 受注数量 受注金額 となったのですが模範解答には//ココです。の部分がなく、*商品コード 商品名 販売単価 これのままで終わっていました。 自分が間違えているのでしょうか??もし間違えているなら理由を教えて下さい。長くてすいません
- ベストアンサー
- その他(データベース)
- 【データベース】 正規形を答える問題
正規形を答える問題で悩んでいます。 次のような問題です。 属性{A,B,C,D}をもつ表に対して、次の二つの従属性が見られる。 (1)A,B → C,D (2)C→B この表の正規形は何か。 第2正規形か第3正規形で迷っています。 第2正規形の条件を満たす理由は 候補キーは{A,B},{A,C}で どの候補キーも非キー属性に対して完全関数従属だからです。 その後、非キー属性が候補キーに対して推移的に関数従属していないかを考えたのですが、「おそらくしていない…」というくらいで第3正規形であると確証ができません。 確証ができない理由が一つあります。 実際の業務でこのテーブルをつくるときに、 {A,C}→D, C→Bを利用して、 ACD とCBの二つの表に分けると思うからです。 うまく分けられるってことは第2正規形だからかな…と考えてしまいます。 アドバイスいただけないでしょうか… よろしくお願いします。
- ベストアンサー
- 情報処理技術者
- 第4正規形について
何度も投稿してしまい申し訳ありません。 今回は第四正規形についてです。 http://www.st.rim.or.jp/~ryoma/tips/seikika.htm ここのサイトの(6)第四正規形の説明について、 正規化後の表が、 ------------------------ 商品コード、仕入先コード ------------------------ 000120001 111 ------------------------ 000120001 112 ------------------------ 000120002 111 ------------------------ 000120002 150 ------------------------ ---------------------- 商品コード、倉庫コード ---------------------- 000120001 1A ---------------------- 000120001 3B ---------------------- 000120002 3C ---------------------- 000120002 2A ---------------------- となっていますが、これでは結合したときに元の表に無い、 000120001 112 3B というタプルが生成されてしまうのではないでしょうか?なのでこれは第4正規化はできないのでは・・・
- ベストアンサー
- MySQL
- 正規化について
どなたか教えてください。 新入社員です。 現在研修中です。研修の課題なのですがわかりません。 内容は次のとおりです。 次の受注伝票を第三正規化までしましょう。 項目:受注番号、日付、顧客番号、顧客名、住所、業種コード、業種名、受注総金額、商品コード、商品名、単価、受注数量 なんとか週末までにできれば解説つきで解答していただける方お願いできますか? あるいは同じ項目の受注伝票の正規化を紹介しているサイトなどご存知の方教えてください。
- 締切済み
- その他(データベース)
- 第3正規形について
平成27年秋期の基本情報技術者試験の問27 関係“注文記録”の属性間(1)~(6)の関数従属性があり,それに基づいて第3正規形まで正規化を行って, “商品”,“顧客”,“注文”,“注文明細”の各関係に分解した。関係“注文明細”として, 適切なものはどれか。ここで,{ X ,Y } は,属性 X と Y の組みを表し, X → Y は,X が Y を関数的に決定することを表す。また,実線の下線は主キーを表す。 注文記録(注文番号,注文日,顧客番号,顧客名,商品番号,商品名, 数量,販売単価) 〔関数従属性〕 (1) 注文番号 → 注文日 (2) 注文番号 → 顧客番号 (3) 顧客番号 → 顧客日 (4) {注文番号,商品番号} → 数量 (5) {注文番号,商品番号} → 販売単価 (6) 商品番号 → 商品名 ア 注文明細(注文番号,数量,販売単価) イ 注文明細(注文番号,顧客番号,数量,販売単価) ウ 注文明細(注文番号,顧客番号,商品番号,顧客名,数量,販売単価) エ 注文明細(注文番号,商品番号,数量,販売単価) 答えはエです。自分なりの解釈してみました。 ア:注文番号からわかるのは(1)、(2)より、注文日と顧客番号である。数量も販売単価も注文番号と商品番号の2つないとわからないので誤答。 イ:アと同じ理由 ウ:よくわかりません。。。 エ:商品番号と顧客番号から分かるのは数量と販売単価だから エがどうして」答えになるのかまたア~ウはどうして違うのか。 わかりやすく教えてください。
- 締切済み
- 情報工学
- 第3正規化するかどうか
第3正規化ってどういう条件でやるものなのでしょうか? http://su10.sgu.ac.jp/~morita/Seminar/6thStudent/siohara/formalize.html 上記だと第3正規化でGenre_nameを分離していますが、 Genre_codeで定まる値が一つならGenre_codeをなくしてGenre_nameをCinemaに直接書いても大差ないように思えます。 (Genre_codeに従属している項目が複数だったらやるべきだと思いますが) 現在テーブルを作成しているのですが、 上記のようにコードをつけて分離しようと思えばできる項目が複数あり、 やるべきかやらざるべきかで悩んでおります。 基本的にやれるところはやった方がいいのでしょうか? (個人的にはテーブルが増えると管理が面倒なのでコードにするにしても、 参照するプログラム側で連想配列でも持たした方が楽かなと思っているのですが)
- ベストアンサー
- その他(データベース)
- DataBaseの主キーについて
今晩は、現在Databaseを勉強中です。 DataBaseの正規化について質問致します。 第2正規化、第3正規化のあとは、全てのキー列が主キーに対して完全従属、そして推移的関数従属でない表が出来ているはず なのですが、これを考えると、第3正規化後も何故主キーが2つ以上になることがあるのでしょうか。 あるフィールド(主キーの列)に対して他の列は完全従属で且つ、推移的従属であれば、主キーは1個しかないと考えられるのですが、 これについての疑問を色々と調べてみましたが納得のいく参考書等も見当たりません。 この内容について詳しい方がおられましたら是非教えて下さい、宜しくお願い致します。
- ベストアンサー
- その他(データベース)
- データ正規化について
【質問内容】 自分で途中までやったんですが、(2)の第2正規形からわからなくなったので、どなたかデータベースに詳しい人のアドバイスをいただけたらなと思います。あと、間違いがあればご指摘願います。 【問題内容】 (1) 職種歴表(非正規形)をバッカス表記法で記述。 (2) (1)についてデータ正規化を第3正規形まで行い、その過程をバッカス表記法で記述。 (4) 正規化後の各表について、基本キー(連結キーの場合,その表 記)、外部キーを示す。 (5) このデータベースのデータ定義をSQL - DDL で記述。 【職種歴表】 従業員番号 従業員名 入社年月日 部門コード 部門名 職種コード 職種名 経験年数 S880123 鈴木太郎 04/01/88 A01 開発1課 P01 初級プログラマ 2 P02 中級プログラマ 3 S01 初級SE 1 T910354 佐藤花子 04/01/91 B01 電算1課 O01 初級オペレータ 2 P01 初級プログラマ 1 S860555 高橋一雄 04/01/86 A02 開発2課 S01 初級SE 3 S02 中級SE 5 (2) 職種歴表 = 従業員番号 + 従業員名 + 入社年月日 + 部門コード + 部門名 + {職種コード + 職種名 + 経験年数} (3) 【第1正規形】 職種歴表A = 従業員番号 + 従業員名 + 入社年月日 + 部門コード + 部門名 職種歴表B = 従業員番号 + 職種コード + 職種名 +経験年数 【第2正規形】 職種歴表A = 従業員番号 + 従業員名 + 入社年月日 + 部門コード + 部門名 職種歴表B = 従業員番号 + 職種コード + 職種名 +経験年数 職種歴表B2 = 職種コード + 職種名
- 締切済み
- SQL Server
お礼
ありがとうございます。 1つ目についてなのですが、言われて見ればそうですね。ご指摘ありがとうございます。 2つ目については「主キー」を決めてしまえばその他のキーは自動的に非候補キーになると勘違いしていました^^;主キーと候補キーは違うのですね、一緒に考えていたのが原因でした。詳しいご解説ありがとうございます。