信頼できる唯一の情報源
信頼できる唯一の情報源 (Single Source of Truth; SSOT) とは、情報システムの設計と理論においては、すべてのデータが1か所でのみ作成、あるいは編集されるように、情報モデルと関連するデータスキーマとを構造化する方法である。データへのリンクで可能なものは参照のみである。プライマリ以外の他の場所のすべてのデータは、プライマリの「信頼できる情報源」の場所を参照するだけであり、プライマリのデータが更新された場合、どこかで重複したり失われたりすることなく、システム全体に伝播される。
SSOTアーキテクチャは、エンタープライズではますます重要になっている。これは、データが重複あるいは非正規化されていると、古い、あるいは誤った情報を取得するリスクがあるためである。一般的な例は、電子カルテである。この場合、SSOT として機能する単一の参照リポジトリに対して、患者の身元を正確に検証することが不可欠である。企業内のデータの重複表現は、データベーステーブル、行、あるいはセルを重複させるのではなく、ポインターを使用して実装される。これにより、信頼できる場所にある要素へのデータ更新が、より大規模なエンタープライズアーキテクチャ全体のすべての連合データベース構成要素に包括的に分散されるようになる。[要出典]
SSOTシステムは、信頼できる、関連性のある、参照可能なデータを提供する。 [1]
実装
上記のようなSSOTの「理想的な」実装は、ほとんどの企業でまず不可能である。これは、多くの組織が複数の情報システムを持っており、それぞれのシステムが同じ実体（顧客など）に関連するデータにアクセスする必要があるためである。多くの場合、これらのシステムはベンダーから既成のまま購入されており、自明な方法で変更することはできない。各システムはそれぞれ、独自のバージョンの共通データまたは実体を格納する必要があるため、独自にレコードのコピーを保持する必要がある（したがって、上記で定義されたSSOTアプローチに直ちに違反する）。例えば、ERP（エンタープライズリソースプランニング）システム（SAPやOracle e-Business Suiteなど）は顧客レコードを保存するかもしれない。一方、 CRM（顧客関係管理）システムにも顧客レコード（またはその一部）のコピーが必要であり、倉庫発送システムにも顧客データの一部またはすべて（出荷先住所など）のコピーが必要な場合がある。ベンダーが変更をサポートしていない場合、これらのレコードを SSOT へのポインターで置き換えることが常に可能であるとは限らない。
複数の情報システムがあるような組織で、信頼できる唯一の情報源を実装したい場合、次の4つのサポートアーキテクチャが一般的に使用される。[要出典]
- エンタープライズサービスバス（ESB）
- マスターデータ管理（MDM）
- データウェアハウス（DW）
- サービス指向アーキテクチャ（SOA） [2]
エンタープライズサービスバス（ESB）
エンタープライズサービスバス（ESB）を使用すると、組織内の任意個のシステムが、別のシステムで変更されたデータの更新を受信できる。信頼できる唯一の情報源を実装するには、任意の実体に対して、正しいデータソースを特定する必要がある。この実体への変更（作成、更新、および削除）は、ESB を介して公開される。そのデータのコピーを保持する必要がある他のシステムは、この更新を購読し、それに応じて独自のレコードを更新する。任意の実体について、マスターとなるデータソースを特定する必要があり、これはしばしばゴールデンレコードと呼ばれる。任意のシステムは、特定の実体（顧客など）に関する情報を公開することもできるし、他の実体（製品など）に関する情報について別のシステムからの更新を購読することもできる。[要出典]
別のアプローチとして、ポイントツーポイントのデータ更新があげられる。しかし、システムの数が増えるにつれて指数関数的にコストがかかるため、このアプローチはITアーキテクチャとしては支持されなくなっている。[要出典]
マスターデータ管理（MDM）
マスターデータ管理システムは、別のシステムに代替の「信頼できる情報源」がない場合でも、特定の実体の信頼できる情報源として機能できる。通常 MDM は、信頼できる情報源として実体の異なる面を更新することができる複数のシステムのハブとして機能する。たとえば、CRMシステムは、顧客のほとんどの面の「信頼できる情報源」となりえる。その情報源は、コールセンターのオペレーターによって更新されるが、顧客は例えば自分の住所を、CRMシステムとは異なるバックエンドを持つカスタマーサービスのウェブサイトを用いて更新することもできる。
MDMアプリケーションは、複数のソースから更新を受信し、ブローカーとして機能して、どの更新が信頼できると見なされるか（ゴールデンレコード）を決定し、この更新されたデータをすべての購読システムに配信する。 MDMアプリケーションは、データを複数の購読システムに配信するためにESBが必要となる。 [3]
データウェアハウス（DW）
データウェアハウスの主な目的は、複数のソースから結合されたデータのレポートと分析をサポートすることである。データウェアハウスではデータが結合されている（データ変換および統合プロセスに組み込まれているビジネスロジックによる）ため、事実上のSSOTとしてよく使用される。ただし、通常、データウェアハウスから入手できるデータは、他のシステムの更新には使用されない。むしろ、データウェアハウスは、複数の利害関係者に報告するための「信頼できる唯一の情報源」となる。より正確には「単一バージョンの真実」と呼ぶほうが正しい。なぜなら、他のバージョンの真実は他のデータソースに存在し、DWを起源とするデータはないからである。DWは、単に他のシステムからロードされたデータをレポートするものである。[要出典]
SOLID＆ソースコード
ソフトウェア設計では、同じスキーマやビジネスロジックなどのコンポーネントが、複数の異なる種類のソースコードとして繰り返し用いられる。複数の異なる種類のソースコードがあるという問題に対処するために、SSOTの概念をソフトウェア開発の原則に適用することもできる。全ての種類のソースコードが同じ SSOT から派生していれば、例えば、再帰的トランスコンパイルなどを使用して、SSOTから異なる種類のソースコードたちに変換することができる。 [4]
分散SaaSデータ（DSD）
信頼できる唯一の情報源が存在するB2Bソフトウェアデータエコシステムのように、データを一元的に保存して参照場所で管理することが現実的でない場合、企業はDSDシステムを使用する。このシステムは、航空交通管制官を演じて、データが保存されている場所に更新をプッシュし、データの正確性を強制することにより、中央のデータ管理と制御を提供する。 [5]