第2正規形(2NF)
2NFとは何ですか?
正規化の2番目のステップは2NFです。
リレーションが1NFにあり、すべてのルールを満たし、すべての非キー属性が主キーに完全に依存している場合にのみ、テーブルは2NFにあります。
第2正規形は、主キーへの部分的な依存関係を排除します。
例を見てみましょう-
例(テーブルは2NFに違反しています)
StudentID | ProjectID | StudentName | プロジェクト名 |
S89 | P09 | オリビア | ジオロケーション |
S76 | P07 | Jacob | クラスターの探索 |
S56 | P03 | Ava | IoTデバイス |
S92 | P05 | アレクサンドラ | クラウド展開 |
上記の表では、部分的な依存関係があります。どのように見てみましょう-
主なキー属性はStudentIDです。 およびProjectID 。
前述のように、非プライム属性、つまり StudentName およびProjectName 部分的に依存するには、候補キーの一部に機能的に依存している必要があります。
StudentName StudentIDで判断できます 、関係を部分的に依存させます。
プロジェクト名 ProjectIDで判別できます 、関係を部分的に依存させます。
したがって、< StudentProject >関係は正規化の2NFに違反しており、データベース設計が不適切であると見なされます。
例(テーブルを2NFに変換)
2NFの部分的な依存関係と違反を削除するには、上記の表を分解します-
StudentID | ProjectID | StudentName |
S89 | P09 | オリビア |
S76 | P07 | Jacob |
S56 | P03 | Ava |
S92 | P05 | アレクサンドラ |
ProjectID | ProjectName |
P09 | ジオロケーション |
P07 | クラスターの探索 |
P03 | IoTデバイス |
P05 | クラウド展開 |
これで、関係はデータベース正規化の2番目の正規形になります
-
第3正規形(3NF)
3NFとは何ですか? 正規化の3番目のステップは3NFです。 リレーションが2NFにあり、推移的な関数従属性がない場合にのみ、テーブルは3NFにあります 例を見てみましょう- 例(テーブルは3NFに違反しています) Movie_ID Listing_ID Listing_Type DVD_Price ($) 0089 007 コメディ 100 0090 003 アクション 150 0091 007 コメディ 100 上記の表は、推移的な機能依存性
-
Djangoのフォームウィジェット
この記事では、Djangoフォームでウィジェットを使用する方法を説明します。ウィジェットは、フロントエンドを改善するのに非常に役立ちます。ウィジェットは、Djangoフォーム、テキストエリア、入力、パスワード入力などからレンダリングされるhtml要素であり、すべてウィジェットです。 まず、Djangoプロジェクトとアプリを作成しましょう。 tutorial14という名前でプロジェクトを作成しました djangoFormWidgetという名前のアプリ 。 settings.pyにアプリを追加します プロジェクトのurls.py。にアプリのURLを含めます テンプレート、 home.