問題タブ [dimensional-modeling]

次元モデルに慣れてきたので、健康保険請求プロセスを調べ始めました。私は次のことを達成しようとしています:

1) 専門分野およびサービスプロバイダーごとに患者ごとの請求を報告する機能 (毎月、四半期ごと、および毎年)

2) サービス提供者による提供者紹介による請求

3) (1)および(2)の月々の支払による請求

4) (1)および(2)のサービスの月ごとの請求

次元モデルは次のとおりです。

ファクトクレーム

チャージ金額

支払金額

サービス日付キー (FK)

支払日キー (FK)

患者キー (FK)

サービス プロバイダー キー (FK)

施設キー (FK)

参照プロバイダー キー (FK)

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

DimServiceProvider ServiceProviderID (SK)

サービスプロバイダー名

専門

DimPatient 患者 ID (SK)

名前

住所

DimDate

DimFacility 施設 ID (SK、PK)

設備名称

施設地域

施設の状態

質問: 1) 料金と支払いのファクト テーブルを分ける必要がありますか?

2) 参照されたプロバイダー キー (DimServiceProvider も指している) について正しいと考えているかどうかわからない

3) いくつかのディメンション テーブルを結合したり、それらを分離したりするための経験則はありますか? ディメンション テーブルを結合する、またはそれらを分離しておくためのルールは何ですか?

次の階層を検討してください。

(各部門には複数のカテゴリがあり、それぞれに複数の製品が含まれています。)

次元モデリングへのKimballアプローチを使用して、次の列を持つ ProductDim テーブルを作成しました。

DepartmentEF 4.1 を使用して、、、CategoryおよびProductエンティティを ProductDim テーブルにマップしようとしています。関連するクラスの簡略版を次に示します。

問題は、これらのクラスを使用しようとすると、次の例外が発生することです。

System.InvalidOperationException : エンティティ タイプ 'Category' と 'Department' はテーブル 'ProductDim' を共有できません。これらは同じタイプ階層にないか、それらの間で主キーが一致する有効な 1 対 1 の外部キー関係がないためです。

これに対する回避策はありますか? そうでない場合、Entity Framework は次元的にモデル化されたデータベースでうまく使用できますか?

そのため、トランザクション ライフサイクル モデル (または累積ファクト スナップショット テーブル) に基づく Sales Fact テーブルがあり、非常に多くの異なる日付キー列 (販売日、返金日など) があります。日付列ごとに異なるメジャーを作成しました。つまり、空でない販売日のキー列の合計は [販売数] であり、空でない払い戻し日のキー列の合計は [払い戻しの数] などです。の日付キー列が異なる日付キー ディメンションに関連付けられています。販売日ディメンションと返金日ディメンションはロール プレイング ディメンションであり、すべて同じ DimDate テーブルに基づいています。日付に基づかないディメンションは他にもありますが、この例のために単純にしておきます - storeType (小売、e コマースなど) には別の追加ディメンションがあります。

キューブをブラウズすると (ほとんどのユーザーは Excel でキューブをブラウズして探索するため)、[販売数] と [返金数] を列セクションにドラッグし、次に StoreType ディメンションを行セクションにドラッグできます。 、データを次のように適切に表示します。

これは問題ありません。日付フィルターを適用していないため、すべてが表示されます。ファクト テーブルのデータを確認しましたが、確かに数値は正しいです。

しかし、[販売数] と [返金数] の両方に同じ日付フィルターを適用したいので、両方のディメンションをフィルター領域にドラッグし、同じ日付フィルターを両方に適用します。数値は両方の列ですべて同じです。

..両方の日付ディメンションに1つの日付を効果的に適用することで、同じ行のセットにフィルターダウンしていると思うため(同じテーブルからのものであるため)。Fact テーブルから個々の行をクエリして、それらが異なる値を持っていることを確認できるため、これが正しくないことはわかっています。

基本的には、2 つの列を一緒に表示したいのですが、実際には共通点はありません。各列に 2 つの異なる日付フィルターを設定することもできます。つまり、2010 会計年度のすべての売上を表示し、2011 会計年度のすべての払い戻しを表示します。これも、ユーザーが完全に閲覧できるため、測定値を使用できるようにする必要があります。複雑な MDX クエリを実行します。

別のファクト テーブルを作成して、同じデータをトランザクション ファクト テーブルに格納し、それを個別にカウントできると思いますが、多かれ少なかれ同じものをカウントするために 2 つの別個のファクト テーブルを用意しても意味がありません。

これを行う方法はありますか？ヘルプ！！

A source system tracks student attendance for a school district by reporting absence events. Attendance on any particular day can be determined by examining three datasets: school calendar, student enrollment, and absence.

On any given school day, the number of enrolled students in attendance is usually much larger than the number that are absent, so this approach reduces the number of records stored to track attendance significantly.

I am trying to determine the proper way to represent daily attendance in a dimensional model. The most obvious way is to create a factless table with a grain per school day per student, and an attendance dimension that has values for both attendance and absence reasons. This is quite straightforward to work with OLAP, but the downside is the size of the fact table.

For example, for 30,000 students and 188 school days means that there are approximately 0.5 million records per year (if this doesn't seem large enough to be an issue, then consider an example in which attendance must be reported on per period rather than per day). Contrast this to a fact table that records only absences and the number is considerably smaller. However, if I do this, then I am not sure how to build cubes that aggregate daily attendance facts.

The specific OLAP technology being used is SQL Server Analysis Services 2008 R2. Any thoughts?

スター スキーマの設計について読んでいると、多くの人がさまざまな種類のディメンション テーブルにさまざまな名前を使用していることがわかりました。

各タイプの名前と簡単な説明をリストしてください。エイリアス名もリストされている場合。

スター スキーマを使用してデータ ウェアハウスを作成しています。すべてのディメンション テーブルを正常に構築できましたが、ファクト テーブルで行き詰まっています。Sales テーブルを Fact テーブルとして作成する必要があります。SalesKey、OrderKey、ProductKey などがあります。すべての注文は販売であるため、各注文には一意の SalesKey がありますが、各販売には複数の製品があります。

このテーブルを作成するのに最適なものは何ですか?

みたいなの作ればいいのかな

だから私は出荷のための次元データベースを持っています:

貨物には多くのパッケージが含まれています。パッケージには多くの料金が含まれています。

これはディメンションであり、料金は私が最も関心のあるデータであるため、3 つのテーブルとそれらの多対 1 の関係を 1 つの料金ファクト テーブルにフラット化しました。これは、それぞれが 1 ポンドの重さの 2 つのパッケージを含む 1 つの出荷の簡単なスナップショットです。

パッケージの重量をクエリ可能にするために、料金の粒度までプッシュする必要がありました。これにより、集計で問題が発生します。各パッケージには 1 ポンドのパッケージ重量が適用され、出荷の場合は 2 ポンドになります。この方法で重みをメジャーとして集計する方法が見つかりません。私は SSAS と OLAP に非常に慣れていないので、次に何を試せばよいかわかりません。どんな提案でも大歓迎です。

数日前に Oracle Warehouse Builder を使い始めました。ソース テーブルの日付の一部をディメンションとして使用したいと考えています。ウィザードを使用して時間ディメンションを生成しましたが、ソース テーブルに保存されている日付を生成された時間ディメンションに接続する方法がありません。どうすればいいですか？私は何かを誤解していると確信しています。

ありがとう！

ファクト テーブル (次元的にモデル化されたデータ ウェアハウス) のメジャー フィールドで NULL 値が通常 0 としてマップされる理由は何ですか?

たとえば、StudentID、Address、City、State、Zip を含む Student テーブルと、説明、クレジット、料金、日付を含む class テーブルなど、2 つのテーブルから始まるスター スキーマを作成する方法を誰かに説明してもらえますか?

各テーブルから主キーを取得し、それらを外部キーとしてファクト テーブルに配置することは理解していますが、2 つのテーブルから始めて 5 つのテーブルを持つ実際のスターを作成する方法はありますか?

教授というテーブルを追加した場合、それはディメンション テーブルと見なされますか、それとも日付テーブルはディメンション テーブルと見なされますか?