如何知道何时停止正常化？
Fra*_*fka 0 normalization database-design
好吧，基本上我觉得我倾向于过度规范化事情，也许我这样做是以牺牲性能为代价的。因此，为了阐明这个问题，我创建了以下模式作为示例：
如您所见，我概述了两种不同的方法。这里的想法是所有大学都有课程（例如工程），并且所有课程都有专业（例如电气工程）。为了让这个例子起作用，我们必须假设有 40 个项目，比如 1000 个专业，并且学校有相同的项目/专业。
现在，我在这种情况下的典型做法是将任何可能重复的内容（即专业和课程）放入自己的表中；然后有一个关系，如上所示。另一种我倾向于远离的方法是第二种模型，其中 program 和 major 是具有重复值的列（例如，Engineering 可能会在表格中重复 1,00 次）。基本上，如果值重复，我会为它创建一个表。
现在，我对其中哪一种更好的方法不太感兴趣，因为我只是用它们作为一个例子来阐明真正的问题：人们如何知道它们何时过度规范化？我知道您在规范化表格方面做得太过分了，但我从来不知道衡量标准是什么。
附录
大学不需要在一个项目中拥有所有专业，因此大学与专业相关，而不是项目（例如，大学 X 有工程学院，但没有核工程，这是工程项目的一部分）。
在设计数据库时，规范化是在生成逻辑模型（即关系数据模型）时进行的过程。性能是物理模型的一个属性；逻辑模型在特定数据库管理系统上的实现。
您不能“过度规范化”关系数据模型。关系数据模型要么处于第五范式，要么处于较低范式并且存在更新异常。
归一化过程是一个明确定义的过程，用于分析模型内关系的函数、多值和连接依赖关系，并采用这些关系的投影来消除候选键未隐含的任何依赖关系。
假设您有一个在特定 DBMS 上实现的第五范式的关系数据模型。在某些时候，这种实现的性能变得不可接受。您决定如何解决此问题将取决于正在使用的 DBMS 以及 DBMS 提供的功能。
在查看了可用于正在使用的 DBMS 的功能后，您可能决定采用 DBMS 中的一些表并重新分解它们，使它们处于较低的正常形式。（注意：逻辑模型没有改变，你已经改变了物理模型来解决实现的性能问题。）通过重构这些表，你引入了更新异常的可能性，因为你的关系数据模型排在第五正常形式，您可以准确确定这些可能发生的位置。确定这些后，您可以选择忽略它们，或添加一些额外的处理来识别它们和/或解决它们。（注意：通过添加额外的处理，您可能会影响性能，以至于“非规范化”这些表的感知好处实际上被否定了。） 在任何情况下，您都可以对您可能采取的任何行动进行明智的分析。