ブログ · 2023年9月14日 · Steve Simpson · データアーキテクチャ

Steve のデータモデリング：選択リストから無限の彼方へ

はじめに：

Steve のデータモデリングシリーズの、データモデリングについての新しい回へようこそ！このブログでは、選択リストの多彩な使い方を探り、より高度なデータモデリングの要件のために代替案を検討すべきシナリオについて話します。

選択リストを理解する

選択リストは、決まった値の集合が必要な項目に最適です。すっきりしたユーザー体験を提供しますが、いくつかの制約があります。

値を追加するには高い管理者権限が必要です。
新しい値は Sandbox を通じてリリースしなければなりません。

サードパーティの統合から来る値が Salesforce にあらかじめ追加されていないと、データ検証エラーが起きます。

選択リストの選択肢を探る

検討すべき選択リストの選択肢は次のとおりです。

選択肢1：グローバル値セット

これは Salesforce の標準の選択肢で、オブジェクトをまたいでリストを活用できます。

選択肢1、選択リストとグローバル値セット。利点：すっきりしたユーザー体験。欠点：管理者が値を追加しなければならない、変更は Sandbox へのリリースが必要、外部システムが問題を起こす、値に関連項目を持たせられない

グローバル値セットは、複数の場所で使う値に最適です。たとえば「パイプのサイズ」と「パイプの厚さ」の二つのグローバル値セットを用意し、ユーザーが値を選べるすっきりした UI を提供できます。

[caption id="" align=“alignnone” width=“1372”] 値セットの例 [/caption] [caption id="" align=“alignnone” width=“1814”] 値の例 [/caption] [caption id="" align=“alignnone” width=“676”] リストから選ぶ [/caption]

選択肢2：テキスト項目

検証のない、ただのテキスト項目です。

選択肢2、テキスト項目。利点：どんな値でも受け付ける。欠点：データ検証がなく、ユーザー体験が悪い

データの値が統合を通じて送られてくるなら、テキスト項目を検討してもいいかもしれません。ただしこの方法では検証が失われ、ユーザーがどんなデータでも入力できるので、不整合につながるおそれがあります。

Salesforce 上で項目が参照のみで、値を表示するだけなら、これも選択肢になります。

[caption id="" align=“alignnone” width=“678”] 検証なし [/caption]

選択肢3：共有の参照オブジェクト

選択肢3、レコードタイプを持つ共有の参照オブジェクトと、レコードタイプで絞り込んだ参照。利点：データを動的に追加でき、関連項目もいくらか持てる。欠点：Sandbox でのデータロードが必要で、元のオブジェクトは値ではなくキーを持つ

複数のレコードタイプを持つ共有の参照オブジェクトは、データロードに使えます。この方法では主オブジェクトに二つの参照項目を作り、実際の値ではなく参照オブジェクトにリンクします。管理者権限なしで新しい値を動的に追加することもでき、柔軟性が高まります。

[caption id="" align=“alignnone” width=“1462”] レコードタイプを使う [/caption] [caption id="" align=“alignnone” width=“1700”] 絞り込み条件付きの参照を使う [/caption] [caption id="" align=“alignnone” width=“1434”] 値を追加する [/caption] [caption id="" align=“alignnone” width=“658”] 値を選ぶときの見え方。並び順が正しくなく、最初の読み込みではすべての値が表示されないので、ユーザーは検索する必要がある。また、ユーザーがその場でレコードを増やさないよう、プロファイルや権限セットから「作成」を外すこと。 [/caption]

セクション3：高度な選択肢

より高度なシナリオでは、次の選択肢を検討してください。

選択肢4：参照オブジェクトを使うカスタム画面

選択肢4、参照オブジェクトとテキスト項目に、参照オブジェクトから選択リストの値を読み取る Lightning Web コンポーネントを組み合わせる。利点：データを動的に追加でき、元のオブジェクトが値を保持する。欠点：LWC の開発とカスタムページが必要

編集画面にカスタムの Lightning Web コンポーネント（LWC）を使っているなら、参照オブジェクトを使って値を読み取って表示し、参照ではなく実際の値を保存できます。

選択肢5：独立したオブジェクト

選択肢5、リストごとに一つの独立した参照オブジェクト。利点：データを動的に追加でき、データモデルがすっきりし、関連項目を多く持てる。欠点：Sandbox でのデータロード、値ではなくキー、オブジェクトが多くなる

参照の値の重要性が増してきたら、それぞれに独立したオブジェクトを作り、別々の参照項目を作ることを検討してください。この方法なら動的にデータを追加でき、データモデルをすっきり保ち、各オブジェクトに追加の関連項目を持たせられます。

実践的な例

各選択肢を示す実践的な例です。

標準の選択リスト： 決まった値で、すっきりした UI を提供します。

検証なしのテキスト項目： 柔軟ですが、データ検証はありません。

参照オブジェクトへの参照： 同じオブジェクトをレコードタイプで絞り込んで使い、柔軟性を得ます。

独立したオブジェクト： 参照ごとに別のオブジェクトを使い、すっきりして柔軟なデータモデルを実現します。

まとめ

選択リストとその代替案の細かな違いを理解することは、効果的なデータモデリングに欠かせません。標準の選択リストから独立したオブジェクトまで、どの選択肢にも特定のデータモデリングのニーズに応える固有の利点があります。

またお越しください！

さらなる知見やヒントは、この www.SteveTechArc.com と YouTube チャンネル @SteveTechArc (opens in a new tab) で。チャンネル登録して、私たちと一緒にデータモデリングの腕を磨きましょう！

アーキテクト仲間やアーキテクトを目指す人たちと面白い考えを共有して、世界を変える手助けを！

文字起こしには AI を活用

STA 2.2