1

複合主キーのリレーションの具体例を見ています。機能的な依存関係に基づいて、私はそれが1NFであることを知っています。 3NFに正規化しているうちに、私はまだ遭遇していない状況に遭遇しました。私はすべての部分的な依存関係と推移的な依存関係についての手順を踏んでいましたが、3NFに正規化する最後の手順では、主キーとそれに依存するすべての非プライム属性を含むリレーションを作成する必要があります。正規化の理論が必要です説明

私の具体的なケースでは、プライマリキーを持っていますが、フル機能の依存関係はありません。複合主キーのみを含む表を作成しますか?それとも、私は1つも作っていないのですか?

私は複合キーと主キーの混乱はありません。私の質問がその1つと異なると思う理由を知るために私のコメントを参照してください。

+0

しかし、私はこの物の大部分を学んでいるので、私は何かを誤解している可能性があります。 – Gary

+0

[通常のフォーム - 2番目と3番目の - 可能な複写は複合キーだけですか?非自明の依存?](http://stackoverflow.com/questions/27474203/normal-forms-2nd-vs-3rd-is-the-difference-just-composite-keys-non-trivial-d) – philipxy

+0

理解しています。私はその2つをゆるやかに話す。私はプライマリキーとコンポジットキーの違いを知っています – Gary

答えて

1

複合キーと他の属性で構成されている関係は完全に正当です。理論的に有効なだけでなく、現実世界でも起こります。

このような状況では、その関係は、単に複合キーによって識別されるものの存在をアサートしているだけです。また、データのユーザーはデータの存在をテストするために使用され、非キー属性との関連が一般的に使用されるのと同じ種類のルックアップではありません。

+0

ありがとうございました!これは私の質問にはっきりと答えています。私は本当にそれを感謝します – Gary

+0

私はそのような関係の別の用途を言及するのを忘れました。 3方向結合の中間関係として使用できます。 –

1

FD(機能的な依存関係)は、使用している "1NF"の様々な意味に関係なく1NFとは関係ありません。だから1NFについて何を言おうとしているのかははっきりしない。定義によるリレーションは、各タプルの各属性の値を持ちます。一部のために一部のなどの属性のようなタプルがCKS(候補キー)&のFDは適用されませんので、関係ない「値のリスト」のようなものとの関係のようなもの。特定のデータタイプ(because of some fuzzy application-dependent received wisdom about "atomicity", or in Codd's sense of having no relation-valued attributes)を持たない「1NFリレーション」を定義すると、満足度はFDがそのデータタイプのデザインを保持するかどうかに依存しません。 (さらに、そのような「非1NF」の非原子的な設計の「正規化された」「原子的に」与えられたバージョンがFDを満たす場合、元のものはの制約を有するが、はFDの制約ではない 。)

部分的でないFDはいっぱいです。 2NF & 3NFへの途中で重要な唯一の部分的なFDは、CK上の非プライム属性の部分的なFDです。これらがなくなると、あなたは2NFを持っています。 ( "すべての部分的な依存関係と推移的な依存関係の手順に従う"というのは、計画が2NFに分解されてから3NFに分解されるように思えます)2NFを必要とする3NFの定義には部分的な依存関係は言及されていません。また、3NFの定義と、3NFに関係を置くための一般的なアルゴリズムは、部分的な依存関係を利用しないだけです。

他の部分FDもあります。彼らはちょうど関係ない。特に、適切なスーパーキー上の属性のすべてのFDは部分的です。関係がどのような通常の形かを決定するための定義に従い、関係を通常の形にするためのアルゴリズムに従ってください。これはすべての定義とアルゴリズムに適用されます。 There is no point in worrying about every property you notice that it might be "bad".

PS最初に2NFに入れて関係を3NFに入れないでください。これは、元の3NFの分解が見つからないようにすることができます。 3NFのアルゴリズムを使用します。 (通常、3NFの場合は、やや強いEKNF(Elementary Key Normal Form)で分解を生成します)。

+0

私は同意しません。キーに機能的に依存しない値がテーブルに存在する場合、テーブルは1NFにありません。これは実生活では難しいことです。しかし、テーブルの主キーが単一の値ではなく値のリストを決定する状況に直面している多くの設計者がいます。たとえば、キーがstudentIdで、リストがコースのリストである場合、学生はサインアップされます。コースリストをカンマ区切りの値で1つの列に入れたい人もいます。これは実際には1NFの違反ですが、それはそのようには見えません。 –

+0

"FD"は専門用語であり、 "値のリストを決定する"と言ったときにそれを悪用している(つまり使用していない)。定義によるリレーションは、各タプルの各属性の値を持ちます。タプルのようなものの属性のようなもののための "値のリスト"を持つものは関係ではないので、CKとFDは適用されません。 「1NFリレーション」を「アトミック性」に関するあいまいな知恵のために特定のデータ型のないリレーションとして定義すると、満足度はFDがそのデータ型でデザインを保持するかどうかに依存しません。 (「1NF」を定義してください。)(私の編集された答えを見てください) – philipxy

+0

PS CKsは* FDs *の結果です。すべての関係にはCKがあります。 "機能的にキーに依存しないテーブルの値"は発生しません。とにかく、「キー」はFKと同様に*関係*に​​あるものです。あなたは関係ではないデザインを持っているかもしれないので( "1NF"のために選ぶ定義によって)、それは "1NF関係"ではなく、CK&FDが問題であるCK&FDではありませんでした。 *関係*。あなたは*関係*のようなことを含むCKやFDのようなものを考えているかもしれません。それは関係、CKやFDではありません。 – philipxy