問題タブ [star-schema]

次のようなエネルギー消費のファクト テーブルがあります。

カレンダー テーブルは Kimball の推奨事項に従って構造化されており、ユーザーがローカル時間と UTC 時間でクエリできるように 2 つのカレンダー ID を用意している理由は、データ ウェアハウス ツールキットの推奨事項です。

これで問題はありませんが、夏時間が始まると問題が発生します。

粒度が 30 分単位であるため、時計が変わるとファクト レコードが重複します。

また、クロックが逆方向に変化すると、データにギャップが生じます。

どうすればこの状況に対処できますか?

重複した値を平均して代わりに保存する必要がありますか?

また、データにずれがある場合は、ずれの直前と直後の平均をとればいいのでしょうか？

バスケットボール選手とその統計のデータベースを設計したいと考えています。この種のタスクには、スター スキーマ データベースが最適であると聞いています。

私が間違っていなければ、スター スキーマには薄暗いテーブルとファクト テーブルがあります。

スコア/統計をファクト テーブルとチーム、年、コーチ、カンファレンスなどにロードする予定です。これは受け入れられるアプローチですか？

私はデータベース設計の初心者なので、できれば助けてください。または、私のプロセスについての考えを教えてください。ありがとう！

スター スキーマ データ ウェアハウスにデータをインポートする方法を見つけるために、Web 上のあらゆる場所を検索しました。スター スキーマとデータ ウェアハウスの設計についてはオンラインで多くの情報が説明されていますが、データがどのように DW に読み込まれるかについては説明されていません。これが私がこれまでに行ったことです：

各選手の高校バスケットボールの統計を応用しようとしています。

私は持っている：

1. すべての選手の名前、身長、ポジション、背番号のリスト
2. すべての高校のリスト
3. すべてのスケジュールのリスト
4. 会議のリスト
5. 今年の各プレーヤーの統計 (ポイント、リバウンド、スティール、プレイしたゲームなど)。

統計は私のファクト テーブルであり、残りは私の暗いテーブルであると仮定します。

今、百万ドルの質問 - 一体どのようにしてデータをそのフォーマットに適切に変換するのでしょうか?

それらをそれぞれのテーブルに単純にインポートしようとしましたが、それらがどのように接続されているかわかりません。

例: 800 人のプレーヤーと 400 の学校があります。各学校には一意の ID (主キー) があります。プレイヤーを薄暗いプレイヤーにアップロードし、学校を薄暗い学校にアップロードします。では、それらをどのように接続すればよいでしょうか。

助けてください。前もって感謝します。とりとめのない申し訳ありません:)

一部の従来の OLAP キューブを適切に再設計するには、一般的なスケーラビリティと、OLAP キューブの速度の特定の要因を理解する必要があります。

• 一般: OLAP キューブは、行​​と列 (属性) に対してどのようにスケーリングしますか? たとえば、属性番号に応じて、n^2 または n^3 のようなものを想定します。

• 階層的な順序の影響: 階層的な順序は、計算、保存、および応答時間にどのように影響しますか? たとえば、日、月、年の階層は、3 つを別個の独立した属性と見なすよりもはるかに高速であると想定します。

• 特殊なケース - 空の属性と冗長な属性: 空の属性はキューブの計算と使用速度にどのように影響しますか? 冗長な属性の影響はどうですか? たとえば、後者に関しては、属性 country = USA および country code = US を持つことは冗長であると考えます。

クエリ設計の問題に直面していて、問題に対する私のアプローチが不必要に複雑であるかどうかわからない:

私はファクトテーブルを持っています:

現在、それに対していくつかの分析クエリを実行しています。そのうちの 1 つ (たとえば) は次のようになります。

おそらくわかるように、このクエリは、特定の時間バケット分布のメッセージの「スコア」属性の平均を計算し、それと並行してバケット全体の累積を計算します (ウィンドウを使用)。

次にやろうとしているのはmessages.text、各バケットの平均に最も近い上位 5 つ (たとえば) を見つけることです。

現在、私が持っている唯一の計画は次のとおりです。

ウィンドウ関数内でウィンドウ関数を使用することを含む設計を考え出す最初の試みであり、それが機能(rank() over (partition by start_time, order by score - avg(score) over (partition by start_time))するかどうかを確認するつもりさえなかったので、これを命令的に段階的に書き留めた理由.

正しい方向に進んでいるかどうかについてアドバイスをいただけますか?

次元モデリングまたはスター スキーマに関する洞察が必要です。

通常、データ ウェアハウスを設計するときは、ファクト テーブルとディメンション テーブルを用意します。

ただし、ディメンションをファクト テーブルに埋め込むことには意味があります。特に、他の属性を持たず、ほとんど値を変更しない単純なディメンションの場合。

実際のテーブルにディメンションがあると、クエリが非常に高速に実行され、ディメンション テーブルを個別に維持する必要がなくなり、ETL を実行するときにディメンション テーブルを検索する必要がなくなります。

次元を事実から分離しておく考慮事項はありますか?

SQL Server 2008 r2 に test1 データベースを作成してから、別の test 2 db ..

テスト 2 db では、スター スキーマ erd を作成します。

ここで、test1 db からデータを選択し、test2 db で実行したい.. etl のように.. 抽出、変換、ロード...

ここにクエリがあります

この uery データを実行すると、テーブルに挿入されません

だから私はこれをどのようにやったのですか？

MS SQL サーバー

スタースキーマを作っています。PK'sテーブルにandを設定しました。FK現在、制約を削除し、テーブルを切り捨て、制約を再度追加し、テーブルを再作成するプロシージャを作成しようとしています。制約を削除しようとすると、次のエラーが表示されます。

「制約はテーブル、外部キー制約PK_TIMEDIMによって参照されています。制約を削除できませんでした。」SalesFactTableFK_SALESFACTTABLE

編集: 1 つの問題が解決されました。もう一つ見つかりました。などの不思議な自動生成があることを除いて、同じエラーが表示さFK'sれFK__SalesFact__CUST___19DFD96Bます。

私が間違っていることを教えてください。