避免空白：

Question

我理解数据库规范化的概念，但总是很难用简单的英语解释它 - 特别是对于求职面试。我已经阅读了wikipedia帖子，但仍然觉得很难向非开发人员解释这个概念。 “以不会获得重复数据的方式设计数据库”是首先想到的。

有没有人用简单的英语解释数据库规范化的概念？有什么好的例子可以显示第一，第二和第三范式之间的差异？

假设您去求职面试并且该人员要求：解释规范化的概念以及如何设计规范化数据库。

面试官在寻找什么关键点？

Answer 1

好吧，如果我必须向我的妻子解释它，那就是这样的：

主要思想是避免重复大数据。

让我们来看看他们来自的人员和国家名单。我们只是拿着一个引用国家表格的数字，而不是保留每个人的名字，只要“波斯尼亚和黑塞哥维那”。所以我们不是拿着100“波斯尼亚和黑塞哥维那”，而是拿着100＃45。现在将来，巴尔干国家经常发生这种情况，它们分裂为两个国家：波斯尼亚和黑塞哥维那，我将不得不在一个地方改变它。好吧，等等。

现在，为了解释2NF，我会改变这个例子，让我们假设我们保留每个人访问过的国家列表。而不是像下面这样的表：

Person   CountryVisited   AnotherInformation   D.O.B.
Faruz    USA              Blah Blah            1/1/2000
Faruz    Canada           Blah Blah            1/1/2000

我会创建三个表，一个表包含国家/地区列表，一个表包含人员列表，另一个表连接它们。这给了我最大的自由，我可以获得改变人的信息或国家信息。这使我能够按照规范化期望“删除重复的行”。

Answer 2

这就是我问受访者：

为什么我们不为应用程序使用单个表而不是使用多个表？

答案是当然正常化。如前所述，它避免了冗余，并且存在更新异常。

Answer 3

这不是一个彻底的解释，但正常化的一个目标是允许增长而不尴尬。

例如，如果您有一个user表，并且每个用户只有一个且只有一个电话号码，那么该表中的phonenumber列就可以了。

但是，如果每个用户的电话号码都是可变的，那么拥有phonenumber1，phonenumber2等列会很尴尬。这有两个原因：

如果您的列上升到phonenumber3而有人需要添加第四个数字，则必须在表格中添加一列。
对于电话号码少于3个的所有用户，其行上都有空列。

相反，您需要一个phonenumber表，其中每一行都包含一个电话号码和一个外键引用，该引用属于它所属的user表中的哪一行。不需要空白列，每个用户可以根据需要使用少量或多个电话号码。

Answer 4

关于规范化的一个注意事项：完全规范化的数据库 space 有效，但不一定是最有效的 time 数据排列，具体取决于使用模式。

跳过多个表，从非规范化位置查找所有信息需要时间。在高负载情况下（每秒数百万行，数千个并发客户端，比如信用卡事务处理），时间比存储空间更有价值，适当的非规范化表可以提供比完全规范化表更好的响应时间。

有关此问题的更多信息，请查找Ken Henderson撰写的SQL书籍。

Answer 5

我会说规范化就像保持笔记有效地做事情，可以这么说：

如果你有一张说你必须的便条   没有购买冰淇淋   正常化，你会有   另一个说明，说你必须去   购买冰淇淋，只有一个   每个口袋。

现在，在现实生活中，你永远不会这样做   这个，为什么要在数据库中呢？

对于设计和实现部分，那就是当你可以回到“语言”并远离外行术语时，但我认为你可以简化。你会先说出你需要的东西，然后当归一化时，你会说你会确定以下内容：

表格中不得有重复的信息组
任何表都不应包含在功能上不依赖于该表主键的数据
对于3NF，我喜欢Bill Kent的观点：每个非关键属性都必须提供关于密钥，整个密钥以及密钥的事实。

我认为如果你谈论非规范化，以及你不能总是拥有最好的结构并且处于正常形式的事实，那可能会更令人印象深刻。

Answer 6

规范化是一组规则，用于设计通过关系连接的表。

它有助于避免重复输入，减少所需的存储空间，无需重新构建现有表以适应新数据，从而提高查询速度。

第一范式：数据应以最小单位分解。表不应包含重复的列组。每行用一个或多个主键标识。例如，“自定义”表中有一个名为“名称”的列，它应该分为“名字”和“姓氏”。此外，“自定义”应该有一个名为“CustiomID”的列来标识特定的自定义。

第二范式：每个非关键列应与整个主键直接相关。例如，如果“自定义”表格中有一个名为“城市”的列，则该城市应该有一个单独的表格，其中定义了主键和城市名称，在“自定义”表格中，将“城市”列替换为“城市ID”，让'CityID'成为故事中的外键。

第三范式：每个非键列不应该依赖于其他非键列。例如，在订单表中，“总计”列取决于“单价”和“数量”，因此应删除“总计”列。

Answer 7

我在Access课程中教授规范化并将其分解为几种方式。

在讨论了故事板的前兆或计划出数据库之后，我接着进行了规范化研究。我解释这样的规则：

每个字段应包含最小的有意义值：

我在电路板上写了一个名字字段，然后在其中加上名字和姓氏，比如Bill Lumbergh。然后，当名字和姓氏都在一个字段中时，我们会询问学生并询问他们会遇到什么问题。我以我的名字为例，就是吉姆·理查兹。如果学生不带我上路，那我就拉着他的手拿走他们。 :)我告诉他们我的名字对某些人来说是一个艰难的名字，因为我有些人会考虑2个名字，有些人称我为理查德。如果你试图搜索我的姓氏，那么对于一个普通人来说（没有通配符）会更难，因为我的姓氏被埋在了字段的末尾。我还告诉他们，他们在使用姓氏轻松排序字段时会遇到问题，因为我的姓氏最后都被埋没了。

然后，我让他们知道有意义的是基于将要使用数据库的观众。如果我们存储人员的地址，我们在工作中不需要单独的公寓或套房区域，但UPS或FEDEX等运输公司可能需要将其分开以便轻松拉出他们需要去的地方的公寓或套房。他们在路上，从交货到交货。所以它对我们没有意义，但对他们来说绝对有意义。

避免空白：

我用一个类比向他们解释为什么他们应该避免空白。我告诉他们Access和大多数数据库都不像Excel那样存储空白。 Excel不关心您是否在单元格中没有输入任何内容并且不会增加文件大小，但Access将保留该空间，直到您实际使用该字段为止。因此，即使它是空白的，它仍将占用空间并向他们解释它也会减慢搜索速度。
我使用的类比是衣柜里的空鞋盒。如果您在衣柜里有鞋盒，并且您正在寻找一双鞋子，那么您需要打开并在每个盒子中查看一双鞋子。如果有空的鞋盒，那么你只是在衣柜里浪费空间，而且当你需要透过这些鞋子时也会浪费时间。

避免数据冗余：

我向他们展示了一张表，其中包含许多重复的客户信息值，然后告诉他们我们想要避免重复，因为我有香肠的手指，如果我不得不反复输入同样的东西，会输入错误值再次。这种“胖指法”的数据会导致我的查询找不到正确的数据。相反，我们会将数据分解为单独的表，并使用主键和外键字段创建关系。这样我们就节省了空间，因为我们没有多次输入客户的姓名，地址等，而只是在客户的字段中使用客户的ID号。然后，我们将讨论下拉列表/组合框/查找列表或以后微软想要命名的其他内容。 :)作为用户，您不希望每次在该客户字段中查找并键入客户编号，因此我们将设置一个下拉列表，该列表将为您提供客户列表，您可以在其中选择他们的姓名和它会为您填写客户的ID。这将是1对多的关系，而1个客户将有许多不同的订单。

避免重复的字段组：

我在谈论多对多关系时证明了这一点。首先，我绘制了2个表，1个将保存员工信息，1个将保存项目信息。这些表格与此类似。

(Table1)
tblEmployees
* EmployeeID
First
Last
(Other Fields)….
Project1
Project2
Project3
Etc.
**********************************
(Table2)
tblProjects
* ProjectNum
ProjectName
StartDate
EndDate
…..

我向他们解释说，这不是建立员工与他们所从事的所有项目之间关系的好方法。首先，如果我们有一个新员工，那么他们将没有任何项目，所以我们将浪费所有这些领域，其次，如果一个员工已经在这里很长一段时间，那么他们可能已经完成了300个项目，所以我们会有包括300个项目字段。那些新的，只有1个项目的人将有299个浪费的项目领域。这种设计也有缺陷，因为我必须在每个项目字段中搜索以找到所有在某个项目上工作的人，因为该项目编号可以在任何项目字段中。

我涵盖了相当多的基本概念。如果您有其他问题或需要帮助澄清/用简单的英语分解，请告诉我。维基页面不是简单的英文版本，对某些人来说可能是令人生畏的。

Answer 8

我已多次阅读关于规范化的wiki链接，但我已经从article找到了更好的规范化概述。这是一个简单易懂的解释，归一化到第四范式。给它读一读！

预览：

什么是规范化？

规范化是一个过程有效地组织数据数据库。这有两个目标规范化过程：消除冗余数据（例如，存储多个表中的相同数据）并确保数据依赖性感觉（仅存储相关数据）表）。这两个都是值得的目标因为它们减少了空间量a 数据库消耗并确保数据逻辑上存储。

http://databases.about.com/od/specificproducts/a/normalization.htm

Answer 9

数据库规范化是设计数据库以消除冗余数据的正式过程。设计包括：

规划数据库将存储的信息
概述用户将从中请求的信息
记录审核假设

使用data-dictionary或其他元数据表示来验证设计。

规范化的最大问题是最终会有多个表来表示概念上的单个项目，例如用户配置文件。不要担心将表格中的数据标准化，这些数据会插入记录但不会更新，例如历史记录日志或财务事务。

<强>参考

Answer 10

+1与你妻子交谈的类比。我觉得与没有技术头脑的人交谈需要一些轻松的谈话。

但是...

要添加到此对话中，硬币的另一面（在面试中可能很重要）。

规范化时，您必须观察数据库的索引方式以及查询的编写方式。

在一个真正规范化的数据库中，我发现在某些情况下编写由于错误的连接操作，表上的索引错误以及表本身的简单错误设计而导致的查询更容易。

直言不讳地说，在高级规范化表格中编写错误查询会更容易。

我认为每个应用程序都有一个中间立场。在某些时候，您希望能够轻松地将所有内容排除在几个表之外，而无需加入大量表来获取一个数据集。

用简单的英语标准化

11 个答案:

每个字段应包含最小的有意义值：

避免空白：

避免数据冗余：

避免重复的字段组：