0

私はシナリオのモデル化に苦労しており、テーブルを正規化する際に、フィールドが同じテーブルにあるべきか他のテーブルにあるべきかを判断するためのキーとして FK も考慮する必要があるという質問に出くわしました。

たとえば、ユーザーとチームのテーブルがあります (1 人のユーザーは、さまざまなスポーツを考慮してゼロまたは複数のチームになる場合があります)。

Owner                                       Teams

 -----                                    -------- 
OwnerID ---PK                              TeamID  ---PK
OwnerName                                  OwnerID    ---FK  
                                          TeamManager
                                          TeamLogo

この関係を観察すると、TeamManager と TeamLogo は完全に (機能的に) TeamID のみに依存しており、UserID にはまったく依存していません (これを理解するのは正しいですか?)。関係を確立するために、UserID と TeamID の別のテーブルが必要ですか?

どんな提案も本当に役に立ちます。

これは在宅ワークではありません。私は Web サイトのモデリングを行っており、最適なスケーラブルなデータベース設計を得るために通常のフォームに関する知識を向上させています。

ありがとうございました、

4

2 に答える 2

2

...フィールドが同じテーブルにあるべきか、他のテーブルにあるべきかを判断するためのキーとして、FKも考慮する必要がありますか?

参照整合性の子エンドポイントであることは、キーであることと直交しています (つまり、FK の子はキーである場合とそうでない場合があります)。「外部キー」という名前は、(ほとんどの DBMS で) キーである必要がある親エンドポイントのみを指します。

したがって、あなたの例では、キーである必要Teams.OwnerIDはありません（実際には、説明から判断するとそうではありません）。

この関係を観察すると、TeamManager と TeamLogo は完全に (機能的に) TeamID のみに依存しており、UserID にはまったく依存していません (これを理解するのは正しいですか?)。

はい。それで合っています。

すべての属性が機能的にキー、キー全体、およびキーだけにTeams依存するため、これは 3NF にあります (Codd を助けてください ;) ) 。

理由は次のとおりです。

  • キー サブセットに依存するものは何もないため、これは 2NF です (実際、キーは 1 つの属性にすぎないため、「キー サブセット」はありません)。
  • すでに指摘したように、機能的に依存しTeamManagerてTeamLogoいないOwnerIDため、推移的な依存関係がないため、これは 3NF です。

関係を確立するために、UserID と TeamID の別のテーブルが必要ですか?

このような単純な 1:N 関係をモデル化する場合: いいえ。

M:N のモデリングは別の問題です。

したがって、言及していない追加の詳細がない限り、このモデルはうまく正規化されているように見えます。

于 2012-04-26T19:43:06.403 に答える
0

UserId と TeamId に 3 番目のテーブルを用意する理由がわかりません。TeamManager に関する詳細情報があれば、マネージャー テーブルを作成します。チームごとに 1 人のユーザーですか? ユーザーはマネージャになることができますか?

于 2012-04-26T19:14:59.077 に答える