まえがき
関係 （テーブル）の正規化は 、リレーショナルデータベースの理論の基本的な部分の1つです。 正規化の目的は、関係の冗長性を取り除き、その構造を変更して、関係を処理するプロセスにさまざまな無関係な問題が生じないようにすることです。 このアプローチが無視されると、設計効率が急速に低下し、他の同様の自由とともに、重大な結果につながる可能性があります。
アクティビティの性質上、リレーショナルデータベースの設計に何らかの形で関係している専門家であれば、関係を理解し、正規化することができます。 この投稿では、さまざまな理由でこのトピックをまだマスターしていないHabrahabrの読者に、この知識のギャップを簡単に埋める機会を与えることを目的として、通常の形式に捧げられた小さなシリーズの出版物を始めたいと思います。
このアプローチは、正規化の原則を詳細かつ正確に提示することを目的としていません。これは、このアプローチでの公開に大量の情報が必要なため、ブログのフレームワーク内では明らかに不可能だからです。 さらに、この目的のために、優秀な専門家によって書かれた大量の文献があります。 私の意見では、私の仕事は基本的な原則を一般的な方法で実証し説明することです。
使用される用語
属性は、あるエンティティのプロパティです。 多くの場合、テーブルフィールドと呼ばれます。
属性ドメインは、属性が取ることができる有効な値のセットです。
タプルは、特定のエンティティ（テーブル行）を一緒に記述する相互接続された有効な属性値の有限セットです。
リレーションは、タプル（テーブル）の有限セットです。
関係スキームは、エンティティを定義する属性の有限セットです。 言い換えると、これは特定のフィールドセットで構成されるテーブルの構造です。
投影 -いくつかの属性を削除および（または）再配置することにより、特定の関係から取得された関係。
属性（属性セット）XとYの間の機能的な関係は、この点で有効なタプルのセットに対して、2つのタプルがXの値で一致する場合、Yの値で一致することを意味します。たとえば、「Company name」属性の値がCanonical Ltd 、そのようなタプルの「Headquarters」属性の値は、常に英国ロンドンのミルバンクタワーになります。 指定：{X}-> {Y}。
最初の標準形
リレーションは、すべての属性がアトミックである場合、つまり、説明されたエンティティの他のプロパティに対応するより単純な属性に分割できない場合、最初の標準形式 （1NFと省略）になります。
初期リレーションをメイン、非アトミック属性の値を従属と呼びます。
属性が非アトミックである初期関係を正規化するには、主関係と従属関係のスキームを組み合わせる必要があります。 さらに、たとえば、異常なリレーションに対応するテーブルがすでにデータベースに含まれており、情報で満たされている場合、非原子属性の値に複数のタプルが含まれることがあるため、タスクは複雑になります。
例で明確にする必要があります。 「従業員コード」、「名前」、「役職」、「プロジェクト」という属性を持つ関係を考えてみましょう。 明らかに、1人の従業員が複数のプロジェクトに取り組むことができます。 プロジェクトが識別子、名前、完了日で記述されているとします。
| 従業員コード | 氏名 | 役職 | プロジェクト |
| 1 | イワノフイワンイワノビッチ | プログラマー | ID：123; 名前：蒸気ボイラー制御システム; 完了日：2011年9月30日
ID：231; 名前：室内のさまざまなガスの過剰MPCを監視および警告するための変電所。 完了日：2011年11月30日 ID：321; 名前：保護システム用の顔認識モジュール。 完了日：12/01/2011 |
注：ある観点から、「名前」属性は非アトミックと見なすこともできます。この場合、「姓」、「名」、「ミドルネーム」のような単純なものに分割する必要があります。
次に、比率を1NFに正規化するアルゴリズムを検討します。
- 新しい関係を作成します。この関係のスキームは、元の関係のメインスキームと従属スキームを1つにマージすることによって取得されます。
- 元のリレーションの各タプルについて、このタプルの従属リレーションにあるタプルと同じ数の新しい行に含めます。
- 下位リレーションの属性に対応する新しいリレーションの属性値を入力します。
- 新しいリレーションシップの行を元のアトミック属性の値で埋めます。
結果は次のようになります。
| 従業員コード | 氏名 | 役職 | プロジェクトコード | 役職 | 完了日 |
| 1 | イワノフイワンイワノビッチ | プログラマー | 123 | 蒸気ボイラー制御システム | 2011年9月30日 |
| 1 | イワノフイワンイワノビッチ | プログラマー | 231 | 室内のさまざまなガスの過剰MPCを監視および警告するための変電所 | 2011年11月30日 |
| 1 | イワノフイワンイワノビッチ | プログラマー | 321 | セキュリティシステム用の顔認識モジュール | 2011年12月1日 |
第2正規形
1NFにある比率にも冗長性があることは明らかです。 それを排除するために、2番目の標準形式が意図されています。 しかし、その説明を進める前に、最初の欠点をまず特定する必要があります。
最初の関係に、一部の商品とそのサプライヤの供給に関する情報を含めます。
| サプライヤーコード | 市区町村 | 市のステータス | 製品コード | 数量 |
| 1 | モスクワ | 20 | 1 | 300 |
| 1 | モスクワ | 20 | 2 | 400 |
| 1 | モスクワ | 20 | 3 | 100 |
| 2 | ヤロスラブリ | 10 | 4 | 200 |
| 3 | スタブロポリ | 30 | 5 | 300 |
| 3 | スタブロポリ | 30 | 6 | 400 |
| 4 | プスコフ | 15 | 7 | 100 |
{{ベンダーコード、製品コード}-> {数量}、
{ベンダーコード}-> {市}、
{サプライヤーコード}-> {ステータス}、
{市}-> {ステータス}}
関連する主キー：{サプライヤーコード、製品コード}。
明らかに、この関係には冗長性があります。それは、供給と供給という2つのエンティティを表します。 これに関して、次の異常が発生します。
- 挿入異常。 リレーションに商品をまだ納入していないサプライヤーに関する情報を追加することはできません。
- 取り外しの異常。 サプライヤからの配信が1つだけの場合、その情報を削除すると、サプライヤに関するすべての情報が削除されます。
- 異常の更新。 サプライヤに関する情報を変更する必要がある場合（たとえば、サプライヤが別の都市に移動した場合）、サプライヤからのすべてのサプライレコードの属性値を変更する必要があります。
これらの異常を解消するには、初期比率を予測に分割する必要があります。
- 最初のものには、主キーと、それに明示的に依存するすべての非キー属性を含める必要があります。
- 残りの投影（この場合は1）は、主キーに暗黙的に依存する非キー属性と、これらの属性が明示的に依存する主キーの一部を含みます。
| サプライヤーコード | 製品コード | 数量 |
| 1 | 1 | 300 |
| 1 | 2 | 400 |
| 1 | 3 | 100 |
| 2 | 4 | 200 |
| 3 | 5 | 300 |
| 3 | 6 | 400 |
| 4 | 7 | 100 |
{ベンダーコード、製品コード}-> {数量}
| サプライヤーコード | 市区町村 | 市のステータス |
| 1 | モスクワ | 20 |
| 2 | ヤロスラブリ | 10 |
| 3 | スタブロポリ | 30 |
| 4 | プスコフ | 15 |
{{ベンダーコード}-> {市}、
{サプライヤーコード}-> {ステータス}、
{市}-> {ステータス}}
このようなパーティションにより、上記の異常が解消されました。商品をまだ配達していないサプライヤーに関する情報を追加したり、サプライヤー情報を削除せずに配達情報を削除したり、サプライヤーが別の都市に移動した場合に簡単に情報を更新したりできます。
これで、読者はすでに独立して推測できる第2正規形の定義を定式化できます：最初の正規形であり、その非キー属性のそれぞれが還元不可能に依存している場合にのみ、関係は第2正規形 （2NFと省略）にあります主キー。
文学
このトピックをより深くより徹底的に研究するには、この記事の執筆に基づいて、Chris J. Data著の「Introduction to Database Systems」をお勧めします。