数据库规范化

Question

我是数据库设计的新手，我一直在阅读有关规范化的大量内容。 如果我有三张桌子：住宿、火车站和机场。 我会在每个表中都有地址列还是其他表引用的地址表？ 有没有过度规范化这样的事情？

谢谢

Answer 1

数据库规范化是关于构建关系（表），以维护关系（表）内的事实（列）之间以及构成模式（数据库）的各种关系（表）之间的某些功能依赖性。 有点满嘴，但这就是它的全部意义。

关系数据库理论中五种范式的简单指南是范式的经典参考。 本文简单定义了每种范式的本质是什么，以及它对数据库表设计的意义。 这是一个非常好的“试金石”参考。

要正确回答您的特定问题，需要附加信息。 您必须提出的一些关键问题是：

• 地址是简单事实（例如文本块）还是复合事实（例如由多个属性组成：地址行、城市名称、邮政编码等）？
• 与“住宿”、“机场”和“火车站”有关的其他“事实”是什么？
• 哪些“事实”集唯一且最低限度地识别“机场”、“住宿”和“火车站”（这些事实通常称为关键或候选关键）？
• 地址事实和构成每个关系键的事实之间存在哪些函数依赖关系？

综上所述，您问题的答案并不像人们希望的那样直接！

是否有“过度规范化”之类的东西？ 也许。 这取决于您已确定并用于构建表的功能依赖项是否对您的应用程序域具有重要意义。

例如，假设确定一个地址由多个属性组成； 其中之一是邮政编码。 从技术上讲，邮政编码也是一个复合项目（至少加拿大邮政编码是）。 进一步规范化您的数据库以识别这些事实可能会过度规范化。 这是因为邮政编码的组成部分与您的应用程序无关，因此将它们纳入数据库设计将是一种过度规范化。

Answer 2

对于地址，我几乎总是会创建一个单独的地址表。 不仅用于规范化，还用于存储字段的一致性。

至于过度规范化这种事情，绝对有！ 很难就什么是过度规范化和什么不是过度规范化提供指导，因为我认为这主要来自经验。 但是，请遵循有关每个标准化级别的书籍，然后一旦开始变得难以看出事情的发展方向，您可能已经走得太远了。

也可以查看所有示例/示例数据库。 它们会很好地指示您何时应该拆分数据，何时不应该拆分数据。

此外，请充分了解您存储的数据类型和数量，以及访问速度等。由于许多性能和可扩展性原因，许多现代 Web 软件正在完全非规范化。 值得研究一下为什么以及何时应该和不应该去规范化的原因。

Answer 3

我会在每个表中都有地址列还是其他表引用的地址表？

机场、火车站和住宿是否可以使用不同的地址格式？

单个 ADDRESS 表最大限度地减少了处理地址所需的工作 - 套件、RR、邮政/邮政编码、州/省...

有没有过度规范化这样的事情？

有不同级别的标准化。 我只遇到过我认为糟糕的设计而不是规范化。

Answer 4

就个人而言，我会去另一张桌子。

我认为它使设计更简洁，使地址报告更简单，并使您需要更轻松地对地址架构进行任何更改。

如果您稍后需要对其进行非规范化，您始终可以创建两个视图，其中包含火车站和机场信息以及您需要的任何地址信息。

Answer 5

这不是我真正理解的规范化。 您似乎不是在谈论删除冗余，而是在谈论如何对存储或数据模型进行分区。 我假设住宿、火车站和机场的地址示例都是不相交的？

据我所知，如果您开始沿着思路思考，那只会是规范化。 邮政编码在功能上取决于街道地址，因此应将其分解到自己的表中。

在这种情况下，这可能是可取的或不可取的，具体取决于上下文。 如果您管理记录并且可以确保正确性，则可能是可取的，如果用户可以更新他们自己的记录则不太可取。

一个相关的问题是标准化一个人的名字是否太过分了？

Answer 6

如果您有一个对性能非常敏感的项目/功能，在某些情况下对数据库进行非规范化可能是明智之举。 但是，由于各种原因，这可能会导致维护问题。 您可能希望使用缓存表复制数据，但这也有缺点。 这确实是个案基础，但在通常的实践中，数据库规范化是一件好事。 我见过的 99% 的非规范化数据库不是设计的，而是开发人员的误解/错误。

Answer 7

我会在每个表中都有地址列还是其他表引用的地址表？

正如其他人所暗示的那样，这并不是一个真正的规范化问题，因为您并没有试图减少冗余或组织依赖项。 无论哪种方式都是完全可以接受的。 如果您要集中验证或特定于地址的业务逻辑，则将地址移动到单独的表可能是有意义的。

有没有过度规范化这样的事情？

是的。 如前所述，在大型系统（大量数据、大量事务或两者）中，您可以标准化到性能成为问题的程度。 这就是为什么许多系统使用非规范化数据库进行报告和查询的原因。

除了性能之外，还有一个问题是数据查询的难易程度。 在将有大量最终用户查询数据的系统中（可能很危险！），对于大多数非技术人员或非数据库人员来说，非规范化结构更容易理解。

像我们处理的大多数事情一样，这是理解、性能和未来可维护性之间的权衡，并且很少有明确的答案来说明在任何给定系统中的界限。

凭借经验，您将了解最适合您编写的系统的界限在哪里。

话虽如此，我的偏好是在更多与更少的标准化方面犯错。

Answer 8

我认为在这种情况下，每个表中都有地址列是可以的。 您几乎不会有一个会被使用两次以上的地址。 大多数地址将仅用于每个实体一个。

但是额外的表格中可能包含街道、城市、国家/地区的名称……

最重要的是，每个火车站、住宿和机场都可能只有一个地址，因此是 n:1 关系。

Answer 9

如果您使用的是 Oracle 9i，您可以将地址对象存储在您的表中。 这将消除对地址格式的（合理的）担忧。

Answer 10

我同意 S.Lott 的观点，并想补充：

1. 一个好的答案取决于你已经知道的东西。 然而，关系数据库理论的基本“数学”定义了非常明确的、不同的规范化级别。 当你达到最终的正常形式时，你就不能再正常化了。

2. 根据您想用三个实体建模的内容以及识别它们的方式，您可以提出非常不同的概念数据模型，所有这些模型都可以用标准形式的混合表示——或者根本不规范化（如 1表中包含所有数据的描述符和 NULL 空洞……）。 考虑将您的三个实体标准化为最终的正常形式。 我现在可以引入一个新的需求、用例或扩展，如果你查看它的内容，它会给一个到目前为止的描述性属性以某种方式排序、引用或结构化的性质。 然后，模型应该表示这种行为，曾经是一个属性的东西也许最好是一个被其他实体引用的单独实体。

3. 过度规范化？ 只有在某种意义上，您才能规范化给定模型，使其在给定数据库平台上的存储或处理效率低下。 根据可以在那里有效处理的内容，您可能希望对某些方面进行非规范化，权衡冗余以换取速度（数据仓库数据库一直这样做）和洞察力，反之亦然。

到目前为止我看到的所有（工作）数据库设计要么有一个相当规范化的概念数据模型，在逻辑和/或物理数据模型级别（用 Sybase PowerDesigner 术语来说）进行了相当多的非规范化，以使模型“可管理” -- 要么，要么他们不工作，即失败，因为维护问题很快就变成了特大号。

Answer 11

当您说“地址”时，我想您是指完整的地址，例如街道、城市、州/省、国家/地区和邮政编码。 那是 4 或 5 个字段，如果您允许“地址行 1”和“地址行 2”、转交等，则可能更多。这肯定应该在一个单独的表中，并使用“addressid”链接到 Station，等表。 否则，您将创建同一组字段定义的 3 个单独副本。 这是个坏消息，因为它需要额外的努力来保持它们的一致性。 比如，如果最初你只处理美国地址（我是美国人，所以我假设是美国），但后来你发现你还需要允许加拿大人。 您需要扩大邮政编码字段的大小并添加国家/地区代码。 如果有一个公共表，那么你只需要做一次。 如果没有，那么你必须这样做三遍。 并且“三次”很可能不仅仅是更改数据库架构，而是更改程序中处理地址的每个位置。

规范化的好处之一是最小化更改的影响。

Answer 12

有时您希望非规范化以提高查询效率。 但这应该非常谨慎地进行，只有在您有充分的理由相信完全规范化的模型会造成严重的低效率问题之后。 以我卑微的经验，大多数程序员都无法快速进行非规范化，通常会很快“哦，把它分解成一个单独的表太麻烦了”。

Answer 13

我只能在此处已经发布的答案中添加一个更具建设性的注释。 无论您选择标准化您的数据库，当地址标准化（看起来相同）时，这个过程几乎变得微不足道。 这是因为当您努力防止重复时，所有实际上相同的地址看起来都相同。

现在，标准化地址是不平凡的。 有 CASS 服务可以为您（针对美国地址）执行此操作，这些服务已通过 USPS 认证。 我实际上在SmartyStreets工作，这是我们的专长，所以我建议您从那里开始搜索。 您可以执行批处理或使用 API 来标准化您收到的地址。

如果没有这样的东西，您的数据库可能会被规范化，但是重复的地址数据（无论是正确的还是不完整的和无效的等）仍然会渗入，因为它们可以采用多种形式。 如果您对此还有任何疑问，我会亲自为您提供帮助。