任务分解

经典的软件开发模型把软件生命周期分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护等阶段。数据库的需求分析和设计是软件开发项目的需求分析和设计的一个重要子集。目前得到公认的数据库设计方法是1978年提出的新奥尔良法，它把数据库设计分为用户需求分析、概念结构设计、逻辑结构设计和物理结构设计四个步骤。

（1）概念结构设计

概念结构设计是数据库设计的一个关键阶段，简单地说就是将用户需求转换成数据库的概念模式。通过对在需求分析阶段得到的用户应用需求进行综合、归纳、抽象，形成一个独立于具体的数据库管理系统（DBMS）的概念模式。在此阶段，用E-R模型来描述数据的抽象结构。

（2）逻辑结构设计

在逻辑结构设计阶段，将高层的概念模型映射到所选用的DBMS所能实现的数据模型上。也就是将概念设计阶段设计好的E-R模型转换为要使用的DBMS所支持数据模型相符合的数据模型。

（3）物理结构设计

物理结构设计，是为逻辑数据模型选定一个合适的物理结构的过程，即设计数据库的存储结构和存取方法，以及其实现细节。

在实际软件工程项目中，需要简洁、合理、切合实际的需求分析，以及合理的过程和步骤，才能设计出更有利于项目实现、合理的数据库模型，这也是后续项目内容高效、高质、高性能、易于实现的保证。因此，整个项目单元内容可分解为4个任务来实现不同的目标，具体的任务内容和能力目标如下：

1.任务内容

任务1：数据库需求分析。

任务2：设计E-R模型。

任务3：构建关系模型。

任务4：设计规范化。

2.能力目标

知识目标：掌握数据库需求分析与设计的步骤、数据流图、E-R模型、数据类型、完整性约束、三个范式等相关知识。

技能目标：使用Microsoft visio软件绘制业务流程图、数据流图、E-R图，设计数据表逻辑结构，包括主键、外键等约束，对关系模式进行规范化检查。

任务1　数据库需求分析

数据库需求分析是数据库设计人员在用户参与的条件下，分析数据库应用系统的业务和数据库处理需求，从用户角度来认识系统。需求分析通过调研和用户充分沟通交流，获取用户原始需求后，对这些需求进行分析、提炼，形成满足用户应用业务需求的抽象描述，为数据库设计提供基础和依据。其结果好坏将直接影响数据库设计，乃至后续整个应用开发的工作。

1.任务描述

“电子商务系统”涉及多种对象之间的业务关系，其中主要是买方（消费者）和卖方（销售商家）的购买关系，需求分析应该从消费者购买商品、商家处理订单并发货两个关键业务角度出发，通过各种需求获取方法（如调研、询问、交流会、跟班作业、记录等），获取“电子商务系统”的用户原始需求。然后对用户原始需求进行分析。分析的主要内容包括用户数据的要求、数据加工处理的要求、数据安全性与完整性要求，同时形成包含业务需求、业务流程、功能结构、数据流图等信息的需求文档。

本任务需要完成如下重要工作：

①分析业务流程。

②分析系统功能结构。

③绘制数据流图。

2.任务实现

每个商业企业的“电子商务系统”的业务并不完全相同，各自有自己的个性需求，但核心的功能模块基本相同，关键的业务流程基本相同。下面从业务流程、系统功能结构、数据流等方面来实现数据库的需求分析。

（1）业务流程

电子商务的业务系统包括前台业务系统和后台业务系统，前台业务系统主要完成顾客选择商品和购买商品的功能，后台业务系统主要完成客服人员或管理人员对订单和商品的处理功能。二者涉及的业务流程较多，前台业务流程主要为购物流程，客户通过浏览电子商务网站上的商品，选购合适的商品，填写收货信息并选择支付方式，完成订单的生产，如图2-1所示。后台业务流程主要为订单处理流程，客服人员查看并选择相应的订单进行处理，并安排商品的配送，完成订单的处理，如图2-2所示。

（2）系统功能结构

系统功能结构是为满足用户应用系统的业务需求而设计的软件功能模块构成。根据上述对电子商务系统业务流程的分析，结合实际调研的用户需求，“电子商务系统”的主要功能模块包括商品（产品）管理、订单管理、用户管理、统计分析等模块。商品管理模块的功能包括：商品管理、商品类别管理和供应商管理。订单管理模块的功能包括：订单查询和订单处理。用户管理模块的功能包括：会员管理、客服人员管理和管理人员管理。统计分析模块的功能包括：流量统计分析和销售统计分析。其功能结构图如图2-3所示。

各模块完成的业务功能如下：

①商品管理模块。商品管理模块主要实现的功能操作包括：商品的添加、修改、查询和删除；商品类别的添加、修改、查询和删除；供应商的添加、修改、查询和删除。

②订单管理模块。订单管理模块主要实现的功能操作包括：订单的查询、修改、确认、取消、发货处理等。

③用户管理模块。用户管理模块主要实现的功能操作包括：会员的添加、修改、查询和删除，以及会员基本信息、积分、等级等资料的维护。客服人员的添加、修改、查询和删除，客服人员的基本信息、权限等资料的维护；管理人员添加、修改、查询和删除，管理人员的基本信息、权限等资料的维护。

④统计分析模块。统计分析模块主要实现的功能操作包括：网站访问流量的统计分析、商品销售情况的统计分析等，如根据商品、商品类别或供应商的不同，进行销售金额、数量的分类统计分析。

（3）数据流图

数据流分析是对事务处理所需的原始数据进行收集，经过处理后所得到的数据及其流向，一般用数据流图（Data Flow Diagram，DFD）来表示。数据流图是结构化系统分析方法（SA）中常用的工具，它以图形的方式，从数据传递和加工的角度出发，来描绘数据在系统中流动和处理的过程，表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程。数据流图的基本图形元素主要有：数据流、数据加工（处理）、数据存储，以及数据源（终点，也有称外部实体）。

●　数据流：是数据在系统内传输的一项或一组数据，即流动中的数据。在绘制数据流图时，数据流用带箭头的线表示，在其线旁标注数据流名（如：→）。

●　数据加工：或称数据处理，是对数据进行处理加工的单元，接收输入的数据，然后进行加工处理，并且产生新的数据输出。在绘制数据流图时，数据加工用圆圈表示，在圆圈内写上加工名（如：〇）。

●　数据存储：用于存储数据信息，表示数据信息的静态存储，如文件、数据库表、账本等。在绘制数据流图时，用双杠表示（如：=）。

●　数据源（终点）：指数据的源点或终点，表示系统之外的实体，它们与本系统有信息传递关系，如人、物或其他软件系统。在绘制数据流图时，用方框表示（如：□）。

根据“电子商务系统”的业务流程的需求分析，可以画出前台业务的数据流图，如图2-4所示，以及后台主要业务的数据流图，如图2-5所示。

任务2　设计E-R模型

当数据库的需求分析完成之后，接下来的阶段就是数据库设计阶段。数据库设计，简单地讲，就是在需求分析的基础上，对数据模式的设计。数据库设计是数据库应用项目建设的一个重要过程，介于数据库需求分析和数据库实施两个阶段之间。规范的数据库设计，有利于整个项目的实现。数据库设计可分为三个阶段：概念结构设计、逻辑结构设计和物理结构设计。

概念结构设计是数据库设计的一个重要阶段，就是将需求分析阶段得到的用户需求抽象为信息结构，即概念模型。概念模型有许多，其中最著名、最实用的一种就是E-R模型。E-R模型将现实世界的信息结构统一用属性、实体以及它们之间的联系来描述。

E-R（Entity-Relationship）模型，即实体-联系模型。它通过直观的E-R图来描述现实世界的概念模型，反映实体与实体之间的联系，提供了以图形方式表示实体、属性、联系的方法。实体（Entity）表示客观世界的一个事物，如一件商品就是一个实体，每一个人就是一个实体。属性（Attribute）指实体所具有的某一特性。一个实体可以由多个属性来刻画。如姓名、身高、体重就是人这个实体的属性。联系（Relationship）表示实体和实体之间的关联关系。如商品和会员这两个实体的关系可以是购买，即会员购买商品。

在绘制E-R图时，实体用矩形表示，矩形框内注明实体的名称。属性用椭圆形表示，椭圆形内注明属性的名称，并将其与相应的实体用直线连接起来，表示这个实体的某个属性，如图2-6所示。联系用菱形表示，菱形框内注明联系名称，并用直线和相关联的实体连接起来，同时注明联系的类型（如：1：1、1：N、M：N）。图2-7就是一个简单的E-R图。

两个实体之间的联系可以分为三种：

（1）一对一联系（1：1）

如果实体集A中每一个实体，在实体集B中至多有一个实体与之联系，反之亦然，那么就称实体集A与实体集B具有一对一的联系。如“一夫一妻制”国家的丈夫与妻子的联系，总统与国家的联系，这些都是一对一联系的例子。

（2）一对多联系（1：N）

如果实体集A中每一个实体，在实体集B中有N个（N≥0）实体与之联系，反过来，实体集B中每一个实体，在实体集A中只有一个实体与之联系，那么就称实体集A与实体集B具有一对多的联系。如班级和学生的联系，就是一对多联系。

（3）多对多联系（M：N）

如果实体集A中每一个实体，在实体集B中有N个（N≥0）实体与之联系，反过来，实体集B中每一个实体，在实体集A中有M个（M≥0）实体与之联系，那么就称实体集A与实体集B具有多对多的联系。如课程和学生的联系，就是多对多联系。

1.任务描述

完成了“电子商务系统”的需求分析，并且对需求分析阶段的成果进行评审，评审通过后，接下来的任务就是在需求分析的成果基础上，完成“电子商务系统”的概念结构设计，其重要内容就是E-R模型设计，即绘制E-R图。E-R图包含三个重要的因素：实体（Entity）、实体的属性（Attribute），以及实体和实体之间的关系（Relationship），在绘制E-R图之前，必须明确这些要求的具体内涵。

本任务需要完成如下重要工作：

①确定存储信息。

②明确实体和实体属性。

③明确实体和实体间的联系。

④绘制E-R图。

2.任务实现

为了绘制合理的“电子商务系统”的E-R图，必须先明确实体、属性和联系等要素的具体内涵，即系统中应该包含哪些实体，这些实体各自应有哪些属性，实体和实体之间应该是什么样的联系。然后根据这些内涵来绘制E-R图，这样才能设计出合理的、符合实际需求的E-R模型，因此，可以通过如下四个步骤来实现：确定存储信息，明确实体及实体属性，明确实体间的联系，绘制E-R图。

（1）确定存储信息

数据库是存储数据的，那么“电子商务系统”主要有哪些数据需要存储呢，这必须在充分理解并分析用户的需求、系统的功能的基础上来确定。根据“电子商务系统”的功能结构，对商品管理、订单管理和用户管理等主要模块进行分析，以确定数据库需要存储哪些对象的信息。

●　商品管理：对商品、商品类别、供应商进行管理，即需对这些对象进行增加、删除、修改和查询等相关的管理和维护。因此，数据库需要存放商品、商品类别、供应商这些对象的相关信息。

●　订单管理：对订单的查询、修改与处理。即需对订单进行查询、修改、取消和发货处理等相关的管理和维护。因此，数据库需要存放订单的相关信息。

●　用户管理：对会员（客户）、客服、管理人员进行管理。即需对这些对象进行增加、删除、修改和查询等相关的管理和维护。因此，数据库需要存放会员、员工、管理人员的相关信息。

（2）明确实体及实体属性

确定了数据库需要存放的信息后，接下来就要确定哪些关键实体存储在数据库中，同时需确定每个实体包含的具体属性。

根据上述确定的数据库需存储的信息，“电子商务系统”数据库中需要的实体有：商品、商品类别、供应商、订单、会员、员工和部门。每个实体的属性如下：

商品：编号、名称、库存、供应商、售价、成本价、图片、类别、上架时间。

商品类别：编号、名称、描述。

供应商：编号、名称、联系人、地址、电话。

订单：订单号、会员、商品、数量、金额、日期。

会员：编号、姓名、地址、电话、用户名、密码。

员工：工号、姓名、部门、性别、电话、用户名、密码。

部门：编号、名称、经理、人数。

根据以上分析，可以绘制出“电子商务系统”中实体及其属性的结构图，如图2-8所示。

（3）明确实体间的联系

E-R图中另一个重要的要素就是实体和实体之间的联系（关系），根据上述确定好的实体，结合这些实体之间的业务逻辑关系，可以分析出各实体之间的关系，根据这些关系就可以建立实体之间的连接。实体与实体之间的联系类型有一对一（1：1）、一对多（1：N）、多对多（M：N）三种类型。“电子商务系统”各实体之间的联系分析如下：

●　商品与商品类别有包含（或从属）关系，即商品属于相应的商品类别，一种商品类别可以有多种商品，商品类别和商品之间是一对多的联系。

●　供应商与商品有供应关系，即供应商提供相应的商品，一家供应商可以供应多种商品，供应商与商品之间是一对多的联系。

●　商品与订单有生成关系，即选购的商品通过提交购物车而生成相应的订单，一份订单可以包含多种商品，订单与商品之间是一对多的联系。

●　员工与部门有从属关系，即员工属于相应的部门，一个部门可以有多位员工，部门与员工之间是一对多的联系。

●　员工与订单有处理关系，即员工处理相应的订单，一个员工可以处理多份订单，员工与订单之间是一对多的联系。

（4）绘制E-R图

根据以上“电子商务系统”分析所得出的实体、实体属性、实体与实体之间的联系，可以绘制“电子商务系统”的E-R图。在绘制E-R图时，其三个基本要素表示方法如下：

●　实体：用“矩形”表示，矩形框内标明实体的名称。

●　属性：用“椭圆形”表示，并用无方向的连线和相应的实体连接。

●　联系：用“菱形”表示，菱形框内标明联系的名称，并用无方向的连线与有关的实体连接起来，同时在连线上标明联系的类型（即1：1或1：N或M：N）。

在绘制E-R图时，如果已经绘制了实体与实体的属性图，为了简化E-R图，在实际项目工作中可以省略属性，这样，避免重复，也使E-R图更简洁。使用Microsoft visio软件绘制“电子商务系统”E-R图，如图2-9所示。

任务3　构建关系模型

构建关系模型，是数据库逻辑设计的重要任务，是把概念模型转换成适合所选择的DBMS的数据模型。“电子商务系统”选择的Microsoft公司的SQL Server 2012是关系型数据库，因此，需把概念模型转换成适合SQL Server 2012的关系（数据）模型。在构建关系模型的时候，需要了解两个重要概念，即数据表和数据类型。

（1）数据表

关系模型数据库的数据表是一个由行和列构成的二维表。其特点如下：

①表中同一列（字段）的数据具有相同的性质，即具有相同的数据类型。

②表中的列名（字段名）不能重复，即具有唯一性。

③表中的列（字段）的位置具有顺序无关性，即列的次序可以变换而不影响表的定义。

④表中元组（记录、行）的位置具有顺序无关性，即元组的次序变换并不影响元组本身。

⑤表中的元组（记录、行）无冗余性，即不应有内容完全相同的元组（记录、行）。

⑥表中的基本数据项具有原子性，即数据项不可再分解。

（2）数据类型

数据类型是什么，在“数据结构”中的定义是：“一组数据的集合以及定义在这组数据集合上的一系列操作的总称”。在设计表时，需要根据各字段值的特性设置合适的数据类型。SQL Server 2012支持的常见数据类型有：数值类型（如bigint、int、smallint、tinyint、real、float、decimal）、字符类型（如char、varchar、text、ntext、nchar、nvarchar）、日期类型（如date、datetime、smalldatetime、time）、货币类型（money、smallmoney）、位类型（如bit）等。各数据类型后面将详细介绍。

1.任务描述

在数据库系统设计中，实现概念模型设计之后，就是实现数据库逻辑设计，其重要任务就是将E-R模型转换为关系模型。因此，在完成“电子商务系统”的E-R模型设计之后，接下来的任务就是构建“电子商务系统”关系模型。项目的数据库系统平台是采用Microsoft公司的SQL Server 2012关系型数据库系统，任务的主要目标是根据已完成的E-R模型来设计基于SQL Server 2012数据平台的电子商务系统所有的数据表以及每个表的结构（包括列、主键、外键）。这些表包括商品表、商品类别表、供应商表、订单表、会员表、员工表和部门表。

2.任务实现

E-R图是由实体、实体属性和实体间的联系三个要素组成，将E-R图转换为关系模型，就是将实体、实体属性和实体间的联系转换为关系模型。实现内容包括：实体与联系转换为关系及联系；确定每个关系的主键和外键；设计数据表。

在关系模型中，关系是指表，元组是指表中的记录，字段或属性是指表中的列。主键是唯一标识关系中每个元组的属性，可以是一个属性，也可以是几个属性的组合，主键实现了实体完整性。外键则可以实现参照完整性，当一个关系（如r1）可能在他的属性中包括另一个关系（如r2）的主键。这个属性在r1上称为参照r2的外键。

（1）实体类型转换成关系，并确定主键

在实体及联系转换成关系过程中，采用如下转换方法：

①每个实体类型转换为一个关系。

②实体的属性即为关系的属性（列）。

③实体的标识属性即为关系的主键。

依据以上方法，结合图2-8中“电子商务系统”的实体和属性，转换成相应的关系如表2-1所示。

（2）实体联系转换成关系间的联系，确定外键

外键反映了实体之间的联系，使表与表之间构成了主从表之间的关系，以维护两个表之间的数据一致性，也就是外键约束关系。实体间的联系有一对一（1：1）、一对多（1：N）、多对多（M：N）的关系。相对应地，关系之间的联系也有这三种联系，这些联系可以通过设置外键来实现。

根据图2-9“电子商务系统”E-R图，“电子商务系统”各表之间的外键关系设计如下：

●　商品表与商品类别表之间：通过共同属性“商品类别编号”来实现联系，商品表中“类别”与商品类别表中的“编号”相关联，实现两个关系表的外键联系。

●　商品表与供应商表之间：通过共同属性“供应商编号”来实现联系，商品表中“供应商”与供应商表中的“编号”相关联，实现两个关系表的外键联系。

●　订单表与商品表之间：通过共同属性“商品编号”来实现联系，订单表中“商品”与商品表中的“编号”相关联，实现两个关系表的外键联系。

●　订单表与会员表之间：通过共同属性“会员编号”来实现联系，订单表中“会员”与会员表中的“编号”相关联，实现两个关系表的外键联系。

●　员工表与部门表之间：通过共同属性“部门编号”来实现联系，员工表中“部门”与部门表中的“编号”相关联，实现两个关系表的外键联系。

（3）设计数据表

通过前面的分析和设计，已经确定了“电子商务系统”各个实体、实体属性，以及实体间的联系，并且把E-R模型转换成了关系模型。接下来就是把关系设计成数据表，在关系型数据库中，一个关系对应一个数据库表，同时，为了数据库在实现和维护过程中更有利于数据的完整性、方便性、合理性，设计数据表时，除主键、外键约束外，根据实际需求，还可考虑其他相关的约束，如是否为空、唯一性、默认值等。

在设计数据表时，应注意如下几点：

●　使用合理的表名和字段名，建议采用英文。

●　针对各字段的数据特征，选择合理的数据类型及长度。

●　除主键与外键约束设置外，根据需求，合理设置空值约束、唯一性约束和默认值约束。

因此，“电子商务系统”基于SQL Server 2012数据库系统平台的数据表设计如表2-2～表2-8所示。

任务4　设计规范化

不规范的数据库设计，可能引起大量的数据操作异常，给数据维护和编程人员带来巨大的麻烦，也可能因较大的数据冗余而浪费存储空间，同时大大降低了系统的性能。而简洁、结构清晰、合理的、规范的数据库设计，将大大减低或避免这些负面的影响。检查数据库设计是否规范，其主要内容涉及规范化检查、范式检查和完整性约束检查。

（1）范式

为了建立结构清晰合理、较少冗余的数据库，在数据库设计时必须遵循一定的规则，在关系数据库中，这种规则就是范式。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。关系数据库中的关系必须满足一定的要求，根据不同程度的要求满足不同的范式。满足最低要求的范式是第一范式（1NF），在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式依次类推。一般说来，数据库只需满足第三范式（3NF）就行了。下面将介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

①第一范式（1NF）。第一范式（1NF）是最基本的范式，也是关系模式需满足的基本要求。第一范式对数据库表的要求是：表中所有字段的值都是不可分割的基本数据项，即具有原子性；没有重复的字段（属性）；一条记录的某个属性不能有多个值；每一行只包含一个实体的信息。

②第二范式（2NF）。第二范式是在第一范式的基础上建立起来的，即满足第二范式必须先满足第一范式。如果一个数据表已经满足第一范式，而且每一个非主属性（除主键以外的其他列）都完全依赖于主属性（主码、主键），则该表满足第二范式。实际上，第二范式要求每个表只描述一类实体信息，而不是多种实体信息。如在电子商务系统中，把商品信息和订单信息放在同一表，就不符合第二范式，如图2-10所示，因为存在“商品名称”“价格”依赖于“商品编号”，而“订购日期”依赖于“订单编号”，这就是明显的部分依赖关系，而不是完全依赖关系。那么，如何设计才符合第二范式呢？应该设计两个表，把商品信息放在一个表中，而订单信息放在另一个表中。

③第三范式（3NF）。满足第三范式（3NF）必须先满足第二范式，而且任何两个非主属性之间不存在函数依赖关系或传递关系。简单地说，第三范式（3NF）要求一个数据库表中不包含已在其他表中已包含的非主关键字信息。如员工表（员工编号、姓名、性别、部门编号、部门经理），这样的员工表就不符合第三范式，因为在员工表中非主属性存在传递关系，即员工编号→部门编号→部门经理。如果原来没有设计部门表，则根据第三范式的要求也应该设计它，否则就会有大量的数据冗余。

（2）完整性约束

完整性约束是为保证数据库中数据的正确性、一致性和相容性，对关系模型提出的某种约束条件或规则。通常包括实体完整性、参照完整性、用户自定义完整性三种完整性，其中用户自定义完整性包括域的完整性和其他完整性。

①实体完整性。实体完整性也称行的完整性，用来唯一标识表中每一个实体的，通过主键来实现，设置为主键的列（属性）不能取空值，也不能有相同的值。如把员工表中的工号设置为主键，在输入记录时，工号这个属性对应的值不能为空值，也不能有工号相同的多条记录。这样就能唯一标识所有员工。

②参照完整性。参照完整性也称引用完整性，实现两个表之间数据引用的一致性，通过设置外键来实现。参照表中外键的取值要么是空值（如果允许为空值的话），要么是被参照表中的主键值，但不能为其他值（无效值）。如“电子商务系统”中部门表与员工表，部门表中设置“部门编号”为主键，员工表中设置“部门编号”为外键，那么，在员工表中输入数据时，“部门编号”的值，要么是空值（如果允许为空值的话），要么是部门表中“部门编号”存在的值。

③用户自定义完整性。用户自定义完整性则是根据应用环境的要求和实际的业务需要，对某一具体应用所涉及的数据提出约束性条件。主要包括域的完整性（如CHECK约束）和其他完整性（如触发器）。

域的完整性也称列的完整性，保证数据表中列（字段）取值的合理性。如员工表中“性别”这一列的取值只能是“男”或“女”，不能是其他值。

1.任务描述

完成了“电子商务系统”的关系模式设计，设计了系统符合SQL Server 2012的数据表，接下来的任务是对设计的数据表进行规范化检查，这是一项重要的评审工作。设计规范性检查工作内容比较多，本任务要求完成命名规范检查、范式检查、数据类型检查、主键与外键检查等工作任务。

2.任务实现

对数据表设计成果进行规范化检查是一项重要的评审工作，在进行评审时建议进行交叉评审，这一组的设计成果由另一组来评审，在评审前老师对评审内容及涉及的知识进行介绍，各组评审结束后，由老师进行综合总结，并指导各组根据评审结果对设计成果进行修改。

（1）命名规范检查

命名规范，就是需要共同遵循的、通用的命名规则。命名规则有多种，但在同一数据库系统中，应使用统一的、规范的一种命名规则，不要在一个数据库系统中采用多种命名规则。遵守规范的命名规则有助于提高系统设计和开发的效率，并且有利于提高开发的应用程序的可读性和可维护性。根据前面的设计内容，目前主要检查基于SQL Server 2012的“电子商务系统”的表和字段的命名规范。

①数据表名规范化检查。在项目中，常用的数据表命名规则如下：

●　不使用关键字和保留字（如：“create”“table”）。

●　禁止使用带空格的名称（如：“product orders”）。

●　名称长度SQL Server支持1～128个字符，但建议不要太长。

●　使用能体现表中内容的名称（如表存放的是商品信息，可用“product”）。

●　名称使用相应的英文（如订单表，可用“orders”），虽然可以采用中文，但为了后续维护和开发带来方便，建议不要采用中文名称。

●　名称的字符可以使用英文字母、数字、下画线的组合，但不能使用其他特殊符号（如“？”），也不要采用全数字（如“123”），名称的开头字符建议采用英文字母。

根据以上常用的数据表命名规则，对“电子商务系统”的数据表的命名检查情况如表2-9所示。

②字段名的规范化检查。在项目中，数据表中各字段常用的命名规则如下：

●　不使用关键字和保留字（如：“update”“select”）。

●　禁止使用带空格的名称（如：“product name”），对于需用多个单词表达意义的字段名，可以使用单词组合，但中间不带空格（如：“OderDate”可以表示订单日期的字段）。

●　名称长度SQL Server支持1～128个字符，但建议不要太长，如果名称太长，可以采用缩写，缩写一般取前3个字符，也有取前4个字符的（如：“商品编号”可以缩写为“ProName”）。

●　使用能体现字段所表达的属性的名称（如姓名，可用“name”）。

●　名称采用相应的英文或拼音（如地址，可用“address”），虽然可以采用中文，但为了后续维护和开发的方便，建议不要采用中文名称。

●　名称的字符可以使用英文字母、数字、下画线的组合，但不能使用其他特殊符号（如“？”），也不要采用全数字（如“123”），名称的开头字符建议采用英文字母。

●　字段名前不要加表名等作为前缀，字段名后不加任何类型标识作为后缀。

根据以上常用的字段命名规则，对“电子商务系统”中各数据表中字段的命名检查情况如表2-10～表2-16所示。

续表

（2）范式检查

在定义关系模型的同时，也定义了规范化规则（范式），规范化是一种形式化的数学处理过程。在规范化的数据库系统中，应避免对数据的异常修改，在保证数据完整性的前提下，将数据冗余降低到最小。下面将对“电子商务系统”各个数据表进行第一范式（1NF）、第二范式（2NF）和第三范式（3NF）的检查。

第一范式检查：根据表2-2～表2-8的设计可知，每个表设有主键，这样可确保表中的每一行是唯一的，不存在重复的行。同时，可以分析每个表的字段表示的信息是原子性的，不能再进行细分。因此都符合第一范式。

第二范式检查：首先，根据上一步检查，所有的表都符合第一范式。下面检查每个表的非主属性是否完全依赖主属性（主键）。根据表2-2，product表：主属性为ProID，可以分析出非主属性ProName、Stock、UnitPrice、Cost、Picture和OnTime的数据都完全依赖于主属性ProID。根据表2-3，category表：主属性为CatID，可以分析出非主属性CatName和Discribe的数据都完全依赖于主属性CatID。根据表2-4，supplier表：主属性为SupID，可以分析出非主属性SupName、Contact、Address和Telephone的数据都完全依赖于主属性SupID。根据表2-5，orders表：主属性为OrdID，可以分析出非主属性Qty、Total和OrderDate的数据都完全依赖于主属性OrdID。根据表2-6，member表：主属性为MemID，可以分析出非主属性有MemName、Address、Telephone、UserName和UserPwd的数据都完全依赖于主属性MemID。根据表2-7，employee表：主属性为EmpID，可以分析出非主属性EmpName、Sex、Telephone、UserName和UserPwd的数据都完全依赖于主属性EmpID。根据表2-8，department表：主属性为DepID，可以分析出非主属性DepName、Manager和PeoTotal的数据都完全依赖于主属性DepID。因此都符合第二范式。

第三范式检查：首先，根据上一步检查，所有的表都符合第二范式。根据表2-2～表2-8的设计可知，每个表的非主属性之间相互独立，并不存在依赖关系或传递关系。因此都符合第三范式。

综合以上对各个表进行3个范式的检查，其检查结果如表2-17所示。

（3）数据类型检查

在设计数据表时，除了定义各字段名外，还需定义每个字段合理的数据类型及长度。检查“电子商务系统”各个数据表中各字段的数据类型，主要检查数据类型是否合理，如某字段是字符型还是数值型，长度是否合理。SQL Server 2012支持的常用数据类型主要包括数值型、字符型、日期型和位类型，具体如表2-18所示。

续表

根据以上常用的数据类型，检查“电子商务系统”各个数据表中各字段数据类型及长度是否合理，如果不合理，则需进行修改。检查结果如表2-19所示。

（4）主键与外键检查

主键实现了实体完整性约束，唯一标识表中的每一个实体。设置主键的属性，其属性值不能为NULL值，同时具有唯一性，即不能有相同的主键属性值。一个表只能设置一个主键。根据以上要求，检查“电子商务系统”各个数据表中是否设置了主键，是否设置合理（即能否唯一标识每个实体，实现实体完整性）。检查结果如表2-20所示。

外键实现了数据表之间的联系，实现了数据表的参照完整性，是维护数据表之间数据一致的重要方法。一个表可以有多个外键。例如，引用B表中的主键列（属性）作为A表中一个字段，则在A表中此列为它的外键，这样实现了A和B的外键约束关系，在A表中此列的值必须引用B表中此列对应的有效值或NULL值（前提A表此列允许为NULL值）。根据以上描述，检查“电子商务系统”各个数据表之间外键是否设置合理。检查结果如表2-21所示。