0

時間の経過とともにデータが変化するデータベース アプリケーションを設計しています。履歴データを保持し、ユーザーが SQL Server Analysis Services を使用してそれを分析できるようにしたいのですが、これを可能にするデータベース スキーマを考え出すのに苦労しています。変更を追跡できるいくつかのスキーマ (CDC への依存を含む) を思いつきましたが、そのスキーマを SSAS 内で動作する BISM に変換する方法がわかりません。また、BISM に適切に変換されるスキーマを作成することもできましたが、それには私が探している歴史的な機能がありません。この種のことを行うための確立されたベストプラクティスはありますか?

これが私がやろうとしていることの例です:

毎月の売上高を含む Sales というファクト テーブルがあります。また、Customers という通常のディメンション テーブルを使用して、ユーザーが顧客ごとに分類された売上高を確認できるようにしています。顧客と営業担当者の間には多対多の関係があるため、顧客ディメンションを参照する責任という参照ディメンションと、責任ディメンションを参照する営業担当者参照ディメンションを作成できます。これで、販売 -> 顧客 -> 責任 -> 販売担当者という参照ディメンションのチェーンによって販売担当者にリンクされた販売ファクトができました。問題は、時間の経過とともに変化するのは販売の事実だけではないということです。また、特定の営業事実の時点で、どの営業担当者が顧客の責任者であったかの履歴を維持できるようにしたいと考えています。また、特定の販売事実が発生した時点で販売担当者のオフィスがどこにあったかを知りたいのですが、これは彼の現在の場所とは異なる可能性があります。また、特定のセールス ファクトの時点での顧客の組織の規模を知ることもできます。これも現在とは異なる可能性があります。これを BISM に適した方法でモデル化する方法がわかりません。これは、現在とは異なる可能性があります。これを BISM に適した方法でモデル化する方法がわかりません。これは、現在とは異なる可能性があります。これを BISM に適した方法でモデル化する方法がわかりません。

4

2 に答える 2

2

目的を達成するための確立されたベスト プラクティスの方法は、ディメンションがゆっくりと変化するディメンション モデルです。営業担当者は、SCD の有用性を説明するためによく使用されます。たとえば、チームの業績に応じてボーナスを支給するセールス マネージャーは、担当者が新しい地域に異動しても合計額が減ることを望んでいません。SCD は、この種のもの (および説明した状況) を追跡するのに最適であり、歴史的に任意の時点でどのように見えたかを確認できます。

開始するには、Ralph Kimball の Web サイトを参照してください。読むことをお勧めする最初の 3 つの記事は、「緩やかに変化する次元」、「ゆっくりと変化する次元 第 2 部」、および「次元モデリングの 10 の必須ルール」です。

成功するためには、次の点に注意してください。

  1. 3NF トランザクション データベースを設計していません。非正規化に慣れましょう。
  2. 粒度の意味を理解し、データベースの粒度を明示的に定義してください。
  3. 自然キーをキーとして使用しないでください。また、代理キーにインテリジェンスを焼き付けないでください (時間キーを除く)。
  4. アプリケーションの目標は、クエリの速度と、理解とナビゲーションの容易さです。
  5. タイプ 1 とタイプ 2 の緩やかに変化するディメンションを理解し、それらをどこで使用するかを理解します。
  6. 「関係を断ち切る」力を持つビジネス側のスポンサーを確保してください。組織内には、同じものに対して異なる定義を持つさまざまな人々がいます。決定を下す権限を持つ執行者が必要です。私の言いたいことを理解するために、組織内の 5 人の異なる人に「顧客」または「粗利益」を定義するように依頼してください。どちらかを同じように定義する人が 2 人いれば幸運です。
  7. それを翼にしようとしないでください。The Data Warehouse Lifecycle Toolkitを読んで、最初は奇妙に思えてもアイデアを受け入れてください。彼らが働きます。
  8. OLAP は強力で、うまく実装すれば生活を一変させる可能性があります。そうでない場合、それは絶対的な悪夢になる可能性があります。
  9. 楽しむ！
于 2012-06-14T03:02:14.567 に答える
2

現在、毎月の売上高を含むファクト テーブルがあるとおっしゃいました。つまり、顧客ごとに 1 か月に 1 つのレコードです。したがって、このファクト テーブルの各レコードは、実際には、対応するディメンションでその月に発生した個々の売上 "トランザクション" の集計です。

したがって、特定の月に、顧客 123 に対してそれぞれ $10 の 5 つの個別の販売トランザクションが存在する可能性があります...そして、個々の販売トランザクションはそれぞれ別の営業担当者 (A、B、C、D、E) によって処理される可能性があります。あなたが記述したファクト テーブルには、顧客 123 に対して 50 ドルのレコードが 1 つあります...しかし、SalesReps (ABCDE) をどのようにモデル化しますか?

あなたの目標に基づいて...

  • 特定の販売事実の時点で、どの販売担当者が顧客の責任者であったかの履歴を維持できるようにするため
  • 特定の販売事実の時点で販売担当者のオフィスがどこにあったかを知るため
  • 特定の販売事実の時点での顧客の組織の規模を知る

...より低い粒度でモデル化する方が簡単だと思います...特に、販売トランザクションごとに 1 レコードの粒度を持つ販売トランザクション ファクト テーブルです。各販売トランザクションには、1 人の顧客と 1 人の営業担当者がいます。

FactSales
    DateKey (date of the sale)
    CustomerKey (customer involved in the sale)
    SalesRepKey (sales rep involved in the sale)
    SalesAmount (amount of the sale)

履歴変更の追跡については...履歴変更を追跡する属性を持つディメンションは、「緩やかに変化するディメンション」としてモデル化する必要があるため、「代理キー」を使用する必要があります。したがって、たとえば、顧客ディメンションでは、顧客 ID は主キーではなく、単にビジネス キーになります...そして、任意の整数を主キーとして使用します...この任意のキーが参照されますを代理キーとして使用します。

ディメンションのデータをモデル化する方法は次のとおりです...

DimCustomer
    CustomerKey (surrogate key, probably generated via IDENTITY function)
    CustomerID (business key, what you will find in your source systems)
    CustomerName
    Location (attribute we wish to track historically)
    -- the following columns are necessary to keep track of history
    BeginDate
    EndDate
    CurrentRecord

DimSalesRep
    SalesRepKey (surrogate key)
    SalesRepID (business key)
    SalesRepName
    OfficeLocation (attribute we wish to track historically)
    -- the following columns are necessary to keep track of historical changes
    BeginDate
    EndDate
    CurrentRecord

FactSales
    DateKey (this is your link to a date dimension)
    CustomerKey (this is your link to DimCustomer)
    SalesRepKey (this is your link to DimSalesRep)
    SalesAmount

これにより、同じ顧客に対して複数のレコードを持つことができます。元。CustomerID 123 は 2012 年 3 月 5 日に NC から GA に移動します...

CustomerKey | CustomerID | CustomerName | Location | BeginDate | EndDate | CurrentRecord
1 | 123 | Ted Stevens | North Carolina | 01-01-1900 | 03-05-2012 | 0
2 | 123 | Ted Stevens | Georgia        | 03-05-2012 | 01-01-2999 | 1

一部の属性の変更履歴を追跡する SalesReps やその他のディメンションにも同じことが当てはまります。

したがって、CustomerID、CustomerName (またはその他の履歴追跡されていない属性) によって販売トランザクション ファクト テーブルをスライスすると、顧客のすべてのトランザクションにわたって集計されたファクトを含む単一のレコードが表示されます。代わりに、CustomerName と Location (過去に追跡された属性) によって販売トランザクションを分析することにした場合、顧客がその場所にいた間の売上高に対応する、顧客の場所の「バージョン」ごとに個別のレコードが表示されます。

ところで、時間に余裕があり、さらに学習したい場合は、Kimball のバイブル「The Data Warehouse Toolkit」を強くお勧めします...これは、ディメンション モデリング シナリオの強固な基盤を提供するはずです。

于 2012-06-14T01:44:42.760 に答える