データベース設計、フリーランサーの扱い方
コンテキスト
私は小さなERPシステム用のデータベースをモデル化しています。しかし最近、頭を包み込むのに苦労しているという困難な場所にぶつかりました。その論理にはいくつかの問題があります。特別な場合には、DB設計のバックグラウンドを持つ誰かが助けてくれることを願っています（これは私の最初の大規模なDBモデルプロジェクトです）。
- Contactは、さまざまな人の情報を保持するテーブルです。
- 連絡先には、Organization、idへの外部キーであるorganization_idフィールドがあります
- 連絡先に組織がない場合（organization_id = null）、「フリーランサー」であるケースを処理します...
- Organizationは、組織に関する情報を保持するテーブルです。組織は多くの連絡先にリンクされています。
- 請求書は請求書情報を保持するテーブルです。
問題：連絡先Aに請求書Xがあり、その連絡先が組織を変更するとします（トランザクション後）。請求書の所有者は誰ですか？ （つまり、請求書を特定のエンティティにリンクするにはどうすればよいですか）。
私が探求した可能な解決策
- テーブルInvoiceの外部キー（organization_id）でInvoiceをOrganizationにリンクします。
ただし、連絡先に組織がない（フリーランサーである）場合は扱いません。そのような連絡先に販売/請求書がある場合...システムはそれを処理できません。
- テーブルInvoiceの外部キー（contact_id）でInvoiceをContactにリンクします。
ただし、連絡先が組織を変更した場合、その組織は連絡先の過去の請求書を継承します（これは間違っています）。
- フロントエンドで、その連絡先が「フリーランサー」である場合、連絡先の情報に基づいて組織を自動生成します。
正直なところ、私はこの解決策が好きではありません。安いハックのように感じます。
- 連絡先に組織を強制する...
これ以外の解決策があることを願っています...
編集＃1
いくつかの回答を分析した後、重要な情報が欠落していることに気付きました。小さなERPシステムは多くのクライアントによって使用され、その一部はB2B（企業間）モデルに従い、他はに従うB2C（企業対顧客）モデル。B2Cモデルでは、連絡先には組織がありませんが、プロジェクト/販売を関連付けることができるはずです。
この組織に "従業員"が1人しかいない場合でも、各フリーランサーに個別の組織を提供することに問題はありません。実際、フリーランサーは会社の役割（自分のアドレス/メールアカウント/電話番号）と、個人または従業員の完全に分離された役割も持つことができるため、これは法的状況をよりよく反映しています。また、他のものをより均一にモデル化するのにも役立ちます。
当社で使用しているCRMはこのように機能します
最初に、住所、中央メールアドレス、Webサイト、電話などを使用して、システムに新しい組織/会社を作成します。
連絡担当者は常に「アクティブ」な組織に追加されます。必要に応じて、会社の住所とは異なる住所を入力できます（必須ではありません）。また、組織がないと連絡先を追加できません。
連絡担当者は決して会社を変更しません。それらは非アクティブになる可能性があり、既存の連絡先のコピーである新しい連絡先担当者を追加できます。これは、かつては私の担当者であった履歴情報を管理するのに役立ち（今日の新しい会社にいても）、あなたのような問題を回避します。
最後のポイントは、確かにすべてのシステムに最適なソリューションではありません。この種のモデルは、特定のケースのニーズに合っているかどうかを判断する必要があります。
あなたの編集へ：あなたが本当に組織と個人に説明責任を持たせたい場合には、従うほうがよいかもしれません 説明責任をモデル化する方法に関する彼の本「分析パターン」からのファウラーの考え（4ページを参照） =。個人および組織用の追加のテーブル「パーティ」を作成します。 「パーティ」の各エンティティには、「組織」に対応するエントリがあるか、「個人」に1つのエントリがあります。オブジェクトリレーショナルモデリングを行う場合、「パーティ」は個人と組織の基本クラスにすぎません。請求書は、参照外部キーとして「PartyID」のみを取得します。
これにより、個人だけでなく組織にも一律に対応できるようになります。
最初に赤面したのは、2つのことで物事が簡単になるということです。
「フリーランサー」を表す組織を作成し、その組織にすべてのフリーランスの連絡先を割り当てます。
そして
請求書には、OrganizationIdとContactIdの両方が含まれている必要があります。これは、請求書の時点での組織と連絡先の関係を表します。
連絡先が後で組織を変更した場合でも、請求書には元のOrganizationIdが残っているため、問題にはなりません。
データベースを愛する経験豊富な設計者からの警告：経営者が承認したビジネスユースケース、エンティティ関係図、企業全体のマスターデータフロー図などを用意せずにデータの関係を推測しようとすると危険です。あなたの質問は、承認されたデータ図から構造を計画してから、古いシステムをウェッジする必要があるかもしれないブリッジを構築するのではなく、データベースの観点から「オンザフライ」で関係の欠陥をキャプチャしようとしていることを示しているようです新しい。それは会計上の問題につながる可能性があります...あなたがすでに推測したようなデータの悪夢だけではありません。 （ サンプルケース ）
一部のシステムで私が見た興味深い傾向は、個人を特定できる情報によって実世界のオブジェクトとして検証できるデータオブジェクトとして個人を追跡することです。個人は、役割や履歴を含むポートフォリオを持ち、組織全体を移動するときに参照することができます。プライバシーの懸念に気をつけてください...
フラグインジケータを使用して、OrganizationオブジェクトまたはPersonオブジェクトのデータの使用を切り替えることができる役割としての顧客を使用すると、移行の変更をあまり必要とせずに、b2cb2b統合の問題を管理できる場合があります。一般に、トランザクションは詳細をオブジェクトの外部キーとして役割とタイムスタンプの位置に格納します。たとえば、GISに接続されたLocationというオブジェクトは、出荷元、出荷先、請求先、請求元、または郵送先としての役割を持つことができます。
重要なシステムのテーブルには、一意のID、アクティブ/非アクティブフラグ、アクティブ日時、最終変更日時、非アクティブ日時、ステータスコードが必要です。これらにより、履歴データクエリとトランザクション制御ログを最適に制御できます。ステータスコードを使用すると、レコードのマージ、エラーで入力されたフラグ、法的フラグなどを追跡できるだけでなく、トランザクションでのデータの重複を最小限に抑えることができます
新しいERPシステムは、構造化データベースと非構造化データ、SQLとNoSQLなどを処理します。計画で使用される考え方としてのオブジェクト、ロール、トランザクションは、今後の頭痛の種を最小限に抑えることができます。