报告非规范化与规范化数据库[关闭]

Question

我们正在构建报告应用程序，我们将每天倾倒大量数据。目前，我们有两个数据模型，一个用于运营，另一个用于报告。

报告数据模型中的列很少出现在操作表中。如果操作数据模型得到更新，我们如何确保报告数据模型进行类似的更改，以及更新的成本是多少？

例：

Report Table - 
     user_name
     organisation_name
     event_name
     etc 10 more col.

User Table -
    id
    name
    ..

Organisation Table -
    id
    name 

让我们考虑报告表包含1百万条记录，并更改组织名称，该更改需要反映在报告表中。更改细节的频率可能是平均的。

所以我们有两个选择Normalized database - 这将保存报表上的更新，但查询处理将花费更长的时间。非规范化数据库 - 这将有助于我们指导更快的查询处理，但它将涉及维护它的复杂性。

请指教，我们应该走哪条路？我们的数据量非常高，报告数据非常精细。

Answer 1

第一个问题：

让我们考虑报告表包含1百万条记录，并更改组织名称，该更改需要反映在报表中...

......更新费用是多少？

它应该很低，因为我们不需要更新“报告表”。您只需更新维度表，原因如下：

考虑不要制作一个由报告工具直接读取的“报告表”。请考虑使用星型模式（“非规范化”选项之一）。将通过在运行时将事实与维度相关联来生成报告。

请参阅销售之星模式的实体关系图（ERD）：https://upload.wikimedia.org/wikipedia/en/f/fe/Star-schema-example.png

让我们假设Wiki文章中的示例ERD是拥有不同商店品牌的公司的数据仓库，因此它们的名称将彼此不同。

因此，我们将“store_name”列添加到DIM_STORE表，并仅添加到DIM_STORE表。 FACT_SALES表保持不变。

当商店更改其名称时，我们更新DIM_STORE.store_name列。

DIM_STORE和FACT_SALES在store_id上​​加入，允许我们从DIM获取当前商店名称。

商店很少更改其名称，但是当它确实发生时，报告用户通常希望记录此更改。这种类型的尺寸更新称为缓慢变化的尺寸（SCD）。

这篇Wiki文章解释了SCD：https://en.wikipedia.org/wiki/Slowly_changing_dimension

仅供参考，通常使用SCD类型1和2。我更喜欢Type 2，因为它保留了历史记录，但是根据您的报告要求选择最佳的历史记录。

ERD来自这篇关于星型模式的Wiki文章：https://en.wikipedia.org/wiki/Star_schema

第二个问题：

如果运营数据模型得到更新，我们可以确保报告数据模型进行类似的更改

如果在源系统中更改了表结构，则必须相应地手动更新加载过程和数据仓库表。在某些情况下，这可能涉及重新加载所有数据。

代理键：与您的问题密切相关，代理键是维持SCD所必需的：http://www.bidw.org/datawarehousing/what-is-surrogate-key/

在关于SCD的Wiki文章中，supplier_key是由数据仓库或ETL prcess生成的代理密钥，supplier_code类似于来自事务源数据库的organization_id（或Wiki文章中关于星型模式的store_id）。

我认为这些概念需要一些研究和重新阅读才能消化，所以我希望你不要急着做。如果做得好，他们需要大量的时间进行规划和设计，但以后会节省大量的开发时间。

Answer 2

唯一的选择是标准化数据库。为什么？

优点：

• 维护更方便。
• 由于您将拥有大量数据，因此规范化数据库将需要更少的磁盘空间！为什么？因为不是让我们说每次使用他的用户名表示用户，这可以说平均需要10个字符，你可以使用他的id，只需要2或3个字符。在长距离范围内，这是一个巨大的差异。

“慢”查询实际上并不是真的慢。唯一的骗局，只是一块蛋糕，你将不得不编码更多。但是你编码一次，数据库永远存在。

Answer 3

“非规范化”一词的问题在于它并没有具体说明您将要使用的设计原则。一个更好的计划是采用一个特定的设计计划，一个不会导致完全规范化的数据库，但是有一些东西可以实现。

一个相当广泛使用的设计方案是星型模式，或近似变体，雪花模式。这两种模式已用于报告数据库，以及数据集市和数据仓库。

在我处理星型模式的每种情况下，都会从一个或多个其他数据库中复制数据，并对这些源数据库进行规范化。源数据库用于OLTP（在线事务处理），而星型模式用于OLAP（在线分析处理）目的，包括报告。

将数据从OLTP存储定期传输到OLAP存储的过程（例如每天一次）称为ETL（提取，传输和加载）。这本身就是一门艺术，你可以购买一些工具来促进ETL。如果您想构建自己的ETL过程，还可以学习一些技巧。

具有两个数据库的模式，一个用于OLTP，另一个用于OLAP，使您可以在两个不同的上下文中获得两种不同设计模式的好处。维护两个不同的数据库的成本几乎是维护一个数据库的两倍，您还必须管理传输过程。

所有这些都没有给你一个明确的答案，但它确实给你一些流行语用于搜索网络上的相关项目。

Answer 4

我认为您需要了解的第一件事是组织名称可能会发生变化的频率。如果答案不是很频繁，那么我会将报告表保持原样（非规范化）。