在Kimball的多维数据仓库设计模型的实践中，查找表(而不是维度)是否包含sid列？

Question

尝试为BI网页上的下拉列表创建一个简单的查找表。该表包含两个列，一个键和一个描述。

在设计此表时，维度建模的最佳实践是什么？键=>编号、描述=>字符(列=>数据类型)是足够的还是键需要是SID？

想象一下网页或网页表格中的下拉列表，比如"Country“。

Answer 1

如果您的自然密钥只能与一种描述相关联，而您的查找表只包含静态引用数据，那么我认为不需要使用代理键。

在您给出的示例中，下拉列表将包含国家。在我看来，如果维度模型是基于星型模式的，那么国家就不会成为一个独立的维度，而是另一个维度(例如地理或客户等)上的属性。这将不需要包括代理密钥，即使您要添加一个，因此将是浪费时间，精力和存储。

如果您的维度模型基于雪花，或者您的密钥可以与多个描述相关联(例如，如果描述可以随着时间的推移而改变)，那么是的，我将包括一个替代密钥。但是，我不会将它放在引用表中，代理键应该属于拥有数据的维度。