5

ディメンション（SiteItem）には2つの重要な事実があります。

perUserClicks 
perBrowserClicks

ただし、このディメンション内には、属性列に基づく値のグループ（AboveFoldItems、LeftNavItems、OnTheFlyItemsなどのグループを呼び出します）があり、それぞれにそのグループに固有のファクトがあります。

AboveFoldItems: eyeTime, loadTime
LeftNavItems: mouseOverTime
OnTheFlyItems: doesn't have any extra, but may in the future

次のファクトテーブルスキーマは大丈夫ですか？

DateKey   
SessionKey
SiteItemKey
perUserClicks 
perBrowserClicks
eyeTime
loadTime
mouseOverTime

一部の列のみが一部のディメンションキーに関係しているため、少し無駄に思えます（無関係なファクトはNULLのままです）。しかし...これは一般的な問題のように思われるので、これには一般的な解決策があるはずですよね？

4

3 に答える 3

4

私はこれに関するDamirの回答に概ね同意していますが、特定のケースではファクトテーブルが非常に狭いため、NULLを保持するというAaronの主張にはまだメリットがあります。

特定のサブジェクト領域にいくつかのスタースキーマがあり、すべてではないにしてもほとんどのディメンション（準拠および内部）を共有する複数のファクトテーブルがあります。限定された範囲のディメンションは、企業全体で「適合」とは見なされませんが、「共有内部」ディメンションと呼ばれるものです。

現在、通常、ディメンションが変更されていないようにデータが同時に読み込まれる場合、キーで両方のファクトテーブルを結合できますが、もちろん、サロゲートである場合、ディメンションキーで2つの異なるスタースキーマを結合することはできません。従来のゆっくりと変化する次元で。一般に、サロゲートではなく、ディメンション内の自然キーまたは「ビジネスキー」で別々のスターを結合する必要があります（通常、日付ディメンションの特殊なケースで、変更されず、自然キーしかない場合を除きます）。

2つの星を結合するときは、LEFT JOINを使用する必要があることに注意してください。その場合、おそらく考慮しなければならないNULLが生成されるため、実際には元のモデルに戻ります。 NULL！;-)

追加のファクトテーブルの利点は、テーブルが広く、キーのセットが少なく、データの垂直分割によってスペースが節約され、論理モデルがよりクリーンになる場合に、より明白になります。これは、キーが実際に共有されている場合に特に当てはまります。ある程度まで（ダミーキーまたはNULLキーを1つ持つことは、絶対に良い考えではありません）、これは通常、次元モデリングの問題を示しています。

ただし、Aaronが言うように、極端にプッシュすると、共有キーを持つ各ファクトテーブルに単一のファクト列を持つことができます。つまり、キーのオーバーヘッドがファクトコストを小さくし、実際には偽装されたEAVモデルになります。

また、キンボールの「次元が少なすぎる」状況にあるかどうかも確認したいと思います。SessionKeyとSiteItemKeyに適切なディメンション属性をまとめる必要があるようですが、モデル全体と要件を確認しないと、言うのは難しいですが、カーディナリティが低い、またはスノーフレークディメンションがないユーザーの人口統計があると思います完全なセッションまたはサイトディメンション。

于 2010-03-08T23:56:07.057 に答える
3

洗練されたソリューションは実際にはありません。null許容の列があるか、EAVソリューションを使用しています。私は以前にEAVについて投稿しました（そして読む価値のあるコメントをたくさん生成しました）：

私はいくつかのシナリオでそのモデルのファンですが、ディメンション/属性が頻繁に変更されない場合、それは無料で多くの余分な作業になる可能性があります。列のNULL値は、周囲のコードがそれらを適切に処理できる限り、実際には無駄にはなりません。

于 2010-03-08T20:58:45.600 に答える
1

複数のファクトテーブル（factperUserClicks、factperBroWserClicks、factEyeTimeなど）を持つことができます。

これらのそれぞれには、DateKey、SessionKey、SiteItemKeyがあります。このように、「意味のある」ディメンションキーのみが各ファクトとともに表示されます。

理想的には、DWにNULLがないようにする必要があります。同じファクトテーブルにNULLを保持する場合は、ゼロを使用する方が適切な場合があります。

ディスクスペースを節約する限り、理想的な解決策はわかりませんが、DWでは、とにかく速度と（クエリ）単純さのためにスペースを交換することになっています。

于 2010-03-08T23:05:46.607 に答える