すべての構造は約束である
ほかに 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章、第1部：データアーキテクトになる。前へ：意味のあるデータモデリング。
どのクラスでも尋ねる質問があります。「Salesforceの仕事をしている」と言う人がいたら、製品オブジェクトのAPI参照名は何でしょう？
Product2です。これが私の最初のリトマス試験です。どこかの時点でSalesforceは製品オブジェクトを作り、うまくいかないことに気づき、それを置き去りにしなければなりませんでした。単に取り去ることはできなかったので、Product2を追加したのです。Salesforceでさえ、自分の古い構造と付き合い続けています。
Salesforceはまた、自分自身に成長の余地を与えました。標準オブジェクトには接頭辞も接尾辞もなく、組織をカスタマイズする私たちは、その領域を決して使えません。だからSalesforceはオブジェクトを追加し続けても、私たちが作るものと衝突することがないのです。
ここに教訓があります。オブジェクトを作るのは10分です。それと付き合うのは何年もです。追加するオブジェクトや項目の一つひとつが約束です。ストレージを使います。制限がつきまといます。設計したかどうかにかかわらず、共有モデルを持ちます。それに触れる人全員にライセンスが必要です。そして今ではAIもそれを読むので、どう名付け、どう説明するかが、エージェントがあなたのデータについて何を理解するかを決めます。足すのは簡単。取り去るのは難しいのです。
この章は、Salesforceの構成要素を判断に変えていきます。
画像はAIで生成しました。
構造をひと目で
Section titled “構造をひと目で ”Salesforceにはデータを保持する場所が6つあります。最初の仕事はそれらがすべて存在すると知ることなので、私はこれを1枚のスライドにまとめています。
| 構造 | 何のためのものか | 注意点 |
|---|---|---|
| 標準オブジェクト | Salesforce自身のモデル：取引先、取引先責任者、商談、ケース、納入商品など | 本来の目的で使わないと、逆らってくる |
| カスタムオブジェクト | あなた自身のビジネスデータ | 作るのは簡単、引退させるのは難しい |
| 外部オブジェクト | 別のシステムにあるデータを、Salesforceで表示する | 触れるたびにコールアウトが発生する |
| Big Object | 保持しなければならないが、めったに開かない膨大なボリューム | 標準のUIもレポートもない。インデックスを通じてクエリする |
| ファイル | ドキュメント、写真、その他のコンテンツ | ファイルストレージがすぐに膨らむ |
| 添付ファイル | ファイルを保存する古い方法 | 従来の仕組み。ファイルを使う |
どれかを選ぶことは、その一部にすぎません。構造より前に、そもそもデータをどこに置くべきかという問いがあります。コア上か、すでにある場所で参照するか、アーカイブするか。
この章の道筋
Section titled “この章の道筋 ”この章は大きいので、10のパートに分かれています。それぞれ単独でも読めます。第2章ではモデルがどうあるべきかを決めました。ここでは、それがSalesforceの上でどう存在すべきかを決めます。
- Salesforceのデータプラットフォーム：データベース以上のもの。 Salesforceは何が違うのか、そしてなぜプラットフォームには形があるのか。
- 母船を見よ：標準データモデル。 Salesforceがすでに作ってあるセールスとサービスのモデル、ファイル、ストレージ、そして個人取引先。
- 自分で作る：カスタムオブジェクト。 「カスタムオブジェクトの新規作成」画面が決めること、自分では作っていない項目、そしてどんなAPI参照名でも読み解く方法：標準、カスタム、管理パッケージ。
- このデータはどこにあるのか？ コア上か、参照か、アーカイブか。オブジェクトを作る前に決める。
- 正しいオブジェクトを選ぶ。 きれいに合うかのテスト、標準オブジェクトが持ち込む荷物、個人取引先、そして人が何を使えるかを決めるライセンス。
- 項目もアーキテクチャである。 データ型を一つずつ、人を驚かせる振る舞い、そしてすべての項目に説明を付ける理由。
- リレーションには結果が伴う。 参照関係か主従関係か、3階層の深さと2つの親の幅、論理的な連結オブジェクトとSalesforceの連結オブジェクト、そして痛い目を見る制限。
- 所有とライフサイクル。 誰がレコードを所有するか、所有がアクセスになる共有テーブル、そしてレコードの生涯で何が起きるか。
- データの一貫性を保つ。 一貫性のはしご：どの層にもコストがあり、新しいルールを満たすために履歴を「直す」ことは決してしない。
- Salesforceの物理モデルを設計する。 Steve Truckingの一部分を、論理モデルからSalesforceまで、一歩ずつ組み立てながら、考えた筋道とともに。
読み終えたら、章の学習ガイドで理解度を確認しましょう。試験のためのチェックリスト、試験の先にある習慣、覚えておきたい用語、そしていくつかの問いがあります。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- Salesforceがすでにモデル化しているもの。 何かを発明する前に：母船を見よ。
- それぞれの種類のデータをどこに置くか。 コア上か、参照か、アーカイブか。構造を選ぶ前に。
- どの構造に保持するか。 それぞれが何を手放すのかを知った上で。
- オブジェクトどうしがどう関係し、誰がレコードを所有するか。 そしてそれがアクセスと規模にとって何を意味するか。
- モデルがどのライセンスに依存するか。 オブジェクトを設計した後ではなく、前に確認する。
- データの一貫性をどう保つか。 そして一貫性の層それぞれのコスト。
試験の先へ： AIの支援による構築では、オブジェクトや項目を数分で作れます。足すことがほぼ無料になると、「すべての構造は約束である」ことの重要性は下がるのではなく、上がります。各モジュールの最後で、その判断についてAIが何を変えるかを扱います。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab)、Salesforceヘルプ（英語）
- Standard User Licenses (opens in a new tab)、Salesforceヘルプ（英語）
次へ： 企業のデータを理解する