第五周翻译（Stairway to T-SQL DML Level 3: Implementing a Relational Model in SQL Server）

本文是阶梯系列的一部分：T-SQL DML的阶梯。

 这个阶梯将会为你提供一个最基本的理解，即如何使用SQL Server的翻译 SQL(T- SQL)的方言并且对SQL Server表格中的数据进行更深度地处理。DML是数据操纵语言，针对的是处理数据的语言的方面。所以它包括语句的选择、插入、更新和删除。而这个阶梯也将会提供一些SQL语言的历史和一些关于集合理论的一般概念和理解。而每一层都会建立在先前的水平之上，所以当你完成时，你将会更好地了解并知道如何从SQL Server中选择和修改数据。

 而在上一级的阶梯中，我提供了关于基本选择语句和SQL历史的信息，而这些级别为理解如何检索数据和SQL环境是如何随着技术和技术解决方案发生演变的提供了基础，而技术和技术解决方案已经改变了当前的工作。在这个级别中，我将探索如何实现基于关系模型的简单SQL Server数据库。但是在开始创建数据库之前，首先让我介绍一下关系模型的创建者的一些历史。

 关系数据建模之父

 关系数据库设计的概念起初是由Edgar F Codd提出。. 在1970年，Codd发表论文，论文的标题为“大型共享数据银行的数据关系模型”。Codd在IBM工作时就构建了这种建模理论，但是IBM在Codd的数据建模概念上思维跳得并不够快，所以IBM并不是第一个供应关系数据库引擎的供应商，它仅是利用了Codd的新关系数据建模理论。Codd的关系建模概念现在是用于SQL Server和其他关系数据库引擎中创建关系数据库的框架。Codd出生在英格兰的波特兰岛，他在加入皇家空军之前就学习了数学和化学，之后成为了第二次世界大战的飞行员。在1948年，他搬到纽约，开始了在IBM工作，而在那里他是一名数学程序员。之后他又漂泊了好几年，最终他搬到加州，在IBM圣何塞研究实验室里工作。直到20世纪90年代，当他的健康状况不佳而公司迫使他退休时，Codd依然继续努力地完善并证明了关系数据模型的合理性。2003年4月18日，Codd去世，享年79岁。

 在SQL Server中实现关系模型

 这个阶梯并不是用来教你如何为关系数据建模，或者数据库设计，而是教你如何从一个关系模型中创建一个SQL Server数据库。但是在我为创建SQL Server的数据库提供代码块之前，我们首先应该探索一个将被实现的关系数据模型。我的简单的关系模型将包含一些实体(数据表)，其中有主键定义和不同实体之间的一些关系(外键约束)。

 我的简单的关系模型是一个简单的酒店预订系统。而这个预订系统需要跟踪客户的预订信息。如图1所示，说明了这个简单的关系模型，而我将会使用T-SQL来实现它:

图1：这是一个简单的关系数据库模型，它由6个表格组成

通过回顾这个模型，你可以看到它包含许多实体(由方框表示)来跟踪预订相关信息。而每个实体都由一些属性(列)组成，在其中一个或多个属性被标识为主键(粗体和下划线的名称)。表示实体之间的一些关系(以箭头表示)，以显示不同的实体之间是如何相互关联的。我将使用实体、属性、主键和关系的关系模型，然后开发一个物理SQL Server数据库，它将表示此关系模型的设计。但是要从这个模型构建物理数据库，我们还需要在SQL Server中识别基于此模型定义的不同对象。但是对于图1中的每个实体或框，我会在SQL Server中创建一个表。而对于每个实体的每个属性，我将在关联的表中新创建一个列。对于每个主键，我将会创建一个唯一的集群索引(需要注意的是，使用唯一的非聚集索引也能够创建主键)。有关索引的更多信息，请参考http://www .sqlservercentral.com/stairway/72399/).。最后，对于每个关系，我都将会创建一个个外键约束。当开始构建我的数据库时，我首先需要建立一个SQL Server数据库来保存我计划建立的所有新数据库对象。我的数据库将被称为房间预订。我将使用以下的T-SQL来创建我的数据库：

CREATE DATABASE RoomReservation;

要从我的模型中开始构建我的房间预订数据库对象，首先将创建表对象。要在sql server服务器中创建一个表，我需要使用创建表语句。通过使用创建表语句，我将能够定义表中的每个表和所有列。下面是创建SQL Server表格的简单语法：

CREATE TABLE <table_name> (<column_definition> [,…N]);

地点:

<table_name>=表名

<column_definition>= column_name data_type[NULL | NOT NULL]

对于CREATE TABLE语句的完整语法，请参见联机的SQL Server Books。

我创建的第一个表是Customer表，它是使用清单1中的代码创建的。

清单1:创建Customer表

在这段代码中，当我创建我的Customer表时，我建立了我需要的所有列，但是我还指定了在插入或更新记录时，该列是否还需要一个值。通过在某些列上指定非空值来实现这一点，而其他列则指定为空值。

如果一个列被定义为不为空，那就意味着你不能创建一个空的记录，除非你用一个实际值填写在这个列。而使用空值规范定义一个列意味着你可以创建一行，就不必为这个指定一个值，或者另一种方法是，该列允许空值。我在创建表的语句上面就允许地址2和邮箱地址支持空值，而所有其他的就需要值将提供创建一个行。

但是这个创建表语句并没有完全定义我的客户表，因为它是在我上面的关系数据库模型中表示的。还需要建立一个主键约束的列ID。这个主键约束将确保该表中没有两个具有相同的客户编号码的值的记录。这个主键约束将能够确保该表中没有两个记录具有相同的客户编号码的值。创建主键的代码如清单2所示

清单2:向客户表添加主键约束
此表语句向客户表添加了主键约束。该主键将在聚集索引命名pk_customer窗体的创建。在翻译SQL语言中，通常有不止一种方法可以完成同样的事情。或者，可以通过运行清单3中的创建表语句一次性创建客户表和主键。

清单3:用主键创建客户表的另一种方法
在这一点上，我已经向你展示了如何创建具有定义主键的表。剩下要展示给你的是如何建立外键约束。但是在此之前，让我先向你提供创建上述关系数据库模型中其余表和主键的脚本。你可以在清单4中找到它。

清单4:创建额外的表和主键约束

一个外键约束在两个相互关联的表之间强制引用完整性。外键约束定义的表是“引用表”，需要在另一个表中有相关的记录，称其为“引用”表，任何时候在表中插入或更新一行。在图1的关系模型中，这些外键之间的关系由箭头表示。外键约束只在关系中的一个表上定义。在图表中，外键约束将被定义在具有箭头尾部(无尖端)的那些表上。

为了在关系模型中定义这些外键约束，需要修改每个引用表来添加约束。清单5是我用来在保留表上创建外键约束的t - sql代码。这个约束确保记录不会被插入或者更新到预订表中，除非在顾客表中有基于客户编号找到匹配的记录。

清单5:在引用客户表的预订表上创建一个外键约束
为了完成设计，需要实现其他所有外键约束。图1中，在我的模型识别，清单6包含了我的数据模型中建立额外外键约束的变更表语句。

清单6:创建额外的外键限制

验证数据库的设计

  一旦完成了从数据模型构建数据库的工作，就应该验证所实现的设计，以确保它是正确的。这个验证过程是确保我在构建物理数据库中的所有数据完整性规则都能正确地实现。在设计中，需要验证这些规则。

    所有插入或更新的行必须对定义为非空值的列有一个特定的值。

主键的列不允许重复的值。

具有外键约束因素的列不允许在引用表中没有匹配记录的数据。

在验证数据完整性规则之前，首先还需要用一些有效数据填充引用的表。使用清单7中的代码来填充那些有一些有效数据的表:

清单7:插入初始数据

为了验证我在数据库中构建的数据完整性规则，我将运行清单8中的INSERT语句。

清单8:用INSERT语句测试各种约束

这些INSERT语句中的每一个都应该失败，因为它们违反了构建在订房数据库中的数据完整性规则。第一个INSERT语句违反了预订规则列的非空验证的检查。

第二个INSERT语句违反了放在房间类型表上的主键约束。这个INSERT语句试图为房间类型编号的列插入3的值。问题是在房间类型值为3的房间类型表中已经有了记录。

最后一个INSERT语句违反了顾客缴费方式表的外键约束。在这个特殊的INSERT语句中，顾客表中没有客户编号值为2的值。

要想正确地插入这些记录，插入的数据值就需要清理。一旦数据被清理干净，就可以将这些新数据插入到合适的表中。清单9包含清除所有数据完整性检查并成功插入到房间预订数据库中的适当表的清理INSERT语句:

清单9:附加约束测试

关系数据库设计

我的预订示例演示了如何使用关系模型并使用它来实现SQL Server数据库。通过使用非空值、主键和外键完整性约束，将数据完整性规则建立到数据库设计中。这就允许在底层数据库定义中执行这些规则，而就不必在业务处理层中编写代码来验证这些数据的规则。通过这样做，允许SQL Server数据库引擎为我执行这些数据完整性检查。

通过了解并在关系数据库模型周围建立数据库设计，你将构建一个成熟且高效的数据库实现，你可以在数据库中建立数据完整性检查。