数据仓库中的客户维度——人与公司的混合答案

【问题标题】：Customer dimension in data warehouse - mix persons with companies数据仓库中的客户维度——人与公司的混合
【发布时间】：2013-03-29 13:05:56
【问题描述】：

我们确实有各种各样的客户 - 其中大多数是个人，但也有一些是公司。这两个组都共享相同的事实集，但是它们的维度属性不同（示例）：

Person
 FirstName
 LastName
 BirthDate
 Sex
 Region
 City
Company
 Name
 RegistrationNumber
 Region
 City

将个人和公司都包含在一个维度中是个好主意吗？

Customers
 FirstName
 LastName
 BirthDate
 Sex
 Name
 RegistrationNumber
 Type (Person,Company)

值得一提的是，也有自雇客户——在这种情况下，他们具有个人和公司的所有属性。

如果我使用两个维度，这将使所有分析内容变得更加困难，因为大多数时候我对这两个组都感兴趣。另一方面，如果我只使用一个维度，将会有很多默认值。我检查了“数据仓库工具包”，但没有找到相关信息。

我的问题 - 我应该创建两个表、一个表还是使用完全不同的方法来设计数据仓库中的客户维度？

【问题讨论】：

子类型/超类型的一个例子，参见，例如，这里：basicofcomputer.com/supertypes_and_subtypes_entities.htm
@koriander 实际上我们的生产系统就是这样处理的。你在数据仓库中使用这种设计吗？
我想这取决于您的特定数据仓库，但通常具有分层维度，并且不同级别的维度可以具有不同的属性。恐怕我没有太多的经验可以和你分享，我只能建议检查你的 OLAP 系统的功能。

【解决方案1】：

将个人和公司都包含在一个维度中是个好主意吗？

在数据仓库中，是的。信息不会更新，您不必担心空列或默认列，查询的轻松（速度）更为重要。

在操作数据库中规范化数据的一个原因是消除更新异常的可能性。当数据存储在多个地方时，可以在一个地方更新，而不能在另一个地方更新。

【讨论】：

【解决方案2】：

我的理由是你解释的场景，我们可以维护两个维度，并且可以在 Fact 中包含两个键。

Fact 可能包含 PERSON_KEY 和 CUSTOMER_KEY。因此，如果是一个人 PERSON_KEY 可以是-1，或者如果是其他方式 COMPANY_KEY 可以是-1。如果个人或公司详细信息需要用于系统内的某些其他目的，则可以考虑这一点。我认为维度意味着进入可能的粒度级别。

【讨论】：