問題タブ [data-warehouse]

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

私は、典型的なスター スキーマを含むデータ ウェアハウスと、次のようなことを行う一連のコードを持っています (明らかに、はるかに大きくなりますが、これは説明用です)。

私はそれをビューに置き換えることを考えています（MODEL_SYSTEM_1、言う）、それは次のようになります：

しかし、ビューMODEL_SYSTEM_1には一意の列名が含まれている必要があり、オプティマイザーのパフォーマンスについても懸念があります。なぜなら、さまざまなファクトとディメンションにわたる WHERE 句のすべての項目が最適化されることが懸念されるからです。 、ビューは星全体に渡って表示されるため、ビューをパラメーター化することはできません (少年、それはクールではないでしょうか!)

だから私の質問は -

1. このアプローチは問題ありませんか、それともパフォーマンスを低下させ、より優れた構文しか提供しない抽象化になるだけですか?

2. 適切な PK と FK がすべて配置されている場合、これらのビューをコード生成し、列名の重複を排除する (後でビューを手動で調整する必要がある場合でも) 最善の方法は何ですか? から引き出すためにSQLを書くだけですか、INFORMATION_SCHEMAそれともすでに利用可能な良い例がありますか。

編集:私はそれをテストしましたが、パフォーマンスは、より大きなプロセスでも同じように見えます-それぞれがこれらのビューを使用する複数のスターに参加しても.

自動化の主な理由は、データ ウェアハウスにこれらのスターが多数あり、FK/PK が設計者によって適切に行われているためですが、すべてのテーブルまたはドキュメントを選択する必要はありません。ビューを生成するためのスクリプトを作成しました (テーブルの略語も生成します)。それは から自動的にスケルトンを生成するのにうまく機能しINFORMATION_SCHEMA、ビューの作成をコミットする前に微調整することができます。

誰かがコードを欲しがっているなら、私はおそらくここでそれを公開することができます.

複雑なデータの蓄積を行っています。私たちの顧客は、2 つの次元 (時間とビジネス ユニット) を含むいくつかのデータを私たちに送信します。時間は主に年月です。ビジネス ユニット ディメンションには、名前と、レポートおよび分析の目的で BU が属することができるいくつかのカテゴリなど、いくつかの属性しかありません。

彼らが私たちに送るものには、いくつかの現在の状態情報 (日付とコード) が含まれています。これらは事実のようです。また、ビジネス ユニットとの関係を特徴付ける情報も送信します (ほとんどが追加コード)。繰り返しますが、これらはビジネス ユニットと期間に固有のものです。

最後に、彼らは明らかに付加的な事実である情報を送ってきます。適切な単位を持つ通貨とカウントが含まれます。

この定性的な情報を 1 つのファクト テーブルに付加的なファクトと混ぜ合わせるべきですか? それとも、定性的なもの (カウントでのみ使用できます) を定量的なもの (合計で使用できます) から分離する必要がありますか?

レストランの配達情報を含むデータウェアハウスを構築しています。データはSQLServer2005に格納されてから、SQL Server AnalysisServices2005キューブに配置されます。

配信情報は、次の表で構成されています。

FactDeliveres

• BranchKey
• DeliveryDateKey
• プロダクトキー
• InvoiceNumber（DD：縮退ディメンション）
• 量
• 単価
• ラインコスト

ノート：

• FactDeliveresの粒度は、請求書の各行です
• 製品ディメンションには、サプライヤー情報が含まれます

そして問題：ファクトテーブルの主キーがありません。主キーは、各配信とProductKeyを一意に識別するものである必要があります。しかし、配達を一意に識別する方法はありません。

ソースOLTPデータベースには、すべての配信に固有のDeliveryIDがありますが、これはユーザーにとって意味のない内部IDです。InvoiceNumberはサプライヤーの請求書番号です。これは手動で入力されるため、重複します。

キューブでは、FactDeliveresのInvoiceNumberフィールドのみに基づいてディメンションを作成しました。つまり、InvoiceNumberでグループ化すると、（誤って）同じInvoiceNumberを持っているという理由だけで、2つの配信が組み合わされる可能性があります。

DeliveryID（DeliveryKeyと呼ばれる）を含める必要があると感じましたが、その方法がわかりません。

私もそうです：

1. これをInvoiceNumberディメンションの基になるキーとして使用しますか？
2. 新しい配信があるたびに増加するDimDeliveryを作成しますか？これは、DeliveryDate、Supplier、InvoiceNumberなど、一部の属性がFactDeliveriesから出てDimDeliveryに入るということを意味している可能性があります。

結局のところ、私はあなたに尋ねることができます：ソースデータベースに次の情報がある場合、Deliveriesキューブを作成するにはどうすればよいですか？

DeliveryHeaders

• DeliveryID（PK）
• 配送日
• サプライヤーID（FK）
• InvoiceNumber（手動で入力）

配達の詳細

• DeliveryID（PK）
• ProductID（PK）
• 量
• 単価

レポートを生成するために必要な mysql データがたくさんあります。ほとんどが過去のデータであるため、あまり変化しませんが、20 ～ 30 ギガバイトの容量があり、今後も大きくなることが予想されます。私は現在、いくつかの複雑なクエリを実行し、csv および Excel ファイルを出力する php スクリプトのコレクションを持っています。また、ブックマークされたクエリで phpMyAdmin を使用しています。それらを手動で編集してパラメーターを変更します。データの量が増えており、それにアクセスする必要がある人の数も増えているため、この状況を改善するために時間を割いています。

先日、データ ウェアハウジングについて読み始めましたが、これは私がしなければならないことに関連する分野のようです。私はいくつかの 良い 記事を読み、本を待っています. この種のシステムが何をするのか、何ができるのかを把握していると思います。

自分のデータのレポート システムを作成することは、常にやるべきことのリストにありましたが、最近まで、それは非常にニッチなプログラミング ベンチャーになるだろうと考えていました。データ ウェアハウジングが一般的なものであることを知ったので、開発を容易にするために利用可能な何らかのレポート/ウェアハウジング フレームが必要であると考えています。レポートなどをスケジュールしたりメールで送信したりするためのインターフェースやスクリプトを書くことは喜んで飛ばし、クエリを書いたり関係を設定したりすることに専念したいと思います。

私は主にランプの男でしたが、言語やプラットフォームを切り替えることは好きではありません。1 回限りのスクリプトはうまくスケーリングできないため、より堅牢なソリューションが必要です。

では、始めるのに適した場所はどこでしょうか?

2 つの異なる出所を持つデータがあります。一部は顧客からのもので、一部は別のベンダーからのものです。現在、このデータを物理的に "マージ" して、ほぼ 100 列、数万行の巨大なテーブルを作成し、2 つの次元を形式的に分離していません。したがって、実際にはこのテーブルをあまり使用できません。

この混乱を適切な、しかし小さなスター スキーマに再設計します。

2 つの次元は明らかです。たとえば、時間もその 1 つです。

顧客提供のデータは、多くの事実値を提供します。各ベンダーは、同じディメンションに適合する追加のファクト値を提供する場合と提供しない場合があります。

このファクト データはすべて同じ粒度です。すべてのベンダーから情報を取得することはあまりないため、「スパース」と呼ぶことができます。

これが私のジレンマです。

この 1 つのファクト テーブル (いくつかの null を含む) は、さまざまなソースから入力されたものですか?

それとも、このn +1 個のファクト テーブル (1 つは顧客から入力され、他は各ベンダーから入力されたもの) ですか?

それぞれのデザインには長所と短所があります。「マージ」または「個別にロード」の選択について、セカンドオピニオンが必要です。

顧客は、収益、コスト、カウント、重量、およびトランザクションの終了について知っているその他の情報を提供します。

ベンダー 1 は、一部のトランザクションに関する追加の詳細 (重量、コスト、期間) を提供します。他のトランザクションは、ベンダー 1 からの価値はありません。

ベンダー 2 は、トランザクションの一部について追加の詳細 (ボリューム、期間、長さ、外貨レート) を提供します。他のトランザクションは、ベンダー 2 にとって価値がありません。

一部のトランザクションには、両方のベンダーが含まれます。いくつかのトランザクションには、どちらのベンダーもありません。

ヌルを持つ 1 つのテーブル? 3つのテーブル？

データ ウェアハウスの作成に使用できるサンプル データベースはどこからダウンロードできますか? Microsoft (Northwind など) からのサンプルであってはなりません。

編集：私の質問を明確にしておらず申し訳ありません。私の大学では、データ ウェアハウスを作成しなければならないクラスがあります。Northwind はネット上で非常に人気があるため、教授はこのデータベースを使用しないように言いました。この SQL Server 2008 に使用しますが、Northwind の使用は禁止されています。

ビジネス インテリジェンス ツール Inetsoft Style Report を使用している人はいますか? 私はそれで立ち往生しており、誰かがサーバー管理のチューニングやベストプラクティスについてアドバイスを持っているかどうか疑問に思っていましたか? Tomcat と db2 データベースを使用して、高速な Solaris ボックスで実行しています。

保存する必要がある大量のデータがあり、レポートを生成できる必要があります。それぞれが Web サイト上のイベントを表しています (1 秒あたり 50 以上のデータがあるため、明らかに古いデータを集計する必要があります)。

私はこれを実装するためのアプローチを評価しています。明らかに、信頼性が高く、可能な限り簡単にスケーリングできる必要があります。また、柔軟かつ効率的な方法でデータからレポートを生成できる必要があります。

一部の SO 担当者がそのようなソフトウェアの経験を持ち、推奨事項を作成したり、落とし穴を指摘したりできることを願っています。

理想的には、これを EC2 にデプロイしたいと考えています。

私のデータ ウェアハウス プロジェクトは、来年 (SQL Server 2005 から) Teradata に移行するようです。

Teradata のベスト プラクティスに関するリソースを探しています。SQL ダイアレクトの制限から、クエリを適切に実行するためのイディオムや規則まで、特に SQL Server 2005 と大きく異なる点が強調されている場合。Art of SQL (より Oracle に焦点を当てたもの)。

現在、私のビジネス プロセスは T-SQL ストアド プロシージャを使用しており、PIVOT、UNPIVOT、共通テーブル式などの SQL Server 2005 機能にかなり依存して、4 TB のデータ ウェアハウスから毎月約 2,700 万行の出力を生成しています。