我设计了一个具有 3 个维度和一个事实的数据仓库，为此我阅读了 Kimball、Bouman、Malinowski 的一些书籍......
在名为The Data Warehouse ETL Toolkit 的 Kimball 和 Caserta 书中，第 128 页谈到了审计维度。据我了解，它和其他维度一样是与事实挂钩的维度，主要用于评估数据质量。
问题是……这个审计维度实际上是用在企业环境中的吗？大公司在他们的数据仓库项目中使用它？
我正在做我的最终学位项目，我不知道我是否应该包括这个维度，因为我只在书本上看到过它，但这似乎是一种用于数据质量目的的好方法。
提前致谢。
【问题讨论】：
标签： design-patterns database-design data-warehouse etl business-intelligence
OP 询问，
这个审计维度实际上是用在企业环境中的吗？大公司在他们的数据仓库项目中使用它？
简短的答案是：是的，有时
长 答案是，审计维度在真正需要时使用。审计维度应该存储 ETL 元数据信息。其中一些元数据可以直接存储在事实表本身中。 load date、loading batch number、job name、user name 等数据可以直接存储在事实表中。
但事实上，当您决定将这些信息存储在事实表本身中时，您很快就会意识到其中许多信息实际上对于大量记录是相同的事实表。
例如，如果您每天在事实表中加载 10 万条记录，那么所有这 10 万条记录的loading job name、source file name、user who executed the job、batch number 等都是相同的。因此，如果您从事实表中删除这些信息，并将其保存在单独的表中并将该单独表的 surrogate key 引用到您的事实中，这确实是有意义的。这减少了数据冗余和空间需求，可能提高了加载速度。正常数据规范化技术，你知道的。
当然，有些信息您应该不放入您的审核维度。比如说，load date-time 的记录。对于您的事实中的所有记录，这将是唯一的 - 所以很明显，如果您要将这些信息放在您的审计维度中，您的审计表将与您的事实一样大。相反，您应该将此类信息放入事实表本身。
我亲眼见过/工作过一些世界上最大的零售和电信行业的数据仓库，并见证了这些数据仓库中的某种审计维度。
【讨论】：
是的，它很有用，因为它允许您存储关于每一行的流程元数据。这可能包括：
这些信息对于定期监控以及出现问题时的调试都是非常宝贵的。考虑一个非常简单的例子——当有人错误地加载了错误的源文件时，如何快速识别应该删除且没有审计维度的行？
【讨论】：