如何处理 B.I 数据模型中的非规范化答案

【问题标题】：How to handle denormalization in B.I data model如何处理 B.I 数据模型中的非规范化
【发布时间】：2017-12-01 13:22:04
【问题描述】：

据我所知，规范化是为了避免数据库中的不一致。

通过归一化我们：

减少数据冗余，并且
保护数据完整性。

这就是大多数 OLTP 数据库采用 3NF 的原因。

来自 OLTP 的不同数据库汇集在一个数据仓库中。（DWH，OLAP）。 DWH 是非规范化的 (1FN)，很明显它必须是这样的，因为 DWH 的主表有数百列。

通过该 DWH，我们可以构建多个数据集市，稍后我们将使用 BI 报告工具（Cognos、QlikView、BO ..）进行分析

问题在于 BI 报表的数据模型没有规范化。

这难道不是报告的冗余和数据完整性的问题吗？

【问题讨论】：

将数据仓库视为报表而不是数据库。此外，数据仓库不会受到与正常形式所关注的相同类型的异常的影响。通常，数据仓库会插入行，但不会更新或删除。

标签： data-warehouse business-intelligence olap database-normalization denormalization

【解决方案1】：

在 OLAP 系统（如数据仓库）中，关键的效率需求在于查询和数据检索。

因此，一些设计考虑是为了更快地检索信息，即使更新可能更长。

此类模型的一个示例是 Star-Schema，我们在其上对数据进行非规范化处理，所有数据都将存储在 1-join-hop 距离内。

事务等关键元素位于大表（Facts）中，外键指向维度。

维度本身较小，并且可能包含未规范化的数据。例如，address 维度可以存储街道、社区和城市数据，而无需将其规范化为 3NF。

确实存在冗余问题（您实际上不必为每个日期行存储Day_of_Week），但这并不重要（因为在这种情况下存储不是瓶颈）。

根据完整性 - 你只在更新时面对它（FE 一个不太现实的场景，State_Province 在Dim_Store 中更改），并且在 DWH 更新是一种罕见的情况，我们允许自己效率低下。

此外 - 完整性不是由 DB（或规范化）强制执行，而是由 ETL 过程的设计和实现来强制执行。

Read more on Data Warehouses modeling

【讨论】：

但这里的问题是，如果我们用于报告且未标准化的维度表，是否不代表报告的完整性或冗余性存在问题？如果不是为什么？未规范化的小表可能会有些不协调。
有意识地减少冗余以支持这些关键需求。数据库不强制执行完整性。它需要以这种方式满足报告速度和可理解性的其他目标。相反，您依靠 ETL 来保持一致性和完整性。就完整性和所需空间而言，冗余只是一个问题。 DW 优先考虑其他事情。您可以拥有一个非常好的 ETL，以确保所有数据都具有高完整性，或者不好的 ETL。
确实存在冗余问题（您实际上不必为每个date 行存储Day_of_Week），但这并不重要（因为在这种情况下存储不是瓶颈）。根据完整性 - 您只在更新时面对它（F.E. brand 每个产品的更改），在 DWH 中更新是一种罕见的情况，我们允许自己效率低下。
@Dimgold 谢谢，您能否将该部分添加到验证答案中。

【解决方案2】：

关于冗余：一些数据仓库引擎（如 Amazon Redshift）允许非常方便地进行非规范化的数据压缩。假设您有一个包含 1 亿条记录的销售事件表，并且每笔销售都有一个城市。在 OLTP 数据模型中，您将有 sales 和 cities 与 city_id 连接它们。在允许压缩的 OLAP 数据模型中，使用压缩文本 city 属性的 sales 表要容易得多。您将能够在不连接表格的情况下按城市计算销售额，并且您的城市值不会占用太多磁盘空间，因为它们会被编码。

有关压缩的更多信息在 Amazon 文档中：Choosing a Column Compression Type

关于数据完整性：您必须设计 ETL 例程以最大限度地减少重复数据的可能性，并根据以下标准运行计划的重复检查：

select count(*) from table;
select count(*) from (select distinct <expression> from table);

其中是列的列表，其组合应该是唯一的（您的人工主键）。

【讨论】：