実体化

多くの Foundry ワークフローでは、最新のデータが不可欠です。オントロジーのユーザーは、入力データソースのデータとユーザーによる編集を組み合わせることで、各オブジェクトの最新の状態を含む、オントロジーのインデックス化済みデータの実体化を作成できます。

実体化のユースケース

実体化の主なユースケースは、次の 2 個です。

• ユーザーによる編集を含め、各オブジェクトの最新の状態を必要とする下流の Foundry パイプラインを構築する。
• オブジェクトタイプのすべてのオブジェクトの最新の状態を含むオントロジーデータをダウンロードできるようにする。

実体化されたデータセットの作成

Ontology Manager のデータソースタブで 編集設定を切り替え、実体化タブに移動します。実体化タブでは、入力データソースの種類に応じたさまざまな設定で、実体化されたオブジェクトデータセットやオブジェクトの制限付きビューを作成できます。実体化は自動的に更新され、データセットプレビューから手動でビルドすることはできません。

ライトバックデータセットと実体化されたデータセットの比較

Phonograph とも呼ばれる Object Storage v1（OSv1）では、ライトバックデータセットが実体化されたデータセットに相当します。OSv1 でオブジェクトタイプ、または結合テーブルを持つ多対多のリンクタイプに対するユーザーによる編集を有効にするには、ライトバックデータセットが必要です。

Object Storage v2（OSv2）では、ユーザーによる編集を有効にするために、実体化されたデータセットは必要ありません。代わりに、Ontology Manager のデータソースタブで編集設定を切り替えることで、オブジェクトタイプに対するユーザーによる編集を有効にできます。このため、OSv2 では実体化は任意であり、前述の 2 個の主なユースケースで必要な場合にのみ実体化を作成します。また、OSv2 では、オブジェクトタイプのプロパティの一部のみを実体化したい場合に、複数の実体化されたデータセットを作成できます。

OSv1 のライトバックデータセットと OSv2 の実体化されたデータセットのその他の動作の違いについて、以下で説明します。

ライトバックデータセットと実体化されたデータセットのビルドスケジュール

OSv1（Phonograph）のライトバックデータセットと OSv2 の実体化されたデータセットでは、ビルドスケジュールの扱いが異なります。

• OSv1 には、新しいユーザーによる編集があったときに、ライトバックデータセットのビルドをトリガーする仕組みはありません。代わりに、ライトバックデータセットを任意の頻度でビルドするためのスケジュールを作成できます。新しいデータがない場合、追加のコンピュートを使用しないように、これらのビルドは自動的に中止されます。スケジュールが設定されておらず、ライトバックデータセットがビルドされていない場合、ライトバックデータセットのデータはオントロジーを正確に表していない可能性があります。
• OSv2 は、2 個の異なるユースケースにそれぞれ対応するように設計されています。
  • 編集が適用された直後に、ユーザーによる編集を実体化されたデータセットに反映させるには、ユーザーによる編集の自動伝播を有効にできます。このモードでは、ユーザーによる編集が、設定された実体化されたデータセットに自動的に伝播されます（数分の低遅延）。新しいユーザーによる編集の頻度に応じてビルドがより頻繁に発生するため、追加のコストがかかる場合があります。
  • ユーザーによる編集を実体化されたデータセットに伝播する際の低遅延が重要でない場合は、定期的なビルドを設定することでコストを削減できます。このモードでは、入力データソースに新しいデータがあるたびに、または 6 時間ごとに、実体化されたデータセットが再ビルドされます。

ライトバックデータセットと実体化されたデータセットの保持

ライトバックデータセットと実体化されたデータセットでは、保持の仕組みが異なります。

• OSv1 では、プラットフォーム内で指定できる特定の保持ポリシーを適用できるという点で、ライトバックデータセットは通常のデータセットと同様に動作します。これにより、ライトバックデータセットが定期的にビルドされていれば、オブジェクトタイプの状態の過去のスナップショットを振り返ることができます。

• OSv2 では、実体化されたデータセットにはカスタマイズできない保持ポリシーが適用されます。過去のトランザクションは継続的に削除され、最新のスナップショットのみが利用可能であることが保証されます。この場合、オブジェクトタイプの状態の過去のスナップショットを保持することが重要であれば、下流にトランスフォームを設定する必要があります。この保持ポリシーはオブジェクトタイプを削除した場合にも適用されるため、削除されたオブジェクトタイプの実体化されたデータセットを保持するには、同様に下流のトランスフォームが必要です。

ライトバックデータセットと実体化されたデータセットのデータセットスキーマ

OSv1（Phonograph）のライトバックデータセットと OSv2 の実体化されたデータセットでは、入力データソースのスキーマとの関係が異なります。

• OSv1 では、入力データソースのスキーマがコピーされ、ライトバックデータセットのスキーマとして使用されます。
• OSv2 では、Foundry オントロジーを分かりやすくするために、この動作が変更されています。ユーザーはオントロジーのデータを実体化するため、実体化されたデータセットに使用されるスキーマは、元データソースの設定に依存するのではなく、オントロジーの定義からコピーされます。具体的には、各プロパティの API名メタデータが、実体化されたデータセットのスキーマとして使用されます。OSv1 から OSv2 に移行する際に、入力データソースのスキーマを引き続き使用したい場合（たとえば、既存のライトバックデータセットの下位互換性を保証するため）は、Palantir の担当者にお問い合わせください。

制限付きビューの実体化オプション

OSv1（Phonograph）では、制限付きビューを入力データソースとして使用して詳細な権限が設定されたオブジェクトタイプについて、制限付きビューを実体化することはできません。ユーザーは、入力データソースである制限付きビューの元データセットのすべての行を含むライトバックデータセットのみを実体化できます。その後、アクセス制限に基づいて、ライトバックデータセットへのアクセスを適切に保護する責任はユーザーにあります。

OSv2 では、以下に示すように、制限付きビューを入力データソースとして使用して詳細な権限が設定されたオブジェクトタイプについて、通常のデータセットと制限付きビューのどちらも、実体化されるリソースとして設定できます。

オブジェクトタイプに複数の入力データソースがある場合、どの入力データソースのデータを実体化するかを選択して、実体化されたデータセットを設定できます。入力データソースが選択されていない場合、その入力データソースからマッピングされたオブジェクトタイプのプロパティは、実体化されたデータセットに反映されません。入力データソースの一部が制限付きビューである場合は、2 個の選択肢があります。

• 制限付きビューのリソースを 1 個選択して、制限付きビューとして実体化できます。設定例を以下に示します。

• 複数の入力データソースを選択できますが、その場合、オントロジーデータを Foundry データセットとしてのみ実体化できます。この制限があるのは、入力データソースである制限付きビューごとに異なるポリシー設定を持つことができ、制限付きビューでは現在、列レベルのポリシーの設定がサポートされていないためです。設定例を以下に示します。

制限付きビューからのデータセットの実体化

前述のとおり、OSv1 と OSv2 のどちらでも、制限付きビューを入力データソースとするオブジェクトタイプを、通常のデータセットとして実体化できます。制限付きビューはトランスフォームの入力として使用できないため、これはプラットフォーム内で制限付きビューをデータセットに変換できる唯一の場所です。実体化されたデータセットは制限付きビューのポリシーを引き継がないため、実体化されたデータセットの作成と可視化には、より高いレベルの権限が必要です。

説明のために、以下の用語を使用します。

• オブジェクトタイプ： 対象のオブジェクトタイプ。
• 制限付きビュー： オブジェクトタイプの元となる制限付きビュー。
• 元データセット： 制限付きビューの元データセット。

以下の図は、元データセット、制限付きビュー、オブジェクトタイプの関係を示しています。

これらの定義を踏まえて、新しい実体化されたデータセットを作成し、そのトランザクションを閲覧するためにユーザーに必要な条件を説明します。これらは 2 個の別々のステップです。

新しい実体化されたデータセットを作成するには、元データセットから新しいデータセットへの恒等変換を実行する権限が必要です。セキュリティの観点では、ユーザーが元データセットと制限付きビューの両方の任意アクセス制御と強制アクセス制御を満たす必要があることを意味します。

これらの条件が満たされている場合、以下の例に示すように、新しい実体化されたデータセットを作成するオプションが表示されます。

これらの条件が満たされていない場合、このオプションは表示されません。以下の例では、ユーザーが必要な任意アクセス制御を満たしていないため、実体化されたデータセットを作成できません。

実体化されたデータセットのトランザクションを閲覧するには、ユーザーは元データセットのトランザクションを閲覧できる必要があります。つまり、元データセットのトランザクションの強制アクセス制御も満たす必要があります。

以下の図では、この関係を元データセット、制限付きビュー、オブジェクトタイプ、実体化されたデータセットとともに示しています。制限付きビューでは切り離されている元データセットのマーキングが、実体化されたデータセットに伝播されます。つまり、トランザクションを閲覧するには、ユーザーがこのマーキングを満たす必要があります。

OSv2 のオブジェクトタイプに、強制アクセス制御タイプのプロパティが含まれる場合、実体化されたデータセットでも、ユーザーが Allowed markings、Allowed organizations、Max classification のすべての強制アクセス制御を満たす必要があります。来歴は前述のとおり元データセットから引き継がれ、強制アクセス制御タイプのプロパティを含むオブジェクトタイプには、オブジェクトタイプで定義された強制アクセス制御も適用されます。

以下の図は、1 個のマーキングを持つ元データセットと、元データセットからのマーキングおよびオブジェクトタイプで設定されたマーキングの 2 個のマーキングを持つ実体化されたデータセットを示しています。

元データセットには、以下のマーキングが含まれています。

オブジェクトタイプの設定では、以下に示すように、別のマーキングを持つ強制アクセス制御タイプのプロパティを設定できます。

この設定により、実体化されたデータセットは、元データセットと、強制アクセス制御タイプのプロパティを含むオブジェクトタイプの両方から来歴を引き継ぎます。

制限付きビューからのデータセット実体化に関する制限

OSv2 の制限付きビューに以下のいずれかのポリシーが含まれる場合、実体化データセットを設定することはできません。

1. 制限付きビューに、ユーザーの強制アクセス制御を参照し、文字列プロパティに適用される条件が含まれる場合。代わりに、オントロジーの文字列プロパティを強制アクセス制御プロパティに変換し、最大の機密情報区分に基づくアクセス制御または強制マーキングのセットを設定できるようにする必要があります。
2. 制限付きビューに承認済みグループIDの条件がある場合。
3. 制限付きビューのデータソースに、固定値として組織またはマーキングを直接参照する条件がある場合。代わりに、組織とマーキングの詳細な条件が、文字列プロパティや固定値ではなく、強制アクセス制御プロパティを参照するようにする必要があります。

ブランチ

実体化は、以下の制限のもとで Global Branches と併用できます。

• ブランチ上で実体化を作成することはできません。
• ブランチ上で実体化を編集することはできません。

実体化が関連付けられたオブジェクトタイプへの変更は、ブランチ内でインデックス化されます。そのブランチからの更新は、実体化されたデータセットまたは制限付きビューに書き込まれます。オブジェクトタイプを削除するか、ブランチから外すと、実体化されたデータセット内のブランチも削除されます。制限付きビューの制限により、実体化された制限付きビューのブランチは削除されません。この制限への対応策は現在開発中です。