問題タブ [star-schema]

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

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

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

サーバーテーブルにサーバー名に関する情報が含まれるスタースキーマモデルがあります。情報テーブルには、特定のサーバーに必要な情報が含まれています。実際のデータテーブルには、どのサーバーにどの情報が含まれているかに関する情報が含まれています。

今私が抱えている問題は、JDBCを使用してデータをデータテーブルに挿入しようとしていることです。しかし、スター スキーマ モデルの実際のデータ テーブルにデータを追加する方法がわかりません。データベースに接続して情報ごとに毎回挿入する必要がありますか、またはデータベースと一度だけ通信することでそれを行うことができる直接的な方法があります。これは、各サーバーのすべての情報を取得するコードです。IndexData は、Oracle データベースに値を挿入するクラスです。

スター スキーマの設計について読んでいると、多くの人がさまざまな種類のディメンション テーブルにさまざまな名前を使用していることがわかりました。

各タイプの名前と簡単な説明をリストしてください。エイリアス名もリストされている場合。

スター スキーマを使用してデータ ウェアハウスを作成しています。すべてのディメンション テーブルを正常に構築できましたが、ファクト テーブルで行き詰まっています。Sales テーブルを Fact テーブルとして作成する必要があります。SalesKey、OrderKey、ProductKey などがあります。すべての注文は販売であるため、各注文には一意の SalesKey がありますが、各販売には複数の製品があります。

このテーブルを作成するのに最適なものは何ですか?

みたいなの作ればいいのかな

スター スキーマの正しいディメンションにも外部キーと主キーの関係がありますか?概念的に正しいですか?Dateware の実装で混乱しているので助けてください。はいの場合、どのような場合に、いいえサンクスと同じ

映画レンタル データ ウェアハウスを設計しています

ファクト テーブルを映画のレンタル/返品で構成したいのですが、混乱しています。

映画はどこの店でも返品できるので、それを示す必要があります。

私はこれらの次元を持っています：時間、顧客情報、映画情報、そして店

別々のレコードである場合、レンタルまたは返品の場合、どこに表示されるかわかりませんか?

この情報を表示するためのスター スキーマを設計するためのオプションは何でしょうか。それをどこに置くべきかわかりません。私の頭は爆発寸前です。

私はデータ ウェアハウス設計の初心者です。私はいくつかの理論を持っていますが、最近、OLAP キューブの設計に関する実際的な問題に遭遇しました。スタースキーマを使用しています。
2 つのディメンション テーブルと 1 つのファクト テーブルがあるとします。

Dimension Gazetteer:
dimension_id
country_name
Province_name
district_name

ディメンション デバイス:
dimension_id
device_category
device_subcategory

ファクト テーブル:
Gazetteer_id
device_dimension_id
ハザード ID (メジャー列)
area_m2 (メジャー列)

「ビジネス オブジェクト」(実際には地雷原) は、複数のデバイスを持つことができ、単一の場所 (Gazetteer) に配置され、X 平方メートルを占有します。
そこで、どのデバイス カテゴリがあるかを知るために、次のようにハザードのある各デバイスごとにファクトを作成しました。

私は「ハザードの数」という尺度をハザード ID の個別カウントとして定義しました。
また、area_m2 の合計として「総占有面積」メジャーを定義しました。
これで、ディメンション ガゼッターとデバイスを使用して、特定のディメンション メンバーにいくつの危険があるかを知ることができます。
しかし、問題は area_m2 です。これは合計として定義されるため、実際の面積の n 倍の値になります。ここで、n はハザード オブジェクトのデバイスの数です。たとえば、上記のデータでは 18000m2 になります。
この問題をどのように解決しますか？

Pentaho スタックを使用しています。

前もって感謝します

既存のSQLServerデータベース用のデータウェアハウスを構築する必要があります。私はすでにスタースキーマディメンションとファクトテーブルのデザインを持っています。私の質問は：

SQL Server 2008 Enterpriseには、データをトランザクションデータベースから新しいデータウェアハウスデータベースに変換するのに役立つツールがありますか？データをクリーンアップしてウェアハウステーブルにデータを入力するのに役立つツールを探しています。私は以前、Oracleデータベースを使用するアカデミック環境でこれを実行しました。この場合、SQLを使用してすべてを「手動で」実行する必要がありました。

開発中のスター スキーマの特定のディメンションに何を入れるべきか、ファクト テーブルに何を入れるべきかを判断するのに苦労しています。

例として、プロジェクトが不動産管理会社の住宅を追跡しているとしましょう。さまざまな日付、賃借人、契約などのディメンションはすべてかなり簡単です。家の場合、データがどこにあるかに関係なく、現在の所有者、現在の賃借人、現在の賃貸契約、および近隣、住所、現在の賃貸価格、現在の市場価値などを追跡する必要があります。 . 所有者、賃借人、および契約自体が次元であることに注意してください (また、近隣と住所も次元である可能性がありますが、私はそれらをあまり気にしません)。

家について保持されている多くのデータは、クエリのフィルター処理や、キューブの行ヘッダーと列ヘッダーに使用されます。その一部は、補助的な情報としてのみ必要であり、家ごとに見られますが、全体としては必要ありません.

データとそれをどうする必要があるかを考えると、(少なくとも) 3 つのオプションがあります。

• DimHouse: house テーブルはディメンションであり、ファクト テーブルの方が見栄えがするかもしれない多くの属性がありますが、それらは参照とフィルター処理に使用されるため、ここにある必要があります。現在の賃借人のような属性には、スノーフレーク/アウトリガーが必要になります。
• FactHouse: 他のファクト テーブルに結合されたハウス情報の累積スナップショットを持ちます。おそらく、トリミングされた DimHouse をブリッジとして使用します。これは私には奇妙に思えますが、事実のように見えるものを事実テーブルに入れます。
  • 現在の所有者、現在の賃借人などを関連するファクト テーブルに入れ、それらの事実を所有者/賃借人/その他として最新の状態に保ちます。変更します (これも奇妙ですが、私たちをスター スキーマの土地にとどめます)。

ということで、次元ルートを下ってきました。胸焼けしますが、目標を達成します。データを整理するためのより良い方法があるかどうかを知りたいだけです。冗長性 (類似したデータを持つファクト テーブルとディメンション テーブルを使用するなど) やスノーフレークは、それらが意味を成し、物事を行うための最良の方法 (「最善」の値の場合) であれば気にしません。

次の形式のファクト テーブルを考えてみましょう。

Fact1各次元に 1 つの列インデックスがあります。Dim1時間の範囲までの粒度を持つ時間ディメンションであると想定されます (たとえば、2011 年 3 月 12 日の午後 2 時から午後 6 時の間)。Dim1 内の列をカバーするものとして含めるDim2と便利でしょうか? Dim3または同様にそれらのいずれかで？

より一般的には、他のディメンション テーブルの FK 列を特定のディメンションのインデックスのカバー列として含めると便利でしょうか?

注: ファクト テーブルについては、特定のファクトを一意に識別する必要はないと想定しています。したがって、主キーまたは代理キーがありません。(Dim1, Dim2, Dim3) が常に一意のタプルであることによって、一意性が保証されます。