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)
Data Architectコース第3章の学習ガイドです。まず10のモジュールを読んでください。このページでは、何が身についたかを確認できます。
この学習ガイドについて。 このガイドは、このコース自体の内容と、Salesforceが公開している試験ガイドの出題目標の一覧だけをもとに作られています。実際の試験問題をもとにしたことは一度もなく、試験に何が出るかを知っているとも主張しません。すでに受験した方は、どうか試験の問題を私に送らないでください。認定資格の契約で共有が禁じられていますし、そもそも答えを暗記するのはアーキテクトになる方法として間違っています。
この章はモデルがプラットフォームと出会う章であり、試験の多くを担っています。最大の2つのセクション、Data Modeling and Database DesignとSalesforce Data Management（それぞれ試験の4分の1）の両方につながっています。プラットフォームの数値は変わります。チェックリストには各モジュールが引用している数値を、確認した日付とともに載せています。それぞれの制限が何のためにあるのかを学び、頼る前に現在の数値を確認しましょう。
進めながらチェックしていきましょう。各項目には、それを教えている箇所へのリンクがあります。
DM-1：プラットフォーム上でデータモデルを設計する
- Salesforceがメタデータ駆動のマルチテナントプラットフォームであることを知っている：オブジェクトは新しいテーブルではなくメタデータであり、どのオブジェクトも存在した瞬間からAPIを持つ。（メタデータは設計図である、APIはオブジェクトと一緒についてきた）
- ガバナ制限は、一つのテナントが共有リソースを独占できないようにするためにあることを知っている。（エレベーターを独占することはできない）
- 標準データモデルを読める：リードは取引先、取引先責任者、商談に変換される。商談商品は価格表エントリを指し、価格表エントリはProduct2を指す。そしてサービス側にはケース、納入商品、エンタイトルメントがある。（Salesモデル、Serviceモデル）
- 新規カスタムオブジェクトの画面が何を決めるかを知っている：レコード名をテキストにするか自動採番にするか。オブジェクト分類（共有、Bulk API、ストリーミングAPIがオンならEnterprise Applicationオブジェクト、オフならLight Applicationオブジェクト）。そしてデフォルトでオフの検索を許可。（新規カスタムオブジェクトの画面）
- API参照名を読める：標準オブジェクトと標準項目には接頭辞も接尾辞もない。カスタムオブジェクトとカスタム項目は
__cで終わる。管理パッケージは名前空間プレフィックス（abc__）を付ける。そしてパッケージのオブジェクトに自分で追加した項目には__cが付くが、ベンダーの接頭辞は決して付かない。（接頭辞と接尾辞：何を見ているのか） - 標準オブジェクトについてきれいに合うかのテストを当てはめられ、意味や重みがカスタムオブジェクトを指し示すのはいつかを知っている。（きれいに合うかのテスト）
- 納入商品と個人取引先が何のためにあるのか、個人取引先は法人取引先の約2倍のストレージを使うこと、そして個人取引先は一度有効にすると無効にできないことを知っている。（納入商品はよい例、個人取引先、個人が取引先になるのはいつか？）
- 必要な振る舞いでデータ型を選び（車両番号は数値ではない）、日付/時間はGMTで保存され、読む人それぞれのタイムゾーンで表示されるので、等しいかどうかではなく範囲で比較することを知っている。（数字はいつも数値とは限らない、日付、日付/時間、時間）
- テキストには2つの種類があることを知っている：レコード上の255文字までのもの（インデックスを付けられ、一意や外部IDとして使える）と、それを超えるロングテキストエリアやリッチテキストエリア。後者にはインデックスがなく、
WHEREでの絞り込みも数式もできない。（テキストの仲間） - 自動採番のNameを使うべきときと、それがレコードのIDではないことを知っている。（人がそれを識別する必要があるか？）
- 外部IDによって連携がupsertでき、親の外部IDで子をロードできることを知っている。（外部ID）
- 値を数式で導出すべきときと、保存しなければならない過去の事実であるときを知っている。（保存か、導出か？）
- 論理的な連結オブジェクト（モデリングの考え方：ほかの2つのオブジェクトを多対多で結び、独自の属性を持つオブジェクト）とSalesforceの連結オブジェクト（主従関係を2つ持つカスタムオブジェクト）の違い、そしてSalesforceが言うのは後者であることを知っている。（親2つの幅）
- 階層リレーションを知っている：標準の「マネージャ」項目のような、ユーザーオブジェクトにだけある特別な参照関係で、直接にも間接にも同じユーザーに戻ってくることはできず、ロール階層とは別物である。（階層：ユーザーオブジェクト独自のリレーション）
- 参照関係と主従関係の違いを知っている：所有、共有、必須の親、連鎖削除、積み上げ集計。（参照関係、主従関係）
- 主従関係はすでにデータのあるオブジェクトには作れない（参照関係を作り、値を入れ、変換する）こと、主の側に積み上げ集計がない場合にしか参照関係に戻せないこと、子を移すには親の変更を許可が必要なことを知っている。（子は親を替えられるか？）
- 主従関係についてのプラットフォームの形を知っている：深さはカスタムの詳細が3階層まで（参照関係でどこでも鎖を切れる）、幅は主従関係の親2つまで。Salesforceの連結オブジェクトでは、先に作られた主従関係が第1の主（所有者、見た目、ディビジョン）になり、2つ目が第2の主になる。そしてアクセスには両方の親が必要で、最も制限の厳しいほうが勝つ。（3階層の深さ、親2つの幅）
- 親が削除されたときの参照関係の3つの選択肢を知っている：項目をクリアする（デフォルト）、削除を禁止する、または連鎖削除する。連鎖削除はSalesforceが有効にするまでオフで、共有を迂回する。（参照関係）
- 自己リレーションは参照関係でなければならないこと、そして組み込みの2つ、取引先の「親取引先」とケースの「親ケース」を知っている。（自己リレーション）
- 積み上げ集計の再計算には時間がかかることがあり、積み上げ集計は
NOW()、TODAY()、オブジェクト間参照を使う数式を使えないこと、そして積み上げ集計のためだけに主従関係を選ぶべきではないことを知っている。代わりになるのは、フローやトリガーで最新に保つ保存項目である。（積み上げ集計は便利だが、無料ではない） - モジュールが引用しているリレーションの制限を知っている：オブジェクトごとに主従関係は2つ。リレーション項目はデフォルトで40（最大50）。積み上げ集計はデフォルトで25（最大40）。（リレーションにも制限がある）
DM-2：共有を尊重し、スケールするモデル
- 主従関係の子には独自の所有者も共有テーブルもないことを知っている：アクセスは主に従う。（所有もついてくる）
- 親子データスキューを知っている：Salesforceのガイダンスは、一つの親につき子を約1万件までにすること。（1万件の子の問い）
- 所有データスキュー（一人のユーザーがあるオブジェクトのレコードを1万件を超えて所有する）と、そのガイダンスを知っている：所有を分散させるか、そのユーザーをロール階層の外に置くか最上位に単独で置き、共有ルールが使う公開グループに入れない。（所有は規模の問題になり得る）
- 共有テーブルを知っている：カスタムオブジェクトの共有オブジェクトは
Object__Share。詳細オブジェクトには共有テーブルがなく、アクセスは主から来る。そして所有者が変わると手動共有は削除されるが、独自の理由を持つApex共有は残る。（共有テーブル：所有がアクセスになる場所） - 連携やエージェントが作るレコードを誰が所有するかを、所有が共有を決めているかどうかに基づいて決められる。（システムが作るレコードは誰が所有するのか？）
DM-4：Big Objectと、標準・カスタムオブジェクトの比較
- データの3つの置き場所を知っている：コア上（sObject。毎日作業する場所）、参照（別のシステムが真実の源：Salesforce Connectの外部オブジェクト
__x、またはカスタムの呼び出し）、そしてアーカイブ（コア上ならBig Object__b、コアの外ならウェアハウス）。（コア上とコアの外） - 外部オブジェクトは触れるたびにコールアウトを行うので、遅延とソースシステムの可用性が重要になることを知っている。（参照）
- Big Objectを知っている：膨大なボリューム、インデックスを通じて完全一致か範囲でクエリ、標準のUIもレポートもない、オブジェクトと項目の権限のみ、自動化なし。（アーカイブ）
- ほとんどのレコードは項目数にかかわらずデータストレージ約2KBとして数えられ、ファイルはファイルストレージで別に計測されることを知っている。（2列でも200列でも、ファイルと添付ファイル）
SDM-1：ライセンスと、人が使えるオブジェクト
- 3つの社内ライセンス、Sales Cloud、Service Cloud、Platformと、それぞれが何を使えるかを知っている。（3つの社内ライセンス）
- ライセンスはデータモデルの一部であることを知っている：Salesforce Platformのユーザーはリード、キャンペーン、商談、売上予測を使えず、Customer Communityのユーザーは商談を使えない。（ここで全部をややこしくしましょう：ライセンス）
- 外部ライセンスの階層を知っている：Customer Community、Customer Community Plus（レポート、ダッシュボード、標準の共有）、Partner Community（営業オブジェクト）。そしてPartner Communityは個人取引先と一緒に使えない。（スタジアム）
- メンバーベースとログインベースのライセンスの違いと、それぞれがどんな利用者層に合うかを知っている。（支払い方が設計を変える）
- プラットフォームのライセンスの中には、ユーザーを最大10個のカスタムオブジェクトからなる1つのアプリに制限するものがあること、そしてその中で工夫するためのレコードタイプのパターンを知っている。（ライセンスがモデルを形づくるとき）
- Salesforce Integrationライセンスは、システム間連携のためのAPIのみのユーザー向けであることを知っている。（もはやユーザーは人だけではない）
- SLAのレポートにはエンタイトルメントとマイルストンが必要で、それにはServiceのライセンスが必要なことを知っている。（ここで全部をややこしくしましょう：ライセンス）
SDM-2：データの一貫性を保つ
- ルールを一貫性のはしごの正しい段に置ける：データ型と語彙、必須と一意、入力規則、重複ルール、自動化。（データの一貫性を保つ）
- 制限付き選択リストはAPIからであってもリストにない値を拒否し、グローバル値セットは一つのリストを複数の項目で共有する（最大1,000個の値）ことを知っている。（1段目）
- ページレイアウトでの必須はその画面だけを守り、データは守らないこと、そして入力規則はすべての保存で動くことを知っている。（UIでの入力チェックはデータの入力チェックではない、3段目）
- ISNEW()とISCHANGED()、カスタム権限、あるいは本番稼働日で入力規則の対象を絞れ、それぞれの選択肢がどの保存（一括での所有者変更や積み上げ集計のように、自分では制御できない保存も含む）をまだチェックするのかを知っている。（古いレコードの問題）
- 一致ルールと重複ルール、モジュールが引用している制限（オブジェクトごとに有効な重複ルールは5つ、それぞれに一致ルールは3つ）、そしてそれらはシステムをまたぐ識別を解決しないことを知っている。（4段目：重複ルール）
- 重複ルールは同じ瞬間に保存されたレコード同士を比較しないこと、APIやインポートでの保存はアラートなしでブロックされること、そして一つの保存とそれが引き起こすすべては一つのトランザクションとしてまとめてロールバックされることを知っている。（4段目、すべてか無か）
- ワークフロールールとプロセスビルダーはサポートが終了しており、自動化とはフローかApexであることを知っている。（5段目：自動化）
試験の先へ
Section titled “試験の先へ ”試験は床であって天井ではありません。ここに挙げるのは、問題で問われるかどうかにかかわらず、アーキテクトに必要なこの章の習慣です。
- プラットフォームには形がある。 汎用のデータベースではなく、使っているプラットフォームに向けて設計しましょう。
- 母船を見よ。 概念を発明する前に、Salesforceがそれをどうモデリングしているかを見ましょう。
- すべてのオブジェクトは約束である： ストレージ、制限、共有モデル、ライセンス、そして依存関係。
- オブジェクトを選ぶ前にデータがどこにあるかを問う： コア上、参照、アーカイブ。
- API参照名を読めば、誰が作ったのかがわかる。 そして何を変えられるのかも。
- 今日アーカイブしていないなら、いつかアーカイブすることがあるのか？
- Big Objectは、提案する前にプロトタイプを作る。
- ビジネス上の名前が違っても、自動的にオブジェクトが違うわけではない。
- どのIDがデータを必要とするかを問う： 人、顧客、パートナー、連携、エージェント。
- すべての項目に説明を付ける。 そして重要なところには分類を。
- まずリレーションの振る舞いを記述する。 設定はそれを実装するもの。機能を得るためにモデルを歪めない。
- 削除の問い： 誰かが親を削除したら、子に何が起きるべきか？
- どの輪で鎖を切るかを選ぶ： 子が本当に独自の生涯を持つところを参照関係にする。
- 所有は第1の主から、アクセスは両方から： 最も制限の厳しいほうが勝つ。
- 無効と消えたを分ける。 そして保持をビジネスルールにする。
- ルールを正しく属する限り下へ押し下げる。 正当な履歴は書き換えるのではなく、迂回を用意する。
- 図はアーキテクチャではない。 すべての構造をビジネス上の理由までさかのぼれるようにする。
覚えておきたい用語
Section titled “覚えておきたい用語 ”| 用語 | ひとことで |
|---|---|
| メタデータ駆動 | オブジェクトや項目は、新しい物理テーブルではなく、プラットフォームが実行時に読む定義である |
| マルチテナンシー | 多くの組織がインフラを共有しつつ、それぞれが分離されている。一つの建物の中の部屋のように |
| ガバナ制限 | 一つのテナントが共有リソースを独占しないようにする制限 |
| 外部オブジェクト | Salesforce Connectを通じてSalesforceに表示され、触れるたびにソースから取得されるデータ |
| Big Object | 非常に大きく、めったに使われないデータのためのストレージ。インデックスを通じてクエリする |
| 個人取引先 | 個人を取引先として表したもの。B2Cのモデル向け |
| きれいに合う | ビジネス概念が標準オブジェクトの本来の目的と一致していること |
| 外部ID | 別のシステムの識別子を持つ項目。upsertと照合に使う |
| upsert | レコードがあれば更新し、なければ作成する |
| 参照関係 | 子が独自の所有者と生涯を保つリレーション |
| 主従関係 | 子が親に属するリレーション：所有者と共有を引き継ぎ、連鎖削除され、積み上げ集計がある |
| 論理的な連結オブジェクト | モデリングの考え方。ほかの2つのオブジェクトを多対多で結び、独自の属性を持つオブジェクト。どう作るかは問わない |
| Salesforceの連結オブジェクト | Salesforceが「連結オブジェクト」と言うときに指すもの。主従関係を2つ持つカスタムオブジェクト |
| 第1の主と第2の主 | Salesforceの連結オブジェクトで先に作られた主従関係（所有者、見た目、ディビジョン）と、2つ目の主従関係（レポートの範囲。1つ目が削除されると第1の主になる） |
| 階層リレーション | 「マネージャ」のような、ユーザーオブジェクトにだけある特別な参照関係。同じユーザーに戻ってくることはできない |
| 名前空間プレフィックス | 管理パッケージのオブジェクトや項目に付くベンダーの接頭辞。abc__Inspection__cのように |
| 共有テーブル | レコードの共有の大半を持つ共有オブジェクト（AccountShare、Truck__Share）。ユーザーまたはグループごとに1行で、その理由とともに |
| 積み上げ集計 | 主の項目で、詳細の件数、合計、最小値、最大値を求めるもの |
| データスキュー | 一つの親や一人の所有者の下にレコードが多すぎ、ロックや長い共有の再計算を引き起こす状態 |
| メンバーベース／ログインベース | 外部ユーザー単位で支払うか、月ごとのログイン単位で支払うか |
| 一貫性のはしご | データのルールを強制する層。データ型から自動化まで |
| 制限付き選択リスト | どこから来ても、リストにない値を拒否する選択リスト |
| データ分類 | 所有者、使用状況、機密度、コンプライアンス分類についての項目のメタデータ |
理解度チェック
Section titled “理解度チェック ”コースと同じスタイルの短いシナリオです。開く前に自分の答えを決めましょう。
1. ユーザーは、ERPが所有し一日中更新している注文の詳細を見る必要があります。Salesforceで編集はしません。コピーして取り込むべきでしょうか？
参照しましょう。Salesforce Connectによる外部オブジェクトなら、同期すべきコピーを持たずに、ERPを真実の源のままにしておけます。表示するたびにコールアウトが発生するので遅延とERPの可用性が重要になること、そして頻繁な編集やレポートよりも参照のためのアクセスに向いていることは受け入れましょう。参照を読み直しましょう。
2. ビジネスは販売代理店、仕入先、小売パートナーを管理したいと言っています。カスタムオブジェクトを3つ作りますか？
いいえ。どれも会社なので取引先にきれいに合い、名前の違いは役割です。種別、レコードタイプ、リレーションで表せます。きれいに合うかのテストを読み直しましょう。
3. ある設計は商談を使っていますが、データを必要とする人の大半はSalesforce PlatformかCustomer Communityのライセンスです。どうしますか？
それらのライセンスは商談を使えないので、ライセンスはアーキテクチャ上の制約です。別のライセンスを買う、体験の場所を移す、あるいは設計し直す。たいていはカスタムオブジェクトの方向へ。ここで全部をややこしくしましょう：ライセンスを読み直しましょう。
4. ERPが毎晩取引先の更新を送ってきます。連携は、Salesforce IDをクエリせずに、どうやって正しいレコードを見つけるべきでしょうか？
ERPの顧客番号を外部ID項目に保存し、それでupsertします。見つかれば更新し、なければ作成します。子レコードも、親の外部IDで親を指せます。外部IDを読み直しましょう。
5. 配送品目は配送なしに存在できず、移動せず、独自の所有者も必要ありません。配送はルートに載る前から存在し、別のルートに移れます。それぞれどのリレーションにしますか？
配送品目から配送へは主従関係です（生涯親に属し、アクセスを引き継ぎ、削除が連鎖する）。配送からルートへは参照関係です（独自の生涯を持ち、最初は任意で、移動でき、ルートを削除しても配送が削除されてはならない）。ビジネス上の関係から始めるを読み直しましょう。
6. 連携が1日に3,300件の配送を作り、すべてを連携ユーザーが所有しています。そのユーザーは階層の中ほどにロールを持っています。リスクは何で、どう直しますか？
所有データスキューです。1万件を超えると、そのユーザーを動かしたりグループを変えたりするだけで長い共有の再計算が起きます。アクセスにとって所有が重要なら所有を分散させます。そうでなければ、連携ユーザーをロール階層の外に置くか、最上位のロールに単独で置き、共有ルールが使うグループには入れません。所有は規模の問題になり得るを読み直しましょう。
7. 入力規則を追加したら、古いレコード2万件がそれに違反しました。ユーザーがそのうちの1件で電話番号を編集すると、保存に失敗します。ルールはどうするべきだったでしょうか？
何が真でなければならないかだけでなく、いつ強制するかを言うべきでした。関係する項目にISNEW()やISCHANGED()を使って対象を絞り、ルールより前からあるレコードには、履歴を書き換えるのではなく意図的な迂回を用意します。古いレコードの問題を読み直しましょう。
8. ビジネスはすべての配送写真を「Salesforceに」入れたいと言っています。年400万〜500万枚で、30パーセントずつ増えています。何を提案しますか？
アクセスとストレージを分けます。ファイルはそのボリュームのために作られたコアの組織の外のストレージに置き、ユーザーが見つけて見られるように、Salesforceには参照、件数、あるいはインデックスレコードを持たせます。写真を読み直しましょう。
9. クルー割り当て（Crew Assignment）は、クルー（Crew、先に作成）とトラック（Truck）への主従関係を持っています。ある配車担当者はクルーを見られますが、トラックは見られません。その人はクルー割り当てを見られるでしょうか？
いいえ。クルーが第1の主なので、割り当ての所有者と見た目はクルーから来ますが、アクセスには両方の親が必要です。配車担当者には、それぞれの主従関係項目の共有設定が求めるレベルで、クルーとトラックの両方へのアクセスが必要です。最も制限の厳しいほうが勝ちます。親2つの幅を読み直しましょう。
10. パートナーが積荷目録のファイルを再送し、その中に同じ顧客が2回出てきます。取引先にはブロックに設定した重複ルールがあります。これで安全でしょうか？
重複ルールだけでは安全ではありません。同じ瞬間に保存されたレコードは互いに比較されず、すでにSalesforceにあるレコードとだけ比較されるので、両方の行が通ってしまうことがあります。一意性を項目まで押し下げましょう。一意の外部IDなら、プラットフォームがすべての保存でチェックするので、勝つのは1件だけです。4段目：重複ルールとすべてか無かを読み直しましょう。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)、Salesforceヘルプ（英語、2026-09-25確認）：出題目標とその配分の公式一覧。受験を予約する前に、必ず最新版を確認しましょう。
- 各モジュールの「さらに学ぶ」には、そのプラットフォームの事実の裏づけとなるSalesforceのドキュメントが、確認した日付とともに載っています。