問題タブ [star-schema]

スター スキーマ設計はデータ ウェアハウスに不可欠ですか? それとも、別の設計パターンでデータ ウェアハウジングを行うことができますか?

投稿されたフォーム データを分析するためのスター スキーマに取り組んでいます。フォーム データが投稿されるサイトは、実際にはフォームをホストするサイトの外部にあるため、フォーム内のデータのみが利用可能になります。非表示のフィールド、元のリファラー、セッション ID などの追加の有用な情報を含めるオプションを提供します。

正規表現を使用して特定のデータ型に一致させ、郵便番号などの特定の次元に引き出すことができます。

次元の恣意的な性質に対処するための解決策があります。それは素晴らしいものではありませんが、うまくいくでしょう。

私が抱えている問題は、ファクト テーブルに何が入るかわからないことです。集計できる適切な数値があるわけではありません。これらの基準を満たす「はい、フォーム投稿があります」という事実は別として。

私はこれに正しい方法でアプローチしているかどうか疑問に思っていますか？仕事に間違ったツールを使用していませんか? それとも、何かが足りないのですか？

サイモン。

詳細:

機能には 2 つの領域があり、2 つのタイムスタンプなどの条件に基づいてフォーム投稿をフィルタリングします。しかし、フィルタリングに関しては、ほとんど何でも手に入れることができます。選択したフォーム投稿は、エクスポート用の csv ファイルを生成するために使用されます。

もう 1 つの主な分野は分析です。広告費から顧客へのリードへの変換を研究することは、当然の出発点です。また、多少オープンエンドであり、フォームデータに依存します。

これは少し未解決の質問ですが、人々の意見を聞きたいです。

明示的に宣言された一時テーブル (テーブル変数または通常の #tmp テーブル) を使用することはめったにありません。そうしないと、T-SQL がより簡潔で読みやすく、デバッグ可能になると信じているからです。また、必要な場合 (クエリで派生テーブルを使用する場合など) に一時ストレージを使用するよりも、SQL の方が優れた仕事をすることができると思います。

唯一の例外は、データベースが一般的なリレーショナル データベースではなく、スター スキーマまたはスノーフレーク スキーマである場合です。最初にファクト テーブルにフィルターを適用してから、結果の一時テーブルを使用してディメンションから値を取得することをお勧めします。

これは一般的な意見ですか、それとも反対の意見を持っている人はいますか?

SQLサーバーデータベースを使用して.net 3.5で新しいアプリケーションを構築しています。データベースはかなり大きく、データに負荷がかかる約 60 のテーブルがあります。.net アプリケーションには、データ入力およびサードパーティ システムからこのデータベースにデータを取り込む機能があります。

すべてのデータがデータベースで利用可能になった後、システムは多くの計算を行う必要があります。計算ロジックはかなり複雑です。計算に必要なすべてのデータはデータベースにあり、出力もデータベースに保存する必要があります。データ収集は毎週行われ、必要なレポートを生成するには毎週計算を行う必要があります。

上記のシナリオにより、ストアドプロシージャを使用してこれらすべての計算を行うことを考えていました。問題は、データの独立性も必要であり、ストアド プロシージャはそれを提供できないことです。しかし、これを .net by query database で常に行っていると、作業をすぐに終わらせることができないと思います。

たとえば、2000行を返す1つのテーブルをクエリする必要があり、次に各行に対して300の結果を返す別のテーブルをクエリする必要があります。データ、計算を行い、出力を別のテーブルに保存します。

ここで私の質問は、パフォーマンスが重要であるため、ストアド プロシージャ ソリューションを使用してデータベースの独立性を忘れるべきかということです。また、ストアド プロシージャ ソリューションを使用すると、開発時間が大幅に短縮されると思います。クライアントのいずれかがOracleデータベースでこのソリューションを必要とする場合(別のデータベースを維持したくないため)、ストアドプロシージャをOracleデータベースに移植し、将来の変更/機能強化のために2つのバージョンを維持します. 同様に、他のクライアントが他のデータベースを要求する場合があります。

上記の 2000 行は製品 SKU のものです。前述の 300 行は、処理コスト、輸送コストなど、計算したいさまざまな属性のものです。前述の 10 のテーブルには、通貨換算、単位換算、ネットワーク、エリア、会社、販売価格、1 あたりの販売数に関する情報が含まれています。結果のテーブルには、分析とレポートの目的ですべての情報がスター スキーマとして格納されます。目標は、製品に関する詳細な情報を取得して、製品販売のどの属性が費用を負担しているか、どこを改善できるかを知ることです.

現在 SQL Server、SSIS、および SSAS を使用しているデータ ウェアハウスのファクト テーブルとディメンション テーブルを設計しています。ディメンションとファクト テーブル間のリレーションシップを SQL にプログラミングすることで、実際にメリットが得られるでしょうか? それとも、キューブを作成するときにリレーションシップを手動で定義したほうがよいのでしょうか?

テーブルへのデータの挿入に制約がなく、関係を除外すると、データのロードと変換が簡単になるようです。

大量のデータ用のデータベースを設計している最中ですが、主キーにどのデータ型を使用すればよいか疑問に思っていました。

テーブルのパーティション分割があり、データベースは最終的にクラスター化され、代替データセンターへのホット フェイルオーバーになります。

編集

テーブル - 複数の期間と物事についてチャットする複数のユーザーとチャットするための複数の期間と複数の事柄のチャットシステムを考えてください。

私が考えているのは指数関数的な問題です。つまり、何かが短期間に数十億行を生成する可能性があります。つまり、データベースや DBA が DBA のことを行う前に、

マーク - GUID に関するあなたの懸念を共有します - GUID が飛び交うコーディングは好きではありません。

スター スキーマの設計をどこから始めるべきか混乱しています。

たとえば、次のようにデータベースにテーブルがあります。

次のような負荷を分析するためのデータ ウェアハウスを設計したいと考えています。

1. 2008年の融資総額。
2. 貸付契約数が10以上の貸付の種類については、貸付の種類及び契約数

スター スキーマを作成する場合、どこから始めればよいですか?

私の理解では、すべてのスタースキーマには中心が必要であり、中心のファクトテーブルには「メジャー」と「他のファクトテーブルとの関係」が含まれています。

では、スタースキーマを設計するときは、必ず中心から始めて、まず対策を確認するということでしょうか。次に、別のファクト テーブルとの適切な関係を選択しますか?

しかし、まだ別の質問があります。対策として何を選択する必要がありますか? 尺度を選択するとき、どのような質問を自問する必要がありますか?

SQLAlchemy で表現したいスター スキーマ アーキテクチャのデータベースがあります。今、これを可能な限り最善の方法で行うにはどうすればよいかという問題があります。現在、データが異なるテーブルに保存されているため、カスタムの結合条件を持つ多くのプロパティがあります。異なるファクトテーブルのディメンションを再利用できればいいのですが、それをうまく行う方法がわかりません。

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

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

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

スタースキーマでは、テーブル名の前にディメンションまたはファクトテーブルを付けるのが一般的ですか？列名の前にテーブル名を付けることも一般的な方法ですか？

私の通常のOLTPデータベースでは、これを行いませんが、スタースキーマでこのタイプの名前付けの例を確認しています。

データウェアハウススキーマとOLTPスキーマに異なる命名基準のセットを用意することは理にかなっていますか？

ありがとうドワイト