web-dev-qa-db-ja.com

ファクトテーブルには、単一の一意の値を持つ列を含める必要がありますか？

レポートを簡素化するために、私たちが持っているファクトテーブルごとに、よりユーザーフレンドリーな形式ではありますが、ファクトテーブルの名前を示す列を含めることができるかどうか疑問に思っています。

例えば.

FACT_SALES    
Source     ID      Name   
Sales      1       Bob    
Sales      2       Terry
....

FACT_TESTING    
Source              ID      Type   
Product Testing     23      Adhoc   
Product_Testing     29      ...
...

そうでない場合は、これを表示するために何らかのコーディングを追加する必要があるという点で、エンドユーザーによるアクションを必要とせずにこの情報を追加する適切な方法は何ですか？

data-warehousedimensional-modelingfacttableenum
1
adolf garlic

私がお勧めするのは、fact_sourceテーブルがあることです。

CREATE TABLE fact_source
(
  fact_source_id INTEGER,  -- auto-increment.
  fact_source_name VARCHAR (50)
);

独自のRDBMS（どちらかは言わなかった）独自の自動インクリメントキーシステムを使用して、fact_source_idを生成します）

INSERT INTO fact_source fact_source_name) VALUES ('Sales'), ('Testing');

そして、それを関連するテーブルの外部キーとして使用します。

次に、テストで正常に機能し、リソースの負担がないことが示された場合、レポートクエリでユーザーフレンドリーな（つまりテキスト）出力を「事前に調理」できます。

概説されている理由のためにENUMsを使用しないでください ここ 。システムに機能があるからといってnotは、それらを使用する必要があることを意味します！ shouldは、常にCHECK制約（信じられないことに、MySQLにはこれらがありません）または上記のルックアップテーブルのいずれかを使用する必要があります。

キーをSMALLINT（または同様のもの）として保存すると、スペースを少し節約できます。

1
Vérace

ここでの目的が固定の代替テーブル名を提供することである場合（ソースを記録するのではなく、異なる場合があります）、1つのオプションは、永続化されていない仮想列（SQL Serverで計算された列）を実装することです。

1
Paul Holmes

これは実行可能なアプローチのようです。これは、データセットのソースを追跡するために列RecordSourceが使用されているDataVaultのアプローチにいくぶん似ています。

しかし、ここではそうではないように私には思えます。したがって、2つの方法を提案します。

1）まさにあなたが提案したもの

2）Fact_Testingキューブが「ProductTesting」ソースに明確にバインドされるように、それ自体を表すデータマート/ファクトテーブルを構築します。ドキュメント、名前付け、またはビルド前のレポートの提供を通じて。

0
tobi6