8

製品と従業員のテーブルを持つデータベースについて考えてみます。現在の製品マネージャーをモデル化するための新しい要件があり、製品を担当する唯一の従業員であり、一部の製品は製品マネージャーを必要としないほど単純または成熟していることに注意してください。つまり、各製品には0個または1個の製品マネージャーを含めることができます。

アプローチ1：テーブルを変更して、新しい可能な列Productを追加し、製品マネージャーのない製品が値によってモデル化されるようにします。NULLproduct_manager_employee_IDNULL

アプローチ2：不可能な列と、に一意の制約を設定した新しいテーブルを作成しProductManagersます。これにより、製品マネージャーのない製品は、このテーブルに行がないことでモデル化されます。NULLproduct_IDemployee_IDproduct_ID

他のアプローチもありますが、これらは私が最も頻繁に遭遇するように思われる2つです。

これらが両方とも（私が信じる傾向があるように）正当なデザインの選択であり、単に異なるスタイルを表すと仮定すると、それらには名前がありますか？私はアプローチ2を好み、実際の例を使用せずにアプローチ1を好む人にスタイルの違いを伝えるのは難しいと思います（ここで行ったように！）傾向-方向-6NF（または何でも）自分自身をスタイルします。」

これらのアプローチの1つが実際にアンチパターンであると仮定すると（2つのエンティティ間の関係をそれらのエンティティの1つの属性としてモデル化することにより、アプローチ1の場合であると私は思うので）、このアンチパターンには名前がありますか？

4

5 に答える 5

9

1つ目は、1対多の関係（1人の従業員と多くの製品）にすぎません。これは、オプションであるため（すべての製品に製品マネージャーがあるわけではない）、O：M関係（0から多数）と呼ばれることもあります。また、すべての従業員が製品マネージャーであるとは限らないため、反対側もオプションです。

2つ目は結合テーブルで、通常は多対多の関係に使用されます。しかし、片側は1対1にすぎないため（各製品は1回だけテーブルに表示されます）、実際には複雑な1対多の関係にすぎません。

個人的には最初のものが好きですが、どちらも間違っていません（または悪いです）。

2つ目は、頭に浮かぶ2つの理由で使用されます。

  1. 製品に複数のマネージャーがいる可能性を想定しています。また
  2. 製品の製品マネージャーが誰であるかの履歴を追跡する必要があります。これを行うには、たとえば、current_flag列を「Y」（または同様のもの）に設定します。ここで、一度に1つだけを現在に設定できます。これは実際、データベース中心のアプリケーションではかなり一般的なパターンです。
于 2009-06-05T09:25:27.627 に答える
2

私には、2つのモデルの異なる動作のように見えます。最初の例では、製品ごとに1人の製品マネージャーを配置し、1人の従業員が複数の製品（1対多）の製品マネージャーになることができます。2つ目は、製品ごとに複数の製品マネージャー（多対多）を許可しているようです。これは、2つのソリューションがさまざまな状況で等しく有効であり、どちらを使用するかはビジネスルールによって異なることを示しています。

于 2009-06-05T09:26:35.597 に答える
0

最初のアプローチには欠陥があります。ちょっと想像してみてください。ビジネス要件が変更され、2つのプロダクトマネージャーを製品に設定できるようになる必要があります。あなたは何をしますか？テーブルProductに別の列を追加しますか？うん。これは明らかに1NFに違反します。

2番目のアプローチが提供する別のオプションは、特定のProductManager<->製品関係のいくつかの属性を格納する機能です。たとえば、ある製品に2人のプロダクトマネージャーがいる場合は、そのうちの1人をプライマリとして設定できます...または、たとえば、従業員は電話番号を持っていても、製品マネージャーとして別の電話を持っている場合があります。番号...これも特別なテーブルに行きます。

于 2009-06-05T09:30:39.410 に答える
0

アプローチ 1)

  1. Product Manager フィールドを追加すると、Product テーブルの使用が遅くなります (すべてのデータベースではなく、一部のデータベースで可能性があります)。
  2. Product テーブルから Employee テーブルへのリンクは簡単です。

アプローチ 2)

  1. Product テーブルを使用する既存のクエリは影響を受けません。
  2. データベースのサイズを増やします。Product ID 列を別のテーブルに複製し、一意の制約とインデックスをそのテーブルに追加しました。
  3. Product テーブルから Employee テーブルへのリンクは、最初に中間テーブルにインクを付ける必要があるため、より面倒でコストがかかります。

2 つのテーブル間をどのくらいの頻度でリンクする必要がありますか?

Product テーブルを使用する他のクエリはいくつありますか?

Product テーブルのレコード数は?

于 2009-06-05T18:52:52.323 に答える
0

あなたが与える特定のケースでは、2つのテーブルの主な動機は、欠落しているデータのnullを避けることだと思います。それが、2つのアプローチを特徴付ける方法です。

ウィキペディアに賛否両論の議論があります。

私は、日付がこれを嫌っていることを考えると、複数のテーブルの解決策だけが「有効」であるようにリレーショナル理論を定義していると確信しています。たとえば、単一のテーブル アプローチを「不適切な型付け」と呼ぶことができます (null の型が明確でないため、p4 の引用を参照してください)。

于 2012-03-26T11:59:08.213 に答える