モデルをSalesforceにする
ほかに 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)
モジュール6／6：Data Architectコース第2章「意味のあるデータモデリング」。各モジュールは単独でも読めます。 前へ：第3正規形まで設計し、それから戻す · 次へ：章の学習ガイド、そして次の章：Salesforceのデータアーキテクチャ
このモジュールが答える問い： 論理データモデルは、どのようにSalesforceの物理データモデルになるのか？
ようやくSalesforceの話をします。すべての箱をオブジェクトにしたい衝動をこらえてきたなら、もうそうしてかまいません。でも、ここまで来た順番に注目してください。ビジネスを理解し、データを記述し、それぞれの事実をあるべき場所に置き、どこで意図的にそれを曲げるかを決めました。今になって初めて、Salesforceがそれをどう実装すべきかを問うているのです。覚えておいてほしいのはこの流れです。概念 → 論理 → 物理。 概念モデルはビジネスを記述します。論理モデルはデータを記述します。物理モデルは、実際にそれをどう作るかを記述します。
おすわり、まて、モデル
Section titled “おすわり、まて、モデル ”物理モデルへのステップは、小さなもので見るのがいちばんわかりやすいので、ペットから始めます。
ビジネスと人は誰か？ ブリーダーはビジネスなので、レコードタイプ「ブリーダー」の取引先になります。飼い主も取引先、あるいは個人取引先で、レコードタイプは「飼い主」です。同じ標準オブジェクトの2つの種類が、図の上部に並んでいます。モジュール1からずっといる場所です。
標準の置き場所がないものは何か？ ペット、犬種、芸、ペットの芸、芸の評価はカスタムオブジェクトになります。そして、モジュール5でペットにコピーした種を覚えていますか？ ここでそれが役目を得ます。ペットのレコードタイプ、犬か猫か、になるのです。犬オブジェクトと猫オブジェクトを作る代わりに、1つのオブジェクトに2つのレコードタイプを持たせ、それぞれが独自のページレイアウトと選択リスト値を持ちます。
どの関係を主従関係にするか？ 私は子の親が決して付け替えられない場合にだけ主従関係を使います。 ペットの芸は生涯そのペットに属し、それぞれの芸の評価はそのペットの芸に属するので、どちらも主従関係です。これはすぐに効果を発揮します。主従関係があるからこそ、ペットはペットの芸の積み上げ集計を持てて、モジュール5の覚えた芸の数がひとりでに歩調を合わせ続けるのです。ただし、ペットは家を移ることがあるので、飼い主は参照関係です。
どれを参照関係にするか？ Salesforceは、1つの親に10,000件を超える子を持たせることを推奨していません。おすわりのような人気の芸、よくある犬種、大きなブリーダーなら簡単にそれを超えかねないので、ペットの芸は参照関係で芸を指し示し、ペットも同じように犬種とブリーダーを指し示します。そして、できる限りポリモーフィックな関係は避けましょう。1つの項目が複数のオブジェクトタイプを指せる種類の関係です。初日は便利ですが、後でそれを読まなければならないすべてのもの、つまりレポート、連携、そして今ではエージェントにとって扱いにくくなります。
何をプラットフォームの外に置くか？ ペットが居場所を報告するGPS首輪を着けているなら、その位置情報はまったくコピーする必要がありません。首輪の追跡システムからライブで読み取る外部オブジェクトにできます。
この図のすべての判断は、それより前に決めた何かにさかのぼれます。それこそが大事な点です。では、同じステップをSteve Truckingで行いましょう。
論理モデルから始める
Section titled “論理モデルから始める ”Steve Truckingの論理モデルには今、小売パートナー、物流センター、積荷目録、配送、配送品目、受取人、ルート、停車地、クルー、トラック、クルー割り当てがあります。これらはビジネス概念であり、ここからSalesforceへの対応づけを始められます。
小売パートナーは取引先かもしれません。配送は、Salesforceがすでに持っている現場での予定作業のための何かに対応するかもしれませんし、カスタムオブジェクトになるかもしれません。積荷目録に合う標準のものはないので、おそらくカスタムになります。そして受取人は本当に難しい問いです。個人取引先か、取引先責任者か、それとも単に配送の上の情報か？ それは次の章できちんと答えます。
大切な言葉はやはりかもしれないです。ビジネス概念がSalesforceのオブジェクトのように聞こえるからといって、実装を決めつけないでください。だからこそ論理モデルを先に作ったのです。それがSalesforceの設計を試すための基準になります。
ビジネスエンティティが自動的にカスタムオブジェクトになるわけではない
Section titled “ビジネスエンティティが自動的にカスタムオブジェクトになるわけではない ”管理者の方々に避けてほしい罠があります。「エンティティを11個見つけたので、カスタムオブジェクトが11個必要だ」。違います。論理エンティティは、そのビジネス概念が重要だと教えてくれます。Salesforceがそれをどう保存しなければならないかを決めるものではありません。概念は、標準オブジェクト、カスタムオブジェクト、オブジェクト間のリレーション、1つまたはいくつかの項目、設定で管理する値、あるいはSalesforceの外にあるデータになるかもしれません（Steve Truckingの配送写真はその有力な候補です）。それらの選択をするのが物理モデルであり、だからこそ最初の打ち合わせではそうした選択をしなかったのです。
属性は物理的な項目になる
Section titled “属性は物理的な項目になる ”属性にも同じ移行が起きます。論理モデルのトラックには、車両番号、VIN、メーカー、モデル、年式、ナンバープレート、ステータスがあります。今度は、それらが物理的にどう存在するかを決めます。どのオブジェクトがそれを持つか、どの項目のデータ型を使うか、どれを必須にするか、どれを一意にするか、どれが外部IDか、どれに入力チェックが必要か、どれを保存せずに導出するか、どれが機密か。論理レベルでは、トラックとは何を意味するかを問いました。物理レベルでは、Salesforceはトラックをどう表現するかを問います。別々の問いです。
関係はプラットフォーム上の判断になる
Section titled “関係はプラットフォーム上の判断になる ”関係に費やしたすべての時間が、ここで報われます。それぞれが1対1か1対多か多対多か、必須か任意か、履歴が重要かどうかは、すでにわかっています。今度は、Salesforceがそれをどう実装するかを決めます。参照関係か、主従関係か、Salesforceの連結オブジェクトか。そしておそらく独自の属性を持つ連結です。見てきたように、関係そのものがビジネス上の意味を持ち得るからです。
クルー割り当てを思い出してください。この章を「クルーとトラックの間にSalesforceの連結オブジェクトを作ろう」と言って始めることもできました。そうしていたら何を飛ばしていたかを見てください。なぜその関係が存在するのか、日付とルートが必要か、ステータスを持つか、数週間後の損傷のクレームでその履歴が必要になるか。こうしたビジネスの問いが、クルー割り当てが何であるかを教えてくれます。それがわかって初めて、Salesforceがそれをどう作るか、そしてSalesforceにすでにその役目を果たすものがあるかを決めるべきなのです。
物理モデルを描く
Section titled “物理モデルを描く ”図がまた変わります。概念モデルはビジネス概念とシンプルな線を示しました。論理モデルは、属性、キー、カーディナリティ、関係の中に隠れていたエンティティを加えました。今度の物理モデルは、Salesforceらしく見え始めます。標準オブジェクト、カスタムオブジェクト、項目、リレーションの種類、そしてプラットフォームの外にあるもの。
この3つの図を並べて、その流れが見えるようになってほしいのです。互いに無関係な3つの図ではなく、同じビジネスを3つのレベルで見たものです。
私がこうした図をどう描くかについて一言。レイアウトもメッセージの一部だからです。主となるオブジェクトを中央の少し下に置きます。親オブジェクトがあれば、少し上に置きます。そうすれば、ビジネスが考えるのと同じように、上から下へ、左から右へとモデルを読めます。参照データは脇に置きます。色にも意味があります。Salesforceはいつも青にし、その会社自身のシステムには色を一つ選びます。たいてい緑です。緑は感じのいい、親しみやすい色だからです。赤は使いませんし、黄色は少しきつい。そういうふうにレイアウトされたモデルは、私には歌いかけてくるように見えます。よく見かける図の多くは、実のところスペースのやりくりです。混み合ったガレージに車を全部どう停めるか。私はむしろ、頭がつかめる論理的な絵を描きたいのです。
物理モデルはプラットフォームを尊重しなければならない
Section titled “物理モデルはプラットフォームを尊重しなければならない ”Salesforceは汎用のリレーショナルデータベースではありません。リレーション、所有、セキュリティ、レポートについて独自の考え方を持っています。制限があり、クエリの振る舞いや自動化があり、規模が大きくなったときのモデルの振る舞いに影響するアーキテクチャがあります。ですから、ホワイトボードの上では完璧に見える論理モデルも、物理になるときには変える必要があるかもしれません。それはSalesforceが邪魔をしているのではありません。プラットフォームには形があるということであり、よいアーキテクトはその形を理解しています。次の章は、まさにそれについてです。
また、モジュール5で下した非正規化の判断のために、物理モデルが意図的にきれいな論理モデルと違ってくることもあります。理由を説明できる限り、それでかまいません。
設定画面から設計しない
Section titled “設定画面から設計しない ”もしその習慣があるなら、断ち切ってほしいものがあります。設定 → オブジェクトマネージャー → 新規カスタムオブジェクトからデータアーキテクチャを始め、進めながらモデルを考えることです。Salesforceはものを作るのを信じられないほど簡単にしてくれます。それは強みの一つであり、弱いデータモデルがあっという間にできてしまう理由の一つでもあります。数回クリックすればオブジェクトができ、もう数回で項目とリレーションができます。そしてデータが届き、フローが作られ、レポートが作られ、連携がそれに依存し、5分で作ったオブジェクトを変えるのはとても高くつくようになります。第1章の可逆性テストです。ですから、新規カスタムオブジェクトをクリックする前に、モデルを描きましょう。
物理は永久という意味ではない
Section titled “物理は永久という意味ではない ”3つのモデルを分けておくもう一つの理由は、テクノロジーが変わることです。今日、Steve Truckingのデータの一部はSalesforceのコアにあります。明日には、その一部がData 360やウェアハウス、まだ選んでいないシステムにあるかもしれず、AIアシスタントは独自の表現を必要とします。物理アーキテクチャは変わり得ますが、ビジネス概念は驚くほど安定しています。小売パートナー、配送、受取人は相変わらず存在します。それが論理モデルに価値を与えています。今日の実装に縛られない、ビジネスの長持ちする記述なのです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”論理モデルをSalesforceの物理モデルにするとき、私が決めているのは次のことです。
- どのビジネスエンティティがSalesforceの標準機能に対応し、どれにカスタムオブジェクトや別の表現が必要か。
- 論理的な属性をどう物理的な項目にし、関係をプラットフォーム上でどう実装するか。
- 意図的な非正規化を物理設計のどこに置くか。
- どのデータがSalesforceに属し、どのデータが別の場所に属するか。
- プラットフォームのどんな特性のために、物理モデルが論理モデルと違ってくる必要があるか。
何より、それぞれの判断をさかのぼれるようにしておきたいのです。私の物理モデルの何かを指して**「なぜこれがここにあるの？」**と尋ねられたら、論理モデル、概念モデルとたどって、ビジネスが実際に必要としている何かまで連れて行けるべきです。ビジネス → 概念 → 論理 → 物理。
試験の先へ：AIが変えること。 AIは今や、要件定義書から一足飛びにSalesforceのオブジェクトと項目まで進めます。だからこそ、この順序の重要性は下がるのではなく上がります。要件から設定に飛んだなら、その間に何があったのかを見せるよう頼みましょう。何をエンティティだと判断したのか、どのキーを選んだのか、どの関係を前提にしたのか、どこで非正規化したのか。それらはアーキテクチャ上の判断であり、アーキテクトはやはりそれを見る必要があります。
この章は最初の打ち合わせで名詞に耳を傾けることから始まり、ビジネスまでさかのぼれる物理モデルで終わります。Salesforceの上に作ると決めた今、次の問いはさらに深くなります。私たちは実際にどんなデータプラットフォームの上に作っているのか？
さらに学ぶ
Section titled “さらに学ぶ ”- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab)、Salesforce Developers、Winter ‘27（英語、2026-10-02確認）：「1つの親レコードに対する子が10,000件以下になるように親子関係を構成する」。データスキューについてのガイドラインであり、厳密な制限ではありません。第7章でさらに掘り下げます。
- Roll-Up Summary Field (opens in a new tab)、Salesforceヘルプ（英語、2026-10-12確認）：積み上げ集計項目は、主従関係を通じて詳細レコードを数えたり合計したりする。