スタースキーマ(基礎)
スタースキーマ wikipedia スタースキーマ または 星型スキーマ はデータウェアハウスに利用される最も単純なスキーマである。スタースキーマには唯1つもしくは少数のファクト表と複数のディメンション表が含まれる。スタースキーマはスノーフレークスキーマの一種であるが、多くの用途で利用されている。 スタースキーマは、ディメショナル・モデリングをリレーショナル・データベースで実装したものになる。 詳しくは、ディメンショナル・モデリング にまとめている。 この記事は、あなたが「様々な指標を様々な軸で、レポートを見たい」類の要望に応えるためのスキーマ設計に困っている場合に役立つだろう。 ディメンションテーブル設計 サロゲートキー スタースキーマでは、各ディメンションテーブルに、サロゲートキーを割り当てる。このキーは、業務システムで使われているキー（ナチュラルキー）とは別のものを使用し、データウェ
複数スタースキーマ
複数スタースキーマ(Multiple star schema) 1つのファクトで、全ての分析対象がカバー出来ることは稀である。ほとんどのケースで複数のファクトテーブルが必要になるだろう。本当に価値ある分析は複数のプロセスを横断した分析である。これを誤った方法で実現するとどうなるか？どうすれば良いのかを見ていく。 スタースキーマの作り方に関しては、別の記事にまとめている 。 発生タイミングが異なるファクト 2つ以上のファクトがあったとする。それらは同時に発生しないファクトである場合、異なるファクトテーブルに配置するべきである。誤って単一ファクトテーブルにまとめられると、個々の分析が困難になる。もし分けていれば個々に分析が可能になる。 ある営業部門で以下のような分析要件があったとする。 日付、顧客、製品別注文数量の分析 日付、顧客、製品別出荷量の分析 ディメンションは日付と顧客。ファクトは製品
スロー・チェンジ・ディメンション(Slowly Changing Dimensions)
スタースキーマ(基礎) の記事の知識を前提としています。 ディメンションテーブルのソースとなるデータは、運用している業務システムのものである。これらのデータは、データウェアハウスに移され、それぞれのディメンションテーブルに格納される。 しかし、この情報は運用の過程で変更されることがある。例えば、会員の生年月日を直したり、住所変更などである。この時に運用システム側は、変更履歴を追うようにする。または素直に上書きしてもよい。いずれにしても、ディメンションテーブルは、どのように分析をしたいかによって、変更に対応することが必要になる。 ディメンションの設計において、ソースデータの変更をどのように表現するかを決めることは重要で、これらを「スロー・チェンジ・ディメンション」と呼ぶ。これはファクトに比べるとディメンションはゆっくりと変更されることから由来している。 データ変更がされた場合、様々な対応が考
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
