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