数据库规范化技巧

　　摘要：本文为开发人员提供了一些技巧，使用这些技巧可以在设计 Access 表时避免某些问题。本文适用于 Microsoft Access 数据库 (.mdb) 和 Microsoft Access 项目 (.adp)。

　　简介

　　在设计数据库时，最重要的步骤是要确保数据正确分布到数据库的表中。使用正确的数据结构，可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称是“数据库规范化”。
　　本文简要介绍数据库规范化的基本概念和一些需要注意并力求避免的常见问题。

　　理解您的数据

　　在设计表之前，应明确您打算如何处理数据，还要了解随着时间的推移数据会发生什么样的变化。您所做的假设将会影响最终的设计。

　　您需要什么样的数据？

　　设计应用程序时，关键要了解设计的最终结果，以便确保您准备好所有必需的数据并知道其来源。例如，报表的外观、每个数据的来源以及所需的所有数据是否都存在。对项目损失最大的莫过于在项目后期发现重要报表缺少数据。

　　知道需要什么样的数据后，就必须确定数据的来源。数据是否从其他数据源中导入？数据是否需要清理或验证？用户是否需要输入数据？

　　明确所需数据的类型和来源是数据库设计的第一步。

　　您打算如何处理这些数据？

　　用户是否需要编辑这些数据？如果需要，应如何显示数据以便于用户理解和编辑？有没有验证规则和相关的查找表？要求对编辑和删除保留备份的数据输入有没有相关联的审核问题？需要为用户显示哪些摘要信息？是否需要生成导出文件？了解这些信息后，就可以想象字段之间是如何相互关联的了。

　　数据之间如何相互关联？

　　将数据分组放入相关字段（例如与客户相关的信息、与发票相关的信息等），每个字段组都代表要建立的表。然后考虑如何将这些表相互关联。例如，哪些表具有一对多关系（例如，一个客户可能持有多张发票）？哪些表具有一对一关系（这种情况下，通常会考虑将其组合到一个表中）？

　　随着时间的推移数据会发生什么样的变化？

　　设计表之后，常常会由于没有考虑时间的影响而导致以后出现严重问题。许多表设计在当时使用时效果非常好，但是，常常会因为用户修改数据、添加数据以及随时间的推移而崩溃。开发人员经常会发现需要重新设计表的结构来适应这些变化。表的结构发生变化时，所有相关的内容（查询、窗体、报表、代码等）也必须随之更新。理解并预测数据会随时间推移发生哪些变化，可以实现更好的设计，减少问题的发生。

　　学习如何使用查询

　　了解如何分析和管理数据同样很重要。您应该深刻理解查询的工作原理，理解如何使用查询在多个表之间链接数据，如何使用查询对数据进行分组和汇总，以及如何在不需要以规范化格式显示数据时使用交叉表查询。

　　好的数据设计的最终目标就是要平衡两个需要：既要随着时间的推移有效地存储数据，又要轻松地检索和分析数据。理解查询的功能对正确设计表很有帮助。

　　数据库规范化概念

　　这部分介绍数据库规范化所涉及的基本概念，而不是对数据库规范化进行理论性的探讨。如何在您的实际情况中应用这些概念可能会随着应用程序需要的不同而有所变化。这部分的目的是理解这些基本概念、根据实际需要应用它们，并理解偏离这些概念将会出现哪些问题。

　　将唯一信息存储在一个地方

　　大部分数据库开发人员都理解数据库规范化的基本概念。理想情况下，您希望将相同的数据存储在同一个地方，并在需要引用时使用 ID 来进行引用。因此，如果某些信息发生了变化，则可以在一个地方进行更改，而整个程序中的相应信息也会随之更改。

　　例如，客户表会存储每个客户的记录，包括姓名、地址、电话号码、电子邮件地址以及其他特征信息。客户表中可能包含唯一的 CustomerID 字段（通常是 Autonumber 字段），这个字段即该表的主键字段，其他表使用它来引用该客户。因此，发票表可以只引用客户的 ID 值，而不是在每张发票中存储客户的所有信息（因为同一个客户可能会持有多张发票），这样利用客户的 ID 值即可从客户表中查找客户的详细信息。使用 Access 中功能强大的窗体（使用组合框和子窗体），可以轻松地完成这项工作。如果需要修改客户信息（例如新增电话号码），只需在客户表中修改，应用程序中引用该信息的任何其他部分都会随之自动更新。

　　使用正确规范化的数据库，通过简单的编辑即可轻松处理数据随时间推移而发生的更改。使用未正确规范化的数据库，通常需要利用编程或查询来更改多条记录或多个表。这不仅会增加工作量，还会增加由于未正确执行代码或查询而导致数据不一致的可能性。

　　记录是免费的，而新字段非常昂贵

　　理想的数据库应该只需要随着时间的推移添加新的记录，数据库表应该能够保存大量记录。但是，如果您发现需要增加更多字段，则可能会碰到设计问题。

　　电子表格专家经常会遇到上述问题，因为他们习惯于按照设计电子表格的方式设计数据库。设计经常随时间变化的字段（例如，年、季度、产品和销售人员）需要在将来添加新字段。而正确的设计应该是转换信息并将随时间变化的数据放在一个字段内，这样就可以添加更多记录。例如，只需创建“年”字段，然后在该字段中输入各记录相应的年份值即可，无需为每年创建一个单独的字段。

　　增加额外的字段可能会产生问题，因为表结构的变化会对应用程序的其他部分产生影响。在表中添加更多字段时，依赖该表的对象和代码也需要更新。例如，查询需要获取额外的字段，窗体需要显示这些字段，而报表则需要包含这些字段，等等。但是，如果数据已经规范化，则现有对象会自动检索新数据，并正确计算或显示这些数据。查询功能尤其强大，因为它允许您按“年”字段进行分组，以逐年显示摘要（不管表中包含哪些年份）。

　　但是，数据规范化并不意味着不能显示或使用随时间而变化或依赖时间的字段。需要浏览或显示这类信息的开发人员通常可以使用交叉表查询来达到这一目的。如果您不熟悉交叉表查询，应该学习如何使用它们。虽然它们与表有所不同（尤其是用户无法编辑交叉表查询的结果），但它们的确可以用于在数据表中显示信息（最多可以达到 255 个字段）。如果要在报表中使用它们，则会更加复杂，因为报表需要包含额外的或不断变化的字段名。这就是为什么大多数报表将数据作为独立的分组（而不是独立的列）显示的原因。对于那些别无选择的情况，您必须花时间去解决这个问题。希望所有人都能够理解这种决定会随着时间的变化对其他资源产生的影响。

　　这就是为什么增加记录是免费的（这是数据库的巨大优势）而增加字段是如此昂贵的原因。如果数据库设计正确，则可以适应各种各样的变化。

　　了解何时需要复制数据

　　有时数据需要反规范化，以便保存可能会随时间变化的信息。

　　在通过客户 ID 号将发票链接到客户表的简单示例中，我们可能需要保留开出发票时的客户地址（而不是制作发票时的地址，因为客户信息在这两个事件之间可能会有所变化）。如果开出发票时未保留客户地址，而将来又必须更新客户信息，则可能无法确定发送某些发票的确切地址。这可能会导致非常严重的商业问题。当然，有些信息（如客户的电话号码）可以不保存。因此，应该有选择地决定需要复制哪些数据。

　　需要复制数据的另一个例子是填写发票的明细项。报价单通常用于挑选客户订购的商品。我们可以只存储报价单 ID，而 ID 指向包含产品说明、价格和其他详细信息的报价单。但是，产品说明和价格会随着时间而改变。如果不将数据从报价单复制到明细表中，将来则无法准确地重新打印原始发票。如果您尚未收到付款，问题将非常严重。

　　因此，虽然规范化可以将相同的数据很好地保存在一个地方并能简化编辑工作，但某些情况下却不需要这些优势。如果以后由于历史原因需要数据的快照，则必须从一开始就在数据库中设计好。否则，一旦数据被覆盖就无法再找回。

　　使用没有确切含义的字段作为主键字段

　　为了提高效率，每个表都应该有一个主键字段。主键字段定义了在表中的唯一性，并由索引在其他字段中使用，以提高搜索性能。例如，客户表可以包含为每个客户定义唯一编号的 CustomerID 字段。为了便于讨论，假定表中包含多个字段，而不仅仅是简单的单一表查找（例如国家/地区列表）。

　　一般来说，主键字段应具有如下特征：
　　
　　应该只包含一个字段

　　可以将多个字段定义为表的主键字段，但最好是使用一个字段。首先，如果需要使用多个字段来定义唯一性，则需要占用更多的空间来存储主键。其次，表中的其他索引还必须使用主键字段的组合，这样所占用的空间比使用一个字段所占用的空间要多。最后，在表中标识记录需要获取字段组合。使用一个 CustomerID 字段定义客户比使用其他字段组合要好得多。

　　应该为数字类型

　　Access 提供的 AutoNumber 字段类型是一个 Long Integer（长整数），非常适用于主键字段。这些值可以自动保证每个记录的唯一性，同时也支持多用户数据输入。

　　不会随时间而改变

　　主键字段不应该随时间而改变。一旦标识了主键字段，就应该永远不变（象社会保障号一样）。更改过的主键字段将很难再使用历史数据，因为其中的链接被破坏了。

　　应该没有确切含义

　　要确保主键字段不会随时间而更改，它应该没有确切含义。没有确切含义的主键值在其他数据不完整时也非常有用。例如，您可以指定一个客户编号，而无需该客户的完整地址。应用程序的其余部分可以很好地工作，您也可以在检索记录时添加信息。如果表中使用了国家/地区字段或其他您没有的标识字段作为主键的一部分，则很可能会导致无法使用应用程序。

　　鉴于上述原因，我们建议在大部分表中使用 AutoNumber 字段作为主键字段。通过使用组合框和隐藏列，可以将字段绑定到 AutoNumber 字段并将其隐藏，使用户无法看到。