数据标准化

数据库设计人员的任务是以这样一种方式构造数据，采用该方式可消除不必要的重复并提供到所有必要信息的快速搜索路径。精炼表、键、列和关系以创建高效数据库的过程称为“标准化”。标准化并不只适用于关系文件：它还是索引文件的常见设计活动。

标准化是个复杂过程，具有许多特定规则和不同强度等级。就其完整定义而言，标准化是放弃重复组、最小化冗余、消除部分依赖项的复合键以及分隔非键属性的过程。简言之，标准化规则可以总结为一句话：“每个属性（列）必须是有关键、整个键且仅键的一个事实。”每个表应只描述一种实体类型（如人、地点、客户订单或产品项）。

标准化的一些好处是：

·         数据完整性（因为没有冗余、被忽视的数据）。

·         优化的查询（因为标准化的表生成快速、有效的联接）。

·         更快的索引创建和排序（因为表中列较少）。

·         更快的 UPDATE 性能（因为每个表的索引更少）。

·         改善的并发解析（因为表锁影响的数据少了）。

可以通过遵守以下简单经验法则来标准化大多数简单数据库：包含重复信息的表应划分为单独的表以消除重复。

例如，您的新应用程序是供某书商使用的，他必须跟踪每本书的相关信息，包括下列数据。

·         作者姓名。

·         作者地址。

·         作者电话。

·         书名。

·         ISBN（国际标准书号）。

·         出版年代。

·         出版商名称。

·         出版商地址。

·         出版商电话。

可以只创建一个表，对于所列出的每个数据项均有一个字段。但仔细查看这些数据，很明显这样的表包含很多冗余。例如，许多作者写了不止一本书，因此对于每个书名，作者和出版商信息将重复很多次。如果将所有这些字段均放入一个表，将会有许多容易引起混乱和重复的项。

使用标准化的原则，您可将数据划分为四个组：“作者”(Authors)、“作者书名”(AuthorsTitles)、“书名”(Titles) 和“出版商”(Publishers)，如下表所示。

键提供一种建立表关系的方法。例如，AuthorsTitles 表创建 Authors 和 Titles 表之间的多对多关系（一个作者可能写很多书，而一本书可能由多个作者撰写）。使用 AuthorsTitles 表，您可以查询一个作者写的每个书号（使用 au_id），还可以确定哪个（哪些）作者写了某本书（使用 ti_isbn）。

值得注意的是，不用创建 AuthorsTitles 表，另一种可能的方法是向 Titles 表添加 au_id 属性，但该选项仅当假定每本书只有一个作者时才可行。进一步考虑另一个假设：将 pu_id 属性放入 Titles 表假设每本书由一个出版商出版。如果同一本书由多个公司出版，那么为每个单独的出版商向 Titles 表插入附加的 Title 行将使数据重复，导致该表不是标准化的表。此类设计备选项要求仔细评估这些内容：业务数据的含义，应用程序预期的查询类型，可能的多用户并发问题，以及一个表上有很多索引而可能产生的性能问题。

评估标准化设计备选项时，需要了解还有各种技术可以用来特意使数据库非标准化。为什么要这样做呢？您会因为发现性能问题或希望简化特殊报告而特意使数据非标准化。性能问题源自这样一类生产查询，这些查询需要太多耗时且大量使用磁盘的表联接。特殊报告是关于允许最终用户执行非结构化查询；未经训练的最终用户可能不清楚如何从多个相关表获取信息。

非标准化技术包括复制数据，提供摘要数据，将表拆分为水平或垂直分区以及创建非标准化视图来简化报告（这是一种聪明的选择，可原封不动地保留标准化的数据库）。

作为非标准化的一个示例，请考虑客户地址的情况。客户表通常会包含以下属性：姓名、街道、城市、省/州和邮政编码。虽然城市和省/州可以直接从邮政编码确定，因而可以通过从每个客户的数据中移除城市和省/州来标准化客户表，但通常的做法是保留地址非标准化。

使地址非标准化的原因有以下几个：

·         地址用在很多地方（查询、报表、信封、客户支持屏幕），非标准化可避免应用程序中到处添加大量的地址重建代码。

·         基于地址的查询使用的 SQL 语法简单得多。

·         地址错误限制到单个客户。