連絡先データベースの構築 - 少しスキーマのインスピレーションが必要です

Question

私は、開発中のアプリケーションのデータ構造のレイアウトに取り組んでいます。処理する必要があることの 1 つは、顧客/連絡先情報の保存です。私は、アドレス帳、Gmail 連絡先など、いくつかの異なる連絡先情報プログラムのインターフェイスを研究してきました。

私は基本的に連絡先を「エンティティ」(個人、会社、役割など) に要約しました。

• それぞれ 実在物 複数持つことができます 住所, 電話, Eメール エントリ。
  • これらはそれぞれ「関係」(家庭/職場/アシスタントなど) を定義します。
  • 実在物 {1} --{関係}--> {0..*} データ
• アン 実在物 複数持つことができます 田畑 他の「一般的な」データ (誕生日、AIM アカウントなど) のための自由形式のデータ ストレージです。
  • 実在物 {1} --{フィールド名}--> {0..*} フィールドデータ
• アン 実在物 別のリンクにリンクできます 実在物 たとえば 従業員, 配偶者
  • 実在物 {0..} <--{関係}--> {0..} 実在物

誰かが同様の連絡先データベースの SQL 実装を行ったことがありますか?ここで、一人でプロジェクトに取り組もうとしている人に共有できる、回避すべき洞察/提案/落とし穴はありますか?私が説明したことは合理的だと思われますか、それとも複雑すぎると思われますか?

1 つ質問します。全員が同じ会社で働いている 4 人がいるとします。それらはすべて同じ「勤務先」電話番号を持っています (おそらく内線番号は異なります) - 「勤務先」の番号または住所が変更された場合、連絡先を簡単に更新できるようにしたいと考えています。この多くは、データベースをどのように使用するかにかかっています。これは従業員をそれぞれの企業体に結び付ける問題になると考えていますが、そうすると住所/電話番号は従業員に直接結び付けられなくなります。エンティティ/データの関係を多対多にして、同じメールアドレス/電話番号を複数の人に添付できるようにし、1 か所で更新するとすべての場所で更新できるようにすることについて議論しています。私がこれを考えすぎているのでしょうか？ 髪の毛を抜く

Answer 1

少しありきたりな作業ですが、テーブルについて考え始める前に、データとそれを使って何をするのかを理解する必要があります。

見てみることをお勧めします オブジェクトの役割モデリング （または これ も) 実際にテーブルを実装する前に、平易な英語でモデルを定義します。私はこの VS プラグインを使用します。 ノルマ これにより、スキーマも生成されます。

あるいは、たくさんあります データモデルはこちら それはあなたにインスピレーションを与えるかもしれません。これは「連絡先管理」ですが、「顧客」セクションなど他にもあります

(画像を載せたかっただけなんですが…)
_{（ソース： データベースアンサーズ.org)}

Answer 2

これは、ちょうどあなたの2番目の質問に支援することです。電話の内線は、実際には、人と企業エンティティ間の関係に属しています。

の

Answer 3

Microsoftは資産の保守、連絡先管理、顧客と注文、文書管理、電子商取引、ヘルプデスク、問題追跡ソフトウェア、小売在庫管理、および製品カタログなどのスターターデータベース・スキーマの数を提供しています。 初期データベーススキーマを参照してください。

<時間>

の の編集のの（2016年4月）：マイクロソフトのウェブマスターがリンクを破ったが表示されます。ここでウェイバックマシンのアーカイブページのます。

Answer 4

私の経験では、最大トリミングする傾向にあるポイントのカップル..

相互の関係を考えてみましょう。誰かが会社の従業員であるとして定義されている場合たとえば、その後、同社は、定義によって、その人の雇用主である。

あなたは自分自身のエンティティとして、または人/場所に関連付けられているだけで自由にテキストとしてアドレスを検討していますか？一部のアプリケーションでは、アドレス（物理的な建物など）は「実際の」であり、唯一の1がテーブルに存在することができます。 （多くの場合、それのための政府/郵便識別子を使用して）ます。