3

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

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

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

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

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

だから私の質問は -

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

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

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

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

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

4

3 に答える 3

2

  1. 私が管理しているいくつかのデータ ウェアハウスでこの手法を使用しました。ビューに基づいてレポートを実行する場合と、テーブルに直接アプローチする場合を比較して、パフォーマンスの低下に気付いたことはありませんが、詳細な分析を実行したことはありません。

  2. SQL Server Management Studio のデザイナーを使用してビューを作成し、自動化されたアプローチは使用しませんでした。いずれにせよ、自動化する価値があるほど頻繁にスキーマが変更されるとは想像できません。最初にすべてのテーブルをビューにドラッグするのと同じくらい、結果を微調整するのに時間がかかるかもしれません!

あいまいさをなくすには、列名の前にそれが属するディメンションの名前を付けることをお勧めします。これは、レポートの作成者や、アドホック クエリを実行するすべての人に役立ちます。

于 2008-09-25T18:36:48.910 に答える
1

MS SQL Server を使用している場合は、パラメーター化されたビューにできるだけ近いインライン UDF を試すことができます。

于 2009-10-26T15:46:54.760 に答える
1

1 つまたは複数のサマリー ファクト テーブルにビューを作成し、具体化します。これらは、メインのファクト テーブルが更新されたときにのみ更新する必要があります。具体化されたビューはクエリが高速になり、サマリーで満たすことができるクエリが多数ある場合、これが有利になる可能性があります。

これらの集計が多数ある場合、または集計を頻繁に変更する場合は、データ ディクショナリまたは情報スキーマ ビューを使用して SQL を生成し、テーブルを作成できます。

ただし、これらを頻繁に変更する可能性は低いと思いますので、ビュー定義を自動生成しても無駄かもしれません。

于 2008-09-24T17:24:11.090 に答える