- 締切済み
データベースの正規化について
第4正規形、第5正規形についてさっぱりわかりません。明示的に多値従属がどうのこうの・・・はい～～～？？なんですか、これは・・・・・。 ボイスコッドまでは理解できたのですが、第4正規形、第5正規形だけはさっぱりです・・。 簡単にいうとこれらの正規形ってどういうことなんでしょうか。
- naruyos112
- お礼率0% (0/14)
- その他(データベース)
- 回答数2
- ありがとう数0
- みんなの回答 （2）
- 専門家の回答
みんなの回答
- alioth
- ベストアンサー率48% (13/27)
ひとくちでは説明できないので、次のページ等を参考にしてみてください。 http://www8.pekori.to/~zoma/kanki_t.html http://www.st.rim.or.jp/~ryoma/tips/seikika.htm
- O_cyan
- ベストアンサー率59% (745/1260)
>簡単にいうとこれらの正規形ってどういうことなんでしょうか データベース内のテーブルをそれ以上簡約できない形にすることを正規形と呼びこの正規形に簡約することを正規化と呼びます。 >第4正規形、第5正規形だけはさっぱりです キー１・フィールド１・フィールド２というテーブル１があるとして 第３正規形はキー１からフィールド１のデータにある値とフィールド２にある値が各フィールドが独立に決まります。(キー１→フィールド１とキー１→フィールド２) これを分解してテーブル２がキー１・フィールド１でテーブル３がキー１・フィールド２にするのが第４正規形。 フィールド１がフィールド２に影響を与えたり逆にフィールド２がフィールド１に影響を与えずキー１のみによって決まっているという状況でのみ自明でない多値従属となります。 分解が可能であることを結合従属性があると言って結合従属性のない関係までさらに分解するのが第５正規形です。
関連するQ&A
- 正規化について
テーブルの正規化には、第一正規形、第二正規形、第三正規形、ボイスコッド正規形、第四正規形、第五正規形のステップがありますが、それぞれのステップにおいて、どのような操作をしているのでしょうか？ 特に、ボイスコッド正規形、第四正規形、第五正規形がよくわからないです。 情報無損失結合分解はなんとなくわかるのですが、多値従属性、結合従属性などの意味がまったくわかりません。
- 締切済み
- その他(データベース)
- データベース情報無損失分解、第四正規形について
データベースの学習をしています。 以下の語を説明する文章がそれぞれどれかわかりません。 用語 (1)情報無損失分解 (2)第四正規形 (a)リレーションスキーマリレーション中の結合従属性(X1, X2, ...., Xn)が自明な結合従属性であるか、各XiがRのスーパーキーである場合に成り立つ (b)リレーションスキーマR中の多値従属性X→Yが自明な多値従属性であるか、XがRのスーパーキーである場合に成り立つ
- 締切済み
- 情報工学
- ボイスコッド正規形
http://www.techscore.com/tech/sql/16_02.html を参考に勉強しているのですが、ここのサイトでの疑問点です。 ボイスコッド正規形の説明の一番最後のほうに、 --引用-- 受注番号を主キーとし、下のテーブルでは納入業者を主キーとします。それぞれ、受注番号→商品番号、納入業者→商品番号という完全関数従属関係が成立しています。これらのテーブルは、ボイスコッド正規形の条件を満たしています。 --引用終わり-- ココの点で、受注番号→商品番号の関数従属はなりたっているのでしょうか？？ 12345は商品番号001,002の二つを指している気がするのですが。
- ベストアンサー
- MySQL
- 第4正規系を説明する文章は、どちらだと思いますか？
【データベース】第4正規系を説明する文章は、どちらだと思いますか？ a) リレーションスキーマR中の結合属性*(X1, X2, X3,...,Xn)が自明な結合従属性であるか各XiがRのスーパーキーである場合に成り立つ b) リレーションスキーマR中の多値従属性X→→Yが自明な多値従属性であるか、XがRのスーパーキーである場合に成り立つ
- 締切済み
- その他(データベース)
- ボイスコッド正規化
ボイスコッドを必要とする条件で 「自明でない関数従属性が成立する場合」がわからず困っております。 以下の表があります。 備品グループ 社員氏名 承認者 パソコン類 櫻井忠雄 山田課長 パソコン類 伊藤隆 佐藤課長 パソコン類 福永達也 山田課長 プロジェクタ類 櫻井忠雄 鈴木課長 <ルール> ・備品グループと社員ごとに承認者が決まっている。 ｛備品グループ、社員｝→承認者 ・承認者は一つのグループしか承認できない。 承認者→備品グループ とあるとき、挿入、削除、更新異状が発生することはわかったのですが 「承認者→備品グループという自明でない関数従属性が成立している。」 よって、「ボイスコッド正規化をする必要がある」とありました。 「承認者→備品グループ」は自明に思える（佐藤課長（ほかの課長も）は、パソコン類(承認するものは1つ)のみで、 プロジェクタ類の承認はしてないので自明だと思う）のですが この考えは間違っているのでしょうか？
- ベストアンサー
- 情報処理技術者
- 【データベース】 正規形を答える問題
正規形を答える問題で悩んでいます。 次のような問題です。 属性{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正規形だからかな…と考えてしまいます。 アドバイスいただけないでしょうか… よろしくお願いします。
- ベストアンサー
- 情報処理技術者
- また正規形について。
http://www.techscore.com/tech/sql/16_02.html のＵＲＬの下の方の表 受注番号、商品番号、納入業者 12345 001 業者 A 12345 002 業者 B 12346 001 業者 A 12347 001 業者 D において、 ****以下引用**** このとき、非主キー列「納入業者」は「受注番号」と「商品番号」から決まりますので、(受注番号、商品番号) →納入業者は関数従属の関係が成立しています。よって、このテーブルは第二正規形の条件を満たしていると言えます。（中略） ****引用終わり**** とありますが、私には 商品番号→納入業者 という関数従属関係があるきがするのですが違うのでしょうか？なので第二正規形の時点で、 （商品番号、納入業者）という表が新たに分離される気がするのですが… さらに、 http://www.st.rim.or.jp/~ryoma/tips/seikika.htm のＵＲＬの同じくボイスコッド正規形で扱われ表、 商品コード、仕入先コード、担当者コード 000120001 111 401 000120001 112 402 000120002 111 401 000120002 150 403 仕入先コード、仕入先名 001 東京商店 002 大阪商会 003 名古屋流通 で、 *引用* 商品コード、仕入先コード、担当者コードを属性とする上の表は、繰り返し部分を持たず、また商品コード＋仕入先コード、あるいは商品コード＋担当者コードをキーとすることができ、かつ推移従属の関係が存在しないため、第三正規形です。 *終* とありますが、主キーを【商品コード、仕入先コード】と決めたとき、非候補キーである担当者コードは仕入先コードに関数従属している気が（私は）してしまうので第二正規形へ変形した時点で（仕入先コード、担当者コード）という表が分離されていると思うのですが。 以上の解釈で間違っている考えがあればご指摘ください。
- ベストアンサー
- MySQL
- データベースでの質問です。
データベースの正規化で第一正規化、第二正規化、第三正規化 がありますが 「第一正規化」では、データの重複をなくす事をする 「第二正規化」では関数従属をおこないxの値が決まればyの値が決まるのと同じように あるキーが決まれば、他のキーも決まるようになること 「第三正規化」では関数従属をなくすと聞いたんですが、意味がわかりません 解釈としてはキー項目を２つ組み合わせてある項目を決めると解釈であってるでしょうか？？ 第一正規化と第二正規化はこの解釈でいいでしょうか？？ バカな質問ですいません データベースの正規化の理解に苦しんでいます 回答おねがいします。
- 締切済み
- その他(データベース)
- データベース設計
今まで、サンプルデータを元にselect文の使い方を主に勉強していたのですが、突然データベース設計のレポートを出題されました。 同時に、自分で設計したレポートで意味のあるいろいろなselect文を実行してみる。と言うのも課題なのですが、こちらは何とかなるとおもうのですが、設計がよく分かりません。 課題の内容は以下の通りです。 1.1 ER図 1.2 スキーマ定義とドメイン制約 1.3 想定表における関数従属性、多値従属性、結合従属性 1.4 想定表における候補キーの算出 1.5 想定表における第3正規形判定と分解 1.6 外部キーの説明 具体的にどのように設計していけばよいか、各項目でなにをしなければいけないのか等、参考になるコトを教えてください。 授業の配付資料を読み直してみたのですが、ER図やスキーマ・ドメインなど、出てきてないようです。
- 締切済み
- PostgreSQL
