最初の投稿はすでにいくつかのhabrazhiteliの屋根をすでに破り、特にカルマを揺さぶっていたので、SQLの観点から記事の翻訳を書くことにしました。 それは私にとって、そしておそらく、私だけでなく、役に立つかもしれません。 一般的に、子供の頃から、アルコールをはじめとするさまざまな手段を使って実践で土地論に取り組んできましたが、何かを勉強するのに時間を費やすのは無意味なようです。
唯一おかしいのは、SQLが言語として登場する前から、カットの下にあるこのすべてのゴミがCoddの心の中に生まれたということです。
2番目の正規形または2NFとは何ですか？ 3歳の子供が本当に理解したように...
まず、正規化が追求する目的のために理解します。 カットの下に個別の用語はありません...
最初の標準形式（1NF）に減らすことの目標は、SELECTクエリでデータをフェッチするときにWHERE句の使用を有効にすることです。 すべての列の値は同じ事前定義されたタイプであるため、互いに比較したり、定数と比較したりできます。
たとえば、テーブル 'Family'にVARCHAR型の列 'Kids'がある場合、2つの行 'Vasya'と 'Anya'を簡単に比較して、たとえば、>
フィールド「Children」の一部の行に「Vanya、Sasha」と示されている場合、子供の順序を明確に決定することはできません。 この状況では、「Vasya」と「Vanya、Sasha」の行を比較しても意味がありません。 最初は文字列であり、2番目はすでにリストであるためです。 「C」という文字ですべての子を検索するとします。
| 家族 | キッズ |
|---|
| イワノフス | ヴァシャ |
| ペトロフス | アーニャ |
| シドロフス | ヴァーニャ、サーシャ |
タイプリクエスト
SELECT Kids FROM Family WHERE kids LIKE '%'
LIKEはリストを解析し、値を抽出し、テンプレートと比較するための引数として扱うことができないため、この状況では正常に機能せず、Sashaは見つかりません。 この場合の「Vanya、Sasha」は、文字列のリストなどの非原子値です。 SQLにそのようなデータを処理する方法を教えるには、言語を拡張するか、モデルを1NFに簡素化する必要があります。 1NFへの分解は、複合値をアトミックに分割することにより実現されます。
| 家族 | キッズ |
|---|
| イワノフス | ヴァシャ |
| ペトロフス | アーニャ |
| シドロフス | ヴァニャ |
| シドロフス | サーシャ |
つまり、最初のNFは列値の構造を処理します。
2番目（および3番目、しかし今日ではない）のNFは、テーブルの列間のキーと依存関係を既に処理しています。 説明とともにその
目標をリストします。
- 2番目の標準形式にする主な目標は、データストレージの冗長性を取り除き、その結果、このデータの変更の異常（変更、挿入、削除の異常）を回避することです。
- 2NFでの正規化の2番目の目標は、データモデルを可能な限り個別のテーブルに分割し、元々提供されていなかった新しい方法でクエリで組み合わせて使用できるようにすることです。
- 必要に応じて、テーブルを変更する手間を最小限に抑えます。 テーブルの列間の依存関係が少ないほど、データモデルの変更時に必要な変更は少なくなります。
- ユーザーにとっての表の明瞭さ。 1つの大きなテーブルにすべてのデータを保持するよりも、データを複数の接続され論理的に分離されたラベルとして表示する方が簡単です。 読みやすく、知覚し、設計し、保守しやすいです。 最終的に、データモデルは、子供やプログラマが描くのが大好きな円、ブロック、線の形の黒板または紙から始まります。
たとえば、テーブルがあります
| ID | Cd_name | アーティスト |
|---|
| 10 | 6度の内部乱流 | ドリームシアター |
| 20 | メトロポリス、pt。 2：記憶からのシーン | ドリームシアター |
| 30 | 人形の達人 | ドリームシアター |
主キーは
IDです。 このスキームは2NFにあります。これは、キーに含まれていない
Artistカラムがキー全体によってのみ決定されるためです。
非キー列がキー全体でのみ定義され、その部分で定義できない場合、テーブルは2NFになります一般に、2NFの不一致の問題は、テーブルに複合キーがある場合にのみ発生します。 例のように、単純なキーを持つテーブルには常に2NFがあります。 指定されたテーブルは、そのような場合の単なる例です。なぜなら、その中の両方のキー（および
IDと自然キー
CD_name ）は単純であり、パーツがないためです。
2NFの不一致は表で考慮されます
| アーティスト | Cd_name | 追跡する | 歌詞 |
|---|
| ドリームシアター | 6度の内部乱流 | 誤解された | ペトルッチ |
| ドリームシアター | メトロポリス、pt。 2：記憶からのシーン | 序曲1928 | （楽器） |
| ドリームシアター | 人形の達人 | バッテリー | ノットフィールド |
| メタリカ | 人形の達人 | バッテリー | ノットフィールド |
| エンシフェラム | 復venの物語 | バッテリー | ノットフィールド |
1つの同じ曲を複数のディスクに含めることができ、理論的には、トリビュートなど、異なるグループの同じ名前の曲を含む同じ名前のアルバムが可能です。 したがって、キーは
{Artist、CD_name、Track}です。 この場合、単語の作者を示す
Lyrics列の値は、キーの一部である
{Artist、Track}列から一意に決定されます。 これは2NFの違反です。
この結果、
歌詞の列の値は、曲が属する各ディスクに対して冗長になります。 音楽の分野では、これらの値は変更されませんが、他のドメインドメインでは、このような冗長データの不注意な変更により、すべての値が更新されない場合にデータベースの一貫性のない状態が発生する可能性があります。 これは、変更の異常の例です。
もう1つの結果は、まだCDでリリースされていないが、ラジオで放送されているか、他のメディアでリリースされている曲は、指定されたデータスキームに適合しないことです。 したがって、CDでリリースされるまで、新しい曲をデータベースに追加することはできません。 これは、挿入異常の例です。
同様に、データベースからディスクを削除する場合、このモデルでは曲がCDに含まれていない場合、著者に関する情報を提示することができないため、このディスクのみに含まれるすべての曲の著者に関する情報を失うことを余儀なくされます。 たとえば、内乱流の6度ディスクを削除したいという願望は、ソングライターの誤解が失われることになり、これは許されません。 これは異常除去の例です。
このような異常を回避し、冗長性を削除するには、テーブルを分割する必要があります。つまり、その分解を2つに実行する必要があります。
| アーティスト | Cd_name | 追跡する |
|---|
| ドリームシアター | 6度の内部乱流 | 誤解された |
| ドリームシアター | メトロポリス、pt。 2：記憶からのシーン | 序曲1928 |
| ドリームシアター | 人形の達人 | バッテリー |
| メタリカ | 人形の達人 | バッテリー |
| エンシフェラム | 復venの物語 | バッテリー |
| アーティスト | 追跡する | 歌詞 |
|---|
| ドリームシアター | 誤解された | ペトルッチ |
| ドリームシアター | 序曲1928 | （楽器） |
| メタリカ | バッテリー | ノットフィールド |
クエリを構築するための実際のデータベースでは、外部キーを使用してテーブルを関連付けるなど、テーブル間にセマンティックな関係を導入する必要もありますが、この例では、これらのテーブルの意味が関連していることを理解するだけで十分です。
両方のテーブルには2NFがあり、1つ目はキーにすべての列が含まれているため、2つ目は
歌詞が
{Artist、Track}キーによって決定され、
Artist列または
Track列によって一意に決定されないためです。
私はおそらく倉庫について話すつもりはない、HTMLでタブレットを入力するのはうんざりだ:)
それだけです。
私は今、それが明確であったことを願っています、私は3NFに対処しに行きました！