第1正規形：明確な定義
第一正規形とは何かの決定版を手に入れようとしています。 すべて私が読んだものは少し異なるスピンを持っています。
日付のような多くの当局は、定義により関係は常に第一正規形であると言いますが、他の当局は要件のリストを与えます。つまり、1NFの要件は0から多くあります。
違いは、テーブルとリレーションの間の違いだと思います。テーブルは完全に混乱する可能性がありますが、リレーションシップは特定の制限に従います。したがって、リレーションがSQLでテーブルとして表されるという事実により、混乱が生じます。
SQLデータベースに関連するため、私は特に1NFに焦点を当てています。問題は、テーブルが最初の正規形であることを保証するために必要なプロパティは何ですか？
多くの当局は、表がrelationを表す場合、すでに1NFにあると示唆しています。これにより、1NFの定義が関係の定義に戻ります。
1NFのテーブルのいくつかのプロパティは次のとおりです。
- 列の順序は重要ではありません[1]
- 行の順序は重要ではありません
- すべての行は同じ長さです（つまり、行データは列ヘッダーと一致します）
- 重複する行はありません（これは代理主キーを使用して保証できますが、PK自体は必要ありません）
- 繰り返し列はありません
- 各列にはsingle値（アトミック）が含まれます
[1]技術的には属性は順序付けされていませんが、テーブルでは、行データは列ヘッダーと同じ順序である必要があります。ただし、実際の順序は重要ではありません。
オン複数のデータ：
atomicデータの概念は、アイテムをさらに分解することはできないということです。この概念は、技術的にすべてがad nauseumに分解できるが、問題のデータはにはできないという点で限定されています実際にはデータの使用方法に応じて、さらに細かく分割されます。
たとえば、通常、完全な住所または完全な名前はさらに分解する必要がありますが、名前や町の名前などのコンポーネントは、文字列として使用できるという事実にもかかわらず、おそらくこれ以上分解すべきではありません。
繰り返し列に関して、phone1、phone2などのnearly繰り返し列があるのは設計列としては不十分です。一般的に、繰り返しデータは、追加の関連テーブルの必要性を示しています。
依存関係
同じヘッダーに準拠していることを除いて、行間に関係があってはなりません。
列の間にも関係があってはなりませんが、それがより高い正規形の主題であると私は信じています。
問題は次のとおりです。1NFの定義には上記のどれくらいが含まれていますか？独立した行ビットもそれに含まれますか？
予備的
正規形（1971年の「データベースリレーショナルモデルのさらなる正規化」のプレゼンテーションから、これは最初の正規形として知られています）およびリレーショナルパラダイム自体の定義は、データベース管理の実践に強力な基盤を提供する科学論文で1970年に発表されました。つまり、 「大規模共有データバンクのデータのリレーショナルモデル」 （簡潔にするためのRM） Dr。EF Codd によって作成され、チューリング賞の受賞者であり、リレーショナルフレームワークに関してtheの権限を持っています。
はい、コッド博士のテキストについての説明、解釈、解説、逸脱、意見はたくさんありますが、私は個人的に元の情報源にこだわることを好みます。自分で結論を導き出すことができるように、自分で分析することを強くお勧めします。
私は確かにRMの全体を理解していませんが、RMについて理解していることは、その卓越性、ビジョン、意図、および範囲を評価することを可能にします。とにかく、その天才と優雅さ。その分野では、RMは独自の方法で時の試練に耐え、比類のないままです。
前述の不正確さを強調する行為は、「慈善用語を使用して」不公平です。かなりの距離から見ると、この独創的な資料にはいくつかの改良と拡張が必要でしたが、仕事はまさにその概念から非常に堅実でした（そして実際、コッド博士はすべてではないにしても、そのような改良と拡張を彼自身でほとんど作りました）。
私はこの例外的な情報源に対する私の理解を深めるために、RMを絶えず読み直しています（そして、私の再評価は、再読のたびに増え続けています）。目的は巨人の肩の上に立つことです。
リレーションとテーブル
リレーションはabstractリソースであるため、コッド博士はそれらを表形式で表すことを想定しました（最初は「配列表現」という用語を使用しましたが、その後「テーブル」または「r -table”）を使用すると、リレーショナルデータベース（RDB）のユーザー、設計者、および管理者は、より親しみやすい方法でconcreteの方法でアプローチできます。したがって、RDB実装のコンテキスト内では、テーブルが実際のリレーションを表す限り、リレーションの省略形としてテーブルを使用することが有効です。この機能は（明らかではありますが）非常に重要です。これは、テーブルが第1正規形（1NF）に準拠するリレーションを表すかどうかを評価する前に、リレーションを正確に表す必要があるためです。
RMには、テーブルが実際に関係を表すかどうかを判断するために必要な品質が当然含まれていますが、ここではそれらについて非公式で気取らない解釈を提供します（もう1つ、はい！）。
- 名前が必要です（データベース構造内の各特定の関係は、他の関係と区別する必要があります）。
- それぞれのrowsは、関係の正確な1つのTupleを表す必要があります。
- その行のorderはまったく重要ではありません。
- それぞれのcolumnsには、関係する関係の正確に1つのdomainの意味を表す名前が必要であり、その名前は残りの名前とは異なる必要がありますテーブルの列（列は一意に区別され、特有の意味を持つ必要があります。そうです。データベースモデラーとビジネスエキスパートが正確に重要度の各ドメインを定義する役割が最も重要です）
- その列のorderは重要ではありません。
- すべての行の列数は同じでなければなりません。
- 行を介して示されるタプルのすべてを一意に識別する少なくとも1つ列、または列の1つの組み合わせが必要です。このように、すべての行は異なる必要があります（そうです、これは少なくとも1つのKEYを宣言することの重要性を強調し、2つ以上のKEYがある場合、実用的な理由に基づいて1つをPRIMARYとして定義する必要がありますALTERNATEと見なされますが、決定する前は、各KEYはPRIMARYとしての定義の「候補」でした。
実際にリレーションを表すテーブルを持つことは、それがリレーショナルな種類の操作操作を受けたときに結果が再びリレーションを表すテーブルになるため、重要です。このように、上記のテーブルの動作は予測可能です。
原子ドメイン（列）
RMの最初のセクションでは、いくつかの概念を紹介するために、コッド博士が関係のサンプルをいくつか紹介しています。したがって、Atomic Domainの意味を理解するために、いくつかの適切な点を詳しく説明するRMからの次の抜粋から始めましょう。
これまで、単純なドメイン（要素がアトミック（非分解）値であるドメイン）で定義されている関係の例について説明してきました。非原子値は、リレーショナルフレームワーク内で議論できます。したがって、一部のドメインは要素として関係を持つ場合があります。これらの関係は、次に単純でないドメインなどで定義できます。
このようにして、前述の説明関係のそれぞれが適合の2種類のいずれかであると言うことができます種類Aまたは種類B：
種類Aは、すべてのタプル（行）に排他的にsimple値を含むドメイン（列）で構成される関係（テーブル）のみをグループ化します。 ）リレーション（テーブル）を値として含まない。これは、このコンテキストでは、値がatomicであることを意味します。これは、newリレーション（テーブル）に連続して分解できないためです。したがって、このクラスの関係はnormalizedの関係です。つまり、1NFに準拠しており、その形式が望ましいです。
種類Bは、関係をそれぞれのタプル（行）の値として保持する1つ以上のドメイン（列）を持ち、その値がnonatomicそれらは後で新しい関係（テーブル）に分解できるため、つまり分解可能です。したがって、この種の関係は正規化されていません。つまり、それらは1NFを侵害しており、望ましくない形式になっています。
正規化
コッド博士は、RMの正規化に関するセクションを次の段落で紹介します。
ドメインがすべて単純なリレーションは、ストレージ内で、上で説明した種類の2次元の列の均一な配列で表すことができます。 1つ以上の単純でないドメインとの関係には、さらに複雑なデータ構造が必要です。この理由（および以下で引用する他の理由）により、単純でないドメインを排除する可能性は調査する価値があるようです！実際、非常に単純な除去手順があり、これを正規化と呼びます。
それから彼は続けて示します：
正規化されていないリレーションのグループ（リレーションを値として含むドメインがあります。つまり、それらは非アトミックであり、つまり単純ではありません）
正規化されたリレーションのグループ（つまり、分解されたリレーションのグループ。つまり、リレーション値のドメインが、それらがアトミックであることを示す単純なものに分解されたもの）
そして、彼は正規化されていない関係から正規化された関係を取得するための手順を説明します。
この点で、彼が正規化演習を説明するために採用した関係と演習の説明自体は非常に明確であり、それらを自分で分析することをお勧めします（これにより、一部の読者が本文に取り組むようになることを願っています）.
彼は次のように指摘している。
正規化された種類のさらなる操作が可能です。これらについては、このホワイトペーパーでは説明しません。
そして、前述の操作、つまり2番目と3番目の正規形（2NFと3NF）は、実際には「データベースリレーショナルモデルのさらなる正規化」に詳述されており、前述のように、このペーパーのプレゼンテーション（およびその後の印刷と公開）の後です。 、オリジナル正規形は、最初の正規形として知られるようになりました。
開業医が観察できるように、正規化されていない関係（テーブル）があると（ほとんどの場合不要）convolutionがRDB実装に導入されます。
1NFを満たすリレーションは、非正規化リレーション（テーブル）に必要なものよりも複雑ではないデータサブ言語を使用して実装できる制約とデータ操作操作の定義を容易にします。コッド博士は次のように指摘しています。
上記のように、データのリレーショナルモデルを採用すると、適用された述語計算に基づいてユニバーサルデータサブ言語を開発できます。関係のコレクションが通常の形式である場合は、1次述語計算で十分です。そのような言語は、他のすべての提案されたデータ言語に言語的能力の基準を提供し、それ自体がさまざまなホスト言語（プログラミング、コマンド指向、または問題指向）に埋め込む（適切な構文修正を伴う）の強力な候補になります。 […]
[…]
データサブ言語の普遍性は、その記述能力（計算能力ではない）にあります。
困惑
私の見解では、（a）1NFとthe RM自体に関する前述の解釈や説明などの過剰により、（b）さらにredefine 1NFは、対応する各タプルの単一の値である限り、1NFとの関係準拠である値を保持するドメインとの関係があることを示します。
あなたの他のポイントについての私の見解
同じヘッダーに準拠していることを除いて、行間に関係があってはなりません。
そのステートメントの意図を正しく理解しているかどうかはわかりませんが、同じヘッダーに準拠することとは別に、リレーション（テーブル）の（タプル）行の間に接続が必要です関係（テーブル）が表すことになっている、特定のエンティティタイプ（関心のあるビジネスコンテキストの観点から定義）の特定の発生に関するアサーションである必要があります。
列の間にも関係があってはなりませんが、それがより高い正規形の主題であると私は信じています。
そのステートメントの意味を適切に解釈しているかどうかはわかりませんが、実際には、前の側面に対する私の回答に従って、mustのドメイン（列）の間に関係がある必要がありますrelational（relationalモデルおよび具体的なRDB実装の基本構造）である理由も、関係（テーブル）です。
例証するために、架空の関係（表）に関して
Salary (PersonNumber, EffectiveDate, Amount)
タプル（行）
Salary (x, y, z)
意味を伝えます
The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z
したがって、Salaryリレーション（テーブル）の各タプル（行）は、上記のアサーションの構造に適合している必要があり、その違いは関連するドメイン（列）の値の置き換えですが、存在する必要があります（a）すべてのSalaryドメイン（列）間の関係、および（b）各タプル（行）に関する対応するすべての値間の関係。そのような関係はそれが不可欠です。
より高い正規形（2NFおよび3NF）は、関係（テーブル）のドメイン（列）間の機能的な依存関係を取り除くのに役立ちますndesirable接続を回避するのに役立ちますドメイン間（列）、前述の望ましくない接続はpdate anomaliesの導入を許可します。 2NFと3NFはどちらも、特定のRDB実装における関係（テーブル）の構造の健全性をテストするのに役立ちます。
イラスト。一般的な米国の住所を含むテキスト文字列を取ります：
"123 Cornhusk Rd., South Succotash, NY 12345"
Cornhusk Roadのすべての居住者、South Succotashの町またはニューヨーク州の特定の居住者を検索するクエリを作成するのは、困難な作業です。特に、データに次の文字列がある場合：
"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"
これらはそれぞれ同じ実際の住所を指定します（「Succatash」のようなスペルミスの可能性も考慮されていません）が、それらを正常に比較するためのアルゴリズムを作成することは、この地球での最後の残りの年を専用にしたくないものです。
最初の通常のフォームを入力してください。それがどのように行われるかの詳細については触れません。ほとんどのデータベースで見られるような一般的な形式を検討してください：
create table Addresses(
...
Street varchar,
City int references Cities( ID ),
State char( 2 ) references States( ID ),
Zip int
...
);
これは完全な正規化ではありません。たとえば、StreetをさらにStreetNumとStreetNameに分割することもできますが、これは単純な図では十分であり、実際には、正規化プロセスが実際に行われる限りです。 Cornhusk Roadのすべての住民を見つけるという小さな問題はまだありますが、Streetで「Cornhusk」というサブストリングを検索したところ、どこかにCornhuskという名前の町があったとしても、少なくとも混乱は生じません。
デートらによって提供された定義の問題は、データの一部を調べてそのデータの意味を考慮できないことです。特に私が彼らを責めるのではなく、それはかなり難しい場合があります。
したがって、「文字列」を取得して「アドレス」に変換する必要があります。しかし、包括的な包括的なaddressの定義は、見た目ほど単純ではありません。特に、複数の国の住所で作業する場合。
まず、コンテキストを修正します。文脈がないと何も意味がありません。ここでのコンテキストはaddressです。そのコンテキスト内で、Street、Cityなどの特定の意味を持つデータの一部を確認できます。それぞれの意味を個別のフィールドに割り当てます。
難しいのは、データは、単語と同様に、人によって意味が異なる場合や、人によっては意味が分からない場合があります。それは、それ自体がすべてプロジェクトであり、かなりの協力的努力を必要とする場合があります。しかし、これは優れたデータベース設計において重要な要素です。
正規化のポイントは、異常データを削除するか、少なくとも最小化することです。上の表で、選択した州に存在しない町または郵便番号が入力されている可能性があるという事実を考慮してください。または、選択された町に実際には存在しない通りに入った。ああ、でも今は第2と第3の正規形になりつつあり、それは別のトピックです。
1NFは、特定のデータ構造や固定された一連のルールではなく、関係の数学的概念の紹介と考えてください。リレーションのような数学的構造は、さまざまな方法で表現できます。テーブルは、最も便利な方法の1つにすぎません。テーブルを使用する場合、それらが意図した関係を明確に表し、表に対する操作が表現された関係に関して論理的に健全であることを保証するための制限があります。
列と行の順序と重複が重要ではないと言う場合、これはすべての重要な情報がテーブルに値として記録され、クエリにアクセスでき、テーブルのプレゼンテーションにエンコードされないようにするためです。表での色の使用を明確に禁止している作家はほとんどいませんが、上記の制限の目的を理解すると、意味のあるプレゼンテーション色の使用を同様に除外して、重要な色の値を明示的に記録する必要があります。日付や他の作成者も、同じ理由で非表示の行識別子を廃止します。
原子性の概念は、すべての重要な構造が関係として表現されることを保証することです。これにより、allのデータの依存関係を分析して異常を防ぎ、意味のあるすべての構造に均一にアクセスできるようになります。リレーショナル操作に。複合値は無効ではありませんが、アンパックするにはドメイン固有の演算子が必要であり、これにより複雑さが増し、冗長性が導入される可能性があります。もちろん、実際には、いくつかの単純な複合型と関連する演算子が便利で、クエリのコンパクトさと表現力を高めるのに役立ちますが、これは理論と矛盾しません。
複数値の依存関係のような行の依存関係は1NFに違反しませんが、列間の依存関係のように、より高い正規形の対象になります。 phone1、phone2などのほぼ繰り返される列も、デザインは良くありませんが、1NFに違反していません。
定義と説明 WikiPediaから1NFについて、かなり良いと思います。 - ホアノロ
ウィキペディアの記事の1文を拡張する：
電話番号と見なされ、テキストはアトミックではありません
これにより、非常に混乱している理由がわかります。これが単なるテキストの塊である場合、それはアトミックです。しかし、それが電話番号として見られる場合、それはアトミックではありません。日付などはこの問題を回避しています。データの意味と関係があります。主題を分析するときは、データの意味に取り組む必要があります。
それをさらに分解するポイントがあるかどうかは、第1正規形が満たされているかどうかの問題に関連しています。 1NFの背後にあるポイントは、すべてのデータへのキー付きアクセスを提供することです。ただし、キー付きアクセスを介して取得するものに部分構造がある場合、部分構造へのキー付きアクセスはありません。 - ウォルター・ミッティー
"1NF"は、さまざまなものの束を意味するために使用されます。その多くは、同時に無意味で一般的です。リンクを含めて 「データベース管理システムの正規化」に対する私の回答 を参照してください。それらの1つは 「dbmsの原子性とは」に対する私の答え です。 （両方ともスタックオーバーフローです。）- philipxy
コミュニティWiki 質問に残されたコメントから作成された回答