4

Data Warehouse Toolkitを読んだばかりで、スター スキーマのモデリングは初めてです。

クライアントとクライアント以外の従業員との電話会議に参加するビジネス プロセスがあります。

「オーディエンス」と呼ばれる私のファクト テーブルには、出席者が通話に接続されていた時間と、この通話への接続にかかるコストの測定値が含まれます。粒度は「電話会議への個別接続」です。

準拠したクライアント ディメンションを使用して、非クライアント ディメンションを (まだクライアントではない発信者のために) このように作成する必要があります (この質問の一部ではないディメンションを省略します)。

最初の潜在的なモデル

または、次のように、準拠した Client ディメンションに非準拠の Attending ディメンションを関連付けた方がよいでしょうか。

2 番目の潜在的なモデル

または、このようなビジネス プロセスをモデル化するためのより優れた標準的なメカニズムはありますか?

編集：

上記のモデル 2 を使用して、クライアント ディメンション テーブルと対応するディメンションの上にビューを作成して、それが 1 つのディメンションにしか見えないようにするにはどうすればよいでしょうか?

それは、以下のダミールの答えに代わる許容可能なものですか?

4

4 に答える 4

3

クライアントを 2 つのテーブル (ディメンション) に分割する必要はありません。すべてのクライアント、アクティブ、見込み客を同じディメンション テーブルに入れるだけです。その後、IsActive 属性 (列) を導入して、有料のクライアントと見込み客を区別できます。遅かれ早かれ、データ マイニング ツールを使用して、クライアントについて、また、サービスに料金を支払う意思がある人とそうでない人との違いを知るようになるでしょう。アルゴリズムが機能するには、お金を払っている人と払っていない人の両方のグループのデータを提供する必要があります。要約すると、プロスペクトは有料クライアントと同じテーブルに属します。

これで、モデル No 1 を使用できます。ファクト テーブルのメジャーが意味を成していることを確認してください。たとえば、call_id =123 に 10 人が参加した場合、

sum(cost_of_connection)
from factAudience
where call_id = 123;

実際のコストの 10 倍など、意味のないものではなく、呼び出しの総コストを返す必要があります。

編集

「支払っているクライアント」と「見込みのあるクライアント」はどちらもクライアントのタイプであるため、同じディメンション テーブル (dimClient) に属します。DW のどこかに、dimSale への FK を持つ factSale (または類似のもの) があります。支払いと見込み客を区別するための列が dimClient にない場合でも、factSale と dimClient を結合することで、支払いを行う顧客を獲得できます。

「顧客は誰ですか？」組織に DW を導入する際の一般的な議論です。クライアントの獲得、保持、コンバージョンなどを分析できるようにするために、少なくとも DW では、見込み客は有料の顧客と同じように扱われます。新規顧客の獲得と創出は、(ほぼ) すべての CEO にとってリストの最優先事項であることを覚えておいてください。

于 2010-03-17T12:01:42.937 に答える
2

私は2番目に行きます.それは出席者を専用の次元でモデル化し、その次元の属性を介して彼らの顧客性(または他の方法)を公開できるようにします.これはおそらくドリルダウンしたい方法です.実際の生活（「すべての参加者を表示してください」に続いて「そして今、それらのどれがクライアントですか」）。

クライアント ディメンションでは、すべての出席者の client_id を入力し、出席者がクライアントではない「不明な」要素に一致させます。

これについての素晴らしい議論がここにあります：

http://crpit.com/confpapers/CRPITV75Riazati.pdf

于 2010-03-11T19:58:44.800 に答える
0

違いはほとんどありません。2 番目のバージョンの方が正しい可能性がありますが、OLAP システムはこれをサポートしていますか?

于 2010-03-10T19:50:35.000 に答える