ファクトテーブルの粒度に関する私の理解は正しいですか？
私と私たちの会社の別のDBAは、ベンダーが開発したデータベース設計のレビューを担当しています。ベンダーは、設計の基礎としてキンボールを使用すると述べています。 （注：私はキンボール対インモンなどの議論を探しているわけではありません）彼らは複数の事実と次元を持つマートを設計しました。
公平に言えば、当社は単一のマートを設計したことはありません。私たちは常にコンサルタントにやってもらいました。そして私たちはクラスや何かに送られたことがありません。したがって、倉庫/マート/次元モデリングなどに関する私たちの知識は、私たちが経験したことのほとんど、インターネット上で見つけることができるもの、および自読に基づいています（私たちはInmonとKimballの本を手に入れ、それらを利用しようとしています） 。
ステージは私の知識レベルに設定されたので、デザインの課題に向かいます。
「請求損失統計」と呼ばれるファクトテーブルがあります（これは保険用です）。また、請求の支払い（毎月のレベルまでロールアップ）と、準備金（請求の銀行口座のようなもの）の両方を取得しようとしています。彼らは毎月の支払い額を確認したいと考えています（重要ではありません）。しかし、彼らは準備金の口座の現在の残高を見たいと思っています。
絵の例を挙げます。
クレームの準備金として1000米ドルを設定したとしましょう。これは脇に置かれます（そのため、いくつかの点で銀行口座のように機能します）。
2014年10月には、まだ何も支払いません。したがって、企業は10月末の支払いと準備残高を確認したいと考えています。
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
その後、11月がやってきます。 100ドル、150ドル、75ドルの支払いを行います。彼らは、以下のように、それらの合計額と残高の準備金を確認したいと考えています。
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------
そして、12月の支払いがゼロで、翌年の1月の支払いが$ 200になるとします。
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------
- 122014 - 0.00 - 675.00 -
-----------------------------------------------
- 12015 - 200.00 - 475.00 -
-----------------------------------------------
ここで私は苦労しています。私の理解は、支払いの部分が正しいということです。それらはすべて、各レコード内の月次レベルでロールアップされます。したがって、必要に応じて、年、四半期などにさらにロールアップできます。
ただし、埋蔵量は異なります。バランスです。そして、企業は、各月の残高がどれくらいかを見たいと考えています。ただし、このフィールドで集計することはできません。そうした場合、あなたはいくつかの奇妙な結果を得るでしょう。
どういうわけか、これは私を間違っていると思います。しかし、十分にモデル化した、または十分に知っているとは正直に言えません。私が言えることは、私が知っていることだけです。そして、私が知っていることから、ファクトのすべての値は同じ粒度でなければなりません。
どちらの数値も「月」の細かさは同じですが、何を表すのかという観点からではありません。 1つは、1か月以内の総ドルです。もう1つはバランスです。
これは正しいです？私はこのデザインを押し返してきました。私がそうするのは間違っていますか？事実でこれをしても大丈夫ですか？それとも、悪いデザインの「コードのにおい」の感覚は正確ですか？
任意の助けいただければ幸いです。注：「Xにすべき」とだけ言うのではなく、なぜXにすべきなのかを説明してください。
[〜＃〜] edit [〜＃〜]：まあ、私は事実についての私の最初の理解が間違っていることを学びました。粒度は毎月[〜＃〜]ではありません[〜＃〜]。粒度はトランザクションレベルです。つまり、これはMONTH_YEAR（つまり、実際には財務報告期間）内で、複数の支払いおよび回復トランザクションが発生することを意味します。それらは日付またはトランザクション日付で掲載されます。しかし、ビジネスが以前に参照したレポートと、レガシーシステムにデータが格納される方法が原因で、トランザクションデータ（1行あたり1行）と月間残高（月あたり1行）の両方を配置したかったためです。 ）。
それを知ったとき、私は問題が最初から疑っていた粒だったので、追加的対非追加的、または半追加的ではないことに気付きました。私たちのDBAチームはこれについてプロジェクトチームと話し合い、同じ事実に2つの異なる穀物を入れようとしていると報告しましたが、これは正しくありませんでした。すべてのトランザクションが月次レベルになるため、トランザクションを月次レベルにロールアップして、支払い、回収、および月次準備残高（つまり、準加法ファクト）を保持できるようにする必要があります。または、トランザクションレベルの粒度を維持するために、準備残高をトランザクションに分解する方法を見つける必要があります。または、事実を2つの事実に分解する必要があります。 1つは、予備残高の月次レベルにすることができます。もう1つは、支払いと回収のトランザクションレベルにすることができます。 （彼らも月額レベルの事実で支払いと回収を月額レベルに置くことができなかった理由はありません。ビジネスニーズに依存します。）
私が学んだことを踏まえて、私はトーマスの答えを正しいものとしてマークします。ただし、元の質問から始めたディスカッションは他の人が学ぶための良いものだと思うので、質問の元の部分はそのまま残しておきます。私はまた、ニカダムの答えに対する報奨金を授与するつもりです。それは、加法的、非加法的、および準加法的事実について多くのことを教えてくれ、修正しましたたくさん次元モデリングについて私が持っていた誤解の。
コードのにおいの直感はよく鍛えられています。
reservesで扱っているのは、キンボールが「準加法的事実」と呼ぶものです。それは四半期または年にうまくロールアップしません。
これに対する一般的な解決策は、2つのファクトテーブルを作成することです。1つは加法ファクト（この場合はpayments）ともう1つは非加法ファクトです。非加算的な事実は、実際には月レベルで粒度を持つ必要はありません。それらをその日まで保存しておけば、問題なく機能します。
非加法ファクトreserveへのクエリは、他のファクトとは異なります。あなたがしなければならないビジネス上の決定があります：年レベルでのreserveは何を意味しますか？それはその年の最後の月ですか、それともその年の月の平均ですか？どちらを選択しても、これをモデル化するための解決策はキンボールの本の非加法事実に関する章の下にあります。
Analysis Servicesのようなキューブ製品を使用する場合、すべてを1つのテーブルに格納しても、集計を「そのまま」使用できることに注意してください。ただし、リレーショナルクエリの記述が簡単になるように（そしてファクトの読み込みも簡単になるように）、物事を分離しておくことを好みます。
あなたは正しいです： " 異なる粒子が同じファクトテーブルに混在してはいけません "。
しかし、月末の準備残高と月末の支払いの合計は同じ粒度です。事実の1つは semi-additive です。ファクトのタイプ（追加かどうか）はテーブルの粒度を定義しません。
あなたの説明から、私はあなたの粒度を「月次クレームスナップショット」とみなし、ファクトテーブルを「 定期的なスナップショットファクトテーブル 」にします。
この記事 のキンボールには、同じファクトテーブルに追加ファクトと準追加ファクトの例があります。
The Data Warehouse Toolkit （116ページ）の準加法ファクトを使用した定期的なスナップショットの例を次に示します。
ベストプラクティスは、最低のアトミックレベルでの準備（支払いと調整）のすべての変更を反映するトランザクションファクトテーブルを用意することです。クレームを処理するとき、多くの場合、アトミックレベルはクレームではなくサブクレームです（保険会社には独自の用語がある場合があります）。通常、各サブクレームは、クレームの異なる当事者と、各当事者の支払い/引当金を表します。たとえば、被保険者への支払いはないが、会社の負傷者による無保険への支払い、および病院と弁護士への支払いがある場合があります。
BIツールのパフォーマンスに応じて、トランザクションファクトテーブルを直接使用して、毎月の支払いと残高を取得できます。または、トランザクションの日次または月末に定期的なスナップショットファクトテーブルを更新することもできます。
準加法ファクトを処理できるかどうかは、使用しているBIレイヤーによって異なります。準加法的事実を簡単に処理できるツールとそうでないツールがあります。
キンボールのメインブック（ The Data Warehouse Toolkit ）には、保険に関する完全な章（16）があります。