DBMS の正規形 - TECHCODEVIEW.COM

正規化 を最小化するプロセスです 冗長性 関係または一連の関係から。関係に冗長性があると、挿入、削除、更新の異常が発生する可能性があります。したがって、関係の冗長性を最小限に抑えるのに役立ちます。 標準形 データベーステーブルの冗長性を排除または削減するために使用されます。

Ranjan Hero による DBMS の正規化

データベース管理システム (DBMS) では、標準形式は、データベースの設計が効率的で組織的であり、データ異常がないことを保証するのに役立つ一連のガイドラインです。正規化にはいくつかのレベルがあり、それぞれに正規形式と呼ばれる独自のガイドラインセットがあります。

DBMSの正規形に関する注意点

第一正規形 (1NF): これは正規化の最も基本的なレベルです。 1NF では、テーブルの各セルには 1 つの値のみが含まれ、各列には一意の名前が必要です。第一正規形は、重複データを排除し、クエリを簡素化するのに役立ちます。
第 2 正規形 (2NF): 2NF は、各非キー属性が主キーに依存することを要求することで、冗長なデータを排除します。これは、各列が他の列ではなく、主キーに直接関連付けられる必要があることを意味します。
第 3 正規形 (3NF): 3NF は、すべての非キー属性が互いに独立していることを要求することにより、2NF を基礎に構築されています。これは、各列が同じテーブル内の他の列ではなく、主キーに直接関連付けられる必要があることを意味します。
ボイス・コッド正規形 (BCNF): BCNF は、テーブル内の各行列式が候補キーであることを保証する 3NF のより厳密な形式です。言い換えれば、BCNF は、各非キー属性が候補キーのみに依存することを保証します。
第 4 正規形 (4NF): 4NF は、テーブルに複数値の依存関係が含まれないようにする BCNF をさらに改良したものです。
第 5 正規形 (5NF): 5NF は最高レベルの正規化であり、テーブルをより小さなテーブルに分解してデータの冗長性を除去し、データの整合性を向上させます。

標準形式は、データの冗長性を減らし、データの一貫性を高め、データベースのパフォーマンスを向上させるのに役立ちます。ただし、正規化のレベルが高くなると、データベースの設計やクエリがより複雑になる可能性があります。データベースを設計するときは、正規化と実用性のバランスを取ることが重要です。

正規形の利点

データの冗長性の削減: 正規化により、テーブル内の重複データが排除され、必要なストレージ容量が削減され、データベースの効率が向上します。
データの一貫性の向上: 正規化により、データが一貫性のある組織的な方法で保存されるようになり、データの不整合やエラーのリスクが軽減されます。
簡素化されたデータベース設計: 正規化は、テーブルとデータの関係を整理するためのガイドラインを提供し、データベースの設計と保守を容易にします。
クエリのパフォーマンスの向上: 通常、正規化されたテーブルはデータの検索と取得が容易になり、クエリのパフォーマンスが向上します。
データベースのメンテナンスが簡単になります: 正規化により、データベースがより小さく管理しやすいテーブルに分割されるため、データベースの複雑さが軽減され、データの追加、変更、削除が容易になります。

全体として、DBMS で標準形式を使用すると、データ品質が向上し、データベースの効率が向上し、データベースの設計とメンテナンスが簡素化されます。

第一正規形

リレーションに複合属性または多値属性が含まれる場合、そのリレーションは第一正規形に違反します。また、リレーションに複合属性または多値属性が含まれない場合、リレーションは第一正規形になります。関係内のすべての属性が次の場合、その関係は第一正規形になります。 単一値の属性 。

例 1 – 複数の値の属性 STUD_PHONE があるため、テーブル 1 のリレーション STUDENT は 1NF にありません。 1NF への分解を表 2 に示します。

例

例 2 –

ID Name Courses ------------------ 1 A c1, c2 2 E c3 3 M C2, c3>

上の表では、Course は複数値の属性であるため、1NF には含まれません。複数値の属性がないため、以下のテーブルは 1NF にあります。

ID Name Course ------------------ 1 A c1 1 A c2 2 E c3 3 M c2 3 M c3>

第 2 正規形

第 2 正規形になるには、関係が第 1 正規形である必要があり、関係に部分的な依存関係が含まれていてはなりません。次の場合、リレーションは 2NF にあります。 部分的な依存関係はありません。 つまり、非プライム属性 (候補キーの一部ではない属性) は、テーブルの候補キーの適切なサブセットに依存しません。 部分的な依存関係 – 候補キーの適切なサブセットが非プライム属性を決定する場合、それは部分依存関係と呼ばれます。

jvm

例 1 – 以下の表 3 について考えてみましょう。

STUD_NO COURSE_NO COURSE_FEE 1 C1 1000 2 C2 1500 1 C4 2000 4 C3 1000 4 C1 1000 2 C5 2000>

{同じコース料金のコースが多数あることに注意してください} ここで、COURSE_FEE だけで COURSE_NO または STUD_NO の値を決定することはできません。 COURSE_FEE と STUD_NO を組み合わせて COURSE_NO の値を決定することはできません。 COURSE_FEE と COURSE_NO を組み合わせて STUD_NO の値を決定することはできません。したがって、 COURSE_FEE は、唯一の候補キー {STUD_NO, COURSE_NO} に属さないため、非プライム属性になります。ただし、COURSE_NO -> COURSE_FEE、つまり、COURSE_FEE は、候補キーの適切なサブセットである COURSE_NO に依存します。非プライム属性 COURSE_FEE は候補キーの適切なサブセットに依存しており、これは部分的な依存関係であるため、この関係は 2NF にはありません。上記の関係を 2NF に変換するには、テーブルを次のように 2 つのテーブルに分割する必要があります。テーブル 1: STUD_NO、COURSE_NO テーブル 2: COURSE_NO、COURSE_FEE

   Table 1     Table 2  STUD_NO COURSE_NO COURSE_NO COURSE_FEE  1 C1 C1 1000 2 C2 C2 1500 1 C4 C3 1000 4 C3 C4 2000 4 C1 C5 2000>

注記： 2NF は、メモリに保存される冗長データを削減しようとします。たとえば、C1 コースを受講する学生が 100 人いる場合、100 件のレコードすべてに対して料金を 1000 として保存する必要はありません。代わりに、C1 のコース料金が 1000 であるため、2 番目のテーブルに料金を保存できれば済みます。
例 2 – 関係 R (A、B、C、D) における次の関数の依存関係を考慮します。

AB ->C [A と B が一緒になって C を決定します] BC -> D [B と C が一緒になって D を決定します]>>

上記の関係では、AB が唯一の候補キーであり、部分的な依存関係はありません。つまり、AB の適切なサブセットは非素数属性を決定しません。

X is a super key. Y is a prime attribute (each element of Y is part of some candidate key).>

例 1: 表 4 に示す STUDENT の関係では、FD セット: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}

候補キー: {STUD_NO}

表 4 のこの関係では、STUD_NO -> STUD_STATE および STUD_STATE -> STUD_COUNTRY が真になります。

したがって、STUD_COUNTRY は STUD_NO に推移的に依存します。これは第 3 正規形に違反します。

第 3 正規形に変換するには、リレーション STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) を次のように分解します。 STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE) STATE_COUNTRY (STATE, COUNTRY)

関係 R(A、B、C、D、E) A -> BC、CD -> E、B -> D、E -> A を検討します。上記の関係で考えられるすべての候補キーは {A、E、CD、BC} です。すべての属性は、すべての関数の依存関係が素数の右側にあります。

insキー

例 2: FD を {BC->D, AC->BE, B->E} として設定した関係 R(A,B,C,D,E) の最高正規形を見つけます。

ステップ1： ご覧のとおり、(AC)+ ={A,C,B,E,D} ですが、そのサブセットのどれもリレーションのすべての属性を決定できないため、AC が候補キーになります。 A または C はリレーションの他の属性から導出できないため、候補キー {AC} は 1 つだけになります。

ステップ2： プライム属性は、この例では候補キー {A, C} の一部である属性であり、その他はこの例では非プライム属性 {B, D, E} になります。

ステップ 3: リレーショナル DBMS では複数値または複合属性が許可されないため、リレーション R は第 1 正規形になります。 BC->D は第 2 正規形 (BC は候補キー AC の適切なサブセットではない) であり、AC->BE は第 2 正規形 (AC は候補キー) であり、B->E であるため、この関係は第 2 正規形になります。は第 2 正規形です (B は候補キー AC の適切なサブセットではありません)。

BC->D (BC はスーパーキーでも D もプライム属性でもない) および B->E (B もスーパーキーでも E もプライム属性でもない) であるため、この関係は第 3 正規形ではありませんが、第 3 正規数を満たすには、FD の LHS がスーパーキーであるか、RHS がプライム属性である必要があります。したがって、関係の最高正規形は第 2 正規形になります。

たとえば、関係 R(A, B, C) A -> BC、B -> A と B は両方ともスーパーキーであるため、上記の関係は BCNF にあるとします。

第 3 正規形

非素数属性に対する推移的な依存関係がない場合、関係は第 3 正規形であると言われます。第 3 正規形の基本条件は、関係が第 2 正規形でなければならないということです。

以下に挙げるのは、自明ではない関数依存関係 X -> Y で保持する必要がある基本条件です。

Xはスーパーキーです。
Y は主属性です (これは、Y の要素が候補キーの一部であることを意味します)。

詳細については、を参照してください。 DBMS の第 3 正規形。

BCNF

BCNF (ボイス・コッド正規形) は、第 3 正規形の単なる発展バージョンです。ここでは、第 3 正規形以外の追加ルールがいくつかあります。関係が BCNF であるための基本条件は、関係が第 3 正規形である必要があることです。

BCNF のいくつかの基本的なルールに焦点を当てる必要があります。

Javaのソート配列

1. Table must be in Third Normal Form. 2. In relation X->Y、X はリレーション内のスーパーキーでなければなりません。>>

詳細については、を参照してください。 DBMS の BCNF。

第 4 正規形

第 4 正規形には、候補キーを除いて自明でない多値依存関係は含まれません。第 4 正規形の基本条件は、関係が BCNF である必要があることです。

基本的なルールは以下のとおりです。

1. It must be in BCNF. 2. It does not have any multi-valued dependency.>

詳細については、を参照してください。 DBMS の第 4 正規形。

第 5 正規形

第 5 正規形は投影正規形とも呼ばれます。第 5 正規形の基本条件は以下のとおりです。

Relation must be in Fourth Normal Form. The relation must not be further non loss decomposed.>

詳細については、を参照してください。 DBMS の第 5 正規形。

DBMS における正規形の応用

データの一貫性: 通常の形式では、データの一貫性が確保され、冗長な情報が含まれていません。これは、データベースの不整合やエラーを防ぐのに役立ちます。
データの冗長性: 通常の形式では、一意のデータのみを含むテーブルにデータを編成することで、データの冗長性を最小限に抑えます。これにより、データベースに必要なストレージ容量が削減され、管理が容易になります。
反応時間： 標準形式では、データの取得に必要な結合の数が減るため、クエリのパフォーマンスが向上します。これにより、クエリ処理が高速化され、システム全体のパフォーマンスが向上します。
データベースのメンテナンス: 標準形式を使用すると、更新、削除、または変更が必要な冗長データの量が削減されるため、データベースの保守が容易になります。これはデータベース管理を改善し、エラーや不整合のリスクを軽減するのに役立ちます。
データベース設計: 標準形式は、効率的、柔軟、スケーラブルなデータベースを設計するためのガイドラインを提供します。これにより、必要に応じてデータベースを簡単に変更、更新、拡張できるようになります。

正規形に関する重要なポイント

BCNF には、機能の依存関係によって引き起こされる冗長性がありません。
関係が BCNF にある場合、3NF も満たされます。
リレーションのすべての属性が素属性の場合、リレーションは常に 3NF になります。
リレーショナルデータベース内のリレーションは常に、少なくとも 1NF 形式です。
すべてのバイナリリレーション (属性が 2 つだけのリレーション) は常に BCNF にあります。
リレーションに単一の候補キーしかない場合 (つまり、すべての候補キーが 1 つの属性のみで構成されている場合)、リレーションは常に 2NF になります (部分的な関数依存関係が存在しないため)。
BCNF 形式を使用すると、機能の依存関係が維持されない場合があります。その場合、失われた FD が必要ない場合にのみ BCNF を使用し、それ以外の場合は 3NF までのみ正規化します。
BCNF の後には、4NF など、さらに多くのノーマル形式が存在します。しかし、実際のデータベースシステムでは、通常、BCNF を超える必要はありません。

結論

結論として、リレーショナルデータベースは、正規形式と呼ばれる一連のルールに従って配置できます。データベース管理 (1NF、2NF、3NF、BCNF、4NF、および 5NF)。これにより、データの冗長性が削減され、データの整合性が維持されます。さまざまな種類のデータの異常と依存関係を解決することにより、後続の正規形はそれぞれ、以前の正規形を拡張します。保存されるデータの特定の要件とプロパティによって、どの標準形式を使用する必要があるかが決まります。より高い正規形はより厳密なデータ整合性を提供しますが、データベース構造がより複雑になる可能性もあります。

前年度の質問リンク

GATE CS 2012、質問 2
GATE CS 2013、質問 54
GATE CS 2013、質問 55
ゲート CS 2005、質問 29
ゲート CS 2002、質問 23
ゲート CS 2002、質問 50
ゲート CS 2001、質問 48
ゲート CS 1999、質問 32
GATE IT 2005、質問 22
GATE IT 2008、質問 60
GATE CS 2016 (セット 1)、質問 31

正規形に関するよくある質問

Q.1: DBMS において正規化が重要なのはなぜですか?

答え：

正規化はデータベースの異常を防ぐのに役立ち、最終的にはデータベースの一貫性を確保し、データベースのメンテナンスを容易にします。

Q.2: データベースを過剰に正規化することは可能ですか?

答え：

はい、過剰な正規化は複雑なクエリに影響し、パフォーマンスも低下します。規格化と実用性のバランスが取れています。

Q.3: データベースを (BCNF または 4NF) のような最高正規形に正規化する必要がありますか?

答え：

データベースの正規化には、特定の必要条件はありません。多くの場合、特定のパフォーマンスとシンプルさのためには、下位形式で十分な場合があります。