LuckyTemplates の実装を成功させるためのヒント

LuckyTemplates プロジェクトの計画と実装に関するシリーズを続けていきます。今回は、データセット設計、プロファイリング、モードについて説明します。プロジェクト計画シリーズの第 1 部では展開モードを扱い、第 2 部では検出と取り込みについて説明しています。

目次

• LuckyTemplates プロジェクト実装のためのデータセット設計
  • データセット設計の 4 つのステップ
  • ビジネスプロセスを選択します。
    • LuckyTemplates の実装で避けるべきアンチパターン
  • 穀物を宣言します。
  • 寸法を特定します。
  • 事実を定義します。
• LuckyTemplates プロジェクト実装のためのデータ バス マトリックス
• LuckyTemplates 実装のためのデータ プロファイリング
  • SQL サーバー統合サービス
  • DAX スタジオ
  • LuckyTemplates デスクトップ
• LuckyTemplates 実装のためのデータセットの計画
  • データセット モードの選択
  • データセット モードを選択する際に尋ねるべきいくつかの質問
• 結論

LuckyTemplates プロジェクト実装のためのデータセット設計

データセットの設計プロセスについて説明し、しばらく前から存在するツールであるデータ ウェアハウス バス マトリックスについて説明しましょう。

LuckyTemplates データセットの設計は、データ ウェアハウスの設計に似ています。したがって、データセットとデータ ウェアハウスの両方には、ファクト テーブルとディメンション テーブル、スター スキーマ、ゆっくりと変化するディメンション、ファクト テーブルの粒度、テーブル間の関係を構築するためのローカル情報キーなどの類似した概念があります。

データセット設計の 4 つのステップ

データセット設計プロセスには 4 つのステップがあります。つまり、ビジネス プロセスの選択、ファクト テーブルの粒度の宣言、ディメンションの特定、そしてファクトの定義です。

ビジネスプロセスを選択します。

最初のステップでは、各ビジネス プロセスは、ディメンションとの多対 1 の関係のスター スキーマを持つファクト テーブルによって表されます。

ユーザーは定期的に複数のビジネス プロセスを同時に分析するため、検出プロセスや要件収集プロセス中に、単一のビジネス プロセスを単独で集中的に分析することは困難です。

LuckyTemplates の実装で避けるべきアンチパターン

LuckyTemplates プロジェクトで避けたい一般的なアンチ パターン(一般に効果がなく、逆効果になる可能性がある、再発する問題への対応) は、ビジネス プロセスではなく、特定のプロジェクトまたはチーム用のデータセットの開発です。

たとえば、マーケティング チーム専用のデータセットと販売組織用の別のデータセットを開発します。このアプローチでは、同じ販売データが両方のデータ セットで 2 回クエリされ、更新されるため、必然的にリソースの無駄が発生します。これらは LuckyTemplates サービスのストレージ リソースも消費します。

これらは、データセット設計に適切なプロセスを経る必要がある理由の一部です。データ セットにはバリエーションや変換が含まれる可能性があるため、分離されたアプローチでは管理性とバージョン管理の問題が発生します。

ユーザーまたはチームの分析ニーズは LuckyTemplates プロジェクトの優先事項ですが、最終的にチーム間で共有できる持続可能なソリューションを計画することも重要です。

穀物を宣言します。

ファクト テーブルの粒度は、最終的には、分析クエリに使用できる詳細レベルと、アクセスできるデータの量をカバーします。

したがって、粒度が高いことは詳細度が高いことを意味し、粒度が低いことは詳細度が低いことを意味します。この例としては、販売注文明細レベルを取得したい場合や、プロジェクトに各販売注文の概要レベルのみを含めて、その販売の一部として注文された特定の製品には触れないようにする場合があります。

場合によっては、この粒度は時間枠によって異なる場合があります。現在の四半期については非常に詳細なファクト テーブルを必要としているが、前四半期については、その四半期の総売上がいくらかだけを知りたいという顧客を何人も見かけました。

このステップでは、さまざまなビジネス プロセスの各行が何を表しているかを判断します。たとえば、データ ウェアハウスの販売ファクト テーブルの各行は、顧客からの販売注文の明細を表します。

逆に、売上および利益計画の行は、暦月、製品サブカテゴリ、および販売地域リージョンに集約されます。したがって、この場合、2 つの異なるファクト テーブルと 2 つの異なるグレインがあります。2 つを比較したい場合は、データ モデリング作業が必要になります。

寸法を特定します。

寸法は、前の設計ステップで選択された粒子の自然な副産物にすぎません。

したがって、ファクト テーブルの 1 つのサンプル行は、特定の日付と時刻に個々のプロジェクトや製品を購入した顧客など、特定のプロセスに関連付けられたビジネス エンティティのディメンションを明確に示す必要があります。より低い粒度を表すファクト テーブルの次元は少なくなります。

たとえば、注文書のヘッダー レベルを表すファクト テーブルはベンダーを識別できますが、ベンダーから購入した個々の製品は識別できません。したがって、その場合、製品カテゴリまたは製品サブカテゴリのディメンションを含める必要はありません。

事実を定義します。

ファクトは、ファクト テーブルに含まれる数値列を表します。したがって、ステップ 3 のディメンション列はリレーションシップに使用されますが、ファクト列は数量列の合計や価格列の平均など、集計ロジックを含むメジャーで使用されます。

LuckyTemplates プロジェクト実装のためのデータ バス マトリックス

データ ウェアハウス バス マトリックスは、Ralph Kimball データ ウェアハウス アーキテクチャの要であり、データ ウェアハウス設計への増分的かつ統合的なアプローチを提供します。

ここに示されているアーキテクチャは、Ralph Kimball によるThe Data Warehouse Toolkit第 3 版からのものです。これにより、複数のビジネス チームや部門が同じビジネス プロセスやディメンションにアクセスするために必要となる、スケーラブルなデータ モデルが可能になります。

データ ウェアハウス バス マトリックスを保持しておくと便利です。入力すると、同様のインターネット ファクト テーブルとディメンション テーブルを含む他のデータセットがあるかどうかがわかります。これにより、プロジェクトの再利用が促進され、プロジェクトのコミュニケーションが向上します。

したがって、各行は、総勘定元帳の月次決算など、重要で繰り返し発生するビジネス プロセスを反映しています。各列は 1 つまたは複数のビジネス プロセスに関連するビジネス エンティティを表し、影付きの行はプロジェクト内に含まれるビジネス プロセスを表します。

LuckyTemplates 実装のためのデータ プロファイリング

粒子を特定し、4 段階のデータセット設計プロセスが完了したら、すぐにファクト テーブルとディメンション テーブルのソース データの技術分析を行う必要があります。

データベース図やデータプロファイリング結果などの技術メタデータは、プロジェクト計画段階で不可欠です。

この情報は、LuckyTemplates データセットが意図したビジネス定義を反映し、健全で信頼できるソースに基づいて構築されていることを確認するために使用されます。

つまり 3 つは、プロファイリング情報を収集するための 3 つの異なる方法であり、設計プロセスを終えた人々が最初に実行するステップとなります。

SQL サーバー統合サービス

これにはいくつかの方法があります。1 つの方法は、 SQL Server Integration Services (SSIS) パッケージ内のデータ プロファイリング タスクを使用することです。

データ プロファイリング タスクには ADO.NET 接続が必要で、その出力を XML ファイルまたは SSIS 変数に書き込むことができます。

この例では、ADO.NET ソース データは AdventureWorks データ ウェアハウス、データベース、および SQL サーバーであり、宛先は XML ファイルです。

したがって、タスクが実行されると、SQL サーバー データ プロファイル ビューアーを介して XML ファイルを読み取ることができます。結果は、Null カウントと Null カウントのパーセンテージで確認できます。

DAX スタジオ

データ プロファイリングのもう 1 つの方法は、DAX Studio を使用することです。実際にデータを LuckyTemplates データセットに取り込むには、DAX Studio に移動し、詳細タブに移動して、VertiPaq Analyzerを実行する必要があります。

列のカーディナリティに関する同様の情報が表示されるため、データ モデル内で最も多くのスペースを占有している列がわかります。これには、データに関するさまざまな統計がすべて含まれます。

LuckyTemplates デスクトップ

データ プロファイリングは、LuckyTemplates デスクトップ内の Power Query でも利用できます。「表示」タブに移動すると、カラムの品質、カラムの分布、カラムのプロファイルなどをオンにすることができます。少なくとも最初の 1,000 行程度については、エラー、NULL、平均、標準偏差などの情報を確認できます。

LuckyTemplates 実装のためのデータセットの計画

ソース データがプロファイリングされ、4 段階のデータセット設計プロセスで特定された要件に照らして評価された後、BI チームはデータセットの実装オプションをさらに分析できます。

エンタープライズ データ、ウェアハウス、アーキテクチャ、ETL ツールとプロセスに多額の投資を行っているプロジェクトであっても、ほぼすべての LuckyTemplates プロジェクトでは、ソース データの品質と価値を高めるために、ある程度の追加ロジック、統合、または変換が必要です。

データセットの計画段階では、データセットをサポートするために特定されたデータ変換の問題にどのように対処するかを決定します。さらに、プロジェクト チームは、インポート モード データセット、ダイレクト クエリ データセット、または複合データセットのいずれを開発するかを決定する必要があります。

データセットの計画プロセスを明確にするために、この図では、変換とビジネス ロジックを実装できるデータ ウェアハウスと LuckyTemplates データセットのさまざまなレイヤーを特定します。

一部のプロジェクトでは、最小限の変換が必要であり、LuckyTemplates データセットに簡単に含めることができます。たとえば、ディメンション テーブルに必要な追加列が数個だけで、これらの列の計算方法についての簡単なガイダンスがある場合、IT 組織はデータ ウェアハウスを改訂するのではなく、M 乗クエリ内でこれらの変換を実装することを選択する可能性があります。

BI のニーズと企業データ ウェアハウスとの間に大きなギャップが存在する場合、LuckyTemplates データセットの構築と維持はより複雑になります。

データセット設計者は、より複雑なレベルがある場合には、データセットの影響を定期的に分析し、伝達する必要があります。

ただし、必要な変換ロジックが複数の共同操作、行フィルター、およびデータ型の変更を伴う複雑または広範囲にわたる場合、IT 組織は、新しいデータセットと将来の BI プロジェクトをサポートするために、データ ウェアハウスに重要な変更を実装することを選択する場合があります。

たとえば、プロセスのサポート、修正、更新にステージング テーブルと SQL ストア プロシージャが必要になる場合や、DirectQuery データセットのクエリ パフォーマンスを向上させるためにインデックスの作成が必要になる場合があります。

データセット モードの選択

データセット計画に続く、ただし密接に関連する手順は、既定のインポート モード、DirectQuery/ライブ モード、または複合モードのいずれかを選択することです。

一部のプロジェクトでは、既知の要件を考慮して 1 つのオプションのみが実行可能または現実的であるという単純な決定が行われますが、他のプロジェクトでは、各設計の長所と短所の重要な分析が必要になります。

したがって、データ ソースが遅い、または大量の分析クエリを処理するための設備が整っていないと考えられる場合は、インポート モード データセットが推奨されるオプションである可能性が非常に高くなります。

同様に、データ ソースのほぼリアルタイムの可視性が不可欠な場合、それを実現するには DirectQuery またはライブ モードが唯一のオプションです。DirectQuery モードとライブ モードは互いに非常に似ています。どちらのメソッドもデータセット自体にデータを保存せず、ソース システムに直接クエリを実行して、ユーザーのアクションに基づいてデータを取得します。LuckyTemplates データセット用の DirectQuery と Analysis Services 用の DirectQuery が利用できるようになりました。

データセット モードを選択する際に尋ねるべきいくつかの質問

どのモードを使用するかを決定する際に尋ねるべき質問がいくつかあります。データセットのソースは単一ですか? 単一のソースがない場合、以前は DirectQuery/Live ソースを使用できませんでした。

複合モードのデータセットができましたが、単一のソースがない場合はインポートまたは複合のいずれかになるため、最初に尋ねるのは良い質問です。

DirectQuery/ライブ ソースがオプションの場合、ソースは分析クエリをサポートできますか? 数十億行または数兆行を処理している場合は、インポート モードのデータセットは使用できない可能性があり、データセットが使用可能であることを確認するには DirectQuery または複合モードを使用する必要があります。

DirectQuery/Live ソースがワークロードをサポートできる場合、DirectQuery/Live 接続はインポート モデルによって提供されるパフォーマンスと柔軟性より価値がありますか?

結論

この投稿で、LuckyTemplates プロジェクトの計画に関するこのシリーズを終了します。これらは、取り組んでいるすべての LuckyTemplates プロジェクトにとって不可欠な手順だと思います。これらの手順は、特にエンタープライズ ビジネス インテリジェンスの設定において、デュー デリジェンスを行う際に重要です。

ではごきげんよう、

グレッグ・デックラー