実用的な Salesforce アーキテクチャ

第3章. プラットフォーム・データの概念

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

アーキテクトとして、我々はデータモデルの形と、データモデルとの対話方法を理解する必要がある。成功する企業システムは、効率を最大化し、抵抗を最小化することで機能する。抵抗とは、容易さの反対と定義することができる。維持するために余分な努力やリソースを必要とするものは、抵抗を生む。

それぞれのプラットフォームは、異なる方法で異なることを行う。異なるプラットフォームでソリューションを作成する場合、それぞれのデータモデルをどれだけ簡単に共有・連携できるかを理解することが重要だ。例えば、Salesforceは単一データレコードの更新を迅速かつ簡単に処理できる。単一データレコードの更新を迅速かつ簡単に実行できる他のシステムとも連携する必要がある場合、それらのシステムはほとんど抵抗なく連携できることが期待できる。

一方、他のシステムと比較すると、Salesforceは大量のデータレコードを伴う更新はそれほど高速ではない。大規模なレコード転送や更新を Salesforce よりも高速にネイティブ処理できるシステムと統合したい場合は、抵抗がある。高性能データストアのような中間システムを追加する必要があるかもしれない。あるいは、処理を完了するのに必要な余分な時間を管理するために、カスタムのinboundまたはoutbound処理コンポーネントを構築することもできる。この追加インフラやコードが抵抗となる。もう一つの例は、複雑な階層や深い階層を扱うことだ。Salesforceは、他のオブジェクトとの複雑な結合を必要とするリレーションシップの表示を限定的にしかサポートしていない。Salesforceでは、特にレポート作成において、レポート要件をサポートするためにデータを平坦化することは、かなり一般的な回避策である。階層化されたデータを個々のレコードにコピーすることで、レポートを作成し、他のオブジェクトとのリレーションシップを含めることができる。他のシステムにはこのような癖や制限がなく、まったく異なる方法で階層を保存することができる。異なる癖を持つシステム間で階層を共有するには、より多くの作業が必要になる。これも抵抗の一形態である。

アーキテクトは、抵抗を予測し、効率性を活用したソリューションを設計する。Salesforceがより優れたスケールをサポートする機能を構築し、獲得するにつれて、あなたの仕事の一部は、より小さく、より安く、よりシンプルなソリューションが適合しなくなる「転換点」を特定することである。

この章では、まず行レベルで最も重要なSalesforceデータの概念について説明し、その後、より概念的なI/Oレベルおよびパターンレベルへとステップアップしていく。また、Salesforce (アプリケーション) のすべてのデータが Web サービス API 経由でのみアクセス可能であることの意味についても説明する。Salesforce の内部でデータがどのように構成されているかについて説明した後、外部リレーションシップとデータソースについて説明する。

RDBMSの基本的な技術アーキテクチャ

以下の概念とコンポーネントは、多くのリレーショナルデータベース管理システム （RDBMS）に共通するものである。これらの中にはユーザや開発者が対話できるように公開されていないものもあるが、それでも重要な役割を担っている： ...