一个人怎么知道什么时候停止正常化？

Question

好吧，基本上我觉得我倾向于过度正常化，也许我这样做是以性能为代价的。因此，为了说明这个问题，我创建了以下模式作为示例：

如你所见，我已经概述了两种不同的方法。这里的想法是，所有的大学都有课程(例如，工程)，所有的课程都有专业(例如，电气工程)。要使这个例子奏效，我们必须假设有40个项目，比如1000个专业，学校有相同的课程/专业。

现在，我在这个场景中的典型方法是，获取任何可能重复的内容(例如，专业和程序)，并将这些项放入他们自己的表中；然后建立一个关系，就像上面建模的那样。另一种方法，我倾向于回避，是第二种模式，在这种模式中，程序和专业是具有重复值的列(例如，工程可能在表上重复1,000次)。基本上，如果这个值被重复，我会为它创建一个表。

现在，我对其中哪一种方法不太感兴趣，因为我只是把它们作为一个例子来说明真正的问题:人们如何知道它们何时过度正常化？我知道，当你过于规范化你的表格的时候，有一点是有意义的，但是我从来不知道测量是什么。

增编

一所大学不必把所有的专业都纳入一个项目，因此，大学之所以与专业挂钩，而不是与专业挂钩(例如，X大学有一所工程学院，但没有核工程学院，这是工程项目的一部分)。

Answer 1

在设计数据库时，规范化是在生成逻辑模型(即关系数据模型)时所进行的过程。性能是物理模型的一个属性；在特定的DataBase管理系统上实现逻辑模型。

您不能“过度规范化”关系数据模型。关系数据模型要么是第五范式，要么是较低的范式，并且存在更新异常。

规范化过程是一个定义良好的过程，用于分析模型中关系的函数依赖、多值依赖和连接依赖，并对这些关系进行投影以消除候选键不隐含的依赖。

假设您有一个第五种范式的关系数据模型，它已经在特定的DBMS上实现了。在某种程度上，这种实现的性能已变得不可接受。您决定如何解决这个问题将取决于正在使用的DBMS和DBMS提供的特性。

在查看了正在使用的DBMS的可用功能之后，您可能会决定在DBMS中使用一些表，并重新对它们进行因子分析，以便使它们处于较低的正常形式。(注意:逻辑模型没有更改，您已经更改了物理模型以解决实现中的性能问题。)通过重新分解这些表，您已经引入了更新异常的可能性，并且，由于您的关系数据模型是第五种范式，所以您可以精确地确定这些异常可能发生的位置。确定了它们之后，您可以选择忽略它们，或者添加一些额外的处理来识别和/或寻址它们。(注意:通过添加额外的处理，您可能会影响性能，从而使这些表所认为的“去或错误化”的好处实际上被否定。)在任何情况下，你都可以对你可能采取的任何行动进行知情的分析。

Answer 2

我认为这里的答案至少与“我们应该为达到这一目标而努力实现某一特定理想的距离”的答案非常接近，如果不是相同的话？在开发生命周期的不同步骤中，不同的学科(在软件开发中:应用程序设计、数据库设计/编程、UI、QA等等)有着不同的理想。所有项目都必须采用n层方法吗？在数据库中放置应用程序逻辑可以原谅吗？甚至可以建议使用光标(我悄悄地说过，这样就不会有人听到它了;-)？问题归结为：

1. 当前任务的状态是否为项目留下了一些可以工作和可以维护的东西？或者说，它是最起码的，使它看起来好像事情正在进行？

以及：

1. 向理想靠拢所需的额外时间/努力的好处是什么？

如果当前状态几乎不能正常工作和/或很难维护，那么第二个问题就更容易回答了:向理想靠拢的好处是一个系统可以工作(将来浪费更少的时间，经常回来修复事情)，并且是可维护的(如果您需要修复某个东西或更改需求，并且需要新的功能，那么将来就会有更少的浪费)。

然而，回答这些问题的主要困难在于它需要经验。它需要在几个项目上工作过，尝试过不同的解决问题的方法，并且看看在哪些情况下有效，而在其他情况下没有效果，或者可能根本就不是一个可行的想法。

给出了两个示例模型，一个具有重复字段(即标准化程度较低)的模型是功能性的，但随着时间的推移，它将更难维护，也更难适应新需求所需要的变化。我从经验中了解到这一点，因为我不得不在采取这种方法的系统中工作。它不仅造成了问题，而且更难调试(随着时间的推移，人们手动输入这些字符串值会产生比任何选择在设计时沿着这条道路走的人想象的更少的一致/可预测的数据)，而且它还会大大降低查询的速度，因为在text字段上的筛选不如对integer字段的筛选那么快。

但是经验也需要知道你是否走得太远了。或者走到适当的距离，但方向有点不合适。例如，以所示的第一个模型为例。有两个建模错误：

1. "university_major“表不应该包含"program_id”。“程序”应与“主要”相关，并可通过其与“专业”的关系从"university_major“推断。
2. "university_major“表不应该有"university_major_id”字段。它是一个冗余键，由于它是一个代理项，自动递增值，所以没有添加任何值.有一个自然的键可以是PK："university_id"，"major_id“。"university_major_id“的任意性质将允许"university_id”和"major_id“的多个实例，除非为这两个字段添加额外的唯一索引或约束。

再一次，主要是经验让我想到了这些想法。我还意识到，在某些情况下，系统需要一个单独的自动递增值(我相信SQL Server中的复制需要在所有复制的表上进行复制)，因此您需要为PK添加一个标识字段，并添加唯一的索引并继续使用;-)。

因此，我要说的是，没有任何实际的、可衡量的方法来知道何时停止正常化。这主要取决于经验。我还要补充说，与其他人的合作(利用他们的经验)和评估目前的项目(分配的时间和资源、目标受众等)发挥了作用。但我也认为，某人愿意和/或有能力认识/重视/利用这些其他因素，至少在一定程度上与他们的经验水平成正比。