問題タブ [star-schema]

ETL ツールを探していたところ、Google で Pentaho Kettle について多くの情報が見つかりました。

また、スター スキーマで実行するデータ アナライザーも必要です。これにより、ビジネス ユーザーはさまざまな種類のレポートやマトリックスを操作して生成できます。再び PentaHo Analyzer は良さそうです。

アプリケーションの他の部分は Java で開発され、アプリケーションはデータベースに依存しない必要があります。

Pentaho で十分か、確認すべき他のツールがあります。

Data Warehouse Toolkitを読んだばかりで、スター スキーマのモデリングは初めてです。

クライアントとクライアント以外の従業員との電話会議に参加するビジネス プロセスがあります。

「オーディエンス」と呼ばれる私のファクト テーブルには、出席者が通話に接続されていた時間と、この通話への接続にかかるコストの測定値が含まれます。粒度は「電話会議への個別接続」です。

準拠したクライアント ディメンションを使用して、非クライアント ディメンションを (まだクライアントではない発信者のために) このように作成する必要があります (この質問の一部ではないディメンションを省略します)。

または、次のように、準拠した Client ディメンションに非準拠の Attending ディメンションを関連付けた方がよいでしょうか。

または、このようなビジネス プロセスをモデル化するためのより優れた標準的なメカニズムはありますか?

編集：

上記のモデル 2 を使用して、クライアント ディメンション テーブルと対応するディメンションの上にビューを作成して、それが 1 つのディメンションにしか見えないようにするにはどうすればよいでしょうか?

それは、以下のダミールの答えに代わる許容可能なものですか?

スター スキーマ、ファクト/デミンション テーブル、データをすばやくレポートするための select ステートメントについてよく読んだことがありますが、スター スキーマへのデータ入力の問題は私にはよそよそしいように思えます。スタースキーマデータベースにデータを「理論的に」入力するにはどうすればよいですか? ファクト テーブルを維持しながら。巨大なストアド プロシージャ内の一連の INSERT INTO ステートメントで、20 個のパラメーターが唯一のオプション (およびファクト テーブルにデータを入力する方法) です。どうもありがとう。

この質問をする目的で単純化しようとしました。うまくいけば、これは理解できるでしょう。

基本的に、時間ディメンション、別のディメンション、および階層ディメンションを持つファクト テーブルがあります。質問のために、階層次元が郵便番号と州であると仮定しましょう。他の次元は説明的なものです。それを「顧客」と呼びましょう。50 人の顧客がいると仮定しましょう。

すべての顧客が時間ディメンションで毎日少なくとも 1 つのファクト行を持つ郵便番号が少なくとも 1 つある州のセットを見つける必要があります。郵便番号に 49 人の顧客しかいない場合、私は気にしません。50 人の顧客のうち 1 人でも、郵便番号に 1 日でも価値がなければ、私は気にしません。最後に、どの郵便番号が州の選択に適しているかを知る必要もあります。すべての郵便番号に完全なデータ セットが含まれている必要はありません。少なくとも 1 つの郵便番号が含まれている必要があります。

複数のクエリを作成し、クライアント側で処理を行うことは気にしません。これは、1 日に 1 回だけ生成する必要があり、キャッシュできるデータセットです。単純なブルートフォース反復以外に、複数のクエリでそれを行う特にクリーンな方法は見当たりません。また、データセットには非常に多くの「郵便番号」があります (実際には郵便番号ではありませんが、階層の下位レベルには約 100,000 のエントリがあり、最上位レベルには数百のエントリがあるため、zipcode->state は合理的な例えです)

私はデータ ウェアハウスの初心者であり、スター スキーマの構築について簡単な質問をしたいと思っています。

ファクト レコードが 1 つのディメンションと 1 対多のリレーションシップを持つファクト テーブルがある場合、これをサポートするためにスター スキーマをどのようにモデル化できますか? 例えば：

• ファクト テーブル: POS エントリ (単位は DollarAmount です)
• ディメンション テーブル: プロモーション (これらは、販売が行われたときに有効な販売プロモーションです)

状況として、1 つの POS エントリを複数の異なるプロモーションに関連付けたいと考えています。これらのプロモーションは、非常に多くのプロモーションがあるため、独自のディメンションにすることはできません。

どうすればいいですか？

私のファクト テーブルには、彼が受講したコースのユーザー スコアが保持されます。レポートに表示する必要があるコースの詳細の一部は、複数のテーブル (実際の OLTP データベース内) から取得されます。
そのコース エントリの正規化されていないバージョンをディメンション テーブルに作成する必要がありますか?
または、ファクト テーブルをコース テーブルに直接結合するだけですか?このコースを説明する他のテーブルに結合します (course_type、このコースを作成した学部など)。

私はデータウェアハウジングに不慣れですが、私の質問は比較的簡単に答えられると思います。ディメンションテーブル「product」を使用してスタースキーマを作成しました。このテーブルには、列「PropertyName」と列「PropertyValue」があります。したがって、寸法は次のようになります。

等々。

私のファクトテーブルでは、常にディメンションの代理キーを使用しています。PropertyName列とPropertyValue列の原因により、自然キーが一意ではなくなり、識別できなくなったため、ファクトテーブルの行が多すぎます。

私の質問は、プロパティ列をどうすればよいかということです。各プロパティを、寸法サイズ、寸法色などの別々の寸法に配置するのが最善でしょうか？私は約30の異なるプロパティを取得しました。または、ファクトテーブルのプロパティごとに列を作成しますか？または、すべてのプロパティで1つのディメンションを作成しますか？

助けてくれてありがとう。

私たちは、その作業単位を受け取ってからその作業単位を完了するまで、その作業単位の割り当てを追跡するシステムを持っています。

作業単位には、ソース、タイプなどのいくつかの属性があります。これらは、モデル化にかなり問題ありません。これらは、それらの性質とユーザーがレポートをどのように望んでいるかに応じて、事実の次元または単なる属性のいずれかになる可能性があります。それらの上に。

問題は配分です。

作業単位は複数のチームを通過する場合があり、それらのチーム内で複数の個人を通過する場合があります。その作業単位に対してアクションを実行できます。

そして、私たちのユーザーはこれについて報告することに興味を持つでしょう.

たとえば、特定の期間にチームごとに割り当てられた作業単位の数。

私はデータ ウェアハウジングを初めて使用するので、これをモデル化する方法がわかりません。これまでに特定した候補は次のとおりです。

1) ゆっくりと変化する次元

チームとチーム内の人物への割り当てには、おそらくタイプ 4 を使用します。

2) スナップショット

いつアカウントに含まれていたかを示すメイン ファクトのタイプ 4 の from/to 属性を持つため、キューブにデータを入力するファクト テーブルで各作業単位が複数回発生します。

3) スナップショットの蓄積

私はこれが何であるかを理解しているかどうか確信が持てませんし、関連性があるかどうかもわかりません。

この SCD、チーム、チーム メンバー、ステータス、作業単位のキュー割り当てなどのようなものはたくさんあります。したがって、それはかなりの数の SCD のようです。

オプションのリストで見逃したものは他にありますか? 何かを根本的に誤解していませんか？

だから、私はディメンションに何を入れるか、ファクトテーブルに何を入れるか、そしてこれをどのように達成するかを理解したと思います。ここで、このディメンション「product」とディメンション「productProperties」があるという問題が発生しました。これを分割する必要がありました。そうしないと、「製品」の自然キーが一意でなくなります。私は この質問でこれを尋ねました。

したがって、私の「productProperties」ディメンションテーブルは次のようになっているはずです。素材| サイズ

1.）これを実現するには、「色」、「素材」、「サイズ」などの値の可能なすべての順列を作成する必要がありました。

これは2億行をはるかに超えていたので、これを分割することにしました。現在、ディメンション「Color」があります。これは、実際には「color」、「colorFront」、「colorBack」の列で構成されています。

2.）それは問題ないと思いますが、「surrogate_key」列と「value」列のみで構成されるディメンション「size」についてはどうでしょうか。

私は（他の質問で与えられた読み方の推奨事項で）「縮退ディメンション」について読みました。これは、ファクトテーブルの「単一列ディメンション」を1列にすることを意味します。ファクトテーブルに約5〜6の余分な列が追加されるため、これは私には少し実用的ではないようです。

これを行う必要がある場合はどうなりますか？

3.）これらの縮退したディメンションはファクトテーブルの主キーの一部ですか？

最も重要な質問：ファクトテーブルに製品のエントリがありますが、ディメンションのすべての列に一致しないか、すべてのディメンションにまったく一致しません。つまり、「color」プロパティを持つエントリ/製品がある可能性がありますが、「colorFront」または「colorBack」はありません。'color'、'colorFront'、および'colorBack'のすべての順列を作成したので、ファクトテーブルにデータを入力しようとすると、製品にプロパティ'color'しかない場合、複数の代理キーが取得されます。ファクトテーブルでしょ？

4.）ファクトテーブルをクエリするときに、これらの重複を除外する必要がありますか？それともこれはまったく間違っていますか？

もちろん、次元「色」を3次元に分割することもできます。しかし、その後、いくつかの列にNULL値を持つエントリを取得します。一部の寸法をまったく使用しないエントリ/製品についても同じことが言えます。

5.）これらのNULL値を処理する方法は？

助けてくれてありがとう。

医療ソフトウェアの分析を実装しています。処理するデータは、主に予定に関するものです。レポートを生成するためのスター スキーマを実装する予定です。いくつか疑問があります

1. 予定が後でキャンセル済みとしてマークされるように、データが変更される可能性があります。スター スキーマのデータを変更することはお勧めできません。そうでない場合、より良いアプローチは何ですか。
2. ファクト テーブルへのデータは、データがメイン データベースに追加されるときにバックグラウンド タスクによって挿入されます。再投稿はほとんどいつでもアプリケーションで表示されるため、ファクト テーブルへのデータの絶え間ない挿入は問題です。
3. 私はそれを mysql に実装することを計画しています。誰かがこの種の構造を持つ mysql のパフォーマンスに関連する投稿を教えてくれれば、それは素晴らしいことです。また、このスキーマ Innodb または Myisam を実装するのに適したエンジンはどれですか

ありがとう。