問題タブ [surrogate-key]

代理キーは、私たちの本に何年も存在するメカニズムであり、再び議論するのは嫌いです. ビジネス キーの代わりに代理キーを使用するメリットについては、誰もが口をそろえています。Microsoft Analysis Services 表形式および Microsoft PowerBI 表形式モデルでさえ、代理キーを使用しています。言及された両方のプラットフォームは、1 つの列を使用してディメンションとファクトを接続する機能を提供するため、実際には 1 つのビジネス キーを持つことは非常に困難であるため、代理キーとなります。

最近は BI アーキテクトとして、Analysis Services の多次元および表形式を使用していました。多次元のプロジェクトがあり、毎晩 DataWarehouse で最大 500 GB まで管理されていました。私は、数百万のレコードを持つテーブル間で、5 ～ 6 個のユニオンと 8 ～ 10 個の結合から収縮した事実に直面しました。

サロゲート キーを使用して、ディメンション キーを知ることができるようにするために、追加の結合を作成する必要があります。その結果、N 次元 (構造式のファクトとまだ関連付けられていない) を単一のファクトと "関連付け" たい場合は、DataWarehouse に N 個の追加の結合が必要です。

前の例を見てみましょう。この特定のファクトについては、5 ～ 6 個のユニオン + (8 ～ 10 + N) 個の結合が必要であり、これにより複雑さが増します。このファクトを 10 ～ 15 に関連付ける必要があるとどうなるかのイメージ代理キーを取得するためのディメンション。

ここ数年、私は新聞を読むような初期のコーヒーを使用してファクト式を読み、未使用の列、結合、結合を削除し、ETL プロセス時間を節約するために複雑さを軽減するためにすべてを作成しようとしていました。

DataWarehouse と Semantic Layer を照会する時間を節約できることは十分に理解できますが、ETL についてはどうですか? 何か足りないものがありますか?

ファクト テーブルに適したテーブルを選択するのに問題があります。次の2つのテーブルに問題があります

注文データ テーブル:

1. オーダーID
2. 顧客ID
3. 注文の状況
4. 注文購入場所
5. 注文承認日
6. 注文配送業者
7. OrderDeliveredCustomer
8. 注文予定配達済み

OrderItems テーブル:

1. オーダーID
2. 注文商品ID
3. 製品番号
4. 販売者ID
5. 出荷制限日
6. 価格
7. 重量級

ファクトテーブルに適したテーブルは何ですか? 私のデータソースはhttps://www.kaggle.com/olistbr/brazilian-ecommerceです

応援お願いします。

しばらくの間私を悩ませている質問があります。

ETLプロセス中に主キーを代理キーに置き換えると、実際にはどのように見えますか? ワークフローとはどのようなものですか? 新しい IDENTITY を割り当てるだけですか? もしそうなら、以前の値はどうですか、既存のビジネスキーを新しく作成されたものに置き換える方法は?

私の考えでは、特定のワークフローは次のようになりますが、実際にはまだ実行していません。

1. DimProduct および FactSales テーブル内の既存の PK_Product および FK_Product を削除します。
2. 新しい IDENTITY 列を dimProduct に設定します。
3. 前のビジネス キーの結合に基づいて、新しく作成された IDENTITY 列の値を使用して、FactSales に新しい列を追加します。
4. 両方のテーブルで古い ProductKey 列を削除します。
5. 新しく作成されたサロゲート IDENTITY キーに制約を追加します。
6. 将来の値のためにテーブル間の参照を割り当てます。

しかし、私が間違っていると思うので、あなたの仕事でこれをどのように行っているか教えてください。

名前と住所の情報が重複している非常に大きなテーブルがあります。このテーブルは、タスクを実行し、結果をテーブルに追加するプロセスをフィードします。名前と住所の情報にハッシュ キーを作成することで、このプロセスに入力される量を減らしたいと考えています。そうすれば、ハッシュ キーごとに 1 つのレコードをフィードできるので、入力を 75% 削減できます。そして、このキーが長期にわたって持続する必要があります。

ただし、このハッシュ キーは、結果テーブルを結合するキーとして機能するため、一意である必要があります。永続化された列としてハッシュ キーを作成し、それに一意の制約を与えることはできますが、衝突の可能性がごくわずかであることを懸念しています。2 つの異なる名前とアドレスの文字列が同じハッシュ出力を生成する可能性がある場合でも、両方に対して一意のキーが必要です。

これが起こる可能性は信じられないほどありそうにないとしても、もしそうなったとしても、私には計画がないことを知って嬉しくありません.

また、テーブルのサロゲート ID を使用し、名前とアドレスのグループ内のすべてのレコードに MIN(surrogateID) を割り当てることも検討しました。ただし、特定のグループの MIN(surrogateID) に対応するレコードが削除された場合、ID が変更されました。

個別の名前と住所のルックアップ テーブルを作成し、それぞれに単純な整数 ID を与えることができます。しかし、保管コストは避けたいと思います。

私が考慮していない可能性のある他のオプションはありますか？

両方が一意のキーである場合、主キーと代理キーの違いは何ですか。主キーは、phpmyadmin の代理キーと同じように機能します。ビデオで、代理キーはテーブルの他の列から独立していると聞きました。また、ファクト テーブルとディメンション テーブルとの関係についても説明します。