データベース内の3つのパターン
データベース内の3つのパターン:
データベース設計三パターン(重点)
1、デザインの三パターンとは何ですか.設計表の根拠.この3つのモデルに従って設計されたテーブルでは、データ冗長性は発生しません.
2、三パターンにはどんな内容がありますか.
(1)第1のパターン:どのテーブルにもプライマリ・キーがあり、テーブル内の各フィールドの原子性は再分割できません.
(2)第2のパターン:第1のパターンに基づいて構築され、すべての非プライマリ・キーフィールドはプライマリ・キーに完全に依存し、部分的な依存は生じない.
完全依存:プライマリ・キーが押し出され、他のすべてのフィールドが決定されます.部分依存:非プライマリ・キーフィールドの存在は、プライマリ・キーが結合プライマリ・キーであるなど、一部のプライマリ・キーによって決定されます.(統合プライマリ・キーの使用は推奨されません)
表を設計するとき、「多対多」の関係に遭遇したら、どうしますか.解決方法:多対多、3枚のテーブル、関係テーブルの2つの外部キー.
(3)第3のパターン:第2のパターンに基づいて構築され、すべての非プライマリ・キーフィールドはプライマリ・キーに直接依存し、伝達依存を生成できない.
伝達依存とは?3つのフィールドABCが存在すると仮定すると,Aはプライマリ・キー,AはB,BはCを押し出し,この関係を伝達依存とする.
表を設計するとき、「一対多」の関係に遭遇したら、どうしますか.解決方法:1対多、2枚のテーブル、複数のテーブルに外部キーを追加します.
3つのモデルの役割:データの冗長性を減らすために.
結論:1つのパターン:プライマリ・キーが存在し、各フィールドは再分割できません.二パターン:部分依存は存在しません.三パターン:伝達依存は存在しません.複数対複数、3枚のテーブル、リレーショナル・テーブルの2つの外部キー.1対多、2枚の表、多くの表に外部キーを付けます.
注意:実際の開発では、お客様のニーズを主とし、冗長性を実行速度と交換する場合があります.複数のテーブル接続でデカルト積現象が発生するため、実行効率が低下します.
3、一対一はどのように設計しますか.同じテーブルに置くことができますが、情報が多すぎて、1つのテーブルの1行にフィールドが多すぎる場合があります.この場合、2つのテーブルを使用して保存することを考慮します.
1つ目のシナリオ:プライマリ・キー共有
2つ目のシナリオ:外部キー一意
データベース設計三パターン(重点)
1、デザインの三パターンとは何ですか.設計表の根拠.この3つのモデルに従って設計されたテーブルでは、データ冗長性は発生しません.
2、三パターンにはどんな内容がありますか.
(1)第1のパターン:どのテーブルにもプライマリ・キーがあり、テーブル内の各フィールドの原子性は再分割できません.
(2)第2のパターン:第1のパターンに基づいて構築され、すべての非プライマリ・キーフィールドはプライマリ・キーに完全に依存し、部分的な依存は生じない.
完全依存:プライマリ・キーが押し出され、他のすべてのフィールドが決定されます.部分依存:非プライマリ・キーフィールドの存在は、プライマリ・キーが結合プライマリ・キーであるなど、一部のプライマリ・キーによって決定されます.(統合プライマリ・キーの使用は推奨されません)
表を設計するとき、「多対多」の関係に遭遇したら、どうしますか.解決方法:多対多、3枚のテーブル、関係テーブルの2つの外部キー.
(3)第3のパターン:第2のパターンに基づいて構築され、すべての非プライマリ・キーフィールドはプライマリ・キーに直接依存し、伝達依存を生成できない.
伝達依存とは?3つのフィールドABCが存在すると仮定すると,Aはプライマリ・キー,AはB,BはCを押し出し,この関係を伝達依存とする.
表を設計するとき、「一対多」の関係に遭遇したら、どうしますか.解決方法:1対多、2枚のテーブル、複数のテーブルに外部キーを追加します.
3つのモデルの役割:データの冗長性を減らすために.
結論:1つのパターン:プライマリ・キーが存在し、各フィールドは再分割できません.二パターン:部分依存は存在しません.三パターン:伝達依存は存在しません.複数対複数、3枚のテーブル、リレーショナル・テーブルの2つの外部キー.1対多、2枚の表、多くの表に外部キーを付けます.
注意:実際の開発では、お客様のニーズを主とし、冗長性を実行速度と交換する場合があります.複数のテーブル接続でデカルト積現象が発生するため、実行効率が低下します.
3、一対一はどのように設計しますか.同じテーブルに置くことができますが、情報が多すぎて、1つのテーブルの1行にフィールドが多すぎる場合があります.この場合、2つのテーブルを使用して保存することを考慮します.
1つ目のシナリオ:プライマリ・キー共有
t_user_login
--------------------------------------------------
id(pk) username password
t_user_info
--------------------------------------------------
id(pk+fk) realname tel address...
2つ目のシナリオ:外部キー一意
t_user_login
-------------------------------------------------
id(pk) username password
t_user_info
-------------------------------------------------
id(pk) realname tel.... userid(fk+unique)