0

私はおそらくこれを間違っていますが、これで終わりです。

非常に基本的な CRM のようなものを構築しようとしています。たくさんあることは知っていますが、実際に何かを学びたいと思っています。この特定のシナリオの既製の例を見つけようとしましたが、見つけたのは理論的で単純な例であり、使用できません。

このダイアグラムをもっと単純化することもできますが、その場合は空のセルになるので、基本的にはこれでループします :)

要件：

  • 一部の企業は、以前は連絡がありませんでした。そのため、追加で 2 つのテーブルcontact_emails, company_emails,contact_phonesを作成しましcompany_phonesた。

  • 連絡先の会社には連絡先 (担当者) が割り当てられている場合があります。

  • 人は電話と電子メールを持つことができます。

  • 1人で複数の会社に配属可能

  • 1 つの会社に複数の人を配置できます

図:

ダイアグラム]

質問:

  • 私は正しい軌道に乗っていますか？
  • 何をどのように改善できますか?
4

1 に答える 1

0

あなたはそれを間違っていません...たくさん。;)

1 人を複数の会社に割り当てることができるという要件は、設計では実現されていません。これを含めるには、company_id連絡先から を削除して次を追加します。

company_contacts (company_id PK/FK, contact_id PK/FK)

では、設計の残りの部分で使用される命名規則と一致するように、列contact_phonesの名前を に変更します。company_phones_idphone_id

連絡先を除いて、企業は電話と電子メールを 1 つしか持つことができないというのは正しいですか? companiesそうでない場合は、とcompany_emails/の間の関係のカーディナリティ インジケーターを確認しcompany_phonesます。company_emailsそれが正しければ、会社のandcompany_phonesテーブルをemail_idandphone_id列に置き換えることができます (そうすべきだと言っているわけではありません) 。

これらの懸念に加えて、スキーマは受け入れられるように見えます。

私が検討するかもしれないもう1つの調整があります。会社と連絡先 (関係者と呼ぶことができます) のスーパータイプを追加すると、company_phonesとcontact_phonesテーブル、およびcompany_emailsとテーブルを組み合わせることができますcontact_emails。

parties (id PK)
contacts (party_id PK/FK, name, surname)
companies (party_id PK/FK, company_name, ...)
party_phones (party_id PK/FK, phone_id PK/FK)
party_emails (party_id PK/FK, email_id PK/FK)

ただし、この場合、データベース内の会社と連絡先の電話/メールに異なるカーディナリティを適用することはできませんでした。

于 2015-07-31T21:18:04.403 に答える