問題タブ [snowflake-schema]

ユーザーが独自の「クエリ」を定義してレポートを生成できるように、既存の OLAP スター スキーマの上に配置できるコントロールを探しています。現在、キューブの上に構築された定義済みのレポートがいくつかありますが、作成したキューブに基づいてユーザーが独自の基準を定義できるようにしたいと考えています。トランザクション テーブルを OLAP キューブのように扱える製品はたくさんありますが、既存のキューブに特化した製品はありません。

編集: はっきりさせておきますが、OLAP キューブについてレポートすると主張する無数のレポート ツールがあることは知っています。問題は、彼らは皆、トランザクション データを見ていると思い込み、独自のキューブを作成しようとしていることです。数億ではないにしても、数千のレコードを含むテーブルがあります。ほとんどのツールは、これだけの量のデータを処理するとクラッシュします。他のツールは信じられないほど遅く実行されます。ビジネスマンをターゲットにしたツールは欲しくない。

スターとスノーフレークのスキーマが何であるかを理解するツールが必要です。ファクト テーブルとは何か、ディメンション テーブルとは何かを伝え、それらの上に UI を作成できるようにしたいと考えています。これはツール ベンダーにとっては解決しやすい問題です。立方体は規格化されたパターンであるという事実を信頼し、それを利用するツールが必要です。開発者を対象としたツールが必要で、自分のデータを実際に管理する方法を知っているという前提から始めます。必要なのは、きれいなレポートを作成するだけで、データの重みで崩れないことです。

売上、請求書、注文、顧客、在庫などに関する一部のローカル ERP 向けのレポート ツールを開始します。

このケースに適したサンプル スキーマ (スターまたはスノーフレーク形式) が存在するかどうか疑問に思うので、強固な基盤を構築できます。

基本的な BI 設計については理解していますが、これが一般的な問題であることを考えると、最初の解決策はあるのでしょうか。明らかに、プロジェクトに合わせていくつか変更する必要があります...

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

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

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

これは単純な倉庫の例です：http： //en.wikipedia.org/wiki/File ：Snowflake-schema-example.png

Fact_SalesにまだDate2_IDがある場合、Date3_IDはこれらの2つの日付が同じDim_Dateディメンションに関連付けられますか、それともDim_Date2ディメンションとDim_Date3ディメンションを（それぞれのスノーフレークスキーマで）作成する必要がありますか？

Sales_fact：
Product_ID（FK）
価格

Dim_Product：
Product_IDProduct_Key 説明
_

私が直面している問題は、複数のカテゴリーに分類できる製品がある場合の対処方法です。カテゴリごとにDim_Productのレコードを繰り返す必要がありますか？

例：

ファクトテーブル：
Product_ID（FK）：1
価格：10.5

Dim_Product：
Product_ID：1
Product_Key：ABC
説明：ラップトップ
Category_ID：1

Product_ID：1
Product_Key：ABC
説明：ラップトップ
Category_ID：2

Dim_Category：
Category_ID（FK）：1
説明：HP

Category_ID（FK）：2
説明：Toshiba

3つのテーブルがあります-

1）学生-私のファクトテーブル（FKADDRESS_IDでアドレスを参照）

2）アドレス-このテーブルには、FKCOUNTRY_ID参照COUNTRYが含まれています

3）国-これには、表示するNAMECOLUMNがあります。（PK ID）

私はこれを書いたが、それが正しいかどうかわからない

基本的に私はStudent（FACT TABLE）をCOUNTRY ConsostsofFactに参加させたい---Def.. then this

私たちのデータウェアハウスは、データソースから蓄積されたデータを使用して（そして蓄積を反転する方法はありません）、スノーフレークスキーマを作成します。対処しなければならない要件は、日付範囲に基づいてレポートを作成するためにスキーマを使用できる必要があることです。

私たちのスキーマは次のようになります（簡略化）：

次のようなレポートデータセットを作成します。

問題は、統計ディメンションのデータがすでに蓄積されており、蓄積を元に戻すことができないことです。ファクトテーブルのおよその行数を計算し、5,250,137,022,180を取得しました。データには約250万の日付範囲の順列があり、累積のため、日付ディメンションとファクトテーブルにそれらを計算する必要があります。SQLのSUM関数は、累積のために機能しません（異なるセットに属する2つの値を追加することはできません）。

計算を実行可能にするために従うことができるベストプラクティスはありますか？スキーマ設計に何か問題がありますか？

オンライントレーニングに関するデータを報告する必要があります。データソースは、10年以上前の部品を使用するレガシーデータプロバイダーであるため、内部ロジックを再構築することはできません。統計ディメンションには、たとえば、Webベースのトレーニング（WBT）でユーザーが達成した進行状況（％）、WBTページあたりの呼び出し数、WBTのステータス（ユーザーの場合、「完了」など）が含まれます。 、 そう。データプロバイダーについて重要なことは、現在の状態のスナップショットを提供するだけです。過去のデータにアクセスすることはできません。

pygameを使ってKochKochスノーフレークを実装したいと思います。

私はhttp://en.wikipedia.org/wiki/File:KochFlake.svgからの次の一連の画像を使用しています

私のアルゴリズムはこれです

1. 三角形を描く
2. サイズの3分の1の三角形の点を計算し、中心線を削除します
3. 外側のポイントを見つけます（上の画像の2番目の図に示されているように）
4. すべてのエンドポイントのリストを作成します
5. ポリゴンを使用してすべてのポイントを結合

私は2番目のステップまで完了しました。しかし、私は3番目のステップで苦労しています-外側のポイントを見つける方法がわからないので-ヒントはありますか？

これが2番目のステップまでの私のコードです

ここに問題があります。（主キーID、製品名、製品ID、ストア名、ストアID、販売日）のような列を持つ販売情報を含む販売情報テーブルがあります。店舗/商品/販売日にドリルアップやドリルダウンなどの分析を行いたい。

私が考えている2つのデザインオプションがあります、

1. 製品名、製品ID、ストア名、ストアID、販売日などの列に個別のインデックスを作成します。
2. データウェアハウススノーフレークモデルを使用して、現在の販売情報テーブルをファクトテーブルとして扱い、製品、店舗、および販売日のディメンションテーブルを作成します。

分析性能を上げるためには、スノーフレークモデルの方がいいと聞きました。しかし、データベース設計の観点から、関連する列のインデックスよりも優れているのはなぜですか？

よろしくお願いします、リン

現在、私は、顧客離れ行動、不正検出、CRM分析を特徴とする倉庫ベースのインテリジェントトランザクション分析バンキングシステムに携わってきました。私たちOracleはデータベースとして使用してきました。これは、分析に使用されるデータマイニングアルゴリズムを備えた完全なデータウェアハウジングプロジェクトです。

銀行の約1000人の顧客の記録があります。モデリングには、スタースキーマ、スノーフレークスキーマ、コンステレーションスキーマのどちらを使用するのがよいでしょうか。スタースキーマとスノーフレークスキーマの基本的な違いを知っています。ディメンションテーブルの正規化はスノーフレーク（別名スノーフレーク）スキーマで発生します。これは、大規模なデータベースの場合に結合するのに問題がある可能性があります。

では、私の場合、どちらのスキーマが適しているでしょうか？データウェアハウジングに携わる経験豊富なプログラマーからの回答を歓迎します。

前もって感謝します！