2011-12-17 8 views
0

これは経験豊富なデータベース開発者にとってはおそらく簡単な問題ですが、私は苦労しています...特定のER図をDBモデルに変換するのに問題があります。 。サブタイプのクロスリンク付きスーパータイプ/サブタイプdbデザイン

私はこのプレゼンテーションの17スライドと同様のセットアップがあります。 http://www.cbe.wwu.edu/misclasses/mis421s04/presentations/supersubtype.ppt

スライド17には、従業員タイプ属性を持つ従業員のスーパータイプとER図を示しており、従業員の種類毎時間そのものを(サブタイプとして、サラリーマンやコンサルタント)、これは私の設計状況と非常によく似ています。

私のケースでは、給与従業員だけが他の従業員の上司になることができ、私は何らかの給与従業員が時間別従業員および/または給与従業員および/またはコンサルタントの上司である、どちらも、または両方)、データベースモデルではど​​のように設計できますか?これは一対一の関係であると考えていますか?

私はすべてのテーブル2 FKEYSを有し、かつ、それ自体を参照するとSalariedEmployee(FK_EmployeeとFK_SalariedEmployeeを持つコンサルタントなど)につながる、それらの間のPK-FKの関係を、置くことができますが、私はそれが賢明な解決策ではないかもしれない考え続けます。 ...なぜ私は確信していませんが(完全性の問題?)。

これは問題ありませんか、それとも解決策がありますか、それとも良いですか?

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

答えて

1

あなたのケースは、「一般化のスペシャライゼーション」(略称Gen-Spec)と呼ばれるデザインパターンのインスタンスのように見えます。 gen-specパターンは、オブジェクト指向のプログラマーにはよく知られています。継承とサブクラスについて教えるときにチュートリアルでカバーされています。

gen-specパターンを実装するSQLテーブルの設計は、ややこしいことがあります。データベースデザインのチュートリアルでは、このトピックをよく理解しています。しかしそれは実際に何度も繰り返されます。

「汎化特化リレーショナルモデリング」でWebを検索すると、これを行う方法を教える便利な記事がいくつか見つかります。また、このフォーラムでこれまでに何度もこのトピックが出てきたことも指摘されます。

一般的に、すべての一般化されたデータをキャプチャする単一のテーブルと、そのサブクラスに固有のすべてのデータを含む各サブクラスの1つの特殊なテーブルを設計する方法を示します。興味深い部分は、サブクラステーブルの主キーです。 DBMSのオートナンバー機能を使用して、サブクラスのプライマリキーを設定しません。その代わりに、アプリケーションをプログラミングして、一般化された表に対して取得された主キー値を適切なサブクラス表に伝播します。

これは、一般化されたデータと特殊化されたデータとの間に双方向の関連付けを作成します。特殊なサブクラスごとの簡単なビューは、一般化された特殊なデータをまとめて収集します。一度それを掛けてしまえばそれは簡単ですし、それはかなりうまくいくのです。

特定のケースでは、給与従業員テーブルのPKを参照するFKの「ボス」を指定すると、このトリックを実行するのに十分です。これはあなたが望む双方向協会を生み出し、給料をもたない従業員が上司として参照されるのを防ぎます。

+0

ありがとうございました。私はそれを得ると思うが、確かにチェックする:genテーブル(従業員)のPK idは実際には仕様テーブルの1つのPK idとプログラムで同じにされるだろうか?したがって、各スペックテーブル(サブタイプ)は、常に1つのジェネラルローに関連する異なるPKIDを持ちます。これは、FKの「ボス」も常にgenテーブル(スーパータイプ)に関連付けることができることを意味します。私はこれを正しく理解しましたか? – TomL

+0

ええと...私はもちろん、別の方法を意味していました... specテーブルのPK id(Salary Employeeなど)は、実際にはgenテーブルの1つ(Employee)のPK idと同じになります、 右? – TomL

+0

はい、それ以上「Boss of column」のFKは、Salary Employeesテーブルの1行のPKと同じ値になります。このPKは、gen Employeesテーブルの1つの行にあるPKの値と同じ値になります。したがって、この共通の値に基づいて3つのテーブルをすべて結合することができます。 –

関連する問題