私たちはデータ ウェアハウスを拡張する過程にあり、チームの誰も解決できなかった難問に直面しました。Google で回答を検索してみましたが、適切な用語が得られません。
本質的に、問題はこれです。アイテムを追跡するデータ ウェアハウスがあります。このデータ ウェアハウスから多くのレポートを作成する必要があります。多くのレポートは、これらの項目を分類し、分類に従ってデータを集計することによって作成されます。一部のレポートは分類を共有しており、一部はレポートに固有の独自の分類を持っている場合があります。その場合でも、これらの分類を再利用する必要がある後続のレポートまたは分析 (アドホック) が存在する可能性があります。そして、これらの分類スキームが多数存在する可能性があります。さらに、これらのスキームは、アイテムを分類するために複数のファクト テーブルのデータに依存する場合があります (また、アイテム情報は、異なる粒度のために複数のファクト テーブルにまたがります)。
私たちの当初の計画では、これらのディメンションをカテゴリごとに 1 つ持つか、カテゴリごとに 1 つの列を持つジャンク ディメンションを用意する予定でした。そして、分類の数が静的なままである可能性が高い場合は、それで問題ありません。ただし、常に新しいレポートと分析のニーズがあります。新しい分類スキームを追加するたびに、スキーマと ETL プロセスを変更する必要はありません。データを再インポートしたり、ETL の一部を再実行して再計算したりすることなく、分類のロジックを変更したい場合もあります。
したがって、オプションは次のようになります。
- クエリからクエリへと分類ロジックをコピー アンド ペーストすることを意味する場合でも、ロジックをレポートおよび分析クエリに入れるだけです。
- 欠陥のある次元アプローチを使用する
- クエリで使用できるカテゴリを計算する関数がありますが、内部で追加のクエリを実行する必要がある場合があるため、コストがかかります (パフォーマンスが悪い)。
- 追加のカテゴリ列を含むファクト テーブルの上にビューを配置します。ビューは通常のテーブル スキーマよりも簡単に変更でき、ETL プロセスを変更する必要はありません。
- ある種のブリッジ テーブル スキームを使用して、カテゴリと各カテゴリのアイテム間の多対多マッピングを実装します。これにより、クエリの複雑さが増しますが、スキームの変更はなくなります。ETL は引き続き変更する必要がありますが、変更はおそらくより小さな領域で行われる可能性があります (おそらく、カテゴリ マッピングを更新するための単一のクエリまたは手順)。
通常のファクト フィールドやディメンション フィールドにアクセスする場合と同様に、ユーザーがこれらの分類フィールドにアクセスするために多くのことをする必要がないように、このシステムにアクセスできるようにしたいと考えています。また、新しい分類スキーマがデータベースに追加されるたびに、スキーマと ETL プロセスに多くの変更を加える必要がないようにしたいと考えています。
だから私の質問は、本質的に、この問題を解決するために使用できる、私がリストした5つよりも優れた方法はありますか? 問題をより効果的に解決する 5 つのバリエーションはありますか? それとも、ある程度の苦しみを必要とする難しい問題ですか？多分私はこれについてすべて間違っているので、その点に関するフィードバックも役に立ちます。
tl;dr: データ ウェアハウス内のアイテムをさまざまなカテゴリに分類する方法が必要ですが、最も効率的で、管理が容易で、使いやすいシステムがわかりません。
編集: 追加情報: SQL Server を使用しており、SSRS をプライマリ レポート フロントエンドとして使用し、SSAS を分析またはアドホック クエリ用のセカンダリ フロントエンドとして使用しています。