リレーションには結果が伴う

🌐 ほかに 28 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

モジュール7／10：Data Architectコース第3章「Salesforceのデータアーキテクチャ」。各モジュールは単独でも読めます。 前へ：項目もアーキテクチャである · 次へ：所有とライフサイクル

このモジュールが答える問い： 2つのSalesforceオブジェクトをつなぐとき、本当は何を選んでいるのか？

関係を描くのは簡単です。第2章では線を引き、名前を付けました。小売パートナーは多数の積荷目録を送り、配送は多数の品目を運び、クルーとトラックはクルー割り当てで出会う。カーディナリティ、任意性、履歴について話しました。今度はその線をSalesforceに実装します。すると図の上の線が、ずっと多くの重みを持ち始めます。

Salesforceでリレーションの種類を選ぶとき、私はただこの2つのレコードはつながっていると言っているのではありません。誰が子を所有するのか、子は親なしで存在できるのか、誰がそれを見られるのか、親が削除されたら何が起きるのか、別の親に移れるのか、親に集計できるのか、そして子が何十万件にもなったら何が起きるのかを、同時に決めているかもしれないのです。リレーションはただの線ではありません。振る舞いを持っています。

ビジネス上の関係から始める

参照関係か主従関係かの前に、ビジネスに戻りましょう。配送とその配送品目、つまり冷蔵庫、設置、引き取りを考えてみてください。品目は配送なしで存在できるでしょうか？　できません。配送が削除されたら、品目も消えるべきでしょうか？　はい。品目に独自の所有者や独自のセキュリティが必要でしょうか？　特に必要ありません。誰かが品目をある配送から別の配送へ移すべきでしょうか？　うっかりそうならないことを願います。

次は、配送とそれが載っているルートです。配送はルートに載る前から存在し、計画が変われば別のルートに移せますし、ルートを削除してもそこに載っている配送が削除されることがあってはなりません。図の上では同じに見える2本の1対多の線が、まったく違う振る舞いをするのです。まだ「参照関係」とも「主従関係」とも言っていないことに注目してください。まず振る舞いを記述する。設定はそれを実装するもの。

リレーションの種類

新規項目の画面を開くと、Salesforceはいくつかのリレーションの種類を提示します（Object Relationships Overview (opens in a new tab)、英語）。

• 参照関係：2つのオブジェクトをつなぎます。Salesforceのリレーションの基本中の基本です。
• 主従関係：親が子を支配する、親子の結びつきです。
• 多対多：それ自体は項目の種類ではなく、パターンです。Salesforceの連結オブジェクト、つまり主従関係を2つ持つカスタムオブジェクトです。
• 自己リレーション：オブジェクトからそれ自身への参照関係です。
• 階層：ユーザーオブジェクトにだけ存在する特別な参照関係で、たとえばユーザーの上司がそうです。
• 外部参照関係と間接参照関係：外部オブジェクト、つまりモジュール4の__xオブジェクトとの間のリレーションです。外部参照関係は親の外部オブジェクトを指します。間接参照関係は外部オブジェクトから標準オブジェクトまたはカスタムオブジェクトを指し、一意の外部IDで照合されます。

設計の時間のほとんどは、最初の3つに使われます。一つずつ見ていきましょう。

参照関係：これらのレコードはつながっている

参照関係が言っているのは、このレコードはあのレコードと関連しているということです。子は独自の識別、独自の所有者、独自の生涯を保ちます。配送は自分のルートを指します。ルートがキャンセルされても配送は消えず、もう一度ルートを組まれるために戻ります。

面白いことに、参照関係項目は子に置かれますが、親も何かを得ます。子の関連リストです。ですから作るときには両端に名前を付けましょう。関連リストの表示ラベルは親の上で人々が目にするもので、子リレーション名は開発者や連携が親から子へたどるときに使うものです。デフォルトのまま受け入れないでください。

参照関係は必須にも任意にもできます。任意の場合は、指している先のレコードが削除されたら何が起きるかを決めます。選択肢は3つです（Considerations for Object Relationships (opens in a new tab)、英語）。

• この項目の値をクリアする。デフォルトです。子は残り、参照関係は空になります。
• 参照レコードの削除を許可しない。ルートを削除しようとすると、Salesforceは拒否します。リレーションの一部だからです。
• このレコードも削除する。主従関係のような連鎖削除です。カスタムオブジェクト上のカスタム参照関係でしか提示されず、デフォルトでは無効で、Salesforceに組織で有効にしてもらう必要があります。連鎖削除はセキュリティと共有を迂回するからです。ユーザーは、見ることさえできなかったレコードを削除できてしまいます。

それが、設定画面の中に隠れているライフサイクルの判断です。

ルックアップ検索条件は、ユーザーが選べるものを絞り込みます。配送に取引先責任者への設置担当者（Installer）の参照関係があり、設置担当者は多くの取引先責任者のレコードタイプの一つだとしましょう。ルックアップ検索条件を使えば設置担当者だけを表示でき、条件には現在のレコード、参照先のレコード、そしてユーザー（そのプロファイル、ロール、権限）を使えます（Lookup Filters (opens in a new tab)、英語）。参照関係を正直に保つ安上がりな方法です。

主従関係：この子はあの親に属する

主従関係は、ずっと強い主張をします。クラスでは、とても強い結びつきだと言っています。主なしに詳細は存在できず、主の項目は必須です。詳細は独自の所有者項目を失い、親の所有者を引き継ぎます。詳細に別の共有テーブルはないので、子だけを単独で共有することはできず、親の共有を引き継ぎます。だから詳細オブジェクトは共有ルールも手動共有もキューも持てません。どれも所有者項目を必要とするからです（Object Relationships Overview (opens in a new tab)、英語）。設定では、その共有設定は親レコード値に連動と表示されます。そして主従関係項目そのものでは共有設定を選びます。詳細を作成、編集、削除するのに、ユーザーが主に対して参照のみと参照・更新のどちらのアクセス権を必要とするかです。主を削除すると詳細も削除されます。そして主は積み上げ集計項目を手に入れます。

ですから配送品目を配送の詳細にするなら、私はこう言っていることになります。この品目は、その生涯を通じてこの配送に属する。誰かが設定画面で主従関係を選ぶ前に、答えてほしいのはその問いです。

削除の問い

よく考え抜いたかどうかを確かめる、私のお気に入りの方法があります。誰かが親を削除したら、子に何が起きるべきか？　みんな居心地が悪くなります。それでいいのです。ここからがアーキテクチャです。

ある小売パートナーには何十万件もの過去の配送があります。誰かがそのパートナーを削除します。配送は消えるべきでしょうか？　ほぼ間違いなく違います。クレームも請求も履歴も、すべてそれに依存しています。パートナーの削除はそもそも許すべきではなく、代わりに無効化すべきなのかもしれません。主従関係では、主を削除すると詳細とその詳細まで連鎖して削除され、主を復元すればそれらも戻ってきます（Considerations for Object Relationships (opens in a new tab)、英語）。ですから誰かが「主従関係なら積み上げ集計ができる」と言ったら、私の答えはこうです。すばらしい。ほかに何に同意したのですか？

所有もついてくる

参照関係なら、子は独自の所有者を持てます。主従関係では持てず、アクセスは主に従います。詳細が本当に親の一部なら、それはまさに正しいことです。しかし子が独自の所有者、独自の共有、独自のライフサイクルを必要とするなら、モデルは主従関係が間違った選択だと教えてくれています。次のモジュールで所有をさらに掘り下げ、Sharing and Visibilityのコースではさらに先まで進みます。今は、リレーションの設計とセキュリティの設計は別々の会話ではないと覚えておきましょう。誰かが共有ルールを書く前に、データモデルがセキュリティモデルを形づくっているのです。

親は必須か、任意か？

子は、親がわかる前から存在できるでしょうか？　これは見た目以上に重要です。配送が前日の夜に積荷目録で届き、ルートはその後で組まれるなら、配送のルートを必須にすると、レコードを作成することさえできる前にルートを組まなければならなくなります。物理的なリレーションは、現実のライフサイクルを支えなければなりません。ですから私は、静的な図だけからリレーションを設計しません。知りたいのは、**どう生まれ、単独で存在でき、移動でき、どう終わるのか？**です。

子は親を替えられるか？

デフォルトでは、主従関係の子は別の親に移せません。リレーションで親の変更を許可を選べば、許すことができます（Considerations for Object Relationships (opens in a new tab)、英語）。私の直感は保守的です。ビジネスが、子は生涯一つの親に属すると言うなら、移すことを簡単にはしません。品目がある配送から別の配送へ移るのは、項目の編集ではなく、意図的なビジネス上の出来事であるべきです。ここでも、設定がアーキテクチャなのではありません。ライフサイクルのルールがアーキテクチャであり、設定はそれを実装するものです。

後になってチームを困らせることがあと2つあります。すでにデータがあるオブジェクトに主従関係を作ることはできません。参照関係を作り、すべてのレコードに値を入れてから、変換します。そして参照関係に戻せるのは、主に積み上げ集計項目がない場合だけです。変換がセキュリティに何をするかにも注意してください。参照関係を主従関係に変えると子の共有設定は「親レコード値に連動」になり、主従関係を参照関係に戻すと子の組織の共有設定は公開/参照・更新可能になります（Considerations for Object Relationships (opens in a new tab)、英語）。昨日まで非公開だったレコードが、誰かが気づくまで今日は開かれているのです。早めに選びましょう。

積み上げ集計は便利だが、無料ではない

私は積み上げ集計が好きです。配送の品目を数える、請求書の明細金額を合計する、最新の日付を見つける。ネイティブで、コードは要りません。主従関係項目は子に置かれますが、積み上げ集計は親に置かれます。ただし、細かい注意書きがあります（Roll-Up Summary Field (opens in a new tab)、英語）。

• 特定の変更（新しい積み上げ集計項目、それが依存する数式の変更、強制的な再計算）の後に積み上げ集計の値を計算するには、影響を受けるレコードの数によって最大30分かかることがあります。親の数字がなぜまだ変わらないのかと首をかしげる人を見てきました。
• 何でも集計できるわけではありません。自動採番は集計する項目にできません。そして積み上げ集計が数式項目を集計できるのは、その数式が別のオブジェクトにまたがらず、NOW()やTODAY()のようにひとりでに変わる関数を使わない場合だけです。TODAY()で作った「延滞日数」の数式は、誰もレコードを保存しないまま毎晩変わるので、積み上げ集計が再計算するきっかけがありません。そういう数字には、スケジュールトリガフローかレポートが必要です。
• 検索条件にも制限があります。ロングテキストエリア、複数選択リスト、説明、最終活動日のようなシステム項目、オブジェクト間の数式、参照関係項目は使えません。
• 積み上げ集計は編集ページにないので、入力規則で使うことはできても、そのエラーをそこに表示することはできません。

そして判断を逆にしないでください。「積み上げ集計が必要だから、主従関係にしなければならない」と言わないでください。「この子は本当にこの親に属していて、所有もライフサイクルも合っている。その利点の一つがネイティブの積み上げ集計だ」と言いましょう。意味が合わないなら、計算は別の方法で解きましょう。機能を手に入れるためにデータモデルを歪めないでください。

では、別の方法とは何でしょう？　積み上げ集計を自分で作るのです。計算した値を保持する親の項目と、それを最新に保つ自動化です。小売パートナーが、あるべき姿どおり配送からの参照関係になっていて、ビジネスがパートナー上で未完了の配送の件数を求めているとしましょう。パートナーに数値項目「未完了の配送」（Open Deliveries）を追加します。そしてレコードトリガフロー、あるいはボリュームやロジックがコードを必要とするときはApexトリガが、配送が変わるたびにそれを再計算します。参照関係の上でも動き、何でも条件にでき、ネイティブの積み上げ集計にはできない日付や数式も使えます。

しかし今度は、正しく作るのはあなたの責任です。そして、こういうものがうまくいかなくなるのはここです。自動化は、重要なすべての変更で起動しなければなりません。新しい子、編集された子、削除された子、復元された子、そして別の親に移された子。最後のものは、古い親と新しい親の両方を再計算することを意味します。一度に200件のデータロードを、制限にぶつからずに処理しなければなりません。足し引きではなく数え直しましょう。そうすれば、一つのイベントを取りこぼしても数字が永遠に間違ったままにはなりません。最初のロードのため、そしてずれてしまった日のために、すべてを再計算する方法を計画しましょう。そして、子の保存のたびに親が更新されることを忘れないでください。何千もの子を持つ親は、このあとすぐ見るロックの問題を呼び戻します。ネイティブの積み上げ集計はそのすべてをやってくれます。カスタムのものは、あなたが所有する小さなソフトウェアです。

3階層の深さ：主従関係を積み重ねる

プラットフォームには形があり、主従関係にはその形の次元が2つあります。1つ目は深さです。

主従関係はカスタムの詳細を3階層まで積み重ねられ、そこが底です（Considerations for Object Relationships (opens in a new tab)、英語）。クラスでは、取引先に注文（1つ目）、注文にその品目（2つ目）、品目にその明細（3つ目）と描き、4つ目を追加しようとすると、Salesforceが許してくれません。Steve Truckingならこうなるかもしれません。配送が主で、その配送品目が1階層目、品目の設置タスク（Install Task）が2階層目、各タスクのタスクステップ（Task Step）が3階層目です。4階層目、たとえばステップメモ（Step Note）は参照関係にしなければなりません。

Click to enlarge

積み重ねにはいくつかのルールがついてきます。

• 標準オブジェクトはカスタムオブジェクトの詳細側になれません。 カスタムオブジェクトは取引先の詳細になれますが、取引先をあなたのオブジェクトの詳細にはできません。
• 一つのオブジェクトは、多階層の積み重ねの中に一度しか登場できません。 Salesforceは、自分自身にループして戻ることを望みません。下位の詳細が、自分の主の主を兼ねることはできません。
• 主は最下層を直接積み上げ集計できません。 配送がタスクステップの数を知りたいなら、設置タスクがそのステップを積み上げ、配送品目がその積み上げ集計を積み上げ、配送が品目を積み上げます。一度に1階層ずつです。
• 所有と共有は最上位から来ます。 どの階層も、主の所有者とアクセスを引き継ぎます。
• 主を削除すると、その下のすべてが削除されます。 そして主を復元すれば、すべてが戻ってきます。

たいていは3階層で十分です。設計が4つ目を求め続けるなら、すべての階層が本当に生涯を通じてその上の階層に属しているのかを問いましょう。そして、どのつながりで鎖を切るかは選べることを忘れないでください。4階層目が参照関係である必要はありません。設置タスクは本当は配送品目に属しておらず、独自にスケジュールされ割り当てられるのかもしれません。それならそのつながりを参照関係にします。すると設置タスクが、タスクステップとステップメモを下に持つ新しい鎖を始めます。子が本当に独自の生涯を持つつながりを選び、それを参照関係にしましょう。

Click to enlarge

これで設置タスクは独自の所有者と独自の共有を持ち、配送を削除しても設置タスクは道連れにならず、設置タスクの下にさらに2階層を持てます。それがトレードオフです。鎖は短くなり、設置タスクの生涯はそれ自身のものになります。

親2つの幅：Salesforceの連結オブジェクト

まず、言葉について一言。「連結オブジェクト」には2つの意味があり、私は両方を教えるからです。

第2章で、私たちは論理的な連結オブジェクトを見つけました。2つの重要な概念の連結点が、独自の属性を持つそれ自体のものになったものです。犬は多くの芸を知っていて、芸は多くの犬に知られていて、犬の芸（Dog Trick）がその間に立ってスキルレベルと日付を持ちます。それが論理的な連結オブジェクトです。論理モデルの中にあり、誰かが参照関係か主従関係かを決めるずっと前のものです。

Salesforceはこの用語をもっと狭く使います。Salesforceが連結オブジェクトと言うとき、それは主従関係を2つ持つカスタムオブジェクトのことです（Create a Many-to-Many Object Relationship (opens in a new tab)、英語）。私はそれをSalesforceの連結オブジェクトと呼びます。Salesforceの連結オブジェクトはすべて論理的な連結オブジェクトですが、論理的な連結オブジェクトがすべてSalesforceの連結オブジェクトになるわけではありません。主従関係と参照関係で、あるいは参照関係2つで作れば、それはやはり論理的な連結オブジェクトですが、Salesforceの種類ではありません。（Salesforce自身も完全に一貫しているわけではありません。自社のオブジェクトリファレンスでは、参照関係で作られた一部の標準オブジェクトを「連結オブジェクト」と呼んでいます。試験では狭い定義だと考えてください。）

試験に出やすい知識。 Salesforceの連結オブジェクトは主従関係を2つ持つカスタムオブジェクトで、Salesforceが「連結オブジェクト」と言うときはそれを指します。論理的な連結オブジェクトはもっと広いモデリングの概念で、どう作られていても、多対多で2つのオブジェクトを結び、独自の属性を持つあらゆるオブジェクトです。

2つ目の次元は幅です。子は主従関係の親を2つ持てるか？　はい。3つは？　いいえ。各カスタムオブジェクトが持てる主従関係は最大2つです（Considerations for Object Relationships (opens in a new tab)、英語）。主従関係の親を2つ持たせることが、多対多のためのSalesforceの連結オブジェクトの作り方です。クルーとトラックはクルー割り当てで出会い、第2章で見たとおり、それは配管ではありません。日付があり、ルートがあり、たぶんステータスもあります。連結は、関係がビジネス概念になる場所です。Salesforceによる作り方のヒントはこうです。何であるかがわかる名前を付ける、レコード名を自動採番にする、そしてそれぞれの主の関連リストの名前をもう一方の主に変えて、クルーのページには「トラック」、トラックのページには「クルー」と表示されるようにする（Create a Many-to-Many Object Relationship (opens in a new tab)、英語）。

ここが込み入ったところです。2つの親のうち一方がプライマリで、それは主従関係項目を先に作ったほうです。どちらがそうなのかは見た目ではわからないので、典型的な試験問題であり、典型的な驚きでもあります。

プライマリは何を決めるのでしょう？　3つあります（Create a Many-to-Many Object Relationship (opens in a new tab)、英語）。

• 見た目。 連結オブジェクトのページは、プライマリの主の色とアイコンを使います。
• 所有者。 連結レコードは、プライマリの主レコードの所有者を引き継ぎます。詳細には所有者項目がないので目にすることはなく、意味を持つのは、後で両方の主従関係を削除した場合だけです。
• ディビジョンも、組織でディビジョンを使っているなら同じです。

そしてもう一方がセカンダリです。それは何を意味するのでしょう？

• プライマリになる順番待ちです。 プライマリの主従関係項目を削除するか参照関係に変換すると、セカンダリがプライマリになります。
• レポートの範囲を決めます。 Salesforceは2つのレポートタイプを用意します。「プライマリの主と連結オブジェクトとセカンダリの主」と「セカンダリの主と連結オブジェクトとプライマリの主」です。最初に挙げられた主が、レポートに表示できるレコードを決めます。
• アクセスでも同じだけ重みがあります。 私はこう言っています。所有はプライマリから、アクセスは両方から、そして最も厳しいものが勝つ。 連結オブジェクトは、ほかの詳細と同じく独自の共有テーブルを持ちません。Salesforceは、それぞれの主従関係項目の共有設定を通じて、ユーザーの両方の主レコードへのアクセスを確認します。両方が参照・更新に設定されていれば、クルー割り当てを編集するには、クルーとトラックの両方に参照・更新のアクセス権が必要です（Considerations for Object Relationships (opens in a new tab)、英語）。
• 削除でも同じだけ効きます。 どちらかの主、つまりクルーかトラックを削除すると、その連結レコードはごみ箱に入ります。両方を削除すると、完全に消えます。

Click to enlarge

ほかにもいくつかルールがあります。両方の主が連結オブジェクトからの積み上げ集計を持てますし、連結オブジェクトの数式と入力規則は両方の主の項目を参照できます。しかし連結オブジェクトはほかの何かの主にはなれないので、積み重ねの途中には置けません。また2つの主を同じオブジェクトにすることはできず、オブジェクトからそれ自身への多対多には別の設計が必要です。そして親が200件を超える連結レコードを持ち、連結オブジェクトがもう一方の親に積み上げ集計されている場合、十分な数を削除するまで、Salesforceはその親の削除を許しません。

では、どちらの親をプライマリにすべきでしょう？　意味を所有しているほうを先に作りましょう。クルー割り当てなら、仕事をしているのはクルーなので、私はクルーを先に作ります。そして書き留めておきましょう。画面上の何も、次の人には教えてくれないからです。

とはいえ、私の設計では、Salesforceの連結オブジェクトはあまり多くなりません。たいていオブジェクトの主従関係の親は1つで、それは同じ種類のデータです。顧客データの下に顧客データ、トランザクションの下にトランザクション（第2章のデータの種類、顧客、トランザクション、参照を思い出してください）。もう一方の親が別の種類、たいていは参照データのオブジェクトのとき、そのリレーションは参照関係です。配送品目は配送に属します。主従関係で、どちらもトランザクションデータです。運ぶ商品は参照関係で指します。商品は独自の生涯を持つ参照データで、商品を削除したら何年分もの配送履歴が道連れになるのは誰も望まないからです。配送品目はそれでも、配送とそこに載る商品の間の論理的な連結オブジェクトです。ただ、Salesforceの連結オブジェクトではないだけです。

自己リレーション：線が戻ってくるとき

オブジェクトは自分自身と関係を持てます。親取引先、上司、地域ハブに報告する物流センター。Salesforceには、ほぼどの組織でも出会う2つが組み込まれています。取引先階層を作る親取引先項目、つまり取引先から取引先と、関連するケースをまとめるモジュール2の親ケース、つまりケースからケースです。自己リレーションは参照関係でなければならず、レコードは自分自身を指せません。ただし2つのレコードが互いを指すことはできます（Considerations for Object Relationships (opens in a new tab)、英語）。ユーザーオブジェクトでは、それは独自の特別な種類、階層リレーションで、ユーザーの上司のようなものに使われます。仕組みは簡単で、大切なのは名前です。物流センターから物流センターへのDistribution_Center__cという参照関係は、誰の役にも立ちません。親？　バックアップ？　あふれた分の受け皿？　リレーションには、指している先のオブジェクトではなく、その役割の名前を付けましょう。

Click to enlarge

階層：ユーザーオブジェクト独自のリレーション

これは小さな話ですが、まさに試験が取り上げそうな、あまり知られていない唯一無二の事実です。階層は、ユーザーオブジェクトにだけ存在する特別な参照関係です。あるユーザーを別のユーザーにつなぎ、Salesforceはその鎖がループして戻ることを許しません。ユーザーは直接にも間接にも自分自身を指せません（Object Relationships Overview (opens in a new tab)、英語）。マリアの上司がデヴなら、デヴの上司はマリアにも、マリアの配下にいる誰にもなれません。

そこが、上の自己リレーションとの違いです。取引先やカスタムオブジェクトでは、2つのレコードが互いを指せます。ユーザーでは、階層は階層のままでなければなりません。そしてユーザーとユーザーを関連付ける方法はこれしかありません。ユーザーからそれ自身への通常の参照関係は提供されていません。

あなたはすでに一つ持っています。ユーザーの標準のマネージャー項目は階層リレーションで、承認はそれを使えます。この申請を申請者のマネージャーに送る、というように。自分で作ることもできます。たとえばエスカレーション先（Escalation Contact）や代理承認者（Backup Approver）で、承認は同じようにそれに沿ってルーティングできます（ApprovalProcess, Metadata API (opens in a new tab)、英語）。レコードへのアクセスを決めるロール階層と混同しないでください。階層項目はユーザー間のただのリレーションで、レコードを1件も共有しません。

試験に出やすい知識。 階層リレーションは、標準のマネージャー項目のようにユーザーオブジェクトにだけ存在し、ユーザーは直接にも間接にも自分自身を指せません。それはロール階層ではありません。

リレーションにも制限がある

各オブジェクトが持てる主従関係は最大2つです。参照関係項目と主従関係項目は合わせてリレーション項目として数えられ、デフォルトでオブジェクトごとに40、申請すれば最大50です。積み上げ集計項目はデフォルトでオブジェクトごとに25、最大40です（Increase the Maximum Relationships Allowed per Object (opens in a new tab)、Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab)、英語）。Salesforceは、どちらの制限を引き上げても性能に影響することがあると付け加えています。

その数字に合わせて設計する必要はありません。それに近づいたときに気づく必要があるのです。リレーションが次々とぶら下がっているオブジェクトは、何かを教えてくれています。本当にそれほど中心的なのかもしれません。あるいはモデルが間違っているのかもしれません。（そして第18章の余裕のルールが当てはまります。3年目を基準に測って、制限を十分に下回るようにしましょう。）

1万件の子の問い

それから、子が多すぎる親です。Salesforce自身のガイダンスは、一つの主従関係の親につき子レコードを約1万件を超えないことです（Considerations for Object Relationships (opens in a new tab)、英語）。大規模なレコードアクセスのためのガイドも、親子関係全般について同じことを言っています（Parent-Child Data Skew (opens in a new tab)、英語）。10,001件目のレコードで組織が壊れるわけではありません。しかしその点を超えると、子を保存するたびに親がロックされることがあり、親の共有の変更がすべての子に波及します。

ですから、一つの親に膨大な数の子がいるのを見たら、私は問います。なぜ全部が同じ親の下にあるのか、誰が所有しているのか、どうクエリされるのか、どんな自動化が親に触れるのか？　すべての配送を一つの「Steve Trucking」取引先の下に置けば、数日で1万件を超えます。無害な1対多が、スキューの問題になるのです。次のモジュールでスキューを予告し、第2部で深く掘り下げます。

機能で線を設計しない

このモジュールで身につけてほしい習慣はこれです。「積み上げ集計が必要」「必須にしたい」「共有を引き継がせたい」から始めないでください。それらは実装の手がかりです。ビジネスから始めましょう。子は独自の生涯を持つか、誰が所有するか、単独で存在できるか、移動できるか、親がいなくなったら何が起きるか、関係がデータを持つか、それぞれの側はどれくらい大きくなり得るか。そして、その答えを実装するリレーションを選ぶのです。

Click to enlarge

試験の先へ：AIが変えること。 AIは数秒でリレーションを提案できます。ビジネスがいつか親を削除するかどうかは教えてくれません。図を速く描けるようになっても、何百万件ものレコードと何十もの自動化が依存した後で間違ったリレーションを元に戻すのが安くなるわけではありません。

ここでアーキテクトが決めること

• 子が独自のライフサイクルを持つのか、本当に親に属するのか。そして所有とアクセスを独自に持つべきか、引き継ぐべきか。
• 子が親なしで存在できるか、親の間を移れるか、親の削除の後も残れるか。
• それぞれの参照関係が、親が削除されたときに何をするか。クリア、ブロック、連鎖削除。
• 多対多が配管なのかビジネス概念なのか、論理的な連結オブジェクトをSalesforceの連結オブジェクトにするか、どちらの親をプライマリにするか、そして両方の親がアクセスにとって何を意味するか。
• モデルがプラットフォームの形に合っているか：深さはカスタムの詳細で3階層、幅は主従関係の親2つ、リレーションと積み上げ集計の制限。
• 予想される子の数と分布が、設計を変えるべきスキューのリスクを生まないか。

リレーションとは、2つのデータがどう一緒に振る舞うかについての約束の集まりです。意図的に結びましょう。

さらに学ぶ

• Salesforceヘルプ、Considerations for Object Relationships (opens in a new tab)（英語）、2026-10-13確認。
• Salesforceヘルプ、Object Relationships Overview (opens in a new tab)とCreate a Many-to-Many Object Relationship (opens in a new tab)（英語）、2026-10-13確認。
• Salesforceヘルプ、Roll-Up Summary Field (opens in a new tab)（英語）、2026-10-13確認。
• Salesforce Developers、Metadata API、ApprovalProcess (opens in a new tab)（英語）、2026-10-13確認。
• Salesforceヘルプ、Lookup Filters (opens in a new tab)（英語）、2026-10-13確認。
• Salesforceヘルプ、Increase the Maximum Relationships Allowed per Object (opens in a new tab)とIncrease the Maximum Limit of Roll-Up Summary Fields (opens in a new tab)（英語）、2026-10-02確認。
• Salesforce Developers、Designing Record Access for Enterprise Scale、Parent-Child Data Skew (opens in a new tab)（英語）、2026-10-02確認。