ファクトテーブルの粒度に関する私の理解は正しいですか？

私と私たちの会社の別の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である必要があるのか​​を説明してください。

編集：まあ、私は事実の私の最初の理解が間違っていることを学びました。粒度は毎月ではありません。粒度はトランザクションレベルです。つまり、これはMONTH_YEAR（つまり、実際には財務報告期間）内で、複数の支払いおよび回復トランザクションが発生することを意味します。それらは、日付またはトランザクション日付で掲載されます。しかし、ビジネスが見る以前のレポートのために、また、これは、トランザクションデータ（1行あたり1行）と予約月間残高（1行あたり1行）の両方を配置したかったため、レガシーシステムにデータがどのように格納されているかという理由によります。 ）。

それを知ってみると、問題は最初から疑っていた粒であるほど、加法性と非加法性ではなく、半加法性でさえあることがわかりました。私たちのDBAチームはこれについてプロジェクトチームと話し合い、同じ事実に2つの異なる穀物を入れようとしていると報告しましたが、これは正しくありませんでした。すべてのトランザクションが月次レベルになるため、トランザクションを月次レベルにロールアップして、支払い、回収、および月次準備残高（つまり、準加法ファクト）を提供できるようにする必要があります。または、トランザクションレベルの粒度を維持するために、準備残高をトランザクションに分割する方法を見つける必要があります。または、事実を2つの事実に分解する必要があります。1つは、予備残高の月次レベルにすることができます。もう1つは、支払いと回収のトランザクションレベルにすることができます。（彼らも月額レベルの事実で支払いと回収を月額レベルで置くことができなかった理由はありません。ビジネスニーズに依存します。）

私が学んだことを踏まえて、私はトーマスの答えを正しいものとしてマークします。ただし、元の質問から始めたディスカッションは他の人が学ぶための良いものだと思うので、質問の元の部分はそのままにしておきます。また、ニカダムの答えに対する報奨金を授与するつもりです。それにより、加法的、非加法的、および準加法的事実について多くのことを学び、 次元モデリングに関して私が持っていた多くの誤解を修正しました。

コードのにおいに対するあなたの直感はよく鍛えられています。

あなたが扱っているのreserves は、キンボールが「準加法的事実」と呼ぶものです。それは四半期または年にうまくロールアップしません。

これに対する典型的な解決策は、2つのファクトテーブルを用意することです。1つは追加ファクト（paymentsあなたの場合）用で、もう1つは非追加ファクト用です。非加算的な事実は、実際には月レベルで粒度を持っている必要はありません。それらをその日まで保存しておけば、問題なく機能します。

非加法ファクトreserveは、他のファクトとは異なる方法で照会されます。あなたがしなければならないビジネス上の決定があります：reserve年レベルで何が意味するのですか？それはその年の最後の月ですか、それともその年の月の平均ですか？どちらを選択しても、これをモデル化するための解決策はキンボールの本の非加法事実に関する章の下にあります。

Analysis Servicesのようなキューブ製品を使用する場合、すべてを1つのテーブルに格納しても、集計を「そのまま」使用できることに注意してください。ただし、リレーショナルクエリの記述が簡単になるように（そしてファクトの読み込みも簡単になるように）、物事を分離しておくことを好みます。

あなたは正しいです：「異なるファクトが同じファクトテーブルに混在していてはなりません」。

ただし、月末の引当金残高と月末の支払額は同程度です。それはちょうど事実の一つは、セミアディティブ。ファクトのタイプ（追加かどうか）はテーブルの粒度を定義しません。

あなたの説明から、私はあなたの穀物を「月次クレームスナップショット」とみなし、ファクトテーブルを「定期的なスナップショットファクトテーブル」にします。

で、この記事キンブルは、同じファクトテーブル中の添加剤とセミアディティブ事実の例を持っています。

データウェアハウスツールキット（116ページ）からの準加法ファクトを含む定期的なスナップショットの例を次に示します。

ベストプラクティスは、最低限のアトミックレベルでの準備金（支払いと調整）のすべての変更を反映するトランザクションファクトテーブルを用意することです。クレームを処理するとき、多くの場合、アトミックレベルはクレームではなくサブクレームです（保険会社には独自の用語がある場合があります）。通常、各サブクレームは、クレームの異なる当事者と、各当事者の支払い/引当金を表します。たとえば、被保険者への支払いはないが、会社の負傷者による無保険への支払い、および病院と弁護士への支払いがある場合があります。

BIツールのパフォーマンスに応じて、トランザクションファクトテーブルを直接使用して、毎月の支払いと残高を取得できます。または、トランザクションの日次または月末に定期的なスナップショットファクトテーブルを更新することもできます。

準加法ファクトの処理能力は、使用しているBIレイヤーによって異なります。準加法的事実を簡単に処理できるツールとそうでないツールがあります。

キンボールのメインブック（データウェアハウスツールキット）には、保険に関する全章（16）があります。