意味のあるデータモデリング
ほかに 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コース第2章の学習ガイドです。まず6つのモジュールを読んでください。このページでは、何が身についたかを確認できます。
この学習ガイドについて。 このガイドは、このコース自体の内容と、Salesforceが公開している試験ガイドの出題目標の一覧だけをもとに作られています。実際の試験問題をもとにしたことは一度もなく、試験に何が出るかを知っているとも主張しません。すでに受験した方は、どうか試験の問題を私に送らないでください。認定資格の契約で共有が禁じられていますし、そもそも答えを暗記するのはアーキテクトになる方法として間違っています。
この章は、試験のData Modeling and Database Designセクション（試験の4分の1）の土台です。この章が扱うのは考え方で、次の章「Salesforceのデータアーキテクチャ」がプラットフォームでの作り方を扱います。ですから、オブジェクト、項目、リレーションについて問われることの多くには、両方の章が必要です。
この章の中で、試験で最も重要になりそうなポイントです。それぞれが試験目標と結びつき、教えている箇所へのリンクがあります。進めながらチェックしていきましょう。
DM-1：Salesforceのデータモデルを設計する手法の比較
- 概念データモデル、論理データモデル、物理データモデルの違いと、それぞれが何のためにあるのかを説明できる。（モデルをSalesforceにする）
- 要件の中から候補エンティティを見つけ、仕事をしている人とデータとを区別できる。（名詞から候補エンティティが見えてくる）
- カラスの足記法を読み書きできる：1、多、そして任意か必須かを示す2つ目の記号。（線を読む、任意性も重要）
- 関係のカーディナリティを言える：1対1、1対多、多対多。（「1つか、多数か？」と問う）
- 多対多の関係はそれ自体のエンティティになり、Salesforceではたいてい2つの親を持つ連結オブジェクトになることを知っている。（関係はものになり得る）
- 関係に、上書きされる項目ではなく履歴（開始日と終了日を持つレコード）が必要になるのはいつかを知っている。（時間が関係を変える）
- よい一意のIDを選べ、自然キーや個人情報を含むものがなぜ危ういのかを知っている。（そして一意のIDの話をしなければならない）
- 自然キーと代理キーの違いと、一つのレコードが複数の外部識別子を持ち得ることを知っている。（自然キーと代理キー）
- 自動採番項目は読みやすい番号であって、レコードのSalesforce IDではないことを知っている。（関係は一意のIDに依存する）
- 第1・第2・第3正規形を適用でき、複数の値を持つ項目や、別のものについての事実を繰り返している項目を見抜ける。（1NF、2NF、3NFのシンプルな考え方）
- いつ意図的に非正規化するか（ユーザー、レポート、規模）と、そのコストを説明できる。（第3正規形まで設計し、それから戻す）
- 値のリストについて、選択リストとオブジェクトへの参照関係のどちらにするかを決められる。（参照関係か、選択リストか？）
- カスタムレポートタイプで使えるオブジェクトの関係は最大4つであることと、それが深いモデルにとってなぜ重要かを知っている。（参照関係か、選択リストか？）
- 主従関係が合うとき（子が親を付け替えられることがない）と、参照関係のほうが安全なときを、一つの親に1万件を超える子を持たせないというSalesforceのガイダンスも含めて知っている。（関係はプラットフォーム上の判断になる）
- できる限りポリモーフィックな関係を避ける理由を知っている。（関係はプラットフォーム上の判断になる）
- ビジネスエンティティが自動的にカスタムオブジェクトになるわけではなく、標準オブジェクト、項目、設定、あるいはSalesforceの外にあるデータにもなり得ることを知っている。（ビジネスエンティティが自動的にカスタムオブジェクトになるわけではない）
試験の先へ
Section titled “試験の先へ ”試験は床であって天井ではありません。ここに挙げるのは、問題で問われるかどうかにかかわらず、アーキテクトに必要なこの章の習慣です。
- Salesforceのことは少し忘れる。 取引先や取引先責任者に対応づける前に、ビジネスをモデリングしましょう。
- 2つのものを隠している言葉に耳を澄ませる。 Steve Truckingでは、「顧客」は小売パートナーと受取人でした。
- モデルは会話の一部である。 最初のモデルは正しいためにあるのではなく、どこが間違っているかを教えてくれるためにあります。
- 線に名前を付ける。 同じ箱を持つ2つのモデルが、違うことを意味している場合があります。
- すべての関係について**「今か、時間を通じてか？」と問う。**
- 一意、変わらない、意味を持たない、決して個人情報ではない。
- 事実をそれが属する場所に置く。 それから意図的に戻し、その理由を書き残す。
- 非正規化は複雑さを取り除かない。移動させる。 誰が真実を所有しているかを知りましょう。
- 一つの真実の源、たくさんの形： 画面、レポート、ウェアハウス、そしてAI。
- 設定画面から設計しない。 新規カスタムオブジェクトをクリックする前に、モデルを描きましょう。
- 物理的な判断のすべてを、ビジネスが必要とする何かまでさかのぼる。
覚えておきたい用語
Section titled “覚えておきたい用語 ”| 用語 | ひとことで |
|---|---|
| エンティティ | ビジネスが気にかけ、データを持っているもの |
| 候補エンティティ | 問いを立ててみればエンティティになるかもしれない名詞 |
| 属性 | エンティティを記述する事実 |
| 関係 | 2つのエンティティがどうつながっているか。ビジネスの言葉で名前を付ける |
| カーディナリティ | 一方のいくつが、もう一方のいくつと関係するか |
| 任意性 | その関係が必須か、ゼロもあり得るか |
| カラスの足 | 線の端で「多」を示す記号 |
| 連結オブジェクト | Salesforceで多対多の関係を作る方法。両方の親の子になる |
| 概念モデル | ビジネスに何が存在し、どう関係しているか。Salesforceは出てこない |
| 論理モデル | データ：属性、一意のID、関係。まだプラットフォームに縛られない |
| 物理モデル | プラットフォームでどう作るか：オブジェクト、項目、リレーションの種類 |
| 自然キー | トラックのVINのように、ビジネスにすでに存在する識別子 |
| 代理キー | レコードを識別するためだけに作られた識別子 |
| 外部識別子 | 同じレコードに対する別のシステムのID。保持して対応づける |
| 正規化（1NF、2NF、3NF） | それぞれの事実を属する場所に置くこと：1項目に1つの値、キー全体についての事実、ほかの事実についての事実は置かない |
| 非正規化 | 説明できる理由のために、意図的にデータをコピーしたりフラットにしたりすること |
| 更新時異状 | 同じ事実が多くの場所に保存され、一度の変更で一部のコピーが誤ったまま残ること |
理解度チェック
Section titled “理解度チェック ”コースと同じスタイルの短いシナリオです。開く前に自分の答えを決めましょう。
1. ビジネスから、クルーがトラックを運転すると聞きました。6週間後、ある日にトラック117を使っていたのはどのクルーかと尋ねられます。モデルには何があるべきだったでしょうか？
クルー割り当てです。クルーとトラックの関係を、開始日、終了日、ルートを持つそれ自体のレコードにします。クルーとトラックは時間を通じて多対多であり、ビジネスはその履歴を気にしています。トラックの項目にしていたら上書きされていたでしょう。時間が関係を変えるを読み直しましょう。
2. あるチームが、「一意だから」という理由で、受取人の電話番号を一意のIDに使うことを提案しています。どう答えますか？
テストに不合格です。電話番号は変わり、共有されるので、変わらないものでも確実に一意なものでもありません。そして個人情報であり、そのレコードにつながるすべてのシステムにコピーされてしまいます。意味を持たない生成IDを使い、電話番号は属性として持っておきましょう。そして一意のIDの話をしなければならないを読み直しましょう。
3. 配送に品目1、品目2、品目3の項目があります。品目が4つある配送が届きました。本当の問題は何で、どう直しますか？
モデルが繰り返しの構造を項目の中に隠していました（第1正規形の問題）。直し方は品目4の項目を作ることではなく、配送の子である配送品目エンティティを作り、すべての品目をレコードにすることです。第1正規形を読み直しましょう。
4. すべての配送に物流センターの責任者の名前が保存されています。責任者が替わりました。何が間違っていたのでしょうか？
別のもの（物流センター）についての事実が配送に保存されていました。第3正規形の問題で、今では何百ものレコードにまたがる更新時異状になっています。責任者は物流センターに属し、配送は物流センターを指します。第3正規形を読み直しましょう。
5. 停車地の種類（配送のみ、設置付き、引き取り付き）には所要時間、クルーのスキル、チェックリストが必要です。選択リストとオブジェクトのどちらにしますか？
オブジェクトです。情報の列が2つ以上あり、ビジネスが管理し、独自のスケジュールで変わります。配送のステータスは短く安定したラベルのリストなので、選択リストのままです。参照関係か、選択リストか？を読み直しましょう。
6. パートナーは地域別の時間通り配送のスコアカードを求めていて、地域は物流センターにあります。あなたは地域を各配送にコピーします。何を決めなければなりませんか？
誰が真実を所有するか、コピーをどう同期させるか、そして過去の配送は、配送が行われた時点で正しかった地域を保つのか、物流センターが移ったらそれに従うのか。非正規化は複雑さを移動させただけで、取り除いてはいません。レポートが勝つこともあるを読み直しましょう。
7. 「おすわり」のような芸は、何十万匹ものペットに結びつく可能性があります。ペットの芸から芸へは主従関係と参照関係のどちらにしますか？
参照関係です。Salesforceのガイダンスは一つの親に10,000件までの子で、人気の芸はそれを超えてしまいます。主従関係が合うのはペットの芸からペットへのほうです。ペットの芸は親を付け替えられることがなく、1匹のペットが覚えている芸は少ないからです。それに、主従関係があるからこそ、ペットは覚えた芸の数を積み上げ集計できます。おすわり、まて、モデルを読み直しましょう。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)、Salesforceヘルプ（英語、2026-09-25確認）：出題目標とその配分の公式一覧。受験を予約する前に、必ず最新版を確認しましょう。