SQLserver5基础教程

1、q 数据库是什么？数据库由什么构成？它存储在何处？q 如何定义系统的类型，是关系的还是分析的？q 如何收集当前系统的数据并找出新系统的信息。q 如何通过SSMS、向导或查询编辑器窗口创建数据库，如何在查询编辑器窗口设置数据库选项。q 如何查看数据库的细节。q 如何用SSMS和查询编辑器窗口移除数据库。 注解 在本章的练习中，将不会使用任何明确的、正式的设计技术，毕竟本书并非是专门讲述数据库设计的图书。然而，到达数据库最终设计的过程（物理的和逻辑的）将是相同的。3.1 数据库的定义数据库（database）是对象的容器，它不仅可以存储数据，而且能够使数据存储和检索以安全而可靠的方式进行。SQL

2、Server 2005数据库能够包含如下对象（尽管当数据库刚创建时，这些信息中的一部分尚未创建）：q 表定义。q 表中的列，组成数据行。q 程序（存储过程或程序集），用于访问或操作数据。q 索引，用于加速数据检索。q 视图，查看真实数据的一种特殊的方式。q 函数，可以应用到数据行的重复性任务。上述列表中包含了不少专门术语，因此，下面将花些时间来讲述它们的定义：q 表：表用于存储数据库中的数据。尽管可以使数据库只包含系统表而没有用户表，但数据库至少应该有一个有用的表。系统表是一种特殊的表，SQL Server用系统表来帮助其进行与数据库有关的工作。表包含位于行和列之中的信息，这很像在Excel中

3、那样，但其能力远比Excel中的单元格强大。临时表是另一种类型的数据库表，可以有几种不同的形式。q 列：列提供每一个单独的信息项的定义，由列定义构成表定义。列很像Excel中的列，由存放数据的单元格组成。与Excel中的列不同的是，在Excel中，列的每个单元格可以存放不同类型的数据，而对于SQL Server表中的列，可以存放的数据取决于准备让它存放的数据类型以及数量。每个表至少要有一个列，虽然该列不必包含任何信息。q 行：行由单元格组成，每个单元格来自为表定义的每一个列。表可以有任意数目的行，行的数目只受限于磁盘空间，或者说受限于在数据库创建定义中指定的最大磁盘空间，或服务器上的磁盘空间。

4、每一行描述了一条单独的信息，如用户的银行账户详情或电子商务站点的产品信息。行也称为记录。q 存储过程：当需要一个程序来操作数据或进行与数据有关的工作，或者需要重复地执行相同的数据密集型任务时，把代码存储到存储过程中常常是较理想的选择。存储过程包含一条或多条T-SQL语句，这些语句已经编译并随时可以在需要时执行。存储过程永久存储在数据库中，随时可供使用。q T-SQL语句：SQL Server在进行数据方面的工作时，可以使用的程序语句。q 程序集：程序集是SQL Server 2005中新增内容。它与存储过程类似，可用于操作数据或进行与数据有关的工作，不同的是，使用程序集，更多地是为了程序逻辑（

5、正如在.NET程序中见到的那样）。程序集不仅可以是存储过程的替代物，还能有许多不同的外观，例如，能够使用程序集创建数据类型。q 索引：索引可以看成是预定义的信息列，它告知数据库数据是如何被物理排序和存储的，SQL Server使用索引（通过把T-SQL查询所提供的信息与列中的数据相匹配）来快速查找数据行。索引由一个或多个（在其上定义该索引的表的）列组成，但索引不能跨多个表来定义。SQL Server中的索引非常类似于书的索引，使用索引，能够比一页页地翻阅更快地找到资料。q 视图：可以把视图看作是虚拟表。视图能够包含组合自数个表的信息，它能给数据提供更为用户友好的界面。视图还能极大提高应用的安全

6、性，当然，它也确实削减了使用存储过程和直接访问表的功能。也可以为视图创建索引，从而加快视图中数据处理的速度。q 函数：函数与存储过程相似，只是在处理多行数据时，函数一次只取一行数据或者一次只生成一行数据。例如，若要创建账目，就使用存储过程产生输出；若要一次一个地细查每一笔交易，以计算出每天的利润，则使用函数。在所有数据库中都有一组系统表，SQL Server使用这些系统表来维护数据库。系统表中存储了所有列的信息、所有用户的信息以及许多其他信息（即元数据）。不同于以往版本的SQL Server，在SQL Server 2005中，系统表的安全性有了改进和增强，系统表不再能直接访问，而只能通过视图

7、访问。由于系统表中的数据不能修改，并且系统表提供的信息只在使用高级功能时才有用，因此，没有必要在这里研究系统表。3.2 SQL Server中的数据库当首次安装完SQL Server后，已经有几个数据库安装并显示出来了。本节将一一讲述这些数据库，以便读者了解每一个数据库的功用，这样当在本书之外碰到这些数据库时就不致困扰。首先讲述SQL Server中最重要的数据库，即master数据库，然后讲述tempdb、model、msdb以及AdventureWorks/AdventureWorksDW数据库。3.2.1 master由于master数据库是SQL Server中最重要的数据库，因此在开

8、始讲述它前必须先做警告：任何对master数据库的直接改动行为，请自行负责！深入探究该数据库中的任何系统视图，或者直接修改该数据库的记录信息或列信息都是不明智的。可以通过系统函数以有条不紊的方式对这些数据进行建设性的修改，这是唯一应该用来修改master数据库的方法。master数据库位于SQL Server的核心，如果该数据库被损坏，SQL Server将无法正常工作。master数据库中包含如下重要信息：q 所有的登录名或用户ID所属的角色。q 所有的系统配置设置（例如，数据排序信息、安全实现、默认语言）。q 服务器中的数据库的名称及相关信息。q 数据库的位置。q SQL Server如何

9、初始化。q 用于存储下列信息的特殊的系统表（下列信息并非详尽无遗）：n 如何使用缓存？n 哪些字符集可用？n 可用语言列表。n 系统错误和警告消息。n 程序集，一种特殊的SQL Server对象（所有数据库中的处理SQL Server对象的表不为master数据库所专有）。master数据库是SQL Server安全卫士，它使用上述信息来确保所有的事都在掌控之中。注解 定期备份master数据库非常重要。确保备份master数据库是备份策略的一部分。关于备份，将在第7章详细讲述。3.2.2 tempdbtempdb数据库，正如它的名字所暗示的那样，是一个临时性的数据库，它存在于SQL Serv

10、er会话期间，一旦SQL Server关闭，tempdb数据库将丢失。当SQL Server重新启动时，将重建全新的、空的tempdb数据库，以供使用。关于该过程，还有更多可讲述的内容，但是，在深入探讨这些之前，还是先来了解tempdb数据库的用途是什么。众所周知，数据库能够存储数据，而数据可以存储在多个表中，使用命令和函数来检索和操作这些数据。然而，有时可能想把某个数据集临时存储起来，以便稍后进行处理例如，当要把得自一个存储过程的数据传递给在该存储过程之后运行的另一个存储过程时，一个选择就是把那些数据存储在tempdb数据库中。在存储过程或查询中创建的所有临时表都将被放置在tempdb数据库

11、中。只要tempdb数据库没被更新，一切将称心如意；一旦重建了tempdb数据库，那么存放于其中的数据将丢失，需要重生成数据。或许，你会认为这并非一个理想的解决方案，毕竟，如果能把临时信息存储在该数据库之外的某处，不是很完美吗？其实，tempdb不是这样用的，关于tempdb，实际上只应把它看作是过渡的存储空间。重建tempdb的另一个原因是：不仅开发者要使用该数据库，SQL Server自己也要使用tempdb。实际上，SQL Server始终在使用tempdb，当重新初始化SQL Server时，它需要确认原先正在处理的任何临时性工作都已经清除掉。毕竟，很可能是由于临时性工作的问题导致服务

12、的重启。正像其他数据库一样，tempdb也有大小的限制，必须确保该数据库的大小对于当前的应用以及所有要存储于其中的临时信息是足够的。阅读随后的章节，将看到数据库的大小有最小值和最大值。tempdb也不例外，应该确保该数据库大小可以扩展，这样当需要时就可以增加其大小。注意 因为tempdb的大小是有限的，所以在使用它时必须当心，不要让tempdb被来自不好的存储过程（对于创建有太多记录的表没有明确限制）的表中的记录所填满。如果发生了这种情况，不仅当前的处理不能继续，整个服务器都可能无法工作，从而将影响到在该服务器上的所有用户。第一段中提过，关于tempdb的更新过程还有更多可讲述的内容，这将在下

13、一节中进行阐述。3.2.3 model创建数据库时（很快就要在本章的学习中创建数据库），总是以一套预定义的标准为模型。例如，若希望所有的数据库都有确定的初始大小，或者都有特定的信息集，那么可以把这些信息放在model数据库中，以model数据库作为其他数据库的模板数据库。如果想要使所有的数据库都有一个特定的表，可以把该表放在model数据库里。model数据库是tempdb数据库的基础。对model数据库的任何改动都将反映在tempdb数据库中，所以，在决定对model数据库有所改变时，必须预先考虑好并多加些小心。3.2.4 msdbmsdb给SQL Server代理提供必要的信息来运行作业，

14、因而，它是SQL Server中另一个十分重要的数据库。SQL Server代理是SQL Server中的一个Windows服务，用以运行任何已创建的计划作业（例如包含备份处理的作业）。作业是SQL Server中定义的自动运行的一系列操作，它不需要任何手工干预来启动。既然有了tempdb及model数据库，就不应该直接调整msdb数据库，也的确无此必要。许多进程使用msdb。例如，当创建备份或执行还原时，将用msdb来存储有关这些任务的信息。3.2.5 AdventureWorks/AdventureWorks DWAdventureWorks和AdventureWorksDW是SQL Se

15、rver中的示例数据库（如果在安装过程中选择了安装它们的话）。这些数据库基于一个自行车生产公司，以一种简单的、易于理解的方式来展示SQL Server 2005的新功能，如Reporting Services、CLR（公共语言运行时）特性以及许多其他特性。下一段文字摘录自微软的文档资料，简要地给读者提供了AdventureWords数据库相关背景的概览：Adventure Works Cycles是AdventureWorks示例数据库所基于的虚构的公司，该公司是一家大型跨国生产公司。公司生产金属和复合材料的自行车，产品销往北美、欧洲和亚洲市场。公司总部位于华盛顿州的伯瑟尔市，有290名雇员，

16、公司还拥有一些遍及其销售市场的地区性销售团队。尽管示例数据库不是为SQL Server新手准备的，但在学习完SQL Server基础知识后，使用它们也不会有困难。认识了SQL Server中的数据库以后，终于可以开始创建数据库了！接下来将从决定要创建的数据库的类型入手，数据库的类型取决于数据库的用途。3.3 决定数据库系统类型在能够设计数据库之前，必须先确定该系统是联机事务处理（OLTP）系统，还是联机分析处理（OLAP）系统。可以在第一次接触用户之前、或者在第一次接触用户期间找出答案，但对于OLTP或OLAP的选择可能在初次提议中已经指明。做出决定以前，需要先理解这两个关键的系统类型。3.3

17、.1 OLTPOLTP系统提供数据的即时更新。OLTP数据库系统极有可能有一个用.NET语言（如Visual Basic .NET(VB.NET)、C#或ASP.NET）编写的独立用户前端。用户前端调用数据库，并且立即更新用户对底层数据所做的任何改变。对于OLTP系统，需要进行许多考虑以确保系统快速而可靠，并能保证数据完整性。设计OLTP系统时，至关重要的是：不仅要有正确的数据库结构，还要有正确的物理存放位置。规范化为第三范式（该术语的意思将在本章的后面做详细讲述）的OLTP系统是很常见的，尽管并非每个案例都是如此。通过规范化数据，将有助于达到OLTP系统的其中一个主要目的：使数据更新尽可能地

18、快。在通过移除冗余或重复列来规范化数据时，应确保数据尽可能地简洁。规范化在许多OLTP系统中是极为重要的。1备份许多OLTP系统是一天24小时、一周7天永不停歇地在使用。在这样的系统中，数据改动极为频繁，这就意味着备份数据库是一项必须进行的任务。尽管可以在SQL Server正在使用时对数据库进行备份，但最好还是在不使用SQL Server时或者只有少量的数据更新活动发生时执行备份。理想的时间段也许是在午夜，或者甚至是中断时期。当决定执行备份时，至关重要的是：要经常在OLTP系统中监视和检查备份，以确定系统仍然能如希望的那样工作。下面这种情形并不鲜见：那些被认为能够在灾难发生时用于还原的有效的

19、备份，事实上却是损坏的、不完整的或者可能根本没有创建的备份。因此，应该定期从生产中执行备份，并将其重载入安全的开发场所以确保其有效性。2索引速度对于一个成功的OLTP系统十分关键。在OLTP系统中，存在比OLAP系统数量更多的索引，索引不仅有助于使一个表中的数据与另一个表相关联，而且借助索引能够在表中快速访问到数据行。注解 第6章将讲述如何创建索引、索引如何工作以及如何在解决方案中运用索引。3.3.2 OLAP当考虑OLTP系统时，必须紧记对数据库的更新随时可能发生，而且，更新必定是即时反映在数据库中的。此外，另一个要点是：在这样的系统中，许多更新会同时发生，此时并不会对任何数据有所损害。OL

20、AP系统的设计基于如下前提，即数据保持相对静止、没有频繁发生的更新。这些更新可能发生在每晚、每周、每月或者任何其他时间，只要更新不像在OLTP系统中那样频繁发生即可。正如其名字“联机分析处理”所暗示的那样，在OLAP系统中，大量的处理涉及对现有数据的分析。OLAP系统中的数据只应有极少的更新，或者完全没有更新表面上看，只有当在分析中发现数据错误时，或者如前面提及的那样，当有更多的数据要用于分析时，才进行更新。数据备份多半只在对数据库有所改动时，作为“最终操作”执行。在OLAP系统中，没有必要定期进行备份。设计用作OLAP的系统有时不遵循任何设计标准或规范化规则，并且大多数确实只拥有比OLTP系

21、统数量更少的索引。在OLAP系统中往往不存在规范化，因为若不必从规范化的表中提取数据，将更容易获取数据并对数据切片和切块。由于在OLAP系统中只有极少的或者几乎没有更新，因此不必考虑事务的执行及事务的紧凑性。大多数OLAP系统中不存在规范化。在OLAP系统中发现一两个大型的平面表（而不是几个关联在一起的表）是很寻常的，因此，只会有较少的关系，也将只有较少的索引。注解 OLAP系统也称数据仓库，尽管在整个OLAP系统设计中，数据仓库只是其中的一部分。简言之，数据仓库存放OLAP系统中要使用的数据。3.3.3 示例系统类型选择那么，综合考虑上一节中给出的所有信息，不难发现，尽管在示例系统中数据更新

22、相对不频繁（换句话说，只有当发生金融事务或产生账目时才会有更新），但系统中确实存在联机更新，并产生即时效果。因此，本书中的示例系统将是一个OLTP系统。3.4 收集数据在创建数据库前，首先应该做的事情之一是，找出数据库系统中必须要保存的信息是什么以及应当怎样保存那些信息（例如，用数字或文本的形式保存、信息的长度等等）。要完成这一任务，需要进行数据收集，数据收集可能涉及：与作为系统所有者的人士进行交谈，以及与要使用系统的用户进行交谈。对于比较大的系统，可能需要数次会议，每一次的会议针对系统的一部分进行讨论和研究。即便如此，对于每一部分，可能还要花费数次会议反复讨论。此外，还可以安排面谈、分发调查

23、表，或者甚至只是观察所有活动着的现有过程，所做这一切，都是为了尽可能多地收集关于数据库以及将要如何使用数据库的信息。一个数据库解决方案是否成功，其关键主要不在创建系统，而是在收集信息的过程中、在真正写下第一行代码之前。如果取用了错误的信息，或者遗漏了可能对最终解决方案至关重要的元素，那么此时这个系统已经有了缺陷。使尽可能多的用户介入到早期的阶段，并接着使他们参与到设计进程中，将极大减少错误的发生以及最终产品的部件的遗漏。对于本书中的示例金融程序，首先想要与之交谈的是将要显示的数据的所有者。这些人是银行中处理支票、现金提取、信用卡交易等业务的工作人员，以及那些处理股票份额买卖、单位信托、人寿保险

24、单等业务的人员。这些人了解要给哪一位客户发送什么文件或账目清单，以及这些账目清单中要包含什么信息。此外，这些人对于客户想要如何核对这些账目清单多半有不错的想法，并且他们清楚什么数据允许下载并插入到SQL Server数据库中。在第一次会议中，将研究所有的文档，以明确要在当前系统中存储什么信息。会议中会认识到，当前的系统要发送不同的账目清单：一份是客户活期存款账户的账目清单，其余的是客户所拥有的每一种金融产品的独立账目清单。当研究账目清单时，将注重每一种账目清单所包含的信息，需要捕获这些信息以产生类似的账目清单。这可能不仅是与客户相关的信息，也是监管的账目信息。有了源自手中所有文档资料的信息后，

25、就可以开始讨论什么信息是系统所必需的。显然，在这些会议中将讨论大量的信息，其中一些是有用的，而一些则没有用处。确保讨论是以在场人士提出建议的顺序进行记录的，而不是以“合乎逻辑”的顺序记录的。这样可以模拟会议，在这里，人们将“回忆”起必须满足的项目；在这里，一个观点的提出可能使某人想到其他要点。从最初的讨论中，记录如下的要点：(1) 该软件必须能处理多个金融产品。主要的产品是活期存款账户（银行或个人用户用以保存业务详情）。该系统也必须能管理附带产品（如贷款、人寿保险单、汽车保险单），并且，系统还应能记录股市上的所有股票交易情况。(2) 每月或在客户提出请求的任何时候，产生账目清单。如果客户曾在当

26、月内请求账目清单，仍将产生一份那个月的账目清单。(3) 每天，在有存款的账户上增加利息，从透支的账户中扣除利息。(4) 客户可以以系统独立版的形式拥有年度保险费、月保险费或一次收付清保险费的产品。需要知道何时开始收款以及何时停止收款，也需要确定要为哪一个产品发出提醒（例如，一份给客户的通知，告知客户他的汽车保险单需要续约）。(5) 如果某一项产品的托收失败了，系统必须进行具结，使得下次收款时，能征收到该笔款项。(6) 每一项产品有自己的账目清单，但只有银行业务账目清单是可以请求产生的。(7) 由于允许进行股票份额的交易，因此系统必须在任何时间记录和显示客户特有股票的现值。注意上述列表中的信息完

27、全没有固定的顺序，因为信息往往就是这样显露出来的。还要注意，第(2)点和第(6)点，多少有一些信息上的重复；如果没有认识和理解到这一点，可能将引发问题。注解 这里对示例数据库只执行了数据收集任务。在这里所收集到的信息应该在稍后的设计阶段与用户进行反复查对，不过这已超出了本书的讲述范围。3.5 决定要存储在数据库中的信息现在将使用前一节中记录下的要点，试着找出每一个要点关注的所有领域。通过观察这一系列需要记录信息并把信息存储到数据库中的领域，很明显会发现，需要把它们以某种方式进行排序归类。目前，仍然是以逻辑的视点来观察解决方案，尚不准备开始创建数据库中的任何事物。3.7.1 使用键在数据库的表中

28、，键是标识记录的一种方式。因为键涉及的是全部的记录，所以，可以使用键来建立表之间的关系例如，当要用到不同表中的同名列进行工作时，可以利用这种特性。以键作为一种捷径，能够很容易地在两个表之间建立链接。当唯一地标识表中的记录是数据库设计中的重要部分时，键也能被使用。当单独一个列足以标识记录时，可以将键定义在单一的列上，否则，将键定义在多个列上。接下来的部分介绍可以在数据库中使用的三种类型的键：主键、外键/引用键以及候选键/备用键。另外，还将介绍一种可以用来替代主键的SQL Server方法，称为约束。1主键主键或许是最重要的键的类型。首要地（也是最重要地），要在其上定义主键的列必须只包含唯一的值。

29、主键不能定义在不返回任何行的列（或列的序列）上。为此，不可能在任何允许NULL值的列上定义主键。关于主键的另一个限制是，一个表只能有一个主键。可以利用主键把一个表中的数据与另一个表中的数据相关联。例如，在本书的示例数据库中，有两个表：一个表存储客户，另一个表存储客户的银行交易。在客户表的客户ID（每当加入新客户记录时，将产生一个唯一的客户ID）上定义了主键。那么主键将用来关联银行交易表中的多个记录，为客户ID返回其所有的银行交易。这两个表之间的链接是客户ID（正如前面所述，它被定义为客户表的主键）。稍后，将看到如何把表联接到一起并在它们之间定义关系。联接和关系在本质上指的是同一件事，即：可以在

30、两个（或多个）表之间通过特定的列（或列的集合）定义的逻辑链接。2外键/引用键以一种关系把两个（或多个）表链接到一起，这种情形时有发生。正如上一部分中的例子所示范的那样，在客户表和交易表之间建立链接的是客户ID列。该列在客户表中返回唯一的行，因此定义为主键。然而，在交易表中必须要有相应的外键（或引用键），以链接回客户表的客户ID列。当要在本书的示例数据库中创建关系时，将看到为何创建外键将在两个列之间创建一种链接（或关系）。这种链接是通过约束创建的，约束是SQL Server使用的一种方法，用来检查建立在关系中的细节。从外键的观点来看，约束（或检查）将确保关系遵循为之设置的条件。在后面 “更多关于

31、外键”一节中，会更深入地探讨外键。3候选键/备用键前面讲过，一个表只能有一个主键。然而，可能会有另外的键也能轻而易举地定义为主键，这样的键是成为主键的候选，称为候选键。从根本上来说，在候选键和主键的定义之间没有必然的区别。例如，如果有一个表，用来存储通用（GM）汽车的备件，当在总店为各GM分店订购零件时，可能会有一个内部的GM零件号供使用。该零件号将是唯一的，适于用作主键。另一方面，每一个制造厂商也会为其零件创建（对他们而言）唯一的零件号。如果数据库中包含制造厂商标识符，那么由制造厂商赋予的零件号也能用作主键。由于一个表中不能有两个主键，而且已经选择了GM零件号作为主键，从而可以把制造厂商标识

32、符和制造厂商零件号创建为候选键。4替代主键的唯一约束通过定义这种约束，将确保唯一值只能输入到在约束中定义的一个或几个列中。尽管这似乎很像前面讲过的主键定义，但二者是不同的。唯一约束不是主键，但在唯一约束中定义的一个或几个列也可能成为主键。此外，唯一约束能够包含NULL值，但主键不能。不过，由于NULL被视为与列中任何其他值一样，因此，当准备插入或更新数据时，必须使构成唯一约束的列保持唯一，从而只允许有一个 NULL值。最后，一个表可以有多个唯一约束，但只能有一个主键。3.7.2 创建关系在SQL Server数据库中，关系是两个表之间的逻辑链接。虽然，在后面将看到，设计数据库时，会在两个表之间

33、画出一条物理连线，但表之间是不存在物理链接的。表之间有物理链接意味着，链接两个表的真实数据将只在某个中间位置存储一次，而链接两个表的键的信息要存储多于一次，然而事实并非如此。当定义逻辑关系时，是在告诉SQL Server：将要把来自主表的主键与另一个表的外键链接起来。如此一来，这就需要有两个键，每个表一个。接下来的部分，将从观察关系如何对引用完整性概念起作用开始，详细地讲述关系，1关系和引用完整性可以用关系来强制数据完整性。换句话说，如果由于数据在某个表中而希望另一个表中也有这样的数据，就可以在这两个表之间放置一种关系，以确保没有任何SQL命令破坏这种规则。不过，不要把引用完整性与维护数据完整

34、性的其他过程（例如，在列上放置检查或默认值以保证某个特定列的值是有效的）混淆了。引用完整性围绕如下要旨：数据库中，有两个表包含相同的信息，要求两个表中重复的数据元素保持一致性。例如，如果一个表中有一个主键，另一个表中有一个外键，主键和外键的数据是完全匹配的，那么，重要的是要保证这两部分数据要么一起改变，要么根本不发生改变。要强制引用完整性，并非只有关系一种方法，也可以使用触发器来确保数据有效（这将在第13章中进一步讨论）。举例来说，本书的示例银行系统中包含客户表和交易表。如果某客户在客户表中没有记录，则不能记录该客户的交易。结果，必须使用引用完整性来强制这两个表之间的数据完整性，因此，当某客户

35、的交易记录还存在时，不能从数据库中删除其客户记录。同样，如果某客户没有交易记录存在，则允许移除其客户记录。强制引用完整性的另一个结果是，如果某个客户引用号在客户表中不存在，则无法输入具有该客户引用号的交易记录。若要在这种情形下输入客户交易记录，必须先在客户表中创建客户记录，然后才能完成交易记录的输入。最后，当与某客户记录相关的客户交易记录存在时，如果要修改客户记录中的客户引用号，必须先在客户交易记录中作修改，并检查所修改的客户交易记录的引用已经存在，然后才能在客户记录中修改客户引用号。因此，要想维护数据的完整性，有许多规则要遵循。如果确实希望如此，就使用引用完整性来强制数据的完整性。不过，与此

36、相对的另一种做法是，不使用引用完整性来强制数据完整性，而是通过创建存储过程或触发器（SQL Server中某种类型的程序）来实现这一任务。相关的主题将在第10章和第13章中讲述。使用存储过程和触发器来维护数据完整性是可行的，但不是令人满意的解决方案，因为这会使系统暴露在不能保持数据完整性的场合（可能由于系统设计中的漏洞，也可能由于开发者没有用正确的处理顺序来确保所有数据总是有效的）。不仅如此，如果有人直接向表中加入数据，引用完整性将会丧失。当然，在应用程序中进行数据完整性检查确实能减少网络流量，因为所有的验证都是在前端进行的。在讨论数据库关系类型之前，关于引用完整性，还有一个要点需要说明：如果

37、想要通过在两个表之间创建关系来维护引用完整性，这两个表必须在同一个数据库中。在两个数据库间不可能存在引用完整性。2关系类型在数据库中，主要存在如下三种关系类型：q 一对一关系。q 一对多关系。q 多对多关系。接下来将分别讲述每一种关系类型，这样，当需要创建关系时，就知道应该创建哪一种关系，该在何时创建以及为何要创建。下面先从一对一关系开始讲述，虽然这种关系最不常用，但它可能是最易于理解的一种关系。3一对一关系这种关系在实际运行的数据库中比较罕见。一般来说，没有什么真正的理由来让一个表中的一条记录只与另一个表中的一条记录相匹配。这种情形只会发生在：例如，当要把一个非常大的表拆分成两个单独的表时。

38、为了说明一对一关系，假设本书的示例银行数据库中有一个为ATM卡存储PIN号码的表，该表与客户记录中的其余部分完全分开（如图3-1所示）。多数情况下，一个客户记录有一个PIN号码记录，不过也可能有例外如高利息存款账户可能没有ATM卡，因此也就没有相关联的PIN号码记录。图3-1 一对一关系4一对多关系一对多关系可能是数据库中最常见到的一种关系。这就是一条主记录与子表中0条、1条或多条记录相关联的情形。以示例银行数据库为例，假设有一条客户主记录以及任意数目的关联交易记录。这些关联交易记录的数量可以从0条（对应于客户是银行新客户的情形，此时尚未进行存款或执行交易）到1条或者多条（对应于账户中已有初始

39、存款的情形，此后该账户又发生了更多的存款或取款交易），如图3-2所示。图3-2 一对多关系当在示例数据库解决方案中建立客户对交易关系时，将再次看到这一概念的运用。5多对多关系多对多关系是最后一种能存在于数据库中的关系类型。当主表中0条、1条甚至多条记录与子表中0条、1条或多条记录有关时，多对多关系会较频繁地出现。多对多关系的一个例子是：某公司从好几个仓库进行发货（视为主表），然后，将货物发送到许多商店（视为子表），如图3-3所示。可以对仓库进行定位和组织，使得不同的仓库都能为同一个商店供货，并且，仓库也能分组（如农产品、冷冻品、易腐败品和保税品）。为了让商店能得到丰富的货物补给，需要有许多不同

40、的仓库对其供货（通常是位于不同地点的仓库）。图3-3 多对多关系当在数据库中建立关系时，必须要有外键。在本章的前面曾简要地讲述过外键，下一节将更深入地探讨外键3.7.3 更多关于外键外键是子表上的键，定义在该键中的列（一个或一组）能正好与主表中的列在信息和数量上完全匹配。使用外键，能通过关系构建要返回的数据。此外，外键并非必须映射到主表的主键上。尽管外键映射到主键上十分常见，但是，当主表中被映射的键是唯一键时，也可以在主表与子表之间建立关系。外键的所有本质在于其映射的过程以及它位于子表上这一事实。仅当创建了从子表到父表的关系以后，外键才得以存在。但是，主表和子表到底是什么？为了说明，回想一下讲

41、述关系时的例子。例如，来看一对多关系。主表将在左边，或者说在关系中的“一”这一边，而子表将在右边，也就是关系中的“多”这一边（如图3-4所示）。图3-4 外键关于外键、关系以及主表和子表，还有最后一点需要说明。对于主表和子表而言，完全有可能二者就是同一个表，外键和唯一键也都定义在这同一个表中。这称为自联接或自反关系。这种情形是相当特殊的，因而在数据库中往往并不多见，尽管也可以通过这种关系来确保一个列中的数据与另一个列中的数据完全匹配，就像在任何其他联接中那样。例如，假设有一个围绕客户的表，其中有两列，一列是父客户ID，保存总公司的ID并用来链接所有的分部。如果把总公司也看作是联合企业的分部，第

42、二个列是具体的分部ID，可以在这两列之间放置一个链接，使得当总公司作为分部时，该链接依然有效（如图3-5所示）。另一个例子是：在所有雇员所在的雇员表中，具有一个从雇员到其经理的自联接。学习完关系，下面将讨论如何规范化数据库。图3-5 位于同一表中的外键3.8 规范化数据库的规范化是减少表中数据重复的一种技巧。于是，就能建立通过键或索引相互关联的多个表。大量消除重复数据后将得到更小、更紧凑的数据库。这样将减少出现混乱（在存放“相同”数据的列中，哪一列的数据是正确的？哪一列的数据应做修改）的几率，并且，将减少实时更新多列数据的开销。注解 只是提醒一下，现在仍然还在建立解决方案的逻辑阶段，依然还不准

43、备在SQL Server中创建数据库。规范化可能会影响数据库以及数据检索的速度，因此数据库设计者不可能无度地规范化。对数据库进行合理而有益的规范化，重复数据的消除将带来更快的数据排序速度，查询也将运行得更快，从而改善性能。尽管通过规范化将产生高效的数据库，但是，也可能会由于创建了太多的关系和太多狭小的表，导致过分规范化数据，以致检索一条信息需要访问许多的表并在这些表之间产生许多联接。高明的设计者知道何时该停止规范化，不会走得太远，例如产生太多的关系。这些知识主要源自经验和实践，但在示例数据库中，读者将学会该在哪里“停止”。提示 当任何参考表返回一个数据行，没有更多的表查阅检索那条信息，这就是应

44、该停止规范化的信号。本章的这一节，将以称为逻辑建模的方法对示例数据库建模。建立逻辑模型的目的是显示应用程序为满足商业需求而必须存储的数据。它展示数据如何相互关联，并探究在项目开发领域之外的商业领域中的任何整体需求。在创建逻辑模型时，无需考虑任何特定的计算机环境，因此没有为性能、数据存储等进行优化。在逻辑模型中，术语实体用于表示表的一种概念形式。鉴于目前仍然在数据库设计的逻辑建模阶段，因此，在讨论中将使用“实体”而不是“表”，因为实体对于实现的依赖较少。同样，在逻辑建模中，把数据列称为属性。为了建造示例数据库的逻辑模型，将汇总本章之前的所有信息，并在实体中实现属性。这样一来，将明白需要如何修改设

45、计。剩下的问题是：实体中应该包含什么？下面的三个原则决定着实体的内容：q 每一个实体应该有一个唯一的标识符。q 只存储与实体直接有关的信息。q 避免重复值或重复列。在后面的小节中，将更详细地讲述以上每一个原则。3.8.1 每一个实体应该有唯一的标识符在每一个实体中必须能找到唯一的行。可以通过使用唯一标识属性（或几个属性的组合）来实现这一目标。然而，无论使用什么方法，在唯一标识属性（组）中，一定不能有两个行包含相同的信息。考虑到实体中可能没有属性的组合能够使行唯一，或者，可能希望从单独的属性中构造唯一值，此时需要有其他的解决方案。SQL Server中有一种特殊的数据类型，称为唯一标识符（uni

46、que identifier）数据类型，通过它可以使行唯一；不过，更常用的解决方法是，先创建一个整数列，然后把该列设置为标识（identity）列。关于这种方法，将在第5章讲述构建表时学习到更多。3.8.2 只存储与实体直接有关的信息在某些情况下，把非常多的信息放在一个实体中可能很容易，因此几乎改变了这个特定实体存在的理由。这样做的话，将不得不在实体中插入重复的信息，这可能会降低OLTP系统的效率。并且，当为一件事情所设计的实体事实上包含了另一事情的数据时，可能会带来混乱。3.8.3 避免重复值或重复列当一个属性包含的信息是同一个实体（或相关实体）中另一个属性的严格副本时，是空间和资源上的浪费。但是，往往容易在两个（或多个）表中出现重复属性或重复值，因而产生重复的信息。正是在这种情形下，需要避免重复值并把重复值移走。3.8.4 范式现在，已经知道应该在实体中包含什么数据，那么，该如何对数据进行规范化呢？本章要讲述如下几种规范化形式：q 第一范式（1NF）。q 第二范式（2NF）。q 第三范式（3NF）。虽然还有很多别的、“更高”的规范形式，但它们在学术研究之外很少用到，因此本书将不涉及。1第一范式要使数据库满足第一范式，就要消除所有重复信息组。任何重复的数据组