MySQL の正規化とは何ですか?どのような場合にどのように使用する必要がありますか?
5 に答える
ここでは、素人の言葉で正規化を説明しようとします。まず、リレーショナル データベース (Oracle、Access、MySQL) に適用されるものなので、MySQL だけではありません。
正規化とは、各テーブルに最小限のフィールドのみが含まれていることを確認し、依存関係を取り除くことです。従業員レコードがあり、各従業員が部門に属しているとします。従業員の他のデータと共に部門をフィールドとして保存すると、問題が発生します。部門が削除されるとどうなるでしょうか。すべての部門フィールドを更新する必要があり、エラーが発生する可能性があります。また、部門を持たない従業員がいる場合はどうなるでしょうか (おそらく新しく割り当てられたのでしょうか?)。これで null 値になります。
したがって、簡単に言えば、正規化とは、null になるフィールドを持つことを回避し、テーブル内のすべてのフィールドが記述されているデータの 1 つのドメインにのみ属していることを確認することです。たとえば、employee テーブルでは、id、name、社会保障番号などのフィールドを使用できますが、これら 3 つのフィールドは部門とは関係ありません。従業員 ID のみが、従業員が所属する部門を示します。したがって、これは、従業員が所属する部門は別のテーブルにある必要があることを意味します。
簡単な正規化プロセスを次に示します。
EMPLOYEE ( < employee_id >, name, social_security, department_name)
説明したように、これは正規化されていません。正規化された形式は次のようになります
EMPLOYEE ( < employee_id >, name, social_security)
ここで、Employee テーブルは 1 セットのデータのみを担当します。では、従業員が所属する部署をどこに保存するのでしょうか? 別のテーブルで
EMPLOYEE_DEPARTMENT ( < employee_id >, department_name )
これは最適ではありません。部署名が変わったら?(それは米国政府で常に起こります)。したがって、これを行う方が良い
EMPLOYEE_DEPARTMENT ( < employee_id >, department_id )
DEPARTMENT ( < department_id >, department_name )
第 1 正規形、第 2 正規形、第 3 正規形があります。しかし、DB コースを勉強している場合を除き、私は通常、理解できる最も正規化された形式を使用します。
お役に立てれば。
正規化は MYSql 専用ではありません。これは一般的なデータベースの概念です。
正規化は、データベース内のデータを効率的に編成するプロセスです。正規化プロセスには 2 つの目標があります。冗長なデータを排除する (たとえば、同じデータを複数のテーブルに格納する) ことと、データの依存関係を意味のあるものにする (関連するデータのみをテーブルに格納する) ことです。これらはどちらも、データベースが消費するスペースの量を減らし、データが論理的に格納されるようにするため、価値のある目標です。
SQL の標準形を以下に示します。
第 1 正規形 (1NF): 単一の値の属性のみを持ち、繰り返しも配列も許可されていない場合、関係は 1NF にあると言われます。
第 2 正規形 (2NF): リレーションが 1NF にあり、すべての非キー属性が主キーに完全に依存している場合、リレーションは 2NF にあると言われます。
第 3 正規形 (3NF): 関係が 2NF にあり、推移的な依存関係がない場合、その関係は 3NF にあると言います。
Boyce-Codd Normal Form (BCNF): 関係のすべての行列式が候補キーである場合にのみ、その関係は BCNF にあると言われます。
第 4 正規形 (4NF): 関係が BCNF にあり、多値の依存関係を含まない場合、その関係は 4NF にあると言われます。
第 5 正規形 (5NF): 関係のすべての結合依存関係が関係の候補キーによって暗示される場合にのみ、関係は 5NF にあると言われます。
Domain-Key Normal Form (DKNF): すべての変更異常がない場合、その関係は DKNF にあると言います。挿入、削除、および更新の異常は、変更の異常に分類されます
こちらもご覧ください
これは、重複を排除してデータの一貫性を維持するための手法です。したがって、同じ情報が複数のテーブルに格納されているデータベースは正規化されません。
データベースの正規化に関するウィキペディアの記事を参照してください。
(これはリレーショナル データベースの一般的な手法であり、MySQL に固有のものではありません。)
アプリケーションのデータベース スキーマを作成するときは、異なるテーブルの複数の列に情報が格納されないようにする必要があります。
DB 内のすべてのテーブルがアプリケーション内の重要なエンティティを識別するため、一意の識別子は必須の列です。
現在、ストレージ スキーマを決定する際に、これらのエンティティ (テーブル) の間で、viz-a-viz、1 対 1、1 対多、多対多など、さまざまな種類の関係が特定されています。
- 1 対 1 の関係 (例: 生徒がクラス内で一意のランクを持っている) の場合、同じテーブルを使用して (両方のテーブルから) 列を格納できます。
- 1 対多の関係 (例: 学期は複数のコースを持つことができます) の場合、親テーブルに外部キーが作成されます。
- 多対多の関係 (たとえば、教授が多くの学生を担当し、その逆) の場合、3 つ目のテーブルを作成し (両方のテーブルの主キーを複合キーとして)、両方の関連データを作成する必要があります。テーブルが格納されます。
これらすべてのシナリオに対処すると、db-schema は 4NF に正規化されます。
リレーショナル データベース設計の分野では、正規化とは、データベース構造が汎用クエリに適しており、データの整合性の損失につながる挿入、更新、および削除の異常などの望ましくない特性がないことを保証する体系的な方法です。 .[1] リレーショナル モデルの発明者である EF Codd は、1970 年に正規化の概念と、現在では最初の正規形として知られているものを導入しました。[2] コッドは 1971 年に 2 番目と 3 番目の正規形を定義し[3]、コッドとレイモンド F. ボイスは 1974 年にボイス-コッド正規形を定義しました[4]。高次正規形は、その後数年間に他の理論家によって定義されました。最新のものは、2002 年に Chris Date、Hugh Darwen、および Nikos Lorentzos によって導入された 6 番目の正規形です。
非公式に、リレーショナル データベース テーブル (関係のコンピューター化された表現) は、それが第 3 正規形 (3NF) である場合、「正規化された」としばしば説明されます。[6] ほとんどの 3NF テーブルには、挿入、更新、および削除の異常がありません。つまり、ほとんどの場合、3NF テーブルは BCNF、4NF、および 5NF に準拠しています (通常は 6NF には準拠していません)。
データベース設計ガイダンスの標準的な部分は、設計者が完全に正規化された設計を作成する必要があるということです。その後、パフォーマンス上の理由から、選択的非正規化を実行できます[7]。ただし、データ ウェアハウス設計への次元モデリング アプローチなどの一部のモデリング分野では、正規化されていない設計、つまり大部分が 3NF に準拠していない設計を明示的に推奨しています。[8]