星型模式中的“维度”表和关系数据库中的“查找”表有什么区别？

Question

我正在尝试设计一个星型模式事实表以及一些围绕它的维度表。如果我再利用被称为自然键customer_key同时在fact_table和dim_customer当时我没有看到调用朦胧的东西和查找表之间的差异。此外，如果我每次都需要更新，customer_name我将丢失在录制时代表此事实的历史数据。尝试对暗表和事实表进行建模时，我缺少什么？

我想了解关系“查找”表技术和数据仓库“维度”表之间的区别？

fact_table               dim_customer          dim_product
-------------            ------------          -----------
customer_key             customer_key          product_key
product_key              name                  name
units_sold               email                 description
unit_price

请原谅我在这个问题中可能表现出的任何无知。我是数据仓库新手。

Answer 1

如果您只有这些表，那么您的数据仓库星型模式和实际模式之间几乎没有区别。

不过，您可能有一个更复杂的关系模式，其中还有客户组或项目类型，并且您的模式看起来更像

事实表 -> 客户表 -> 客户组表
事实表 -> 项目表 -> 项目类型表

当您处理星型模式时，您将非规范化模式，以便在客户维度表中包含客户组描述，在项目维度表中包含项目类型描述。

星型模式的基础是你有一个事实表，每个维度都是一个表，离事实表只有一步之遥。

Kimball 描述它的方式：

星型模式的特征是由通过主/外键关系链接到关联维度表的事实表组成。

如果您不将维度非规范化为单维度表，您最终会得到雪花模式。雪花似乎是个好主意，但它们通常会导致查询性能变差，并且可能会给您带来各种麻烦，尤其是当您计划在数据仓库之上构建多维数据集时。

金博尔再次发表了一篇文章：

我们通常鼓励您在单个维度表中处理多对一的层次关系，而不是雪花状的。对于有经验的 OLTP 数据建模者来说，雪花可能看起来是最佳的，但对于 DW/BI 查询性能来说，它们并不是最佳的。链接的雪花表给直接接触表结构的用户带来了复杂性和混乱；即使用户从表中缓冲，雪花也会增加优化器的复杂性，优化器必须将数百个表链接在一起才能解决查询。雪花还给 ETL 系统增加了管理链接规范化表的键的负担，当链接的层次关系发生变化时，这些键会变得非常复杂。虽然雪花可以通过用代码替换重复的文本字符串来节省一些空间，但节省的空间可以忽略不计，

关于您关于更改客户数据和丢失历史记录的问题，在通过使用“缓慢变化的维度”解决的数据仓库中。

您基本上有几种类型的缓慢变化的维度，但您可能正在寻找“类型 2”，这主要归结为在维度行上存储 valid_from 和 valid_to 日期，以便您可以选择在交易时有效的行.

类型 2 SCD

除了主代理键之外，我建议向正在进行类型 2 处理的维度添加五个附加字段。这些字段如图 1 所示。日期时间是完整的时间戳，表示更改生效和下一个更改生效之间的时间跨度。类型 2 维度记录的结束有效日期时间必须完全等于该维度成员的下一次更改的开始有效日期时间。

这是一个需要涵盖的广泛主题，但我希望这能让您走上正确的基础知识之路，并且您将来可以使用正确的术语。

kimball 站点是维度建模的一个很好的资源（很多人称之为参考），所以我建议你浏览词汇表和设计技巧部分