3.1 データベースの正規化
正規形は、冗長性の観点から特徴づけるリレーショナル データ モデル内のリレーションのプロパティであり、データのサンプリングまたは変更の論理的に誤った結果を引き起こす可能性があります。正規形は、リレーション (データベース内のテーブル) が満たさなければならない一連の要件として定義されます。
データベースの関係を通常の形式に準拠した形式に変換するプロセスは、正規化と呼ばれます。正規化は、データベースの構造を最小限の論理的冗長性を提供する形式にすることを目的としており、パフォーマンスの低下または向上、またはデータベースの物理ボリュームの削減または増加を目的としたものではありません。
正規化の最終的な目標は、データベースに保存されている情報の潜在的な不整合を軽減することです。正規化プロセスの一般的な目的は次のとおりです。
- 特定の種類の冗長性の除外。
- いくつかの更新異常を修正します。
- 現実世界を十分に「高品質」に表現したデータベース プロジェクトの開発は直感的であり、その後の拡張のための優れた基盤として機能します。
- 必要な整合性制約を適用する手順を簡素化します。
冗長性は通常、主要なファクトのみが各リレーションに保存されるようにリレーションを分解することによって排除されます (つまり、保存されている他のファクトから派生しないファクト)。
正規化のアイデアはデータベース設計に非常に役立ちますが、データベース設計の品質を向上させるための普遍的または網羅的な手段ではありません。これは、データベース構造には、正規化では除去できないさまざまなエラーや欠点が存在する可能性があるためです。
これらの考慮事項にもかかわらず、正規化理論は、データベース プロジェクトの品質に関する科学的に厳密で合理的な基準と、この品質を向上させるための正式な方法を提供するため、リレーショナル理論と実践の非常に貴重な成果です。これにより、正規化理論は、他のデータ モデルで提供される純粋に経験に基づいた設計アプローチから際立っています。さらに、情報技術の全分野において、形式的な厳密さのレベルの点でリレーショナル データベースの正規化理論に匹敵する、設計ソリューションを評価および改善する方法は事実上存在しないと主張できます。
正規化は「単なる常識」であり、有能な専門家であれば依存関係理論を適用することなく完全に正規化されたデータベースを「自然に」設計するという理由で批判されることがあります。
しかし、クリストファー・デート教授が指摘したように、正規化はまさに成熟したデザイナーの頭の中で指針となる常識の原則です。つまり、正規化の原則は形式化された常識です。一方、常識の原則を特定して形式化することは非常に困難な作業であり、それを解決することに成功することは大きな成果となります。
3.2 第一正規形
第一正規形 (1NF) は、リレーショナル データ モデルにおける関係の基本正規形です。
リレーション変数は、その変数の有効な値の中に、各リレーション タプルに各属性の値が 1 つだけ含まれている場合に限り、第一正規形になります。
関係モデルでは、関係の概念の定義により、関係は常に第一正規形になります。
さまざまなテーブルに関しては、関係を正しく表現していない可能性があり、したがって 1NF に含まれていない可能性があります。このような場合の Christopher Date の定義によれば、テーブルは、それが何らかの関係を直接かつ真に表現している場合に限り、正規化されます (つまり、第一正規形になります)。具体的には、当該テーブルは次の 5 つの条件を満たしている必要があります。
- 行には上から下への順序はありません (つまり、行の順序は情報を伝えません)。
- 列には左から右の順序はありません (つまり、列の順序には情報が含まれません)。
- 重複した行はありません。
- 行と列の各交差には、対応するドメインの値が 1 つだけ含まれます (他には何も含まれません)。
- すべての列は「通常」です。
テーブルのすべての列の「規則性」とは、通常の列名を参照する代わりに特別な演算子の呼び出しでのみアクセスできる、または行に副作用を引き起こす「隠し」コンポーネントがテーブル内にないことを意味します。標準の演算子を呼び出すときはテーブルを使用します。
元の正規化されていない (つまり、何らかの関係を正しく表現していない) テーブル:
職員 | 電話番号 |
---|---|
イワノフ I.I. |
283-56-82 390-57-34 |
ペトロフ P.P. | 708-62-34 |
シドロフ S.S. |
1NF に縮小されたテーブル。これは、ある関係の正しい表現です。
職員 | 電話番号 |
---|---|
イワノフ I.I. | 283-56-82 |
イワノフ I.I. | 390-57-34 |
ペトロフ P.P. | 708-62-34 |
3.3 第 2 正規形
リレーション変数が第 2 正規形になるのは、それが第 1 正規形であり、すべての非キー属性が (すべての) 候補 key に既約依存している場合に限ります。
既約性とは、潜在的なキーに、この関数の依存関係を導出できるより小さな属性のサブセットが含まれていないことを意味します。還元不可能な関数依存関係については、「完全関数依存関係」という同等の概念がよく使用されます。
候補キーが単純な場合、つまり単一の属性で構成されている場合、そのキーに対する関数の依存関係は還元不可能 (完全) になります。候補キーが複合キーの場合、第 2 正規形の定義に従って、リレーション内に複合候補キーの一部に依存する非キー属性があってはなりません。
関係を第 2 正規形に変換する例
属性のペア {会社支店、役職} が次の関係の主キーを形成するとします。
会社支店 | 職名 | 給料 | コンピュータの可用性 |
---|---|---|---|
トムスク支店 | クリーナー | 20000 | いいえ |
モスクワ支店 | プログラマー | 40000 | 食べる |
トムスク支店 | プログラマー | 25000 | 食べる |
給与は支店と役職によって異なり、コンピューターの利用可能かどうかは役職のみに依存するとします。
「位置 -> コンピュータを持っている」という関数依存関係があり、左側 (行列式) が主キーの一部にすぎず、第 2 正規形の条件に違反します。
2NF に減らすには、元の関係を 2 つの関係に分解する必要があります。
会社支店 | 職名 | 給料 |
---|---|---|
トムスク支店 | クリーナー | 20000 |
モスクワ支店 | プログラマー | 40000 |
トムスク支店 | プログラマー | 25000 |
職名 | コンピュータの可用性 |
---|---|
クリーナー | いいえ |
プログラマー | 食べる |
プログラマー | 食べる |
3.4 第 3 正規形 (3NF)
リレーション変数 R は、次の条件が当てはまる場合にのみ 3NF になります。
- Rは第 2 正規形です。
- 非キー属性なしR候補キーに対する推移関数依存関係にないR。
定義の説明:
リレーション R の非キー属性は、R のどの候補キーにも属さない属性です。
属性セット X に対する属性セット Z の関数依存性 (X → Z と書かれ、「x が z を決定する」と発音) は、X → Y および Y → Z となるような属性セット Y が存在する場合、推移的です。この場合、集合 X、Y、Z のいずれも他の集合の部分集合ではありません。つまり、関数の依存関係 X → Z、X → Y、および Y → Z は自明ではなく、関数の依存関係 Y → X も存在しません。
3NF の定義は、コッドの定義と同等ですが表現が異なり、1982 年にカルロ ザニオーロによって与えられました。それによると、関係変数は、その関数依存関係 X → A のそれぞれが次の条件の少なくとも 1 つを満たす場合に限り、3NF に属します。
- X には A が含まれます (つまり、X → A は自明な関数依存関係です)。
- X - スーパーキー
- A はキー属性です (つまり、A は候補キーの一部です)。
Zaniolo の定義では、3NF とより厳格なボイス・コッド正規形 (BCNF) の違いが明確に定義されています。BCNF では 3 番目の条件 (「A がキー属性である」) が除外されます。
Codd の 3NF 定義の印象的で伝統的に説明的な要約は、Bill Kent によって与えられました。キー以外の各属性は、「キー、完全なキー、そしてキー以外の何ものでもない情報を提供する必要がある」というものです。
非キー属性の「完全なキー」に依存するという条件により、関係が第 2 正規形になることが保証されます。そして、それらが「キー以外何もない」に依存するための条件は、それらが第 3 正規形であることです。
Chris Date は、Kent の要約を 3NF の「直感的に魅力的な特徴」として語り、わずかに修正を加えれば、より厳密なボイス-コッド正規形の定義としても機能すると観察しています。「各属性は、キーに関する情報を提供する必要がある」 、フルキー、そしてキー以外の何ものでもありません。
Kent のバージョンの 3NF 定義は、Data の定式化のボイス-コッド正規形バージョンよりも厳密ではありません。これは、前者では、キー以外の属性がキーに依存することだけが述べられているためです。
プライマリ属性 (キーまたはその一部) は機能的に依存する必要はまったくありません。それぞれがキー自体またはキーの一部を提供することで、キーに関する情報を提供します。ここで、このルールはキー以外の属性に対してのみ有効であることに注意してください。これをすべての属性に適用すると、複雑な代替キーがすべて完全に無効になります。そのようなキーの各要素は「フル キー」条件に違反するためです。
例としてリレーション変数 R1 を考えてみましょう。
職員 | デパートメント | 電話 |
---|---|---|
グリシン | 会計 | 11-22-33 |
ワシリエフ | 会計 | 11-22-33 |
ペトロフ | 供給 | 44-55-66 |
各従業員は 1 つの部門にのみ所属します。各部門には 1 台の電話があります。Employee 属性が主キーです。従業員は個人用の電話を持っておらず、従業員の電話番号は部門によってのみ異なります。
この例では、次の機能依存関係が存在します: 従業員 → 部門、部門 → 電話、従業員 → 電話。
各属性が潜在的なキー Employee に対して還元不可能な関数依存関係を持っているため、リレーション変数 R1 は第 2 正規形になります。
従業員 → 電話の関係は推移的であるため、この関係は第 3 正規形ではありません。
R1 を分割すると、3NF に含まれる 2 つのリレーション変数が生成されます。
デパートメント | 電話 |
---|---|
会計 | 11-22-33 |
供給 | 44-55-66 |
職員 | デパートメント |
---|---|
グリシン | 会計 |
ワシリエフ | 会計 |
ペトロフ | 供給 |
初期関係 R1 は、必要に応じて、関係 R2 と R3 を結合する操作の結果として簡単に取得されます。