web-dev-qa-db-ja.com

データベースの正規化

私の結果が正しいかどうかを理解するのを手伝ってくれる人が誰かに教えてくれれば、感謝します。次の表があるとします。

BOOK (BookTitle, AuthorName, BookType, ListPrice, AuthorAffil, Publisher)

AuthorAffilは著者の所属を示します。次の機能的な依存関係が存在するとします。

{BookTitle} -> {Publisher, BookType} 
{BookType} -> {ListPrice} 
{AuthorName} -> {AuthorAffil}

この表が1NF、2NF、または3NFのいずれであるかを尋ねられます。

2行のデータに繰り返し情報が含まれていないため、このテーブルは1NFであると思います。

これが2NFの場合、次のようになります。

R1 = {BookTitle} -> {Publisher, BookType, ListPrice} 
R2 = {AuthorName} -> {AuthorAffil} 
R3 = {AuthorName, BookTitle} -> {extras}

この概念を理解しているのか、間違いがあるのか​​を教えてください。どんな種類のヘルプも歓迎します。

normalizationdenormalization
4
user1404664

第1正規形と第2正規形を明確に扱いましょう。

第1正規形（1NF）

2つの行に繰り返し情報が含まれていないため、テーブルが1NFにあるかどうかはわかりません。情報を繰り返すことで、[〜＃〜] book [〜＃〜]は次のように見えないと考えているかもしれません：

BOOK { BookTitle, AuthorName1, AuthorName2, AuthorName3, BookType, ListPrice, AuthorAffil, BookPublisher  }

これは本当に1NFの定義ではありません。代わりに、[〜＃〜] book [〜＃〜]は、すべての行の各列が任意のタイプの単一の値を持つ場合にのみ1NFになります。どれほど恣意的に複雑であっても、それはその列に対して定義されます。複数のAuthorNames列を追加することは悪い設計になる可能性がありますが、それぞれに単一の作成者の名前が含まれているため、1NFに違反しません。 wouldが1NFに違反するのは、AuthorNames列があり、定義されている場合です。著者名のコンマ区切りリストが含まれます。その場合、私たちは絶対に[〜＃〜] book [〜＃〜]が1NFにないことを知っています。

variableが1NFになるように設計することも可能です。ただし、AuthorName列ですが、ユーザーは作成者のコンマ区切りリストを入力し始めます。結果のテーブルは、意図したものの、1NFではnotになります。これらの両方の場合で、テーブルはrelationalテーブルでさえありません。これは、リレーションのプロパティを取得するために必要な専門分野に従っていないためです。

第2に、[〜＃〜] book [〜＃〜]は、少なくとも1つの候補キーが存在しないと1NFである、またはそうではありません。今すぐ述べたように、[〜＃〜] book [〜＃〜]には候補キーがないため、すべてに同じ値を入力できます2行以上の列。これにより、行が重複し、行が重複するテーブルはリレーショナルテーブルではなくなります。

第2正規形（2NF）

[〜＃〜] book [〜＃〜]の分解の試みを見ると、BookTitle、AuthorNameが想定されていました。この仮定が正しかったとしても、元のテーブルが現在2NFであると言うのは正しくありません。代わりに、分解の結果として得られた3つのテーブルのそれぞれを、機能の依存関係に関して評価する必要があります。 R2は5NFにあります。これは、単一の非キー列がキーに完全に依存して機能し、そのキーが唯一の候補キーであり、単一列であるためです。 R3は5NFにあります。これは、唯一の非キー列（想定される「エクストラ」）も機能的に単一の候補キーに完全に依存しており、追加の候補キー。 R1だけが2NFになりましたが、非キー列ListPrice、これは別の非キー列BookTypeに機能的に依存しているため、推移的な依存関係を形成します。

BookTitle、AuthorNameの単一の候補キーの仮定も、正しいこと！おそらく、この特定の本の世界では、興味のあるすべての本には1人の著者しかいません。その場合、R3の作成は、実際の機能の依存関係に関して正しくありません。したがって、all候補キーとallを明確にすることが重要です依存関係、結合依存関係、および多値依存関係。主題の専門家と一緒に、決してそれらを想定しないでください。そうしないと、間違った設計になります。本ごとに1人しか存在できないときに本ごとに多くの著者がいると仮定すると、R3になり、のFDが可能になりますBookTitle->AuthorName違反する。書籍ごとに1人の著者がいると仮定すると、実際には書籍ごとに多くの結果が存在する可能性があります[〜＃〜] book [〜＃〜]ユーザーは、必要な数ではなく1つの著者名のスペースしかなく、唯一の選択肢は著者名のsetsを入力することです。コンマやパイプのようなもので区切られます。

参考文献

Fabian Pascalの Practical Database Foundation Series およびCJ Dateの コンピュータプロフェッショナルのためのリレーショナル理論 は、テーブルをリレーショナルにするための優れたリファレンスですテーブルと正規化の基礎。これらの情報源から、この回答のすべての情報が導き出されました。

2
Todd Everett

キーを定義する

最初のステップは、キーを定義することです。同じタイトルの2つの本が存在できないとすると、キーはBookTitleです。

正規化

1NF本の著者が1人いるとすると、Relationは1NFであると考えることができます。たとえばありません

           BookTitle                               AuthorName
Data Structures & Other Objects Using C++     Michael Main, Walter J. Savitch

しかし私たちは

     BookTitle                                    AuthorName
Java: A Beginner's Guide                           Herbert Schildt

「Authorsnames」やその他のものではなく「AuthorName」があるので、それを考えることができます。

2NF {BookTitle}がキーである場合、関係は確実に2NFである1つの属性のみで構成されるキーとのすべての関係

NFすべての推移的な機能依存を考慮する必要があります。

彼らです：

{BookType} --> {ListPrice} 
{AuthorName} --> {AuthorAffil}

したがって、3NF正規化は次のとおりです。

 Books {BookTitle (key), AuthorName (fk: Authors), Booktype (fk:BookTypes),Publisher)
 Authors {AuthorName (key), AuthorAffil}
 BookTypes {BookType (key), ListPrice}

ここで、fkは別のテーブルへの外部キーを意味します

1
EagleOne