第3正規形(3NF)とは?条件と変換例をわかりやすく解説
第3正規形(3NF)とは?
データベースの正規化における第三段階が第3正規形(3NF:Third Normal Form)です。
テーブルが3NFであるためには、次の2つの条件を満たす必要があります。
- リレーションが第2正規形(2NF)であること
- 推移的関数従属が存在しないこと
推移的関数従属とは、「A → B」「B → C」という依存関係から、間接的に「A → C」が導かれてしまう状態を指します。このような依存関係が残っていると、データの冗長性や更新時の不整合が発生しやすくなります。
例:3NFに違反するテーブル
次の <MovieListing> テーブルを見てみましょう。
| Movie_ID | Listing_ID | Listing_Type | DVD_Price($) |
|---|---|---|---|
| 0089 | 007 | Comedy | 100 |
| 0090 | 003 | Action | 150 |
| 0091 | 007 | Comedy | 100 |
このテーブルには、次のような関数従属が成り立っています。
| Movie_ID → Listing_ID Listing_ID → Listing_Type |
その結果、Movie_ID → Listing_Type という依存関係が間接的に成立しています。これが推移的関数従属であり、このテーブルは3NFを満たしていないことになります。
例:3NFへ変換したテーブル
3NFの形に整えるには、テーブルを分割して推移的関数従属を取り除く必要があります。
<Movie> テーブル
| Movie_ID | Listing_ID | DVD_Price($) |
|---|---|---|
| 0089 | 007 | 100 |
| 0090 | 003 | 150 |
| 0091 | 007 | 100 |
<Listing> テーブル
| Listing_ID | Listing_Type |
|---|---|
| 007 | Comedy |
| 003 | Action |
分割後の <Listing> テーブルでは、Listing_ID を主キーとしてジャンル情報を一意に管理できます。そのため「Listing_ID → Listing_Type」という依存関係のみが残り、推移的関数従属は解消されます。
以上のようにテーブルを適切に分割することで、両テーブルとも第3正規形(3NF)を満たす状態になりました。
-
第2正規形(2NF)とは?部分関数従属の排除を具体例で解説
第2正規形(2NF)とは?データベース正規化における第2段階が「第2正規形(2NF:Second Normal Form)」です。あるテーブルが2NFと呼ばれるためには、以下の条件をすべて満たす必要があります。リレーションが第1正規形(1NF)のルールをすべて満たしていることすべての非キー属性が主キーに対して完全関数従属していることつまり、第2正規形は主キーへの部分関数従属を排除するための正規形です。ここからは、具体的な例を使って2NFについて詳しく見ていきましょう。例:2NFに違反するテーブル<StudentProject>StudentIDProjectIDStudentNam
-
Djangoフォームウィジェットの使い方を徹底解説|Textareaで入力フォームをカスタマイズ
Djangoのフォームウィジェットとは? この記事では、Djangoフォームにおける「ウィジェット(widget)」の使い方について詳しく解説します。ウィジェットを活用すると、フロントエンドの見た目や操作性を大きく向上させることができます。 ウィジェットとは、DjangoフォームからHTMLとしてレンダリングされる要素のことです。テキストボックス(input)、テキストエリア(textarea)、パスワード入力欄(password input)など、フォームを構成するUI部品はすべてウィジェットに該当します。 事前準備:プロジェクトとアプリの作成 まずはDjangoプロジェクトとアプリを作成