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

我们正在构建报告应用程序，其中我们将每天倾销大量数据。目前我们有两个数据模型用于运营和另一个报告。报告非规范化与规范化数据库

报表数据模型中的几列存在于操作表中。如果操作数据模型得到更新，我们可以如何确保报告数据模型进行类似的更改，那么更新的成本又会是多少？

例子：

Report Table - 
    user_name 
    organisation_name 
    event_name 
    etc 10 more col. 

User Table - 
    id 
    name 
    .. 

Organisation Table - 
    id 
    name

让我们考虑报告表包括1万条记录，并组织名称得到改变，这种改变需要在报告表中反映出来。改变细节的频率可能是平均的。

因此，我们有两个选择规范化的数据库 -
这将节省报告表更新用，但查询处理将需要更长的时间。非规范化数据库 - 这将有助于我们指导更快的查询处理，但它会涉及到维护它的复杂性。

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

来源

2017-08-30 RockStar

一些查询可能会更快，有些人可能会比较慢。 “不成熟的优化是万恶之源。” – philipxy

唯一的选择确实是归一化数据库。为什么？

优点：

更容易维护。
由于您将拥有大量数据，规范化的数据库将需要更少的磁盘空间！为什么？因为我们不是每次用他的用户名代表用户，我们说平均需要10个字符，而是使用他的id，并且只用2或3个字符。在很远的范围内，这是一个巨大的差异。

“较慢”的查询实际上并不是真的很慢。唯一的弱点是，你必须多编一些代码。但是，你编码一次，数据库永远保持。

来源

2017-08-30 08:16:52 campovski

你的规范化的例子是引入一个代理键。除少数情况外，代理键与标准化无关。规范化是将复杂谓词分解为基本事实类型，同时保留数据中的依赖关系，其目标是通过消除冗余和数据异常来确保一致性。存储空间和性能不是逻辑模型的问题。 – reaanb

我认为这个问题并没有问什么是标准化或什么是标准化，但为什么要使用标准化。更简单的维护帐户（数据一致性等） – campovski

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

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

在我处理星型模式的每一种情况下，数据都是从一个或多个其他数据库复制而来的，并且这些源数据库被标准化。源数据库用于OLTP（联机事务处理），而星型模式用于OLAP（联机分析处理）目的，包括报告。

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

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

所有这些都不能为您的问题给出明确的答案，但它确实为您提供了一些用于在网络上搜索相关项目的流行语。

来源

2017-08-30 10:46:19

第一个问题：

让我们考虑报告表包括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

FYI，SCD 1型和2是常用的。我更喜欢Type 2，因为它保留了历史记录，但是为您的报告要求选择最好的一个。

的ERD来源于此维基文章星型架构： https://en.wikipedia.org/wiki/Star_schema

第二个问题：

如果运行数据模型得到更新，我们如何确保上报数据模型做出类似的改变

如果表结构在源系统发生变化，那么你将^ h可以相应地手动更新您的加载过程和数据仓库表。在某些情况下，这可能涉及重新加载所有数据。

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

在上的SCD维基文章supplier_key是由数据仓库或ETL prcess产生的代理键，并且supplier_code类似于来自事务性源数据库的organization_id（或Wiki文章中有关星型模式的store_id）。

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

来源

2017-10-10 00:41:52

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

回答

相关问题