web-dev-qa-db-ja.com

SQL Serverデータウェアハウスのストアドプロシージャの場所

キンボールデータウェアハウスを構築しています。ステージングデータベースとファイナルデータウェアハウスがあります。

CustomerTransactionテーブルを作成するストアドプロシージャがあります。ストアドプロシージャを配置するのに最適な場所はどこですか？ステージングデータベースとデータウェアハウスのどちらですか？または各場所の良い点/悪い点は何ですか？私はデータウェアハウスを作成し、学び始めました。

create procedure dbo.FactCustomerTransactionImport  -- should this be in StagingDB or datawarehouse DB?
as

insert into DWFinal.dbo.FactCustomerTransaction
(
     CustomerId, 
     Quantity, 
     Price, 
     Amount
)
select 
     CustomerId, 
     Quantity, 
     Price, 
     Quantity * Price as Amount
from StagingDB.dbo.CustomerTransaction
sql-serverdatabase-designsql-server-2016stored-proceduresdata-warehouse
3
user162241

これは好みの問題です。私が物事をまったく解体する主な理由は、セキュリティと、二次的にバックアップのためです。

最終的なスタースキーマテーブルの読み込みを含むETLアクティビティは、Stagingレイヤーの側面として考えています。すべての「重い物を持ち上げる」ことは私の倉庫で起こります。

これが私がデータウェアハウスを通常分割する方法です。これらは別個の物理データベースである必要があり、データの量に必要な場合は個別のVMまたは物理マシンである場合があります。

  • 重要なデータソースごとに個別のデータベース（CRM、OLTPデータベース、テレフォニーシステムなど）。ここでは、最小限の変更を加えて、ソースシステムからのデータの単純なコピーを保存します。たとえば、各レコードのDateCapturedとDateModifiedを記録しますが、データの値や型のクリーンアップは行いません。アイデアは、ソースシステムの負荷を最小限に抑えるために、できるだけ早くデータを取得することです。
    • 原則として、これらのデータベースは任意に削除でき、ウェアハウスの他の部分を変更せずにソースシステムから再入力できます。
    • ソースごとに別々のデータベースを使用すると、ユーザー（サービスアカウントなど）のアクセスが制限されます。ぼくの Service_SalesforceReaderユーザーは、Salesforceデータベースで特権を読み書きしましたが、他にはありません。
    • これらのデータベースへの書き込みは、通常、専用のETLアプリケーションを介して行われ、いくつかのSQLプロシージャがそれらをサポートします。
  • 中間ステップ用のStagingデータベース。 「ETL」の「T」。これには、データクリーニング用のルックアップテーブル、合成キーを割り当てるためのテーブル、およびETLプロセス用のログテーブルが含まれます。
    • ここでのデータはほとんどが静的であり、ソース管理（国コードなど）またはソースデータの変換から再作成できます。これらのシステムから再作成できますが、異なる合成キーが作成されている可能性があります。倉庫チームの人だけがここにアクセスする必要があります。
    • このデータベースには、SQLプロシージャの90％が含まれています。データをフォーマットし、スタースキーマレイアウトにピボットします。ステージングでETLロジックを維持する客観的な理由が1つあります。それはセキュリティです。これらの手順にアクセスする必要があるのはウェアハウス管理者だけですが、多くの人はウェアハウスレイヤーにアクセスする必要があります。
  • きちんとしたファクトテーブルとディメンションテーブルを含むWarehouseデータベース。このレイヤーには、特定の消費者を支援するビューがあります。たとえば、結合でナイスを再生しない視覚化ツールがある場合、すべての次元が結合された、各スターのビュー（おそらくマテリアライズ）がある可能性があります。
    • このレイヤーの現在の倉庫にある唯一のsprocはロギング用であり、実際に使用されているとは思いません。

実際には、スタースキーマに組み込まれていると評価されない必要なデータがある場合は、一部のパワーユーザーに特定のソースデータベースへのアクセスを許可する必要があります。このような場合、それらをリンクするStagingの合成キーテーブルへのアクセスを許可して、それらが（たとえば）CustomerSK整数からSalesforce AccountID文字列にトラバースできるようにする必要がある場合もあります。そうすると、人のプロセスを壊さずに何かを変更することが難しくなるため、これは最後の手段となるはずです。

4
Jon of All Trades