数据规范化和编写查询

Question

我是个小伙伴。开发人员（工作5个月），我对数据规范化有疑问。现在，据我所知，数据规范化背后的一般原则是创建一个RDBMS，将​​数据冗余保持在最低限度。在我的项目中，其中一个DB人员创建了一个DB。我们有50多个表，DB中的表通常非常分散，即。一个表有两三列，就是这样。现在，当谈到编写SQL查询时，由于每个查询都涉及梳理几个不同的表并将它们连接在一起，因此它已成为一种轻微的麻烦。我想知道这是否是数据规范化的副作用？或者这指向其他什么？

我知道对我来说最简单的事情就是根据我必须编写的查询来编写表。这将创建一个包含大量冗余数据的数据库，但我很好奇是否有一个快乐的媒体？

就像后记一样，我不想碰到我正在抱怨我的工作，但我真的很想知道更多关于这一点。我的工作环境不是最友好的，所以我不愿意和同事提出这个问题。但是，我会感谢更有经验的人的任何想法，书籍，教程或意见。

感谢。

Answer 1

Answer 2

  

数据规范化背后的一般原则是创建一个RDBMS，其中数据冗余保持最小。

只是部分正确。

规范化与“冗余”无关。

这是关于“更新异常”。

1NF是“不使用数组”规则。打破1NF意味着一行不是原子的，但集合中的集合和独立更新不会很好。会有锁定和缓慢。

2NF是“一键”规则。每行只有一个键，行中的所有内容都取决于键。密钥的部分没有依赖关系。有些人喜欢谈论候选键，自然键和外键;它们可能存在，也可能不存在。当所有属性都依赖于一个键时，满足2NF。如果密钥是单列代理键，则通常会满足此正常形式。

如果违反了2NF，您的列将依赖于部分键，而不是整个键。如果您有一个表（部件号，修订号）作为键，以及颜色和重量的属性，其中重量取决于整个键，但颜色仅取决于部件号。您有一个2NF问题，您可以更新某些部件颜色而不是其他颜色，从而产生数据异常。

3NF是“唯一的关键”规则。如果将派生数据放在一行中，并更改派生结果，则它与源列不匹配。如果更改源列而不更新派生值，则也会出现问题。是的，触发器是一个糟糕的黑客攻击，允许3NF设计违规。这不是重点。关键在于定义3NF并显示它可以防止更新问题。

  

每个查询都涉及梳理几个不同的表并将它们连接在一起。我想知道这是否是数据规范化的副作用？

是的。

Answer 3

Database views 是这种困境中至关重要的工具。 This excellent introduction说：

  

这是个好消息：你不必使用规范化的表格！ ...在顶层创建一个连接视图的抽象层非常容易（至少对于DBA而言）标准化数据表，将基表完全“置于幕后”，并且看不到。

Answer 4

这听起来像数据规范化，但我必须更多地了解架构，业务案例等，以便可靠地进行调用。如果您拥有对数据库的控制权，则可以编写一个view来表示链接表的常见查询。为了提高性能，您可以创建indexed or materialized视图（名称取决于数据库平台，在本例中为Oracle vs. Sql Server）。

几乎任何数据库入门都可以帮助您实现这些概念。如果您正在使用Sql Server并且真的有兴趣了解更多信息，SQL Server Books Online是一个很好的资源。

Answer 5

拥有大量表格肯定是数据库设计规范化的一个症状。在编写查询时这可能会很痛苦，但它比使数据不同步要好得多。

我有时会编写带有数千个表的数据库。每天晚上，我们都有一个程序运行并将生产表中的数据转储到data warehouse，以便我们可以更轻松地报告。数据仓库表的规范化程度要低得多，这使得编写查询变得更加简单。如果在你的情况下有意义，你可能想要考虑这样的事情。

Answer 6

如果没有看到数据，很难说你的数据是否过度规范化（或者没有正确规范化 - 在几个表上传播字段并不意味着它已经标准化）一般来说，你可能需要加入几个数据用于在规范化的数据库中查看有用数据的表。

您可以创建将表连接在一起的视图，然后您可以查询视图。这在选择数据时可能会有所帮助。

Answer 7

在设计良好的数据库中，您在查询中需要的连接应该非常容易编码。缺点是你有详细的SQL。好处是巨大的： -

• 一致易于更新的表格。
• 根据业务需求快速更改。设计良好的DB通常可以处理在原始设计中甚至没有考虑过的查询。
• 快速容纳新实体。将新数据实体和属性添加到设计良好的数据库中相对容易。它可能是一个噩梦，对非规范化数据库进行看似简单的更改。