ファクトとディメンション テーブル

Azure Data Explorer データベース用のスキーマを設計するときは、テーブルを大きく 2 つのカテゴリのいずれかに属するものと考えます。

• ファクト テーブル
• ディメンション テーブル

ファクト テーブル

ファクト テーブルは、サービス ログや測定情報など、レコードが変更できない "ファクト" であるテーブルです。 レコードは、ストリーミング形式または大きなチャンクでテーブルに徐々に追加されます。 レコードは、コストのため、または価値が失われたために削除されるまで、そこに残っています。 それ以外でレコードが更新されることはありません。

エンティティ データの変化がゆっくりしている場合、エンティティ データがファクト テーブルに保持されることがあります。 たとえば、場所があまり変更されないオフィス機器のような、一部の物理エンティティに関するデータです。 Kusto のデータは変更できないので、各テーブルに次の 2 つの列を保持するのが一般的な方法です。

• エンティティを識別する ID (string) 列
• 最終変更 (datetime) タイムスタンプ列

各エンティティ ID の最後のレコードだけが取得されます。

ディメンション テーブル

ディメンション テーブル:

• エンティティ識別子からそのプロパティへの参照テーブルのような、参照データを保持します
• 1 回のトランザクションで内容全体が変更されるテーブルのスナップショットのようなデータを保持します

ディメンション テーブルに定期的に新しいデータが取り込まれることはありません。 代わりに、.set-or-replace、.move extents、.rename tables などの操作を使用して、データ コンテンツ全体が一度に更新されます。

ファクト テーブルからディメンション テーブルが導出されることがあります。 このプロセスは、ファクト テーブルの 具体化されたビュー を使用して、各エンティティの最後のレコードを受け取るテーブルに対するクエリを使用して実行できます。

ファクト テーブルとディメンション テーブルを区別する

Kusto には、ファクト テーブルとディメンション テーブルを区別するプロセスがあります。 そのうちの 1 つは連続エクスポートです。

これらのメカニズムでは、ファクト テーブル内のデータが厳密に 1 回処理されることが保証されます。 それらは、データベース カーソル メカニズムに依存します。

たとえば、連続エクスポート ジョブを実行するたびに、データベース カーソルの最後の更新以降に取り込まれたすべてのレコードがエクスポートされます。 連続エクスポート ジョブでは、ファクト テーブルとディメンション テーブルを区別する必要があります。 ファクト テーブルでは新しく取り込まれたデータのみが処理され、ディメンション テーブルは参照として使用されます。 そのため、テーブル全体を考慮する必要があります。

テーブルを "ファクト テーブル" または "ディメンション テーブル" として "マーク" する方法はありません。 データがテーブルに取り込まれ方法と、テーブルが使用される方法により、その種類が識別されます。