キンボールデータウェアハウスを構築しています。ステージングデータベースとファイナルデータウェアハウスがあります。
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
これは好みの問題です。私が物事をまったく解体する主な理由は、セキュリティと、二次的にバックアップのためです。
最終的なスタースキーマテーブルの読み込みを含むETLアクティビティは、Staging
レイヤーの側面として考えています。すべての「重い物を持ち上げる」ことは私の倉庫で起こります。
これが私がデータウェアハウスを通常分割する方法です。これらは別個の物理データベースである必要があり、データの量に必要な場合は個別のVMまたは物理マシンである場合があります。
DateCaptured
とDateModified
を記録しますが、データの値や型のクリーンアップは行いません。アイデアは、ソースシステムの負荷を最小限に抑えるために、できるだけ早くデータを取得することです。Service_SalesforceReader
ユーザーは、Salesforce
データベースで特権を読み書きしましたが、他にはありません。Staging
データベース。 「ETL」の「T」。これには、データクリーニング用のルックアップテーブル、合成キーを割り当てるためのテーブル、およびETLプロセス用のログテーブルが含まれます。Warehouse
データベース。このレイヤーには、特定の消費者を支援するビューがあります。たとえば、結合でナイスを再生しない視覚化ツールがある場合、すべての次元が結合された、各スターのビュー(おそらくマテリアライズ)がある可能性があります。実際には、スタースキーマに組み込まれていると評価されない必要なデータがある場合は、一部のパワーユーザーに特定のソースデータベースへのアクセスを許可する必要があります。このような場合、それらをリンクするStaging
の合成キーテーブルへのアクセスを許可して、それらが(たとえば)CustomerSK
整数からSalesforce AccountID
文字列にトラバースできるようにする必要がある場合もあります。そうすると、人のプロセスを壊さずに何かを変更することが難しくなるため、これは最後の手段となるはずです。