データベースの正規化とは何ですか? 正規形とは何ですか?

データベースの正規化は、データベース モデルを最適に設計するための構造化された一連の手順です。 データベースの正規化により、データベース管理者、データ エンジニア、データ アーキテクトは、アプリケーションのデータベース層が最大の効率で機能するような方法でアプリケーションのデータを保存するためのフレームワークをモデル化および設計できます。

この文脈において、データ モデルとは、データが表すビジネス ユース ケースに固有の一連の関係と概念的なエンティティを指します。 たとえば、小売銀行データの場合、これには金融取引や顧客の普通預金口座情報が含まれる場合があります。

ほとんどの Web サイトとソフトウェア アプリケーションは効率的に動作するためにデータのストレージに依存しているため、データベースの正規化はデータ管理において依然として重要なステップです。

第 6 正規形 (6NF) もあることは注目に値します。 とはいえ、6NF はまだ標準化されていないため、この定義には含めていません。

組み込みの技術辞書からの関連資料データ アーキテクチャとは

データベースの正規化プロセスは、さまざまな理由からデータベース管理において重要なステップです。 データベースの正規化は次のことに役立ちます。

データベース異常とは、特定のデータ値や属性の挿入、更新、削除など、データを変更するときに発生するエラーです。 これらの変更により、データが不正確または欠落する可能性があります。 データを正規化すると、データベースが日常の操作中にこれらの問題に悩まされるのを防ぐことができます。

機能的な依存関係は、データが表す概念的および物理的なエンティティであるデータベース属性間の関係です。 顧客の属性には、電話番号や自宅の住所などが考えられます。

その仕組みは次のとおりです。ある属性 (A) は、B の値がわかれば A の値を一意に決定できる場合、別の属性 (B) に機能的に依存します。このプロセスは逆には機能しません。 言い換えれば、関数の依存関係はデータ間の関係を表します。 これらは、正規化によって整理または管理するのが最適です。このプロセスについては、以下で説明します。

データベース設計では、データベース (およびそのデータ) の多くの部分がデータベースの他のいくつかの部分に依存することを避けたいと考えています。 言い換えれば、密結合システムは避けたいと考えています。

密結合システムでは、システムの一部が破損または機能停止する可能性があり、その結果、他の多くの部分が破損し、最終的にはデータベースのパフォーマンスに悪影響を及ぼします。

正規化は、データベース管理者がよりモジュール化され、相互依存性が低い疎結合システムを実現するのに役立ちます。 この疎結合は、問題が必然的に発生する場合の運用診断と根本原因の分析に役立ちます。

専門家からのデータベース 101 リレーショナル データベースとは何ですか?

データベース管理において、冗長性とは主にシステム内に重複データが存在することを指しますが、これは正規化によって回避できます。 データの重複を避けることは、データ モデルを簡素化する代わりに複数の場所でデータの一貫性を更新/維持する必要があるリスクに加えて、データの維持に必要な追加の費用とストレージ リソースを節約できるため、重要です。

上記すべてのプラスの副作用は、バグ、システムの問題、そして最終的にはソフトウェア アプリケーションの潜在的なダウンタイムさえも回避できることです。 データが適切に正規化されていない場合、データベース層での障害が原因でシステムのダウンタイムが発生する可能性があります。 この側面は、バックエンド システムでのアプリケーション データの適切な管理と保存を、フロントエンドでの顧客エクスペリエンス、そして最終的にはアプリケーションを所有する企業の市場での成功に直接結びつけます。

正規化されたデータベースは効率の向上にも役立ちます。 たとえば、システムは、顧客向けにデータをモデル化し、提供し、処理するために、より小規模な一連の操作を実行する必要がある場合があります。 データが適切に正規化されているため、操作セットが小さくなると、必要な計算能力も少なくなり、データベース アプリケーションが実行されるソフトウェア インフラストラクチャ (またはスタック) のコスト削減につながります。 このため、データベースの正規化は運用コストの節約にも直接結びつきます。

正規化の利点を理解したところで、データベースを正規化する手順を見てみましょう。 これらを正規形と呼びます。

このステップでは、データはまだ正規化されていないため、冗長性が多く、構造やモデリング ロジックが適用されていない生の形式のままです。

0NF から 1NF への移行には、以下が含まれます。

書籍をサンプル データ セットとして使用して、データを 0NF から 1NF に移動するために必要な例を見てみましょう。

以下では、各書籍が異なる属性 (著者 1 と著者 2) にわたって複数の著者情報を保存しているため、テーブルがゼロ正規形式でデータを表していることがわかります。これらの情報は同じデータの繰り返し列です。 また、著者名など複数の値を格納する列があるため、これを修正する必要があります。

データを Books テーブル (および Book ID 識別子を作成) と Book-Author テーブルに分割することで、重複を排除します。 Books テーブルには Book ID 識別子が追加され、Book-Author テーブルにはすべての著者 ID 情報が 1 つの列 (著者 ID) に加えて追加の著者属性 (著者の名前、性別、地理的位置) が格納されます。

この例では本は 1 冊だけですが、保存する本の数が増えてもこの構造は維持されます。

組み込みの専門家から学ぶ非リレーショナル データベースとは何ですか?

1NF から 2NF への移行には以下が含まれます。

上で説明した機能依存関係の定義に従って、書籍 ID などの他の特定の属性に基づいて著者名を一意に決定できないため、このデータは完全に機能依存しているわけではありません。

これは、BookID には 2 人の別々の作成者がいるためであり、データを第 2 正規形に正しく取得する必要があることを意味します。

キーの値から 1 つの属性の値を一意に決定するには、データをさらに分割し、Authors テーブルを作成します。 この形式のデータを使用すると、次のことができるようになります。

2NF から 3NF への移行には、以下が含まれます。

第 3 正規形ルールに基づいてデータを再評価すると、国属性の値を一意に決定する非 ID フィールド (県) があることがわかります。 したがって、国は機能的に非 ID 列である州に依存します。

この依存関係を排除することで、第 3 正規形のデータを取得できます。 これを行うには、州の値を州 ID として設定した州テーブルを作成し、その州 ID を Authors テーブルに保持します。 最後に、データをリンクし、第 2 正規形で見られた推移的な依存関係を回避します。

3NF からボイス・コッド正規形への移行には、以下が含まれます。

この形式と第 3 正規形式の違いは微妙です。 第 3 正規形と同様に、主に非キー属性に対する関数の依存関係を削除することに関心がありますが、ここでは潜在的なキー属性に対する関数の依存関係を削除することに関心があります。

この時点で、データはすでに高度に正規化されているため、この点を超えると過剰正規化の領域に入ります。これは、データが過度に分離されサイロ化されているため、データベースにパフォーマンスの問題が発生するレベルまで正規化することを意味します。

実際には、これら最後の 2 つの形式は使用されません。 理論的には、データベース異常の数をさらに減らすように設定されています。 理論的な詳細をさらに詳しく知りたい場合は、次のいくつかの役立つリソースを参照してください。

一般的に、第 1 正規形からボイス・コッド正規形までが、正規化の利点を実現するために最も一般的に使用される一連のステップを定義します。 4 番目と 5 番目の形式は、実際にはほとんど見られません。