2章コアアーキテクチャの概念-データ-

概要

従来のRDBMSとSalesforceの違い
データガバナンスを理解する
データセキュリティを理解する
データ規制コンプライアンス
データカテゴリの調査
データウェアハウスとデータレイクの性質
適切なドキュメント管理システムの選択
データアーキテクチャの概念を理解する
データモデルの設計と文書化
データベース関係の使用

ポイント

アーキテクトが習得する必要のある主要な領域のひとつがデータである
データの入力、利用に際して様々な考慮事項が存在する
企業活動を維持するための体制やルールづくりが重要である
アーキテクトはデータに関する規制を理解し、規制に抵触しないための提案を行う必要がある
アーキテクトは、要件に沿って正規化と非正規化やオブジェクト間のリレーションを設計・文書化する

詳細

従来のRDBMSとSalesforceの違い

RDBMS(Relational Data Base Management System)のデータは複数の関連するテーブルに分割される
各テーブルの各行には主キーと呼ばれる一意の識別子がある
関連している主キーを外部キーで参照することによってテーブルをリンクできる
データにはSQLを使用してアクセスする
リレーショナルデータベーストランザクションは以下の4つの特性(ACID)で定義される
リレーショナルデータベースは、複雑な操作やデータ分析タスクに最適である
一貫性を重視し堅固な構造を提供するように設計されている

原子性（Atomic）
トランザクションをアトミック単位として扱うこと
すべてのタスクが成功する必要がある
成功しない場合はロールバックされる
トランザクションが部分的に完了した状態ではならない
一貫性（Consistent）
特定のトランザクションの前にデータが一定の状態の場合、トランザクションが実行されたらその状態を維持する必要がある
データベースの状態はトランザクション全体を通じて一貫している必要がある
独立性（Isolated）
トランザクションは個別であるため、それらの間に依存関係や共有データがあってはならない
これには複数のトランザクションが並行して実行されている場合に当てはまる
他のトランザクションに影響を与えるトランザクションはない
耐久性（Durable）
データは永続的に保持される
トランザクションがデータベース内のデータを更新してコミットすると、データベースは変更されたデータを保持することが期待される

インターネットが普及しだし、Webアプリケーションが必ずしも構造化されているとは限らず、
硬固な構造に適合させることが困難なデータを生成し始めたため新たな課題が発生した
これにより非リレーショナルデータベースが登場した
非リレーショナルデータベースは3つの特性（BASE）を持っている

基本的に利用可能（Basically Available）
システムは障害が発生した場合でも利用可能である
ソフト状態（Soft state）
結果整合性アクティビティのために、システム内のデータの状態が変化する可能性がある
結果整合性（Eventual consistency）
整合性は保証されないが、ある時点でデータは整合性のある状態となる

非リレーショナルデータベースは非常にスケーラブルであり、一貫性より可用性を重視する
Salesforceソリューション設計で高可用性でスケーラブルなデータベースシステムを必要とする課題に直面する場合がある
HerokuはMongoDBやCouchDBなどのNoSQLデータベースのいくつかをアドオンとしてサポートしている
NoSQLのユースケース

頻繁に書き込まれるが、めったに読み取られない統計データ
ビッグデータ（長年にわたる多くの国の統計など）
バイナリアセット（PDFまたはMP3ファイルなど）
ユーザーのブラウザに直接提供できるデータストアにストレージを提供する必要がある
一時的/一時的なデータ
ダウンタイムが重要な高可用性アプリ
非常に多くのトランザクションを処理する必要がある高スケーラビリティのアプリ

IoTデータなどSalesforceへ大量のデータを受信するケースではHerokuConnectを介したソリューションが適している

Salesforceは通常のRDBMSとは少し異なる
組織IDを用いてテナントが分離されている
RDBMS設計では最適ではないとみなされるがSalesforceの世界では問題ないいくつかの概念がある

自己参照
500の列を持つこと
非正規化された集計オブジェクトを作成する場合には許容される
Salesforceフィールドは型を認識する
チェックボックスフィールドへ番号を設定することはできない
また、これをオフにすることはできない
データ操作にはSOQL（Salsforce Object Query Language）という独自のクエリ言語を用いる
データストレージに注意する必要がある
オブジェクトのサイズが急増することによってレポートなどの機能のパフォーマンスが低下しないよう注意が必要である
堅固なデータアクセス制御モデル
特定のユーザがアクセスできるオブジェクトとフィールドを記録している

データガバナンスを理解する

企業は通常、データの使いやすさ、可用性、セキュリティ、整合性などのトピックに重点を置いている
これには、データの品質が常に高水準であることを保証するデータスチュワードシップや、データへのアクセスを保証するその他のアクティビティなど、データライフサイクルのさまざまな段階で従う必要のある必要なプロセスが含まれている

データガバナンスの目的

データ主導の意思決定における一貫性を信頼性を高める
データサイロを分解する
適切なデータが適切な目的に使用されていることを確認する
データエラーのリスク回避や誤用を防ぐ
規則要件に関連するリスクを減らす
データセキュリティを継続して監視・改善し、データ配布ポリシーの要件を定義・検証する
データの現金化を有効にする
説明責任を定義することで情報の質を高める
高品質のデータに基づいて、最高の顧客中心のユーザージャーニーを実現する

データガバナンス機関は次のアーティファクトを作成して維持する

データのマッピングと分類
企業のデータ資産を文書化する
ビジネス用語集
組織で使用されるビジネス用語を定義する
データカタログ
システム全体からメタデータを収集することで作成される
これらを使用して、利用可能なデータ資産の台帳を作成するために使用される

適切に設計されたデータガバナンスプログラムには、統治機関として機能するチームとデータスチュワードのグループが含まれる
彼らは協力して、データを管理し、計画された活動と手順を実装および実行するために必要な標準とポリシーを作成する

データスチュワード

企業内の役割であり、組織のデータガバナンスプロセスを維持および使用して、データとメタデータの両方の可用性と品質を確保する責任を負っている人物である
データスチュワードは、特定のポリシーおよび/または規制上の義務に従って組織のデータを管理するために、ポリシー、ガイドライン、およびプロセスを利用する責任もある
データスチュワードとデータカストディアンは、いくつかの責任を共有する場合がある

データ管理者

企業内の役割であり、システムに入力されるデータの転送と保存を担当する人物である
データスチュワードは通常、データセットに保存される内容を担当し、データ管理者は環境やデータベース構造などの技術的な詳細を担当する
データ管理者は時々データベース管理者またはExtractTransformLoad（ETL）開発者とも呼ばれる

データセキュリティを理解する

データのセキュリティは企業の最大の懸念事項の1つである
データの漏洩や侵害などからデータを保護する必要がある

データ暗号化
データが最終データストアに保存されるときと、データが移動している時に暗号化を行う
転送中の暗号化
メッセージを送信する前に暗号化する宛先で復号化される
これは中間者攻撃による送信を傍受することからデータを保護する
保管時の暗号化
暗号化されたデータを保存する
これにより、特定の暗号化キーにアクセスすることなく、復号化されたバージョンを読み取って表示することができなくなる
Salesforce Shiled
保存データを暗号化するための暗号化ソリューションを提供する
ファイルシステム、データベース、および検索インデックスファイルに適用される

ソリューションの一部としてSalesforce Shieldを使用することを計画している場合は、システムランドスケープアーキテクチャ図で明示する必要がある

データの復元
バックアップ/リストア・ソリューションは、データをリストアまたはリカバリする必要がある場合に、データを安全な場所/ソースで確実に使用できるようにするために使用される
ほとんどの業界では、運用データのバックアップを保持することが不可欠である
通常、データの復元は、部分データ、参照データ、親子レコードとリレーションシップの復元などの追加の課題があるため、バックアップよりも困難である
注意）
Salesforceは米国時間2020年7月31日、「Data Recovery as a paid feature (有料機能としてのデータ復旧) 」を廃止し、サービスとしての提供を終了すると発表した

AppExchange製品など、データをバックアップおよび復元するために使用できるツールがいくつかある
ETLツールの実装によるカスタムメイドのソリューションも選択肢のひとつである
アーキテクトは、利用可能なさまざまなオプションと、考えられる長所と短所について、関係者に説明できることが求められる
レビューボードでは、技術的に可能な最善の解決策を考え出すことが求められる
シナリオに明記されていない限り、コストの考慮は不要である

データ・マスキング

データの難読化は主に、個人を特定できる情報 (PII) または機密性の高い商用データまたは個人データとして分類されるデータを保護するために行われる
データの難読化には、仮名化と匿名化という2つの一般的な手法がある
どちらを選択するかは、マスクされたデータに関連するリスクの程度と、データの処理方法によって異なる

匿名化
何らかの再識別が可能だが、匿名データを再識別することはできない
データを匿名化する一般的な方法は、データをスクランブルすること
これは、場合によっては元に戻すことができるプロセス
たとえば、ロンドンはndoolnになる可能性がある
このマスキング手法では、データの一部を静的文字またはランダム文字で非表示にできる
データ仮名化
データ値の近似値を使用して、人物を識別できないようにしたり、データの意味を廃止する

データ消去

特定のデータが他の値で上書きされ、電子データが完全に破壊されて回復不可能になるソフトウェアベースのアクティビティである
データ削除とは異なる
データの削除はデータを回復可能な形式のままにすることができる
データ消去は永続的であり、機密性の高いデータにとって特に重要である
これらの用語の違いを理解して、関係者に最適な戦略を提案できるようにすることが重要である
暗号化されたデータは、暗号化キーを破棄するだけで永久に破棄/消去できる

データ規制コンプライアンス

収集される顧客データとビジネスデータの量が増加するにつれて、そのデータの使用を管理するルールを導入することが不可欠になってきた
アーキテクトは、完全に準拠したソリューションを設計するために、これらの規則を認識する必要がある
ソリューションがこれらの規制にどのように準拠しているかを関係者に説明できる必要がある

業界標準と政府の規制に基づいて、いくつかのデータ規制が実施されている
これらは、企業、個人、または政府のデータへの不正アクセスのリスクを軽減するために作成されている
Salesforceソリューションを設計する際に最近よく目にする規制には、次のようなものがある

一般データ保護規則 (GDPR)
英国版GDPR (UK-GDPR)
HIPAA (Health Insurance Portability and Accountability Act:医療保険の携行性と責任に関する法律) (HIPAA)
カリフォルニア州消費者プライバシー法 (CCPA)
2003年公正正確信用取引法 (FACTA)
個人情報の保護に関する法律 (APPI)
グラム・リーチ・ブライリー (GLB)
PCI DSS (Payment Card Industry Data Security Standard)
これらの規制を遵守しないと、民事および刑事責任に加えて、多額の罰金や企業の評判に対する公的損害が生じる可能性がある

Payment Card Industry Data Security Standard (PCIコンプライアンスとも呼ばれるPCI DSS)は、
クレジット・カード・プロバイダからのクレジット・カード情報の受入れ、処理、格納または送信などクレジット・カード情報に
関連する活動に関与するすべての企業に適用される情報セキュリティ標準である
Salesforce Billingは2012年にPCI Level 1に準拠し、それ以来毎年コンプライアンスを維持している

支払い方法の収集段階のすべての段階で、クレジットカード情報をSalesforceに保存しないことで、PCIへの準拠を維持する

決済カードの情報はトークン経由で決済処理者にのみ送信され、Salesforce内に保存されることはない
これらのトークンは、顧客、支払いカード、マーチャント、支払い処理者ごとに一意である
トークンが送信されると、支払プロセッサは、格納されている実際の個人アカウント番号にリンクできまる
Salesforceはトークンを使用することで、カード自体の実際の詳細を保存することなく、顧客の決済カードの情報を保存できる
トークンが悪人の手に渡ったとしても、元のマーチャントと支払い処理者によって使用されている場合にのみ機能するため、役に立たない

PCIコンプライアンスを維持しながらSalesforceに保存できる情報には、次のようなデータが含まれる
名刺の名前
クレジットカード番号の下4桁
カードタイプ
トークン
失効年月

オンライン支払メカニズムのしくみと、ソリューションに適したものを選択する方法を理解することが重要である
審査委員会でPCI非準拠のソリューションを提案すると、望ましくない他の多くの議論につながる可能性がある
規制やコンプライアンスに関する十分な知識と理解を示さないと、試験の失敗につながる可能性がある

オンライン支払いの場合、支払いゲートウェイと統合するには、一般に2つの主な方法があることを理解しておく必要がある
外部でホストされるチェックアウトページを利用する方法が、PCI準拠を維持するためにのメンテナンスプロセスが簡単になるため
はるかに簡単である
独自のチェックアウトアプローチを使用する明確な必要がない場合は、外部でホストされるページアプローチを提案する方が
常に安全である

支払いゲートウェイによって提供およびホストされる外部でホストされるチェックアウトページを利用する

このアウトアプローチは、チェックアウトページは、支払プロバイダーによって提供される別のwebサイトでホストされる
顧客がWebサイトのチェックアウトボタンをクリックすると、別のドメイン名でホストされている支払いページに
リダイレクトされる
注文情報とカートの合計金額は通常、支払いページに表示される

お客様はこのページにカードの詳細を入力し、送信ボタンをクリックする
カードの詳細は、外部の支払いWebサイトにのみ入力されることに注意する
ページとフォームは、そのような詳細をキャプチャするために使用されることはない
支払いが成功すると、顧客はWebサイトのランディングページにリダイレクトされ、確認/取引コードもWebサイトに戻される

外部ホスト型チェックアウトアプローチの利点

セキュリティの強化
支払取引に関与するすべての追加当事者は、データ侵害に関連するリスクを増加させる
支払いの詳細は支払いプロバイダー/処理者によって収集されるため、お客様のWebサイトはトランザクションの一部とは
見なされないため、このアプローチの全体的なセキュリティレベルは高くなる
責任の軽減
支払い処理は支払いプロバイダーによって行われる。機密情報を収集していないため、マーチャントとしての責任が軽減される
お客様の安心
お客様は、PayPalなど、既に信頼しているWebサイト/ドメインに支払いの詳細を提供する方が安心である
これは特に、小規模な販売業者や新しいブランドに当てはまる
支払い方法の柔軟性
通常、ホストされたチェックアウトページでは、複数の支払い方法から選択できる
このページは、支払いプロバイダーがより多くの支払い方法を含むように引き続き更新される
コードを変更する必要がなくなる
簡略化されたセットアップ
この方法は、セットアップとメンテナンスが最も簡単である
カスタマイズの制限
支払いページは別のWebサイトでホストされるが、多くの支払いプロバイダーでは、ロゴ、ヘッダーとフッター、配色の設定など、
カスタマイズのレベルが制限されている

独自のWebサイト(たとえば、Salesforceコミュニティ)でホストされるチェックアウトページを作成する

このアプローチでは、顧客は自分のWebサイトでホストされているページに支払いの詳細を
提供する(たとえば、Salesforceコミュニティ)
このページの見た目や操作はユーザーが完全に制御できるが、必要なすべての機能、検証およびセキュリティ対策の実装も
ユーザーが担当する

オンサイトチェックアウトアプローチの利点

完全にシームレス
このアプローチの最も重要な利点である
顧客はどこにもリダイレクトされない
支払いプロセス全体が、顧客に提供している旅と経験の一部のように感じられる
ワンクリック購入
これは、Amazonなどの大手マーチャントが行っていることに似ている
顧客の支払詳細を収集して、顧客のアカウントに添付できるようにする
これにより、ワンクリック機能の導入が可能になる
カスタマイズ
支払回収ページは任意の方法で作成できる
Webサイトの見た目や操作に合わせたスタイルを設定できる
チェックアウトプロセスの一部として追加の詳細を収集するなど、UIのスタイル設定を超えたカスタマイズが可能である

データカテゴリの調査

参照データとマスターデータは、アーキテクトがほとんどのプロジェクトで扱う2つの一般的なデータカテゴリである
このセクションでは、これらに加えてトランザクションデータ、レポートデータ、メタデータ、ビッグデータ、
および非構造化データの特性についても説明する
これらのさまざまなデータカテゴリをより深く理解することは、データガバナンスを含む全体的なデータ戦略を
構築するのに役立つ

トランザクションデータ

通常のビジネストランザクションによって生成される
企業内で最も頻繁に変更されるデータであり、ビジネスイベントを説明する

トランザクションデータのイベント例

お客様への販売
回収済支払
作成された見積
顧客への出荷品目
トランザクションデータは通常、CRM、ERM、HRアプリケーションなどの運用システムによって生成および管理される

マスタデータとマスタデータ管理

企業は通常、日常のトランザクションをサポートする主要なビジネス情報を提供する
このようなデータは通常、顧客、製品、場所などを記述する
このようなデータはマスターデータと呼ばれ、一般にパーティ(従業員、顧客、サプライヤーなど)、場所(サイト、リージョンなど)、
モノ(製品、資産、車両など)と呼ばれる
通常のビジネスオペレーションでは、通常のビジネスプロセスの一環としてマスタデータを作成/作成・使用する
ただし、運用アプリケーションは通常、マスターデータのアプリケーション固有のユースケース向けに設計されている
これにより、マスターデータのエンタープライズ要件全体との不整合が発生する可能性がある
その結果、次のことが起こる

マスターデータの品質が低い
重複データと散在データ
真に管理されたデータの不足
マスターデータ管理 (MDM) は、ITとビジネスが連携して、特定のツールとテクノロジを使用してエンタープライズ
マスターデータの正確性と統一性を確保する分野を説明するために広く使用される概念である
真実の1つのバージョンを維持することは、ほとんどの組織の最優先事項の1つである
MDMツールを使用すると、重複削除やデータの一括管理、誤ったデータが入力されないルールを組み込むことができる

MDM実装スタイル

一般的に使用されているのは次の3つである
これらの実装スタイルの主な違いは、データの処理方法と、MDMツール自体の役割 (データを制御するハブまたは他の
データストアとデータを同期するツール) である

レジストリスタイル
照合、クレンジングアルゴリズムを実行し、一致したレコードに一意のグローバル識別子を割り当てることで、さまざまな接続されたシステムでの重複を検出する
これは、関連するレコードを識別し、システム全体で特定のデータ資産の包括的な360ビューを構築するのに役立つ
この方法では、データはソース・システムに戻されない
マスターデータへの変更は、引き続きソースシステムで行われる
MDMツールは、ソースシステムが独自のデータ品質を管理できることを前提としている
特定のデータ資産の360ビューが必要な場合(例えば、顧客がそれを必要としている)、MDMツールは各参照システムを使用して、
一意のグローバル識別子を使用してリアルタイムで360ビューを構築する
通常、特定のデータセットに対して一意のグローバル識別子が引き続き有効であることを確認するための継続的なプロセスが
必要である
集計スタイル
このスタイルでは、通常、データは複数のソースから収集され、ハブに統合されて、1つの真実のバージョンが作成される
これはゴールデンレコードと呼ばれることもある
ゴールデンレコードはハブに一元的に格納され、最終的にレポートまたは参照にて使用される
ゴールデンレコードに対して行われた更新はすべてプッシュされ、元のソースに適用される
連結スタイルは、次の手順で行う
a) 特定のオブジェクトの同一または類似のレコードを識別する
これには、完全一致または部分一致アルゴリズムを使用できる
b) 自動的に統合されるレコードを決定する
c) 統合する前に、データスチュワードによる確認が必要なレコードを特定する

これらのプロセス中に、ツールは構成済みのフィールドの重みを使用する場合がある
通常、重みの高いフィールドは、最終的にゴールデンレコードを形成する属性を決定する際に、より重要な要素と見なされる

共存スタイル
このスタイルは、ゴールデンレコードを作成するという点で、連結スタイルに似ている
ただし、マスターデータの変更は、MDMハブまたはデータソースシステムで実行できる
この方法は、データを双方向に同期する複雑さのため、通常、統合スタイルよりも適用にコストがかかる

また、マッチングロジックが通常どのように機能するかを理解することも重要である
主に2つのマッチングメカニズムがある

部分一致
これは一般的に使用されるメカニズムだが、一致を識別するために必要な作業のために実行が遅くなる
転置、省略、切り捨て、スペルミス、発音の変化など、データ・パターンの可能な変化に基づく確率的決定が使用される
完全一致
このメカニズムは、レコード上のフィールドをターゲットレコードからの同一の一致と比較するため、高速になる

Salesforceアーキテクトとして、プラットフォームで利用可能なすぐに使用できるツールの機能と制限、および市場の
主要なMDMプレイヤー (特にAppExchangeアプリケーションを介してSalesforceと直接統合されているプレイヤー) によって
提供される機能について理解する必要がある

レビューボードのプレゼンテーションでは、実務と同様に利害関係者を指導し、彼らが持つさまざまな選択肢について
説明することが求められる
MDMツールを使用する必要があることを説明するだけでは不十分であり、推奨される製品名を具体的に指定する必要がある
また、提案するツールで採用されているMDM実装スタイルを理解する必要がある

参照データ
参照データは、他のデータを分類または分類するために使用される静的または緩やかに変化するデータである
参照データはマスターデータとは異なる
どちらもビジネスプロセスとトランザクションにコンテキストを提供するが、参照データは主に分類と分類に関するものであり、
マスタデータは主に事業者（例えば顧客）に関するものである
レポートデータ
レポートとビジネスインテリジェンスを容易にするために特定の方法で編成されたデータ
集計または非集計のいずれかの方法で運用レポートに使用されるデータは、このカテゴリに属する
レポートデータは、マスターデータ、参照データ、およびトランザクションデータを組み合わせることによって作成される
メタデータ
他のデータを記述するデータと呼ばれる
eXtensible Markup Language (XML) は、一般的に使用されているメタデータ形式である
例えば、コンピューターファイルのプロパティ (サイズ、種類、作成者、作成日) がある
Salesforceは、構造化されたメタデータを使用してほとんどの機能を記述できるため、メタデータを多用している
カスタムオブジェクト、ワークフロー、レポート構造、検証規則、ページレイアウト、およびその他の多くの機能はすべて、
Salesforceプラットフォームからメタデータとして抽出できる
これによりマージとデプロイのプロセスが自動化される
ビッグデータ
従来のデータベースやデータ処理アプリケーションで扱うには大きすぎる数億 (場合によっては数十億) の行を含むデータセット
企業は、AIに基づく意思決定や、パーソナライズされた顧客中心のサービスやジャーニーといったさまざまな目的にデータを
利用したいと考えている
ビッグデータを適切な方法で使用すれば、特定のビジネスの差別化要因になる

アーキテクトは、膨大な量と多様なデータ (非リレーショナルデータベースの場合が多い) とリレーショナルデータ (複雑な
ビジネスロジックを処理する場合) を管理するために必要なテクノロジを組み合わせて、クライアントを導く必要がある

非構造化データ
このデータには定義済みの構造がないため、構造化RDBMSに適合させることができない
ほとんどの場合、この種類のデータはテキストデータとして表示される
たとえば、PDFファイルはテキストマイニングにより非構造化文書から構造および関連データを抽出することができる

データウェアハウスとデータレイクの性質

データウェアハウス (DWまたはDWH)

1つ以上の異なるソースから統合された現在および履歴データの中央リポジトリ
DWH (エンタープライズデータウェアハウス (EDW) とも呼ばれる) は、データ分析とレポート作成に使用されるシステムである
DWHに格納されるデータは、運用システム (CRMシステムなど) を含む複数のシステムから取得される
データの品質を確保するために、DWHにアップロードする前に、一連のデータクレンジングアクティビティを行う場合がある

組み込みのETL機能を持つDWHツールもあれば、外部のサードパーティ製ツールに依存するDWHツールもある
Amazon Redshiftなど、一般的なデータウェアハウスソリューションの名前を理解しておく必要がある

データレイク

構造化されていない方法で格納されているデータのシステムまたはリポジトリ
データレイクは、すべてのソースからのあらゆる種類のデータを受け入れて格納する
構造化されたデータ、半構造化されたデータ、処理されたデータ、変換されたデータも、
データレイク(XMLデータやデータベースからのデータなど)に格納できる
収集されたデータは、レポート、視覚化、ビジネスインテリジェンス、機械学習、高度な分析に使用される
AWS Lake Formationなどの一般的なデータレイクソリューションの名前を理解しておく必要がある

また、どの解決策をどのような理由で提案すべきかを知る必要がある
履歴傾向レポート、詳細データ分析機能、および大量のデータに関するレポート機能を提供できるプラットフォームを
提供する必要がある場合は、DWHの方がユースケースに適している
Salesforceから抽出されたデータは、ほとんどが構造化形式であることに注意する

多くのレビューボードシナリオでは、プラットフォームデータをアーカイブする必要がある
機械学習や高度な分析などのタスクを容易にするために、構造化データと非構造化データを1つの場所に格納する
必要がある場合は、データレイクが適切なソリューションになる可能性がある

適切なドキュメント管理システムの選択

バージョン管理

包括的な監査証跡
ロックが組み込まれたドキュメントのチェックインおよびチェックアウト機能

Salesforceにもドキュメント管理の一部を提供する機能が組み込まれている
ファイル
ユーザーが電子ドキュメントをアップロードおよび保存できる
ファイルは非公開で保存することも、「Chatter」を使って他のユーザーと共有することもできる

Salesforce CRMコンテンツ

ユーザーはエンタープライズドキュメントを作成、複製、および開発できる
たとえば、プレゼンテーションやチラシなど
コンテンツを顧客やパートナーなどの他の内部または外部ユーザーと共有することもできる

ナレッジ

エンタープライズ向けのナレッジベース
ユーザーは、管理されたワークフローを使用して、ナレッジ記事を作成および管理し、公開できる
これにより、内部および外部ユーザー(例えば、それらをケースに取り付ける)は、これらのナレッジ記事を検索し、
さまざまな方法で使用できる
ナレッジ記事はライブラリに整理できるため、簡単に管理および共有できる

静的リソース

これらは主に、レコードに添付しなくてもフォルダに静的ファイルを格納するために使用される
これは、Visualforceページで静的リソース (ロゴなど) を参照する必要がある場合などに特に便利である

ほとんどの企業では、すでに何らかのドキュメント管理システムが導入されている可能性が高い
たとえば、Microsoft SharePoint、Box、Google Drive、One Driveなど
Salesforce UI内で外部ドキュメントにアクセスして管理するには、最初から作成するのではなく、これらのシステムと
統合する必要がある
そのためには、「Files Connect」という、Salesforceですぐに使える別のツールを使用することも可能である

データアーキテクチャの概念を理解する

データアーキテクトは、概念レベルの段階で、ビジネス知識、ビジネスプロセス、および運用を深く理解する必要がある
これにはデータフロー、ビジネスルール、および企業でのデータの使用方法または使用方法に関連する知識が含まれている
アーキテクトは、各ビジネスプロセスの背後にあるさまざまな分類法とデータフローも定義する
データ設計図は、堅牢で成功したデータアーキテクチャを構築するために不可欠である
多くの場合、このアクティビティは企業全体のレベルではなく、プロジェクトレベルで行われる

主要なデータエンティティと要素(アカウント、製品、注文など)
データエンティティの関係 (データ整合性要件やビジネスルールなどの詳細を含む)
最終顧客が期待する出力データ
必要なセキュリティポリシー
出力データを生成するために収集、変換および使用されるデータ
定義されたデータエンティティの所有権と、それらの収集および配布方法
論理レベルのデータアーキテクチャ設計
このデータアーキテクチャ設計は、データモデリングとも呼ばれる

この段階で、アーキテクトは処理するテクノロジの種類を検討し、使用するデータ形式を定義する
論理データモデル
ビジネス要件をテクノロジとデータベース構造に繋がる
データアーキテクトは、基盤となる各システムまたはデータベースの標準、機能、ベストプラクティス、および制限事項を考慮する必要がある
この段階で明確にデータフローを定義されなければならない
データ整合性の要件と命名規則
命名規則を定義し、関連する各データベースで一貫して使用する必要がある
特に、データが複数の基盤システムに存在する必要がある場合、運用データと参照データの整合性要件を検討する必要がある

データのアーカイブと保持のポリシー

初期の段階でデータのアーカイブおよび保存ポリシーに対処しないと、プロジェクト全体のコスト、システムパフォーマンスの
低下やデータの不整合の可能性に影響する

プライバシーおよびセキュリティ情報

概念設計では、機密と見なされるデータ要素を定義することが重視されるが、論理設計では機密情報が保護され、データが適切な
対象者にのみ表示されるようにするために、より詳細へと掘り下げる
また、データ・アーキテクトは、データ・レプリケーションに関連する戦略と、移行中と停止中の両方でレプリケートされた
データを保護する方法にも取り組む必要がある

データフローとパイプライン

この段階では、異なるシステムとデータベース間のデータフローの詳細を明確に示す必要がある
これらのフローは、概念レベルで定義されたフローと一致している必要があり、パイプライン中に必要なデータ変換や、
データの取り込みの頻度などの詳細を反映する必要がある

物理レベルのデータアーキテクチャ設計

このデータアーキテクチャ設計は、内部設計とも呼ばれる
この段階では、アーキテクトは基礎となるシステムまたはデータベースの実際の技術的側面に関心を持つ
ストレージデバイスにデータを格納する方法 (特定のフォルダー構造内など) を定義する
実際のプロジェクトの設計段階では論理モデル図に加え、実装段階では物理モデル図が必須である

ソリューションの完全なSalesforce物理データモデルをドキュメント化 (またはドキュメント化のアクティビティをリード)
する必要がある
対象のオブジェクトがどのように使われているかを明確に説明し、各統合フィールドのデータソースの完全な説明と、
関連するすべてのデータフローの明確な説明が必要である

データモデルの設計と文書化

データモデルは、ソリューションの基盤である
データモデルの設計を適切に行うには、データモデリングの主要な概念を理解する必要がある
これは、正規化と非正規化の比較から始まり、データベース設計のための標準的な3つの標準形式を確認し、最後に
データベーステーブル間の一般的なリレーションシップの種類と、それがSalesforceにどのように反映されるかを理解する

正規化と非正規化

正規化
データベース内のデータをその関係に基づいて効率的に配置するプロセスである
ディスク領域の浪費、クエリの低速化、作成、読み取り、更新、削除 (CRUD) 操作の実行にかかる処理時間の
増加など、データの冗長性を排除するために行う
冗長データはデータ不整合を増加させる可能性がある
たとえば、同じデータが複数の場所に保持され、そのうちの1つで更新される場合、変更が他のすべてのオカレンスに反映されるようにする必要がある
そうしないと、データの不整合が発生するリスクが生まれるからである
非正規化
正規化プロセスの逆と考えることができる
非正規化データセットでは冗長情報を意図的に使用する
非正規化はいくつかの目的で行われるが、主にクエリの実行と分析の実行中にパフォーマンスを向上させるために行われる

非正規化プロセスにより、テーブルの数が減り (ただし、より多くのストレージが消費される) 、複雑なテーブル結合が
簡素化されるため、複数のテーブルに存在するデータを照会する際のパフォーマンスが向上する
非正規化で採用されている概念は、すべてのデータを1つの場所に配置することによって、検索プロセスを簡略化できる

アカウントマネージャーとして、すべての顧客の住所を保存して、特定の期間にこれらの各住所に送信した出荷数を示す重要なレポートを生成できるようにしたいケース

このユーザーストーリーの焦点は分析/レポートである
Salesforceの標準レポート機能を考慮すると、アカウントとアカウントアドレスの詳細を2つの異なるテーブルに格納することは
理にかなっている
これにより、Salesforceが複数のテーブルからデータをクエリする追加プロセスをバックグラウンドで実行しているにもかかわらず、出荷レコードを適切な住所にすぐにリンクし、必要なレポートを最小限の労力で作成することもできる

正規化された形式のデータモデルの例

アカウントマネージャーとして、すべての顧客の住所を保存して、顧客レコードページとリストビューを見たときに連絡先住所をすばやく見つけられるようにしたいケース

ここでは、データの入力または表示中のユーザーエクスペリエンスに焦点を当てる
この場合、非正規化されたデータセットを使用することは理にかなっている
これらの非正規化フィールドは、リストビューやページレイアウトに簡単に追加でき、少ないクリック数で編集することもできる

次の図は、提案されたデータモデルと格納されているデータの例を示している

非正規化フォームのデータモデルの例

データベースリレーションの使用

正規化プロセスの目的の1つは、データの冗長性を取り除くことである
そのためには、テーブルを関連する複数のサブジェクトベースのテーブルに分割する必要がある
リレーションシップには、主に1対1、1対多、多対多の3種類がある

一対一リレーションシップ

この種類のリレーションシップでは、最初のテーブルの各レコードに、2番目のテーブルのリンクレコードが1つだけ含まれる
同様に、2番目のテーブルの各レコードには、1番目のテーブルの一致するレコードを1つだけ含めることができる
この関係では、テーブルの一方が他方の拡張と見なされる
この関係はあまり一般的ではないが、セキュリティ上の理由からデータを分割するなど、有効なケースもある

一対一のリレーションシップの図

1対多リレーションシップ

この一般的な種類のリレーションシップは、1つのテーブル (親) のレコードが別のテーブル (子) の複数のレコードに
関連付けられている場合に発生する
これには、複数の注文を行う顧客、複数の住所を持つアカウント、複数の注文明細項目を持つ注文など、多数の例がある
この関係を維持するには、主キーと外部キーと呼ばれるものを使用する必要がある
子テーブルでは、主IDはそのテーブル内の各レコードの一意の識別子になり、外部キーは親の主キーの一意の識別子を参照する
このタイプのリレーションシップは、Salesforceで参照フィールドまたは主従フィールドを使用して作成できる

一対多リレーションシップの図

多対多リレーションシップ

この種類のリレーションシップは、最初のテーブルの複数のレコードを2番目のテーブルの複数のレコードに関連付けることが
できる場合に発生する
学生とコースの例を考えてみる
各学生は複数のコースに参加でき、各コースには複数の学生が参加できる
2つのテーブル間に多対多リレーションシップを作成するには、ブリッジテーブルまたは接合テーブルと呼ばれる3番目の
テーブルを作成する必要がある
この多対多リレーションシップは、実質的に2つの1対多リレーションシップに分割される
ジャンクションテーブルのレコードは2つの外部キーの値を保持し、それぞれが2つのメイン・テーブルのレコードを指す
ジャンクションオブジェクトをSalesforceで作成するには、2つの主従フィールドまたは2つの参照フィールド(この場合、
ジャンクションというよりもブリッジと呼ばれることが多い)を持つカスタム・オブジェクトを作成する
どちらのアプローチも有効であり、それぞれ最適なユースケースがある

多対多リレーションシップの図