このように関連する4つのテーブルがあります（例です）。

Company:
ID
Name
CNPJ

Department:
ID
Name
Code
ID_Company 

Classification:
ID
Name
Code
ID_Company

Workers:
Id 
Name
Code
ID_Classification
ID_Department

classificationwith があるとしid = 20, id_company = 1ます。そして、departmentそれはid_company = 2（別の会社を表す）持っています。

これにより、分類と部門が別々に会社にリンクされるため、2つの会社の従業員を作成できます。そんなことはしたくないので、人間関係に問題があり、それを解決する方法がわかりません。

問題は、モデルからエンティティタイプが欠落しているという事実に起因しています。次のERDを考慮してください。

との間に交差エンティティタイプを追加したことに注意してください。この新しいエンティティタイプ：モデルに暗黙的に含まれる情報を提供します。特定の部門には、さまざまな分類の一連のジョブがあります。DEPARTMENTCLASSIFICATIONPOSITION

POSITION明示的なエンティティとしてモデルに追加することには、いくつかの利点があります。

1. WORKERさまざまな企業の部門や分類に潜在的に割り当てられることを心配する問題を回避します。
2. 給与グレードなど、ポジションに適用される可能性のある他の述語の軌跡を提供します。
3. 現在位置にが存在しない場合でも、位置が存在するという事実を記録できますWORKER。これは非常に有用な情報です。

位置の問題を回避するために注意が部門と別の会社にある分類のために定義されている、私は両方のキーを展開してきましたDEPARTMENTし、CLASSIFICATIONトッド・エベレットの答えの長さで、あなたが約読むことができる理由のために良いしています、。

注意 上記のモデルは単純化を前提としています。具体的には、各位置が一度だけ記録されることを想定しています。これは、ビジネスルールに適している場合と適していない場合があります。POSITION会社内の同じ部門と分類に複数のレコードが必要な場合は、代理キーを導入できますPOSITION。

関係に問題はないと思います。代わりに問題は、各テーブルにサロゲートキー（ID）を使用することにより、結果のデータベースが、ある会社の部門と別の会社の部門の労働者の挿入を防ぐことができないことだと思います。これを理解する良い方法は、ER Diagrammingツールを使用してスキーマを視覚化することです。無料でダウンロードできるOracle Data Modelerツールを使用します。

ER図

現状では、2つの会社、たとえばIBMとを持つことができますMicrosoft。 部署IBMを持つことができSoftware Development、MicrosoftはDesktop Software部署を持つことができます。IBMはSoftware Engineer分類を持つことができ、MicrosoftはSoftware Developer分類を持つことができます。あなたがのために代理キーを持っているので、今、DepartmentそしてClassification、事実Software DevelopmentであるIBM部門とDesktop SoftwareあるMicrosoft部門は、将来の親子関係のために失われます。これもの場合Classificationです。したがって、それは偶然に割り当てることが容易であるHarlan Millsが誰であるか、IBMの従業員Software Developmentの部門、分類がでSoftware DeveloperているですMicrosoft分類！同様に、労働者には正しい分類と間違った部門が与えられる可能性があります！最初の例を示す図を次に示します。

1 IDはを表しIBM、2 IDはを表しMicrosoftます。私は赤でハイライトされてきたシナリオHarlan Millsとは、Bill Gatesその逆10部門200分類IDに関連付けられたIDとバイスにより可視化され、間違った部署に割り当てられているが。

解決するオプション

それで、彼が起こらないようにするオプションは何ですか？2つの即時オプションがあります。1つ目は、すべてのテーブルに代理キーを使用することでこの問題が存在することを認識し、それが発生しないことを確認するための追加のプログラミングを導入することです。これはアプリケーションで実行できますが、挿入と更新がアプリケーションの外部で発生する可能性がある場合は、依然として誤った関連付けが発生する可能性があります。より良いアプローチは、従業員の挿入と更新で起動するトリガーを作成して、割り当てられた部門が割り当てられた分類と同じ会社のものであることを確認し、そうでない場合は挿入または更新を失敗させることです。

2番目のオプションは、すべてのテーブルに代理キーを使用しないことです。代わりに、Company基本キーであり、親を持たないテーブルに対してのみ代理キーを使用してから、子テーブルとの識別関係を作成します。そして、テーブル、今のPK持ってそれらを区別するために、プラスシーケンス番号や名前を。その後、から関係とにはまたになるとのようにPK となり、プラス（私は、この例では、シーケンス番号を使用しています）、プラス。結果はテーブルにのみあります。今では割り当てることは不可能ですDepartmentClassificationDepartmentClassificationCompany IdDepartmentClassificationWorkeridentifyingWorkerCompany IdDepartment NumberClassification Numberone Company IdWorkerWorkera Departmentに1つとCompanya Classificationに別にCompany。

なぜこれが不可能なのですか？スキーマは、間の参照整合性実装しているためそれは不可能であるWorkerとDepartmentとをClassification。試みが挿入するように作られている場合WorkerのためにDepartment一つにCompanyし、かつClassification、他の、対応する親テーブルに存在しない組み合わせは、参照整合性違反と挿入しません作業をトリガします。

次に、2番目のオプションの実装の更新された図を示します。

優先オプション

2つのオプションのうち、2番目の理由-識別関係とカスケードキーを使用する-を絶対に好む。まず、このオプションは、追加のプログラミングなしで目的のルールを実現します。トリガーの開発は簡単ではありません。コーディング、テスト、および保守する必要があります。パフォーマンスに影響を与えないようにトリガーロジックを最適化することも簡単ではありません。データベース専門家向けの応用数学の本は、そのようなソリューションの複雑さに関する多くの詳細を提供します。第二に、ルールは、DepartmentとClassificationがのコンテキスト外に存在できないことを意味するCompanyため、スキーマは実際の世界をより正確に反映するようになりました。

これは、すべてのテーブルにサロゲートキーが必要であると単純に仮定するのが悪い考えである理由を正確に示しているため、素晴らしい質問です。 Fabian Pascalには、このトピックに関する優れたブログ投稿があり、代理キーはデータの整合性の観点から悪い考えであるだけでなく、一部の検索が遅くなることもあることを示しています。物理レベルでは、キーが適切にカスケードされていれば不要な結合が必要なためです。この質問が明らかにするもう1つの興味深いトピックは、データベースに挿入されたすべてのデータが現実世界に関して正確であることを保証できないことです。代わりに、挿入されたデータが宣言されたルールと一致することのみを保証できます。この場合、カスケードキーアプローチを使用して、DBMSがWorker特定のa をCompany割り当て、同じClassificationa Departmentを割り当てる必要があるというルールに関してデータの一貫性を維持できるようにすることで、最善を尽くすことができますCompany。しかし、現実の世界Microsoftに部署Desktop Softwareがあり、データベースのユーザーが部署がSoftware Development DBMSは何もできませんが、真の事実が与えられたと仮定します。

私が質問を理解する方法は、「労働者」テーブルのID_Classificationフィールドは、それぞれの労働者の会社に定義された分類のみを許可する必要があるということです。したがって、Workers.ID_Classificationフィールドに挿入/更新された情報を（ルールを添付するか、トリガーを介して）検証することで、この要件に対処できます。

私の読書から、私はまだこの分類が何であり、なぜID_Companyを持つ必要があるのか理解していません。ここで言及した誰かのようなポジションの場合、すべてのポジションを含む静的テーブルの方が良いと思います。

会社の分類/位置を簡単に見つけるためにこれを行っている場合は、簡単なクエリ/ビューを追加して、分類作業員部門を接続し、分類の会社IDを取得してください。

現在、マテリアライズドビューや結合インデックスなどのよりスマートなビューまたはテクノロジーが存在するため、問題がクエリのパフォーマンスである場合はそれらを使用してください。