这种关系是第三范式（3NF）吗？

Question

我创建了一个名为 Customer 的关系并将其定义为：

我只是想知道它是否在3NF中？

我担心的是地址，因为多个客户可能有相同的地址。

我想，因为地址有重复的值，所以它不在 2NF 中。我该如何解决这个问题？

我应该将姓名作为名字、姓氏和地址作为（国家、城市、...）分开吗？

Answer 1

表到底是1NF还是3NF，要看城市的域值是多少。这回答了您是否具有原子性。

本质上，关于地址信息的抽象中规范化的含义是非常有争议的，这不是一个容易回答的领域，因此我个人认为必须根据数据的语义使用逐案解决这一问题。

否则请考虑以下地址：

418 N Bradley St
Chelan, WA 98816

最大分解需要多少个原子场？所以我们认为这是：

CREATE TABLE address (
    id int not null unique,
    street_segment char(1),
    street_name varchar not null,
    city_name varchar,
    state_province varchar,
    mail_code
);

这似乎很简单，直到您得到一个地址，这在南美洲很常见，需要跨街，然后我们开始添加字段。但是现在您必须跟踪马那瓜的地址，例如：

Bo Altagracia km 3 1/2 carretera sur | Montoya 3c al Oe

请注意，这是一款基于地标，距离和方向的顺序地址，它不适合这个数据模型在所有和标准化表示需要至少一个附加表和一些额外的领域，而且我们不能再执行相同非空约束。

但这并不一定意味着如果我们只是将地址作为文本字符串存储在整个国家并包括国家/地区，那么这并不一定意味着有任何破坏 1NF 的情况。

如果您没有理由跟踪国家/地区，那么人们可能会将“伦敦，英格兰”视为城市名称的有效表示，然后是的，我们可以将其视为 1NF。本质上，这样的表具有城市域（其中“英格兰伦敦”与“英国伦敦”不同，“法国巴黎”与“北卡罗来纳州巴黎”不同）。这为您提供了许多可能的问题，但它不会造成典型的标准化问题，除非您需要跟踪国家/地区（这里的国家/地区只是城市域值的一个附带部分，而不是域本身）。

因此，在这种情况下，它可能是也可能不是1NF，具体取决于您如何定义地址的域以及您必须相对于什么来跟踪它。如果是1NF，那么它也是3NF。

但是，如果您将城市和国家分成不同的字段，那么您会遇到规范化问题，因为城市依赖于国家，因此要成为真正的 1NF，您可能需要更多地打破区域层次结构（城市表，州/省表、国家/地区表）。

对此的典型方法正是您所做的，即将地址视为文本字符串原子域，而不是进一步分解。

编辑：使用数组的 1NF 问题的另一个例子

假设在 PostgreSQL 上我正在存储 IP 地址并将查询八位字节。我可能代表一个IP地址作为SMALLINT []数组等：阵列[192,168,1,101,24]代替像“192.168.1.101/24”一个CIDR表示和这并没有破1NF。每个 smallint 数组在其域中都是不同的，每个数组都代表其域的一个值。这不会破坏 1NF，因为在 IP 地址的域中，每个数组代表其域中的单个值（这是由序数很重要的事实确保的）。这是一个很好的例子，说明为什么假设包含复杂的数据结构或数组必然违反 1NF 是错误的。

最后，如果“这种数据类型可以分解，因此它不是原子的”破坏了 1NF，那么每次使用日期时间数据类型也是如此......

TL; 博士

仅当列在给定域中存储两个或多个值时，才会违反 1NF 的原子性要求。在最初的问题中情况并非如此，因此鉴于显示的信息，不会违反 1NF。鉴于没有违反1NF，并且name和address都是customerid的函数，而不是eachother的函数，满足3NF的要求。