数据库规范化 - 外键答案

【问题标题】：Database normalization - foreign keys数据库规范化 - 外键
【发布时间】：2013-07-30 01:43:18
【问题描述】：

我正在尝试了解数据库规范化，我了解总体思路，但什么是正确的方法，什么是多余的。

例如，我有一个标准的员工部门数据库作为第一步。

表格是

EMPLOYEES:
id, first_name, last_name, dob, email, city, address, department_name

因此，为了将其标准化为第一步，我会将部门名称移动到单独的表中，并在必要时以多对一的形式加入。

EMPLOYEES:
id, first_name, last_name, dob, email, city, address, department_id
DEPARTMENTS
id, name

这是否足以进行规范化，还是将除department_id 之外的所有其他字段移动到像employees_meta 这样的第二个表更好？想象一下，如果我们在描述员工的表中还有 20 个字段，那么什么是正常的？

如果我们谈论的是优化网页，正确的规范化是只将我们在处理员工表时始终显示的字段以及我们不经常使用的所有其他信息移动到不同的表中吗？

【问题讨论】：

规范化处理实体。代表模型中实体的所有内容都应该分开（规范化）。到目前为止，您的标准化看起来还不错:o)
谢谢，这是一个简短而美好的定义，可惜它在 cmets 中 :)
thanx，但为什么评论不好？
是的，我会说这是一个很好的答案
您可以为该评论投票；）

标签： mysql database database-design

【解决方案1】：

EMPLOYEES:
id, first_name, last_name, dob, email, city, address, department_name

因此，为了将其标准化为第一步，我将移动部门名称到一个单独的表，并在必要时以多对一的形式加入。

EMPLOYEES:
id, first_name, last_name, dob, email, city, address, department_id
DEPARTMENTS
id, name

当您基于函数依赖进行规范化时，您的原始表总是以更少的列结束。你从 8 开始，你以 8 结束。

您将原始表中的“department_name”替换为“department_id”。否规范化指南说“用 ID 号替换文本”。这不仅与规范化无关，它还引入了以前不需要的强制连接。

这并不一定意味着用 ID 号替换文本是错误的做法。确实意味着您不应该将其称为规范化。因为不是。

规范化的第一步是识别候选键和函数依赖关系。

【讨论】：

很好的答案，但第一步是确定与应用程序域相关的功能依赖关系——这是通过查看建议的表格布局无法真正得到的。识别相关的功能依赖需要大量的领域披露和分析。
这就是为什么我说，“规范化的第一步是识别候选键和函数依赖关系。”

【解决方案2】：

将城市字段移动到单独的表中，我认为这足以正常。 database normalization 的简单关键是避免重复值并将其分隔到单个表中。但是，有些情况下的数据不需要像sex字段那样分开，最好使用枚举数据类型，然后再分开到其他表中。

注意：查询连接表过多会降低性能。

【讨论】：

是的，完全忘了city会重复，但是我提到的meta表值得吗？
+1 你是对的，城市看起来也是这个模型中的一个实体 :o)
@Vlakarados 它总是取决于您的型号和功能。如果每个城市都有员工是一项重要功能，那么您对城市实体的痛苦就会减轻，如果不保持原样
非常感谢，我从没想过一个表的规范化会在这个表加入时对性能有帮助！
@Vlakarados，关于employees_meta，我认为这是由employees 表完成的。如果你的意思是像以 object_id、object_attribute 和 value 作为字段的通用数据模型，那么查询数据的性能会降低。

【解决方案3】：

规范化处理实体。代表模型中实体的所有内容都应该分开（规范化）。

如果您有一个包含人员（名字、姓氏等）的表，并且所有这些人员也是具有登录用户名和密码的用户，那么您不需要规范化。

但是，如果只有某些人是用户，则您应该规范化为 2 个表（人员，将 person_id 用作人员实体链接的用户），并且如果您需要将人员和用户实体存储在几个不同的地方（人员之间的关系，用创建和最后修改的用户标记一条记录）然后你最好规范化。

因此，正如 CatCall 所说，规范化不会更改带有 id 的名称。那只是创建查找。

【讨论】：

【解决方案4】：

如果您有关于某个位置以及城市的其他信息，例如（城市、州、邮政编码），那么只需将邮政编码与员工数据一起存储即可。有一个名为“美国位置索引”的单独表或任何包含邮政编码作为主键、城市和州的表。您可以存储状态名称的 2 种变体，全称和缩写。基本上重点是城市和州很容易通过邮政编码确定......你可以这样想...... 美国的每个州都有很多城市，每个城市都有很多邮政编码，但每个邮政编码都标识了一个特定的城市和州的组合。例如，在 NYC，邮政编码 10010 将标识为 new York, NY，而 10001 将标识为 new York, NY。但 11222 将标识为纽约布鲁克林。希望这会有所帮助。

【讨论】：