2

私はこのサイトに参加したばかりで、これが私の最初の質問です。私の質問がStackOverflowの質問ポリシーに従っていることを願っています。

私は次の能力を持つ電話帳用のDBを設計しています

  • 連絡先には2つのタイプ（会社または個人）->ContactTypeがあります
  • また、各連絡先には、必要な数の電子メール、電話番号、およびアドレスを含める必要があります。
  • また、どの人がどの会社で働いているかを指定したいので、会社の連絡先の詳細だけでなく、その会社の従業員とその仕事のリストとその連絡先（CoEmpJobテーブル）も表示できます。

以下のリンクに示されているdbダイアグラムを設計しましたが、それは適切に構造化されていますか、それとも私が望むものをより良い方法で達成できますか？

前もって感謝します。

私の電話帳のデザイン

4

1 に答える 1

0

設計の現状では、Companys テーブルや ContactTypes テーブルなど、いくつかのものが欠けています。Contacts テーブルにリンクしている CoEmpJob テーブルに外部キーがないようです。

Phones テーブルでは、個人的にはプレフィックス フィールドを使用しません (連絡先を電話プレフィックスで表示したい場合を除きます)。この場合、すべての電話番号が一意であることが保証されます。その場合、PhoneNum フィールドが主キーになり、 PhoneID フィールドは不要ですが、夫と妻が同じデータベースにある場合もあります。彼らはほぼ確実に異なる携帯電話番号を持っていますが、ほぼ確実に同じ自宅の電話番号を共有しています! この場合、あなたのデザインは正しいです。

複数の住所を持っている人が何人いるかはわかりません (あったとしても、非常に少ないと思います)。これは、Address テーブルのフィールドを Contacts テーブルに移動できることを意味します。

(追加) 会社に関して、どの Person がどの Companyで働いているかを指定したい場合は、会社テーブル (欠落) と結合テーブル (CoEmpJob) が必要になります。現実の世界では、この設計にはさらに多くのテーブルが必要になります。結合テーブルは、どの連絡先がどの会社に接続されているか、現在の仕事は何かを示すことができますが、人々は仕事 (および会社) を変えるため、そのような設計では履歴が保存されません。 . また、人 (従業員) を部門にリンクするのが通例です。1 人の人が一度に複数の部門に接続できる可能性があるため、別の結合テーブルが必要になります。これは非常に複雑になる可能性があります-それはあなたが望むものに依存します.

あなたのコメントは、会社のデータを連絡先テーブルに保存することを示唆しています。これは非常に悪い考えです。それらは別々に保管する必要があります。

于 2013-01-07T05:36:58.187 に答える