14

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

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

  • 各エンティティは、複数の住所、電話、電子メールのエントリを持つことができます。
    • これらのそれぞれが「関係」を定義します（自宅/職場/アシスタントなど）
    • エンティティ{1}-{関係}->{0..*}データ
  • エンティティには、他の「一般的な」データ（誕生日、AIMアカウントなど）の自由形式のデータストレージである 複数のフィールドを含めることができます。
    • エンティティ{1}-{fieldName}->{0..*}フィールドデータ
  • エンティティは、たとえば従業員、配偶者として別のエンティティにリンクできます
    • エンティティ{0.. }<-{relationship}->{0.. }エンティティ

同様の連絡先データベースのSQL実装を行った人はいますか？ここで自分でプロジェクトに取り組んでいる誰かと共有することを避けるための洞察/提案/落とし穴はありますか？私が説明したことは合理的または過度に複雑に見えますか？

1つの質問ですが、同じ会社で働く4人の人がいるとします。それらはすべて同じ「勤務先」の電話番号を持っています（おそらく異なる内線番号が付いています）-「勤務先」の番号または住所が変更された場合、連絡先をかなり簡単に更新できるようにしたいと思います。これの多くは、データベースの使用方法に帰着します。これは、従業員をそれぞれの会社のエンティティにリンクすることになると思いますが、住所/電話番号は従業員に直接接続されなくなりました。エンティティとデータの関係を多対多にして、同じ住所/電話番号を複数の人に添付できるようにすることについて議論しています。1つの場所で更新すると、すべての場所で更新できます。私はこれを考えすぎているのでしょうか？髪を抜く

4

4 に答える 4

16

少し些細なことですが、テーブルについて考え始める前に、データとそれをどうするかを知っておく必要があります。

実際にテーブルを実装する前に、オブジェクトロールモデリング（またはこれも）を調べて、モデルを平易な英語で定義することをお勧めします。私はこのVSプラグインを使用します：NORMAもスキーマを生成します。

あるいは、ここにあなたを刺激するかもしれないたくさんのデータモデルがあります。これは「連絡先管理」ですが、「顧客」セクションなどの他にもあります

（画像を投稿したかっただけです。） （出典：databaseanswers.org）連絡先管理

于 2009-12-02T20:26:14.903 に答える
4

これは、2番目の質問を支援するためだけのものです。電話の内線番号は、実際には個人と会社のエンティティ間の関係に属しています。

contact_model_01

于 2009-12-02T23:22:14.147 に答える
2

マイクロソフトは、資産管理、連絡先管理、顧客と注文、ドキュメント管理、eコマース、ヘルプデスク、問題追跡ソフトウェア、小売在庫管理、製品カタログなど、多数のスターターデータベーススキーマを提供しています。スターターデータベーススキーマを参照してください。

編集（2016年4月）：Microsoftのウェブマスターがリンクを壊したようです。これがページのWaybackMachineアーカイブです。

于 2011-12-25T05:12:27.177 に答える
1

私の経験で浮き彫りになりがちないくつかのポイント。

相互関係を考慮してください。たとえば、誰かが会社の従業員であると定義されている場合、その会社は定義上、その人の雇用主です。

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

于 2009-12-02T20:49:37.647 に答える