1対多の関係に関連付けテーブルを使用するのは一般的な方法ですか？
現在、一部のデータベースアーキテクトが作業しているという概念の不一致に直面しています。この分野での私の教育は純粋にUofGoogleからのものなので、彼らは正しいと確信していますが、オンラインで彼らの側を裏付ける証拠を見つけることができません。
私たちが議論しているデータベースの一部は、さまざまな領域内の製造設備の一部に関係しています。すべての一意のAREA_CDを含むテーブルがあります。各エリアには複数の機器（EQUIP_CD）を含めることができますが、1つの機器を複数のエリアに配置することはできません。つまりこれはOne（AREA_CD）からmany（EQUIP_CD）への関係です。
私のデータベース設計の理解は、エリアテーブルに直接関連する機器のテーブルが必要であるということです。ここで、AREA_CD = PK＆FKからエリアテーブルEQUIP_CD = PKまでです（結合されたPKは、同じを共有するいくつかの機器があるためです）コード名ですが、同じではありません。これは、アップグレードしようとしているレガシーシステムからの残念な現実です）。
建築家は、エリアテーブルとイクイップメントテーブルを関連付けテーブルを介して結合することがベストプラクティスであると言っています。これは、多対多の関係のために特別に考えられたものです。
これは、EQUIP_CDが特定の種類の機器（属性を格納することに関心がある）を参照し、その複数の機器が異なる領域に存在する可能性がある場合、私には意味があります。ただし、これは多対多の関係であり、ここでは当てはまりません。さまざまなタイプの機器を参照するいくつかの共有コード名があり、属性はそれらがどのエリアにあるかによって異なります。
関連付けテーブルを使用する理由は次のとおりです。
- データ保護。アソシエーションテーブルは、コードテーブルによって保護されています。しかし、この場合、これによって値が追加されることはないと思います。それを保護するEQUIP_CDに接続されている他のテーブルがあります。
- 将来の柔軟性。これは私には理解できます。
- ベストプラクティス。それはそうですか？
だから私の質問..1対多の関係の関連付けテーブルの使用はベストプラクティスですか？上記の3つを超えて、この設計には他の正当化がありますか？
私は同僚に挑戦するつもりはありませんが、私の学習をさらに促進するだけです。前もって感謝します！
pdate ：データモデルが修正され、関連テーブルが削除されます。
単純なケースの場合、あなたは正しいので、1つ<->多くの関係に個別のリンクテーブルを用意する必要はありません。
頭に浮かぶのは、リレーションシップ用に別のテーブルを用意する必要があるかもしれない2、3の例だけです。
行の履歴を追跡していて（ビジネスロジックレイヤーで、トリガーを介して、またはOracleがそれらをサポートしている場合は「テンポラルテーブル」）、機器テーブルで変更を追跡しない関係のプロパティがある場合自体。おそらく、あなたが記述したコード、あるいはその場所で機器を保守する現在の責任者かもしれません。
後で多くの<->多くの関係をサポートする必要があると考えている場合。
ただし、この場合はそうは思われません。すべての関係にリンクテーブルを必要とするレガシーフレームワークでいくつかの奇妙な点をサポートする必要がある場合（他のレガシーな奇妙な点を回避する必要があることをすでに説明しているので、これは妥当です）。
この方法で作業するのは簡単な現地の慣行です（明らかに、これは良い考えにはなりませんが、それに対して、あなたが戦う権限を持たない可能性があります！）