問題タブ [data-vault]

データ ウェアハウスをモデリングする場合、ディメンション モデリングよりもData Vaultを優先する理由はありますか? これら2つの主な違いは何ですか?

JSON 形式のデータが非常に多く、それらからデータ ウェアハウスを構築したいと考えています。大量のデータがあり、半構造化されているため、MongoDB などのドキュメント NoSQL データベースを使用することを考えました。

データのモデリングに関しては、データ ボールト モデルを使用することを考えました。NoSQL データベース (MongoDB など) でデータ ボールト モデルを使用することは可能ですか? そのような場合の長所と短所は何ですか？

だから私はデータボールトを実装しようとしています。ハブのモデリングに問題があります。互いに通信しない 2 つのシステムがあります。ハブ内の異なるソースから同じアイテムを表す方法を知りたいです。

当社の注文システムでは、顧客を区別するための番号が生成されます。たとえば、「ボブ」という名前の顧客がいて、彼が 5 つの場所で当社のサービスを必要としているとします。そのため、これら 5 つの場所を個別の顧客として扱います。したがって、5 つの異なる顧客 ID (10004-10008) を取得します。これまでのところ、Data Vault で簡単に作業できます。

ここで注意が必要なのは、運用システムにあります。複合ビジネス キーがあります。したがって、一意の顧客名「bob」と、その場所ごとにシーケンス番号 (1-5) を取得します。したがって、(bob,1) は一意ですが、(joe,1) も使用できます。

私たちのオペレーション システムでは、注文システムの ID を入力する方法がありません。私たちの注文システムでは、(bob,1) 情報は、(bob,1) が作成されてから十分に入力されます。

タイムラインは次のようになります。ボブが入ってきて、5 つの場所が必要だと言いました。注文システムは彼に ID (10004-10008) を与えます。1 週間後、彼はオペレーション システム (bob,1)、(bob,2)...(bob,5) に作成され、2 週間後には (10004,bob,1)、(10005,bob) が表示されます。 、2) 注文システムで。

このシナリオにどのように対処しますか?

ありがとう

Data Vault 2.0 では、ビジネス キーをハッシュし、このハッシュをテーブルの主キーとして使用します。また、リンク テーブルはハッシュ主キーを使用して関係を作成します。

私の問題は、基本的にランダムなハッシュに関するものです。統計はもちろん、ランダムに分散されたデータには使用できないため、クエリオプティマイザーは適切な推定を適用できません。

そのため、クエリ オプティマイザーは、頻繁に並べ替えたい場合に奇妙な計画を使用します (並べ替える行が 4 行しかないと考えているため)。SQL Server でデータ ボールトを扱うのは私が初めてではないので、これをどのように修正できますか?

クエリ オプティマイザーがインデックス シークまたは結合演算子を使用すると、行の見積もりが完全に失われ、ばかげた計画が選択されます。

そこから何かを得るには、(FORCE ORDER) などの結合ヒントとクエリ ヒントを使用してそれらをポンピングする必要があります。

これに対する一般的なアプローチは何ですか？

EDW は以下の構成で計画しています。

運用システム --> ステージング エリア --> EDW (データ ボールト)

データ保管庫の法律に従って、ビジネス キーをハッシュする必要があります。ステージング領域または ETL (ステージング領域から EDW まで) でハッシュを実装する必要があります。

ステージング エリアにメタデータを追加する場合、通常はどのように処理しますか?

どうもありがとう

ディメンション モデリングのコンテキストでは、典型的なケースとして、行の変更を追跡するためにディメンション テーブルに代理キーがあると便利です ( http://www.kimballgroup.com/2006/07/design-tip-81-fact-テーブル代理キー/ )。

代理キーを実現するには、3 つの一般的な方法があります。1) シーケンス番号 2) バージョン番号 3) ハッシュ キー (データ ボールトで使用)

私の質問は、私が見たほとんどの次元モデリングでシーケンス番号が好まれる理由です。

どうもありがとう

情報マートの構築中にビジネス ルールを適用できる場合、ビジネス ボールトを持つ目的は何ですか?

次の 3 つの一意の属性が 3NF モデルの SalesOrderHeader テーブルから届く場合、SalesOrderHeader ハブの理想的なビジネス キーはどれですか。

1. SalesOrderID(元テーブルのPK)
2. 受注番号
3. 発注番号

他のエンティティ (外部キー) の ID と追加の情​​報によって識別されるエンティティを表現したいと考えています。以下は、特定のシナリオです。

エンティティ:

• 製品
• お客様

顧客が製品を購入すると、注文が行われます。注文には、同じ顧客と製品のセットに対する異なる購入を示す序数も含まれます。たとえば、顧客 James が製品の接着剤を 2 回購入した場合、私は (James,glue, 1), (James,glue, 2) になります。注文の識別は、顧客、製品、序数の組み合わせです (これはビジネス要件によるものであり、その後のデータ更新/修正を容易にするためでもあります)。

次に、Products を HUB に、Customers を HUB に、Orders を 2 つの HUB 間のリンクにします。

私が理解しようとしているのは、Order LINK に序数を含める方法です。

私が持っている 1 つの提案は、序数を格納する HUB を作成し、それに序数を事前に入力することです (同じ製品を 100 回購入する顧客は一度もいないため、100 行の事前入力で十分なはずです)。次に、Order LINK は序数 HUB を参照して、何らかの識別を行うこともできます。

これが良いアプローチかどうか教えてください（データベースが機能するために、何かを事前に入力する必要があるという事実、たとえば仮定を立てる必要があるという事実はあまり好きではありません）。そうでない場合、より良い代替手段は何ですか?