我目前遇到的一个问题是我对标准化有所了解，但是我觉得构建数据库的方式不需要对它进行标准化。简而言之，我正在使用Tkinter Python和SQLite3作为通讯录管理员。我只有一个表，它有9（技术上是10）列。
FirstName|LastName|Email|Notes|PhoneNumber|Address|City|State|ZipCode
还有一个名为“ ID”的附加列，它是自动创建的rowID，也是我用作“主键”的行。
因此，考虑到这些信息，我允许用户添加个人，并能够编辑所有这些信息，也可以删除等等。
因此，如果有人想添加一个新人，他们可以这样做。如果一个人搬到另一个地址，他们可以更改它。新电话号码？可以编辑。
这种信息编辑不会在数据库或任何其他类型的“异常”中创建冗余或重复。但是，我希望从别人的角度出发。
但是就我所处的情况而言，我不明白为什么我需要创建一个新表来规范化数据库。这是一个非常简单的数据库，似乎不需要它。
答案 0 :(得分：3)
简单的答案是，您描述的表已经已充分规范化 。这可能就是为什么您找不到实际的理由来进一步规范化它的原因。
但是，如果您放弃了这个想法并且在改进或扩展数据库时不继续考虑数据库规范化的原则，那么您很可能会遇到数据库规范化要解决的问题。许多SQL功能需要适当的规范化，不能正常工作，或者如果数据未经规范化则不适用。
例如，如果您决定希望每个联系人都具有多个电话号码，则可以添加PhoneNumber2列，也可以添加两列HomePhoneNumber和MobilePhoneNumber。然后，您可能想要多个电子邮件地址，昵称，多个地址等，等等。
您可能开始有重复的数据，这些数据需要手动更新或需要不断擦洗数据库的代码等。如果要添加其他相关表，总的来说数据库将变得更加灵活。然后，例如，您可以添加许多不同的电话号码，而不仅限于2列，也不必不断添加和重命名列...这反过来可能需要对应用程序代码进行重大更改，才能添加新的电话号码列。
由于我同意这个话题会变得不必要地复杂，所以我将在很大程度上保留我的答案。但是值得讨论一下philipxy关于第3范式（3NF）失败的通知...只是为了使我的回答更具体和有用。对于OP，以下字段并非彼此完全独立：
Address|City|State|ZipCode
ZIP + 4码（00000-0000）足以标识一个地址。 5位代码足以识别城市和州。因此，在某种程度上，将所有字段包含在一个表中具有“冗余”数据（与传递相关的字段）。为了解决这种情况，可以将City和State字段移动到单独的表中，并使用ZipCode作为外键和主键，从而进一步满足3NF的要求。
将街道地址字段移动到另一个表并在ZIP + 4上进行链接对于一次性地址而言是荒谬的，因为这最终会产生一对一的关系，从而实质上使附加表的任何用处都无效。存储通用的ZIP + 4参考表同样很可笑，因为即使需要街道地址验证的企业级系统也将利用Web服务进行验证，而不是容纳一些笨拙的本地标准化表。
实际上，很少对地址和邮政编码执行此操作。这不是企业级系统，因此通常认为这种技术性是不必要的，或者完全被忽略。从技术上讲，实际的USPS数据库具有邮政编码，该邮政编码具有多个地方可接受的名称（除其他例外），因此，如果尝试以任何可能的方式应用所有常规格式，则可能会变得过于复杂。
是否可以将字段保留为原样以允许存在矛盾和/或冗余的数据？是。一个人可能在城市旁边有一个不正确的邮政编码，或者一个与街道地址不符的ZIP + 4错字。如有必要，请考虑实施地址验证Web服务（甚至为每个地址手动在线执行此操作），然后再担心这种情况下的标准化。
这种简要分析的实质是：尽管OP误解了表格总体上已经匹配了多个范式，但OP的直觉也很正确，即不必（且不常见）应用所有/某些范式。