一般的なエンティティリレーションシップOLTPデータベースモデルからKimballスタースキーマのデータウェアハウス/マートモデルにデータをロードする際の一般的な設計アプローチは何ですか？OLTPリレーショナルデータベースからデータウェアハウジングモデルへの変換
個人的に、私は次のように動作する傾向がある：
これは私にとってはうまくいきました。これらのプロジェクトの多くは、本当に大きなものでもありません。
ジョン・サンダースのプロセス説明は良いです。
SQLサーバーにDatawarehouseプロジェクトを実装する場合は、優れたテキスト "The Microsoft Data Warehouse Toolkit"でプロジェクト全体を配信するために必要なすべての情報があります。 Funilly十分
、著者の一人は、私は現在、小規模/中規模データウェアハウスに取り組んでいます
申し訳ありません、私はKimbleではなくKimbleです。私は同僚から本を借りてきましたが、データ変換を実行するために使用される共通の戦略とツールを頭に浮かべていました。 –
SSISは方法です。実行する必要があるタスクの大部分はすでに既存のパッケージコンポーネントによって処理されており、並列処理機能は実際にスループットの点でも迅速に動くことができます。 –
:-)ラルフ・キンボールです。私たちはKimballが提示するいくつかのコンセプト、すなわち、事実と次元の表を持つスタースキームを採用しています。ファクトは、ファクトがディメンションにのみ結合するように構成されています（ファクトまたはファクトのディメンションには関係ありませんが、これが選択の仕方ではありません）。
SSISを使用して、プロダクションDB - >ソースDB - >ステージングDB - >レポートDBからデータを移動します（おそらくDBを少なくしていた可能性がありますが、それはその方法です）。
SSISは、データフローを非常に論理的に構造化できるので、本当にいいです。 SSISコンポーネントとストアドプロシージャの組み合わせを使用します.SSISの優れた機能の1つは、ソース/デスティネーションのデータフロー間の変換としてSQLコマンドを提供する機能です。つまり、必要に応じてすべての行に格納されたprocsを呼び出すことができます（少し遅くなりますが）。
変更データの取得（CDC）という新しいSQL Server 2008の機能を使用して、テーブルのすべての変更を監査できます（これらのテーブルで表示する列を指定できます）。それをプロダクションDB上で使用して何が変更されたのかを知ることができます。そのため、レコードをソースDBに移動して処理することができます。
Data Vault Modelingをご覧ください。それは、属性の変更などのいくつかの孤独な言葉の問題を解決すると主張している。
私は高い評価を答えに同意するが、私は以下を追加しようと思いました：
* Do you use a staging area to perform the transformation and then負荷の倉庫に？
ステージングが必要かどうかは、トランスフォームのタイプによって異なります。ステージングは、ETLをより管理しやすいチャンクに分割するメリットをもたらしますが、ウェアハウスに影響を与えずにデータ上で操作を実行できる作業領域も提供します。ファクトレコードをロードするときにルックアップとして使用するために、OLTPシステムのキーと最新のdimレコードのキーを格納するステージング領域に（少なくとも）いくつかのディメンションルックアップを持たせることができます。 変換はETLプロセス自体で行われますが、途中で手助けするためにステージングが必要な場合とない場合があります。
* How do you link data between the warehouse and the OLTP database?
バックOLTPシステムへの参照として、データウェアハウスに（利用可能な場合、または実際の主キー）ビジネスキーをロードするために有用です。また、DWプロセスでの監査では、ロードされたロードプロセスを記録することによって、データの各ビットの系統を記録する必要があります。ストアドプロシージャ、DTS/SSISパッケージ、アプリケーションコードから やSQLなど
* Where/How do you manage the transformation process - in theデータベース？
これは通常、SSISパッケージに含まれますが、多くの場合、ソースクエリで変換する方が効率的です。残念ながら、これはソースクエリを理解して維持するのが非常に複雑になるため、パフォーマンスが問題ではない場合は、SSISコードを変換するのが最適です。これを行うと、ステージング領域を持つもう1つの理由として、異なるテーブル間でソースクエリでより多くの結合を行うことができます。
@John - データウェアハウスモデルにKimbleの「ファクトおよびディメンションスタースキーマ」デザインを使用しましたか？ –
そうだと思います。私はこの「キンブル」人を読んだことはありませんが、人々はデータウェアハウスで彼の名前をアルゴリズムで「クヌス」と呼ぶほど多く呼びます。しかし、再び、私は決してその最初のクヌスの本を完成させず、セット全体を売ることを諦めた。私が今作業しているデータマートは、いくつかのディメンションが次元を持つので、スノーフレークのものです。私たちの状況は、顧客とセールスマンの両方がディメンションであることに類似しています。 –
謝罪、私はキンブルではなくキンブルを意味しています:) –