database-design - 什么是归一化(或归一化)？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

11 个月前关闭。



Improve this question




为什么数据库人员继续规范化？

它是什么？它有什么帮助？

它适用于数据库之外的任何东西吗？

Answer 1

规范化基本上是设计一个数据库模式，以避免重复和冗余数据。如果相同信息在数据库中的多个位置重复，则存在在一个位置而不是另一个位置更新的风险，从而导致数据损坏。
有许多标准化级别，从 1. 范式到 5. 范式。每个范式都描述了如何摆脱某些特定问题。
第一范式 (1NF) 很特殊，因为它与冗余无关。 1NF 不允许嵌套表，更具体地说，不允许将表作为值的列。 SQL 首先不支持嵌套表，因此大多数普通关系数据库默认为 1NF。所以我们可以在接下来的讨论中忽略 1NF。
范式 2NF 到 5NF 都涉及相同信息在同一张表中多次表示的场景。
例如，考虑一个卫星和行星的数据库:

Moon(PK) | Planet  | Planet kind
------------------------------
Phobos   | Mars    | Rock
Daimos   | Mars    | Rock
Io       | Jupiter | Gas
Europa   | Jupiter | Gas
Ganymede | Jupiter | Gas

冗余是显而易见的:木星是一颗气态行星的事实被重复了三遍，每个卫星一个。这是一种空间浪费，但更严重的是，这种模式使不一致的信息成为可能:

Moon(PK) | Planet  | Planet kind
------------------------------
Phobos   | Mars    | Rock
Deimos   | Mars    | Rock
Io       | Jupiter | Gas
Europa   | Jupiter | Rock <-- Oh no!
Ganymede | Jupiter | Gas

查询现在可以给出不一致的结果，这可能会带来灾难性的后果。
(当然，数据库不能防止输入错误的信息。但它可以防止不一致的信息，这同样是一个严重的问题。)
规范化设计会将表拆分为两个表:

Moon(PK) | Planet(FK)     Planet(PK) | Planet kind
---------------------     ------------------------
Phobos   | Mars           Mars       | Rock
Deimos   | Mars           Jupiter    | Gas
Io       | Jupiter 
Europa   | Jupiter 
Ganymede | Jupiter 

现在没有事实重复多次，所以不存在数据不一致的可能性。 (由于行星名称重复，看起来仍然存在一些重复，但将主键值作为外键重复并不违反规范化，因为它不会引入数据不一致的风险。)
经验法则
如果相同的信息可以用更少的单个单元格值表示，不计算外键，那么应该通过将表拆分为更多表来规范化该表。例如，第一个表有 12 个单独的值，而两个表只有 9 个单独的(非 FK)值。这意味着我们消除了 3 个冗余值。
我们知道相同的信息仍然存在，因为我们可以写一个 join查询返回与原始非规范化表相同的数据。
如何避免此类问题？
通过对概念模型进行一些思考，例如通过绘制实体关系图，可以轻松避免规范化问题。行星和卫星是一对多的关系，这意味着它们应该用外键关联在两个不同的表中表示。当具有一对多或多对多关系的多个实体在同一表行中表示时，就会发生规范化问题。
规范化重要吗？ 是的，这是非常重要的。如果数据库存在规范化错误，就会面临将无效或损坏的数据导入数据库的风险。由于数据“永远存在”，因此在第一次进入数据库时​​很难清除损坏的数据。
但我真的认为区分从 2NF 到 5NF 的不同范式并不重要。当模式包含冗余时，通常很明显 - 只要问题得到解决，无论是 3NF 还是 5NF 被违反都不那么​​重要。
(还有一些额外的范式，如 DKNF 和 6NF，它们仅与数据仓库等特殊用途系统相关。)
不要害怕规范化 .规范化级别的官方技术定义非常模糊。这听起来好像归一化是一个复杂的数学过程。但是，规范化基本上只是常识，您会发现如果使用常识设计数据库模式，它通常会完全规范化。
关于规范化有很多误解:

有些人认为规范化的数据库速度较慢，而非规范化可以提高性能。然而，这仅在非常特殊的情况下才是正确的。通常，规范化数据库也是最快的。

有时标准化被描述为一个渐进的设计过程，您必须决定“何时停止”。但实际上标准化级别只是描述了不同的具体问题。 3rd NF 以上的范式解决的问题首先是非常罕见的问题，因此您的模式很可能已经在 5NF 中。

它适用于数据库之外的任何东西吗？ 不直接，不。规范化的原则非常适用于关系数据库。然而，一般的基本主题——如果不同的实例可能不同步，你不应该有重复的数据——可以广泛应用。这基本上是 DRY principle .