报告非规范化与规范化数据库

时间:2017-08-30 08:11:32

标签: database-design database-normalization denormalization

我们正在建立报告申请,我们将每天倾销大量的数据。目前,我们有两个数据模型,一个用于运营,另一个用于报告。

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

示例:

Report Table - 
     user_name
     organisation_name
     event_name
     etc 10 more col.

User Table -
    id
    name
    ..

Organisation Table -
    id
    name 

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

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

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

4 个答案:

答案 0 :(得分:1)

第一个问题:

  

让我们考虑报告表包含1百万条记录,   和组织名称变更,这种变化   需要反映在报告表中......

     

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

它应该很低,因为我们不需要更新"报告表"。您只需更新维度表,原因如下:

考虑不制作报告表"由报告工具直接读取。请考虑使用星型模式("非规范化"选项之一)。将通过在运行时将事实与维度相结合来生成报告。

请参阅销售之星架构的实体关系图(ERD): https://upload.wikimedia.org/wikipedia/en/f/fe/Star-schema-example.png

让我们想象一下,维基文章中的示例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)。源数据库。

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

答案 1 :(得分:0)

唯一的选择是规范化数据库。为什么呢?

优点:

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

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

答案 2 :(得分:0)

“非规范化”一词的问题在于,它并不具体说明您将要使用的设计原则。一个更好的计划是采用一个特定的设计方案,一个不会导致完全规范化的数据库,但这有一定的意义。

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

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

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

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

所有这些都没有为您的问题提供明确的答案,但它确实为您提供了一些用于搜索网络相关项目的流行语。

答案 3 :(得分:0)

我认为您需要了解的第一件事是组织名称更改的频率。如果答案不是很常见,那么我将报表表保持原样(不规范化)。