問題タブ [star-schema]

値の列が1つある単一のファクトテーブルがあり、値のタイプ（メジャー）がディメンションによって定義されているスタースキーマのタイプの名前はありますか？

言い換えると、次のようなテーブルです。

外部キーを介してさまざまなメジャーを表す1つの値列。

このパターンの名前はありますか？

PostgreSQL 9.0 で次の構造を持つテーブルを想像してください。

簡単にするために、1 つのテキスト列だけを取り上げますが、実際には 12 のテキスト列があります。このテーブルには 100 億行あり、各列には多くの重複があります。テーブルは、COPY FROM を使用してフラット ファイル (csv) から作成されます。

パフォーマンスを向上させるために、次のスター スキーマ構造に変換したいと考えています。

ファクト テーブルは、次のようなファクト テーブルに置き換えられます。

私の現在の方法は、基本的に次のクエリを実行してディメンション テーブルを作成することです。

次に、使用するディメンション テーブルを作成します。

その後、次のクエリを実行する必要があります。

すべての文字列を他のすべての文字列と数回比較することで得られる恐ろしいパフォーマンスを想像してみてください。

MySQL では、COPY FROM 中にストアド プロシージャを実行できました。これにより、文字列のハッシュが作成され、その後のすべての文字列比較は、長い生の文字列ではなくハッシュに対して行われます。これは PostgreSQL ではできないようですが、どうすればよいですか?

サンプル データは、次のようなものを含む CSV ファイルになります (整数と倍精度も引用符で囲みます)。

200,000,000行を超えるフラットファイル（CSV）があり、23個のディメンションテーブルを持つスタースキーマにインポートします。最大のディメンションテーブルには300万行があります。現時点では、1台のコンピューターでインポートプロセスを実行しており、約15時間かかります。時間がかかりすぎるので、40台程度のパソコンを使ってインポートしたいと思います。

私の質問

40台のコンピューターを効率的に利用してインポートを行うにはどうすればよいでしょうか。主な懸念は、すべてのノードでディメンションテーブルを同一にする必要があるため、すべてのノードでディメンションテーブルを複製するのに多くの時間がかかることです。これは、将来、インポートを行うために1000台のサーバーを使用した場合、サーバー間の広範なネットワーク通信と調整のために、単一のサーバーを使用するよりも実際には遅くなる可能性があることを意味します。

誰か提案がありますか？

編集：

以下は、CSVファイルを簡略化したものです。

インポート後、テーブルは次のようになります。

ディメンションテーブル1

ディメンションテーブル2

ファクトテーブル

私はデータウェアハウスのスタースキーマと属性階層を研究していますが、本の例には私の理解を確認するためのサンプルデータが提供されていないため、混乱しています。

この本には、次の属性階層を持つ製品のディメンションを持つ販売データウェアハウスがあります。PRODUCT（AllProducts、ByProductType、OneProduct）

下の画像を参照してください。

製品ディメンションテーブルにはどのようなサンプルデータが入りますか？

製品

AllProducts ByProductType OneProduct

？？？

？？？

？？？

私が間違っていない場合、属性はテーブルの列またはフィールドであり、このテーブルのデータがどのように表示されるか理解できません

同じ画像からTimeディメンションを取得すると、データを簡単にサンプリングできます。

時間

年四半期月週

2010 1 1 1

2010 1 1 2

2010 1 1 3

2010 1 1 4

私が混乱しているもう1つのことは、ファクトテーブルでのデータの表示です。この本では、ファクトテーブルに意図的に重複したデータが含まれると記載されています。たとえば、年間の売上高を算出するために、週ごとの売上高はすでに計算されているため、その場で集計する必要はありません。ここで、時間ディメンションに、年、四半期、月、週を一度に表す主キー値1がある場合、ファクトテーブルに1年間の集計値を保持するにはどうすればよいですか？

時間

ID年四半期月週

1 2010 1 1 1

SALES_FACT_TABLE

販売時間ID製品ID

1000 1？

レポート用のデータマートの構築に取り組んでいます。私はこの分野に不慣れで、助けを求めています。

ファクトテーブルと2つのディメンションテーブルがあります。ファクトテーブルには、主キーと2つのディメンションテーブルへの外部キー参照の3つのフィールドしかありません。2つのディメンションテーブルには、1）電話番号と2）内線番号に関連するデータがあります。（これらのディメンションテーブルは情報が異なるため、組み合わせることができません）

ご覧のとおり、私のファクトテーブルには定量的な列がありません。

電話番号と対応する内線番号を表示するレポートを生成したいと思います。

この情報は、2つのディメンションテーブルで結合を実行することで取得できます。

だから私の質問は、レポートにファクトテーブルを使用する必要がありますか？つまり、最初に電話番号テーブルからキーを取得し、ファクトテーブルで結合を実行し、拡張キーを取得して、拡張テーブルで結合を実行する必要がありますか？

また

この場合は可能であるため、2つのディメンションテーブルを結合してレポートを生成するだけですか？

ファクトテーブルを含める必要がありますか？

読んでくれてありがとう。

どんな助けでも大歓迎です。

私は jasperETL を初めて使用し、スター スキーマ データベースに CSV ファイルのデータを入力する必要があります。このタスクを実行する方法を知っている人はいますか? この情報を見つけることができるチュートリアルや本があるかもしれません。インターネットで検索しましたが、これについては何も見つかりませんでした。前もって感謝します。

スター スキーマとスノーフレーク スキーマの基本的な違いは知っています。スノーフレーク スキーマは、ディメンション テーブルを正規化するために複数のテーブルに分割します。スター スキーマには、ディメンション テーブルの「レベル」が 1 つしかありません。しかし、Snowflake Schemaのウィキペディアの記事には、

「一部のユーザーは、従来の多次元レポート ツールを使用して単純なスター スキーマ内で表現できないデータベースにクエリを送信することを希望する場合があります。これは、顧客データベースのデータ マイニングで特に一般的であり、共通の要件は顧客間の共通要素を見つけることです。複雑な基準を満たす製品を購入した人. 特にデータウェアハウスが最初に設計されたときにこれらの形式のクエリの準備が予期されていなかった場合は特に、単純なクエリツールがそのようなクエリを形成できるようにするために、通常、ある程度のスノーフレークが必要になります。」

同じ基になるデータに対して、スノーフレーク スキーマで記述できるクエリをスター スキーマで記述できないのはどのような場合ですか? スター スキーマでは常に同じクエリが許可されるようです。

私は現在のWebアプリケーションの周りにスタースキーマをまとめる方法に固執しています（stackoverflowと同様の構造）。私は持っています：

• 調査には多くの質問があります
  • 質問には多くの投票があります

• 質問には多くのコメントがあります

  • 質問、投票、コメントはすべてユーザーと日付に添付されます

質問を保存して回答できるように、スタースキーマを作成する方法に固執しています。つまり、今日の質問の投票数はいくつですか。質問bは今日、誰からのコメントでしたか？

どんなアイデアも役に立ちます！

前もって感謝します

このパラダイムを学びながら、教育目的で NFL 統計に基づいてデータ ウェアハウスを構築しています。次のモデリングの問題があります。

プレーヤーは、異なるチームで異なる年にプレーできます。同様に、コーチは、キャ​​リアの異なる年に異なるチームを指導できます。プレーヤーは、別の年に別のポジションでプレーする可能性もあります (まれですが可能性があります)。

異なる年の選手、コーチ、チーム間の割り当てをモデル化する最良の方法は何ですか?

さまざまな年の名簿情報をディメンションに格納しますか? たとえば、TimeKey、TeamKey、および CoachKey を持つ DimTeamRoster (チームには 1 人のヘッド コーチしか存在できないため) と、TeamRosterKey、PlayerKey、Positionkey を持つ FactTeamRoster があります。

それとも、TimeKey、TeamKey、PlayerKey、PositionKey を持つ FactTeamRoster を使用しますか? しかし、このファクト テーブルには実際にはメジャーが保存されず、単にその年の割り当てが保存されるだけなので、このアプローチは理にかなっていますか?

他の可能な解決策と、各アプローチの長所/短所/正しさは何ですか?

スター スキーマは、ディメンション テーブルとファクト テーブルで構成されます。

ファクト テーブルには、各ディメンションの外部キーが含まれており、それに加えて「メジャー」が含まれています。この測定値は正確には何を構成していますか?

保存されているのは集計関数の答えですか?